Правила работы RR

• Если RR получил маршрут от клиента, он отправляет его всем своим клиентам, не-клиентам-соседям и внешним (EBGP) соседям.

  
• Если RR получил маршрут от не-клиента, он отправляет его всем клиентам и EBGP-соседям. Не-клиентам маршруты НЕ отправляются (потому что они эти маршруты уже получили напрямую от исходного маршрутизатора).

  
• Если RR получил маршрут от EBGP-соседа, он отправляет его всем своим клиентам, не-клиентам-соседям и внешним соседям.

  
• Если клиент получил маршрут от RR, он его может отправить только EBGP-соседу.

Как мы сказали выше, в сети может быть несколько Route-reflector’ов. Это нормально, это не вызовет образование петли, потому что существует атрибут Originator ID — как только RR получит маршрут, где указан он сам, как отправитель этого маршрута, он его отбросит. Каждый RR в таком случае будет иметь таблицу маршрутов BGP точно такую же, как у других. Это вынужденная избыточность, позволяющая значительно увеличить стабильность, но при этом у вас должна быть достаточная производительность самих устройств, чтобы, например, поддерживать по паре Full View на каждом. Но несколько RR могут собираться в кластеры и разрушать деревни обеспечивать экономию ресурсов — таблица BGP будет делиться между несколькими RR. Принадлежность к одному кластеру настраивается на каждом RR и определяется атрибутом Cluster ID.

И вот тут тонкий момент — считается, что Best Practice — это настройка одинакового Cluster-ID на всех RR, но на самом деле это не всегда так. Выбирать нужно, исходя из дизайна вашей сети. Более того, часто рекомендуют даже намеренно разделять Route Reflector’ы — как ни странно, это увеличивает стабильность сети. Дабы не растекаться мысью по древу, просто дам ссылку на материал об этом.

Вот так выглядит обычная схема с RR:

Схема с основным и резервным RR:

Внутри кластера между всему RR должна быть полная связность. Кластеров может быть несколько и между ними также следует создавать Full-Mesh сеть:

Повторимся, что кластер: это Рут-рефлектор (один или несколько) вместе со всеми своими клиентами. Кроме того, часто практикуют иерархические RR. Например, так:

RR1 получает маршруты от удалённой AS и раздаёт их своим дочерним RR (Client/RR1), которые в свою очередь раздают их клиентам. Это имеет смысл только в достаточно крупных сетях.

Относительно Route Reflector'ов важно понимать, что сам маршрутизатор, выполняющий функции RR не обязательно участвует в передаче данных. Более того, часто RR специально выносят за пределы пути передачи трафика, чтобы он выполнял исключительно обязанности по передаче маршрутов, чтобы не увеличивать нагрузку на него.