1.-pim-sparse-mode.md
1 # PIM Sparse Mode 2 3 Совершенно другой подход применяет **PIM SM**. Несмотря на название \(разреженный режим\), он с успехом может применяться в любой сети с эффективностью как минимум не хуже, чем у PIM DM. 4 Здесь отказались от идеи безусловного наводнения мультикастом сети. Заинтересованные узлы самостоятельно запрашивают подключение к дереву с помощью сообщений **PIM Join**. 5 Если маршрутизатор не посылал Join, то и трафик ему отправляться не будет. 6 7 Для того, чтобы понять, как работает PIM, начнём с уже знакомой нам простой сети с одним PIM-маршрутизатором: 8  9 Из настроек на R1 надо включить возможность маршрутизации мультикаста, PIM SM на двух интерфейсах \(в сторону источника и в сторону клиента\) и IGMP в сторону клиента. _Помимо прочих базовых настроек, конечно \(IP, IGP\)._ 10 11 С этого момента вы можете расчехлить GNS и собирать лабораторию. Достаточно подробно о том, как собрать стенд для мультикаста я рассказал в этой [статье](https://linkmeup.ru/blog/126.html). 12 13 ```text 14 R1(config)#ip multicast-routing 15 R1(config)#int fa0/0 16 R1(config-if)#ip pim sparse-mode 17 R1(config-if)#int fa1/0 18 R1(config-if)#ip pim sparse-mode 19 ``` 20 21 > Cisco тут как обычно отличается своим особенным подходом: при активации PIM на интерфейсе, автоматически активируется и IGMP. На всех интерфейсах, где активирован PIM, работает и IGMP. 22 > В то же время у других производителей два разных протокола включаются двумя разными командами: отдельно IGMP, отдельно PIM. 23 > Простим Cisco эту странность? Вместе со всеми остальными? 24 > 25 > Плюс, возможно, потребуется настроить адрес RP \(**ip pim rp-address 172.16.0.1**, например\). Об этом позже, пока примите как данность и смиритесь. 26 27 Проверим текущее состояние таблицы мультикастовой маршрутизации для группы 224.2.2.4: 28 29  30 31 После того, как на источнике вы запустите вещание, надо проверить таблицу ещё раз. 32 33  34 35 Давайте разберём этот немногословный вывод. 36 37 Запись вида **\(\*, 224.2.2.4\)** называется **\(\*, G\)**, /читается _старкомаджи_/ и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик. 38 Если список нисходящих интерфейсов \(OIL\) пуст — **Null**, значит нет получателей — а мы их пока не запускали. 39 40 Запись **\(172.16.0.5, 224.2.2.4\)** называется **\(S, G\)**, /читается _эскомаджи_/ и говорит о том, что известен источник. В нашем случае источник с адресом 172.16.0.5 вещает трафик для группы 224.2.2.4. Мультикастовый трафик приходит на интерфейс FE0/1 — это **восходящий** \(**Upstream**\) интерфейс. 41 42 Итак, нет клиентов. Трафик от источника доходит до маршрутизатора и на этом его жизнь кончается. Давайте добавим теперь получателя — настроим приём мультикаста на ПК. 43 ПК отсылает IGMP Report, маршрутизатор понимает, что появились клиенты и обновляет таблицу мультикастовой маршрутизации. 44 Теперь она выглядит так: 45 46  47 48 Появился и нисходящий интерфейс: FE0/0, что вполне ожидаемо. Причём он появился как в \(\*, G\), так и в \(S, G\). Список нисходящих интерфейсов называется \*OIL — Outgoing Interface List_. 49 50 Добавим ещё одного клиента на интерфейс FE1/0: 51 52  53 54 Если читать вывод дословно, то имеем: 55 \(\*, G\): Есть получатели мультикастового трафика для группы 224.2.2.4 за интерфейсами FE0/0, FE1/0. Причём совершенно неважно, кто отправитель, о чём и говорит знак «\*». 56 57 \(S, G\): Когда мультикастовый трафик с адресом назначения 224.2.2.4 от источника 172.16.0.5 приходит на интерфейс FE0/1, его копии нужно отправить в FE0/0 и FE1/0. 58 59 Но это был очень простой пример — один маршрутизатор сразу знает и адрес источника и где находятся получатели. Фактически даже деревьев тут никаких нет — разве что вырожденное. Но это помогло нам разобраться с тем, как взаимодействуют PIM и IGMP. 60