Теоретические основы и архитектура

BGP Communities представляют собой числовые теги (атрибуты), прикрепляемые к префиксам BGP для автоматизации управления политиками маршрутизации. Существуют Standard Communities (32 бита, формат AA:NN, RFC 1997), Extended Communities (64 бита, используются для Route Target в L3VPN, RFC 4360) и Large Communities (96 бит, формат Global_Admin:Data1:Data2 для 4-байтных AS, RFC 8092). В операторской сети комьюнити используются для управления атрибутом Local Preference (влияющим на выбор пути оттока трафика из AS), манипуляции длиной AS_PATH через Prepending, ограничения области анонсов (Well-known communities: NO_EXPORT, NO_ADVERTISE) и активации механизмов защиты от DDoS (Blackholing community 65535:666). При прохождении границы автономной системы оператор обязан фильтровать входящие клиентские комьюнити, чтобы абоненты не могли несанкционированно переопределять внутренние политики ядра.

Три формата community

Community - необязательный транзитивный атрибут, который не влияет на выбор пути сам по себе, а служит меткой для политик. Существует три формата:

ФорматРазмерЗаписьТип атрибутаГде применяется
Standard (RFC 1997)32 битаASN:значение (16+16 бит)8теги региона, клиента, actions
Extended (RFC 4360)64 битатип:администратор:значение16Route Target и Site of Origin в VPN
Large (RFC 8092)96 битглобальный админ:данные1:данные2 (32+32+32)32операторские схемы с 4-байтными ASN

В 16-битное поле standard community не помещается 4-байтная AS, поэтому для 4-байтных ASN используют Large. Extended community содержат тип, подтип и значение: Route Target передаётся как target:65000:100 в формате 2-байтной AS и 4-байтного номера, а в сети с 4-байтными ASN применяется другой тип кодирования. Extended и large community передаются отдельными атрибутами, и set community не затрагивает extcommunity.

Well-known communities

Значения зарезервированы IANA и действуют без настройки на соседях:

  • NO_EXPORT (65535:65281, 0xFFFFFF01): маршрут не отправляется eBGP-соседям за пределы AS (в confederation - за пределы confederation).
  • NO_ADVERTISE (65535:65282): маршрут не отправляется вообще никому из BGP-соседей.
  • NO_EXPORT_SUBCONFED / LOCAL_AS (65535:65283): маршрут не уходит за пределы sub-AS.
  • BLACKHOLE (65535:666, RFC 7999): запрос на отбрасывание трафика к префиксу (RTBH).
  • GRACEFUL_SHUTDOWN (65535:0, RFC 8326): сосед просит перевести трафик на другой путь перед обслуживанием.

Информационные и управляющие метки

Оператор строит схему из двух классов меток:

  • Информационные (маркировка при приёме): регион, тип соседа, точка входа, например 65000:100 для клиента A. Они используются в экспортных политиках: клиентские маршруты уходят всем, маршруты провайдеров - только клиентам.
  • Управляющие (action): клиент сам просит поведение через метку, например 65000:80 задаёт LOCAL_PREF 80 (резервный вход), 65000:666 включает blackhole, 65000:1001 просит prepend для апстрима 1.

Метки должны быть описаны и опубликованы для клиентов; любая схема без документации превращается в неуправляемый набор чисел.

Политика на входе: фильтрация, а не доверие

Клиентские community нельзя пропускать внутрь без проверки. Правила: (1) принимать только собственные префиксы клиента (prefix-list), (2) удалять или заменять чужие community (set community 65000:100 без additive в Cisco/Huawei перезаписывает список; в Junos аналогичное поведение даёт community set), (3) action-метки обрабатывать только при совпадении префикса и метки. Ошибка (2) в Junos особенно опасна: community и Route Target в Junos хранятся в одном списке, и community set CUST в vrf-export политике удалит RT, после чего VPN-маршрут не импортируется ни в одну VRF.

Передача community по сети

По умолчанию Cisco не отправляет community соседям: нужно send-community (standard), send-community extended или both. На Huawei это peer ... advertise-community (для extended - advertise-ext-community), в Junos community передаются по умолчанию, в RouterOS в BGP-соединении они передаются по умолчанию, но фильтры могут их менять. Если на RR или PE не включена передача, метка исчезает на ближайшем узле, и политики на удалённых PE перестают срабатывать, при том что на PE1 всё выглядит корректно.

RTBH: blackhole community шаг за шагом

  1. Клиент A под DDoS анонсирует /32 жертвы 203.0.113.77/32 с меткой 65000:666.
  2. PE1 проверяет по prefix-list, что /32 лежит внутри блока клиента (203.0.113.0/24 le 32), иначе любой клиент отключил бы чужую сеть.
  3. Политика меняет next hop на 192.0.2.1 (адрес из TEST-NET-1 со статикой на Null0/discard), ставит высокий LOCAL_PREF и NO_EXPORT.
  4. Маршрут распространяется по iBGP, и каждый edge-PE, получив его, разрешает next hop в discard-маршрут: трафик на жертву отбрасывается на входе в сеть, а не доходит до клиента.

Нужно разрешить приём /32 именно для этой метки: обычный фильтр ограничивает длину префикса /24.

Алгоритм выбора лучшего пути

Cisco IOS-XE и аналогичные платформы сравнивают атрибуты в таком порядке:

  1. Weight (только Cisco; Huawei аналог preferred-value) - больше лучше.
  2. LOCAL_PREF - больше лучше (по умолчанию 100; Junos preference 170 - это другое).
  3. Локально созданный маршрут (network, redistribute, aggregate).
  4. Кратчайший AS_PATH.
  5. Наименьший Origin (IGP < EGP < incomplete).
  6. Наименьший MED, сравнивается только между путями от одной соседней AS (если нет always-compare-med).
  7. eBGP лучше iBGP.
  8. Наименьшая метрика IGP до next hop.
  9. Самый старый eBGP-путь, затем наименьший router-id (ORIGINATOR_ID), кратчайший CLUSTER_LIST, наименьший адрес соседа.

Community влияют на выбор через политики, которые меняют LOCAL_PREF, AS_PATH (prepend) или MED; сами по себе они не сравниваются.

Типовые ошибки

Забыт send-community; policy без финального term (неявный deny отбрасывает все остальные маршруты); перезапись community вместо additive; приём blackhole без проверки владельца префикса; LOCAL_PREF задан на одном PE, а на другом перебивается политикой RR; сравнение MED между разными AS; распространение no-export внутри VPN без понимания границы AS.

Схема архитектуры и топология