PIM Sparse Mode
Совершенно другой подход применяет PIM SM. Несмотря на название (разреженный режим), он с успехом может применяться в любой сети с эффективностью как минимум не хуже, чем у PIM DM. Здесь отказались от идеи безусловного наводнения мультикастом сети. Заинтересованные узлы самостоятельно запрашивают подключение к дереву с помощью сообщений PIM Join. Если маршрутизатор не посылал Join, то и трафик ему отправляться не будет.
С этого момента вы можете расчехлить GNS и собирать лабораторию. Достаточно подробно о том, как собрать стенд для мультикаста я рассказал в этой статье.
Cisco тут как обычно отличается своим особенным подходом: при активации PIM на интерфейсе, автоматически активируется и IGMP. На всех интерфейсах, где активирован PIM, работает и IGMP. В то же время у других производителей два разных протокола включаются двумя разными командами: отдельно IGMP, отдельно PIM. Простим Cisco эту странность? Вместе со всеми остальными?
Плюс, возможно, потребуется настроить адрес RP (ip pim rp-address 172.16.0.1, например). Об этом позже, пока примите как данность и смиритесь.
Проверим текущее состояние таблицы мультикастовой маршрутизации для группы 224.2.2.4:
После того, как на источнике вы запустите вещание, надо проверить таблицу ещё раз.
Давайте разберём этот немногословный вывод.
Запись вида (*, 224.2.2.4) называется (*, G), /читается старкомаджи/ и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик. Если список нисходящих интерфейсов (OIL) пуст — Null, значит нет получателей — а мы их пока не запускали.
Запись (172.16.0.5, 224.2.2.4) называется (S, G), /читается эскомаджи/ и говорит о том, что известен источник. В нашем случае источник с адресом 172.16.0.5 вещает трафик для группы 224.2.2.4. Мультикастовый трафик приходит на интерфейс FE0/1 — это восходящий (Upstream) интерфейс.
Итак, нет клиентов. Трафик от источника доходит до маршрутизатора и на этом его жизнь кончается. Давайте добавим теперь получателя — настроим приём мультикаста на ПК. ПК отсылает IGMP Report, маршрутизатор понимает, что появились клиенты и обновляет таблицу мультикастовой маршрутизации. Теперь она выглядит так:
Появился и нисходящий интерфейс: FE0/0, что вполне ожидаемо. Причём он появился как в (*, G), так и в (S, G). Список нисходящих интерфейсов называется *OIL — Outgoing Interface List_.
Добавим ещё одного клиента на интерфейс FE1/0:
Если читать вывод дословно, то имеем: (*, G): Есть получатели мультикастового трафика для группы 224.2.2.4 за интерфейсами FE0/0, FE1/0. Причём совершенно неважно, кто отправитель, о чём и говорит знак «*».
(S, G): Когда мультикастовый трафик с адресом назначения 224.2.2.4 от источника 172.16.0.5 приходит на интерфейс FE0/1, его копии нужно отправить в FE0/0 и FE1/0.
Но это был очень простой пример — один маршрутизатор сразу знает и адрес источника и где находятся получатели. Фактически даже деревьев тут никаких нет — разве что вырожденное. Но это помогло нам разобраться с тем, как взаимодействуют PIM и IGMP.
Last updated
