# Выбор 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, которым она уведомляет всех о своей доступности.\
\&#xNAN;*Есть и другие типы сообщений в PIM, но это уже детали*

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

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

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

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://linkmeup.gitbook.io/sdsm/9.-multicast/2.-pim/5.-vibor-rp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.