Route Reflector и confederation

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

Для преодоления проблемы масштабирования iBGP Full Mesh в сетях операторов применяются Route Reflectors (RR, отражатели маршрутов, RFC 4456) или BGP Confederations (RFC 5065). Route Reflector модифицирует классическое правило Split Horizon: маршрутизатор, настроенный как RR, имеет право пересылать (отражать) маршруты, полученные от одного iBGP-клиента, другим iBGP-клиентам и non-client соседям. Маршрутизаторы PE становятся клиентами RR и устанавливают сессии только с парой резервированных RR (RR1 и RR2), что снижает количество сессий с N*(N-1)/2 до 2*N. Для защиты от петель отражения BGP вводит два обязательных атрибута: ORIGINATOR_ID (Router-ID узла, впервые сгенерировавшего маршрут; если узел видит свой ID, маршрут отбрасывается) и CLUSTER_LIST (список идентификаторов кластеров Cluster-ID, через которые прошёл маршрут; если RR видит свой Cluster-ID в списке, маршрут блокируется). В продакшене пара RR настраивается с ОДИНАКОВЫМ Cluster-ID для предотвращения дублирования маршрутов или с РАЗНЫМИ Cluster-ID для независимой сходимости.

Правила отражения (RFC 4456)

Route Reflector смягчает split horizon iBGP. Клиентом называют iBGP-соседа, для которого RR настроен как отражатель; все остальные iBGP-соседи RR считаются non-client. Клиент сам ничего не знает о своей роли: route-reflector-client (Cisco), reflect-client (Huawei) или cluster в группе (Junos) задаются только на RR. Правила распространения лучшего пути:

RR отражает только лучший путь (best path), выбранный по своей таблице. Следствие: клиенты видят не все пути, а ровно то, что выбрал RR, и RR не меняет next hop у отражаемых маршрутов (next-hop-self на RR для клиентов обычно не нужен и по умолчанию не действует на отражаемые маршруты).

ORIGINATOR_ID и CLUSTER_LIST

Два необязательных нетранзитивных атрибута защищают от петель отражения:

• ORIGINATOR_ID (тип 9, 4 байта): router-id маршрутизатора внутри AS, который первым ввёл маршрут в iBGP. Его ставит первый RR при отражении. Если PE получает маршрут со своим ORIGINATOR_ID, он отбрасывает его.
• CLUSTER_LIST (тип 10): последовательность 4-байтных Cluster-ID. Каждый RR при отражении добавляет в начало списка свой Cluster-ID; RR, увидевший свой Cluster-ID в списке, отбрасывает маршрут.

Оба атрибута осмысленны только внутри AS и не уходят в eBGP. При выборе пути (после router-id) вместо router-id сравнивают ORIGINATOR_ID, затем кратчайший CLUSTER_LIST и только потом адрес соседа. Cluster-ID по умолчанию равен router-id RR; запись на Cisco bgp cluster-id 100 и Junos cluster 0.0.0.100 - одно и то же число 100 в десятичной и точечной форме.

Cluster-ID: общий или разный на паре RR

Резервный RR2 строят одним из двух способов:

• Одинаковый Cluster-ID у RR1 и RR2 (оба обслуживают один кластер): маршрут, отражённый RR1, RR2 отбросит при получении от RR1, так как увидит свой Cluster-ID. Это экономит память (на клиенте и RR меньше путей), но каждый клиент обязан иметь сессии с обоими RR. Если клиент подключён только к RR1 и RR1 упал, клиент изолирован.
• Разные Cluster-ID (RR1 и RR2 друг для друга клиенты или non-client внутри mesh верхнего уровня): каждый клиент получает пути от обоих RR, а сходимость при отказе одного RR быстрее и независима. Цена: вдвое больше путей и больше памяти на RR и PE.

Сессий при двух RR и N клиентах: 2*N плюс сессия между RR, против N*(N-1)/2 в full mesh (100 PE: 201 против 4950).

Дизайн: где ставить RR

RR работает в плоскости управления и не обязан стоять на пути трафика (out-of-path): поэтому его можно сделать выделенным виртуальным или отдельным маршрутизатором и не нагружать пересылкой. Достаточно иметь IGP и LDP-достижимость между RR и PE, чтобы next hop клиентов разрешались. Для крупных сетей строят иерархию: региональные RR являются клиентами центральных RR. Ограничения RR: он видит топологию с точки зрения своего IGP, поэтому выбирает best path по метрике до next hop от RR, а не от клиента (проблема hot potato), что может приводить к неоптимальным выходам. Решения: размещать RR в каждой зоне, Optimal Route Reflection (RFC 9107), BGP add-path (RFC 7911) для передачи нескольких путей и best-external на PE. Для VPN (VPNv4) RR дополнительно не импортирует VRF и хранит все маршруты без фильтрации RT, если не включён RT-constrained distribution.

Confederation (RFC 5065)

Альтернатива RR: AS делят на sub-AS (приватные номера 65001, 65002), внутри каждой sub-AS нужен full mesh или RR, а между sub-AS работает "почти eBGP". Внешний мир видит один confederation identifier 65000. Что меняется:

• В AS_PATH появляются сегменты AS_CONFED_SEQUENCE (тип 3) и AS_CONFED_SET (тип 4). Они не учитываются при сравнении длины AS_PATH (на Cisco включается bgp bestpath as-path confed) и удаляются при выходе из confederation.
• Между sub-AS сохраняются NEXT_HOP, LOCAL_PREF и MED, как в iBGP, поэтому политика остаётся единой для всей AS.
• Петли ловятся по AS_CONFED_SEQUENCE: если собственная sub-AS уже есть в пути, маршрут отбрасывается.
• Сессия между sub-AS - eBGP с TTL 1: при peering на loopback нужен ebgp-multihop 2 (Huawei ebgp-max-hop, Junos multihop ttl).

Ошибка в bgp confederation peers или в identifier приводит к сессии, которая выглядит как eBGP другой AS, а не как внутренняя часть confederation.

Сравнение RR и confederation

Оба механизма можно сочетать: внутри sub-AS поставить RR (как в конфигурации урока).