SPT Switchover — переключение RPT-SPT
До сих пор мы преимущественно рассматривали только Клиента 1. Теперь обратимся к Клиенту 2. По началу всё для него идентично Клиенту 1 — он пользуется RPT от RP, который мы рассматривали ранее. Кстати, поскольку оба — и Клиент 1 и Клиент 2 — используют одно дерево, такое дерево называется Shared Tree — это довольно общее название. Shared tree = RPT.
Вот как выглядит таблица мультикастовой маршрутизации на R5 в самом начале, сразу после построения дерева:
Здесь нет записи (S, G), но это не значит, что мультикастовый трафик не передаётся. Просто R5 не заботится о том, кто отправитель.
Обратите внимание по какому пути должен идти в этом случае трафик — R1-R2-R3-R5. Хотя ведь короче путь R1-R3-R5.
А если сеть посложнее?
Как-то неаккуратненько.
Дело в том, что пока мы привязаны к RP — она корень RPT, только она поначалу знает, где кто находится. Однако если вдуматься, то после первого же мультикастового пакета все маршрутизаторы по пути трафика будут знать адрес источника, ведь он указан в заголовке IP.
Почему бы кому-нибудь не отправить самому Join в сторону источника и оптимизировать маршрут?
Получив такой Join, R3 отправляет его не на RP, как делал это с обычным Join (*, G), а в сторону источника (через интерфейс согласно таблице маршрутизации). То есть в данном случае R3 отправляет Join (172.16.0.5, 224.2.2.4) в интерфейс FE1/0.
Далее этот Join попадает на R1. А R1 по большому счёту без разницы, кто его отправлял — RP или кто-то другой — он просто добавляет FE1/1 в свой OIL для группы 224.2.2.4.
В этот момент между источником и получателем два пути и R3 получает два потока.
Время сделать выбор, чтобы обрезать лишнее. Причём именно R3 его делает, потому что R5 уже не сможет различить эти два потока — они оба придут через один интерфейс. Как только R3 зафиксировал два одинаковых потока с разных интерфейсов, он выбирает предпочтительный согласно таблице маршрутизации. В данном случае прямой, лучше, чем через RP. В этот момент R3 посылает Prune (S, G) в сторону RP, обрубая эту ветку RPT. И с этого момент остаётся только один поток напрямую от источника.
Таким образом PIM построил SPT — Shortest Path Tree. Оно же Source Tree. Это кратчайший путь от клиента до источника. Кстати, дерево от источника до RP, которое мы уже рассматривали выше, — по сути ровно то же самое SPT. Оно характеризуется записью (S, G). Если маршрутизатор имеет такую запись, значит он знает, что S является источником для группы G и построено дерево SPT.
Корнем дерева SPT является источник и очень хочется сказать «кратчайший путь от источника до клиента». Но это технически некорректно, поскольку пути от источника до клиента и от клиента до источника могут быть разными. А именно от клиента начинает строиться ветка дерева: маршрутизатор отправляет PIM Join в сторону источника/RP и RPF также проверяет правильность интерфейса при получении трафика.
Вы помните, что вначале этого параграфа на R5 была только запись (, G), теперь после всех этих событий их станет две: (, G) и (S, G).
Между прочим, даже если вы посмотрите на мультикастовую таблицу маршрутизации R3 в ту же секунду, как нажали Play в VLC, то увидите, что он уже получает трафик от R1 напрямую, о чём говорит наличие записи (S, G). То есть SPT Switchover уже произошёл — это действие по умолчанию на оборудовании многих производителей — инициировать переключение после получения первого же мультикастового пакета.
Вообще говоря, происходить такое переключение может в нескольких случаях:
Не происходить вообще никогда (команда ip pim spt-threshold infinity).
При достижении определённой утилизации полосы пропускания (команда ip pim spt-threshold X).
Безусловно — сразу после получения первого пакета (действие по умолчанию или no ip pim spt-threshold X)
Как правило, решение о том, что «пора», принимает LHR.
В этом случае во второй раз изменяется правило работы RPF — он снова проверяет местонахождение источника. То есть из двух потоков мультикаста — от RP и от источника — предпочтение отдаётся трафику от источника.
Last updated
