> 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/1.-praktika/0.-problema-rezervirovaniya.md).

# Проблема резервирования

Какая сейчас с рут-рефлектором есть проблема? У всех маршрутизаторов связи установлены только с ним. И если R1 вдруг выйдет из строя, пиши пропало — сеть ляжет.\
Для этих целей, давайте настроим кластер и в качестве второго RR выберем R2.\
То есть теперь на R3 и R4 нужно поднимать соседства не только с R1, но и с R2.

Теперь sh ip bgp update-group выглядит так:

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

Один внешний, один внутренний — не RR-клиент и два внутренних RR-клиента.\
Аналогично на R2:

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

На клиентах у нас теперь два соединения с RR:

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

Обратите внимание, в сообщениях Update теперь появились два новых атрибута: Cluster-List и Originator-ID. Исходя из названия, они несут в себе номер RR-кластера и идентификатор отправителя анонса:

R1<->R2\
[![](http://img-fotki.yandex.ru/get/9263/83739833.2f/0_c70c1_6fbf2b26_XXXL.png)](http://fotki.yandex.ru/users/ait-it/view/815297/)

Эти параметры добавляются только маршрутам, передающимся по IBGP.

Они необходимо для того, чтобы избежать образования петель. Если, например, маршрут прошёл несколько кластеров и вернулся в исходный, то в параметре Cluster-List среди всех прочих, маршрутизатор увидит номер своего кластера, и после этого удалит маршрут.

![](http://img-fotki.yandex.ru/get/9107/83739833.30/0_c756a_1f83ff6b_XXL.png)

> Попробуйте ответить на вопрос, зачем нужен атрибут Originator-ID? Разве Cluster-List не исчерпывает все варианты?

Если сейчас даже сжечь R1, то связь частично ляжет только на время обнаружения проблемы и перестроения таблиц маршрутизации (в худшем случае это 3 минуты ожидания Keepalive сообщения BGP и ещё какое-то время на изучение новых маршрутов).\
Но, если дизайн сети предполагал, что RR — это самостоятельные железки, и через них не ходил трафик (то есть они занимались исключительно распространением маршрутов), то, вполне вероятно, что перерыва трафика не будет вовсе. Во-первых, отправитель только через 3 минуты заметит, что что-то не так с RR — в течение этого времени маршрут у него всё-равно будет, а поскольку он ведёт не через бесславно погибший RR, трафик будет ходить вполне благополучно. По прошествии этих трёх минут отправитель переключится на резервный RR и получит от него новый актуальный маршрут. Таким образом связь не будет прервана.

Суть иерархических рут-рефлекторов лишь в том, что один из них является клиентом другого. Это помогает выстроить более понятную и прозрачную схему работы, которую будет проще траблшутить далее.\
На нашей сети это лишено какого бы то ни было смысла, поэтому данный случай рассматривать не будем.