> 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/9.-multicast/2.-pim/5.-vibor-rp.md).

# Выбор RP

Выше мы для простоты задавали RP вручную командой **ip pim rp-address** ***X.X.X.X***.\
И вот как выглядела команда **show ip pim rp**:

![show ip pim rp](http://img-fotki.yandex.ru/get/9806/83739833.38/0_da339_f2fdf5d0_XL.png)

Но представим совершенно невозможную в современных сетях ситуацию — R2 вышел из строя. Это всё — финиш. *Клиент 2* ещё будет работать, поскольку произошёл SPT Switchover, а вот всё новое и всё, что шло через RP сломается, даже если есть альтернативный путь.\
Ну и нагрузка на администратора домена. Представьте себе: на 50 маршрутизаторах перебить вручную как минимум одну команду (а для разных групп ведь могут быть разные RP).

Динамический выбор RP позволяет и избежать ручной работы и обеспечить надёжность — если одна RP станет недоступна, в бой вступит сразу же другая.

В данный момент существует один общепризнанный протокол, позволяющий это сделать — **Bootstrap**. Циска в прежние времена продвигала несколько неуклюжий [Auto-RP](http://lookmeup.linkmeup.ru/#term306), но сейчас он почти не используется, хотя циска этого не признаёт, и в **show ip mroute** мы имеем раздражающий рудимент в виде группы 224.0.1.40.

> Надо на самом деле отдать должное протоколу Auto-RP. Он был спасением в прежние времена. Но с появлением открытого и гибкого Bootstrap, он закономерно уступил свои позиции.

Итак, предположим, что в нашей сети мы хотим, чтобы R3 подхватывал функции RP в случае выхода из строя R2.\
R2 и R3 определяются как кандидаты на роль RP — так они и называются **C-RP**. На этих маршрутизаторах настраиваем:

```
RX(config)interface Loopback 0
RX(config-if)ip pim sparse-mode
RX(config-if)exit
RX(config)#ip pim rp-candidate loopback 0
```

Но пока ничего не происходит — кандидаты пока не знают, как уведомить всех о себе.

Чтобы информировать все мультикастовые маршрутизаторы домена о существующих RP вводится механизм **BSR — BootStrap Router**. Претендентов может быть несколько, как и C-RP. Они называются соответственно **C-BSR**. Настраиваются они похожим образом.

Пусть BSR у нас будет один и для теста (исключительно) это будет R1.

```
R1(config)interface Loopback 0
R1(config-if)ip pim sparse-mode
R1(config-if)exit
R1(config)#ip pim bsr-candidate loopback 0
```

Сначала из всех C-BSR выбирается один главный BSR, который и будет всем заправлять. Для этого каждый C-BSR отправляет в сеть мультикастовый **BootStrap Message (BSM)** на адрес 224.0.0.13 — это тоже пакет протокола PIM. Его должны принять и обработать все мультикастовые маршрутизаторы и после разослать во все порты, где активирован PIM. BSM передаётся не в сторону чего-то (RP или источника), в отличии, от PIM Join, а во все стороны. Такая веерная рассылка помогает достигнуть BSM всех уголков сети, в том числе всех C-BSR и всех C-RP. Для того, чтобы BSM не блуждали по сети бесконечно, применяется всё тот же механизм RPF — если BSM пришёл не с того интерфейса, за которым находится сеть отправителя этого сообщения, такое сообщение отбрасывается.

![Bootstrap](http://img-fotki.yandex.ru/get/9763/83739833.38/0_da33a_5ce7b684_XXL.png)

С помощью этих BSM все мультикастовые маршрутизаторы определяют самого достойного кандидата на основе приоритетов. Как только C-BSR получает BSM от другого маршрутизатора с бОльшим приоритетом, он прекращает рассылать свои сообщения. В результате все обладают одинаковой информацией.

![show ip pim bsr-router](http://img-fotki.yandex.ru/get/9820/83739833.38/0_da33b_943c21dc_XL.png)

На этом этапе, когда выбран BSR, благодаря тому, что его BSM разошлись уже по всей сети, C-RP знают его адрес и юникастом отправляют на него сообщения **Candidte-RP-Advertisement**, в которых они несут список групп, которые они обслуживают — это называется **group-to-RP mapping**. BSR все эти сообщения агрегирует и создаёт **RP-Set** — информационную таблицу: какие RP каждую группу обслуживают.

![Candidate-RP-Adverisement](http://img-fotki.yandex.ru/get/9753/83739833.38/0_da33c_cbc248cb_XXL.png)

Далее BSR в прежней веерной манере рассылает те же BootStrap Message, которые на этот раз содержат RP-Set. Эти сообщения успешно достигают всех мультикастовых маршрутизаторов, каждый из которых **самостоятельно** делает выбор, какую RP нужно использовать для каждой конкретной группы.

![BSR](http://img-fotki.yandex.ru/get/9497/83739833.38/0_da33d_b62a5449_XXL.png)

BSR периодически делает такие рассылки, чтобы с одной стороны все знали, что информация по RP ещё актуальна, а с другой C-BSR были в курсе, что сам главный BSR ещё жив.\
RP, кстати, тоже периодически шлют на BSR свои анонсы Candidate-RP-Advertisement.

Фактически всё, что нужно сделать для настройки автоматического выбора RP — указать C-RP и указать C-BSR — не так уж много работы, всё остальное за вас сделает PIM.\
Как всегда, в целях повышения надёжности рекомендуется указывать интерфейсы Loopback в качестве кандидатов.

**Завершая главу PIM SM, давайте ещё раз отметим важнейшие моменты**

1. Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
2. Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента — нет дерева.
3. RPF помогает избежать петель.
4. Все маршрутизаторы должны знать о том, кто является RP — только с её помощью можно построить дерево.
5. Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
6. В первой фазе строится RPT — дерево от клиентов до RP — и Source Tree — дерево от источника до RP. Во второй фазе происходит переключение с построенного RPT на SPT — кратчайший путь от получателя до источника.

Ещё перечислим все типы деревьев и сообщений, которые нам теперь известны.

**MDT — Multicast Distribution Tree**. Общий термин, описывающий любое дерево передачи мультикаста.\
**SPT — Shortest Path Tree**. Дерево с кратчайшим путём от клиента или RP до источника. В PIM DM есть только SPT. В PIM SM SPT может быть от источника до RP или от источника до получателя после того, как произошёл SPT Switchover. Обозначается записью **(S, G)** — известен источник для группы.\
**Source Tree** — то же самое, что SPT.\
**RPT — Rendezvous Point Tree**. Дерево от RP до получателей. Используется только в PIM SM. Обозначается записью **(\*, G)**.\
**Shared Tree** — то же, что RPT. Называется так потому, что все клиенты подключены к одному общему дереву с корнем в RP.

Типы сообщений PIM Sparse Mode:\
**Hello** — для установления соседства и поддержания этих отношений. Также необходимы для выбора DR.\
**Join (\*, G)** — запрос на подключение к дереву группы G. Не важно кто источник. Отправляется в сторону RP. С их помощью строится дерево RPT.\
**Join (S, G)** — Source Specific Join. Это запрос на подключение к дереву группы G с определённым источником — S. Отправляется в сторону источника — S. С их помощью строится дерево SPT.\
**Prune (\*, G)** — запрос на отключение от дерева группы G, какие бы источники для неё не были. Отправляется в сторону RP. Так обрезается ветвь RPT.\
**Prune (S, G)** — запрос на отключение от дерева группы G, корнем которого является источник S. Отправляется в сторону источника. Так обрезается ветвь SPT.\
**Register** — специальное сообщение, внутри которого передаётся мультикаст на RP, пока не будет построено SPT от источника до RP. Передаётся юникастом от FHR на RP.\
**Register-Stop** — отправляется юникастом с RP на FHR, приказывая прекратить посылать мультикастовый трафик, инкапсулированный в Register.\
**Bootstrap** — пакеты механизма BSR, которые позволяют выбрать маршрутизатор на роль BSR, а также передают информацию о существующих RP и группах.\
**Assert** — сообщение для выбора PIM Forwarder, чтобы в один сегмент не передавали трафик два маршрутизатора.\
**Candidate-RP-Advertisement** — сообщение, в котором RP отсылает на BSR информацию о том, какие группы он обслуживает.\
**RP-Reachable** — сообщение от RP, которым она уведомляет всех о своей доступности.\
*Есть и другие типы сообщений в PIM, но это уже детали*

А давайте теперь попытаемся абстрагироваться от деталей протокола? И тогда становится очевидной его сложность.

1\) Определение RP,\
2\) Регистрация источника на RP,\
3\) Переключение на дерево SPT.

Много состояний протокола, много записей в таблице мультикастовой маршрутизации. Можно ли что-то с этим сделать?

На сегодняшний день существует два диаметрально противоположных подхода к упрощению PIM: SSM и BIDIR PIM.