BGP: community
Добрались мы до атрибута Community.
Если в нескольких словах, для чего используется community? Community используется для маркирования маршрутов (похоже на маркирование в QOS) для того, чтобы можно было в дальнейшем обработать эти маршруты по каким-то специальным правилам.
Например выделить сети для ЦОД, выделить их в отдельный community и назначить им привелигированный маршрут.
Есть зарезервированные Community, такие как:
NO_EXPORT (0xFFFFFF01) — community атрибут не пересылается между пирами внешних AS (тоесть между EBGP пирами)
NO_ADVERTISE (0xFFFFFF02) — при получении маршрута с атрибутом community no_advertise не пересылает этот атрибут не только EBGP но и IBGP пирам.
LOCAL_AS — рассылает только пирам своей подсистемы.
INTERNET — рассылается везде.
По умолчанию community не посылаются.
Существует два вида community:
Standart — название комьюнити словесно.
Extended — обозначается как AS:N, где N номер компьюнити.
Обычно используется стандартное компьюнити. У операторов чаще всего используется расширенное.
По умолчанию как я уже сказал, community не рассылается, для того чтобы community рассылался необходимо в секции BGP указать это для соседа, так:
neighbor 1.1.1.1 send-community
Где указать вид community, будет это расширенный или и стандартный и расширенный комьюнити.
Так же, для того чтоб наш роутер мог работать с новыми расширенными компьюнити нужно указать глобально в настройках роутера: ip bgp-community new-format.
Далее на соседе через route-map вешаем тот community, который нам нужен, итого конфиг будет выглядеть так:
neighbor 1.1.1.1 remote-as 2
neighbor 1.1.1.1 send-community
neighbor 1.1.1.1 route-map SETCOMMUNITY out
route-map SETCOMMUNITY permit 10
set community no-export
Таким образом мы отправим маршруты и ко всем привяжем community no_export.
Что бы этого не происходило, нужно добавить ключ additive.
set community no-export additive
Есть такое понятие как community-list, очень похоже на access-list, тоесть фильтрация на основе атрибута community.
Так же выделяют несколько типов таких листов:
— стандартный community-list, который создается так:
— расширенный community-list имеет нумерацию от 100 до 199 и отличается от стандартных листов тем, что может использовать регулярные выражение, как мы это делали в случае as-path листов.
ip community-list 144
— именованные community list
Думаю в пояснениях не требуется, вид такой:
Есть еще одна расширенная Community, которая называется cost community, она так же является не транзитивной, работает только внутри AS, либо в конфедерации и используется для манипулирование маршрутами внутри IBGP. Наименьший cost имеет наиболее высокие приоритет. Формат команды:
set ext community cost [igp] community-id 243 cost-value [0 4294967295]
В следующей заметке рассмотрим примеры настройки и использования community.
Использование BGP-community Values для управления политикой маршрутизации в Upstream Provider Network
Параметры загрузки
Содержание
Введение
В этом документе показано, как атрибут сообщества протокола BGP (Border Gateway Protocol) можно использовать для управления политикой маршрутизации в сети вышестоящего (основного) поставщика услуг.
Предварительные условия
Требования
Для понимания этого документа необходимо знать принципы работы протокола маршрутизации BGP. Дополнительные сведения см. в разделе Практические примеры BGP.
Используемые компоненты
Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования. Однако сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:
Cisco IOS® Software Release 12.2(27)
Маршрутизаторы Cisco серии 2500
Сведения, представленные в этом документе, получены для устройств в особой лабораторной среде. Все устройства, описанные в данном документе, были запущены с конфигурацией по умолчанию. При работе с реальной сетью необходимо полностью осознавать возможные результаты использования всех команд.
Теоретические сведения
Пока сами сообщества не изменяют процесс принятия решений по BGP, сообщества можно использовать как флаги для пометки набора маршрутов. В этом случае маршрутизаторы основного поставщика услуг могут использовать эти флаги с целью соблюдения политики маршрутизации в своей сети (например, для применения локального предпочтения).
Поставщики услуг устанавливают соответствие между настраиваемыми значениями сообщества и значениями локального предпочтения в сети поставщика услуг. Идея в том, чтобы клиенты с определенными политиками, которые требуют изменения LOCAL_PREF в сети поставщика услуг, задавали соответствующие значения сообщества при обновлении маршрутов.
Сообщество – это группа префиксов, которые используют общее свойство и могут быть настроены с помощью атрибута сообщества BGP. Атрибут сообщества протокола BGP является дополнительным транзитивным атрибутом переменной длины. Этот атрибут состоит из четырех восьмиразрядных значений (октетов), которые определяют сообщество. Значения атрибута сообщества кодируются номером автономной системы (Autonomous System, AS) в двух первых восьмиразрядных значениях (октетах), а остальные два октета определяются автономной системой. Префикс может иметь несколько атрибутов сообщества. Спикер BGP, который видит множество атрибутов сообщества в префиксе, может действовать на основании одного, нескольких или всех атрибутов. Маршрутизатор может добавить или изменить атрибут сообщества, прежде чем передать атрибут другим точкам. Дополнительные сведения об атрибуте сообщества см. в разделе Практические примеры BGP.
Атрибут локального предпочтения показывает автономной системе, какой путь является предпочтительным для выхода в определенную сеть. Если для одного пункта назначения указано несколько путей, предпочтение отдается пути с более высоким значением предпочтения (по умолчанию значение атрибута локального предпочтения равно 100). Дополнительные сведения см. в разделе Атрибут локального предпочтения.
Условные обозначения
Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.
Настройка
Управление политикой маршрутизации
В этом разделе содержатся сведения о настройке функций, описанных в этом документе.
Примечание. Для поиска дополнительных сведений о командах, описываемых в этом документе, используйте Средство поиска команд (доступное только зарегистрированным пользователям ).
Для упрощения предполагается, что соответствие между атрибутом сообщества и атрибутом локального предпочтения установлено между основным поставщиком услуг (AS 100) и клиентом (AS 30).
Если пользователь объявляет префиксы с атрибутом сообщества равными 100:300, тогда основной поставщик услуг настраивает локальное предпочтение этих маршрутизаторов на 130 и 125, если атрибут сообщества равен 100:250.
Это дает возможность управлять политикой маршрутизации в сети поставщика, если вы изменяете значения сообщества для префиксов, объявленных поставщику услуг.
На схема сети клиенту AS 30 требуется такая политика маршрутизации с атрибутами сообщества.
Трафик от поставщика AS 100 в направлении сети 6.6.6.0/24 идет по каналу R1-R3. В случае отказа канала R1-R3 весь трафик идет по каналу R2-R3.
Трафик от поставщика AS 100 в направлении сети 7.7.7.0/24 идет по каналу R2-R3. В случае отказа канала R2-R3 весь трафик идет по каналу R1-R3.
Чтобы применить эту политику маршрутизации, R3 объявляет свои префиксы:
6.6.6.0/24 с атрибутом сообщества 100:300
7.7.7.0/24 с атрибутом сообщества 100:250
6.6.6.0/24 с атрибутом сообщества 100:250
7.7.7.0/24 с атрибутом сообщества 100:300
Когда соседи R1 и R2 (протокол BGP) получат от R3 эти префиксы, R1 и R2 применяют предварительно настроенную политику на основе соответствия между атрибутами сообщества и атрибутами локального предпочтения (см. таблицу). Таким способом соблюдается нужная клиенту (AS 30) политика маршрутизации. R1 устанавливает префиксы в таблице BGP.
6.6.6.0/24 с локальным предпочтением 130
7.7.7.0/24 с локальным предпочтением 125
R2 устанавливает префикс в своей таблице BGP:
6.6.6.0/24 с локальным предпочтением 125
7.7.7.0/24 с локальным предпочтением 130
Поскольку критерии отбора пути BGP отдают предпочтение более высокому локальному приоритету, путь с локальным предпочтением 130 (130 больше, чем 125) выбирается как лучший путь в AS 100 и устанавливается в таблице IP-маршрутизации R1 и R2. Дополнительные сведения о критериях выбора пути BGP см. раздел Алгоритм выбора наилучшего пути BGP.
Схема сети
В этом документе используются настройки сети, показанные на следующей схеме.
Варианты конфигурации
В этом документе используются следующие конфигурации:
Проверка
R1 получает префиксы 6.6.6.0/24 и 7.7.7.0/24 с атрибутами сообщества 100:300 и 100:250, как показано жирным шрифтом в выводе команды show ip bgp в этом разделе.
Примечание. Поскольку эти маршруты устанавливаются в таблице BGP на основе политики настройки, для префиксов с атрибутом сообщества 100:300 назначается локальное предпочтение 130, а для префиксов с атрибутом сообщества 100:250 назначается локальное предпочтение 125.
Команда show ip bgp в R1 подтверждает, что наилучший путь, выбранный в R1, имеет локальное предпочтение (LoclPrf) = 130.
Точно так же R2 получает префиксы 6.6.6.0/24 и 7.7.7.0/24 с атрибутами сообщества 100:250 и 100:300, как показано жирным шрифтом на выходе команды show ip bgp в этом разделе.
Примечание. Поскольку эти маршруты устанавливаются в таблице BGP на основе политики настройки, для префиксов с атрибутом сообщества 100:300 назначается локальное предпочтение 130, а для префиксов с атрибутом сообщества 100:250 назначается локальное предпочтение 125.
Вывод команды show ip bgp в R2 подтверждает, что наилучший путь, выбранный в R2, имеет локальное предпочтение (LoclPrf) = 130.
Для префикса 6.6.6.0/24 предпочтительным IP-маршрутом является канал R1-R3 от поставщика AS 100 к клиенту AS 30. Команда show ip route в R1 и R2 подтверждает это.
Для префикса 7.7.7.0/24 предпочтительным IP-маршрутом является канал R2-R3 от поставщика AS 100 к клиенту AS 30. Команда show ip route в R1 и R2 подтверждает это.
В случае отказа одного канала, например, канала R1-R3, весь трафик должен идти по каналу R2-R3. Вы сможете смоделировать это, если закроете канал между R1-R3.
Обратите внимание на таблицу IP-маршрутизации для префиксов 6.6.6.0/24 и 7.7.7.0/24 в маршрутизаторах R1 и R2. Используйте канал R2-R3 для выхода из AS 100.
Этот вывод команды show показывает, что маршрут для префиксов 6.6.6.0/24 и 7.7.7.0/24 указывает на следующий ожидаемый сегмент 10.10.12.2 (R2). Теперь посмотрим на таблицу IP-маршрутизации в R2, чтобы проверить следующий участок для префиксов 6.6.6.0/24 и 7.7.7.0/24. Для успешной работы следующим должен быть R3 в соответствии с настроенной политикой.
Следующий сегмент 10.10.23.3 – это последовательный интерфейс 9/0 в R3 канала R2-R3 Это подтверждает, что настроенная политика работает правильно.
Настройка BGP атрибута community
Зарезервированные значения community:
1. no—advertise – все маршруты, которые передаются с таким значением атрибута community, не должны анонсироваться другим BGP-соседям.
3. no—export—subconfed– все маршруты, которые передаются с таким значением атрибута community, не должны анонсироваться внешним BGP соседям. Т.е. рассылаются только пирам своей подсистемы.
4. internet – рассылается всем BGPсоседям.
| Рассмотрим настройку на примере следующей топологии: |
 |
Начнем с базовой настройки – поднимем интерфейсы и назначим IP адреса:
AR1
interface GigabitEthernet 0/0/0
ip address 10.1.14.1 255.255.255.0
interface GigabitEthernet 0/0/1
ip address 10.1.12.1 255.255.255.0
interface loopback 0
ip address 1.1.1.1 255.255.255.255
AR2
interface GigabitEthernet 0/0/0
ip address 10.1.25.2 255.255.255.0
interface GigabitEthernet 0/0/1
ip address 10.1.12.2 255.255.255.0
interface GigabitEthernet 0/0/2
ip address 10.1.23.2 255.255.255.0
interface loopback 0
ip address 2.2.2.2 255.255.255.255
AR3
interface GigabitEthernet 0/0/2
ip address 10.1.23.3 255.255.255.0
interface loopback 0
ip address 3.3.3.3 255.255.255.255
AR4
interface GigabitEthernet 0/0/0
ip address 10.1.14.4 255.255.255.0
interface loopback 0
ip address 4.4.4.4 255.255.255.255
AR5
interface GigabitEthernet 0/0/0
ip address 10.1.25.5 255.255.255.0
interface loopback 0
ip address 5.5.5.5 255.255.255.255
Далее настраиваем BGP соседство между устройствами:
AR1
router id 1.1.1.1
bgp 64513
peer 10.1.12.2 as-number 64513
peer 10.1.14.4 as-number 64512
AR2
router id 2.2.2.2
bgp 64513
peer 10.1.12.1 as-number 64513
peer 10.1.23.3 as-number 64514
peer 10.1.25.5 as-number 64515
AR3
router id 3.3.3.3
bgp 64514
peer 10.1.23.2 as-number 64513
AR4
router id 4.4.4.4
bgp 64512
peer 10.1.14.1 as-number 64513
AR5
router id 5.5.5.5
bgp 64515
peer 10.1.25.2 as-number 64513
На этом базовая настройка окончена.
1. Настройка общего community атрибута. На маршрутизаторе AR5 поднимем три loopback интерфейса и объявим их в BGP процессе:
AR5
interface loopback 1
ip address 10.1.5.5 255.255.255.0
interface loopback 2
ip address 10.2.5.5 255.255.255.0
interface loopback 3
ip address 10.3.5.5 255.255.255.0
bgp 64515
network 10.1.5.5 255.255.255.0
network 10.2.5.5 255.255.255.0
network 10.3.5.5 255.255.255.0
AR2
bgp 64513
peer 10.1.12.1 next-hop-local
Проверим BGP таблицу маршрутизации на AR2 и AR4:
[AR2] display bgp routing-table
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.5.0/24 10.1.25.5 0 0 64515i
*> 10.2.5.0/24 10.1.25.5 0 0 64515i
*> 10.3.5.0/24 10.1.25.5 0 0 64515i
[AR4] display bgp routing-table
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.5.0/24 10.1.14.1 0 64513 64515i
*> 10.2.5.0/24 10.1.14.1 0 64513 64515i
*> 10.3.5.0/24 10.1.14.1 0 64513 64515i
Теперь на маршрутизаторе AR5 создадим политику при помощи которой будем добавлять community атрибут 100 к маршруту 10.1.5.0/24:
AR5
acl number 2000
rule 5 permit source 10.1.5.0 0.0.0.255
route-policy com5 permit node 5
if-match acl 2000
apply community 100
bgp 64515
peer 10.1.25.2 route-policy com5 export
Также разрешим объявлять community атрибут на всех маршрутизаторах:
AR1
bgp 64513
peer 10.1.14.4 advertise-community
peer 10.1.12.2 advertise-community
AR2
bgp 64513
peer 10.1.12.1 advertise-community
peer 10.1.23.3 advertise-community
peer 10.1.25.5 advertise-community
AR3
bgp 64514
peer 10.1.23.2 advertise-community
AR4
bgp 64512
peer 10.1.14.1 advertise-community
AR5
bgp 64515
peer 10.1.25.2 advertise-community
Проверим передачу атрибута на маршрутизаторах AR2 и AR 4:
[AR2] display bgp routing-table community
Total Number of Routes: 1
Network NextHop MED LocPrf PrefVal Community
*> 10.1.5.0/24 10.1.25.5 0 0
[AR4] display bgp routing-table community
Total Number of Routes: 1
Network NextHop MED LocPrf PrefVal Community
*> 10.1.5.0/24 10.1.14.1 0
AR5
acl 2100
rule 5 permit source 10.2.5.0 0.0.0.255
route-policy com5 permit node 10
if-match acl 2100
apply community no-export
acl number 2200
rule 5 permit source 10.3.5.0 0.0.0.255
route-policy com5 permit node 15
if-match acl 2200
apply community no-advertise
Проверим какие атрибуты получает маршуртизатор AR 2:
[AR2] display bgp routing-table community
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Community
*> 10.1.5.0/24 10.1.25.5 0 0
*> 10.2.5.0/24 10.1.25.5 0 0 no-export
*> 10.3.5.0/24 10.1.25.5 0 0 no-advertise
Проверим таблицы маршрутизации на AR2, AR1, AR 4 и проверим какие маршруты они получают:
[AR2] display bgp routing-table
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.1.5.0/24 10.1.25.5 0 0 64515i
*>i 10.2.5.0/24 10.1.25.5 0 0 64515i
*>i 10.3.5.0/24 10.1.25.5 0 0 64515i
[AR1] display bgp routing-table
Total Number of Routes: 2
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.1.5.0/24 10.1.12.2 0 100 0 64515i
*>i 10.2.5.0/24 10.1.12.2 0 100 0 64515i
Total Number of Routes: 1
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.5.0/24 10.1.14.1 0 64513 64515i
Как видим, AR2 не объявляет маршрут 10.2.5.0/24 за пределы своей автономной системы, но объявляет его маршрутизатору AR1, так как они находятся в одной автономной системе. И AR2 не объявляет маршрут 10.3.5.0/24 ни одному BGP устройству, так как у него атрибут no-advertise.
3. Настройка атрибута community для суммирования маршрутов. Поднимем loopback интерфейсы на AR3 и объявим их в BGP процесс.
AR3
interface loopback 1
ip address 10.1.3.3 255.255.255.0
interface loopback 2
ip address 10.2.3.3 255.255.255.0
bgp 64514
network 10.1.3.3 255.255.255.0
network 10.2.3.3 255.255.255.0
Мы хотим чтобы маршрут 10.1.5.0/24, объявляемый маршрутизатором AR5 и маршрут 10.2.3.0/24, объявляемый AR3 были просуммированы в сеть класса А 10.0.0.0/8. Community атрибут данного маршрута должен быть 200. Маршрут 10.1.3.0/24 должен быть объявлен маршрутизатору AR4. Для этого создадим политику маршрутизации на AR 3, в которой будем добавлять атрибут 100 маршруту 10.2.3.0/24.
AR3
acl 2100
rule 5 permit source 10.2.3.0 0.0.0.255
route-policy com3 permit node 5
if-match acl 2100
apply community 100
route-policy com3 permit node 10
bgp 64514
peer 10.1.23.2 route-policy com3 export
На AR1, полученные маршруты 10.1.5.0/24 и 10.2.3.0/24 несут community атрибут 100.
[AR1] display bgp routing-table community
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Community
*>i 10.1.5.0/24 10.1.12.2 0 100 0
*>i 10.2.3.0/24 10.1.12.2 0 100 0
*>i 10.2.5.0/24 10.1.12.2 0 100 0 no-export
Отфильтруем маршруты с community атрибутом 100. А также создадим две политики, в которых мы будем суммировать маршруты и добавлять атрибут 200:1 к суммированному маршруту:
AR1
ip community-filter 1 permit 100
route-policy match_com permit node 5
if-match community-filter 1
route-policy add_com permit node 5
apply community 200:1 additive
Далее на AR1 в BGP процессе будем суммировать маршруты, которые попадают под политику match_com и добавим к ним атрибут при помощи политики add_com :
AR1
bgp 64513
aggregate 10.0.0.0 255.0.0.0 detail-suppressed origin-policy match-com attribute-policy add_com
Проверим BGP таблицу маршрутизации на AR 4:
[AR4] display bgp routing-table
Total Number of Routes: 2
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.0.0.0 10.1.14.1 0 64513i
*> 10.1.3.0/24 10.1.14.1 0 64513 64514i
[AR4] display bgp routing-table community
Total Number of Routes: 1
Network NextHop MED LocPrf PrefVal Community
*> 10.0.0.0 10.1.14.1 0
У статьи есть другие ресурсы
Требуется войти для загрузки или просмотра. Нет аккаунта? Register
BGP community routing policy
В этой статье пойдёт речь об использовании атрибута community протокола BGP для управления анонсированием сетей. Статья будет полезна новичкам в BGP, имеющим базовое представление об этом протоколе. Тут не будет листингов с конфигами, которые всё равно никто не читает, да и у разных вендоров они отличаются, но будет объяснение принципов и возможностей использования community.
О чем вообще речь
Управление маршрутами на IX
Рассмотрим типичную точку обмена трафиком.
Каждый участник отдаёт свои сети RS’у, который отдаёт все сети всем участникам. Допустим, Member1 не хочет, чтоб Member2 видел его маршруты через этот IX. Для этого на RS1 в исходящих фильтрах добавляется запрет на анонсирование маршрутов с определённым community. Например, участнику 1 не отдаём маршруты с community 1:0, участнику 2 — с 2:0, участнику 3 — с 3:0. Участник 1 в исходящем фильтре вешает на свои префиксы community 2:0 — в результате Участник 2 не получает его сети от RS, а остальные — получают.
Управление входящим трафиком
Рассмотрим провайдерскую сеть со следующей топологией:
Задача:
1) Указывать, куда следует анонсировать сети региона, на региональном маршрутизаторе (а не объединять сети всех регионов в большую свалку на пограничнике). Подзадача — анонсировать по разному с разных пограничников, но сейчас это рассматривать не будем.
2) Предоставить клиентам возможность управления своим входящим трафиком, как в примере с IX.
Для этого пишем следующие правила:
100:1000[0,1,3,5] — правило анонсирования аплинку 1 (0 — не анонсировать, 1 — просто анонсировать 3 — добавить AS100 3 раза, 5 — добавить AS100 5 раз)
100:2000[0,1,3,5] — правило анонсирования аплинку 2
100:3000[0,1,3,5] — правило анонсирования IX1
На бордере настраиваем соответствующие исходящие фильтры на каждого аплинка.
Повесив на региональном маршрутизаторе на набор префиксов, анонсируемых в iBGP бордеру, набор community 100:10001 100:20003 100:30000, сети региона будут проанонсированы аплинку 1 без препенда, аплинку 2 с препендом и не проанонсированы IX1. Аналогичные community может вешать клиент для управления своим трафиком.
Управление исходящим трафиком
Топология та же, что и в предыдущем примере.
На маршруты, полученные от аплинков, на бордере вешаем следующие community:
100:65001 — маршруты, полученные от Uplink1
100:65002 — маршруты, полученные от Uplink2
100:65003 — маршруты, полученные от IX1
Допустим, клиенту надо отдать только маршруты, полученные от Uplink1 — в исходящем фильтре на клиента разрешаем только маршруты с community 100:65001. Или, если надо отдать все маршруты и дать клиенту возможность выставить для маршрутов от разных аплинков разный local-pref. Вообще, то же самое можно сделать при помощи as-path фильтров, но если с какой-то AS есть несколько пирингов с разной стоимостью трафика — тут на помощь приходит community.
Таким же образом можно по-разному шейпить или тарифицировать трафик к разным аплинкам.
Рассказываем о своей политике Интернету
Правила community должны быть записаны в формате RPSL и выложены во whois базе регионального регистратора (для Европы и СНГ это RIPE). Кроме того, можно выложить на сайте, чтоб клиентам проще было найти.
Well-known community
Кроме создаваемых вручную, RFC1997 опредяет 3 общеизвестных community:
1) NO_EXPORT (0xFFFFFF01) — не отдавать префиксы полноценными eBGP пирам, но отдавать eBGP пирам внутри конфедерации
2) NO_ADVERTISE (0xFFFFFF02) — не отдавать префиксы никому
3) NO_EXPORT_SUBCONFED (0xFFFFFF03) — не отдавать префиксы никаким eBGP пирам, включая конфедерацию
В документации Cisco можно ещё найти упоминание о community Internet (0), префиксы с которой должны отдаваться всем пирам. В RFC об этом ничего не сказано, на практике, даже в роутерах Cisco, если в фильтре разрешить только маршруты с указанными нами community (и не упомянуть Internet), то маршруты с community Internet никуда анонсироваться не будут.
У BGP community есть и другие применения, например, перенос метрики клиентского IGP через MPLS-VPN, кроме того, есть cost community, добавляющие условия в BGP best path selection algorithm, но в данной статье моей целью было описать использование этого атрибута в «чистом» BGP.
