> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/8.1.-ibgp/2.-problema-n-kvadrat/0.-route-reflector/0.-pravila-raboti-rr.md).

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

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

  <img src="http://habrastorage.org/storage3/d8e/ef1/72e/d8eef172ea5a66f7c7336659fd36c90c.gif" alt="" data-size="original">
* Если RR получил маршрут от не-клиента, он отправляет его всем клиентам и EBGP-соседям. Не-клиентам маршруты НЕ отправляются (потому что они эти маршруты уже получили напрямую от исходного маршрутизатора).

  <img src="http://habrastorage.org/storage3/935/7b0/709/9357b070908dee13d1ee17aeb37541d8.gif" alt="" data-size="original">
* Если RR получил маршрут от EBGP-соседа, он отправляет его всем своим клиентам, не-клиентам-соседям и внешним соседям.

  <img src="http://habrastorage.org/storage3/849/16c/5de/84916c5de42918394c999fdea5aad280.gif" alt="" data-size="original">
* Если клиент получил маршрут от RR, он его может отправить только EBGP-соседу.

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

> И вот тут тонкий момент — считается, что Best Practice — это настройка одинакового Cluster-ID на всех RR, но на самом деле это не всегда так. Выбирать нужно, исходя из дизайна вашей сети. Более того, часто рекомендуют даже намеренно разделять Route Reflector’ы — как ни странно, это увеличивает стабильность сети.\
> Дабы не растекаться мысью по древу, просто [дам ссылку](http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-and-cluster-id/) на материал об этом.

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

![](http://img-fotki.yandex.ru/get/9112/83739833.2f/0_c7087_53b1a2bd_XL.png)

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

![](http://img-fotki.yandex.ru/get/9110/83739833.2f/0_c7088_2e99d4d4_XL.png)

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

![](http://img-fotki.yandex.ru/get/9169/83739833.2f/0_c7089_aae089f8_XL.png)

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

![](http://img-fotki.yandex.ru/get/9104/83739833.2f/0_c708a_5c5cb964_XL.png)

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

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