Протокол PIM — это набор протоколов для передачи мультикаста в сети между маршрутизаторами. Отношения соседства строится аналогично как и в случае динамических протоколов маршрутизации. PIMv2 отправляет каждые 30 секунд Hello сообщения на зарезервированный мультикаст адрес 224.0.0.13 ( All-PIM-Routers ). Сообщение содержит в себе Hold Timers — обычно равен 3.5*Hello Timer, то есть 105 секунд по умолчанию.
PIM использует два основных режима работы — Dense и Sparse mode. Начнем c Dense mode.
Source-Based Distribution Trees.
Dense-mode режим целесообразно использовать в случае большого количества клиентов различных мультикаст групп. Когда маршрутизатор получает мулькаст трафик, то первым делом он проверяет его на правило RPF. RPF — данное правило используется для проверки источника мультикаста с юникастовой таблицей маршрутизации. Необходимо, чтоб трафик приходил на тот интерфейс, за которым скрывается данный хост по версии юникастовой таблицы маршрутизации. Этот механизм решает проблему возникновения петли при передаче мультикаста.
R3 из мультикаст сообщения узнает источник мультикаста ( Source IP ) и проверит два потока от R1 и R2 по своей юникастовой таблице. Поток с того интерфейса, на который указывает таблица ( R1 к R3 ), будет передан дальше, а поток от R2 будет дропнут, так как, чтоб добраться до источника мультикаста, надо отправлять пакеты по S0/1.
Вопрос, что будет если у вас два эквивалентных маршрута с одинаковой метрикой? В этом случае маршрутизатор будет выбирать по next-hop у данных маршрутов. У кого выше ip адрес, тот и победил. Если необходимо изменить данное поведение, то можно использовать ECMP. Подробнее тут.
После проверки правила RPF, маршрутизатор отправляет мультикаст пакет всем своим PIM соседям, за исключением того, от кого был получен данный пакет. Остальные PIM маршрутизаторы повторяют данный процесс. Путь, который прошел мультикаст пакет от источника до конечных получателей, образует дерево, которое называется — source-based distribution tree, shortest-path tree (SPT), source tree. Три разных названия, выбирайте любое.
Как решить вопрос с тем, что некоторым маршрутизаторам не сдался какой-то мультикастовый поток и отправлять его некому, а ему вышестоящий маршрутизатор шлет. Для это придуман Prune механизм.
Prune Message.
Например, R2 будет продолжать слать R3 мультикаст, хотя R3 по правилу RPF дропает его. Зачем нагружать канал? R3 шлет PIM Prune Message и R2, при получении данного сообщения, удалит интерфейс S0/1 из списка ( outgoing interface list ) для данного потока, список интерфейсов, с которых надо посылать данный трафик.
После получения Prune сообщения, R2 выставляет Prune таймер в 3 минуты. Через три минуты он начнет отправлять трафик опять, пока не получит очередное Prune сообщение. Это в PIMv1.
А в PIMv2 добавлен State Refresh таймер ( по умолчанию 60 секунд ). Как только было отправлено Prune сообщение с R3, запускается данный таймер на R3. По истечении данного таймера, R3 будет отправлять State Refresh сообщение, которое будет сбрасывать 3-ех минутный Prune Timer на R2 для данной группы.
Причины отправки сообщения Prune:
Graft Message.
Представим, что R3 не захотел трафик от R2, отправил Prune и получал мультикаст от R1. Но вдруг, упал канал между R1-R3 и R3 остался без мультикаста. Можно ждать 3 минуты, пока на R2 не истечет Prune Timer. 3 минуты ждать долго, чтоб не ждать, необходимо послать сообщение, которое моментально выведет данный интерфейс S0/1 на R2 из pruned состояния. Таким сообщением будет Graft сообщение. После получения Graft сообщения, R2 отправит в ответ Graft-ACK.
Prune Override.
Посмотрим на данную схему. R1 вещает мультикаст в сегмент с двумя маршрутизаторами. R3 получает и вещает трафик, R2 получает, но вещать трафик ему некому. Он отправляет Prune сообщение к R1 в данный сегмент. R1 должен удалить Fa0/0 из списка и перестать вещать в данный сегмент, но что будет c R3? А R3 находится в том же сегменте, тоже получил данное Prune сообщение и понял всю трагичность ситуации. Перед тем как R1 перестанет вещать, он устанавливает таймер в 3 секунды и перестанет вещать через 3 секунды. 3 секунды — именно столько времени у R3, чтоб не потерять свой мультикаст. Поэтому R3, как можно скорее, отправляет Pim Join сообщение для данной группы и R1 уже не думает переставать вещать. О Join сообщениях ниже.
Assert Message.
Представим такую ситуацию: в одну сеть вещают сразу два маршрутизатора. Получают один и тот же поток от источника, и оба вещают его в одну сеть за интерфейсом e0. Поэтому им надо определить кто же будет одним единственным вещателем для данной сети. Для этого используются сообщения Assert. Когда R2 и R3 детектируют дупликацию мультикаст трафика, то есть на R2 и R3 приходит мультикаст, который они сами вещают, маршрутизаторы понимают, что тут что-то не так. Маршрутизаторы отправляют в этом случае Assert сообщения, в которые включены Administrative Distance и метрика маршрута при помощи которого достигается источник мультикаста — 10.1.1.10. Победитель определяется так:
Победивший в этом голосовании, маршрутизатор становится Designated Router-ом. Для выбора DR также используются Pim Hello. В начале статьи было показано PIM Hello сообщение, там можно заметить DR поле. Побеждает тот, у кого выше IP адреса на этом линке.
Полезная табличка:
MROUTE Table.
После первоначального рассмотрения работы протокола PIM, нам необходимо разобраться с тем, как работать с мультикастовой таблицей маршрутизации. В таблице mroute храниться информация о том, какие потоки были запрошены со стороны клиентов и какие потоки льются с мультикаст серверов.
Например, при получения IGMP Membership Report или PIM Join на каком-то интерфейсе, в таблицу маршрутизации добавляется запись типа ( *, G ):
Данная запись означает, что был получен запрос на трафик с адресом 238.38.38.38. Флаг DC означает, что мультикаст будет работать в режиме Dense mode и С означает, что получатель непосредственно подключен к маршрутизатору, то есть маршрутизатор получил IGMP Membership Report, а PIM Join.
Если есть запись типа (S,G) означает, что у нас есть мультикаст поток:
В поле S — 192.168.1.11, у нас прописан IP адрес источника мультикаста, именно он будет проверяться правилом RPF. При проблемах, первым делом необходимо проверить юникастовую таблицу на маршрут к источнику. В поле Incoming Interface указывает интерфейс, на который поступает мультикаст. В юникастовой таблице маршрутизации, маршрут до источника должен ссылаться на интерфейс, указанный здесь. В Outgoing Interface указывается куда будет мультикаст перенаправлен. Если он пуст, значит к маршрутизатору не поступало запросов на данный трафик. Более подробную информацию о всех флагах можно найти здесь.
PIM Sparse-mode.
Стратегия Sparse-mode противоположна Dense-mode. Когда Sparse-mode получает мультикаст трафик, он будет отправлять трафик только через те интерфейсы, где были запросы на данный поток, например Pim Join или IGMP Report сообщения с запросом на данный трафик.
Cхожие элементы у SM и DM:
Для контроля того, кому, где и какой мультикаст трафик нужен в сети, необходимо общий информационный центр. Таким центром у нас будет Rendezvous Point ( RP ). Все, кто хочет какой-то мультикаст трафик или кто-то начал получать мультикаст трафик от источника, то он отправляет его на RP.
Когда RP получит мультикаст трафик, то отправит его тем маршрутизаторам, которые запросили до этого этот трафик.
Представим такую топологию, где RP это R3. Как только R1 получит трафик от S1, то он инкапсулирует данный мультикаст пакет в юникастовое PIM Register сообщение и отправит его на RP. Откуда он знает кто RP? В данном случае, он настроен статически, а о динамической настройке RP поговорим позже.
RP посмотрит — а была ли информация от кого-то, кто хотел бы получать этот трафик? Предположим, что не было. Тогда RP отправит R1 сообщение PIM Register-Stop, что означает — никому не нужен этот мультикаст, в регистрации отказано. R1 не будет посылать мультикаст. Но хост-источник мультикаста будет слать его, так что R1 после получения Register-Stop, запустит таймер Register-Suppression timer, равный 60 секундам. За 5 секунд до истечения данного таймера, R1 будет посылать пустое Register сообщение с Null-Register bit ( то есть без инкапсулированного мультикаст пакета) в сторону RP. RP в свою очередь будет действовать так:
Как мультикаст доходит до RP вроде бы разобрались, теперь попытаемся ответить на вопрос как RP доводит трафик до получателей. Здесь необходимо ввести новое понятие — root-path tree (RPT). RPT — это дерево с корнем в RP, растущее в сторону получателей, разветвляющиеся на каждом PIM-SM маршрутизаторе. RP создает его, получая PIM Join сообщения и добавляет в дерево новую ветвь. И так, делает каждый нижестоящий маршрутизатор. Общее правило выглядит так:
Представим, что у нас появился клиент мультикаста на маршрутизаторе R5 на группу 228.8.8.8. Как только R5 получит IGMP Membership Report от хоста, R5 отправляет PIM Join в направлении RP, а сам добавляет в дерево интерфейс, смотрящий на хост. Далее, R4 получает PIM Join от R5, добавляет в дерево интерфейс Gi0/1 и отправляет PIM Join в направлении RP. Наконец то, RP ( R3 ) получает PIM Join и добавляет Gi0/0 в дерево. Таким образом, получается регистрация получателя мультикаста. У нас строится дерево с корнем R3-Gi0/0 > R4-Gi0/1 > R5-Gi0/0.
После этого, будет отправлен PIM Join к R1 и R1 начнет слать мультикаст трафик. Важно заметить, что если хост запросил трафик до того, как началось вещание мультикаста, то RP не будет отправлять PIM Join и вообще не будет ничего отправлять в строну R1.
Если вдруг пока отправляется мультикаст, хост перестанет хотеть его получать, как только RP получит PIM Prune на интерфейс Gi0/0, то сразу отправит PIM Register-Stop непосредственно на R1, а затем и PIM Prune сообщение через интерфейс Gi0/1. PIM Register-stop отправляется юникастом на тот адрес, с которого поступило PIM Register.
Как мы говорили раньше, как только маршрутизатор отправляет PIM Join другому, например R5 на R4, то на R4 добавляется запись:
И запускается таймер, что сбросить данный таймер R5 должен постоянно PIM Join сообщения постоянно, а то R4 исключит из outgoing list. R5 будет отправлять каждые 60 PIM Join сообщения.
Shortest-Path Tree Switchover.
Мы добавим интерфейс между R1 и R5, посмотрим как будет литься трафик при такой топологии.
Допустим, что трафик отправлялся и получался по старой схеме R1-R2-R3-R4-R5 и тут мы подключили и настроили интерфейс между R1 и R5.
Первым делом, у нас перестроиться юникастовая таблица маршрутизации на R5 и теперь сеть 192.168.1.0/24 достигается через интерфейс R5 Gi0/2. Теперь R5 получая мультикаст на интерфейсе Gi0/1, понимает, что правило RPF не удовлетворяется и мультикаст логичнее бы получать на Gi0/2. Он должен отключиться от RPT и построить более короткое дерево, которое называется Shortest-Path Tree ( SPT ). Для этого он через Gi0/2 отправляет PIM Join на R1 и R1 начинает слать мультикаст еще и через Gi0/2. Теперь R5 надо отписаться от RPT, чтоб не получать две копии. Для этого он отправляет Prune сообщение указывая ip адрес источника и вставляя специальный бит — RPT-bit. Это значит, что не надо мне посылать трафик, у меня здесь дерево получше. RP также отправляет в сторону R1 PIM Prune сообщения, но не отправляет Register-Stop сообщение. Еще одна особенность: R5 теперь будет постоянно отправлять PIM Prune на RP, так как R1 продолжает отправлять PIM Register на RP каждую минуту. RP пока не будет новых желающих данного трафика будет отвечать ему отказом. R5 уведомляет RP, что он продолжает получать мультикаст через SPT.
Динамический поиск RP.
Auto-RP.
Данная технология является проприетарной от Cisco и не пользуется особой популярной, но все еще жива. Работа Auto-RP состоит из двух основных этапов:
1) RP шлет RP-Announce сообщения на зарезервированный адрес — 224.0.1.39, объявляя себя RP либо для всех либо для определенных групп. Отправляется данное сообщение каждую минуту.
2) Необходим RP mapping agent, который будет слать RP-Discovery сообщения с указанием для каких групп какой RP необходимо слушать. Именно из этого сообщения, обычные PIM маршрутизаторы будут определять для себя RP. Mapping Agent может быть как сам RP маршрутизатор, так и какой-либо отдельный PIM маршрутизатор. RP-Discovery отправляется на адрес 224.0.1.40 c таймером в одну минуту.
Посмотрим на процесс поподробнее:
Настроим R3 как RP:
R2 как mapping agent:
А на всех остальных будем ожидать RP через Auto-RP:
Как только мы настроим R3, он начнет отправлять RP-Announce:
А R2 после настройки mapping agent-ом, начнет ждать сообщения RP-Announce. Только когда он найдет хотя бы один RP, то начнет отправлять RP-Discovery:
Таким образом, как только обычные маршрутизаторы ( PIM RP Listener ) получат данное сообщения, они будут знать где искать RP.
Одна из основных проблем Auto-RP заключается в том, что чтобы получать сообщения RP-Announce и RP-Discovery необходимо отправлять PIM Join на адреса 224.0.1.39-40, а для того, чтобы отправить, надо знать где находится RP. Классическая проблема курицы и яйца. Для решение это проблемы, был придуман режим PIM Sparse-Dense-Mode. Если маршрутизатор не знает RP, то он работает в режиме Dense-mode, если знает, то в режиме Sparse-mode. Когда на интерфейсах обычных маршрутизаторов настроен PIM Sparse-mode и команда ip pim autorp listener, то маршрутизатор будет работать в режиме Dense-mode только для мультикаста непосредственно Auto-RP протокола ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Данный функция работает похоже на Auto-RP. Каждый RP шлет сообщение mapping agent-у, который собирает маппинг информацию и далее рассказывает всем остальным маршрутизаторам. Опишем процесс аналогично Auto-RP:
1) Как только мы настроим R3 в качестве кандидата быть RP, командой:
То R3 ничего делать не будет, для того, чтобы начать слать специальные сообщение, ему, для начала, надо найти mapping agent-а. Таким образом, переходим ко второму шагу.
2) Настраиваем R2 как mapping agent:
R2 начинает рассылать PIM Bootstrap сообщения, где указывает себя в качестве mapping agent-а:
Отправляется данное сообщение на адрес 224.0.013, которое PIM протокол использует и для других своих сообщений. Он отправляет их во все стороны и поэтому нет проблемы курицы и яйца, как было в Auto-RP.
3) Как только RP получит сообщение от BSR маршрутизатора, он сразу отправит юникастовое сообщение на адрес BSR маршрутизатора:
После чего, BSR получив информацию о RP, разошлет их мультикастом на адрес 224.0.0.13, который слушают все PIM маршрутизаторы. Поэтому, аналога команды ip pim autorp listener для обычных маршрутизаторов нет в BSR.
Anycast RP with Multicast Source Discovery Protocol (MSDP).
Auto-RP и BSR нам позволяют распредилить нагрузку на RP следующим образом: У каждой мультикаст группы есть только один активный RP. Не получится сделать распределение нагрузки для одной мультикаст группы несколько RP. MSDP делает это при помощи выдачи RP маршрутизаторам одинакового ip адреса с маской 255.255.255.255. MSDP узнает информацию при помощи одного из методов: статики, Auto-RP или BSR.
На картинке у нас Auto-RP конфигурация с MSDP. Оба RP настроены с ip адресом 172.16.1.1/32 на Loopback 1 интерфейсе и используется для всех групп. При RP-Announce оба маршрутизатора рассказывают о себе, ссылаясь на этот адрес. Auto-RP mapping agent, получив информацию, рассылает RP-Discovery об RP c адресом 172.16.1.1/32. Про сеть 172.16.1.1/32, маршрутизаторам мы рассказываем при помощи IGP и, соответственно. Таким образом, PIM маршрутизаторы запрашивают или регистрируют потоки с того RP, к который указан как next-hop у маршрута к сети 172.16.1.1/32. Cам протокол MSDP же призван для самих RP, чтоб обмениваться сообщениями о информации про мультикаст.
Рассмотрим такую топологию:
Switch6 вещает трафик на адрес 238.38.38.38 и о нем пока знает только RP-R1. Вот Switch7 и Switch8 запросили данную группу. Маршрутизаторы R5 и R4 отправят PIM Join на R1 и R3, соответственно. Почему? Маршрут до 13.13.13.13 у R5 будет ссылаться на R1 по метрике IGP, как и у R4.
RP-R1 знает о потоке и начнет вещать его в сторону R5, а вот R4 ничего о нем не знает, так как R1 просто так его отправлять не будет. Поэтому необходим MSDP. Настраиваем его на R1 и R5:
Они поднимут сессию между друг другом и при получении какого-либо потока будут сообщать о нем своему RP соседу.
RP-R1 как только получит поток от Switch6, сразу отправит юникастом MSDP Source-Active сообщение, где будет содержаться информация типа ( S, G) — информация о источнике и назначении мультикаста. Теперь, когда RP-R3 будет знать, что такой источник как Switch6, он при получении запроса от R4 на данный поток, будет слать в сторону Switch6 PIM Join, руководстваясь таблицей маршрутизации. Следовательно, R1 получив такой PIM Join, начнет слать трафик в сторону RP-R3.
MSDP работает по TCP, RP посылают друг другу keepalive сообщения для проверки жизнеспособности. Таймер равен 60 cекундам.
Остается непонятной функция разделения MSDP пиров в различные домены, так как в сообщениях Keepalive и SA не указывается принадлежность какому-либо домену. Также в данной топологии тестировалась конфигурация с указанием различных доменов — разницы в работе не было.
Если кто-то может внести ясность, с радостью почитаю в комментариях.
На этом думаю закончить статью. Внизу полезный материалы и ссылки, которые использовались:
PIM использует два основных режима работы — Dense и Sparse mode. Начнем c Dense mode.
Source-Based Distribution Trees.
Dense-mode режим целесообразно использовать в случае большого количества клиентов различных мультикаст групп. Когда маршрутизатор получает мулькаст трафик, то первым делом он проверяет его на правило RPF. RPF — данное правило используется для проверки источника мультикаста с юникастовой таблицей маршрутизации. Необходимо, чтоб трафик приходил на тот интерфейс, за которым скрывается данный хост по версии юникастовой таблицы маршрутизации. Этот механизм решает проблему возникновения петли при передаче мультикаста.
R3 из мультикаст сообщения узнает источник мультикаста ( Source IP ) и проверит два потока от R1 и R2 по своей юникастовой таблице. Поток с того интерфейса, на который указывает таблица ( R1 к R3 ), будет передан дальше, а поток от R2 будет дропнут, так как, чтоб добраться до источника мультикаста, надо отправлять пакеты по S0/1.
Вопрос, что будет если у вас два эквивалентных маршрута с одинаковой метрикой? В этом случае маршрутизатор будет выбирать по next-hop у данных маршрутов. У кого выше ip адрес, тот и победил. Если необходимо изменить данное поведение, то можно использовать ECMP. Подробнее тут.
После проверки правила RPF, маршрутизатор отправляет мультикаст пакет всем своим PIM соседям, за исключением того, от кого был получен данный пакет. Остальные PIM маршрутизаторы повторяют данный процесс. Путь, который прошел мультикаст пакет от источника до конечных получателей, образует дерево, которое называется — source-based distribution tree, shortest-path tree (SPT), source tree. Три разных названия, выбирайте любое.
Как решить вопрос с тем, что некоторым маршрутизаторам не сдался какой-то мультикастовый поток и отправлять его некому, а ему вышестоящий маршрутизатор шлет. Для это придуман Prune механизм.
Prune Message.
Например, R2 будет продолжать слать R3 мультикаст, хотя R3 по правилу RPF дропает его. Зачем нагружать канал? R3 шлет PIM Prune Message и R2, при получении данного сообщения, удалит интерфейс S0/1 из списка ( outgoing interface list ) для данного потока, список интерфейсов, с которых надо посылать данный трафик.
The following is a more formal definition of a PIM Prune message:
The PIM Prune message is sent by one router to a second router to cause the second router to remove the link on which the Prune is received from a particular (S,G) SPT.
После получения Prune сообщения, R2 выставляет Prune таймер в 3 минуты. Через три минуты он начнет отправлять трафик опять, пока не получит очередное Prune сообщение. Это в PIMv1.
А в PIMv2 добавлен State Refresh таймер ( по умолчанию 60 секунд ). Как только было отправлено Prune сообщение с R3, запускается данный таймер на R3. По истечении данного таймера, R3 будет отправлять State Refresh сообщение, которое будет сбрасывать 3-ех минутный Prune Timer на R2 для данной группы.
Причины отправки сообщения Prune:
- Когда мультикаст пакет не прошел проверку RPF.
- Когда нет локально подключенных клиентов, который запросил мультикастовую группу ( IGMP Join) и нет PIM соседей, которым можно отправлять мультикастовый трафик ( Non-prune Interface).
Graft Message.
Представим, что R3 не захотел трафик от R2, отправил Prune и получал мультикаст от R1. Но вдруг, упал канал между R1-R3 и R3 остался без мультикаста. Можно ждать 3 минуты, пока на R2 не истечет Prune Timer. 3 минуты ждать долго, чтоб не ждать, необходимо послать сообщение, которое моментально выведет данный интерфейс S0/1 на R2 из pruned состояния. Таким сообщением будет Graft сообщение. После получения Graft сообщения, R2 отправит в ответ Graft-ACK.
Prune Override.
Посмотрим на данную схему. R1 вещает мультикаст в сегмент с двумя маршрутизаторами. R3 получает и вещает трафик, R2 получает, но вещать трафик ему некому. Он отправляет Prune сообщение к R1 в данный сегмент. R1 должен удалить Fa0/0 из списка и перестать вещать в данный сегмент, но что будет c R3? А R3 находится в том же сегменте, тоже получил данное Prune сообщение и понял всю трагичность ситуации. Перед тем как R1 перестанет вещать, он устанавливает таймер в 3 секунды и перестанет вещать через 3 секунды. 3 секунды — именно столько времени у R3, чтоб не потерять свой мультикаст. Поэтому R3, как можно скорее, отправляет Pim Join сообщение для данной группы и R1 уже не думает переставать вещать. О Join сообщениях ниже.
Assert Message.
Представим такую ситуацию: в одну сеть вещают сразу два маршрутизатора. Получают один и тот же поток от источника, и оба вещают его в одну сеть за интерфейсом e0. Поэтому им надо определить кто же будет одним единственным вещателем для данной сети. Для этого используются сообщения Assert. Когда R2 и R3 детектируют дупликацию мультикаст трафика, то есть на R2 и R3 приходит мультикаст, который они сами вещают, маршрутизаторы понимают, что тут что-то не так. Маршрутизаторы отправляют в этом случае Assert сообщения, в которые включены Administrative Distance и метрика маршрута при помощи которого достигается источник мультикаста — 10.1.1.10. Победитель определяется так:
- Тот у кого ниже AD.
- Если AD равны, то у кого ниже метрика.
- Если и тут равенство, то тот у кого выше IP в сети, в которую они вещают этот мультикаст.
Победивший в этом голосовании, маршрутизатор становится Designated Router-ом. Для выбора DR также используются Pim Hello. В начале статьи было показано PIM Hello сообщение, там можно заметить DR поле. Побеждает тот, у кого выше IP адреса на этом линке.
Полезная табличка:
MROUTE Table.
После первоначального рассмотрения работы протокола PIM, нам необходимо разобраться с тем, как работать с мультикастовой таблицей маршрутизации. В таблице mroute храниться информация о том, какие потоки были запрошены со стороны клиентов и какие потоки льются с мультикаст серверов.
Например, при получения IGMP Membership Report или PIM Join на каком-то интерфейсе, в таблицу маршрутизации добавляется запись типа ( *, G ):
Данная запись означает, что был получен запрос на трафик с адресом 238.38.38.38. Флаг DC означает, что мультикаст будет работать в режиме Dense mode и С означает, что получатель непосредственно подключен к маршрутизатору, то есть маршрутизатор получил IGMP Membership Report, а PIM Join.
Если есть запись типа (S,G) означает, что у нас есть мультикаст поток:
В поле S — 192.168.1.11, у нас прописан IP адрес источника мультикаста, именно он будет проверяться правилом RPF. При проблемах, первым делом необходимо проверить юникастовую таблицу на маршрут к источнику. В поле Incoming Interface указывает интерфейс, на который поступает мультикаст. В юникастовой таблице маршрутизации, маршрут до источника должен ссылаться на интерфейс, указанный здесь. В Outgoing Interface указывается куда будет мультикаст перенаправлен. Если он пуст, значит к маршрутизатору не поступало запросов на данный трафик. Более подробную информацию о всех флагах можно найти здесь.
PIM Sparse-mode.
Стратегия Sparse-mode противоположна Dense-mode. Когда Sparse-mode получает мультикаст трафик, он будет отправлять трафик только через те интерфейсы, где были запросы на данный поток, например Pim Join или IGMP Report сообщения с запросом на данный трафик.
Cхожие элементы у SM и DM:
- Отношения соседства строятся также, как и в PIM DM.
- Работает правило RPF.
- Выбор DR аналогичен.
- Механизм Prune Overrides и сообщения Assert аналогичены.
Для контроля того, кому, где и какой мультикаст трафик нужен в сети, необходимо общий информационный центр. Таким центром у нас будет Rendezvous Point ( RP ). Все, кто хочет какой-то мультикаст трафик или кто-то начал получать мультикаст трафик от источника, то он отправляет его на RP.
Когда RP получит мультикаст трафик, то отправит его тем маршрутизаторам, которые запросили до этого этот трафик.
Представим такую топологию, где RP это R3. Как только R1 получит трафик от S1, то он инкапсулирует данный мультикаст пакет в юникастовое PIM Register сообщение и отправит его на RP. Откуда он знает кто RP? В данном случае, он настроен статически, а о динамической настройке RP поговорим позже.
ip pim rp-address 3.3.3.3
RP посмотрит — а была ли информация от кого-то, кто хотел бы получать этот трафик? Предположим, что не было. Тогда RP отправит R1 сообщение PIM Register-Stop, что означает — никому не нужен этот мультикаст, в регистрации отказано. R1 не будет посылать мультикаст. Но хост-источник мультикаста будет слать его, так что R1 после получения Register-Stop, запустит таймер Register-Suppression timer, равный 60 секундам. За 5 секунд до истечения данного таймера, R1 будет посылать пустое Register сообщение с Null-Register bit ( то есть без инкапсулированного мультикаст пакета) в сторону RP. RP в свою очередь будет действовать так:
- Если получателей как не было, так и нет, то он будет отвечать Register-Stop сообщением.
- Если получатели появились, то он никак не ответит на него. R1 не получив на свою регистрацию отказа в течении 5 секунд, обрадуется и отправит Register сообщение с инкапсулированным мультикаст на RP.
Как мультикаст доходит до RP вроде бы разобрались, теперь попытаемся ответить на вопрос как RP доводит трафик до получателей. Здесь необходимо ввести новое понятие — root-path tree (RPT). RPT — это дерево с корнем в RP, растущее в сторону получателей, разветвляющиеся на каждом PIM-SM маршрутизаторе. RP создает его, получая PIM Join сообщения и добавляет в дерево новую ветвь. И так, делает каждый нижестоящий маршрутизатор. Общее правило выглядит так:
- Когда PIM-SM маршрутизатор получает PIM Join сообщение на каком-либо интерфейсе, за исключением интерфейса за котором скрывается RP, он добавляет в дерево новую ветвь.
- Также ветвь добавляется, когда PIM-SM маршрутизатор получает IGMP Membership Report с непосредственно подключенного хоста.
Представим, что у нас появился клиент мультикаста на маршрутизаторе R5 на группу 228.8.8.8. Как только R5 получит IGMP Membership Report от хоста, R5 отправляет PIM Join в направлении RP, а сам добавляет в дерево интерфейс, смотрящий на хост. Далее, R4 получает PIM Join от R5, добавляет в дерево интерфейс Gi0/1 и отправляет PIM Join в направлении RP. Наконец то, RP ( R3 ) получает PIM Join и добавляет Gi0/0 в дерево. Таким образом, получается регистрация получателя мультикаста. У нас строится дерево с корнем R3-Gi0/0 > R4-Gi0/1 > R5-Gi0/0.
После этого, будет отправлен PIM Join к R1 и R1 начнет слать мультикаст трафик. Важно заметить, что если хост запросил трафик до того, как началось вещание мультикаста, то RP не будет отправлять PIM Join и вообще не будет ничего отправлять в строну R1.
Если вдруг пока отправляется мультикаст, хост перестанет хотеть его получать, как только RP получит PIM Prune на интерфейс Gi0/0, то сразу отправит PIM Register-Stop непосредственно на R1, а затем и PIM Prune сообщение через интерфейс Gi0/1. PIM Register-stop отправляется юникастом на тот адрес, с которого поступило PIM Register.
Как мы говорили раньше, как только маршрутизатор отправляет PIM Join другому, например R5 на R4, то на R4 добавляется запись:
И запускается таймер, что сбросить данный таймер R5 должен постоянно PIM Join сообщения постоянно, а то R4 исключит из outgoing list. R5 будет отправлять каждые 60 PIM Join сообщения.
Shortest-Path Tree Switchover.
Мы добавим интерфейс между R1 и R5, посмотрим как будет литься трафик при такой топологии.
Допустим, что трафик отправлялся и получался по старой схеме R1-R2-R3-R4-R5 и тут мы подключили и настроили интерфейс между R1 и R5.
Первым делом, у нас перестроиться юникастовая таблица маршрутизации на R5 и теперь сеть 192.168.1.0/24 достигается через интерфейс R5 Gi0/2. Теперь R5 получая мультикаст на интерфейсе Gi0/1, понимает, что правило RPF не удовлетворяется и мультикаст логичнее бы получать на Gi0/2. Он должен отключиться от RPT и построить более короткое дерево, которое называется Shortest-Path Tree ( SPT ). Для этого он через Gi0/2 отправляет PIM Join на R1 и R1 начинает слать мультикаст еще и через Gi0/2. Теперь R5 надо отписаться от RPT, чтоб не получать две копии. Для этого он отправляет Prune сообщение указывая ip адрес источника и вставляя специальный бит — RPT-bit. Это значит, что не надо мне посылать трафик, у меня здесь дерево получше. RP также отправляет в сторону R1 PIM Prune сообщения, но не отправляет Register-Stop сообщение. Еще одна особенность: R5 теперь будет постоянно отправлять PIM Prune на RP, так как R1 продолжает отправлять PIM Register на RP каждую минуту. RP пока не будет новых желающих данного трафика будет отвечать ему отказом. R5 уведомляет RP, что он продолжает получать мультикаст через SPT.
Динамический поиск RP.
Auto-RP.
Данная технология является проприетарной от Cisco и не пользуется особой популярной, но все еще жива. Работа Auto-RP состоит из двух основных этапов:
1) RP шлет RP-Announce сообщения на зарезервированный адрес — 224.0.1.39, объявляя себя RP либо для всех либо для определенных групп. Отправляется данное сообщение каждую минуту.
2) Необходим RP mapping agent, который будет слать RP-Discovery сообщения с указанием для каких групп какой RP необходимо слушать. Именно из этого сообщения, обычные PIM маршрутизаторы будут определять для себя RP. Mapping Agent может быть как сам RP маршрутизатор, так и какой-либо отдельный PIM маршрутизатор. RP-Discovery отправляется на адрес 224.0.1.40 c таймером в одну минуту.
Посмотрим на процесс поподробнее:
Настроим R3 как RP:
ip pim send-rp-announce loopback 0 scope 10
R2 как mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
А на всех остальных будем ожидать RP через Auto-RP:
ip pim autorp listener
Как только мы настроим R3, он начнет отправлять RP-Announce:
А R2 после настройки mapping agent-ом, начнет ждать сообщения RP-Announce. Только когда он найдет хотя бы один RP, то начнет отправлять RP-Discovery:
Таким образом, как только обычные маршрутизаторы ( PIM RP Listener ) получат данное сообщения, они будут знать где искать RP.
Одна из основных проблем Auto-RP заключается в том, что чтобы получать сообщения RP-Announce и RP-Discovery необходимо отправлять PIM Join на адреса 224.0.1.39-40, а для того, чтобы отправить, надо знать где находится RP. Классическая проблема курицы и яйца. Для решение это проблемы, был придуман режим PIM Sparse-Dense-Mode. Если маршрутизатор не знает RP, то он работает в режиме Dense-mode, если знает, то в режиме Sparse-mode. Когда на интерфейсах обычных маршрутизаторов настроен PIM Sparse-mode и команда ip pim autorp listener, то маршрутизатор будет работать в режиме Dense-mode только для мультикаста непосредственно Auto-RP протокола ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Данный функция работает похоже на Auto-RP. Каждый RP шлет сообщение mapping agent-у, который собирает маппинг информацию и далее рассказывает всем остальным маршрутизаторам. Опишем процесс аналогично Auto-RP:
1) Как только мы настроим R3 в качестве кандидата быть RP, командой:
ip pim rp-candidate loopback 0
То R3 ничего делать не будет, для того, чтобы начать слать специальные сообщение, ему, для начала, надо найти mapping agent-а. Таким образом, переходим ко второму шагу.
2) Настраиваем R2 как mapping agent:
ip pim bsr-candidate loopback 0
R2 начинает рассылать PIM Bootstrap сообщения, где указывает себя в качестве mapping agent-а:
Отправляется данное сообщение на адрес 224.0.013, которое PIM протокол использует и для других своих сообщений. Он отправляет их во все стороны и поэтому нет проблемы курицы и яйца, как было в Auto-RP.
3) Как только RP получит сообщение от BSR маршрутизатора, он сразу отправит юникастовое сообщение на адрес BSR маршрутизатора:
После чего, BSR получив информацию о RP, разошлет их мультикастом на адрес 224.0.0.13, который слушают все PIM маршрутизаторы. Поэтому, аналога команды ip pim autorp listener для обычных маршрутизаторов нет в BSR.
Anycast RP with Multicast Source Discovery Protocol (MSDP).
Auto-RP и BSR нам позволяют распредилить нагрузку на RP следующим образом: У каждой мультикаст группы есть только один активный RP. Не получится сделать распределение нагрузки для одной мультикаст группы несколько RP. MSDP делает это при помощи выдачи RP маршрутизаторам одинакового ip адреса с маской 255.255.255.255. MSDP узнает информацию при помощи одного из методов: статики, Auto-RP или BSR.
На картинке у нас Auto-RP конфигурация с MSDP. Оба RP настроены с ip адресом 172.16.1.1/32 на Loopback 1 интерфейсе и используется для всех групп. При RP-Announce оба маршрутизатора рассказывают о себе, ссылаясь на этот адрес. Auto-RP mapping agent, получив информацию, рассылает RP-Discovery об RP c адресом 172.16.1.1/32. Про сеть 172.16.1.1/32, маршрутизаторам мы рассказываем при помощи IGP и, соответственно. Таким образом, PIM маршрутизаторы запрашивают или регистрируют потоки с того RP, к который указан как next-hop у маршрута к сети 172.16.1.1/32. Cам протокол MSDP же призван для самих RP, чтоб обмениваться сообщениями о информации про мультикаст.
Рассмотрим такую топологию:
Switch6 вещает трафик на адрес 238.38.38.38 и о нем пока знает только RP-R1. Вот Switch7 и Switch8 запросили данную группу. Маршрутизаторы R5 и R4 отправят PIM Join на R1 и R3, соответственно. Почему? Маршрут до 13.13.13.13 у R5 будет ссылаться на R1 по метрике IGP, как и у R4.
RP-R1 знает о потоке и начнет вещать его в сторону R5, а вот R4 ничего о нем не знает, так как R1 просто так его отправлять не будет. Поэтому необходим MSDP. Настраиваем его на R1 и R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 на R1
ip msdp peer 1.1.1.1 connect-source Loopback3 на R3
Они поднимут сессию между друг другом и при получении какого-либо потока будут сообщать о нем своему RP соседу.
RP-R1 как только получит поток от Switch6, сразу отправит юникастом MSDP Source-Active сообщение, где будет содержаться информация типа ( S, G) — информация о источнике и назначении мультикаста. Теперь, когда RP-R3 будет знать, что такой источник как Switch6, он при получении запроса от R4 на данный поток, будет слать в сторону Switch6 PIM Join, руководстваясь таблицей маршрутизации. Следовательно, R1 получив такой PIM Join, начнет слать трафик в сторону RP-R3.
MSDP работает по TCP, RP посылают друг другу keepalive сообщения для проверки жизнеспособности. Таймер равен 60 cекундам.
Остается непонятной функция разделения MSDP пиров в различные домены, так как в сообщениях Keepalive и SA не указывается принадлежность какому-либо домену. Также в данной топологии тестировалась конфигурация с указанием различных доменов — разницы в работе не было.
Если кто-то может внести ясность, с радостью почитаю в комментариях.
На этом думаю закончить статью. Внизу полезный материалы и ссылки, которые использовались:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Сети для самых маленьких. Часть девятая. Мультикаст
akai
Спасибо, всегда полезно освежить в памяти. Любопытно, как один сетевой вендор, презентуя свою новую-старую фабрику, призванную заменить все прочие протоколы, показывает страшные картинки «как было», где громоздятся друг на друга PIM, OSPF и MPLS. Производит впечатление на некоторых, наверное. Хотя по факту ничего особо сложного там нет.
Ruslan_Mammadov Автор
Складывается такое ощущение, что сейчас в новых разработках большую роль играют маркетологи, а не инженеры.