В данной статье мы рассмотрим с вами такую тему, как протокол PIM в режиме Dense.
Изучать его мы будем на следующей топологии:
В качестве источника мультикаст-трафика будет выступать маршрутизатор R6, в качестве получателя R7.
Итак, что же это за зверь такой, PIM Dense Mode (DM)? По сути своей, это протокол маршрутизации для multicast-трафика, который считает, что приложение, которому требуется мультикаст-рассылка настолько популярно, что в каждом сегменте сети есть хотя бы один получатель такого рода трафика. Согласно этому в дизайн протокола заложена мысль, что маршрутизатор должен передавать мультикаст-трафик через все свои интерфейсы (за исключением некоторых – во имя избежания петель, но об этом позже). Т.е. если на интерфейс Fa0/0 маршрутизатора R1 придет мультикаст-поток от сервера, то он должен будет переслать его через Se1/0 и Se1/1 (кстати, такой процесс называется флудингом). Нельзя не заметить, что если просто пересылать пакеты через все существующие интерфейсы, то в сети образуется петля мультикастного-трафика. Для предотвращения таких петель в PIM реализован механизм проверки пути Reverse Path Forwarding (RPF). Работает он следующим образом: при приеме мультикаст-пакета первым делом необходимо посмотреть на IP-адрес источника. Если юникаст-маршрут к этому адресу пролегает через тот же интерфейс, через который пришел мультикаст-пакет, то пакет флудится дальше. Если же нет, то данные дропаются.
Рассмотрим на примере: предположим, что на R3 приходят два мультикаст-пакета (на интерфейсы Se1/0 и Se1/1) от сервера R6 (ip=172.16.16.6). R3 сверяется со своей таблицей маршрутизации для указанного IP-адреса (show ip route 172.16.16.6) и видит, что выходным интерфейсом является Se1/0. Следовательно пакет, полученный через Se1/0 флудится в сторону R5, а пакет полученный через Se1/1 дропается. Собственно, такая процедура выполняется на всех маршрутизаторах в сети.
Прим. Чтобы PIM-маршрутизаторы могли корректно исполнять свои функции (т.е. строить мультикастную таблицу маршрутизации), они все должны установить друг с друг отношения соседства (подобно OSPF и EIGRP). Для этого раз в 30 секунд на всех интерфейсах (где включен PIM) на зарезервированный адрес 224.0.0.13 рассылаются Hello-сообщения. После того, как на интерфейсе будет установлено отношение соседства, через этот интерфейс далее смогу рассылаться служебные PIM-сообщения (какие конкретно – рассмотрим далее).
Процесс, описанный параграфом выше, описывает процесс, который в терминах PIM называется построением мультикаст-дерева источника (source—based tree или shortest—path tree, SPT). Само дерево описывает путь между источником и всеми сетями, которые нуждаются в получении трафика от этого источника. В качестве корня дерева выступает сам источник мультикаст-трафика, в качестве листьев – получатели, а в качестве непосредственно ветвей – транзитные маршрутизаторы между источником и получателем. Переходя на наш пример, для связки R6-R7 дерево примет вид: R7-R4-R1-R6.
PIM-DM создает новое SPT в случае когда источник начинает слать пакеты на новый мультикаст-адрес (также адрес назначения мультикаст-пакета еще называют мультикаст-группой). SPT включает в себя все интерфейсы за исключением RPF-интерфейсов, что создает некоторую проблему – ведь не все подсети хотят получать мультикаст-поток. Для удаления «лишних» интерфейсов из дерева PIM использует Prune-сообщения. Как это работает: R1 получает мультикаст-поток на адрес 239.1.1.8 (в котором нуждается R8) от R6 и передает его в сторону R4 и R2. R2 передает его в сторону R3, а R4 в сторону R5 и затем в сторону R3. Таким образом на R3 приходят два одинаковых мультикаст-пакета, а проверку на RPF пройдет только один из них (естественно тот, который пришел от R2 – т.к. он ближе к источнику)! Возникает резонный вопрос – для чего гонять трафик по пути R1-R4-R5-R3, если он все равно, в конце концов, дропается? Разработчики RFC учли этот вопрос и предложили следующее решение: как только R3 получает мультикаст-пакет через интерфейс, который не проходит RPF-проверку, то он незамедлительно через этот же интерфейс высылает сообщение Prune, которое говорит маршрутизатору-соседу больше не слать к нему трафик (если говорить научно, а не «на пальцах», то такое сообщение говорит следующее: удали интерфейс, через который ты получишь это Prune-сообщение, из выходного списка для трафика, который идет от указанного источника к указанной группе. В нашем случае IP источника 172.16.16.6, группа 239.1.1.9. В PIM такая связка записывается как (172.16.16.6, 239.1.1.9)).
Прим. Термин «выходной список» (или outgoing interface list, OIL) означает набор интерфейсов, через которые можно высылать мультикаст-трафик.
R3#show ip mroute 239.1.1.8
(172.16.16.6, 239.1.1.8), 00:00:40/00:02:28, flags: T
Incoming interface: Serial1/0, RPF nbr 10.1.23.2
Outgoing interface list:
Serial1/1, Prune/Dense, 00:00:40/00:02:22
Serial1/2, Forward/Dense, 00:00:40/00:00:00
R5#show ip mroute 239.1.1.8
(172.16.16.6, 239.1.1.8), 00:00:29/00:02:35, flags: PT
Incoming interface: Serial1/1, RPF nbr 10.1.45.4
Outgoing interface list:
Serial1/0, Prune/Dense, 00:00:28/00:02:32, A
Информация из листинга может быть интерпретирована следующим образом: интерфейс Se1/0 маршрутизатора R5 находится в состоянии Prune из-за полученного сообщения от R3. Тут хотелось бы отметить следующий момент: на R5 нет ни одного интерфейса в OIL, который бы находился в состоянии Forward (это значит, что R5 не участвует в SPT для дерева (172.16.16.6, 239.1.1.8)). Поэтому R5 передает сообщение Prune в сторону R4, а R4 в сторону R1.
R4#show ip mroute 239.1.1.8
(172.16.16.6, 239.1.1.8), 00:01:55/00:01:10, flags: PT
Incoming interface: Serial1/1, RPF nbr 10.1.14.1
Outgoing interface list:
Serial1/0, Prune/Dense, 00:01:54/00:01:05
R1#show ip mroute 239.1.1.8
(172.16.16.6, 239.1.1.8), 00:04:32/00:02:59, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Dense, 00:04:32/00:00:00
Serial1/1, Prune/Dense, 00:01:19/00:01:40
Т.е. трафик идет по дереву R1-R2-R3.
Поскольку PIM-DM по своей натуре стремится всегда передавать мультикаст трафик, то R5 переведет свой интерфейс Se1/0 из состояния Prune в состояние Forward через 2 минуты и 32 секунды. Объясняется такое поведение следующим: когда маршрутизатор получает Prune сообщение через какой-либо интерфейс, то этот интерфейс помещается в состояние Prune и запускается Prune-таймер (3 минуты по-умолчанию) по истечении которого интерфейс должен быть возвращен в состояние Forward. Согласитесь, что это не самое оптимальное поведение, ведь R3 все еще не заинтересован в получении мультикаст-потока от R5! Чтобы устранить такое поведение было придумано специальное сообщение State Refresh. Сущность этого сообщения следующая: перед истечением Prune-таймера R3 посылает сообщение State Refresh через все интерфейсы из OIL-списка, которые находятся в состоянии Prune. Маршрутизатор R5 при получении такого сообщения сбрасывает свой Prune-таймер в первоначальное состояние (3 минуты) и передает State Refresh дальше соседу R4.
Помимо этого можно увидеть и еще одну возможную проблему: в данный момент времени R4 не получает мультикаст-поток на адрес 239.1.1.8 (что и есть на самом деле) – т.е. весь OIL находится в состоянии Prune. Предположим, что в этот момент времени маршрутизатор R7 объявляет о своем желании получать трафик на группу 239.1.1.8 (R7 посылает сообщение Join в сторону R4). Однако у R1 интерфейс, смотрящий в сторону R4 будет находиться в состоянии Prune до момента истечения таймера. Т.е. хост R7 может не принимать мультикаст-трафик в течение трех минут. Не критично, но не совсем красиво. Для устранения данной проблемы было придумано Graft-сообщение. Его генерирует маршрутизатор R4 (тот, который получил JOIN от клиента) и передает его через IIL в сторону R1. R1 получая GRAFT через интерфейс, который находится в состоянии Prune, немедленно переводит его в состояние Forward.
Еще одним интересным моментом, о котором я бы хотел написать, является дизайн, в котором один получатель может получать трафик от двух маршрутизаторов одновременно в одном сегменте. Чтобы смоделировать такую ситуацию, соединим R5 и SW1.
R2#ping 239.1.1.7 repeat 3 source Loopback0
Reply to request 0 from 172.16.100.7, 208 ms
Reply to request 0 from 172.16.100.7, 304 ms
Reply to request 1 from 172.16.100.7, 176 ms
Reply to request 2 from 172.16.100.7, 213 ms
Как видим на первый пакет к нам приходят два ответа от R7, а на следующие по одному. Из-за чего так происходит? Все довольно просто. Первоначально R2 рассылает мультикаст-трафик через Se1/0 и Se1/1. R1 и R3 строят SPT для (2.2.2.2, 239.1.1.7) и передают пакеты далее на R4 и R5 соответственно. R4 и R5 флудят пакет далее через свои Fa0/0 интерфейсы. В итоге на R7 приходят два ICMP-запроса, на каждый из которых он и отвечает. Почему же на следующие пакеты мы видим только один ответ? Ответ заключается в следующем: когда R5 высылает пакет через Fa0/0, то помимо R7 его получает и R4 (и соответственно пакет от R4 получает R5). R4 и R5 трактуют эту ситуацию следующим образом: в LAN среде есть маршрутизатор, который также шлет пакеты для SPT (2.2.2.2, 239.1.1.7). Далее маршрутизаторы генерируют Assert сообщение, внутри которого находятся данные об их юникаст-метрике в сторону источника 2.2.2.2. Тот маршрутизатор, у которого меньше метрика (если же два маршрутизатора используют протоколы маршрутизации с разной AD, то тот, у которого меньше AD) становится Assert-победителем и только он будет передавать трафик для указанного SPT в LAN-сегмент. Если же метрики равны, то победителем становится маршрутизатор с наибольшим IP-адресом. В нашем случае победитель – R5. А R4 в сторону R1 высылает Prune-сообщение.
Прим. Любопытно отметить, что хотя R5 выиграл Assert, но маршрутизатором, который обслуживает JOIN-сообщения в данном LAN-сегменте будет R4, т.к. он имеет меньший IP-адрес. Эдакая балансировка нагрузки между маршрутизаторами.
В заключение хочу отметить, что в статье нет ни слова о настройке. Это не случайно: настроить мультикаст гораздо проще, нежели понять как он работает. А моей целью всегда является именно донесение материала. Тем более, что настраивается PIM-DM очень просто: первоначально на маршрутизаторах надо дать команду ip multicast—routing, а затем на нужных интерфейсах ввести ip pim dense—mode.
Метки: multicast, PIM
Опубликовано: Маршрутизаторы и коммутаторы
» Оставить комментарий
Вы должны войти чтобы прокомментировать.