PIM Dense Mode
Last updated
Last updated
PIM DM пытается решить проблему доставки мультиакста в лоб. Он заведомо предполагает, что получатели есть везде, во всех уголках сети. Поэтому изначально он наводняет всю сеть мультикастовым трафиком, то есть рассылает его во все порты, кроме того, откуда он пришёл. Если потом оказывается, что где-то он не нужен, то эта ветка «отрезается» с помощью специального сообщения PIM Prune — трафик туда больше не отправляется.
Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст — вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft — маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт. Как видите, здесь не стоит вопрос определения пути к получателям — трафик достигнет их просто потому, что он везде. После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT — Shortest Path Tree.
Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в , где корнем является источник. SPT — это конкретный вид дерева — дерево кратчайшего пути. А вообще любое мультикастовое дерево называется MDT — Multicast Distribution Tree.
Предполагается, что PIM DM должен использоваться в сетях с высокой плотностью мультикастовых клиентов, что и объясняет его название (Dense). Но реальность такова, что эта ситуация — скорее, исключение, и зачастую PIM DM нецелесообразен.
Что нам действительно важно сейчас — это механизм избежания петель. Представим такую сеть:
Один источник, один получатель и простейшая IP-сеть между ними. На всех маршрутизаторах запущен PIM DM.
Что произошло бы, если бы не было специального механизма избежания петель? Источник отправляет мультикастовый трафик. R1 его получает и в соответствии с принципами PIM DM отправляет во все интерфейсы, кроме того, откуда он пришёл — то есть на R2 и R3.
R2 поступает точно так же, то есть отправляет трафик в сторону R3. R3 не может определить, что это тот же самый трафик, который он уже получил от R1, поэтому пересылает его во все свои интерфейсы. R1 получит копию трафика от R3 и так далее. Вот она — петля.
Что же предлагает PIM в такой ситуации? RPF — Reverse Path Forwarding. Это главный принцип передачи мультикастового трафика в PIM (любого вида: и DM и SM) — трафик от источника должен приходить по кратчайшему пути. То есть для каждого полученного мультикастового пакета производится проверка на основе таблицы маршрутизации, оттуда ли он пришёл.
1) Маршрутизатор смотрит на адрес источника мультикастового пакета. 2) Проверяет таблицу маршрутизации, через какой интерфейс доступен адрес источника. 3) Проверяет интерфейс, через который пришёл мультикастовый пакет. 4) Если интерфейсы совпадают — всё отлично, мультикастовый пакет пропускается, если же данные приходят с другого интерфейса — они будут отброшены. В нашем примере R3 знает, что кратчайший путь до источника лежит через R1 (статический или динамический маршрут). Поэтому мультикастовые пакеты, пришедшие от R1, проходят проверку и принимаются R3, а те, что пришли от R2, отбрасываются.
Такая проверка называется RPF-Check и благодаря ей даже в более сложных сетях петли в MDT не возникнут. Этот механизм важен нам, потому что он актуален и в PIM-SM и работает там точно также. Как видите, PIM опирается на таблицу юникастовой маршрутизации, но, во-первых, сам не маршрутизирует трафик, во-вторых, ему не важно, кто и как наполнял таблицу.
Однако PIM DM может применяться в некоторых случаях. Например, в совсем небольших сетях, где поток мультикаста небольшой.
Останавливаться здесь и подробно рассматривать работу PIM DM мы не будем — это устаревший протокол с массой недостатков (ну, как ).
