BGP community routing policy

В этой статье пойдёт речь об использовании атрибута community протокола BGP для управления анонсированием сетей. Статья будет полезна новичкам в BGP, имеющим базовое представление об этом протоколе. Тут не будет листингов с конфигами, которые всё равно никто не читает, да и у разных вендоров они отличаются, но будет объяснение принципов и возможностей использования community.

О чем вообще речь

Community — опциональный транзитивный атрибут протокола BGP, занимает 32 бита и записывается в виде [AS number]:[low order bits], например 100:10001. Вообще, можно писать что угодно, но рекомендуется указывать свою AS, т.к. community передаётся между AS и могут возникать конфликты. На BGP префикс можно повесить определённый community и в другом месте, согласно этому community, применить к префиксу опреденные правила. Чем-то похоже на route tag, только применение намного шире.

Управление маршрутами на 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 может вешать клиент для управления своим трафиком.

Если, например, IX1 поддерживает community и 333:10001 что-то означает, то клиент может повесить community 100:30001 333:10001, в таком случае сеть будет проанонсирована в IX, а оттуда проанонсирована участникам в соответствии с местными правилами.

Управление исходящим трафиком

Топология та же, что и в предыдущем примере.

На маршруты, полученные от аплинков, на бордере вешаем следующие 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.