L3 Multicast. PIM. Dense Mode. Практика. Часть 2.
2021.11.11. Kurapov Alexey.
L3 Multicast. PIM. Dense Mode
Продолжим изучение передачи Multicast
трафика в сетях в целом, и работу
протокола PIM в
режиме Dense-mode
в частности.
В статье L3 Multicast. PIM. Dense Mode. Практика. Часть
1 была рассмотрена топология:
Продолжим работу с ней
Рассмотрим механизм RPC:
Зачем?
Reverse
Path Forwarding (RPF) — это проверка,
которую выполняют маршрутизаторы, для того чтобы убедиться, что multicast трафик передается по пути без
петель.
Как
работает?
Начнем с GW_2. Роутер на интерфейсе Gi0/0 (в
сторону сервера) проводит RPF для Source
IP,
запустим ping
с сервера на multicast адрес
239.1.1.1:
Смотрим в Wireshark на
интерфейсе Gi0/0 роутера GW_2:
Пакеты с source
IP = 172.16.0.10 и destination
IP = 239.1.1.1:
Reverse Path Forwarding проводится для Source IP = 172.16.0.10, роутер GW_2 проверяет обратный маршрут – unicast маршрут на адрес 172.16.0.10:
Роутер сравнивает вывод команды sh ip route 172.16.0.10 – unicast маршрут – via Gi0/0 и интерфейс, через, который был получен multicast
пакет, на multicast группу – sh ip mroute 172.16.0.10 239.1.1.1 –
Incoming interface – Gi0/0:
- если значения равны -> все в порядке,
петли нет, и multicast трафик
передается на интерфейсы, указанные в Outgoing
interface list
– OIL,
- если значения интерфейсов не равны – пакет
дропается.
Также работу механизма RPF можно
проверить с помощью команды:
#sh ip rpf source_IP:
Т.о. пакеты с source IP 172.16.10 можно
получать только на interface Gi0/0, если придут с другого интерфейса, то
дропаем их – это защита от петель в протоколе PIM.
RPF проверка
проводится на каждом роутере независимо и следовательно для работы PIM требуется
базовая unicast ip-связность – unicast маршрутизация.
PIM –Protocol
Independent Multicast
– не зависит от низлежащих – underlay,
протоколов.
Роутеры R1 и R2 и GW_1 также выполняют RPF
проверку:
С текущей топологией не совсем полностью
раскрыта работа механизма RPF, дополним
топологию роутером R3:
Настройки
R3 аналогичны настройкам R1 и R2.
Отправляем
ping с
сервера и смотрим на интерфейсе Gi0/0 Gw_1:
Роутер R1 ожидает multicast трафик
с source ip = 172.16.0.10
только с interface gi0/2 от GW_2, но получает его и с interface gi0/0 от роутера R3 и будет дропать его, т.к. данные интерфейс не
пройдет RPF проверку. Данный вариант не оптимальный и
поэтому R1 высылает в сторону R3 сообщение Prune:
Суть сообщения Prune – сосед 10.0.5.2 не высылай мне multicast трафик
для multicast группы 239.1.1.1, с source IP 172.16.0.10
в течении 210 секунд.
И роутер R3 10.0.5.2 не высылает указанный трафик в течении 210 секунд. По истечении этого таймера роутеры R1 и R3 переводят интерфейсы между собой в состояние forwarding, и R1 опять высылает R3 сообщение Prune. Такой вариант также не является оптимальным, т.к. по истечении Holdtime в сети наблюдается multicast flooding на несколько секунд.
Как решить проблему?
R1 и R3 отправляют
Assert сообщения друг другу:
в которые включены AD и
метрика маршрута при помощи которого достигается источник мультикаста —
172.16.0.10. Победитель тот у кого ниже AD, если AD равны, то у кого ниже метрика, если и тут
равенство, то тот у кого выше IP в сети, в
которую они вещают этот мультикаст.
В нашем случае побеждает R3, он и высылает в дальнейшем по истечению Holdtime в сообщения Assert:
R1 отвечает сообщением Prune – мне не нужен трафик на multicast группу
239.1.1.1:
Таймер Holdtime снова
выставляется в 210 секунд и проблема milticast
flooding решена
до его истечения.
У R3 нет
клиентов заинтересованных в multicast
трафике на группу 239.1.1.1 и он также
высылает сообщение Prune в сторону GW_2:
Если на R3 появится клиент, заинтересованный в трафике
на группу 239.1.1.1, то он вышлет сообщение Graft в
сторону GW_2 и GW_2 начнет высылать multicast также
до истечения Holdtime.
Prune сообщения
всегда в сторону Uptime-neighbor –
это интерфейс, который проходит RPF
проверку.
Комментарии
Отправить комментарий