BGP_RR_CLUSTER_LOOP Сетевое оборудование и VPN

BGP Error: Route Reflector cluster ID loop detected — Траблшутинг петель

Обновлено: 25.08.2026 · Официальная документация ↗

Маршрутизатор (Route Reflector) получает BGP UPDATE от клиента или другого RR, но префикс не попадает в таблицу BGP (show ip bgp) или помечается как недоступный/отброшенный. При детальном дебаге регистрируется:

%BGP-7-RIB: 192.0.2.0/24 from 10.10.10.2 rejected due to CLUSTER_LIST loop (Cluster ID 10.10.10.1 already in list)
%BGP-7-RIB: 198.51.100.0/24 from 10.10.10.3 rejected due to ORIGINATOR_ID loop (Originator ID matches local Router ID)

Префиксы присутствуют на RR-сервере, но клиенты отражателя не получают обновления.
В выводе show ip bgp <prefix> на соседнем RR префикс отсутствует.
Атрибут Cluster list содержит локальный Cluster ID принимающего маршрутизатора.

1. Анализ механизмов предотвращения петель в Route Reflector (RFC 4456)

Для предотвращения петель внутри iBGP при использовании Route Reflector используются два обязательных non-transitive атрибута:

ORIGINATOR_ID (Type Code 9): Содержит Router ID инициатора маршрута в локальной AS. Если маршрутизатор видит собственный BGP RID в этом поле, маршрут отбрасывается.
CLUSTER_LIST (Type Code 10): Список Cluster ID всех RR, через которые прошел маршрут. Если RR видит свой Cluster ID в списке, обновление отбрасывается.

2. Проверка атрибутов маршрута на стороне RR

# Cisco IOS-XE
show ip bgp 192.0.2.0/24
show ip bgp update-group

# Junos
show route 192.0.2.0/24 detail | match "Cluster|Originator"

# Arista EOS
show ip bgp 192.0.2.0/24 detail

3. Исправление дублирующихся Cluster ID при избыточной схеме (Dual RR)

Если в сети используются два независимых Route Reflector для отказоустойчивости, возможны две схемы:

Схема 1 (Одинаковый Cluster ID): Используется, когда оба RR отражают маршруты одной и той же группе клиентов и соединены между собой. В этом случае они намеренно игнорируют отраженные друг другом маршруты, предотвращая дублирование.
Схема 2 (Разные Cluster ID): Используется, если RR имеют разных клиентов или сложную иерархическую структуру. При ошибке конфигурации разные кластеры получают один ID, что дропает легитимные пути.

Корректировка конфигурации кластера:

# Настройка уникального Cluster ID на Route Reflector
router bgp 65000
 bgp cluster-id 10.255.255.1
 neighbor 10.1.1.10 route-reflector-client
 neighbor 10.1.1.20 route-reflector-client

4. Junos: Настройка кластера Route Reflection

set protocols bgp group RR-CLIENTS type internal
set protocols bgp group RR-CLIENTS cluster 10.255.255.1
set protocols bgp group RR-CLIENTS neighbor 10.1.1.10
set protocols bgp group RR-CLIENTS neighbor 10.1.1.20

💡 Практика специалистов: Если два RR в одном ЦОД используют одинаковый Cluster ID и связаны eBGP-линками через сторонние AS, префиксы не закольцуются, но при падении внутрикластерного iBGP-линка маршрутизаторы откажутся принимать апдейты друг друга из-за защиты Cluster List.

Частые вопросы (FAQ)

Что по умолчанию используется в качестве Cluster ID, если директива 'bgp cluster-id' не задана?

По умолчанию в качестве Cluster ID используется 32-битный BGP Router ID самого Route Reflector.

Может ли клиент Route Reflector изменять атрибут CLUSTER_LIST?

Нет. Клиенты RR не обрабатывают и не модифицируют CLUSTER_LIST и ORIGINATOR_ID. Эти атрибуты создаются и дополняются исключительно самими серверами Route Reflector при отражении апдейтов.

Как обойти проверку ORIGINATOR_ID при миграции смены BGP Router ID?

Проверку ORIGINATOR_ID обойти нельзя, так как это фундаментальный механизм loop prevention. Необходимо перезапустить BGP-сессии (clear ip bgp *) после изменения Router ID для очистки старых записей в RIB.

Передаются ли атрибуты CLUSTER_LIST и ORIGINATOR_ID внешним eBGP соседям?

Нет. Согласно RFC 4456, эти атрибуты являются intra-AS BGP Path Attributes и удаляются перед отправкой UPDATE eBGP-соседям.