BGP Communities: стандартные, large и extended

Что такое BGP communities?

BGP communities -- это 32-битные теги, которые прикрепляются к анонсам маршрутов. Они несут сигнальную информацию между автономными системами, не меняя сам маршрут. Community говорит: «обработай этот префикс иначе» -- понизь предпочтение, сделай prepend, отбрось полностью или анонсируй только определённым пирам. Communities транзитивны: они распространяются через BGP-сессии, если их явно не убрать. Существует три типа: стандартные (RFC 1997), extended (RFC 4360) и large (RFC 8092).

Communities решают проблему координации. Без них каждое решение по маршрутной политике требует двусторонней настройки на обоих концах сессии. С communities ваш аплинк или route server на IX читает ваши теги и применяет запрошенную политику. Вы ставите тег один раз -- сеть действует.

Если вам сначала нужно поднять BGP-сессию, смотрите BIRD2 BGP Configuration on Linux или FRR BGP Configuration on Linux.

Какие три типа BGP communities существуют?

Они различаются размером, кодированием и задачами, которые они решают. Стандартные покрывают большинство случаев, но ломаются с 4-байтными ASN. Large communities исправляют это ограничение. Extended communities используются в специализированных приложениях управляющей плоскости (control plane).

Свойство	Standard (RFC 1997)	Large (RFC 8092)	Extended (RFC 4360)
Размер	32 бита	96 бит (3 x 32 бита)	64 бита
Формат	ASN:value	ASN:value1:value2	type:subtype:value
Поддержка ASN	только 2-байтные	нативная 4-байтная	2 или 4-байтные (зависит от типа)
BGP-атрибут	COMMUNITIES (8)	LARGE_COMMUNITIES (32)	EXTENDED COMMUNITIES (16)
Основное применение	Сигнализация аплинку, traffic engineering	То же, но с поддержкой 4-байтных ASN	MPLS VPN, EVPN, route targets
Распространённость	Повсеместно	Повсеместно с ~2018	Протокол-специфичные

Standard communities (RFC 1997)

Стандартные communities -- это 32-битные значения, записываемые как два 16-битных целых через двоеточие: ASN:value. Старшие 16 бит определяют AS, которая задаёт значение community. Младшие 16 бит несут действие или информацию.

Пример: 174:70 означает «Cogent: установить local preference 70». Только Cogent определяет, что значит 70 в пространстве имён 174. Каждый провайдер публикует свои определения communities.

16-битное поле ASN ограничивает стандартные communities двухбайтными ASN (0-65535). По состоянию на 2026 год выделено более 120 000 ASN, и большинство новых назначений -- 4-байтные. Стандартные communities не могут их представить.

IANA резервирует диапазон 65535:0 -- 65535:65535 для well-known communities.

Large communities (RFC 8092)

Large communities используют три 32-битных целых: Global Administrator : Local Data 1 : Local Data 2. Global administrator -- это ASN сети, определяющей community. Оба поля local data задаются оператором.

Этот формат решает проблему 4-байтных ASN. AS с номером 398465 может определить 398465:100:0 как валидную large community. Стандартные communities так не умеют.

Трёхполевая структура позволяет задавать более богатую семантику. Распространённый паттерн -- ASN:function:parameter. Например, 35661:1010:174 может означать «prepend один раз во Франкфурте в сторону Cogent (AS174)».

Поддержка large communities есть в BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+ и Junos 17.3+. Если ваш BGP-демон выпущен после 2018 года, он почти наверняка их поддерживает.

Extended communities (RFC 4360)

Extended communities -- это 64-битные значения с полями type, subtype и value. В отличие от стандартных и large communities, у extended communities структурированная семантика: type и subtype определяют, как интерпретировать значение.

Extended communities встречаются в основном в:

• MPLS L3VPN: Route targets (rt 65000:100) и route distinguishers управляют импортом/экспортом VRF
• EVPN: MAC mobility, ESI labels и route types
• BGP Flowspec: ограничение скорости трафика и redirect-действия

Для traffic engineering между автономными системами стандартные и large communities -- правильный инструмент. Extended communities важны, когда вы запускаете оверлейные сервисы. Далее в статье речь пойдёт о стандартных и large communities.

Что такое well-known BGP communities?

IANA определяет несколько well-known community-значений в зарезервированном диапазоне 65535:*. Каждая соответствующая стандарту реализация BGP обязана их понимать.

Community	Значение	Hex	Поведение	RFC
NO_EXPORT	65535:65281	0xFFFFFF01	Не анонсировать за пределы локальной AS-конфедерации	1997
NO_ADVERTISE	65535:65282	0xFFFFFF02	Не анонсировать ни одному BGP-пиру	1997
NO_EXPORT_SUBCONFED	65535:65283	0xFFFFFF03	Не анонсировать за пределы локальной AS	1997
NOPEER	65535:65284	0xFFFFFF04	Не анонсировать билатеральным пирам	3765
BLACKHOLE	65535:666	0xFFFF029A	Запросить blackhole для помеченного префикса	7999
GRACEFUL_SHUTDOWN	65535:0	0xFFFF0000	Сигнал о плановом отключении сессии, установить local-pref в 0	8326

NO_EXPORT -- самый используемый. Пометьте префикс этим тегом, и ваш пир не будет ре-анонсировать его за пределы своей AS. Так контролируют утечки маршрутов третьим сторонам.

BLACKHOLE и GRACEFUL_SHUTDOWN подробно рассмотрены ниже, в разделах по traffic engineering.

Как BGP communities применяются для traffic engineering?

Communities позволяют влиять на решения маршрутизации в сетях, которыми вы не управляете. Вы не можете зайти на роутеры аплинка и поменять конфиг. Но вы можете пометить свои анонсы communities, которые аплинк согласился обрабатывать. Это и есть BGP traffic engineering через communities.

Как работает сигнализация local preference через communities?

Большинство транзитных провайдеров предлагают communities, которые устанавливают local preference вашего префикса внутри их сети. Более высокий local preference означает «предпочтительный путь». Более низкий -- «использовать только как резерв».

Например, провайдер с AS 64500 может определить:

Community	Эффект
64500:100	Обычный preference (по умолчанию)
64500:90	Пониженный preference (резервный путь)
64500:150	Повышенный preference (предпочтительный путь)

Помечая анонс 64500:90 при отправке одному аплинку и оставляя значение по умолчанию для другого, вы смещаете входящий трафик в сторону аплинка без backup community. Это работает, потому что local preference оценивается раньше длины AS-path в процессе принятия решений BGP.

Проверяйте документацию вашего провайдера. Значения выше даны для примера. Каждый провайдер определяет свою схему.

Как работает BGP prepending через communities?

AS-path prepending искусственно увеличивает длину пути, чтобы сделать маршрут менее предпочтительным для удалённых сетей. Вместо того чтобы делать prepend на своём роутере (что затронет всех пиров одинаково), communities позволяют запрашивать prepending выборочно.

Типичная схема провайдера:

Community	Эффект
64500:1001	Prepend 1x для всех пиров
64500:1002	Prepend 2x для всех пиров
64500:1003	Prepend 3x для всех пиров

С large communities можно указать цель точнее:

Large community	Эффект
64500:1:174	Prepend 1x в сторону Cogent (AS174)
64500:2:174	Prepend 2x в сторону Cogent (AS174)
64500:3:0	Prepend 3x для всех пиров

Именно эта гранулярность делает large communities заменой стандартным для traffic engineering. Третье поле кодирует целевой ASN или группу пиров.

Как работает BGP blackholing с community BLACKHOLE?

Blackholing указывает вышестоящим сетям отбрасывать весь трафик, предназначенный помеченному префиксу. Это инструмент защиты от DDoS: когда IP под атакой, вы анонсируете его с community BLACKHOLE, и ваши аплинки null-route'ят трафик до того, как он попадёт в вашу сеть.

RFC 7999 стандартизирует well-known community 65535:666 для этой цели.

Требования для работы blackholing:

1. Точность префикса. Анонсируйте /32 (IPv4) или /128 (IPv6) для целевого IP. Никогда не blackhole'те целый /24.
2. Двустороннее соглашение. Ваш аплинк должен быть настроен на обработку community BLACKHOLE. Это не автоматически. Уточните у провайдера.
3. Тег NO_EXPORT. Всегда добавляйте NO_EXPORT вместе с BLACKHOLE, чтобы blackhole не распространялся за пределы непосредственного аплинка.
4. Мониторинг. Blackholing отбрасывает весь трафик -- и легитимный, и вредоносный. Мониторьте и отзывайте анонс, как только атака прекратится.

Большинство IX route servers тоже поддерживают blackholing через 65535:666. Route server устанавливает next-hop на blackhole-адрес и добавляет NO_EXPORT перед редистрибуцией.

Как использовать communities для выборочного анонса?

Выборочный анонс (selective announcement) позволяет управлять тем, какие пиры или IX видят ваш префикс. Это паттерн «не анонсировать кому» или «анонсировать только кому».

Типичные реализации используют модель deny/allow:

Community	Эффект
64500:0:0	Не анонсировать никому (глобальный deny)
64500:0:174	Не анонсировать Cogent
64500:8:174	Анонсировать только Cogent (переопределение deny)

У Virtua (AS35661) это реализовано через схему communities с привязкой к локациям, описанную в справочной таблице ниже.

Как работает graceful shutdown с community GRACEFUL_SHUTDOWN?

RFC 8326 определяет community GRACEFUL_SHUTDOWN (65535:0) для планового обслуживания. Когда нужно погасить BGP-сессию, пометка маршрутов этим community сообщает принимающим роутерам, что нужно понизить local preference до 0 и начать предпочитать альтернативные пути до того, как вы отключитесь.

Последовательность:

1. Добавить community GRACEFUL_SHUTDOWN ко всем маршрутам, отправляемым пиру на обслуживание
2. Дождаться конвергенции (трафик перемещается на альтернативные пути)
3. Погасить BGP-сессию
4. Провести обслуживание
5. Поднять сессию обратно
6. Убрать community

Без graceful shutdown разрыв сессии вызывает немедленный отзыв маршрутов. Трафик падает, пока BGP не сконвергирует на альтернативном пути. С graceful shutdown трафик переключается постепенно до того, как сессия упадёт.

Это напрямую связано со стратегиями multi-homing failover.

Как настроить BGP communities в BIRD2?

BIRD2 использует типизированные атрибуты communities на объектах маршрутов. Три соответствующих атрибута:

Атрибут	Тип	Тип community
bgp_community	clist (список пар)	Standard
bgp_large_community	lclist (список триплетов)	Large
bgp_ext_community	eclist (список extended)	Extended

Добавление communities в BIRD2

Используйте метод .add() в блоках фильтров:

filter export_to_upstream {
  # Add standard community
  bgp_community.add((65535, 666));

  # Add large community
  bgp_large_community.add((35661, 1010, 174));

  # Add multiple communities
  bgp_community.add((65535, 65281));  # NO_EXPORT

  accept;
}

Сопоставление communities в BIRD2

Проверка принадлежности оператором ~:

filter import_from_peer {
  # Match a specific standard community
  if (65535, 666) ~ bgp_community then {
    dest = RTD_BLACKHOLE;
    accept;
  }

  # Match a specific large community
  if (35661, 9999, 0) ~ bgp_large_community then {
    reject;
  }

  # Match with wildcards using sets
  # Any community in the 64500:* range
  if bgp_community ~ [(64500, *)] then {
    bgp_local_pref = 50;
  }

  accept;
}

Оператор ~ возвращает true, если левый операнд является членом правого. Для сопоставления множеств используйте паттерны пар/триплетов с * в качестве wildcard.

Удаление communities в BIRD2

Очистка communities на входе для предотвращения несанкционированной сигнализации:

filter scrub_inbound {
  # Remove all communities in our ASN namespace
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, *, *)]);

  # Remove specific well-known community
  bgp_community.delete((65535, 666));

  accept;
}

Обработка graceful shutdown в BIRD2

function honor_graceful_shutdown() {
  if (65535, 0) ~ bgp_community then {
    bgp_local_pref = 0;
  }
}

filter ebgp_inbound {
  honor_graceful_shutdown();
  # ... other import filters
  accept;
}

Примените ebgp_inbound как import-фильтр на всех EBGP-сессиях. Когда пир отправляет community GRACEFUL_SHUTDOWN, фильтр устанавливает local preference в 0, и ваш роутер предпочитает любой альтернативный путь.

Blackhole trigger в BIRD2

protocol static blackhole_triggers {
  ipv4 {
    table master4;
  };
  # Announce 203.0.113.5/32 with BLACKHOLE + NO_EXPORT
  route 203.0.113.5/32 blackhole;
}

filter export_blackhole {
  if dest = RTD_BLACKHOLE then {
    bgp_community.add((65535, 666));    # BLACKHOLE
    bgp_community.add((65535, 65281));  # NO_EXPORT
    # Accept only /32 for blackholes
    if net.len = 32 then accept;
  }
  reject;
}

Как настроить BGP communities в FRR?

FRR использует определения community-list в стиле IOS и действия route-map. Communities сопоставляются через match, устанавливаются через set.

Определение community lists в FRR

! Standard community list - match specific community
bgp community-list standard BLACKHOLE permit 65535:666
bgp community-list standard GRACEFUL_SHUTDOWN permit 65535:0
bgp community-list standard NO_EXPORT permit no-export

! Large community list
bgp large-community-list standard PREPEND_1X permit 35661:1:0
bgp large-community-list standard NO_ANNOUNCE permit 35661:9:0

FRR поддерживает как нумерованные (1-99 для standard, 100-500 для expanded), так и именованные community lists. Именованные проще поддерживать.

Установка communities в route-maps FRR

route-map EXPORT-TO-UPSTREAM permit 10
 set community 65535:666 no-export additive
!
route-map EXPORT-TO-UPSTREAM permit 20
 set large-community 35661:1010:174 additive

Ключевое слово additive добавляет communities вместо замены существующих. Без него set community перезаписывает все текущие communities.

Сопоставление communities в route-maps FRR

route-map IMPORT-FROM-PEER permit 10
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!
route-map IMPORT-FROM-PEER permit 20
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map IMPORT-FROM-PEER permit 30
 ! Default: accept everything else

Удаление communities в FRR

route-map SCRUB-INBOUND permit 10
 set comm-list OUR_COMMUNITIES delete
 set large-comm-list OUR_LARGE_COMMUNITIES delete
!
bgp community-list expanded OUR_COMMUNITIES permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMUNITIES permit 35661:.*:.*

Это удаляет все communities в вашем пространстве имён ASN, которые пир мог бы внедрить. Примените этот route-map как neighbor <peer> route-map SCRUB-INBOUND in.

Graceful shutdown в FRR

FRR предоставляет встроенную команду:

router bgp 35661
 bgp graceful-shutdown

Это автоматически добавляет community GRACEFUL_SHUTDOWN (65535:0) ко всем маршрутам, отправляемым EBGP-пирам. Используйте перед плановым обслуживанием.

На принимающей стороне примените route-map, который сопоставляет community и понижает local preference:

route-map HONOR-GSHUT permit 10
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map HONOR-GSHUT permit 20
 ! Accept everything else at normal preference

Сравнение конфигурации communities: BIRD2 vs FRR

Операция	BIRD2	FRR
Добавить standard community	bgp_community.add((ASN, val))	set community ASN:val additive
Добавить large community	bgp_large_community.add((ASN, v1, v2))	set large-community ASN:v1:v2 additive
Сопоставить standard community	if (ASN, val) ~ bgp_community	match community LIST_NAME
Сопоставить large community	if (ASN, v1, v2) ~ bgp_large_community	match large-community LIST_NAME
Удалить по паттерну	bgp_community.delete([(ASN, *)])	set comm-list LIST_NAME delete
Wildcard-сопоставление	[(ASN, *)] в выражении множества	Expanded community-list с regex
Применить фильтр	import filter name; в протоколе	neighbor X route-map NAME in

BIRD2 обрабатывает операции с communities inline внутри filter-функций. FRR разделяет определение (community-list) и действие (route-map). Оба подхода работают. Inline-синтаксис BIRD2 компактнее для сложной логики с условиями. Разделённая модель FRR читабельнее для простых match-and-set политик.

Какие значения BGP communities у Virtua?

Virtua (AS35661) поддерживает стандартные и large BGP communities. Large communities используют формат 35661:ACTION_LOCATION:TARGET. Схема привязана к локациям, что позволяет управлять анонсами по POP, по типу пиров или по конкретному ASN пира.

Коды локаций

Код	Город	Страна	POP ID
000	Париж	Франция	PAR01FR
001	Лилль	Франция	LIL01FR
010	Франкфурт	Германия	FRA01DE
020	Амстердам	Нидерланды	AMS01NL
999	Все локации	--	ALL

Action communities

Действие	Формат large community	Эффект
Источник маршрута	35661:0[LOC]:TARGET	Информационное: откуда получен маршрут
Prepend 1x	35661:1[LOC]:TARGET	Prepend AS35661 один раз в сторону target
Prepend 2x	35661:2[LOC]:TARGET	Prepend AS35661 два раза в сторону target
Prepend 3x	35661:3[LOC]:TARGET	Prepend AS35661 три раза в сторону target
Только экспорт	35661:8[LOC]:TARGET	Переопределение deny: анонсировать только target
Не экспортировать	35661:9[LOC]:TARGET	Не анонсировать target

Селекторы target

Значение target	Смысл
0	Все пиры на указанной локации
1	Только транзитные пиры
2	Только IX-пиры
Конкретный ASN	Один пир (например, 174 для Cogent)

Правила приоритета

При конфликте нескольких communities Virtua оценивает их в следующем порядке (наивысший приоритет первый):

1. 35661:8[LOC]:ASN -- явное разрешение для конкретного пира
2. 35661:9[LOC]:ASN -- deny для конкретного пира
3. 35661:9[LOC]:1 или 35661:9[LOC]:2 -- deny для группы пиров (transit или IX)
4. 35661:9[LOC]:0 -- deny для всех пиров на локации
5. 35661:9999:0 -- глобальный deny (не анонсировать нигде)

Примеры с communities Virtua

Анонсировать везде, кроме Cogent во Франкфурте:

# BIRD2
bgp_large_community.add((35661, 9010, 174));

! FRR
route-map EXPORT permit 10
 set large-community 35661:9010:174 additive

Анонсировать только IX-пирам на всех локациях:

# BIRD2
bgp_large_community.add((35661, 9999, 1));  # deny all transit

! FRR
route-map EXPORT permit 10
 set large-community 35661:9999:1 additive

Prepend 2x для всех пиров в Париже:

# BIRD2
bgp_large_community.add((35661, 2000, 0));

! FRR
route-map EXPORT permit 10
 set large-community 35661:2000:0 additive

Подробнее о настройке BGP с Virtua: BGP Bring Your Own IP on a VPS.

Как проверить BGP communities на маршруте?

Проверка в BIRD2

birdc show route for 203.0.113.0/24 all

Ищите атрибуты BGP.community и BGP.large_community в выводе:

203.0.113.0/24   unicast [upstream1 2026-03-19] * (100) [AS64500i]
    via 198.51.100.1 on eth0
    Type: BGP univ
    BGP.community: (65535,666) (65535,65281)
    BGP.large_community: (35661,0010,174)
    BGP.as_path: 64500

Проверка в FRR

vtysh -c "show ip bgp 203.0.113.0/24"

В выводе будет строка Community::

BGP routing table entry for 203.0.113.0/24
  65535:666 no-export
  Large Community: 35661:0010:174

Проверка внешними инструментами

Изнутри своей сети вы не увидите всё. Используйте внешние looking glasses, чтобы проверить, что видит остальной интернет:

• bgp.tools: найдите свой префикс и проверьте вкладку «Communities». Показывает communities, видимые множеством коллекторов по всему миру.
• RIPE Stat: виджет «BGP Looking Glass» показывает атрибуты communities от коллекторов RIPE RIS.
• NLNOG Looking Glass: запросы с узлов NLNOG RING в разных AS.

Всегда проверяйте снаружи. Community может быть корректно установлен на вашем роутере, но удалён промежуточной сетью.

Как обеспечить безопасность communities?

Communities транзитивны по умолчанию. Любая сеть на пути может их прочитать, добавить или удалить. Это создаёт риски безопасности, если не фильтровать должным образом.

Удаляйте входящие communities в своём пространстве имён ASN

Если пир отправляет маршрут с вашими собственными communities (например, 35661:9999:0), и вы их не удалите, ваши export-фильтры могут их обработать. Это может привести к полному прекращению анонса префикса.

Всегда очищайте своё пространство имён communities на импорте:

# BIRD2 - apply on every EBGP import filter
bgp_community.delete([(35661, *)]);
bgp_large_community.delete([(35661, *, *)]);

! FRR - apply as inbound route-map on every EBGP neighbor
bgp community-list expanded OUR_COMMS permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMS permit 35661:.*:.*

route-map SCRUB-IN permit 10
 set comm-list OUR_COMMS delete
 set large-comm-list OUR_LARGE_COMMS delete

Проверяйте запросы на blackhole

Никогда не выполняйте 65535:666 от любого пира вслепую. Злонамеренный или неправильно настроенный пир может сделать blackhole для ваших клиентских префиксов.

Правила приёма blackhole:

• Принимать blackhole-теги только для префиксов, которые пир авторизован анонсировать
• Проверять валидность RPKI/ROA перед обработкой blackhole (см. RPKI ROA Setup for BGP)
• Ограничить принимаемую длину префикса до /32 (IPv4) и /128 (IPv6) для blackhole
• Всегда добавлять NO_EXPORT к blackhole-маршрутам перед редистрибуцией

# BIRD2 - safe blackhole acceptance
filter import_with_blackhole {
  if (65535, 666) ~ bgp_community then {
    # Only accept /32 for blackhole
    if net.len != 32 then reject;
    dest = RTD_BLACKHOLE;
    bgp_community.add((65535, 65281));  # NO_EXPORT
    accept;
  }
  # ... normal import policy
  accept;
}

Удаляйте communities при экспорте, когда нужно

Перед анонсом маршрутов пирам удалите communities, которые им не следует видеть или обрабатывать:

# BIRD2 - clean export to IX route server
filter export_to_ix {
  # Keep well-known communities, remove internal ones
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, 0, *)]);  # Remove informational
  # Keep action communities the IX needs to see
  accept;
}

Безопасность communities -- часть более широкой стратегии фильтрации маршрутов. См. BGP Route Filtering and Security для полной картины.

Что-то пошло не так?

Communities не появляются на внешних looking glasses. Ваш аплинк может их удалять. Проверьте, находится ли community в пространстве имён, которое он обрабатывает. Некоторые провайдеры удаляют все сторонние communities по умолчанию.

Blackhole не работает. Проверьте длину префикса (требуется /32 или /128). Убедитесь, что аплинк поддерживает RFC 7999. Проверьте, добавляется ли NO_EXPORT -- без него blackhole может распространиться дальше, чем нужно, и быть удалён.

Large communities не распространяются. Старые реализации BGP молча отбрасывают неизвестные атрибуты. Если промежуточная AS использует ПО, выпущенное до поддержки RFC 8092, large communities будут потеряны. Проверьте AS path и определите сеть, которая их отбрасывает.

Ошибки синтаксиса фильтров BIRD2. Community-пары используют скобки, не двоеточия: (35661, 100), а не 35661:100. Large communities -- триплеты: (35661, 100, 200). Двоеточие -- только для отображения и CLI.

community-list в FRR не сопоставляется. Именованные community lists должны указываться в точности как определены. Проверьте на опечатки. Используйте show bgp community-list для проверки содержимого списка.

Communities перезаписываются вместо добавления в FRR. Отсутствует ключевое слово additive в set community или set large-community. Без него все существующие communities заменяются. Всегда используйте additive, если не хотите перезаписать намеренно.

Проверяйте логи при проблемах с BGP-сессиями:

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

Авторское право 2026 Virtua.Cloud. Все права защищены. Данный контент является оригинальным произведением команды Virtua.Cloud. Воспроизведение, повторная публикация или распространение без письменного разрешения запрещены.