bgp community что такое
BGP community
Материал из Xgu.ru
[править] Описание атрибута community
Значения от 0x00000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF зарезервированы.
Как правило community отображаются в формате ASN:VALUE. В таком формате, доступны для использования community от 1:0 до 65534:65535. В первой части указывается номер автономной системы, а во второй значение community, которое определяет политику маршрутизации трафика.
Некоторые значения communities предопределены. RFC1997 определяет три значения таких community. Эти значения должны одинаково распознаваться и обрабатываться всеми реализациями BGP, которые распознают атрибут community.
Если маршрутизатор получает маршрут в котором указано предопределенное значение communities, то он выполняет специфическое, предопределенное действие основанное на значении атрибута.
Предопределенные значения communities (Well-known Communities):
Маршрутизаторы которые не поддерживают атрибут community, будут передавать его далее, так как это transitive атрибут.
[править] BGP community в Cisco
Изменение формата community с 32битного числа на пару 16битных чисел:
По умолчанию community отбрасываются в исходящих обновлениях BGP. Даже если community указывались в соответствующей исходящей route-map. Для того чтобы изменить это, необходимо явно настроить отправку community соседям:
[править] Community internet
В Cisco, кроме well-known значений community, используется также специальное значение internet. Для этого используется значение 0:0.
Community internet используется для обозначения всех маршрутизаторов, так как все маршрутизаторы принадлежат этой community. Например, если в community-list необходимо разрешить все community, кроме одного определенного значения, то permit internet будет использоваться как permit all в ACL.
[править] community-list
Особенности стандартного community-list:
Особенности расширенного community-list:
[править] Community в route-map
Использование community как критерия совпадения в route-map:
Удаление community из входящих или исходящих обновлений BGP:
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 132
— именованные community list
Думаю в пояснениях не требуется, вид такой:
Есть еще одна расширенная Community, которая называется cost community, она так же является не транзитивной, работает только внутри AS, либо в конфедерации и используется для манипулирование маршрутами внутри IBGP. Наименьший cost имеет наиболее высокие приоритет. Формат команды:
set ext community cost [igp] community-id 112 cost-value [0 4294967295]
В следующей заметке рассмотрим примеры настройки и использования community.
Йоб Шнайдерс, NTT: «Large BGP Communities — решение проблемы роутинга между операторами AS»
В августе текущего года в архивах IETF появилось обсуждение способов решения проблемы обмена мета-информацией между автономными системами (AS) по методу RFC1997 BGP communities.
Дело в том, что интернет опять угрожает «кончиться», причём самым неожиданным образом — из-за «скелета в шкафу» или частного, но широкого случая, иллюстрирующего, насколько серьёзной может быть проблема технического долга, известная любому разработчику. Сначала мы наблюдали проблему исчерпания пула IPv4 адресов, в качестве решения которой был введён в эксплуатацию не на 100% функционирующий стандарт IPv6. Теперь на наших глазах назревает другая опухоль, связанная, однако, всё с той же сетевой маршрутизацией.
Написанное Йобом Шнайдерсом из компании NTT открытое письмо к IETF служит стартом общественного обсуждения проблемы, угрожающей вскоре стать критической. Дело в том, что основное удобство RFC1997 — 32-битность записи. Первые 16 бит принадлежат ASN, последние 16 несут в себе какое-то значение. Однако уже сейчас один из пяти операторов автономных систем в сети имеет 4-байтный ASN (RFC4893) (4 байта = 32 бита), что делает невозможным использование 16-битной записи (32-битное значение просто не влазит).
Мы обратились напрямую к Йобу Шнайдерсу за комментарием по данной проблеме.
Йоб Шнайдерс, IP Development Engineer в NTT Communications, основатель NLNOG RING, вице-президент PeeringDB.
Йоб, в двух словах, вы можете объяснить почему larger BGP community является решением данной проблемы?
Всё просто: RFC 1997 BGP Communities это то что используют все ISP (интернет-провайдеры) для обмена мета-информации между автономными системами. Стиль RFC 1997 предлагает вам 2 байта, новые Large Communities — 8 байтов, что отвечает требованиям многих операторов.
Почему проблема усугубляется с каждым новым размещённым ASN?
IANA исчерпала 2-байтные ASN, поэтому по умолчанию вам присвоит 4-байтный ASN, только если вы не попросите иначе. Это значит, что использование лучших практик, таких как communities, для внутренней разметки и роутинга будет вам недоступно. По-крайней мере стандартными способами, как это делают другие операторы и сети. Нельзя просто увеличивать сложность сетевых политик, используя существующие документы — это повышает вероятность ошибок.
Как эта проблема влияет на интернет-провайдеров и обычных пользователей?
Обычные конечные пользователи, как, например, наши родители, вряд ли когда-либо столкнутся с данной проблемой, однако её прямым следствием является неидеальный роутинг, передача трафика за океан тогда, когда он мог быть локализован. Большинство людей разницы не почувствует, но для работников «интернет-канализации» любые сетевые дистанции выше 50 мс обычно заметны и требуют избежания.
Как можно понять или протестировать наличие проблемы?
Если у вас есть BGP-сессия с 4-байтным ASN или вам был присвоен 4-байтный ASN организацией RIPE NCC, то вас это касается. Это лимитирует варианты, которые вы можете предоставить потребителям, так как необходимо использовать либо частный номер, либо захватывать чужой.
Существует ли какой-то способ избежания или решения проблемы?
На сегодняшний день не существует хорошего способа избежания проблемы. RFC 1997 BGP communities это некоторая «Lingua Franca» (термин, объединяющий один язык разных этнических групп) между сетевыми операторами, однако какой-либо международной договорённости не существует. Некоторые сетевые операторы используют приватные 2-байтные ASN в первых двух байтах RFC 1997 communities, а другие операторы используют Extended BGP Communities не по назначению. Итогом являются «не самые лучшие» методы, вредяющие операторскому сообществу.
Наконец, почему это срочно?
Именно из-за исчерпания IANA номеров для AS. Ваш локальный RIR, ARIN, APNIC, Afrinic, LACNIC и RIPE больше не будут иметь ресурсов для обмена. Раньше они разрешали сетям с проблемами возвращать 32-битный ASN взамен 16-битных, но и эта опция для них скоро закроется.
Любой желающий стать частью процесса должен присоединиться к рассылочному листу IDR и прочитать архив. IETF будет голосовать по данной проблеме вплоть до 20 сентября.
» Спецификация Large BGP Communities на IETF.
» Веб-страница Large BGP Communities.
За поддержкой Large BGP communities обращайтесь к своему вендору.
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.
Настройка 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