Выбор RP
Last updated
Last updated
Выше мы для простоты задавали RP вручную командой ip pim rp-address X.X.X.X. И вот как выглядела команда show ip pim rp:
Но представим совершенно невозможную в современных сетях ситуацию — R2 вышел из строя. Это всё — финиш. Клиент 2 ещё будет работать, поскольку произошёл SPT Switchover, а вот всё новое и всё, что шло через RP сломается, даже если есть альтернативный путь. Ну и нагрузка на администратора домена. Представьте себе: на 50 маршрутизаторах перебить вручную как минимум одну команду (а для разных групп ведь могут быть разные RP).
Динамический выбор RP позволяет и избежать ручной работы и обеспечить надёжность — если одна RP станет недоступна, в бой вступит сразу же другая.
В данный момент существует один общепризнанный протокол, позволяющий это сделать — Bootstrap. Циска в прежние времена продвигала несколько неуклюжий Auto-RP, но сейчас он почти не используется, хотя циска этого не признаёт, и в show ip mroute мы имеем раздражающий рудимент в виде группы 224.0.1.40.
Надо на самом деле отдать должное протоколу Auto-RP. Он был спасением в прежние времена. Но с появлением открытого и гибкого Bootstrap, он закономерно уступил свои позиции.
Итак, предположим, что в нашей сети мы хотим, чтобы R3 подхватывал функции RP в случае выхода из строя R2. R2 и R3 определяются как кандидаты на роль RP — так они и называются C-RP. На этих маршрутизаторах настраиваем:
Но пока ничего не происходит — кандидаты пока не знают, как уведомить всех о себе.
Чтобы информировать все мультикастовые маршрутизаторы домена о существующих RP вводится механизм BSR — BootStrap Router. Претендентов может быть несколько, как и C-RP. Они называются соответственно C-BSR. Настраиваются они похожим образом.
Пусть BSR у нас будет один и для теста (исключительно) это будет R1.
Сначала из всех 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 пришёл не с того интерфейса, за которым находится сеть отправителя этого сообщения, такое сообщение отбрасывается.
С помощью этих BSM все мультикастовые маршрутизаторы определяют самого достойного кандидата на основе приоритетов. Как только C-BSR получает BSM от другого маршрутизатора с бОльшим приоритетом, он прекращает рассылать свои сообщения. В результате все обладают одинаковой информацией.
На этом этапе, когда выбран BSR, благодаря тому, что его BSM разошлись уже по всей сети, C-RP знают его адрес и юникастом отправляют на него сообщения Candidte-RP-Advertisement, в которых они несут список групп, которые они обслуживают — это называется group-to-RP mapping. BSR все эти сообщения агрегирует и создаёт RP-Set — информационную таблицу: какие RP каждую группу обслуживают.
Далее BSR в прежней веерной манере рассылает те же BootStrap Message, которые на этот раз содержат RP-Set. Эти сообщения успешно достигают всех мультикастовых маршрутизаторов, каждый из которых самостоятельно делает выбор, какую RP нужно использовать для каждой конкретной группы.
BSR периодически делает такие рассылки, чтобы с одной стороны все знали, что информация по RP ещё актуальна, а с другой C-BSR были в курсе, что сам главный BSR ещё жив. RP, кстати, тоже периодически шлют на BSR свои анонсы Candidate-RP-Advertisement.
Фактически всё, что нужно сделать для настройки автоматического выбора RP — указать C-RP и указать C-BSR — не так уж много работы, всё остальное за вас сделает PIM. Как всегда, в целях повышения надёжности рекомендуется указывать интерфейсы Loopback в качестве кандидатов.
Завершая главу PIM SM, давайте ещё раз отметим важнейшие моменты
Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента — нет дерева.
RPF помогает избежать петель.
Все маршрутизаторы должны знать о том, кто является RP — только с её помощью можно построить дерево.
Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
В первой фазе строится 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.
