Для какой ситуации существует механизм querier опрашивателя

Оптимизация передачи multicast-трафика в локальной сети с помощью IGMP snooping

Всем привет! Сегодня хотел бы затронуть тему передачи multicast-трафика в локальной корпоративной сети, а именно работу технологии IGMP snooping на коммутаторах. Так получилось, что за последнюю неделю ко мне обратилось несколько человек с вопросами по этой технологии. И я решил подготовить небольшую статью с описанием данной технологии. Но в процессе подготовки, выяснилось, что краткостью здесь не отделаешься, так как есть о чём написать. Кому интересен вопрос работы IGMP snooping, добро пожаловать под кат.

Достаточно часто мы не особенно задумываемся над тем, как передаётся multicast-трафик в пределах нашего L2-домена корпоративной сети. Напомню, multicast-трафик (он же «многоадресный трафик») предназначен для передачи данных определённой группе устройств. По умолчанию коммутатор передаёт multicast-трафик как broadcast (широковещательный), т.е. на все порты без исключения. Это обусловлено тем, что в пакете multicast в качестве MAC-адреса получателя использует специально сформированный адрес, никому не принадлежащий в сети. Если multicast-трафика не много, это не создаёт больших проблем и чаще всего администратор не предпринимает никаких мер по оптимизации его передачи. Если же такого трафика много или хочется просто «причесать» сеть, встаёт задача ограничить его распространение. Тут на помощь приходят различные технологии оптимизации передачи multicast-трафика на канальном уровне (IGMP snooping, CGMP и пр.). Наиболее распространённой и мультивендорной является технология IGMP snooping. IGMP snooping на многих устройствах включён по умолчанию. Например, это справедливо для коммутаторов Cisco. Но как часто бывает, счастье из коробки получить удаётся далеко не во всех случаях. Включённый IGMP snooping не всегда даёт предполагаемый результат и multicast-трафик в ряде случаев почему-то продолжает литься из всех портов. Давайте попробуем со всем этим разобраться.

Начать стоит с аббревиатуры IGMP. Всем нам известно, что когда в сети появляется устройство, которое хочет получать определённый multicast-трафик, это устройство сообщает о своём желании по средствам протокола IGMP (Internet Group Management Protocol). На многих устройствах по умолчанию используется IGMP версии 2. Обмен сообщениями данного протокола в самом простом случае выглядит следующим образом:

Устройство, когда решает получать multicast-трафик, отправляет свой запрос в сообщении IGMP Membership Report (далее IGMP Report). В нём указывается, что именно устройство желает получать. Адрес запрашиваемой multicast-группы указывается в качестве IP-адреса назначения. Данное сообщение в первую очередь предназначается ближайшему маршрутизатору. Ведь именно он отвечает за передачу трафика между локальным сегментом и остальной сетью.

Report Suppression

Если у нас в сети много получателей multicast-трафика, их ответы на IGMP General Query могут породить достаточно большое количество сообщений IGMP Report. Так как маршрутизатору достаточно получить всего одно такое сообщение, используется следующий механизм оптимизации. В сообщении IGMP General Query указывается максимальное время (Maximum Response Time — MRT), в течении которого маршрутизатор ждёт ответа. Клиент, получив IGMP General Query, выбирает произвольное значение таймера от 0 до MRT. Как только выбранное время таймера истекает, клиент отправляет сообщение IGMP Report. Это происходит только в том случае, если до этого клиент не получил IGMP Report от какого-то другого получателя.

Так как все сообщения IGMP проходят через коммутатор, он мог бы их анализировать, чтобы определить за какими портами находятся те или иные получатели multicast-трафика. И далее на основании этой информации передавать трафик только туда, куда это необходимо. Собственно, именно этим и занимается технология IGMP snooping.

Реализация IGMP snooping у разных производителей сетевого оборудования в каких-то нюансах может отличается. Но в целом схема работы похожа. Предлагаю в общих чертах рассмотреть её работу на примере коммутаторов Cisco. Далее мы посмотрим на весь процесс более детально:

Первое, что делает коммутатор, определяет, где находится маршрутизатор(ы). Для этого он слушает наличие в сети сообщений IGMP General Query, PIM, DVMRP и пр.

Далее коммутатор отправляет в сторону маршрутизатора IGMP Report, содержащий такую же информацию, как была получена от устройства.

Если такие получатели есть, больше коммутатор ничего не делает. Посылать сообщение IGMP Leave в сторону маршрутизатора смысла никакого нет.

Источник и получатель потокового multicast-трафика будет реализован через VLC media player (далее VLC проигрыватель).

IGMP snooping отключён, источник multicast-трафика находится в другой сети

Начнём с того, что рассмотрим передачу multicast-трафика без использования технологии IGMP snooping. Для начала отключим IGMP snooping. Как мы помним, на оборудовании Cisco он включён по умолчанию:

cbs-sw-2960x#conf t cbs-sw-2960x(config)#no ip igmp snooping cbs-sw-2960x(config)#exit cbs-sw-2960x# cbs-sw-2960x#sh ip igmp snooping Global IGMP Snooping configuration: ------------------------------------------- IGMP snooping : Disabled 

На роутере включаем маршрутизацию multicast-трафика и запускаем протокол маршрутизации multicast-трафика PIM (Protocol Independent Multicast) в режиме dense-mode. Нам не принципиален режим. Главное, чтобы маршрутизатор запустил IGMP на нужном нам интерфейсе и обеспечил передачу через себя multicast-трафика.

На источнике включаем VLC проигрыватель в режиме передачи потокового трафика. Это и будет наш источник multicast-трафика. В качестве адреса группы будем использовать 230.255.0.1. Передавать по сети будем только аудио. В качестве передаваемой композиции выбираем Adele Rolling in the Deep. Момент важный, так как именно она лучше всего передаётся по сети (факт проверен).

Чуточку тернистый путь уже в самом начале

С проблемой маршрутизации multicast-трафика я столкнулся уже при настройке первого компьютера, который должен был стать источником. В качестве подопытных я взял несколько ноутбуков, которыми пользуются инженеры компании.

Я установил VLC проигрыватель, настроил передачу потокового аудио и… ничего не увидел в дампе Wireshark на внешнем интерфейсе данного компьютера.

Заглянув в таблицу маршрутизации, я увидел два маршрута в сеть 224.0.0.0/4 с абсолютно одинаковой метрикой 276. Причем первым в списке шёл маршрут через некий интерфейс с адресом 169.254.55.11. И только вторым шёл маршрут через нормальный интерфейс данного компьютера (172.17.16.11).

В связи с этим все multicast-пакеты заворачивались на непонятный интерфейс. Заглянув в сетевые подключения, я обнаружил активированный интерфейс Cisco Systems VPN Adapter. Данный интерфейс появляется в системе, когда на компьютер устанавливается Cisco VPN client. Это достаточно старое решение для подключения по VPN и, видимо, его просто забыли удалить.

Отключение данного интерфейса решило проблему.

Далее на клиенте включаем VLC проигрыватель в режиме получения потокового аудио для группы 230.255.0.1.

И снова проблемы.

Когда я перешёл к настройке получателя потокового аудио, у меня сходу не заработало. Тут я нисколечко не удивился, а сразу полез в таблицу маршрутизации. На этом компьютере симптомы были идентичные: multicast-пакеты не появлялись на проводном интерфейсе.

И опять я обнаружил два маршрута в сеть 224.0.0.0/4 с абсолютно одинаковой метрикой 306. Но теперь первым был стандартный маршрут loopback интерфейса. Обычно метрика маршрута для этого интерфейса больше, метрики через другие интересы. По какой-то причине в моём случае они были равны.

Как оказалось, кто-то на данном ноутбуке в ручном режиме выставил метрику проводного интерфейса.

После того, как я установил галочку «Автоматическое изучение метрики», multicast-пакеты стали нормально уходить с данного компьютера.

В итоге на обоих компьютерах была проблема с маршрутизацией multicast-трафика, но в каждом случае источник проблемы был свой.

Сразу видим, как пошёл multicast-трафик. В нашем случае это пакеты потокового вещания, на транспортном уровне использующее протокол UDP.

Не забываем о TTL

Стоит заметить, что по умолчанию VLC проигрыватель устанавливает TTL для пакетов потокового вещания равным 1. Это значит, что такие пакеты не могут быть переданы в другую сеть, т.е. маршрутизироваться. Поэтому для нашего случая в настройках VLC значение TTL было выставлено больше единицы.

По дампу видно, что получатель запросил трафик (отправил сообщение IGMP Report) и маршрутизатор сразу же начал транслировать в сеть нужный multicast-трафик. Сообщений IGMP Report целых два. Видимо, второе VLC проигрыватель отправляет для верности. Одного сообщения вполне было бы достаточно.

Проверяем таблицу маршрутизации multicast-трафика на маршрутизаторе. В ней появились записи, свидетельствующие о том, откуда и куда передаётся трафик:

cbs-rtr-4000#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, G - Received BGP C-Mroute, g - Sent BGP C-Mroute, N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, Q - Received BGP S-A Route, q - Sent BGP S-A Route, V - RD & Vector, v - Vector, p - PIM Joins on route, x - VxLAN group Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 230.255.0.1), 00:29:20/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/0/1.115, Forward/Dense, 00:29:20/stopped (172.17.16.11, 230.255.0.1), 00:03:27/00:02:32, flags: T Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/0/1.115, Forward/Dense, 00:03:27/stopped 

Видим, что источником multicast-трафика является хост 172.17.16.11. При этом получатели находятся за интерфейсом GigabitEthernet0/0/1.115. Маршрутизатор запоминает только, куда слать трафик. Базу самих получателей он не ведёт (такая возможность есть в IGMPv3).

Давайте посмотрим на дамп трафика на клиенте, отфильтрованный по сообщениям IGMP:

Нажимаем кнопку «Воспроизведение» в проигрывателе VLC и наш компьютер запрашивает получение multicast-трафика для группы 230.255.0.1, отправив сообщение IGMP Report. Как мы уже отметили, отправляет он два таких сообщения.

Получив данное сообщение, маршрутизатор начинает трансляцию multicast-трафика (потокового аудио) в локальную сеть и на нашем клиенте мы начинаем слышать передаваемую по сети музыку.

Дамп трафика с компьютера в том же сегменте сети, но не участвующего в получении потокового трафика:

Точно также будут обстоять дела со всеми IGMP сообщениями. Они будут рассылаться на все порты без исключения. Что является абсолютно логичным, так как во всех этих сообщениях в качестве адреса получателя используется multicast-адрес.

IGMP snooping включён, источник multicast-трафика находится в другой сети

Теперь перейдём к рассмотрению ситуации, когда на коммутаторе включен IGMP snooping. Запускаем IGMP snooping на Cisco 2960x:

cbs-sw-2960x(config)#ip igmp snooping cbs-sw-2960x(config)#exit cbs-sw-2960x# cbs-sw-2960x#sh ip igmp snooping Global IGMP Snooping configuration: ------------------------------------------- IGMP snooping : Enabled 

Для начала проверяем, удалось ли коммутатору обнаружить маршрутизатор. Как мы помним, это первый пункт в списке задач IGMP snooping:

cbs-sw-2960x#sh ip igmp snooping mrouter Vlan ports ---- ----- 115 Gi1/0/19(dynamic) 

Видим, что за портом Gi1/0/19 спрятался наш маршрутизатор. Как мы ранее обсуждали, коммутатор подсматривает за наличием в сети пакетов, свидетельствующих о присутствии маршрутизатора. В случае 2960x коммутатор ждёт пакеты IGMP General Query, PIM или DVMRP.

Sep 17:39:39 MSK: IGMPSN: router: PIMV2 Hello packet received in 115 Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19 Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19 Sep 17:39:39 MSK: IGMPQR: vlan_id 115: querier/multicast router detected on port Gi1/0/19 in Disabled state Sep 17:39:39 MSK: IGMPSN: router: Created router port on Vlan 115, port Gi1/0/19 Sep 17:39:39 MSK: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 115. Sep 17:39:39 MSK: IGMPSN: Adding router port Gi1/0/19 to all GCEs in Vlan 115 Sep 17:39:39 MSK: IGMPSN: added rport Gi1/0/19 on Vlan 115 Sep 17:39:39 MSK: IGMPSN: router: Learning port: Gi1/0/19 as rport on Vlan 115 

Коммутатор увидел сообщение PIMV2 Hello от маршрутизатора на порту Gi1/0/19 и добавил себе об этом информацию.

Снова запускаем нашу трансляцию потокового аудио и смотрим, что мы имеем на маршрутизаторе:

(*, 230.255.0.1), 00:00:12/stopped, RP 0.0.0.0, flags: DP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (172.17.16.11, 230.255.0.1), 00:00:12/00:02:47, flags: PT Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0 Outgoing interface list: Null 

Появился источник трафика — 172.17.16.11. Получателей пока нет, о чём свидетельствует строка: Outgoing interface list: Null.

Запускаем клиент VLC, нажимаем кнопку «Воспроизведение» и наслаждаемся музыкой. Параллельно смотрим Wireshark, где видим, как идут multicast-пакеты потокового вещания:

Теперь самое интересное. Анализируем сообщения IGMP на стыке получатель-коммутатор и коммутатор-маршрутизатор.

Пройдём по основным шагам:

1. После нажатия кнопки «Воспроизведение» в проигрывателе VLC, наш компьютер запрашивает получение multicast-трафика для группы 230.255.0.1, отправив сообщение IGMP Report.

Прим. Пакеты на получателе

Коммутатор, когда получил сообщение IGMP Report, заносит себе информацию, о том, что за его портом (в нашем случае – это порт GE0/0/15) есть получатель трафика для группы с MAC-адресом 01:00:5e:7f:00:01.

Замечание. Найти запись о данном MAC-адресе на коммутаторе не удастся. Он нигде не фигурирует, в том числе в стандартном выводе «show mac address-table».

2. IGMP Report попадает на маршрутизатор. Если мы заглянем в само сообщение, то увидим, что это оригинальное сообщение от нашего ПК. Коммутатор его просто переслал на порт, куда подключен маршрутизатор:

Прим. Пакеты на маршрутизаторе. Подчёркнутый MAC адрес принадлежит ПК

Если бы на коммутаторе уже был клиент, который получал трафик для группы 230.255.0.1, коммутатор бы просто начал трансляцию трафика через наш порт (GE0/0/15) и больше ничего не предпринимал бы. Это логично, так как у коммутатора уже был бы нужный трафик, который следовало просто завернуть на ещё один порт. Но в нашем примере, данный клиент первый.

3. Маршрутизатор начинает трансляцию потокового трафика в локальную сеть.

Прим. Пакеты на маршрутизаторе

4. Коммутатор в свою очередь передаёт трафик на порт GE0/0/15, куда подключен наш ПК.

Прим. Пакеты на получателе

5. Компьютер отправляет повторный запрос на получение multicast-трафика (специфика реализации поддержки IGMP на VLC проигрывателе).

Прим. Пакеты на получателе

Так как оно не очень вписывается в нормальное поведение, коммутатор данное сообщение сбрасывает. В связи с этим на маршрутизаторе мы его уже не видим.

6. Периодически маршрутизатор рассылает сообщения IGMP General Query.

7. Коммутатор транслирует их без изменений на все свои порты.

Прим. Пакеты на получателе. Подчёркнутый MAC адрес принадлежит маршрутизатору

8. Компьютер откликается на данное сообщение, отправляя в обратную сторону IGMP Report для группы 230.255.0.1.

9. Коммутатор пересылает первое полученное сообщение IGMP Report (а в данном примере сообщение от нашего компьютера и является первым) в сторону маршрутизатора.

Прим. Пакеты на маршрутизаторе. Подчёркнутый MAC адрес принадлежит получателю

Коммутатор, получив первое сообщение IGMP Report пересылает его только в сторону маршрутизатора. Другим получателям данное сообщение не передаётся, в отличии от обычной схемы работы без IGMP snooping. Т.е. механизм Report Suppression нарушается. Таким образом каждый получатель вынужден будет отправить своё сообщение IGMP Report в ответ на IGMP General Query. Получив такие сообщения, коммутатор актуализирует свою базу соответствия получателей multicast-трафика и внутренних портов.

10. Наживаем кнопку «Остановить» в проигрывателе VLC. Компьютер отправляет сообщение IGMP Leave, о том, что он больше не хочет получать multicast-трафик для группы 230.255.0.1.

Прим. Пакеты на получателе

11. На компьютер приходит сообщение IGMP Group-Specific Query для группы 230.255.0.1. Если мы его развернём, мы увидим, что данное сообщение отправил коммутатор:

Прим. Пакеты на получателе. Подчёркнутый MAC адрес принадлежит коммутатору. При этом IP-адрес отправителя коммутатор использовал 172.17.15.1 (это адрес маршрутизатора)

Т.е. коммутатор, получив сообщение IGMP Leave, выполняет проверку, нет ли других устройств за данным портом, желающих получать multicast-трафика для группы 230.255.0.1.

В сторону маршрутизатора коммутатор ничего не отправляет. Пока коммутатор никак не тревожит маршрутизатор, так как он ещё не уверен, что нужно что-то делать с multicast-трафиком.

12. Ровно через одну секунду коммутатор отправляет повторное сообщение IGMP Group-Specific Query.

13. И ещё через одну секунду, не получив в ответ ни одного IGMP Report, прекращает передавать multicast-трафик на данный порт.

Прим. Пакеты на получателе. Трансляция прекратилась в 13:32:58:58

14. После того, как коммутатор понял, что за портом, где было принято сообщение IGMP Leave, больше нет получателей, он проверяет, а есть ли у него получатели за другими портами. Для этого он смотрит у себя в таблице MAC-адресов наличие записей для MAC-адреса 01:00:5e:7f:00:01 (как мы помним, это MAC-адрес группы 230.255.0.1). Если бы к данному коммутатору были подключены другие получатели, коммутатор на этом бы остановился и продолжил передавать multicast-трафик. Но в нашем случае, других получателей нет. Поэтому он отправляет маршрутизатору сообщение IGMP Leave.

Прим. Пакеты на маршрутизаторе. Подчёркнутый MAC адрес принадлежит коммутатору

15. Получив сообщение IGMP Leave, маршрутизатор, начинает проверку наличия других получателей трафика. Он же не знает, что коммутатор уже сам всё проверил. Маршрутизатор отправляет сообщение IGMP Group-Specific Query для группы 230.255.0.1.

16. Это сообщение коммутатор транслирует на все свои порты. В том числе на порт, куда подключён наш компьютер. Как видно из дампа теперь данное сообщение отправлено маршрутизатором:

Прим. Пакеты на получателе. Подчёркнутый MAC адрес принадлежит маршрутизатору

17. Через одну секунду после отправки первого сообщения маршрутизатор отправляет повторное сообщение IGMP Group-Specific Query.

18. И ещё через одну секунду, не получив в ответ ни одного IGMP Report (что ожидаемо, так как мы уже знаем, что коммутатору до этого никто не откликнулся), маршрутизатор прекращает передавать потоковый трафик в данный сегмент локальной сети.

Прим. Пакеты на маршрутизаторе. Трансляция прекратилась в 13:33:00:65

19. Маршрутизатор продолжает раз в минуту рассылать сообщение IGMP General Query.

20. Коммутатор в свою очередь транслирует его на все свои порты.

Итоговый дамп с устройств

Я специально отфильтровал дампы таким образом, чтобы было точно видно, в какой момент начинается трансляция трафика, а в какой завершается. Большую часть UDP пакетов я убрал для большей наглядности.

Дамп на получателе (получатель-коммутатор):

Дамп на маршрутизаторе (коммутатор-маршрутизатор):

Резюмируя, можно сказать следующее. Коммутатор перехватывает все сообщения IGMP от клиентов. Анализирует их. И в зависимости от ситуации пересылает эти сообщения на маршрутизатор или же удаляет. Так же коммутатор сам участвует в процессе создания IGMP сообщений. Когда последний клиент решает прекратить получать multicast-трафик, мы имеем две проверки наличия получателей. Первую выполняет коммутатор, а вторую – маршрутизатор. Во всей этой схеме маршрутизатор ведёт себя абсолютно также, как в случае, когда у нас на коммутаторе нет IGMP snooping. Т.е. маршрутизатор никак не догадывается о наличии коммутатора с включенной технологией IGMP snooping.

Давайте ещё посмотрим на дамп трафика компьютера, который не участвует в получении потокового трафика, но находится в той же локальной сети.

Прим. Подчёркнутый MAC адрес принадлежит маршрутизатору

Из дампа видно, что данный компьютер за всё время получил только два вида сообщений и ни одного multicast-пакета потокового вещания:

1. Сообщение IGMP Group-Specific Query, которое отправил маршрутизатор, когда в сети больше не осталось ни одного получателя multicast-трафика.
2. Сообщение IGMP General Query, которое периодически рассылает маршрутизатор.

Во-вторых, уменьшает количество IGMP сообщений в сторону маршрутизатора. Фактически маршрутизатор узнаёт только о присутствии первого и об отключении последнего получателей multicast-трафика. Подключение и отключение остальных получателей полностью регулируется коммутатором, что является логичным.

В-третьих, существенно уменьшает количество IGMP сообщений, которые попадают на все порты коммутатора, не вовлечённые в передачу multicast-трафика. Как мы помним, в случае отсутствия IGMP snooping все пакеты IGMP без исключения рассылаются на все порты.

Осталось посмотреть, что мы увидим на самом коммутаторе:

cbs-sw-2960x#sh ip igmp snooping groups Vlan Group Type Version Port List ----------------------------------------------------------------------- 115 230.255.0.1 igmp v2 Gi1/0/14, Gi1/0/15, Gi1/0/19 

Мы видим, что получатели multicast-трафика для группы 230.255.0.1 находятся за портами Gi1/0/14, Gi1/0/15 и Gi1/0/19. За портом Gi1/0/19 находится сам маршрутизатор. Коммутатор автоматически добавил порт с маршрутизатором. Для получения более детальной информации на коммутаторе можно запустить отладчик debug ip igmp snooping.

IGMP snooping включён, источник multicast-трафика находится в той же сети

И так, когда источник находится где-то в другом месте нашей сети, всё прекрасно работает. Но давайте теперь перенесём наш источник multicast-трафика в тот же сегмент сети, где находятся получатели. Ситуация вполне себе житейская. Например, мы имеем систему приёма телевизионных каналов со спутника и несколько STB-приставок. Или же используем VLC проигрыватель или, например, камеры-видео наблюдения, передающие данные сразу нескольким потребителям, находящимся в том же сегменте сети. Ещё один кейс – передача multicast-трафика между контроллером беспроводной сети и точками доступа. Как в этой ситуации отработает IGMP snooping?

Для чистоты эксперимента на маршрутизаторе отключаем PIM, так как теперь нам не нужно больше маршрутизировать multicast-трафик.

Рассматривать вариант с отключённым IGMP snooping смысла нет: весь трафик будет просто передаваться как широковещательный. Поэтому проверяем, что IGMP snooping включён, и запускаем потоковую трансляцию на нашем импровизированном сервере. На клиенте пока VLC проигрыватель не запускаем (т.е. клиент никаких IGMP сообщений не отправляет).

Видим, что на наш компьютер, выполняющий роль клиента, стал сразу же сыпаться multicast-трафик:

Странно, ведь IGMP snooping включен. Посмотрим, как изменится ситуация, если на клиенте запустить VLC проигрыватель и подключиться к группе 230.255.0.1 (именно её мы продолжаем использовать для трансляции нашего потокового аудио). Нажимаем кнопку «Воспроизведение», видим, как наш компьютер отправил сообщение IGMP Report, начинаем слышать музыку. Понятное дело, что multicast-трафик на компьютер приходил всё время. Просто теперь клиент VLC стал его обрабатывать:

Сообщения IGMPv3

Я думаю, Вы уже заметили, что в дампе фигурируют пакеты IGMPv3. При этом ранее мы везде видели только IGMPv2. Обусловлено это тем, что на оборудовании Cisco по умолчанию используется IGMPv2. А в ОС Windows (7, 8, 10) используется IGMPv3. Во всех предыдущих случаях на маршрутизаторе был включён IGMP и клиенты, получая периодически от маршрутизатора сообщения IGMPv2 General Query, автоматически переключились также на вторую версию протокола. В текущем сценарии на маршрутизаторе отключён IGMP, поэтому клиент использует третью версию протокола.

Теперь нужно убедиться, продолжает ли коммутатор рассылать multicast-трафик через все остальные порты. Или наконец заработал IGMP snooping и коммутатор стал слать трафик только туда, где есть клиенты. Но нет. Ничего не поменялось. На другом компьютере, который никак не участвует в нашем эксперименте, мы видим multicast-трафик (сам дамп приводить не буду, multicast-пакеты мы уже хорошо знаем в лицо). Стоит отметить, в дампе мы не обнаружим ни одного сообщения IGMP Report, которые ранее отправил наш клиент, и которые, по идее, должны были также рассылаться на все порты. Значит IGMP snooping на коммутаторе всё-таки частично работает: как минимум коммутатор перехватывает IGMP сообщения.

Впору заглянуть в консоль коммутатора. Информация о получателях для различных групп пуста:

cbs-sw-2960x#sh ip igmp snooping groups cbs-sw-2960x# 

Запустив отладчик (debug), видим:

Sep 13:54:01 MSK: IGMPSN: Received IGMPv3 Report for group v3 received on Vlan 115, port Gi1/0/15 Sep 13:54:01 MSK: IGMPSN: Rx IGMPv3 Report on Gi1/0/15 when Querier is not IGMPv3, Vlan 115. 

Из этих сообщений единственно, что становится ясным, — коммутатор получил сообщение IGMPv3 Report, при этом версия некого Querier не советует IGMPv3 (о Querier поговорим немного позже). А что мы получим, если переключим IGMPv3 на нашем компьютере на IGMPv2 (данная процедура делается через реестр). Вдруг заведётся.

Проверяем. Поведение коммутатора осталось таким же, но вот сообщения в отладчике поменялись:

Sep 15:07:08 MSK: IGMPSN: Received IGMPv2 Report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15 Sep 15:07:08 MSK: IGMPSN: group: Received IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15 Sep 15:07:08 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/15 Sep 15:07:08 MSK: IGMPSN: group: Skip client info adding - ip 172.17.15.11, port_id Gi1/0/17, on vlan 115 Sep 15:07:08 MSK: IGMPSN: No mroute detected: Drop IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15 

Из этих сообщений становится понятно, что коммутатор игнорирует информацию в сообщениях IGMP (и более того их удаляет), так как у него нет «mroute». И тут мы начинаем вспоминать, что первым пунктом программы IGMP snooping является определение, где находится маршрутизатор. И не важно собираемся ли мы маршрутизировать multicast-трафик или нет. В предыдущем разделе мы проверяли вывод команды «show ip igmp snooping mrouter». Там был указан номер порта, куда был подключен наш маршрутизатор, рассылающий сообщения IGMP General Query. Так вот, коммутатору с IGMP snooping обязательно нужно знать, где находится маршрутизатор multicast-трафика. Порт на коммутаторе, куда будет подключен такой маршрутизатор, как раз и получает название mrouter-порт (multicast router port). Без mrouter-порта IGMP snooping работать нормально не будет. А у нас такого порта нет, так как мы отключили на маршрутизаторе IGMP.

Включаем обратно IGMP на маршрутизаторе (для этого активируем на интерфейсе протокол PIM). Проверяем, что на коммутаторе появился mrouter-порт:

cbs-sw-2960x#sh ip igmp snooping mrouter Vlan ports ---- ----- 115 Gi1/0/19(dynamic) 

И снова запускаем наш источник потокового аудио. Пока VLC проигрыватель не включаем. Проверяем, рассылается ли трафик по всем портам коммутатора. Нет. Единственно, куда коммутатор теперь транслирует multicast-трафик – это через mrouter-порт. Делается он это всегда, так как маршрутизатор в нормальных условиях никогда не отсылает сообщений IGMP Report для групп, multicast-трафик которых он будет маршрутизировать. А значит коммутатор никак не сможет узнать, нужен или нет маршрутизатору тот или иной multicast-трафик.

Замечание. Когда мы рассматривали схемы, где источник multicast-трафика находился в другой сети, multicast пакеты попадали на маршрутизатор от источника ровно по той же причине, которую мы описывали. Маршрутизатор не отправлял в сеть с источником multicast-трафика сообщения IGMP Report для группы 230.255.0.1.

Как только мы запускаем VLC проигрыватель, коммутатор сразу начинает передавать multicast-трафик на данный компьютер. В целом схема взаимодействия между клиентом-коммутатором-маршрутизатором в рамках протокола IGMP не отличается от того, что мы рассматривали ранее, когда источник находился в другой сети. Но есть небольшой нюанс.

Взглянем на дамп, полученный с маршрутизатора (часть UDP-пакетов было отфильтровано для большей наглядности):

Из дампа видно, следующее:

• На маршрутизатор, как и ожидалось, постоянно поступает multicast-трафик.
• Маршрутизатор продолжает отрабатывать логику работы IGMP для группы 230.255.0.1. На сообщение IGMP Leave, он отсылает сообщения IGMP Specific-Group Query.
• Но в отличии от предыдущего случая, когда маршрутизатор выясняет, что больше нет получателей для группы 230.255.0.1, маршрутизатор не может прекратить передавать multicast-трафик. Его инициатором в данном сегменте сети является совсем другое устройство (это хост с адресом 172.17.15.12).

И так, мы поняли, что для корректной работы IGMP snooping на коммутаторе Cisco нам нужен маршрутизатор. Но можно ли получить на коммутаторе mrouter-порт без запуска протокола IGMP на маршрутизаторе? Да и вообще, можно ли обойтись совсем без маршрутизатора? Да, для это существует несколько способов. Первый вариант – статически прописать mrouter-порт. Смотреть он может, куда угодно. Главное, чтобы был. Безусловно, это не самый элегантный способ. Второй вариант – запустить на коммутаторе режим IGMP Querier. В этом режиме коммутатор вообразит себя multicast-маршрутизатором и начнёт рассылать и обрабатывать сообщения IGMP. При этом в качестве mrouter-порта будет указывать сам на себя:

cbs-sw-2960x#sh ip igmp snooping mrouter Vlan ports ---- ----- 115 Switch 

Наш коммутатор будет отсылать в том числе от своего имени сообщения IGMP General Query. Это большой плюс. Остальные коммутаторы в сети, получив его, решат, что наш коммутатор – это multicast-маршрутизатор, а значит у них появятся свои mrouter-порты. Таким образом, IGMP snooping будет работать корректно во всей сети.

Замечание. Коммутатор весь multicast-трафик всегда передаёт через mrouter-порт. Если такого трафика будет много, он легко может забить транковые порты между коммутаторами, которые и окажутся в конечном итоге mrouter-портами. Поэтому к дизайну сети стоит подходить аккуратно, правильно выбирая расположение устройств, которые будут выполнять роль IGMP Querier.

Подытожу. Для того чтобы на коммутаторах Cisco корректно работал IGMP snooping, необходимо, чтобы на нём был хотя бы один mrouter-порт. Если на коммутаторе нет ни одного mrouter-порта:

Коммутатор с включённым IGMP snooping (а он, как мы помним, включён по умолчанию) передаёт multicast-трафик, сгенерированный в данном сегменте сети, как широковещательный. При этом не важно есть или нету у нас хотя бы один получатель.

IGMP snooping и 224.0.0.X

Когда я первый раз познакомился с IGMP snooping, первое о чём я подумал, можно ли ограничить с помощью данной технологии multicast-трафик, адресованный группам из диапазона 224.0.0.0-255 (224.0.0.0/24).

Как мы помним, данный диапазон адресов используется только для локальных коммуникаций внутри одного сегмента сети (широковещательного домена). Многие IP-адреса из него зарезервированы под различные служебные протоколы. Например, адрес 224.0.0.5 используется протоколом OSPF, а адрес 224.0.0.10 – протоколом EIGRP. Но так как эти адреса используются сугубо для локально взаимодействия никакие механизмы присоединения/отключения к этим группам не используются. Т.е. для этих адресов не будет сообщений IGMP Report. Поэтому все они полностью исключены из процесса IGMP snooping и коммутатор Cisco будет рассылать трафик для данных групп на все порты.

Бывают и исключения

Бывают исключения в плане отсылки сообщений IGMP Report. Например, мой компьютер пытается присоединиться к группам 224.0.0.251 и 224.0.0.252. Это сервисы Multicast DNS и Link-Local Multicast Name Resolution, которые в своей работе используют механизм присоединения к группе.

Sep 17:27:36 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15 Sep 17:27:36 MSK: IGMPSN: 224.0.0.251 is a Reserved MCAST address Sep 17:27:36 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15 with invalid group address Sep 17:27:37 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15 Sep 17:27:37 MSK: IGMPSN: 224.0.0.252 is a Reserved MCAST address Sep 17:27:37 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15 with invalid group address 

Правда коммутатор Cisco считает такое поведение не достойным для сервисов, которые используют адреса, начинающееся с «224.0.0.». В связи с чем игнорирует сообщение IGMP Report.

В заключение

Мы разобрали общие аспекты работы IGMP snooping на примере оборудования Cisco. Причём рассмотренное поведение является поведением «по умолчанию». За кадром остались вопросы, связанные с тюнингом различных параметров данной технологии (например, тайм аутов между посылками сообщений IGMP Group-Specific Query), изменением схемы работы коммутатора в случае получения от клиентов сообщений IGMP Leave (например, мы знаем, что за портом точно нет других устройств), взаимодействием с протоколом STP (точнее, что делать, когда происходит перестройка топологии сети) и пр. Обычно данные элементы являются уже более вендоро зависимыми и хорошо описаны в документации.

Если мы посмотрим на коммутаторы других производителей, на многих из них мы также найдём технологию IGMP snooping. Конечно же, будут отличия в синтаксисе настройки, каких-то терминах (например, вместо mrouter-порта у многих используется просто router-порт), различных дополнениях и параметрах, которые можно подкрутить. Но по большей части общая схема работы IGMP snooping будет сходной с тем, что мы рассмотрели.

• Блог компании CBS
• Системное администрирование
• Cisco
• Сетевые технологии

Сети для самых маленьких. часть 9.2. мультикаст. протокол igmp

Например, настройка IPTV на роутере D-Link DIR-300 и подобных моделей сводится к установке одной лишь галочки в пункте «Enable multicast streams»:

Лично для меня, настройка IP телевидения по проводному соединению сводилась к нескольким шагам (на примере роутера Asus 520GU):

• Необходимо зайти в раздел WAN, предварительно активировав DHCP
• перейти во вкладку Общее
• найти пункт Выбор порта IPTV STB — выбираем из списка тот порт, к которому будет подключена IPTV-приставка.
• Нажимаем Применить и все.

Это пример наиболее простых способов настройки IPTV.

Настройка IPTV на роутере ASUS

Теперь я опишу 2 способа настройки IPTV через роутер RT-G32 B

Внимание! Описанную инструкцию по настройке IPTV можно использовать и на других моделях роутеров Asus для наглядности, и не только Asus в практическом и теоретическом применении. 1 способ

Перейдите в раздел ЛВС —> Маршрут и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”. Сохраняем – “Применить”

1 способ. Перейдите в раздел ЛВС —> Маршрут и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”. Сохраняем – “Применить”.

В данном случае в локальную сеть будет транслироваться multicast поток для VLC плеера без изменений.

Преимущества данного способа:
1. Никаких дополнительных настроек VLC плеера производить не надо.

Недостатки:
1. Возможность подключения компьютера для просмотра IPTV только через витую пару (Ethernet-кабель).
2. Падение скорости интернет соединения на других компьютерах в локальной сети, в момент воспроизведения IPTV.
3. Сильная нагрузка на маршрутизатор.
4. Излишний multicast трафик внутри сети.

2 способ. Необходимо настроить функцию ”IPTV UDP Multicast to HTTP Proxy”. Перейдите в раздел ЛВС —> Маршруты и поставьте галочку “Включить многоадресную маршрутизацию” – “Yes”, и в поле ”IPTV UDP
Multicast to HTTP Proxy” выберите произвольный порт. Например, 2323. Сохраните изменения – “Применить”.

Преимущества данного способа:

1. Возможность смотреть IPTV на компьютере по WiFi соединению.
2. Остальные компьютеры в локальной сети не испытывают падения скорости при интернет-соединения.
3. Роутер не перегружается.
4. Multicast трафик во внутреннюю сеть не транслируется, а VLC плеер захватывает поток видео с wifi роутера.

1. Необходимо изменить плейлист для используемого мультимедиа плеера.

Правки, которые необходимо внести в VLC плей-листом при использовании функции «IPTV UDP Multicast to HTTP Proxy»:

Откройте плей-лист в текстовом редакторе.
Найдите строки вида — udp://@239.23.0.200:1234/ и удалите часть, которую я выделил жирным. Изменять необходимо все.
На место удаленной части udp://@ вставьте — http://192.168.1.1:2323/udp/, где 192.168.1.1 — IP адрес вашего wi-fi роутера, а 2323 – прокси порт, который вы выбрали.
Результатом будет строка — http://192.168.1.1:2323/udp/239.23.0.200:1234/

Использование IPTV приставки:

Активация опцииChoose WAN Bridge Port и выбор одного или несколькихLAN портов роутерадля подключенияIPTVприставки.

Использование для просмотра IPTV ПК (проводное и беспроводное подключение)

Активация опцииEnable multicast routing», которая отключит фильтрацию multicastтрафика и станет активным перенаправление его во внутреннюю подсеть наLANинтерфейсы в случае необходимости. Не забывайте разрешить активность программы для просмотра IPTV в файрволе.

Как и для чего включают IGMP?

У пользователей, пожелавших воспользоваться преимуществами IPTV через свой домашний маршрутизатор, иногда возникают сложности с подключением к интерактивному телевидению.

Некоторые модемы несовместимы для работы с этой технологией, а на отдельных просто требуется включить через web-конфигуратор igmp. Интерактивное ТВ функционирует посредством широковещательной передачи данных.

Если организовать просмотр такого телевидения с использованием маршрутизатора либо модема ADSL, то ко всем устройствам, соединенным с ними, будет осуществляться передача данных.

Для этого требуется поддержка роутером IGMP, однако старые версии устройств часто ее не имеют, либо у них не хватает аппаратной мощности, то есть просто зависают из-за перегрузки.

Процедура включения

На современном оборудовании обычно, чтобы просматривать IPTV, ручное подключение этого протокола осуществлять нет необходимости.

Достаточно произвести апгрейт программного обеспечения и после этого функция активируется в автоматическом режиме. Главное, чтобы роутер поддерживал этот протокол.

Чтобы включить поддержку IPTV вручную, следует запустить web-конфигуратор роутера и осуществить небольшую настройку. Например, на приборах ASUS потребуется исполнить следующие действия:

1. Войти во вкладку «Локальная сеть»;
2. Далее перейти в закладку «IPTV»;
3. Затем для активации многоадресной маршрутизации в графе «IGMP Proxy» вызвать выпадающее меню и выбрать «Включить»;
4. Аналогичную процедуру выполнить для пункта ниже, отвечающего за отслеживание: «IGMP Snooping»;
5. Завершив активацию параметров, клацнуть виртуальную клавишу в интерфейсе роутера «Применить» (иначе введенные корректировки не будут сохранены);
6. Готово.

Примечание: На старых моделях маршрутизаторов пункт под номером «4» выполнять не требуется, так как в них достаточно активировать графу «IGMP прокси» и все заработает.

Что такое многоадресная рассылка?

Многоадресная рассылка, или Multicast — это способ передачи данных по сетям IPv4, который обеспечивает доставку единого потока информации одновременно тысячам частных или корпоративных пользователей. Работа в режиме Multicast предусматривает, что отправитель передает пакеты данных выбранной группе адресатов. При этом допускается подключение этих адресатов к разным подсетям.

Протокол IPv4 предполагает организацию отправки пакетов тремя способами:

• адресация определенному устройству;
• широковещательная рассылка;
• многоадресная рассылка.

В первом случае трафик передается только на конкретный компьютер. Этот способ позволяет пользователю выполнять значительную часть действий в интернете. Однако передача конкретному устройству потокового видео или других массивных объемов данных приведет к повышенной нагрузке на сеть. Поэтому для решения таких задач целесообразно использовать способы, позволяющие единожды передавать потоки, которые смогут получать многочисленные пользователи.

Широковещательная рассылка предполагает передачу данным от отправителя все подключенным к конкретной сети хостам. Сегодня этот метод используется редко, поскольку создает помехи для передачи других видов трафика.

Оптимальным решением становится многоадресная рассылка, при которой пакеты доставляются каждому подключенному к сети с определенным адресом хосту. Это дает значительную экономию полосы пропускания и снижает нагрузку на сеть.

При многоадресной рассылке сообщения отправляются на адрес группы Multicast, не имеющей географических и физических ограничений — то есть узлы могут быть расположены в разных странах и регионах. Главное, чтобы они были подписаны на рассылку (присоединены к группе). Для присоединения к группе Multicast и используется протокол IGMP.

Настройка Cisco 2911 и Cisco 3560

Настройка Cisco 3560

Создаем Vlan 5
vlan 5
name VLAN5
exit

Настроим ip адрес VLAN5
int vlan 5
ip address 192.168.5.1 255.255.255.0
exit

Сравните два сетевых адреса. Если они не совпадают, устройства находятся в разных сегментах сети. Пример. Маски подсети обоих устройств: будут ли эти два устройства связываться напрямую или они будут использовать маршрутизатор? Поэтому устройства находятся в одной локальной сети и будут обмениваться данными друг с другом. Адреса из этих групп не используются в Интернете.

Они зарезервированы для следующих целей.

• Это набор сетевых адресов и нулей для адреса устройства.
• Включите сетевые адреса и единицы адреса устройства.

Частные адресные пространства также включены в эту область. При уменьшении 8-разрядного раздела создается подсеть адреса.

Добавим порт gi1/1 в VLAN5
int gi0/1

выставляем режим доступа
switchport mode access
switchport access vlan 5
no shutdown
do wr mem

Настройка Cisco 2911

Так как у нас локальной маршрутизацией трафика занимается ядро то тут sub интерфейсов создавать не нужно. Настроим порт роутера gi0/0 на vlan5.

enable
conf t
Настроим ip адрес VLAN5
int gi0/0
ip address 192.168.5.251 255.255.255.0
no shutdown
do wr mem

Комбинация сети и подсети называется расширенным сетевым префиксом. При добавлении битов в маску сети диапазон адресов разделяется на несколько меньших диапазонов. Количество хостов в подсети — это класс 2. Это обычно не так, потому что не все комбинации разрешены.

Для 4 подсетей необходимо определить количество битов, которые будут использоваться для подсети. Для 2 бит возможные подсети 2 — недостаточно, причем 3 бита равны 6 — поэтому будут использоваться три бита для подсети. Это удовлетворяет установленному максимальному количеству компьютеров.

Querier

Рассмотрим чуть более сложный случай:

В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.

Выборы происходят довольно просто и интуитивно понятно.

Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.

1. Активировали IGMP на интерфейсах.
2. Сначала по умолчанию каждый из них считает себя Querier.
3. Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
4. General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
5. Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
6. Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
7. Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
8. Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier’ом становится другой маршрутизатор, у которого IP меньше.

Тот редкий случай, когда меряются, у кого меньше.

Ещё пара слов о других версиях IGMP

Версия 1 отличается по сути только тем, что в ней нет сообщения Leave. Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.

Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый Source Specific Multicast

В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.

Содержимое IGMP Membership Report в IGMPv3

Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру 2, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.

Multicast forwarding

• unicast forwarding основан на dest ip.
• multicast forwarding основан на source ip.

• RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (источник или RP). Если сходится — RPF done, не сходится — RPF fail. Префиксы, прошедшие RPF-check хранятся в inet.1.
• Multicast трафик никогда не форвардится в сторону источника.

show multicast rpf

Routing tables

inet.0 — дефолтная таблица для проведения RPF-check . Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.

inet.1 — записываются результаты RPF-check, форвардинг производится на основании этой таблицы.

>show route table inet.1 inet.1: 238 destinations, 238 routes (238 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 224.0.0.0/4 *[Multicast/180] 74w2d 13:10:11 MultiResolve 224.0.0.0/24 *[Multicast/180] 74w2d 13:10:11 MultiDiscard 232.0.0.0/8 *[Multicast/180] 74w2d 13:10:11 MultiResolve 232.192.1.1,10.200.86.1/32*[PIM/105] 6w0d 08:32:53 Multicast (IPv4) Composite 232.192.1.1,10.200.86.2/32*[PIM/105] 8w3d 15:25:48 Multicast (IPv4) Composite 232.192.1.2,10.200.86.1/32*[PIM/105] 6w0d 08:32:52 Multicast (IPv4) Composite 232.192.1.2,10.200.86.2/32*[PIM/105] 8w3d 15:25:52 Multicast (IPv4) Composite 232.192.1.4,10.200.86.1/32*[PIM/105] 23:11:56 Multicast (IPv4) Composite .

232.192.1.1.10.200.86.1/64 (1 entry, 1 announced) *PIM Preference: 105 Next hop type: Multicast (IPv4) Composite, Next hop index: 1048796 Address: 0xa4edf30 Next-hop reference count: 28 State: Local AS: 100 Age: 6w0d 8:35:30 Validation State: unverified Task: PIM.master Announcement bits (1): 0-KRT AS path: I AS path: Recorded

inet.2 — если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check.

MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.

Чтобы ISIS стал заполнять inet.2 — нужно включить

set protocols isis topologies ipv4-multicast

Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью RIB-groups.

IMPORT-RIB: для протокола PIM import-rib копирует маршруты из протокола в указанную таблицу. То есть указываем только одну таблицу. Указанная таблица будет использоваться для RPF.

Для остальных протоколов первая таблица <> — откуда копируются маршруты, вторая — куда копируются.

set routing-options rib-groups mcast-table import-rib inet.2 set protocols pim rib-group inet mcast-table

set routing-options rib-groups import-rib to-inet2 set routing-options rib-groups import-policy static *по желанию/необходимости set protocols ospf rib-groups to-inet.2 set routing-options interface-routes rib-group inet to-inet2

В обычном понимании: если задаём export-ribs, то при этом указывается только одна таблица, куда будут скопированы маршруты. Но для PIM не работает export-ribs.

Настройка телевизоров со Смарт ТВ

Если ваш роутер поддерживает опцию IPTV, тогда можно провести настройку телевидения по беспроводной сети, следуя такой инструкции:

• Откройте телевизионное меню;
• Зайдите в раздел «Сеть»;
• Перейдите в подменю «Настройка сети SMART TV»;
• Поиск роутера должен запуститься автоматически;
• Выберите из списка имя своего маршрутизатора;
• Введите пароль безопасности для WiFi-соединения;
• Сохраните все настройки.

Телевизионную приставку можно подключить к роутеру и посредством LAN-кабеля.

Ну и последняя инструкция в нашей статье будет посвящена настройке интернет-телевидения (IPTV) на компьютере. Сегодня смотреть цифровое телевещание можно не только на телеприёмнике, но и на ноутбуке, стационарном ПК и даже планшетах и смартфонах.

Чтобы можно было пользоваться сервисом IPTV, вам понадобится скачать специальный IP–TV-плеер или смотреть телевидение посредством онлайн-доступа.

Вы можете скачать в интернете любой программный плеер для IPTV, например, VLC, IPTV-Player, PC-Player или любой другой. Для мобильных устройств есть свои специальные приложения. Особенных настроек в нём делать не потребуется, единственное, что нужно будет указать, это список каналов. В некоторых моделях потребуется указать свой регион.

IPTV предоставляет множество удобных функций, которые помогают улучшить восприятие телевизора и позволяют пользователям самостоятельно выбирать контент для просмотра. Вот эти факторы и сделали его чрезвычайно популярным сегодня.

• https://mediapure.ru/setevye-ustrojstva/wi-fi-oborudovanie/nastrojka-iptv-cherez-router-iptv-po-vozduxu-i-provodnoe-podklyuchenie/
• https://www.smart-soft.ru/blog/mezhsetevoj_protokol_upravlenija_gruppami_igmp/
• https://prosmarttv.ru/iptv/nastrojka-na-routere.html

ICMP — Internet Control Message Protocol

ICMP — это протокол управления сообщениями в Интернете, используется IP-устройствами, чтобы информировать другие IP-устройства о действиях и ошибках в сети. Без TCP IP не является надежным протоколом: он не отправляет подтверждения, не проверяет данные на ошибки (только контрольную сумму заголовка) и не повторяет передачу.

Об ошибках можно информировать с помощью сообщений ICMP. Сообщения ICMP используются для отправки ответной реакции о состоянии сети. Например, маршрутизатор, не найдя подходящего элемента для сети в таблице маршрутизации, отправляет сообщение ICMP «недостижимый пункт назначения». Найдя лучший путь, маршрутизатор может послать сообщение ICMP «перенаправить».

ICMP не располагается поверх IP, как могло бы показаться, напротив, сообщения ICMP отправляются внутри заголовка IP. Следовательно, протокол ICMP должен быть реализован модулем IP стека сети. Эти поля сообщения ICMP ставятся в начале заголовка IP:

Длина	Поле	Описание
1 байт	Тип	В этом поле задается тип сообщения ICMP. Например, значение типа, равное 3, означает, что пункт назначения недостижим, 11 определяет, что время истекло, 12 — обнаружены некорректные параметры заголовка.
1 байт	Код	Код предоставляет дополнительную информацию о типе сообщения. Для типа «недостижимый пункт назначения» код указывает, что именно недостижимо: сеть (0), хост (1), протокол (2) или порт (3).
2 байта	Контрольная сумма	Контрольная сумма сообщения ICMP.
4 байта	Зависит от типа	В последних 4 байтах заголовка ICMP может предоставляться дополнительная информация, зависящая от типа сообщения.

Команда ping

Утилита ping командной строки Windows отправляет ICMP-сообщение «эхо» целевому устройству, указанному именем хоста или IP-адресом в команде ping. Если устройство достижимо, обратно отправляется сообщение «отклик на эхо».

Эта команда очень полезна, когда нужно проверить, можно ли достичь данного устройства, есть ли проблемы на пути к нему (команда PING -t продолжает посылать сообщения, пока не будет остановлена) и как быстро сообщение доходит до устройства.

Если вы не можете достичь какого-либо хоста с использованием команды ping, то это не означает, что его нельзя достичь с помощью других протоколов. ICMP-сообщения «эхо»могут блокироваться маршрутизаторами или брандмауэрами.

На следующем снимке экрана показан вывод, создаваемый командой ping для хоста с IP-адресом 212.183.100.193. По умолчанию ping посылает узлу назначения четыре ICMP-сообщения и ждет откликов. На снимке показано, что были отправлены 32 байта данных и время, при этом не было получено отклика, поэтому все 4 пакета были потеряны:

Какой роутер выбрать для «Ростелекома»

Подключение и настройка роутера от «Ростелекома»

Наличие перечня «вай фай» роутеров на сайте «Ростелекома» еще не означает, что другие устройства для подключения не подойдут. Выбор маршрутизатора лучше осуществлять самому пользователю.

Чтобы правильно подобрать роутер, соответствующий потребностям, в первую очередь убедитесь, что устройство поддерживает тип подключения, используемый «Ростелекомом» в том или ином населенном пункте.

Под технологию ADSL

Если абоненту предоставляется доступ к интернету по телефонной линии, необходимо знать тип стандарта подключения. В случае с роутером «Ростелекомом» возможны два варианта:

Узнать, какой именно стандарт применяется, можно из договора с провайдером. Если данные не прописаны, уточните детали, обратившись в службу поддержки «Ростелекома».

Остальные требования к роутеру не столь принципиальные. Желательно, чтобы устройство имело минимум четыре порта.

Для данного типа соединения компания рекомендует роутеры D-Link, «Интеркросс» и Sagemcom.

При ЕТТН-соединении

По мере постепенного перехода на использование оптоволоконных кабелей, все больше растет популярность ЕТТН-подключения к интернету. По сравнению с ADSL и GPON оно выгодно тем, что не имеет ограничений по подбору сетевого оборудования.

Эта технология предполагает, что кабель от провайдера будет подключен непосредственно к сетевой плате компьютера абонента. Но такая схема неудобна, т. к. в настоящее время пользователи хотят иметь собственную домашнюю сеть с возможностью подключения по Wi-Fi. Решить эту проблему помогает использование роутера.

Чтобы построить домашнюю сеть при подключении ЕТТН, подойдет любой маршрутизатор, имеющий четыре порта. В порт WAN подсоединяется кабель от провайдера, в порт LAN 1 — компьютер, а остальные используются для подключения телевидения от «Ростелекома», сетевого принтера или других устройств.

Также обратите внимание на скорость интернет-подключения согласно выбранному тарифу. В зависимости от этого подберите маршрутизатор

Как правило, современные устройства делаются под стандарт 802 11n с поддержкой предыдущих стандартов, что обеспечивает скорость до 450 Мбит/с.

Подключив роутер, пользователю останется только настроить соединение РРРоЕ согласно документации устройства и параметрам, выданным «Ростелекомом».

Для GPON

При использовании технологии GPON выбора у пользователя, увы, нет.

В этом случае для соединения с провайдером применяется специальный оптический терминал, прошиваемый под конкретного поставщика услуг интернета. Поэтому абонентам «Ростелекома» приобрести его можно только в этой компании.

Использование WiFi-роутера в паре с оптическим терминалом практикуется для расширения существующей сети. При этом подойти могут модели, рекомендуемые для ADSL- и ЕТТН-подключений. Но при их выборе нелишним будет посетить сайт провайдера и посмотреть, какой роутер лучше, какие именно модели подходят для данного региона.

Прогрессивное применение Multicast

Технологию Multicast крайне целесообразно применять в случаях, когда источники видеосигнала (будь то видеокамера или видеосервер) находятся на значительном удалении от приемников данного сигнала. Это могут быть разные терминалы аэропорта, разные здания промышленного назначения с единым постом видеонаблюдения. Или обратная ситуация, когда приемники видеосигнала (например, АРМ видеонаблюдения) размещаются на значительном удалении от источников и не имеют широкополосного канала связи.

Бесспорная выгода использования технологии обусловлена тем, что у источника сигнала (видеокамеры или видеосервера) отсутствует необходимость генерировать количество одинаковых потоков в соответствии с числом приемников, которые одновременно желают получать видеоданные. Технология позволяет экономить не только пропускную способность интерфейсов источников, но и их вычислительные возможности. Экономия вычислительных возможностей – крайне актуальная тема для видеосерверов, поскольку на эти устройства возложен ряд серьезных задач, таких как прием, дешифрование, шифрование, распределение, дополнительное сжатие и преобразование, запись потоков видеоданных, реализация алгоритмов видеоаналитики.

Технология Multicast часто находит применение для рассылки видеосерверами потоков видеоданных рабочим местам и иным приемникам. Однако более прогрессивное применение технологии – использование Multicast-потоков видеокамеры (многие камеры имеют поддержку этой функциональности) для получения видеосигнала приемниками. Это позволяет экономить вычислительные мощности серверов, так как видеопотоки транслируются на приемники непосредственно в обход сервера, а сервер осуществляет запись (со всеми смежными функциями).

Проблемы передачи multicast

IP multicast является одной из ключевых технологий при построении сетей для систем безопасности. При этом необходимость использования multicast накладывает дополнительные требования к архитектуре сети в целом, поскольку используются специальные протоколы, а оборудование должно обладать соответствующей функциональностью. Рассмотрим далее особенности, которые следует учитывать при использовании IP multicast в сетях Ethernet, и какие проблемы могут быть сними связаны.

АдресацияПо аналогии с IP-протоколом, кадры Ethernet определяются как multicast по МАС-адресу назначения, указанному в заголовке

Причем МАС-адрес формируется в соответствии с используемым IP-адресом multicast, и здесь важно помнить, что из IP-адреса в МАС-адрес копируется только часть битов. В результате каждому МАС-адресу формата multicast соответствуют 32 адреса IP multicast, и при использовании нескольких потоков с разными IP-адресами и единым для них МАС-адресом может возникнуть ситуация, когда сетевое оборудование, принимающее хотя бы один из потоков, будет вынуждено также производить обработку пакетов и для остальных потоков, которые к нему попадают

Особенно внимательно нужно проследить, чтобы выбранные IP-адреса не попадали под единый МАС-адрес, соответствующий диапазону локальных сетевых IP multicast-адресов -224.0.0.0/24 (соответствующие адреса лежат в диапазонах: 224.128.0.0/24, 225.0.0.0/24, 225.1 28.0.0/24, 226.0.0.0/24, 226.1 28.0.0/24 и т.д.). Этот диапазон зарезервирован под различные сетевые сервисы и протоколы маршрутизации, поэтому на многих моделях коммутаторов для таких адресов не действуют правила IGMP snooping. В этом случае потоки будут распространяться широковещательным способом, что может привести к перегрузке каналов и системных ресурсов оборудования.

IGMP snoopingПрактически во всех современных моделях управляемых коммутаторов Ethernet есть возможность контролировать распространение потоков multicast с помощью функции отслеживания пакетов IGMP (IGMP snooping). В этом случае коммутатор отслеживает передаваемые хостами и маршрутизаторами внутри сети пакеты IGMP и отправляет потоки для каждой из групп multicast только в те порты, через которые были получены соответствующие запросы IGMP report от хостов или пакеты IGMP query от маршрутизаторов.

Данная функция является обязательной при использовании сервисов, передающих потоки multicast с большой скоростью — к таким можно отнести, например, видеонаблюдение. В противном случае коммутаторы Ethernet будут отправлять пакеты по умолчанию через все порты, расходуя пропускную способность каналов.

Но с использованием IGMP snooping также может быть связана распространенная проблема. Предположим, что источники и приемники потоков multicast находятся в одном широковещательном домене (VLAN) и соединены через цепочку коммутаторов с включенным IGMP snooping. Если в этом домене отсутствует маршрутизатор, который рассылал бы пакеты IGMP query, то на портах, через которые коммутаторы соединены между собой, передача потоков будет блокироваться. Для решения этой проблемы на коммутаторах существует настройка IGMP querier, которая позволяет коммутаторам самим рассылать пакеты IGMP query и таким образом разблокировать порты для передачи потоков (рис. 2).

(Optional) Configuring the Router-Alert Option

Context

By default, the switch does not check whether IGMP messages contain the Router-Alert option and sends all the IGMP messages to the upper-layer routing protocol. To improve device performance, reduce transmission cost, and enhance protocol security, configure the switch to discard IGMP messages without the Router-Alert option.

By default, the switch sends IGMP messages with the Router-Alert option.

Procedure

1. Run system-view The system view is displayed.
2. Run vlanvlan-id The VLAN view is displayed.
3. Run igmp-snooping require-router-alert The device is configured to check whether IGMP messages contain the Router-Alert option.
4. Run igmp-snooping send-router-alert The device is configured to send only IGMP messages with the Router-Alert option.

IGMP Snooping Proxy

IGMP Snooping Proxy– промежуточный сервер в сети, представляющий собой набор программ. На роутере прокси настраивают, чтобы подключатьIPTV. Для этого надо открыть меню роутера на экране компьютера и выбрать необходимые параметры.

Если функция IGMP Snooping proxy отключена, запросы в виртуальной локальной компьютерной сети и ответные сообщения не доходят до адресата и затопляются. Прокси не дает сообщениям переполнять полосы пропускания: он реагирует на сетевые запросы, сокращая их число, принимает отчеты от других сетевых устройств. IGMP Snooping не позволяет отчётам переходить от клиента к клиенту. Отчеты посылаются только выше по сети, к маршрутизаторам.

Настройка IP-TV на маршрутизаторах

Роутеры модели D-Link

Для часто покупаемой модели роутера марки D-LINK DIR 615 необходимо провести всего лишь 2 действия:

Для реже покупаемых моделей, например, для моделей DIR-320 NRU или DIR-300 NRU, нужно:

Роутеры модели Asus

Роутеры фирмы ASUS примечательны тем, что настройка IPTV может производиться 2-умя способами.

В моделях роутеров ASUS, чаще подключение делают так:

1. зайти в меню и перейти по вкладке ЛВС -> Маршрут.
2. откроется окошечко, в котором необходимо отметить пункт включения многоадресной маршрутизации. Не забудьте сохранить настройку, щёлкнув по кнопке «Применить».

Фото: Открытие меню и переход ЛВС -маршрут

Такой способ достаточно лёгкий, ведь отпадает необходимость тратить лишнее время на настройку дополнительных установленных программ, однако, при этом всю работоспособность всей сети берёт на себя роутер. Помимо этого, подключение выполняется только при условии присутствии «Ethernet-кабель», а при пользовании этой программы на других устройствах через локальную сеть скорость интернет соединения заметно снижается и становится меньше.

Роутеры модели Zyxel

Настройка iptv через роутер
ZYXEL KEENETIC START
делается следующим образом:

1. зайти в меню WAN и найти поле «Choose Bridge Port(s)»;
2. в нём указываем тот LAN -порт, к которому будет подключаться TV — приставка.

Фото: настройка IPTV на модемах ZyXEL

Для некоторых моделей в конце настройки нужно выбрать опцию «Choose IPTV STB PORT» и установить там количество подключаемых LAN портов.

Роутеры модели TP-Link

Данный модельный ряд также нуждается в прошивке программы до последней доступной версии. Однако, после прошивки, в автоматическом режиме запускается Multicast, и сам настраивает программу. Возможными причинами неполадок может служить старый плейлист, не обновлённый медиа проигрыватель, блокировка со стороны антивируса, и неправильное подключение кабеля. Если ошибка не в этом, а подключение не произведено, то блокировка идёт со стороны интернет провайдера.

Заключение: что лучше выбрать

Оборудование, рекомендованное провайдером, подходит для настроек сети и подлежит обслуживанию оператору. Если у вас возникнет проблема, специалист технической поддержки даст консультацию по телефону или настроит устройство сам, подключившись к маршрутизатору удаленно. В случае покупки стороннего не рекомендованного устройства, скорее всего, устранять проблемы с оборудованием придется самостоятельно.

Если вас не устраивает, какой роутер предоставляет Ростелеком по умолчанию, изучите характеристики устройства, которое предложил провайдер, и подберите маршрутизатор с аналогичными настройками у стороннего продавца.

Общее понимание Multicast

Unicast — одноадресная рассылка — один отправитель, один получатель. (Пример: запрос HTTP-странички у WEB-сервера).

Broadcast — широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (Пример: ARP-запрос).

Multicast — многоадресная рассылка — один отправитель, много получателей. (Пример: IPTV).

Anycast — одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (Пример: Anycast DNS).

Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.

Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.

Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.

Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.

Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.

Сформулируем два основных принципа мультикастовой рассылки:

1. Отправитель посылает только одну копию трафика, независимо от количества получателей.
2. Трафик получают только те, кто действительно заинтересован в нём.

В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.

Пример I

Начнём с самого простого случая:
На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4. При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене.

Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.

Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?».

Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.

Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.
Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком. Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.

Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.

В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.

Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.

Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?

Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».

То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.

Пример II

Добавим в схему коммутатор и ещё несколько клиентов:
Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.

Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.

В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.

Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).

Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать.

Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов

Адрес	Значение
224.0.0.0	Не используется
224.0.0.1	Все узлы данного сегмента
224.0.0.2	Все мультикастовые узлы данного сегмента
224.0.0.4	Данный адрес выделялся для покойного протокола DVMRP
224.0.0.5	Все OSPF-маршрутизаторы сегмента
224.0.0.6	Все DR маршрутизаторы сегмента
224.0.0.9	Все RIPv2-маршрутизаторы сегмента
224.0.0.10	Все EIGRP-маршрутизаторы сегмента
224.0.0.13	Все PIM-маршрутизаторы сегмента
224.0.0.18	Все VRRP-маршрутизаторы сегмента
224.0.0.19-21	Все IS-IS-маршрутизаторы сегмента
224.0.0.22	Все IGMP-маршрутизаторы сегмента (v2 и v3)
224.0.0.102	Все HSRPv2/GLBP-маршрутизаторы сегмента
224.0.0.107	PTPv2 — Precision Time Protocol
224.0.0.251	mDNS
224.0.0.252	LLMNR
224.0.0.253	Teredo
224.0.1.1	NTP
224.0.1.39	Cisco Auto-RP-Announce
224.0.1.40	Cisco Auto-RP-Discovery
224.0.1.41	H.323 Gatekeeper
224.0.1.129-132	PTPv1/PTPv2
239.255.255.250	SSDP

Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.

Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.

Вот, собственно, самые базисные вещи касательно мультикаста.

Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.

Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.

Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.

Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.

С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.

IGMP

Снова вернёмся к дампу. Видите вот этот верхний пакет, после которого полился мультикастовый поток?
Это сообщение протокола IGMP, которое отправил клиент, когда мы на нём нажали Play. Именно так он сообщает о том, что хочет получать трафик для группы 224.2.2.4.

IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора.

В IPv6 используется MLD (Multicast Listener Discovery) вместо IGMP. Принцип работы у них абсолютно одинаковый, поэтому далее везде вы смело можете менять IGMP на MLD, а IP на IPv6.

Как же именно работает IGMP?

Пожалуй, начать нужно с того, что версий у протокола сейчас три: IGMPv1, IGMPv2, IGMPv3. Наиболее используемая — вторая, первая уже практически забыта, поэтому про неё говорить не будем, третья очень похожа на вторую.

Акцентируемся пока на второй, как на самой показательной, и рассмотрим все события от подключения клиента к группе до его выхода из неё.

Клиент будет также запрашивать группу 224.2.2.4 через проигрыватель VLC.

Роль IGMP очень проста: если клиентов нет — передавать мультикастовый трафик в сегмент не надо. Если появился клиент, он уведомляет маршрутизаторы с помощью IGMP о том, что хочет получать трафик.

Для того, чтобы понять, как всё происходит, возьмём такую сеть:
Предположим, что маршрутизатор уже настроен на получение и обработку мультикастового трафика.

1. Как только мы запустили приложение на клиенте и задали группу 224.2.2.4, в сеть будет отправлен пакет IGMP Membership Report — узел «рапортует» о том, что хочет получать трафик этой группы.
В IGMPv2 Report отправляется на адрес желаемой группы, и параллельно он же указывается в самом пакете. Данные сообщения должны жить только в пределах своего сегмента и не пересылаться никуда маршрутизаторами, поэтому и TTL у них 1.

Часто в литературе вы можете встретить упоминание о IGMP Join. Не пугайтесь — это альтернативное название для IGMP Membership Report.

2. Маршрутизатор получает IGMP-Report и, понимая, что за данным интерфейсом теперь есть клиенты, заносит информацию в свои таблицы
Это вывод информации по IGMP. Первая группа запрошена клиентом. Третья и четвёртая — это служебные группы протокола SSDP, встроенного в Windows. Вторая — специальная группа, которая всегда присутствует на маршрутизаторах Cisco — она используется для протокола Auto-RP, который по умолчанию активирован на маршрутизаторах. Интерфейс FE0/0 становится нисходящим для трафика группы 224.2.2.4 — в него нужно будет отправлять полученный трафик. Наряду с обычной юникастовой таблицей маршрутизации существует ещё и мультикастовая:
О наличии клиентов говорит первая запись (*, 224.2.2.4). А запись (172.16.0.5, 224.2.2.4) означает, что маршрутизатор знает об источнике мультикастового потока для этой группы. Из вывода видно, что трафик для группы 224.2.2.4 приходит через FE0/1, а передавать его надо на порт FE0/0. Интерфейсы, в которые нужно передавать трафик, входят в список нисходящих интерфейсов — OIL — Outbound Interface List. Более подробно вывод команды show ip mroute мы разберём позже. Выше на дампе вы видите, что как только клиент отправил IGMP-Report, сразу после него полетели UDP — это видеопоток.

3. Клиент начал получать трафик. Теперь маршрутизатор должен иногда проверять, что получатели до сих пор у него есть, чтобы зазря не вещать, если вдруг клиентов не осталось. Для этого он периодически отправляет во все свои нисходящие интерфейсы запрос IGMP Query. *Дамп отфильтрован по IGMP*.
По умолчанию это происходит каждые 60 секунд. TTL таких пакетов тоже равен 1. Они отправляются на адрес 224.0.0.1 — все узлы в этом сегменте — без указания конкретной группы. Такие сообщений Query называются General Query — общие. Таким образом маршрутизатор спрашивает: «Ребят, а кто и что ещё хочет получать?». Получив IGMP General Query, любой хост, который слушает любую группу, должен отправить IGMP Report, как он это делал при подключении. В Report, естественно, должен быть указан адрес интересующей его группы. *Дамп отфильтрован по IGMP*.
Если в ответ на Query на маршрутизатор пришёл хотя бы один Report для группы, значит есть ещё клиенты, он продолжает вещать в тот интерфейс, откуда пришёл этот Report, трафик этой самой группы. Если на 3 подряд Query не было с интерфейса ответа для какой-то группы, маршрутизатор удаляет этот интерфейс из своей таблицы мультикастовой маршрутизации для данной группы — перестаёт туда посылать трафик. По своей инициативе клиент обычно посылает Report только при подключении, потом — просто отвечает на Query от маршрутизатора.

Интересная деталь в поведении клиента: получив Query, он не торопится сразу же ответить Report’ом. Узел берёт тайм-аут длиной от 0 до Max Response Time, который указан в пришедшем Query:
При отладке или в дампе, кстати, можно видеть, что между получением различных Report может пройти несколько секунд. Сделано это для того, чтобы сотни клиентов все скопом не наводнили сеть своими пакетам Report, получив General Query. Более того, только один клиент обычно отправляет Report. Дело в том, что Report отсылается на адрес группы, а следовательно доходит и до всех клиентов. Получив Report от другого клиента для этой же группы, узел не будет отправлять свой. Логика простая: маршрутизатор и так уже получил этот самый Report и знает, что клиенты есть, больше ему не надо. Этот механизм называется Report Suppression. Далее в статье мы расскажем о том, почему этот механизм на деле очень редко реально работает.

4. Так продолжается веками, пока клиент не захочет выйти из группы (например, выключит плеер/телевизор). В этом случае он отправляет IGMP Leave на адрес группы.
Маршрутизатор получает его и по идее должен отключить. Но он ведь не может отключить одного конкретного клиента — маршрутизатор их не различает — у него просто есть нисходящий интерфейс. А за интерфейсом может быть несколько клиентов. То есть, если маршрутизатор удалит этот интерфейс из своего списка OIL (Outgoing Interface List) для этой группы, видео выключится у всех. Но и не удалять его совсем тоже нельзя — вдруг это был последний клиент — зачем тогда впустую вещать? Если вы посмотрите в дамп, то увидите, что после получения Leave маршрутизатор ещё некоторое время продолжает слать поток. Дело в том, что маршрутизатор в ответ на Leave высылает IGMP Query на адрес группы, для которой этот Leave пришёл в тот интерфейс, откуда он пришёл. Такой пакет называется Group Specific Query. На него отвечают только те клиенты, которые подключены к данной конкретной группе.
Если маршрутизатор получил ответный Report для группы, он продолжает вещать в интерфейс, если не получил — удаляет по истечении таймера. Всего после получения Leave отправляется два Group Specific Query — один обязательный, второй контрольный. *Дамп отфильтрован по IGMP*.
Далее маршрутизатор останавливает поток.

Querier

Рассмотрим чуть более сложный случай:
В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.

Выборы происходят довольно просто и интуитивно понятно.

Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.

• 1) Активировали IGMP на интерфейсах.
• 2) Сначала по умолчанию каждый из них считает себя Querier.
• 3) Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
• 4) General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
• 5) Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
• 6) Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
• 7) Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
• 8) Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier’ом становится другой маршрутизатор, у которого IP меньше.

Тот редкий случай, когда меряются, у кого меньше.

Выборы Querier очень важная процедура в мультикасте, но некоторые коварные производители, не придерживающиеся RFC, могут вставить крепкую палку в колёса. Я сейчас говорю о IGMP Query с адресом источника 0.0.0.0, которые могут генерироваться коммутатором. Такие сообщения не должны участвовать в выборе Querier, но надо быть готовыми ко всему. Вот пример весьма сложной долгоиграющей проблемы.

Ещё пара слов о других версиях IGMP

Версия 1 отличается по сути только тем, что в ней нет сообщения Leave. Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.

Кроме того, не поддерживаются выборы Querier. За избежание дублирования трафика отвечает вышестоящий протокол, например, PIM, о котором мы будем говорить далее.

Версия 3 поддерживает всё то, что поддерживает IGMPv2, но есть и ряд изменений. Во-первых, Report отправляется уже не на адрес группы, а на мультикастовый служебный адрес 224.0.0.22. А адрес запрашиваемой группы указан только внутри пакета. Делается это для упрощения работы IGMP Snooping, о котором мы поговорим дальше.

Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый Source Specific Multicast. В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.
Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру II, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.

Повторим ещё раз

*Дамп отфильтрован по IGMP*.

1. 1. Первым делом маршрутизатор отправил свой IGMP General Query после включения IGMP на его интерфейсе, чтобы узнать, есть ли получатели и заявить о своём желании быть Querier. На тот момент никого не было в этой группе.
2. 2. Далее появился клиент, который захотел получать трафик группы 224.2.2.4 и он отправил свой IGMP Report. После этого пошёл трафик на него, но он отфильтрован из дампа.
3. 3. Потом маршрутизатор решил зачем-то проверить — а нет ли ещё клиентов и отправил IGMP General Query ещё раз, на который клиент вынужден ответить (4).
4. 5. Периодически (раз в минуту) маршрутизатор проверяет, что получатели по-прежнему есть, с помощью IGMP General Query, а узел подтверждает это с помощью IGMP Report.
5. 6. Потом он передумал и отказался от группы, отправив IGMP Leave.
6. 7. Маршрутизатор получил Leave и, желая убедиться, что больше никаких других получателей нет, посылает IGMP Group Specific Query… дважды. И по истечении таймера перестаёт передавать трафик сюда.
7. 8. Однако передавать IGMP Query в сеть он по-прежнему продолжает. Например, на тот случай, если вы плеер не отключали, а просто где-то со связью проблемы. Потом связь восстанавливается, но клиент-то Report не посылает сам по себе. А вот на Query отвечает. Таким образом поток может восстановиться без участия человека.

И ещё раз

IGMP — протокол, с помощью которого маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении.

IGMP Report — посылается клиентом при подключении и в ответ на IGMP Query. Означает, что клиент хочет получать трафик конкретной группы.

IGMP General Query — посылается маршрутизатором периодически, чтобы проверить какие группы сейчас нужны. В качестве адреса получателя указывается 224.0.0.1.

IGMP Group Sepcific Query — посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.

IGMP Leave — посылается клиентом, когда тот хочет покинуть группу.

Querier — если в одном широковещательном сегменте несколько маршрутизаторов, который могут вещать, среди них выбирается один главный — Querier. Он и будет периодически рассылать Query и передавать трафик.

Подробное описание всех терминов IGMP.

Итак, мы разобрались, как клиенты сообщают ближайшему маршрутизатору о своих намерениях. Теперь неплохо было бы передать трафик от источника получателю через большую сеть.

Если вдуматься, то мы стоим перед довольной сложной проблемой — источник только вещает на группу, он ничего не знает о том, где находятся получатели и сколько их.

Получатели и ближайшие к ним маршрутизаторы знают только, что им нужен трафик конкретной группы, но понятия не имеют, где находится источник и какой у него адрес.

Как в такой ситуации доставить трафик?

Существует несколько протоколов маршрутизации мультикастового трафика: DVMRP, MOSPF, CBT — все они по-разному решают такую задачу. Но стандартом де факто стал PIM — Protocol Independent Multicast.

Другие подходы настолько нежизнеспособны, что порой даже их разработчики практически признают это. Вот, например, выдержка из RFC по протоколу CBT:

CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

PIM имеет две версии, которые можно даже назвать двумя различными протоколами в принципе, уж сильно они разные:

• PIM Dense Mode (DM)
• PIM Sparse Mode (SM)

Independent он потому, что не привязан к какому-то конкретному протоколу маршрутизации юникастового трафика, и позже вы увидите почему.

PIM Dense Mode

PIM DM пытается решить проблему доставки мультиакста в лоб. Он заведомо предполагает, что получатели есть везде, во всех уголках сети. Поэтому изначально он наводняет всю сеть мультикастовым трафиком, то есть рассылает его во все порты, кроме того, откуда он пришёл. Если потом оказывается, что где-то он не нужен, то эта ветка «отрезается» с помощью специального сообщения PIM Prune — трафик туда больше не отправляется.

Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст — вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft — маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт.

Как видите, здесь не стоит вопрос определения пути к получателям — трафик достигнет их просто потому, что он везде.

После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT — Shortest Path Tree.

Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в STP, где корнем является источник.

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. 1) Маршрутизатор смотрит на адрес источника мультикастового пакета.
2. 2) Проверяет таблицу маршрутизации, через какой интерфейс доступен адрес источника.
3. 3) Проверяет интерфейс, через который пришёл мультикастовый пакет.
4. 4) Если интерфейсы совпадают — всё отлично, мультикастовый пакет пропускается, если же данные приходят с другого интерфейса — они будут отброшены.

В нашем примере R3 знает, что кратчайший путь до источника лежит через R1 (статический или динамический маршрут). Поэтому мультикастовые пакеты, пришедшие от R1, проходят проверку и принимаются R3, а те, что пришли от R2, отбрасываются.
Такая проверка называется RPF-Check и благодаря ей даже в более сложных сетях петли в MDT не возникнут.

Этот механизм важен нам, потому что он актуален и в PIM-SM и работает там точно также.

Как видите, PIM опирается на таблицу юникастовой маршрутизации, но, во-первых, сам не маршрутизирует трафик, во-вторых, ему не важно, кто и как наполнял таблицу.

Останавливаться здесь и подробно рассматривать работу PIM DM мы не будем — это устаревший протокол с массой недостатков (ну, как RIP).

Однако PIM DM может применяться в некоторых случаях. Например, в совсем небольших сетях, где поток мультикаста небольшой.

PIM Sparse Mode

Совершенно другой подход применяет PIM SM. Несмотря на название (разреженный режим), он с успехом может применяться в любой сети с эффективностью как минимум не хуже, чем у PIM DM. Здесь отказались от идеи безусловного наводнения мультикастом сети. Заинтересованные узлы самостоятельно запрашивают подключение к дереву с помощью сообщений PIM Join. Если маршрутизатор не посылал Join, то и трафик ему отправляться не будет.

Для того, чтобы понять, как работает PIM, начнём с уже знакомой нам простой сети с одним PIM-маршрутизатором:
Из настроек на R1 надо включить возможность маршрутизации мультикаста, PIM SM на двух интерфейсах (в сторону источника и в сторону клиента) и IGMP в сторону клиента. Помимо прочих базовых настроек, конечно (IP, IGP).

С этого момента вы можете расчехлить GNS и собирать лабораторию. Достаточно подробно о том, как собрать стенд для мультикаста я рассказал в этой статье.

R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim sparse-mode

Cisco тут как обычно отличается своим особенным подходом: при активации PIM на интерфейсе, автоматически активируется и IGMP. На всех интерфейсах, где активирован PIM, работает и IGMP.

В то же время у других производителей два разных протокола включаются двумя разными командами: отдельно IGMP, отдельно PIM.

Простим Cisco эту странность? Вместе со всеми остальными?

Плюс, возможно, потребуется настроить адрес RP (ip pim rp-address 172.16.0.1, например). Об этом позже, пока примите как данность и смиритесь.

Проверим текущее состояние таблицы мультикастовой маршрутизации для группы 224.2.2.4:
После того, как на источнике вы запустите вещание, надо проверить таблицу ещё раз.
Давайте разберём этот немногословный вывод.

Запись вида (*, 225.0.1.1) называется (*, G), /читается старкомаджи/ и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик.

Если список нисходящих интерфейсов (OIL) пуст — Null, значит нет получателей — а мы их пока не запускали.

Запись (172.16.0.5, 225.0.1.1) называется (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.

Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной

Предположим, что уже настроены все IP-адреса в соответствии со схемой. На сети запущен IGP для обычной юникастовой маршрутизации.

Клиент1, например, может пинговать Сервер-источник.
Но пока не запущен PIM, IGMP, клиенты не запрашивают каналы.

Итак, момент времени 0.

Включаем мультикастовую маршрутизацию на всех пяти маршрутизаторах:

RX(config)#ip multicast-routing

PIM включается непосредственно на всех интерфейсах всех маршрутизаторов (в том числе на интерфейсе в сторону Сервера-источника и клиентов):

RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode

IGMP, по идее должен включаться на интерфейсах в сторону клиентов, но, как мы уже отметили выше, на оборудовании Cisco он включается автоматически вместе с PIM.

Первое, что делает PIM — устанавливает соседство. Для этого используются сообщения PIM Hello. При активации PIM на интерфейсе с него отправляется PIM Hello на адрес 224.0.0.13 с TTL равным 1. Это означает, что соседями могут быть только маршрутизаторы, находящиеся в одном широковещательном домене.
Как только соседи получили приветствия друг от друга:
Теперь они готовы принимать заявки на мультикастовые группы.

Если мы сейчас запустим в вольер клиентов с одной стороны и включим мультикастовый поток с сервера с другой, то R1 получит поток трафика, а R4 получит IGMP Report при попытке клиента подключиться. В итоге R1 не будет знать ничего о получателях, а R4 об источнике.

Неплохо было бы если бы информация об источнике и о клиентах группы была собрана где-то в одном месте. Но в каком?

Такая точка встречи называется Rendezvous Point — RP. Это центральное понятие PIM SM. Без неё ничего бы не работало. Здесь встречаются источник и получатели. Все PIM-маршрутизаторы должны знать, кто является RP в домене, то есть знать её IP-адрес.

Чтобы построить дерево MDT, в сети выбирается в качестве RP некая центральная точка, которая,

1. отвечает за изучение источника,
2. является точкой притяжения сообщений Join от всех заинтересованных.

Существует два способа задания RP: статический и динамический. Мы рассмотрим оба в этой статье, но начнём со статического, поскольку чего уж проще статики?

Пусть пока R2 будет выполнять роль RP.

Чтобы увеличить надёжность, обычно выбирается адрес Loopback-интерфейса. Поэтому на всех маршрутизаторах выполняется команда:

RX(config)#ip pim rp-address 2.2.2.2

Естественно, этот адрес должен быть доступен по таблице маршрутизации со всех точек.

Ну и поскольку адрес 2.2.2.2 является RP, на интерфейсе Loopback 0 на R2 желательно тоже активировать PIM.

R2(config)#interface Loopback 0 RX(config-if)#ip pim sparse-mode

Сразу после этого R4 узнает об источнике трафика для группы 224.2.2.4:

и даже передаёт трафик:
На интерфейс FE0/1 приходит 362000 б/с, и через интерфейс FE0/0 они передаются.

Всё, что мы сделали:

Включили возможность маршрутизации мультикастового трафика (ip multicast-routing)

Активировали PIM на интерфейсах (ip pim sparse-mode)

Указали адрес RP (ip pim rp-adress X.X.X.X)

Всё, это уже рабочая конфигурация и можно приступать к разбору, ведь за кулисами скрывается гораздо больше, чем видно на сцене.

Разбор полётов

Ну так и как же в итоге всё работает? Как RP узнаёт где источник, где клиенты и обеспечивает связь между ними?

Поскольку всё затевается ради наших любимых клиентов, то, начав с них, рассмотрим в деталях весь процесс.

1. 1) Клиент 1 отправляет IGMP Report для группы 224.2.2.4
2. 2) R4 получает этот запрос, понимает, что есть клиент за интерфейсом FE0/0, добавляет этот интерфейс в OIL и формирует запись (*, G).

Здесь видно восходящий интерфейс FE0/1, но это не значит, что R4 получает трафик для группы 224.2.2.4. Это говорит лишь о том, что единственное место, откуда сейчас он может получать — FE0/1, потому что именно там находится RP. Кстати, здесь же указан и сосед, который прошёл RPF-Check — R2: 10.0.2.24. Ожидаемо.

R4 называется — LHR (Last Hop Router) — последний маршрутизатор на пути мультикастового трафика, если считать от источника. Иными словами — это маршрутизатор, ближайший к получателю. Для Клиента1 — это R4, для Клиента2 — это R5.

3) Поскольку на R4 пока нет мультикастового потока (он его не запрашивал прежде), он формирует сообщение PIM Join и отправляет его в сторону RP (2.2.2.2).
PIM Join отправляется мультикастом на адрес 224.0.0.13. «В сторону RP» означает через интерфейс, который указан в таблице маршрутизации, как outbound для того адреса, который указан внутри пакета. В нашем случае это 2.2.2.2 — адрес RP. Такой Join обозначается ещё как Join (*,G) и говорит: «Не важно, кто источник, мне нужен трафик группы 224.2.2.4». То есть каждый маршрутизатор на пути должен обработать такой Join и при необходимости отправить новый Join в сторону RP. (Важно понимать, что если на маршрутизаторе уже есть эта группа, он не будет отправлять выше Join — он просто добавит интерфейс, с которого пришёл Join, в OIL и начнёт передавать трафик). В нашем случае Join ушёл в FE0/1:

4) R2, получив Join, формирует запись (*, G) и добавляет интерфейс FE0/0 в OIL. Но Join отсылать уже некуда — он сам уже RP, а про источник пока ничего не известно.
Таким образом RP узнаёт о том, где находятся клиенты. Если Клиент 2 тоже захочет получать мультикастовый трафик для той же группы, R5 отправит PIM Join в FE0/1, потому что за ним находится RP, R3, получив его, формирует новый PIM Join и отправляет в FE1/1 — туда, где находится RP. То есть Join путешествует так узел за узлом, пока не доберётся до RP или до другого маршрутизатора, где уже есть клиенты этой группы.
Итак, R2 — наш RP — сейчас знает о том, что за FE0/0 и FE1/0 у него есть получатели для группы 224.2.2.4. Причём неважно, сколько их там — по одному за каждым интерфейсом или по сто — поток трафика всё равно будет один на интерфейс. Если изобразить графически то, что мы получили, то это будет выглядеть так:
Отдалённо напоминает дерево, не так ли? Поэтому оно так и называется — RPT — Rendezvous Point Tree. Это дерево с корнем в RP, а ветви которого простираются до клиентов. Более общий термин, как мы упоминали выше, — MDT — Multicast Distribution Tree — дерево, вдоль которого распространяется мультикастовый поток. Позже вы увидите разницу между MDT и RPT.

5) Теперь врубаем сервер. Как мы уже выше обсуждали, он не волнуется о PIM, RP, IGMP — он просто вещает. А R1 получает этот поток. Его задача — доставить мультикаст до RP. В PIM есть специальный тип сообщений — Register. Он нужен для того, чтобы зарегистрировать источник мультикаста на RP. Итак, R1 получает мультикастовый поток группы 224.2.2.4:

R1 является FHR (First Hop Router) — первый маршрутизатор на пути мультикастового трафика или ближайший к источнику.

6) Далее он инкапсулирует каждый полученный от источника мультикастовый пакет в юникастовый PIM Register и отправляет его прямиком на RP.
Обратите внимание на стек протоколов. Поверх юникастового IP и заголовка PIM идёт изначальный мультикастовый IP, UDP и данные. Теперь, в отличие от всех других, пока известных нам сообщений PIM, в адресе получателя указан 2.2.2.2, а не мультикастовый адрес. Такой пакет доставляется до RP по стандартным правилам юникастовой маршрутизации и несёт в себе изначальный мультикастовый пакет, то есть это… это же туннелирование! Задача № 1Схема и начальная конфигурация.
На сервере 172.16.0.5 работает приложение, которое может передавать пакеты только на широковещательный адрес 255.255.255.255, с портом получателя UDP 10999. Этот трафик надо доставить к клиентам 1 и 2: Клиенту 1 в виде мультикаст трафика с адресом группы 239.9.9.9. А в сегмент клиента 2, в виде широковещательных пакетов на адрес 255.255.255.255. Подробности задачи тут.

7) RP получает PIM Register, распаковывает его и обнаруживает под обёрткой трафик для группы 224.2.2.4. Информацию об этом он сразу заносит в свою таблицу мультикастовой маршрутизации:
Появилась запись (S, G) — (172.16.0.5, 224.2.2.4). Распакованные пакеты RP дальше отправляет в RPT в интерфейсы FE0/0 и FE1/0, по которому трафик доходит до клиентов. В принципе, на этом можно было бы и остановиться. Всё работает — клиенты получают трафик. Но есть две проблемы:

1. Процессы инкапсуляции и декапсуляции — весьма затратные действия для маршрутизаторов. Кроме того, дополнительные заголовки увеличивают размер пакета, и он может просто не пролезть в MTU где-то на промежуточном узле (вспоминаем все проблемы туннелирования).
2. Если вдруг где-то между источником и RP есть ещё получатели для группы, мультикастовому трафику придётся пройти один путь дважды.

Возьмём для примера вот такую топологию:
Трафик в сообщениях Register сначала дойдёт до RP по линии R1-R42-R2, затем чистый мультикаст вернётся по линии R2-R42. Таким образом на линии R42-R2 будет ходить две копии одного трафика, пусть и в противоположных направлениях.

Поэтому лучше от источника до RP тоже передавать чистый мультикаст, а для этого нужно построить дерево — Source Tree.

8) Поэтому RP отправляет на R1 сообщение PIM Join. Но теперь уже в нём указывается для группы адрес не RP, а источника, изученный из сообщения Register. Такое сообщение называется Join (S, G) — Source Specific Join.
Цель у него точно такая же, как у PIM Join (*, G) — построить дерево, только на этот раз от источника до RP. Join (S, G) распространяется также узел за узлом, как обычный Join (*, G). Только Join (*, G) стремится к RP, а Join (S, G) к S — источнику. В качестве адрес получателя также служебный адрес 224.0.0.13 и TTL=1.

Если существуют промежуточные узлы, например, R42, они также формируют запись (S, G) и список нисходящих интерфейсов для данной группы и пересылают Join дальше к источнику.

Путь, по которому прошёл Join от RP до источника, превращается в Source Tree — дерево от источника. Но более распространённое название — SPT — Shortest Path Tree — ведь трафик от источника до RP пойдёт по кратчайшему пути.
9) R1 получив Join (S, G), добавляет интерфейс FE1/0, откуда пакет пришёл, в список нисходящих интерфейсов OIL и начинает туда вещать чистый мультикастовый трафик, незамутнённый инкапсуляцией. Запись (S, G) на R1 уже была, как только он получит первый мультикастовый пакет от Сервера-источник.
По построенному Source Tree мультикаст передаётся RP (и всем промежуточным клиентам, если они есть, например, R42). Но надо иметь ввиду, что сообщения Register передавались всё это время и передаются до сих пор. То есть фактически R1 отправляет две копии трафика сейчас: один — чистый мультикаст по SPT, другой — инкапсулированный в юникастовый Register.

Сначала R1 отправляет мультикаст в Register — пакет 231. Потом R2 (RP) хочет подключиться к дереву, отправляет Join — пакет 232. R1 ещё какое-то время, пока обрабатывает запрос от R2, отправляет мультикаст в Register (пакеты с 233 по 238). Далее, когда нисходящий интерфейс добавлен в OIL на R1, он начинает передавать чистый мультикаст — пакеты 239 и 242, но пока не прекращает и Register — пакеты 241 и 243. А пакет 240 — это R2 не выдержал и ещё раз попросил построить дерево.

10) Итак, незамутнённый мультикаст достигает RP. Она понимает, что это тот же самый трафик, который приходит в Register, потому что одинаковый адрес группы, одинаковый адрес источника и с одного интерфейса. Чтобы не получать две копии, он отправляет на R1 юникастовый PIM Register-Stop.
Register-Stop не означает, что R2 отказывается от трафика или не признаёт больше этот источник, это говорит лишь о том, что надо прекратить посылать инкапсулированный трафик. Далее идёт ожесточённая борьба — R1 продолжает передавать накопившийся в буфере трафик, пока обрабатывает Register-Stop, и обычным мультикастом и внутри сообщений Register:
Но, рано или поздно R1 начинает вещать только чистый мультикастовый трафик.

При подготовке у меня возник, как мне казалось, закономерный вопрос: ну и к чему все эти туннелирования, PIM Register? Почему бы не поступать с мультикастовым трафиком, как с PIM Join — отправлять хоп за хопом с TTL=1 в сторону RP — рано или поздно ведь дойдёт? Так бы и дерево построилось бы заодно без лишних телодвижений.

Тут возникает несколько нюансов.

Во-первых, нарушается главный принцип PIM SM — трафик посылать только туда, откуда он был запрошен. Нет Join — Нет дерева!

Во-вторых, если клиентов для данной группы нет, FHR не узнает об этом и будет продолжать слать трафик по «своему дереву». К чему такое бездумное использование полосы пропускания? В мире связи такой протокол просто не выжил бы, как не выжил PIM DM или DVMRP.

Таким образом мы имеем одно большое дерево MDT для группы 224.2.2.4 от Cервера-источника до Клиента 1 и Клиента 2. И это MDT составлено из двух кусков, которые строились независимо друг от друга: Source Tree от источника до RP и RPT от RP до клиентов. Вот оно отличие MDT от RPT и SPT. MDT — это довольно общий термин, означающий дерево передачи мультикаста вообще, в то время, как RPT/SPT — это его очень конкретный вид.

А что делать, если сервер уже вещает, а клиентов всё нет и нет? Мультикаст так и будет засорять участок между отправителем и RP?

Нет, в этом случае также поможет PIM Register-Stop. Если на RP начали приходить сообщения Register для какой-то группы, а для неё ещё нет получателей, то RP не заинтересован в получении этого трафика, поэтому, не отправляя PIM Join (S, G), RP сразу посылает Register-Stop на R1.

R1, получив Register-Stop и видя, что дерева для этой группы пока нет (нет клиентов), начинает отбрасывать мультикастовый трафик от сервера.

То есть сам сервер по этому поводу совершенно не беспокоится и продолжает посылать поток, но, дойдя до интерфейса маршрутизатора, поток будет отброшен.

При этом RP продолжает хранить запись (S, G). То есть трафик он не получает, но где находится источник для группы знает. Если в группе появляются получатели, RP узнаёт о них и посылает на источник Join (S, G), который строит дерево.

Кроме того, каждые 3 минуты R1 будет пытаться повторно зарегистрировать источник на RP, то есть отправлять пакеты Register. Это нужно для того, чтобы уведомить RP о том, что этот источник ещё живой.

У особо пытливых читателей обязан возникнуть вопрос — а как быть с RPF? Этот механизм ведь проверяет адрес отправителя мультикастового пакета и, если трафик идёт не с правильного интерфейса, он будет отброшен. При этом RP и источник могут находиться за разными интерфейсам. Вот и в нашем примере для R3 RP — за FE1/1, а источник — за FE1/0.

Ответ предсказуем — в таком случае проверяется не адрес источника, а RP. То есть трафик должен придти с интерфейса в сторону RP.

Но, как вы увидите далее, это тоже не нерушимое правило.

Важно понимать, что RP — это не универсальный магнит — для каждой группы может бытья своя RP. То есть в сети их может быть и две, и три, и сто — одна RP отвечает за один набор групп, другая — за другой. Более того, есть такое понятие, как

Замечание к топологии: в этой задаче только маршрутизаторы R1, R2, R3 находятся под управлением администраторов нашей сети. То есть, конфигурацию изменять можно только на них.

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1 и 239.2.2.2.

Настроить сеть таким образом, чтобы трафик группы 239.1.1.1 не передавался в сегмент между R3 и R5, и во все сегменты ниже R5.

Но при этом, трафик группы 239.2.2.2 должен передаваться без проблем.

Бритва Оккама или отключение ненужных ветвей

После того, как последний клиент в сегменте отказался от подписки, PIM должен отрезать лишнюю ветку RPT.

Пусть, например, единственный клиент на R4 выключил компьютер. Маршрутизатор по сообщению IGMP Leave или после трёх безответных IGMP Query понимает, что клиентов за FE0/0 больше нет, и отправляет в сторону RP сообщение PIM Prune. По формату оно точно такое же, как Join, но выполняет противоположную функцию.

Адрес назначения также 224.0.0.13, и TTL равен 1.
Но маршрутизатор, получивший PIM Prune, перед тем, как удалить подписку, ждёт некоторое время (обычно 3 секунды — Join Delay Timer).

Это сделано вот для такой ситуации:
В одном широковещательном домене 3 маршрутизатора. Один из них стоит выше и именно он передаёт в сегмент мультикастовый трафик. Это R1. Для обоих маршрутизаторов (R2 и R3) его OIL содержит только одну запись.

Если теперь R2 решит отключиться и отправит PIM Prune, то он может подставить своего коллегу R3 — R1 ведь перестанет вещать в интерфейс вообще.

Так вот, чтобы этого не произошло, R1 и даёт таймаут в 3 секунды. За это время R3 должен успеть среагировать. Учитывая широковещательность сети, он тоже получит Prune от R2 и поэтому, если хочет продолжать получать трафик, он мгновенно отправляет обычный PIM Join в сегмент, уведомляя R1, что не надо удалять интерфейс.

Этот процесс называется — Prune Override. R2 как бы объегорил R1, перехватил инициативу.

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 в сторону источника и оптимизировать маршрут?

Зрите в корень. Такое переключение может инициировать LHR (Last Hop Router) — R5. После получения первого мультикастового пакета от R3 R5 отправляет уже знакомый нам Source Specific Join (S, G) в интерфейс FE0/1, который указан в его таблице маршрутизации, как исходящий для сети 172.16.0.0/24.
Получив такой 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 и от источника — предпочтение отдаётся трафику от источника.

DR, Assert, Forwarder

Ещё несколько важных моментов при рассмотрении PIM.

DR — Designated Router. Это выделенный маршрутизатор, который ответственен за отправку служебных пакетов на RP.

Source DR — отвечает за принятие мультикастовых пакетов непосредственно от источника и его регистрацию на RP.

Вот пример топологии:
Здесь ни к чему, чтобы оба маршрутизатора передавали трафик на RP, пусть они резервируют друг друга, но ответственный должен быть только один.

Поскольку оба маршрутизатора подключены в одну широковещательную сеть, они получают друг от друга PIM-Hello. На основе него они и делают свой выбор.

PIM Hello несёт значение приоритета данного маршрутизатора на данном интерфейсе.
Чем больше значение, тем выше приоритет. Если они одинаковы, то выбирается узел с наибольшим IP-адресом (тоже из сообщения Hello).
Если другой маршрутизатор (не DR) в течение Holdtime (по умолчанию 105 с) не получал Hello от соседа, он автоматически берёт на себя роль DR.

По сути Source DR — это FHR — First Hop Router.

Receiver DR — то же, что Source DR, только для получателей мультикастового трафика — LHR (Last Hop Router). Пример топологии:

Receiver DR ответственен за отправку на RP PIM Join. В вышеприведённой топологии, если оба маршрутизатора отправят Join, то оба будут получать мультикастовый трафик, но в этом нет необходимости. Только DR отправляет Join. Второй просто мониторит доступность DR.

Поскольку DR отправляет Join, то он же и будет вещать трафик в LAN. Но тут возникает закономерный вопрос — а что, если PIM DR’ом стал один, а IGMP Querier’ом другой? А ситуация-то вполне возможна, ведь для Querier чем меньше IP, тем лучше, а для DR, наоборот.

В этом случае DR’ом выбирается тот маршрутизатор, который уже является Querier и такая проблема не возникает.
Правила выбора Receiver DR точно такие же, как и Source DR.

Assert и PIM Forwarder

Проблема двух одновременно передающих маршрутизаторов может возникнуть и в середине сети, где нет ни конечных клиентов, ни источников — только маршрутизаторы.

Очень остро этот вопрос стоял в PIM DM, где это была совершенно рядовая ситуация из-за механизма Flood and Prune.

Но и в PIM SM она не исключена.

Рассмотрим такую сеть:
Здесь три маршрутизатора находятся в одном сегменте сети и, соответственно, являются соседями по PIM. R1 выступает в роли RP.

R4 отправляет PIM Join в сторону RP. Поскольку этот пакет мультикастовый он попадает и на R2 и на R3, и оба они обработав его, добавляют нисходящий интерфейс в OIL.

Тут бы должен сработать механизм выбора DR, но и на R2 и на R3 есть другие клиенты этой группы, и обоим маршрутизаторам так или иначе придётся отправлять PIM Join.

Когда мультикастовый трафик приходит от источника на R2 и R3, в сегмент он передаётся обоими маршрутизаторами и задваивается там. PIM не пытается предотвратить такую ситуацию — тут он действует по факту свершившегося преступления — как только в свой нисходящий интерфейс для определённой группы (из списка OIL) маршрутизатор получает мультикастовый трафик этой самой группы, он понимает: что-то не так — другой отправитель уже есть в этом сегменте.

Тогда маршрутизатор отправляет специальное сообщение PIM Assert.

Такое сообщение помогает выбрать PIM Forwarder — тот маршрутизатор, который вправе вещать в данном сегменте.
Не надо его путать с PIM DR. Во-первых, PIM DR отвечает за отправку сообщений PIM Join и Prune, а PIM Forwarder — за отправку трафика. Второе отличие — PIM DR выбирается всегда и в любых сетях при установлении соседства, А PIM Forwrder только при необходимости — когда получен мультикастовый трафик с интерфейса из списка OIL.

Выбор RP

Выше мы для простоты задавали RP вручную командой ip pim rp-address X.X.X.X.

И вот как выглядела команда show ip pim rp:
Но представим совершенно невозможную в современных сетях ситуацию — R2 вышел из строя. Это всё — финиш. Клиент 2 ещё будет работать, поскольку произошёл SPT Switchover, а вот всё новое и всё, что шло через RP сломается, даже если есть альтернативный путь.

Ну и нагрузка на администратора домена. Представьте себе: на 50 маршрутизаторах перебить вручную как минимум одну команду (а для разных групп ведь могут быть разные RP).

Динамический выбор RP позволяет и избежать ручной работы и обеспечить надёжность — если одна RP станет недоступна, в бой вступит сразу же другая.

В данный момент существует один общепризнанный протокол, позволяющий это сделать — Bootstrap. Циска в прежние времена продвигала несколько неуклюжий Auto-RP, но сейчас он почти не используется, хотя циска этого не признаёт, и в show ip mroute мы имеем раздражающий рудимент в виде группы 224.0.1.40.

Надо на самом деле отдать должное протоколу Auto-RP. Он был спасением в прежние времена. Но с появлением открытого и гибкого Bootstrap, он закономерно уступил свои позиции.

Итак, предположим, что в нашей сети мы хотим, чтобы R3 подхватывал функции RP в случае выхода из строя R2.

R2 и R3 определяются как кандидаты на роль RP — так они и называются C-RP. На этих маршрутизаторах настраиваем:

RX(config)interface Loopback 0 RX(config-if)ip pim sparse-mode RX(config-if)exit RX(config)#ip pim rp-candidate loopback 0 

Но пока ничего не происходит — кандидаты пока не знают, как уведомить всех о себе.

Чтобы информировать все мультикастовые маршрутизаторы домена о существующих RP вводится механизм BSR — BootStrap Router. Претендентов может быть несколько, как и C-RP. Они называются соответственно C-BSR. Настраиваются они похожим образом.

Пусть BSR у нас будет один и для теста (исключительно) это будет R1.

R1(config)interface Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0 

Сначала из всех C-BSR выбирается один главный BSR, который и будет всем заправлять. Для этого каждый C-BSR отправляет в сеть мультикастовый BootStrap Message (BSM) на адрес 224.0.0.13 — это тоже пакет протокола PIM. Его должны принять и обработать все мультикастовые маршрутизаторы и после разослать во все порты, где активирован PIM. BSM передаётся не в сторону чего-то (RP или источника), в отличии, от PIM Join, а во все стороны. Такая веерная рассылка помогает достигнуть BSM всех уголков сети, в том числе всех C-BSR и всех C-RP. Для того, чтобы BSM не блуждали по сети бесконечно, применяется всё тот же механизм RPF — если BSM пришёл не с того интерфейса, за которым находится сеть отправителя этого сообщения, такое сообщение отбрасывается.
С помощью этих BSM все мультикастовые маршрутизаторы определяют самого достойного кандидата на основе приоритетов. Как только C-BSR получает BSM от другого маршрутизатора с бОльшим приоритетом, он прекращает рассылать свои сообщения. В результате все обладают одинаковой информацией.
На этом этапе, когда выбран BSR, благодаря тому, что его BSM разошлись уже по всей сети, C-RP знают его адрес и юникастом отправляют на него сообщения Candidte-RP-Advertisement, в которых они несут список групп, которые они обслуживают — это называется group-to-RP mapping. BSR все эти сообщения агрегирует и создаёт RP-Set — информационную таблицу: какие RP каждую группу обслуживают.
Далее BSR в прежней веерной манере рассылает те же BootStrap Message, которые на этот раз содержат RP-Set. Эти сообщения успешно достигают всех мультикастовых маршрутизаторов, каждый из которых самостоятельно делает выбор, какую RP нужно использовать для каждой конкретной группы.
BSR периодически делает такие рассылки, чтобы с одной стороны все знали, что информация по RP ещё актуальна, а с другой C-BSR были в курсе, что сам главный BSR ещё жив. RP, кстати, тоже периодически шлют на BSR свои анонсы Candidate-RP-Advertisement.

Фактически всё, что нужно сделать для настройки автоматического выбора RP — указать C-RP и указать C-BSR — не так уж много работы, всё остальное за вас сделает PIM. Как всегда, в целях повышения надёжности рекомендуется указывать интерфейсы Loopback в качестве кандидатов.

Завершая главу PIM SM, давайте ещё раз отметим важнейшие моменты

1. Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
2. Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента — нет дерева.
3. RPF помогает избежать петель.
4. Все маршрутизаторы должны знать о том, кто является RP — только с её помощью можно построить дерево.
5. Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
6. В первой фазе строится RPT — дерево от клиентов до RP — и Source Tree — дерево от источника до RP. Во второй фазе происходит переключение с построенного RPT на SPT — кратчайший путь от получателя до источника.

Ещё перечислим все типы деревьев и сообщений, которые нам теперь известны.

MDT — Multicast Distribution Tree. Общий термин, описывающий любое дерево передачи мультикаста.

SPT — Shortest Path Tree. Дерево с кратчайшим путём от клиента или RP до источника. В PIM DM есть только SPT. В PIM SM SPT может быть от источника до RP или от источника до получателя после того, как произошёл SPT Switchover. Обозначается записью (S, G) — известен источник для группы.

Source Tree — то же самое, что SPT.

RPT — Rendezvous Point Tree. Дерево от RP до получателей. Используется только в PIM SM. Обозначается записью (*, G).

Shared Tree — то же, что RPT. Называется так потому, что все клиенты подключены к одному общему дереву с корнем в RP.

Типы сообщений PIM Sparse Mode:

Hello — для установления соседства и поддержания этих отношений. Также необходимы для выбора DR.

Join (*, G) — запрос на подключение к дереву группы G. Не важно кто источник. Отправляется в сторону RP. С их помощью строится дерево RPT.

Join (S, G) — Source Specific Join. Это запрос на подключение к дереву группы G с определённым источником — S. Отправляется в сторону источника — S. С их помощью строится дерево SPT.

Prune (*, G) — запрос на отключение от дерева группы G, какие бы источники для неё не были. Отправляется в сторону RP. Так обрезается ветвь RPT.

Prune (S, G) — запрос на отключение от дерева группы G, корнем которого является источник S. Отправляется в сторону источника. Так обрезается ветвь SPT.

Register — специальное сообщение, внутри которого передаётся мультикаст на RP, пока не будет построено SPT от источника до RP. Передаётся юникастом от FHR на RP.

Register-Stop — отправляется юникастом с RP на FHR, приказывая прекратить посылать мультикастовый трафик, инкапсулированный в Register.

Bootstrap — пакеты механизма BSR, которые позволяют выбрать маршрутизатор на роль BSR, а также передают информацию о существующих RP и группах.

Assert — сообщение для выбора PIM Forwarder, чтобы в один сегмент не передавали трафик два маршрутизатора.

Candidate-RP-Advertisement — сообщение, в котором RP отсылает на BSR информацию о том, какие группы он обслуживает.

RP-Reachable — сообщение от RP, которым она уведомляет всех о своей доступности.

*Есть и другие типы сообщений в PIM, но это уже детали*

А давайте теперь попытаемся абстрагироваться от деталей протокола? И тогда становится очевидной его сложность.

1) Определение RP,

2) Регистрация источника на RP,

3) Переключение на дерево SPT.

Много состояний протокола, много записей в таблице мультикастовой маршрутизации. Можно ли что-то с этим сделать?

На сегодняшний день существует два диаметрально противоположных подхода к упрощению PIM: SSM и BIDIR PIM.

SSM

Всё, что мы описывали до сих пор — это ASM — Any Source Multicast. Клиентам безразлично, кто является источником трафика для группы — главное, что они его получают. Как вы помните в сообщении IGMPv2 Report запрашивается просто подключение к группе.

SSM — Source Specific Multicast — альтернативный подход. В этом случае клиенты при подключении указывают группу и источник.

Что же это даёт? Ни много ни мало: возможность полностью избавиться от RP. LHR сразу знает адрес источника — нет необходимости слать Join на RP, маршрутизатор может сразу же отправить Join (S, G) в направлении источника и построить SPT.

Таким образом мы избавляемся от

• Поиска RP (протоколы Bootstrap и Auto-RP),
• Регистрации источника на RP (а это лишнее время, двойное использование полосы пропускания и туннелирование)
• Переключения на SPT.

Поскольку нет RP, то нет и RPT, соответственно ни на одном маршрутизаторе уже не будет записей (*, G) — только (S, G).

Ещё одна проблема, которая решается с помощью SSM — наличие нескольких источников. В ASM рекомендуется, чтобы адрес мультикастовой группы был уникален и только один источник вещал на него, поскольку в дереве RPT несколько потоков сольются, а клиент, получая два потока от разных источников, вероятно, не сможет их разобрать.

В SSM трафик от различных источников распространяется независимо, каждый по своему дереву SPT, и это уже становится не проблемой, а преимуществом — несколько серверов могут вещать одновременно. Если вдруг клиент начал фиксировать потери от основного источника, он может переключиться на резервный, даже не перезапрашивая его — он и так получал два потока.

Кроме того, возможный вектор атаки в сети с активированной мультикастовой маршрутизацией — подключение злоумышленником своего источника и генерирование большого объёма мультикастового трафика, который перегрузит сеть. В SSM такое практически исключено.

Для SSM выделен специальный диапазон IP-адресов: 232.0.0.0/8.

На маршрутизаторах для поддержки SSM включается режим PIM SSM.

Router(config)# ip pim ssm

IGMPv3 и MLDv2 поддерживают SSM в чистом виде.

При их использовании клиент может

• Запрашивать подключение к просто группе, без указания источников. То есть работает как типичный ASM.
• Запрашивать подключение к группе с определённым источником. Источников можно указать несколько — до каждого из них будет построено дерево.
• Запрашивать подключение к группе и указать список источников, от которых клиент не хотел бы получать трафик

IGMPv1/v2, MLDv1 не поддерживают SSM, но имеет место такое понятие, как SSM Mapping. На ближайшем к клиенту маршрутизаторе (LHR) каждой группе ставится в соответствие адрес источника (или несколько). Поэтому если в сети есть клиенты, не поддерживающие IGMPv3/MLDv2, для них также будет построено SPT, а не RPT, благодаря тому, что адрес источника всё равно известен. SSM Mapping может быть реализован как статической настройкой на LHR, так и посредством обращения к DNS-серверу.

Проблема SSM в том, что клиенты должны заранее знать адреса источников — никакой сигнализацией они им не сообщаются.

Поэтому SSM хорош в тех ситуациях, когда в сети определённый набор источников, их адреса заведомо известны и не будут меняться. А клиентские терминалы или приложения жёстко привязаны к ним. Иными словами IPTV — весьма пригодная среда для внедрения SSM. Это хорошо описывает концепцию One-to-Many — один источник, много получателей.

BIDIR PIM

А что если в сети источники могут появляться спонтанно то там, то тут, вещать на одинаковые группы, быстро прекращать передачу и исчезать?

Например, такая ситуация возможна в сетевых играх или в ЦОД, где происходит репликация данных между различными серверами. Это концепция Many-to-Many — много источников, много клиентов. Как на это смотрит обычный PIM SM? Понятное дело, что инертный PIM SSM здесь совсем не подходит?

Вы только подумайте, какой хаос начнётся: бесконечные регистрации источников, перестроение деревьев, огромное количество записей (S, G) живущих по несколько минут из-за таймеров протокола. На выручку идёт двунаправленный PIM (Bidirectional PIM, BIDIR PIM). В отличие от SSM в нём напротив полностью отказываются от SPT и записей (S,G) — остаются только Shared Tree с корнем в RP.

И если в обычном PIM, дерево является односторонним — трафик всегда передаётся от источника вниз по SPT и от RP вниз по RPT — есть чёткое деление, где источник, где клиенты, то в двунаправленном от источника трафик к RP передаётся также вверх по Shared Tree — по тому же самому, по которому трафик течёт вниз к клиентам.

Это позволяет отказаться от регистрации источника на RP — трафик передаётся безусловно, без какой бы то ни было сигнализации и изменения состояний. Поскольку деревьев SPT нет вообще, то и SPT Switchover тоже не происходит.

Вот например:
Источник1 начал передавать в сеть трафик группы 224.2.2.4 одновременно с Источником2. Потоки от них просто полились в сторону RP. Часть клиентов, которые находятся рядом начали получать трафик сразу, потому что на маршрутизаторах есть запись (*, G) (есть клиенты). Другая часть получает трафик по Shared Tree от RP. Причём получают они трафик от обоих источников одновременно.

То есть, если взять для примера умозрительную сетевую игру, Источник1 это первый игрок в стрелялке, который сделал выстрел, а Источник2 — это другой игрок, который сделал шаг в сторону. Информация об этих двух событиях распространилась по всей сети. И каждый другой игрок (Получатель) должен узнать об обоих этих событиях.

Если помните, то чуть раньше мы объяснили, зачем нужен процесс регистрации источника на RP — чтобы трафик не занимал канал, когда нет клиентов, то есть RP просто отказывался от него. Почему над этой проблемой мы не задумываемся сейчас? Причина проста: BIDIR PIM для ситуаций, когда источников много, но они вещают не постоянно, а периодически, относительно небольшими кусками данных. То есть канал от источника до RP не будет утилизироваться понапрасну.

Обратите внимание, что на изображении выше между R5 и R7 есть прямая линия, гораздо более короткая, чем путь через RP, но она не была использована, потому что Join идут в сторону RP согласно таблице маршрутизации, в которой данный путь не является оптимальным.

Выглядит довольно просто — нужно отправлять мультикастовые пакеты в направлении RP и всё, но есть один нюанс, который всё портит — RPF. В дереве RPT он требует, чтобы трафик приходил от RP и не иначе. А у нас он может приходить откуда угодно. Взять и отказаться от RPF мы, конечно, не можем — это единственный механизм, который позволяет избежать образования петель.

Поэтому в BIDIR PIM вводится понятие DF — Designated Forwarder. В каждом сегменте сети, на каждой линии на эту роль выбирается тот маршрутизатор, чей маршрут до RP лучше.

В том числе это делается и на тех линиях, куда непосредственно подключены клиенты. В BIDIR PIM DF автоматически является DR.

Список OIL формируется только из тех интерфейсов, на которых маршрутизатор был выбран на роль DF.

Правила довольно прозрачны:

• Если запрос PIM Join/Leave приходит на тот интерфейс, который в данном сегменте является DF, он передаётся в сторону RP по стандартным правилам. Вот, например, R3. Если запросы пришли в DF интерфейсы, что помечены красным кругом, он их передаёт на RP (через R1 или R2, в зависимости от таблицы маршрутизации).
• Если запрос PIM Join/Leave пришёл на не DF интерфейс, он будет проигнорирован. Допустим, что клиент, находящийся между R1 и R3, решил подключиться и отправил IGMP Report. R1 получает его через интерфейс, где он выбран DF (помечен красным кругом), и мы возвращаемся к предыдущему сценарию. А R3 получает запрос на интерфейс, который не является DF. R3 видит, что тут он не лучший, и игнорирует запрос.
• Если мультикастовый трафик пришёл на DF интерфейс, он будет отправлен в интерфейсы из списка OIL и в сторону RP. Например, Источник1 начал передавать трафик. R4 получает его в свой DF интерфейс и передаёт его и в другой DF-интерфейс — в сторону клиента и в сторону RP, — это важно, потому что трафик должен попасть на RP и распространиться по всем получателям. Также поступает и R3 — одна копия в интерфейсы из списка OIL — то есть на R5, где он будет отброшен из-за проверки RPF, и другая — в сторону RP.
• Если мультикастовый трафик пришёл на не DF интерфейс, он должен быть отправлен в интерфейсы из списка OIL, но не будет отправлен в сторону RP. К примеру, Источник2 начал вещать, трафик дошёл до RP и начал распространяться вниз по RPT. R3 получает трафик от R1, и он не передаст его на R2 — только вниз на R4 и на R5.

Таким образом DF гарантирует, что на RP в итоге будет отправлена только одна копия мультикастового пакета и образование петель исключено. При этом то общее дерево, в котором находится источник, естественно, получит этот трафик ещё до попадания на RP. RP, согласно обычным правилам разошлёт трафик во все порты OIL, кроме того, откуда пришёл трафик.

Кстати, нет нужды более и в сообщениях Assert, ведь DF выбирается в каждом сегменте. В отличие от DR он отвечает не только за отправку Join к RP, но и за передачу трафика в сегмент, то есть ситуация, когда два маршрутизатора передают в одну подсеть трафик, исключена в BIDIR PIM.

Пожалуй, последнее, что нужно сказать о двунаправленном PIM, это особенности работы RP. Если в PIM SM RP выполнял вполне конкретную функцию — регистрация источника, то в BIDIR PIM RP — это некая весьма условная точка, к которой стремится трафик с одной стороны и Join от клиентов с другой. Никто не должен выполнять декапсуляцию, запрашивать построение дерева SPT. Просто на каком-то маршрутизаторе вдруг трафик от источников начинает передаваться в Shared Tree. Почему я говорю «на каком-то»? Дело в том, что в BIDIR PIM RP — абстрактная точка, а не конкретный маршрутизатор, в качестве адреса RP вообще может выступать несуществующий IP-адрес — главное, чтобы он был маршрутизируемый (такая RP называется Phantom RP).

Мультикаст на канальном уровне

Итак, позади долгая трудовая неделя с недосыпами, переработками, тестами — вы успешно внедрили мультикаст и удовлетворили клиентов, директора и отдел продаж.

Пятница — не самый плохой день, чтобы обозреть творение и позволить себе приятный отдых.

Но ваш послеобеденный сон вдруг потревожил звонок техподдержки, потом ещё один и ещё — ничего не работает, всё сломалось. Проверяете — идут потери, разрывы. Всё сходится на одном сегменте из нескольких коммутаторов.

Расчехлили SSH, проверили CPU, проверили утилизацию интерфейсов и волосы дыбом — загрузка почти под 100% на всех интерфейсах одного VLAN’а. Петля! Но откуда ей взяться, если никаких работ не проводилось? Минут 10 проверки и вы заметили, что на восходящем интерфейсе к ядру у вас много входящего трафика, а на всех нисходящих к клиентам — исходящего. Для петли это тоже характерно, но как-то подозрительно: внедрили мультикаст, никаких работ по переключению не делали и скачок только в одном направлении.

Проверили список мультикастовых групп на маршрутизаторе — а там подписка на все возможные каналы и все на один порт — естественно, тот, который ведёт в этот сегмент.

Дотошное расследование показало, что компьютер клиента заражён и рассылает IGMP Query на все мультикастовые адреса подряд.

Потери пакетов начались, потому что коммутаторам пришлось пропускать через себя огромный объём трафика. Это вызвало переполнение буферов интерфейсов.

Главный вопрос — почему трафик одного клиента начал копироваться во все порты?

Причина этого кроется в природе мультикастовых MAC-адресов. Дело в том, пространство мультикастовых IP-адресов специальным образом отображается в пространство мультикастовых MAC-адресов. И загвоздка в том, что они никогда не будут использоваться в качестве MAC-адреса источника, а следовательно, не будут изучены коммутатором и занесены в таблицу MAC-адресов. А как поступает коммутатор с кадрами, адрес назначения которых не изучен? Он их рассылает во все порты. Что и произошло.

Это действие по умолчанию.

Мультикастовые MAC-адреса

Так какие же MAC-адреса получателей подставляются в заголовок Ethernet таких пакетов? Широковещательные? Нет. Существует специальный диапазон MAC-адресов, в которые отображаются мультикастовые IP-адреса.

Эти специальные адреса начинаются так: 0x01005e и следующий 25-й бит должен быть 0 (попробуйте ответить, почему так). Остальные 23 бита (напомню, всего их в МАС-адресе 48) переносятся из IP-адреса.

Здесь кроется некоторая не очень серьёзная, но проблема. Диапазон мультикастовых адресов определяется маской 224.0.0.0/4, это означает, что первые 4 бита зарезервированы: 1110, а оставшиеся 28 бит могут меняться. То есть у нас 2^28 мультикастовых IP-адресов и только 2^23 MAC-адресов — для отображения 1 в 1 не хватает 5 бит. Поэтому берутся просто последние 23 бита IP-адреса и один в один переносятся в MAC-адрес, остальные 5 отбрасываются.

Фактически это означает, что в один мультикастовый MAC-адрес будет отображаться 2^5=32 IP-адреса. Например, группы 224.0.0.1, 224.128.0.1, 225.0.0.1 и так до 239.128.0.1 все будут отображаться в один MAC-адрес 0100:5e00:0001.

Если взять в пример дамп потокового видео, то можно увидеть:
IP адрес — 224.2.2.4, MAC-адрес: 01:00:5E:02:02:04.

Есть также другие мультикастовые MAC-адреса, которые никак не относятся к IPv4-мультикаст (клик). Все они, кстати, характеризуются тем, что последний бит первого октета равен 1.

Естественно, ни на одной сетевой карте, не может быть настроен такой MAC-адрес, поэтому он никогда не будет в поле Source MAC Ethernet-кадра и никогда не попадёт в таблицу MAC-адресов. Значит такие кадры должны рассылаться как любой Unknown Unicast во все порты VLAN’а.

Всего, что мы рассматривали прежде, вполне достаточно для полноценной передачи любого мультикастового трафика от потокового видео до биржевых котировок. Но неужели мы в своём почти совершенном мире будем мирится с таким безобразием, как широковещательная передача того, что можно было бы передать избранным?

Вовсе нет. Специально для перфекционистов придуман механизм IGMP Snooping.

IGMP Snooping

Идея очень простая — коммутатор «слушает» проходящие через него IGMP-пакеты.

Для каждой группы отдельно он ведёт таблицу восходящих и нисходящих портов.

Если с порта пришёл IGMP Report для группы, значит там клиент, коммутатор добавляет его в список нисходящих для этой группы.

Если с порта пришёл IGMP Query для группы, значит там маршрутизатор, коммутатор добавляет его в список восходящих.

Таким образом формируется таблица передачи мультикастового трафика на канальном уровне.

В итоге, когда сверху приходит мультикастовый поток, он копируется только в нисходящие интерфейсы. Если на 16-портовом коммутаторе только два клиента, только им и будет доставлен трафик.

Гениальность этой идеи заканчивается тогда, когда мы задумываемся о её природе. Механизм предполагает, что коммутатор должен прослушивать трафик на 3-м уровне.

Впрочем, IGMP Snooping ни в какое сравнение не идёт с NAT по степени игнорирования принципов сетевого взаимодействия. Тем более, кроме экономии в ресурсах, он несёт в себе массу менее очевидных возможностей. Да и в общем-то в современном мире, коммутатор, который умеет заглядывать внутрь IP — явление не исключительное.

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1, 239.2.2.2 и 239.0.0.x.

Настроить сеть таким образом, чтобы:

— клиент 1 не мог присоединиться к группе 239.2.2.2. Но при этом мог присоединиться к группе 239.0.0.x.

— клиент 2 не мог присоединиться к группе 239.1.1.1. Но при этом мог присоединиться к группе 239.0.0.x.

IGMP Snooping Proxy

У пытливого читателя может возникнуть вопрос по тому, как IGMP Snooping узнаёт все клиентские порты, учитывая, что на IGMP Query отвечает только один самый быстрый клиент, как мы говорили выше. А очень просто: IGMP Snooping не позволяет сообщениям Report ходить между клиентами. Они отправляются только в восходящие порты к маршрутизаторам. Не видя Report от других получателей этой группы, клиент обязан ответить на Query в течение Max Response Time, указанном в этом Query.

В итоге в сети на 1000 узлов на один IGMP Query в течение секунд 10 (обычное значение Max Response Time) придёт 1000 Report’ов маршрутизатору. Хотя ему достаточно было бы и одного для каждой группы.

И происходит это каждую минуту.

В этом случае можно настроить проксирование IGMP-запросов. Тогда коммутатор не просто «слушает» проходящие пакеты, он их перехватывает.

Правила работы IGMP Snooping могут отличаться для разных производителей. Поэтому рассмотрим их концептуально:

1. 1) Если на коммутатор приходит самый первый запрос Report на группу, он отправляется вверх к маршрутизатору, а интерфейс вносится в список нисходящих. Если же такая группа уже есть, интерфейс просто добавляется в список нисходящих, а Report уничтожается.
2. 2) Если на коммутатор приходит самый последний Leave, то есть других клиентов нет, этот Leave будет отправлен на маршрутизатор, а интерфейс удаляется из списка нисходящих. В противном случае просто удаляется интерфейс, Leave уничтожается
3. 3) Если IGMP Query приходит от маршрутизатора, коммутатор перехватывает его, отправляет в ответ IGMP Report для всех групп, которые в данный момент имеют получателей.

А дальше, в зависимости от настроек и производителя, либо этот же самый Query рассылается во все клиентские порты, либо коммутатор блокирует запрос от маршрутизатора и сам выступает в роли Querier, периодически опрашивая всех получателей.

Таким образом снижается и доля лишнего служебного трафика в сети и нагрузка на маршрутизатор.

Multicast VLAN Replication

Сокращённо MVR. Это механизм для тех провайдеров, кто практикует VLAN-per-user, например.

Вот типичный пример сети, где MVR жизненно необходим:

5 клиентов в разных VLAN’ах, и все хотят получать мультикастовый трафик одной группы 224.2.2.4. При этом клиенты должны оставаться изолированными друг от друга.

IGMP Snooping учитывает, разумеется и VLAN’ы. Если пять клиентов в разных VLAN’ах запрашивают одну группу — это будет пять разных таблиц. Соответственно и к маршрутизатору идут 5 запросов на подключение к группе. И каждый сабинтерфейс из этих пяти на маршрутизаторе будет добавлен отдельно в OIL. То есть получив 1 поток для группы 224.2.2.4 он отправит 5 копий, несмотря на то, что все они идут в один сегмент.

Для решения этой проблемы и был разработан механизм Multicast VLAN Replication.

Вводится дополнительный VLAN — Multicast VLAN — в нём, соответственно, будет передаваться мультикастовый поток. Он «проброшен» непосредственно до последнего коммутатора, где трафик из него копируется во все клиентские интерфейсы, которые хотят получать этот трафик — это и есть репликация.

В зависимости от реализации репликация из Multicast VLAN может производиться в User-VLAN или в определённые физические интерфейсы.
А что с IGMP-сообщениями? Query от маршрутизатора, естественно, приходит по мультикастовому VLAN’у. Коммутатор их рассылает в клиентские порты. Когда Report или Leave приходит от клиента, коммутатор проверяет откуда именно (VLAN, интерфейс) и, если необходимо, перенаправляет в мультикастовый VLAN.

Таким образом обычный трафик изолирован и по-прежнему ходит до маршрутизатора в пользовательском VLAN’е. А мультикастовый трафик и IGMP-пакеты передаются в Multicast VLAN.

На оборудовании Cisco MVR и IGMP Snooping настраиваются независимо. То есть можно отключить один и второй будет работать. Вообще же MVR основан на IGMP Snooping и на коммутаторах других производителей для работы MVR может быть обязательным включение IGMP Snooping.

Кроме того, IGMP Snooping позволяет осуществлять на коммутаторах фильтрацию трафика, ограничивать количество групп, доступных пользователю, включение IGMP Querier, статическую настройку восходящих портов, перманентное подключение к какой-либо группе (этот сценарий есть в сопутствующем видео), быструю реакцию на изменение топологии путём рассылки дополнительных Query, SSM-Mapping для IGMPv2 итд.

Заканчивая разговор об IGMP Snooping, хочется повторить — это необязательный функционал — всё и без него будет работать. Но это сделает сеть более предсказуемой, а жизнь инженера спокойнее. Однако все плюсы IGMP Snooping можно обернуть и против себя. Один такой выдающийся случай можно почитать по ссылке.

К слову у той же Cisco есть протокол CGMP — аналог IGMP, который не нарушает принципы работы коммутатора, но он проприетарный и не сказать, что широко распространённый.

Итак, мой неутомимый читатель, мы приближаемся к концу выпуска и напоследок хочется показать, как может быть реализована услуга IPTV на стороне клиента.

Самый простой способ, к которому мы уже не раз обращались в этой статье — запустить плеер, который может принять мультикастовый поток из сети. На нём можно вручную задать IP-адрес группы и наслаждаться видео.

Другой программный вариант, который часто используют провайдеры — специальное приложение, обычно весьма кастомное, в котором зашит набор каналов, используемых в сети провайдера. Нет необходимости что-то задавать вручную — нужно просто переключать каналы кнопками.

Оба эти способа дают возможность смотреть потоковое видео только на компьютере.

Третий же вариант позволяет использовать телевизор, причём как правило, любой. Для этого в доме клиента ставит так называемый Set-Top-Box (STB) — коробочка, устанавливаемая на телевизор. Это шелезяка, которая включается в абонентскую линию и разделяет трафик: обычный юникаст она отдаёт в Ethernet или WiFi, чтобы клиенты имели доступ в Интернет, а мультикастовый поток передаётся на телевизор через кабель (DVI, RGB, антенный итд.).

Часто вы, кстати, можете увидеть рекламу, где провайдер предлагает свои приставки для подключения телевидения — это и есть те самые STB

Напоследок нетривиальная задачка по мультикасту (авторы не мы, в ответах будет ссылка на оригинал).

Самая простая схема:
С одной стороны сервер-источник, с дугой — компьютер, который готов принимать трафик.

Адрес мультикастового потока вы можете устанавливать сами.

И соответственно, два вопроса:

1. Что нужно сделать, чтобы компьютер мог получать поток и при этом не прибегать к мультикастовой маршрутизации?

2. Допустим, вы вообще не знаете, что такое мультикаст и не можете его настраивать, как передать поток от сервера к компьютеру?

Задача легко ищется в поисковике, но попробуйте решить её сами.

Заключение

Незатронутыми в статье остались междоменная маршрутизация мультикастового трафика MSDP, MBGP, BGMP), балансировка нагрузки между RP (Anycast RP), PGM, проприетарные протоколы. Но, я думаю, имея как точку старта эту статью, разобраться в остальном не составит труда.

Благодарности

За помощь в подготовке статьи спасибо JDima.

За техническую поддержку спасибо Наташе Самойленко.

КДПВ нарисована Ниной Долгополовой — замечательным художником и другом проекта.

В пуле статей СДСМ ещё много интересного до окончания, поэтому не нужно хоронить цикл из-за долгого отсутствия выпуска — с каждой новой статьёй сложность значительно возрастает. Впереди почти весь MPLS, IPv6, QoS и дизайн сетей.

Как вы уже, наверно, заметили, у linkmeup появился новый проект — Глоссарий lookmeup (да, недалеко у нас ушла фантазия). Мы надеемся, что этот глоссарий станет самым полным справочником терминов в области связи, поэтому мы будем рады любой помощи в его заполнении.

Оставайтесь на связи

Пишите нам: info@linkmeup.ru
Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Добавить RSS в подкаст-плеер.
Пообщаться в общем чате в тг: https://t.me/linkmeup_chat

Поддержите проект:

Сети для самых маленьких. Часть девятая. Мультикаст

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

• Общее понимание Multicast
• Протокол IGMP
• Протокол PIM
• >>>PIM Dense Mode
• >>>Pim Sparse Mode
• >>>SPT Switchover — переключение RPT-SPT
• >>>DR, Assert, Forwarder
• >>>Автоматический выбор RP
• >>>SSM
• >>>BIDIR PIM
• Мультикаст на канальном уровне
• >>>IGMP-Snooping
• >>>MVR

На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.

В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP-snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.

Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.

Уже гораздо позже я пришёл в к следующему правилу:

И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.

Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.

Общее понимание Multicast

Как известно, существуют следующие типы трафика:
Unicast — одноадресная рассылка — один отправитель, один получатель. (Пример: запрос HTTP-странички у WEB-сервера).
Broadcast — широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (Пример: ARP-запрос).
Multicast — многоадресная рассылка — один отправитель, много получателей. (Пример: IPTV).
Anycast — одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (Пример: Anycast DNS).

Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.

Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.

Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.

Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.

Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.

1. Отправитель посылает только одну копию трафика, независимо от количества получателей.
2. Трафик получают только те, кто действительно заинтересован в нём.

Пример I

Начнём с самого простого случая:

На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.

При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене.

Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.

Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?».
Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.

Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.

Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.

В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.

Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?

Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.

Пример II

Добавим в схему коммутатор и ещё несколько клиентов:

Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.

В данной ситуации трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.

Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).

Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать.
Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов

Адрес	Значение
224.0.0.0	Не используется
224.0.0.1	Все узлы данного сегмента
224.0.0.2	Все мультикастовые узлы данного сегмента
224.0.0.4	Данный адрес выделялся для покойного протокола DVMRP
224.0.0.5	Все OSPF-маршрутизаторы сегмента
224.0.0.6	Все DR маршрутизаторы сегмента
224.0.0.9	Все RIPv2-маршрутизаторы сегмента
224.0.0.10	Все EIGRP-маршрутизаторы сегмента
224.0.0.13	Все PIM-маршрутизаторы сегмента
224.0.0.18	Все VRRP-маршрутизаторы сегмента
224.0.0.19-21	Все IS-IS-маршрутизаторы сегмента
224.0.0.22	Все IGMP-маршрутизаторы сегмента (v2 и v3)
224.0.0.102	Все HSRPv2/GLBP-маршрутизаторы сегмента
224.0.0.107	PTPv2 — Precision Time Protocol
224.0.0.251	mDNS
224.0.0.252	LLMNR
224.0.0.253	Teredo
224.0.1.1	NTP
224.0.1.39	Cisco Auto-RP-Announce
224.0.1.40	Cisco Auto-RP-Discovery
224.0.1.41	H.323 Gatekeeper
224.0.1.129-132	PTPv1/PTPv2
239.255.255.250	SSDP

Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.

Вот, собственно, самые базисные вещи касательно мультикаста.
Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.

Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.

Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.

IGMP

Снова вернёмся к дампу. Видите вот этот верхний пакет, после которого полился мультикастовый поток?

Это сообщение протокола IGMP, которое отправил клиент, когда мы на нём нажали Play. Именно так он сообщает о том, что хочет получать трафик для группы 224.2.2.4.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора.

В IPv6 используется MLD (Multicast Listener Discovery) вместо IGMP. Принцип работы у них абсолютно одинаковый, поэтому далее везде вы смело можете менять IGMP на MLD, а IP на IPv6.

Как же именно работает IGMP?
Пожалуй, начать нужно с того, что версий у протокола сейчас три: IGMPv1, IGMPv2, IGMPv3. Наиболее используемая — вторая, первая уже практически забыта, поэтому про неё говорить не будем, третья очень похожа на вторую.

Акцентируемся пока на второй, как на самой показательной, и рассмотрим все события от подключения клиента к группе до его выхода из неё.
Клиент будет также запрашивать группу 224.2.2.4 через проигрыватель VLC.

Роль IGMP очень проста: если клиентов нет — передавать мультикастовый трафик в сегмент не надо. Если появился клиент, он уведомляет маршрутизаторы с помощью IGMP о том, что хочет получать трафик.

Для того, чтобы понять, как всё происходит, возьмём такую сеть:

Предположим, что маршрутизатор уже настроен на получение и обработку мультикастового трафика.

1. Как только мы запустили приложение на клиенте и задали группу 224.2.2.4, в сеть будет отправлен пакет IGMP Membership Report — узел «рапортует» о том, что хочет получать трафик этой группы.

В IGMPv2 Report отправляется на адрес желаемой группы, и параллельно он же указывается в самом пакете. Данные сообщения должны жить только в пределах своего сегмента и не пересылаться никуда маршрутизаторами, поэтому и TTL у них 1.

Часто в литературе вы можете встретить упоминание о IGMP Join. Не пугайтесь — это альтернативное название для IGMP Membership Report.

2. Маршрутизатор получает IGMP-Report и, понимая, что за данным интерфейсом теперь есть клиенты, заносит информацию в свои таблицы

Это вывод информации по IGMP. Первая группа запрошена клиентом. Третья и четвёртая — это служебные группы протокола SSDP, встроенного в Windows. Вторая — специальная группа, которая всегда присутствует на маршрутизаторах Cisco — она используется для протокола Auto-RP, который по умолчанию активирован на маршрутизаторах.
Интерфейс FE0/0 становится нисходящим для трафика группы 224.2.2.4 — в него нужно будет отправлять полученный трафик.

Наряду с обычной юникастовой таблицей маршрутизации существует ещё и мультикастовая:

О наличии клиентов говорит первая запись (*, 224.2.2.4). А запись (172.16.0.5, 224.2.2.4) означает, что маршрутизатор знает об источнике мультикастового потока для этой группы.
Из вывода видно, что трафик для группы 224.2.2.4 приходит через FE0/1, а передавать его надо на порт FE0/0.
Интерфейсы, в которые нужно передавать трафик, входят в список нисходящих интерфейсов — OIL — Outbound Interface List.
Более подробно вывод команды show ip mroute мы разберём позже.

Выше на дампе вы видите, что как только клиент отправил IGMP-Report, сразу после него полетели UDP — это видеопоток.

3. Клиент начал получать трафик. Теперь маршрутизатор должен иногда проверять, что получатели до сих пор у него есть, чтобы зазря не вещать, если вдруг клиентов не осталось. Для этого он периодически отправляет во все свои нисходящие интерфейсы запрос IGMP Query.

*Дамп отфильтрован по IGMP*.

По умолчанию это происходит каждые 60 секунд. TTL таких пакетов тоже равен 1. Они отправляются на адрес 224.0.0.1 — все узлы в этом сегменте — без указания конкретной группы. Такие сообщений Query называются General Query — общие. Таким образом маршрутизатор спрашивает: «Ребят, а кто и что ещё хочет получать?».

Получив IGMP General Query, любой хост, который слушает любую группу, должен отправить IGMP Report, как он это делал при подключении. В Report, естественно, должен быть указан адрес интересующей его группы.

*Дамп отфильтрован по IGMP*.

Если в ответ на Query на маршрутизатор пришёл хотя бы один Report для группы, значит есть ещё клиенты, он продолжает вещать в тот интерфейс, откуда пришёл этот Report, трафик этой самой группы.
Если на 3 подряд Query не было с интерфейса ответа для какой-то группы, маршрутизатор удаляет этот интерфейс из своей таблицы мультикастовой маршрутизации для данной группы — перестаёт туда посылать трафик.

По своей инициативе клиент обычно посылает Report только при подключении, потом — просто отвечает на Query от маршрутизатора.

Интересная деталь в поведении клиента: получив Query, он не торопится сразу же ответить Report’ом. Узел берёт тайм-аут длиной от 0 до Max Response Time, который указан в пришедшем Query:

При отладке или в дампе, кстати, можно видеть, что между получением различных Report может пройти несколько секунд.
Сделано это для того, чтобы сотни клиентов все скопом не наводнили сеть своими пакетам Report, получив General Query. Более того, только один клиент обычно отправляет Report.
Дело в том, что Report отсылается на адрес группы, а следовательно доходит и до всех клиентов. Получив Report от другого клиента для этой же группы, узел не будет отправлять свой. Логика простая: маршрутизатор и так уже получил этот самый Report и знает, что клиенты есть, больше ему не надо.
Этот механизм называется Report Suppression.

Далее в статье мы расскажем о том, почему этот механизм на деле очень редко реально работает.

4. Так продолжается веками, пока клиент не захочет выйти из группы (например, выключит плеер/телевизор). В этом случае он отправляет IGMP Leave на адрес группы.

Маршрутизатор получает его и по идее должен отключить. Но он ведь не может отключить одного конкретного клиента — маршрутизатор их не различает — у него просто есть нисходящий интерфейс. А за интерфейсом может быть несколько клиентов. То есть, если маршрутизатор удалит этот интерфейс из своего списка OIL (Outgoing Interface List) для этой группы, видео выключится у всех.
Но и не удалять его совсем тоже нельзя — вдруг это был последний клиент — зачем тогда впустую вещать?

Если вы посмотрите в дамп, то увидите, что после получения Leave маршрутизатор ещё некоторое время продолжает слать поток. Дело в том, что маршрутизатор в ответ на Leave высылает IGMP Query на адрес группы, для которой этот Leave пришёл в тот интерфейс, откуда он пришёл. Такой пакет называется Group Specific Query. На него отвечают только те клиенты, которые подключены к данной конкретной группе.

Если маршрутизатор получил ответный Report для группы, он продолжает вещать в интерфейс, если не получил — удаляет по истечении таймера.

Всего после получения Leave отправляется два Group Specific Query — один обязательный, второй контрольный.

*Дамп отфильтрован по IGMP*.

Далее маршрутизатор останавливает поток.

Querier

Рассмотрим чуть более сложный случай:

В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.

Выборы происходят довольно просто и интуитивно понятно.
Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.
1) Активировали IGMP на интерфейсах.
2) Сначала по умолчанию каждый из них считает себя Querier.
3) Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
4) General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
5) Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
6) Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
7) Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
8) Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier’ом становится другой маршрутизатор, у которого IP меньше.

Тот редкий случай, когда меряются, у кого меньше.

Выборы Querier очень важная процедура в мультикасте, но некоторые коварные производители, не придерживающиеся RFC, могут вставить крепкую палку в колёса. Я сейчас говорю о IGMP Query с адресом источника 0.0.0.0, которые могут генерироваться коммутатором. Такие сообщения не должны участвовать в выборе Querier, но надо быть готовыми ко всему. Вот пример весьма сложной долгоиграющей проблемы.

Ещё пара слов о других версиях IGMP

Версия 1 отличается по сути только тем, что в ней нет сообщения Leave. Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.
Кроме того, не поддерживаются выборы Querier. За избежание дублирования трафика отвечает вышестоящий протокол, например, PIM, о котором мы будем говорить далее.

Версия 3 поддерживает всё то, что поддерживает IGMPv2, но есть и ряд изменений. Во-первых, Report отправляется уже не на адрес группы, а на мультикастовый служебный адрес 224.0.0.22. А адрес запрашиваемой группы указан только внутри пакета. Делается это для упрощения работы IGMP Snooping, о котором мы поговорим дальше.

Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый Source Specific Multicast. В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.

Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру II, где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD.

Повторим ещё раз

*Дамп отфильтрован по IGMP*.

1. Первым делом маршрутизатор отправил свой IGMP General Query после включения IGMP на его интерфейсе, чтобы узнать, есть ли получатели и заявить о своём желании быть Querier. На тот момент никого не было в этой группе.
2. Далее появился клиент, который захотел получать трафик группы 224.2.2.4 и он отправил свой IGMP Report. После этого пошёл трафик на него, но он отфильтрован из дампа.
3. Потом маршрутизатор решил зачем-то проверить — а нет ли ещё клиентов и отправил IGMP General Query ещё раз, на который клиент вынужден ответить (4).
5. Периодически (раз в минуту) маршрутизатор проверяет, что получатели по-прежнему есть, с помощью IGMP General Query, а узел подтверждает это с помощью IGMP Report.
6. Потом он передумал и отказался от группы, отправив IGMP Leave.
7. Маршрутизатор получил Leave и, желая убедиться, что больше никаких других получателей нет, посылает IGMP Group Specific Query… дважды. И по истечении таймера перестаёт передавать трафик сюда.
8. Однако передавать IGMP Query в сеть он по-прежнему продолжает. Например, на тот случай, если вы плеер не отключали, а просто где-то со связью проблемы. Потом связь восстанавливается, но клиент-то Report не посылает сам по себе. А вот на Query отвечает. Таким образом поток может восстановиться без участия человека.

И ещё раз

IGMP — протокол, с помощью которого маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении.
IGMP Report — посылается клиентом при подключении и в ответ на IGMP Query. Означает, что клиент хочет получать трафик конкретной группы.
IGMP General Query — посылается маршрутизатором периодически, чтобы проверить какие группы сейчас нужны. В качестве адреса получателя указывается 224.0.0.1.
IGMP Group Sepcific Query — посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.
IGMP Leave — посылается клиентом, когда тот хочет покинуть группу.
Querier — если в одном широковещательном сегменте несколько маршрутизаторов, который могут вещать, среди них выбирается один главный — Querier. Он и будет периодически рассылать Query и передавать трафик.

Подробное описание всех терминов IGMP.

Итак, мы разобрались, как клиенты сообщают ближайшему маршрутизатору о своих намерениях. Теперь неплохо было бы передать трафик от источника получателю через большую сеть.

Если вдуматься, то мы стоим перед довольной сложной проблемой — источник только вещает на группу, он ничего не знает о том, где находятся получатели и сколько их.
Получатели и ближайшие к ним маршрутизаторы знают только, что им нужен трафик конкретной группы, но понятия не имеют, где находится источник и какой у него адрес.
Как в такой ситуации доставить трафик?

Существует несколько протоколов маршрутизации мультикастового трафика: DVMRP, MOSPF, CBT — все они по-разному решают такую задачу. Но стандартом де факто стал PIM — Protocol Independent Multicast.
Другие подходы настолько нежизнеспособны, что порой даже их разработчики практически признают это. Вот, например, выдержка из RFC по протоколу CBT:
CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

• PIM Dense Mode (DM)
• PIM Sparse Mode (SM)

PIM Dense Mode

PIM DM пытается решить проблему доставки мультиакста в лоб. Он заведомо предполагает, что получатели есть везде, во всех уголках сети. Поэтому изначально он наводняет всю сеть мультикастовым трафиком, то есть рассылает его во все порты, кроме того, откуда он пришёл. Если потом оказывается, что где-то он не нужен, то эта ветка «отрезается» с помощью специального сообщения PIM Prune — трафик туда больше не отправляется.

Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст — вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft — маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт.
Как видите, здесь не стоит вопрос определения пути к получателям — трафик достигнет их просто потому, что он везде.
После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT — Shortest Path Tree.

Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в STP, где корнем является источник.

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 мы не будем — это устаревший протокол с массой недостатков (ну, как RIP).

Однако PIM DM может применяться в некоторых случаях. Например, в совсем небольших сетях, где поток мультикаста небольшой.

PIM Sparse Mode

Совершенно другой подход применяет PIM SM. Несмотря на название (разреженный режим), он с успехом может применяться в любой сети с эффективностью как минимум не хуже, чем у PIM DM.
Здесь отказались от идеи безусловного наводнения мультикастом сети. Заинтересованные узлы самостоятельно запрашивают подключение к дереву с помощью сообщений PIM Join.
Если маршрутизатор не посылал Join, то и трафик ему отправляться не будет.

Для того, чтобы понять, как работает PIM, начнём с уже знакомой нам простой сети с одним PIM-маршрутизатором:

Из настроек на R1 надо включить возможность маршрутизации мультикаста, PIM SM на двух интерфейсах (в сторону источника и в сторону клиента) и IGMP в сторону клиента. Помимо прочих базовых настроек, конечно (IP, IGP).

С этого момента вы можете расчехлить GNS и собирать лабораторию. Достаточно подробно о том, как собрать стенд для мультикаста я рассказал в этой статье.

 R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim sparse-mode

Cisco тут как обычно отличается своим особенным подходом: при активации PIM на интерфейсе, автоматически активируется и IGMP. На всех интерфейсах, где активирован PIM, работает и IGMP.
В то же время у других производителей два разных протокола включаются двумя разными командами: отдельно IGMP, отдельно PIM.
Простим Cisco эту странность? Вместе со всеми остальными?

Плюс, возможно, потребуется настроить адрес RP (ip pim rp-address 172.16.0.1, например). Об этом позже, пока примите как данность и смиритесь.

Проверим текущее состояние таблицы мультикастовой маршрутизации для группы 224.2.2.4:

После того, как на источнике вы запустите вещание, надо проверить таблицу ещё раз.

Давайте разберём этот немногословный вывод.

Запись вида (*, 225.0.1.1) называется (*, G), /читается старкомаджи/ и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик.
Если список нисходящих интерфейсов (OIL) пуст — Null, значит нет получателей — а мы их пока не запускали.

Запись (172.16.0.5, 225.0.1.1) называется (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.

Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной

Предположим, что уже настроены все IP-адреса в соответствии со схемой. На сети запущен IGP для обычной юникастовой маршрутизации.
Клиент1, например, может пинговать Сервер-источник.

Но пока не запущен PIM, IGMP, клиенты не запрашивают каналы.

Итак, момент времени 0.

Включаем мультикастовую маршрутизацию на всех пяти маршрутизаторах:

 RX(config)#ip multicast-routing

PIM включается непосредственно на всех интерфейсах всех маршрутизаторов (в том числе на интерфейсе в сторону Сервера-источника и клиентов):

 RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode

IGMP, по идее должен включаться на интерфейсах в сторону клиентов, но, как мы уже отметили выше, на оборудовании Cisco он включается автоматически вместе с PIM.

Первое, что делает PIM — устанавливает соседство. Для этого используются сообщения PIM Hello. При активации PIM на интерфейсе с него отправляется PIM Hello на адрес 224.0.0.13 с TTL равным 1. Это означает, что соседями могут быть только маршрутизаторы, находящиеся в одном широковещательном домене.

Как только соседи получили приветствия друг от друга:

Теперь они готовы принимать заявки на мультикастовые группы.

Если мы сейчас запустим в вольер клиентов с одной стороны и включим мультикастовый поток с сервера с другой, то R1 получит поток трафика, а R4 получит IGMP Report при попытке клиента подключиться. В итоге R1 не будет знать ничего о получателях, а R4 об источнике.

Неплохо было бы если бы информация об источнике и о клиентах группы была собрана где-то в одном месте. Но в каком?

Такая точка встречи называется Rendezvous Point — RP. Это центральное понятие PIM SM. Без неё ничего бы не работало. Здесь встречаются источник и получатели.
Все PIM-маршрутизаторы должны знать, кто является RP в домене, то есть знать её IP-адрес.

1. отвечает за изучение источника,
2. является точкой притяжения сообщений Join от всех заинтересованных.

Пусть пока R2 будет выполнять роль RP.
Чтобы увеличить надёжность, обычно выбирается адрес Loopback-интерфейса. Поэтому на всех маршрутизаторах выполняется команда:

 RX(config)#ip pim rp-address 2.2.2.2

Естественно, этот адрес должен быть доступен по таблице маршрутизации со всех точек.
Ну и поскольку адрес 2.2.2.2 является RP, на интерфейсе Loopback 0 на R2 желательно тоже активировать PIM.

 R2(config)#interface Loopback 0 RX(config-if)#ip pim sparse-mode

Сразу после этого R4 узнает об источнике трафика для группы 224.2.2.4:

и даже передаёт трафик:

На интерфейс FE0/1 приходит 362000 б/с, и через интерфейс FE0/0 они передаются.

Всё, что мы сделали:
Включили возможность маршрутизации мультикастового трафика (ip multicast-routing)
Активировали PIM на интерфейсах (ip pim sparse-mode)
Указали адрес RP (ip pim rp-adress X.X.X.X)

Всё, это уже рабочая конфигурация и можно приступать к разбору, ведь за кулисами скрывается гораздо больше, чем видно на сцене.
Полная конфигурация с PIM.

Разбор полётов

Ну так и как же в итоге всё работает? Как RP узнаёт где источник, где клиенты и обеспечивает связь между ними?

Поскольку всё затевается ради наших любимых клиентов, то, начав с них, рассмотрим в деталях весь процесс.

1) Клиент 1 отправляет IGMP Report для группы 224.2.2.4

2) R4 получает этот запрос, понимает, что есть клиент за интерфейсом FE0/0, добавляет этот интерфейс в OIL и формирует запись (*, G).

Здесь видно восходящий интерфейс FE0/1, но это не значит, что R4 получает трафик для группы 224.2.2.4. Это говорит лишь о том, что единственное место, откуда сейчас он может получать — FE0/1, потому что именно там находится RP. Кстати, здесь же указан и сосед, который прошёл RPF-Check — R2: 10.0.2.24. Ожидаемо.

R4 называется — LHR (Last Hop Router) — последний маршрутизатор на пути мультикастового трафика, если считать от источника. Иными словами — это маршрутизатор, ближайший к получателю. Для Клиента1 — это R4, для Клиента2 — это R5.

3) Поскольку на R4 пока нет мультикастового потока (он его не запрашивал прежде), он формирует сообщение PIM Join и отправляет его в сторону RP (2.2.2.2).

PIM Join отправляется мультикастом на адрес 224.0.0.13. «В сторону RP» означает через интерфейс, который указан в таблице маршрутизации, как outbound для того адреса, который указан внутри пакета. В нашем случае это 2.2.2.2 — адрес RP. Такой Join обозначается ещё как Join (*,G) и говорит: «Не важно, кто источник, мне нужен трафик группы 224.2.2.4».
То есть каждый маршрутизатор на пути должен обработать такой Join и при необходимости отправить новый Join в сторону RP. (Важно понимать, что если на маршрутизаторе уже есть эта группа, он не будет отправлять выше Join — он просто добавит интерфейс, с которого пришёл Join, в OIL и начнёт передавать трафик).
В нашем случае Join ушёл в FE0/1:

4) R2, получив Join, формирует запись (*, G) и добавляет интерфейс FE0/0 в OIL. Но Join отсылать уже некуда — он сам уже RP, а про источник пока ничего не известно.

Таким образом RP узнаёт о том, где находятся клиенты.

Если Клиент 2 тоже захочет получать мультикастовый трафик для той же группы, R5 отправит PIM Join в FE0/1, потому что за ним находится RP, R3, получив его, формирует новый PIM Join и отправляет в FE1/1 — туда, где находится RP.
То есть Join путешествует так узел за узлом, пока не доберётся до RP или до другого маршрутизатора, где уже есть клиенты этой группы.

Итак, R2 — наш RP — сейчас знает о том, что за FE0/0 и FE1/0 у него есть получатели для группы 224.2.2.4.
Причём неважно, сколько их там — по одному за каждым интерфейсом или по сто — поток трафика всё равно будет один на интерфейс.

Если изобразить графически то, что мы получили, то это будет выглядеть так:

Отдалённо напоминает дерево, не так ли? Поэтому оно так и называется — RPT — Rendezvous Point Tree. Это дерево с корнем в RP, а ветви которого простираются до клиентов.
Более общий термин, как мы упоминали выше, — MDT — Multicast Distribution Tree — дерево, вдоль которого распространяется мультикастовый поток. Позже вы увидите разницу между MDT и RPT.

5) Теперь врубаем сервер. Как мы уже выше обсуждали, он не волнуется о PIM, RP, IGMP — он просто вещает. А R1 получает этот поток. Его задача — доставить мультикаст до RP.
В PIM есть специальный тип сообщений — Register. Он нужен для того, чтобы зарегистрировать источник мультикаста на RP.
Итак, R1 получает мультикастовый поток группы 224.2.2.4:

R1 является FHR (First Hop Router) — первый маршрутизатор на пути мультикастового трафика или ближайший к источнику.

6) Далее он инкапсулирует каждый полученный от источника мультикастовый пакет в юникастовый PIM Register и отправляет его прямиком на RP.

Обратите внимание на стек протоколов. Поверх юникастового IP и заголовка PIM идёт изначальный мультикастовый IP, UDP и данные.
Теперь, в отличие от всех других, пока известных нам сообщений PIM, в адресе получателя указан 2.2.2.2, а не мультикастовый адрес.

Такой пакет доставляется до RP по стандартным правилам юникастовой маршрутизации и несёт в себе изначальный мультикастовый пакет, то есть это… это же туннелирование!

На сервере 172.16.0.5 работает приложение, которое может передавать пакеты только на широковещательный адрес 255.255.255.255, с портом получателя UDP 10999.

Этот трафик надо доставить к клиентам 1 и 2:
Клиенту 1 в виде мультикаст трафика с адресом группы 239.9.9.9.
А в сегмент клиента 2, в виде широковещательных пакетов на адрес 255.255.255.255.

7) RP получает PIM Register, распаковывает его и обнаруживает под обёрткой трафик для группы 224.2.2.4.
Информацию об этом он сразу заносит в свою таблицу мультикастовой маршрутизации:

Появилась запись (S, G) — (172.16.0.5, 224.2.2.4).
Распакованные пакеты RP дальше отправляет в RPT в интерфейсы FE0/0 и FE1/0, по которому трафик доходит до клиентов.

1. Процессы инкапсуляции и декапсуляции — весьма затратные действия для маршрутизаторов. Кроме того, дополнительные заголовки увеличивают размер пакета, и он может просто не пролезть в MTU где-то на промежуточном узле (вспоминаем все проблемы туннелирования).
2. Если вдруг где-то между источником и RP есть ещё получатели для группы, мультикастовому трафику придётся пройти один путь дважды.

Трафик в сообщениях Register сначала дойдёт до RP по линии R1-R42-R2, затем чистый мультикаст вернётся по линии R2-R42. Таким образом на линии R42-R2 будет ходить две копии одного трафика, пусть и в противоположных направлениях.

Поэтому лучше от источника до RP тоже передавать чистый мультикаст, а для этого нужно построить дерево — Source Tree.

8) Поэтому RP отправляет на R1 сообщение PIM Join. Но теперь уже в нём указывается для группы адрес не RP, а источника, изученный из сообщения Register. Такое сообщение называется Join (S, G) — Source Specific Join.

Цель у него точно такая же, как у PIM Join (*, G) — построить дерево, только на этот раз от источника до RP.
Join (S, G) распространяется также узел за узлом, как обычный Join (*, G). Только Join (*, G) стремится к RP, а Join (S, G) к S — источнику. В качестве адрес получателя также служебный адрес 224.0.0.13 и TTL=1.

Если существуют промежуточные узлы, например, R42, они также формируют запись (S, G) и список нисходящих интерфейсов для данной группы и пересылают Join дальше к источнику.

Путь, по которому прошёл Join от RP до источника, превращается в Source Tree — дерево от источника. Но более распространённое название — SPT — Shortest Path Tree — ведь трафик от источника до RP пойдёт по кратчайшему пути.

9) R1 получив Join (S, G), добавляет интерфейс FE1/0, откуда пакет пришёл, в список нисходящих интерфейсов OIL и начинает туда вещать чистый мультикастовый трафик, незамутнённый инкапсуляцией. Запись (S, G) на R1 уже была, как только он получит первый мультикастовый пакет от Сервера-источник.

По построенному Source Tree мультикаст передаётся RP (и всем промежуточным клиентам, если они есть, например, R42).

Но надо иметь ввиду, что сообщения Register передавались всё это время и передаются до сих пор. То есть фактически R1 отправляет две копии трафика сейчас: один — чистый мультикаст по SPT, другой — инкапсулированный в юникастовый Register.

Сначала R1 отправляет мультикаст в Register — пакет 231. Потом R2 (RP) хочет подключиться к дереву, отправляет Join — пакет 232. R1 ещё какое-то время, пока обрабатывает запрос от R2, отправляет мультикаст в Register (пакеты с 233 по 238). Далее, когда нисходящий интерфейс добавлен в OIL на R1, он начинает передавать чистый мультикаст — пакеты 239 и 242, но пока не прекращает и Register — пакеты 241 и 243. А пакет 240 — это R2 не выдержал и ещё раз попросил построить дерево.

10) Итак, незамутнённый мультикаст достигает RP. Она понимает, что это тот же самый трафик, который приходит в Register, потому что одинаковый адрес группы, одинаковый адрес источника и с одного интерфейса. Чтобы не получать две копии, он отправляет на R1 юникастовый PIM Register-Stop.

Register-Stop не означает, что R2 отказывается от трафика или не признаёт больше этот источник, это говорит лишь о том, что надо прекратить посылать инкапсулированный трафик.

Далее идёт ожесточённая борьба — R1 продолжает передавать накопившийся в буфере трафик, пока обрабатывает Register-Stop, и обычным мультикастом и внутри сообщений Register:

Но, рано или поздно R1 начинает вещать только чистый мультикастовый трафик.

При подготовке у меня возник, как мне казалось, закономерный вопрос: ну и к чему все эти туннелирования, PIM Register? Почему бы не поступать с мультикастовым трафиком, как с PIM Join — отправлять хоп за хопом с TTL=1 в сторону RP — рано или поздно ведь дойдёт? Так бы и дерево построилось бы заодно без лишних телодвижений.
Тут возникает несколько нюансов.
Во-первых, нарушается главный принцип PIM SM — трафик посылать только туда, откуда он был запрошен. Нет Join — Нет дерева!
Во-вторых, если клиентов для данной группы нет, FHR не узнает об этом и будет продолжать слать трафик по «своему дереву». К чему такое бездумное использование полосы пропускания? В мире связи такой протокол просто не выжил бы, как не выжил PIM DM или DVMRP.

Таким образом мы имеем одно большое дерево MDT для группы 224.2.2.4 от Cервера-источника до Клиента 1 и Клиента 2. И это MDT составлено из двух кусков, которые строились независимо друг от друга: Source Tree от источника до RP и RPT от RP до клиентов. Вот оно отличие MDT от RPT и SPT. MDT — это довольно общий термин, означающий дерево передачи мультикаста вообще, в то время, как RPT/SPT — это его очень конкретный вид.

А что делать, если сервер уже вещает, а клиентов всё нет и нет? Мультикаст так и будет засорять участок между отправителем и RP?
Нет, в этом случае также поможет PIM Register-Stop. Если на RP начали приходить сообщения Register для какой-то группы, а для неё ещё нет получателей, то RP не заинтересован в получении этого трафика, поэтому, не отправляя PIM Join (S, G), RP сразу посылает Register-Stop на R1.
R1, получив Register-Stop и видя, что дерева для этой группы пока нет (нет клиентов), начинает отбрасывать мультикастовый трафик от сервера.
То есть сам сервер по этому поводу совершенно не беспокоится и продолжает посылать поток, но, дойдя до интерфейса маршрутизатора, поток будет отброшен.
При этом RP продолжает хранить запись (S, G). То есть трафик он не получает, но где находится источник для группы знает. Если в группе появляются получатели, RP узнаёт о них и посылает на источник Join (S, G), который строит дерево.

Кроме того, каждые 3 минуты R1 будет пытаться повторно зарегистрировать источник на RP, то есть отправлять пакеты Register. Это нужно для того, чтобы уведомить RP о том, что этот источник ещё живой.

У особо пытливых читателей обязан возникнуть вопрос — а как быть с RPF? Этот механизм ведь проверяет адрес отправителя мультикастового пакета и, если трафик идёт не с правильного интерфейса, он будет отброшен. При этом RP и источник могут находиться за разными интерфейсам. Вот и в нашем примере для R3 RP — за FE1/1, а источник — за FE1/0.
Ответ предсказуем — в таком случае проверяется не адрес источника, а RP. То есть трафик должен придти с интерфейса в сторону RP.
Но, как вы увидите далее, это тоже не нерушимое правило.

Важно понимать, что RP — это не универсальный магнит — для каждой группы может бытья своя RP. То есть в сети их может быть и две, и три, и сто — одна RP отвечает за один набор групп, другая — за другой. Более того, есть такое понятие, как Anycast RP и тогда разные RP могут обслуживать одну и ту же группу.

Замечание к топологии: в этой задаче только маршрутизаторы R1, R2, R3 находятся под управлением администраторов нашей сети. То есть, конфигурацию изменять можно только на них.

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1 и 239.2.2.2.

Настроить сеть таким образом, чтобы трафик группы 239.1.1.1 не передавался в сегмент между R3 и R5, и во все сегменты ниже R5.
Но при этом, трафик группы 239.2.2.2 должен передаваться без проблем.

Бритва Оккама или отключение ненужных ветвей

После того, как последний клиент в сегменте отказался от подписки, PIM должен отрезать лишнюю ветку RPT.
Пусть, например, единственный клиент на R4 выключил компьютер. Маршрутизатор по сообщению IGMP Leave или после трёх безответных IGMP Query понимает, что клиентов за FE0/0 больше нет, и отправляет в сторону RP сообщение PIM Prune. По формату оно точно такое же, как Join, но выполняет противоположную функцию.
Адрес назначения также 224.0.0.13, и TTL равен 1.

Но маршрутизатор, получивший PIM Prune, перед тем, как удалить подписку, ждёт некоторое время (обычно 3 секунды — Join Delay Timer).
Это сделано вот для такой ситуации:

В одном широковещательном домене 3 маршрутизатора. Один из них стоит выше и именно он передаёт в сегмент мультикастовый трафик. Это R1. Для обоих маршрутизаторов (R2 и R3) его OIL содержит только одну запись.

Если теперь R2 решит отключиться и отправит PIM Prune, то он может подставить своего коллегу R3 — R1 ведь перестанет вещать в интерфейс вообще.
Так вот, чтобы этого не произошло, R1 и даёт таймаут в 3 секунды. За это время R3 должен успеть среагировать. Учитывая широковещательность сети, он тоже получит Prune от R2 и поэтому, если хочет продолжать получать трафик, он мгновенно отправляет обычный PIM Join в сегмент, уведомляя R1, что не надо удалять интерфейс.

Этот процесс называется — Prune Override. R2 как бы объегорил R1, перехватил инициативу.

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 в сторону источника и оптимизировать маршрут?

Зрите в корень. Такое переключение может инициировать LHR (Last Hop Router) — R5. После получения первого мультикастового пакета от R3 R5 отправляет уже знакомый нам Source Specific Join (S, G) в интерфейс FE0/1, который указан в его таблице маршрутизации, как исходящий для сети 172.16.0.0/24.

Получив такой 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)

В этом случае во второй раз изменяется правило работы RPF — он снова проверяет местонахождение источника. То есть из двух потоков мультикаста — от RP и от источника — предпочтение отдаётся трафику от источника.

DR, Assert, Forwarder

Ещё несколько важных моментов при рассмотрении PIM.

DR — Designated Router.
Это выделенный маршрутизатор, который ответственен за отправку служебных пакетов на RP.
Source DR — отвечает за принятие мультикастовых пакетов непосредственно от источника и его регистрацию на RP.
Вот пример топологии:

Здесь ни к чему, чтобы оба маршрутизатора передавали трафик на RP, пусть они резервируют друг друга, но ответственный должен быть только один.
Поскольку оба маршрутизатора подключены в одну широковещательную сеть, они получают друг от друга PIM-Hello. На основе него они и делают свой выбор.
PIM Hello несёт значение приоритета данного маршрутизатора на данном интерфейсе.

Чем больше значение, тем выше приоритет. Если они одинаковы, то выбирается узел с наибольшим IP-адресом (тоже из сообщения Hello).

Если другой маршрутизатор (не DR) в течение Holdtime (по умолчанию 105 с) не получал Hello от соседа, он автоматически берёт на себя роль DR.

Receiver DR — то же, что Source DR, только для получателей мультикастового трафика — LHR (Last Hop Router).
Пример топологии:

Receiver DR ответственен за отправку на RP PIM Join. В вышеприведённой топологии, если оба маршрутизатора отправят Join, то оба будут получать мультикастовый трафик, но в этом нет необходимости. Только DR отправляет Join. Второй просто мониторит доступность DR.
Поскольку DR отправляет Join, то он же и будет вещать трафик в LAN. Но тут возникает закономерный вопрос — а что, если PIM DR’ом стал один, а IGMP Querier’ом другой? А ситуация-то вполне возможна, ведь для Querier чем меньше IP, тем лучше, а для DR, наоборот.
В этом случае DR’ом выбирается тот маршрутизатор, который уже является Querier и такая проблема не возникает.

Правила выбора Receiver DR точно такие же, как и Source DR.

Assert и PIM Forwarder
Проблема двух одновременно передающих маршрутизаторов может возникнуть и в середине сети, где нет ни конечных клиентов, ни источников — только маршрутизаторы.
Очень остро этот вопрос стоял в PIM DM, где это была совершенно рядовая ситуация из-за механизма Flood and Prune.
Но и в PIM SM она не исключена.
Рассмотрим такую сеть:

Здесь три маршрутизатора находятся в одном сегменте сети и, соответственно, являются соседями по PIM. R1 выступает в роли RP.
R4 отправляет PIM Join в сторону RP. Поскольку этот пакет мультикастовый он попадает и на R2 и на R3, и оба они обработав его, добавляют нисходящий интерфейс в OIL.
Тут бы должен сработать механизм выбора DR, но и на R2 и на R3 есть другие клиенты этой группы, и обоим маршрутизаторам так или иначе придётся отправлять PIM Join.
Когда мультикастовый трафик приходит от источника на R2 и R3, в сегмент он передаётся обоими маршрутизаторами и задваивается там. PIM не пытается предотвратить такую ситуацию — тут он действует по факту свершившегося преступления — как только в свой нисходящий интерфейс для определённой группы (из списка OIL) маршрутизатор получает мультикастовый трафик этой самой группы, он понимает: что-то не так — другой отправитель уже есть в этом сегменте.

Тогда маршрутизатор отправляет специальное сообщение PIM Assert.
Такое сообщение помогает выбрать PIM Forwarder — тот маршрутизатор, который вправе вещать в данном сегменте.

Не надо его путать с PIM DR. Во-первых, PIM DR отвечает за отправку сообщений PIM Join и Prune, а PIM Forwarder — за отправку трафика. Второе отличие — PIM DR выбирается всегда и в любых сетях при установлении соседства, А PIM Forwrder только при необходимости — когда получен мультикастовый трафик с интерфейса из списка OIL.

Выбор RP

Выше мы для простоты задавали RP вручную командой ip pim rp-address X.X.X.X.
И вот как выглядела команда show ip pim rp:

Но представим совершенно невозможную в современных сетях ситуацию — R2 вышел из строя. Это всё — финиш. Клиент 2 ещё будет работать, поскольку произошёл SPT Switchover, а вот всё новое и всё, что шло через RP сломается, даже если есть альтернативный путь.
Ну и нагрузка на администратора домена. Представьте себе: на 50 маршрутизаторах перебить вручную как минимум одну команду (а для разных групп ведь могут быть разные RP).

Динамический выбор RP позволяет и избежать ручной работы и обеспечить надёжность — если одна RP станет недоступна, в бой вступит сразу же другая.

В данный момент существует один общепризнанный протокол, позволяющий это сделать — Bootstrap. Циска в прежние времена продвигала несколько неуклюжий Auto-RP, но сейчас он почти не используется, хотя циска этого не признаёт, и в show ip mroute мы имеем раздражающий рудимент в виде группы 224.0.1.40.

Надо на самом деле отдать должное протоколу Auto-RP. Он был спасением в прежние времена. Но с появлением открытого и гибкого Bootstrap, он закономерно уступил свои позиции.

Итак, предположим, что в нашей сети мы хотим, чтобы R3 подхватывал функции RP в случае выхода из строя R2.
R2 и R3 определяются как кандидаты на роль RP — так они и называются C-RP. На этих маршрутизаторах настраиваем:

 RX(config)interface Loopback 0 RX(config-if)ip pim sparse-mode RX(config-if)exit RX(config)#ip pim rp-candidate loopback 0 

Но пока ничего не происходит — кандидаты пока не знают, как уведомить всех о себе.

Чтобы информировать все мультикастовые маршрутизаторы домена о существующих RP вводится механизм BSR — BootStrap Router. Претендентов может быть несколько, как и C-RP. Они называются соответственно C-BSR. Настраиваются они похожим образом.

Пусть BSR у нас будет один и для теста (исключительно) это будет R1.

 R1(config)interface Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0 

Сначала из всех C-BSR выбирается один главный BSR, который и будет всем заправлять. Для этого каждый C-BSR отправляет в сеть мультикастовый BootStrap Message (BSM) на адрес 224.0.0.13 — это тоже пакет протокола PIM. Его должны принять и обработать все мультикастовые маршрутизаторы и после разослать во все порты, где активирован PIM. BSM передаётся не в сторону чего-то (RP или источника), в отличии, от PIM Join, а во все стороны. Такая веерная рассылка помогает достигнуть BSM всех уголков сети, в том числе всех C-BSR и всех C-RP. Для того, чтобы BSM не блуждали по сети бесконечно, применяется всё тот же механизм RPF — если BSM пришёл не с того интерфейса, за которым находится сеть отправителя этого сообщения, такое сообщение отбрасывается.

С помощью этих BSM все мультикастовые маршрутизаторы определяют самого достойного кандидата на основе приоритетов. Как только C-BSR получает BSM от другого маршрутизатора с бОльшим приоритетом, он прекращает рассылать свои сообщения. В результате все обладают одинаковой информацией.

На этом этапе, когда выбран BSR, благодаря тому, что его BSM разошлись уже по всей сети, C-RP знают его адрес и юникастом отправляют на него сообщения Candidte-RP-Advertisement, в которых они несут список групп, которые они обслуживают — это называется group-to-RP mapping. BSR все эти сообщения агрегирует и создаёт RP-Set — информационную таблицу: какие RP каждую группу обслуживают.

Далее BSR в прежней веерной манере рассылает те же BootStrap Message, которые на этот раз содержат RP-Set. Эти сообщения успешно достигают всех мультикастовых маршрутизаторов, каждый из которых самостоятельно делает выбор, какую RP нужно использовать для каждой конкретной группы.

BSR периодически делает такие рассылки, чтобы с одной стороны все знали, что информация по RP ещё актуальна, а с другой C-BSR были в курсе, что сам главный BSR ещё жив.
RP, кстати, тоже периодически шлют на BSR свои анонсы Candidate-RP-Advertisement.

Фактически всё, что нужно сделать для настройки автоматического выбора RP — указать C-RP и указать C-BSR — не так уж много работы, всё остальное за вас сделает PIM.
Как всегда, в целях повышения надёжности рекомендуется указывать интерфейсы Loopback в качестве кандидатов.

Завершая главу PIM SM, давайте ещё раз отметим важнейшие моменты

1. Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
2. Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента — нет дерева.
3. RPF помогает избежать петель.
4. Все маршрутизаторы должны знать о том, кто является RP — только с её помощью можно построить дерево.
5. Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
6. В первой фазе строится RPT — дерево от клиентов до RP — и Source Tree — дерево от источника до RP. Во второй фазе происходит переключение с построенного RPT на SPT — кратчайший путь от получателя до источника.

Ещё перечислим все типы деревьев и сообщений, которые нам теперь известны.

MDT — Multicast Distribution Tree. Общий термин, описывающий любое дерево передачи мультикаста.
SPT — Shortest Path Tree. Дерево с кратчайшим путём от клиента или RP до источника. В PIM DM есть только SPT. В PIM SM SPT может быть от источника до RP или от источника до получателя после того, как произошёл SPT Switchover. Обозначается записью (S, G) — известен источник для группы.
Source Tree — то же самое, что SPT.
RPT — Rendezvous Point Tree. Дерево от RP до получателей. Используется только в PIM SM. Обозначается записью (*, G).
Shared Tree — то же, что RPT. Называется так потому, что все клиенты подключены к одному общему дереву с корнем в RP.

Типы сообщений PIM Sparse Mode:
Hello — для установления соседства и поддержания этих отношений. Также необходимы для выбора DR.
Join (*, G) — запрос на подключение к дереву группы G. Не важно кто источник. Отправляется в сторону RP. С их помощью строится дерево RPT.
Join (S, G) — Source Specific Join. Это запрос на подключение к дереву группы G с определённым источником — S. Отправляется в сторону источника — S. С их помощью строится дерево SPT.
Prune (*, G) — запрос на отключение от дерева группы G, какие бы источники для неё не были. Отправляется в сторону RP. Так обрезается ветвь RPT.
Prune (S, G) — запрос на отключение от дерева группы G, корнем которого является источник S. Отправляется в сторону источника. Так обрезается ветвь SPT.
Register — специальное сообщение, внутри которого передаётся мультикаст на RP, пока не будет построено SPT от источника до RP. Передаётся юникастом от FHR на RP.
Register-Stop — отправляется юникастом с RP на FHR, приказывая прекратить посылать мультикастовый трафик, инкапсулированный в Register.
Bootstrap — пакеты механизма BSR, которые позволяют выбрать маршрутизатор на роль BSR, а также передают информацию о существующих RP и группах.
Assert — сообщение для выбора PIM Forwarder, чтобы в один сегмент не передавали трафик два маршрутизатора.
Candidate-RP-Advertisement — сообщение, в котором RP отсылает на BSR информацию о том, какие группы он обслуживает.
RP-Reachable — сообщение от RP, которым она уведомляет всех о своей доступности.
*Есть и другие типы сообщений в PIM, но это уже детали*

А давайте теперь попытаемся абстрагироваться от деталей протокола? И тогда становится очевидной его сложность.

1) Определение RP,
2) Регистрация источника на RP,
3) Переключение на дерево SPT.

Много состояний протокола, много записей в таблице мультикастовой маршрутизации. Можно ли что-то с этим сделать?

На сегодняшний день существует два диаметрально противоположных подхода к упрощению PIM: SSM и BIDIR PIM.

SSM

• Поиска RP (протоколы Bootstrap и Auto-RP),
• Регистрации источника на мультикасте (а это лишнее время, двойное использование полосы пропускания и туннелирование)
• Переключения на SPT.

Кроме того, возможный вектор атаки в сети с активированной мультикастовой маршрутизацией — подключение злоумышленником своего источника и генерирование большого объёма мультикастового трафика, который перегрузит сеть. В SSM такое практически исключено.

Для SSM выделен специальный диапазон IP-адресов: 232.0.0.0/8.
На маршрутизаторах для поддержки SSM включается режим PIM SSM.

Router(config)# ip pim ssm

• Запрашивать подключение к просто группе, без указания источников. То есть работает как типичный ASM.
• Запрашивать подключение к группе с определённым источником. Источников можно указать несколько — до каждого из них будет построено дерево.
• Запрашивать подключение к группе и указать список источников, от которых клиент не хотел бы получать трафик

IGMPv1/v2, MLDv1 не поддерживают SSM, но имеет место такое понятие, как SSM Mapping. На ближайшем к клиенту маршрутизаторе (LHR) каждой группе ставится в соответствие адрес источника (или несколько). Поэтому если в сети есть клиенты, не поддерживающие IGMPv3/MLDv2, для них также будет построено SPT, а не RPT, благодаря тому, что адрес источника всё равно известен.
SSM Mapping может быть реализован как статической настройкой на LHR, так и посредством обращения к DNS-серверу.

Проблема SSM в том, что клиенты должны заранее знать адреса источников — никакой сигнализацией они им не сообщаются.
Поэтому SSM хорош в тех ситуациях, когда в сети определённый набор источников, их адреса заведомо известны и не будут меняться. А клиентские терминалы или приложения жёстко привязаны к ним.
Иными словами IPTV — весьма пригодная среда для внедрения SSM. Это хорошо описывает концепцию One-to-Many — один источник, много получателей.

BIDIR PIM

А что если в сети источники могут появляться спонтанно то там, то тут, вещать на одинаковые группы, быстро прекращать передачу и исчезать?
Например, такая ситуация возможна в сетевых играх или в ЦОД, где происходит репликация данных между различными серверами. Это концепция Many-to-Many — много источников, много клиентов.
Как на это смотрит обычный PIM SM? Понятное дело, что инертный PIM SSM здесь совсем не подходит?
Вы только подумайте, какой хаос начнётся: бесконечные регистрации источников, перестроение деревьев, огромное количество записей (S, G) живущих по несколько минут из-за таймеров протокола.
На выручку идёт двунаправленный PIM (Bidirectional PIM, BIDIR PIM). В отличие от SSM в нём напротив полностью отказываются от SPT и записей (S,G) — остаются только Shared Tree с корнем в RP.
И если в обычном PIM, дерево является односторонним — трафик всегда передаётся от источника вниз по SPT и от RP вниз по RPT — есть чёткое деление, где источник, где клиенты, то в двунаправленном от источника трафик к RP передаётся также вверх по Shared Tree — по тому же самому, по которому трафик течёт вниз к клиентам.

Это позволяет отказаться от регистрации источника на RP — трафик передаётся безусловно, без какой бы то ни было сигнализации и изменения состояний. Поскольку деревьев SPT нет вообще, то и SPT Switchover тоже не происходит.

Источник1 начал передавать в сеть трафик группы 224.2.2.4 одновременно с Источником2. Потоки от них просто полились в сторону RP. Часть клиентов, которые находятся рядом начали получать трафик сразу, потому что на маршрутизаторах есть запись (*, G) (есть клиенты). Другая часть получает трафик по Shared Tree от RP. Причём получают они трафик от обоих источников одновременно.
То есть, если взять для примера умозрительную сетевую игру, Источник1 это первый игрок в стрелялке, который сделал выстрел, а Источник2 — это другой игрок, который сделал шаг в сторону. Информация об этих двух событиях распространилась по всей сети. И каждый другой игрок (Получатель) должен узнать об обоих этих событиях.

Если помните, то чуть раньше мы объяснили, зачем нужен процесс регистрации источника на RP — чтобы трафик не занимал канал, когда нет клиентов, то есть RP просто отказывался от него. Почему над этой проблемой мы не задумываемся сейчас? Причина проста: BIDIR PIM для ситуаций, когда источников много, но они вещают не постоянно, а периодически, относительно небольшими кусками данных. То есть канал от источника до RP не будет утилизироваться понапрасну.

Обратите внимание, что на изображении выше между R5 и R7 есть прямая линия, гораздо более короткая, чем путь через RP, но она не была использована, потому что Join идут в сторону RP согласно таблице маршрутизации, в которой данный путь не является оптимальным.

Выглядит довольно просто — нужно отправлять мультикастовые пакеты в направлении RP и всё, но есть один нюанс, который всё портит — RPF. В дереве RPT он требует, чтобы трафик приходил от RP и не иначе. А у нас он может приходить откуда угодно. Взять и отказаться от RPF мы, конечно, не можем — это единственный механизм, который позволяет избежать образования петель.

Поэтому в BIDIR PIM вводится понятие DF — Designated Forwarder. В каждом сегменте сети, на каждой линии на эту роль выбирается тот маршрутизатор, чей маршрут до RP лучше.
В том числе это делается и на тех линиях, куда непосредственно подключены клиенты. В BIDIR PIM DF автоматически является DR.

Список OIL формируется только из тех интерфейсов, на которых маршрутизатор был выбран на роль DF.

• Если запрос PIM Join/Leave приходит на тот интерфейс, который в данном сегменте является DF, он передаётся в сторону RP по стандартным правилам.
  Вот, например, R3. Если запросы пришли в DF интерфейсы, что помечены красным кругом, он их передаёт на RP (через R1 или R2, в зависимости от таблицы маршрутизации).
• Если запрос PIM Join/Leave пришёл на не DF интерфейс, он будет проигнорирован.
  Допустим, что клиент, находящийся между R1 и R3, решил подключиться и отправил IGMP Report. R1 получает его через интерфейс, где он выбран DF (помечен красным кругом), и мы возвращаемся к предыдущему сценарию. А R3 получает запрос на интерфейс, который не является DF. R3 видит, что тут он не лучший, и игнорирует запрос.
• Если мультикастовый трафик пришёл на DF интерфейс, он будет отправлен в интерфейсы из списка OIL и в сторону RP.
  Например, Источник1 начал передавать трафик. R4 получает его в свой DF интерфейс и передаёт его и в другой DF-интерфейс — в сторону клиента и в сторону RP, — это важно, потому что трафик должен попасть на RP и распространиться по всем получателям. Также поступает и R3 — одна копия в интерфейсы из списка OIL — то есть на R5, где он будет отброшен из-за проверки RPF, и другая — в сторону RP.
• Если мультикастовый трафик пришёл на не DF интерфейс, он должен быть отправлен в интерфейсы из списка OIL, но не будет отправлен в сторону RP.
  К примеру, Источник2 начал вещать, трафик дошёл до RP и начал распространяться вниз по RPT. R3 получает трафик от R1, и он не передаст его на R2 — только вниз на R4 и на R5.

Таким образом DF гарантирует, что на RP в итоге будет отправлена только одна копия мультикастового пакета и образование петель исключено. При этом то общее дерево, в котором находится источник, естественно, получит этот трафик ещё до попадания на RP. RP, согласно обычным правилам разошлёт трафик во все порты OIL, кроме того, откуда пришёл трафик.

Кстати, нет нужды более и в сообщениях Assert, ведь DF выбирается в каждом сегменте. В отличие от DR он отвечает не только за отправку Join к RP, но и за передачу трафика в сегмент, то есть ситуация, когда два маршрутизатора передают в одну подсеть трафик, исключена в BIDIR PIM.

Пожалуй, последнее, что нужно сказать о двунаправленном PIM, это особенности работы RP. Если в PIM SM RP выполнял вполне конкретную функцию — регистрация источника, то в BIDIR PIM RP — это некая весьма условная точка, к которой стремится трафик с одной стороны и Join от клиентов с другой. Никто не должен выполнять декапсуляцию, запрашивать построение дерева SPT. Просто на каком-то маршрутизаторе вдруг трафик от источников начинает передаваться в Shared Tree. Почему я говорю «на каком-то»? Дело в том, что в BIDIR PIM RP — абстрактная точка, а не конкретный маршрутизатор, в качестве адреса RP вообще может выступать несуществующий IP-адрес — главное, чтобы он был маршрутизируемый (такая RP называется Phantom RP).

Все термины, касающиеся PIM, можно найти в глоссарии.

Мультикаст на канальном уровне

Итак, позади долгая трудовая неделя с недосыпами, переработками, тестами — вы успешно внедрили мультикаст и удовлетворили клиентов, директора и отдел продаж.
Пятница — не самый плохой день, чтобы обозреть творение и позволить себе приятный отдых.
Но ваш послеобеденный сон вдруг потревожил звонок техподдержки, потом ещё один и ещё — ничего не работает, всё сломалось. Проверяете — идут потери, разрывы. Всё сходится на одном сегменте из нескольких коммутаторов.

Расчехлили SSH, проверили CPU, проверили утилизацию интерфейсов и волосы дыбом — загрузка почти под 100% на всех интерфейсах одного VLAN’а. Петля! Но откуда ей взяться, если никаких работ не проводилось? Минут 10 проверки и вы заметили, что на восходящем интерфейсе к ядру у вас много входящего трафика, а на всех нисходящих к клиентам — исходящего. Для петли это тоже характерно, но как-то подозрительно: внедрили мультикаст, никаких работ по переключению не делали и скачок только в одном направлении.
Проверили список мультикастовых групп на маршрутизаторе — а там подписка на все возможные каналы и все на один порт — естественно, тот, который ведёт в этот сегмент.
Дотошное расследование показало, что компьютер клиента заражён и рассылает IGMP Query на все мультикастовые адреса подряд.

Потери пакетов начались, потому что коммутаторам пришлось пропускать через себя огромный объём трафика. Это вызвало переполнение буферов интерфейсов.

Главный вопрос — почему трафик одного клиента начал копироваться во все порты?

Причина этого кроется в природе мультикастовых MAC-адресов. Дело в том, пространство мультикастовых IP-адресов специальным образом отображается в пространство мультикастовых MAC-адресов. И загвоздка в том, что они никогда не будут использоваться в качестве MAC-адреса источника, а следовательно, не будут изучены коммутатором и занесены в таблицу MAC-адресов. А как поступает коммутатор с кадрами, адрес назначения которых не изучен? Он их рассылает во все порты. Что и произошло.
Это действие по умолчанию.

Мультикастовые MAC-адреса

Так какие же MAC-адреса получателей подставляются в заголовок Ethernet таких пакетов? Широковещательные? Нет. Существует специальный диапазон MAC-адресов, в которые отображаются мультикастовые IP-адреса.
Эти специальные адреса начинаются так: 0x01005e и следующий 25-й бит должен быть 0 (попробуйте ответить, почему так). Остальные 23 бита (напомню, всего их в МАС-адресе 48) переносятся из IP-адреса.

Здесь кроется некоторая не очень серьёзная, но проблема. Диапазон мультикастовых адресов определяется маской 224.0.0.0/4, это означает, что первые 4 бита зарезервированы: 1110, а оставшиеся 28 бит могут меняться. То есть у нас 2^28 мультикастовых IP-адресов и только 2^23 MAC-адресов — для отображения 1 в 1 не хватает 5 бит. Поэтому берутся просто последние 23 бита IP-адреса и один в один переносятся в MAC-адрес, остальные 5 отбрасываются.

Фактически это означает, что в один мультикастовый MAC-адрес будет отображаться 2^5=32 IP-адреса. Например, группы 224.0.0.1, 224.128.0.1, 225.0.0.1 и так до 239.128.0.1 все будут отображаться в один MAC-адрес 0100:5e00:0001.

Если взять в пример дамп потокового видео, то можно увидеть:

IP адрес — 224.2.2.4, MAC-адрес: 01:00:5E:02:02:04.

Есть также другие мультикастовые MAC-адреса, которые никак не относятся к IPv4-мультикаст (клик). Все они, кстати, характеризуются тем, что последний бит первого октета равен 1.

Естественно, ни на одной сетевой карте, не может быть настроен такой MAC-адрес, поэтому он никогда не будет в поле Source MAC Ethernet-кадра и никогда не попадёт в таблицу MAC-адресов. Значит такие кадры должны рассылаться как любой Unknown Unicast во все порты VLAN’а.

Всего, что мы рассматривали прежде, вполне достаточно для полноценной передачи любого мультикастового трафика от потокового видео до биржевых котировок. Но неужели мы в своём почти совершенном мире будем мирится с таким безобразием, как широковещательная передача того, что можно было бы передать избранным?
Вовсе нет. Специально для перфекционистов придуман механизм IGMP-Snooping.

IGMP-Snooping

Идея очень простая — коммутатор «слушает» проходящие через него IGMP-пакеты.
Для каждой группы отдельно он ведёт таблицу восходящих и нисходящих портов.

Если с порта пришёл IGMP Report для группы, значит там клиент, коммутатор добавляет его в список нисходящих для этой группы.
Если с порта пришёл IGMP Query для группы, значит там маршрутизатор, коммутатор добавляет его в список восходящих.

Таким образом формируется таблица передачи мультикастового трафика на канальном уровне.
В итоге, когда сверху приходит мультикастовый поток, он копируется только в нисходящие интерфейсы. Если на 16-портовом коммутаторе только два клиента, только им и будет доставлен трафик.

Гениальность этой идеи заканчивается тогда, когда мы задумываемся о её природе. Механизм предполагает, что коммутатор должен прослушивать трафик на 3-м уровне.

Впрочем, IGMP-Snooping ни в какое сравнение не идёт с NAT по степени игнорирования принципов сетевого взаимодействия. Тем более, кроме экономии в ресурсах, он несёт в себе массу менее очевидных возможностей. Да и в общем-то в современном мире, коммутатор, который умеет заглядывать внутрь IP — явление не исключительное.

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1, 239.2.2.2 и 239.0.0.x.
Настроить сеть таким образом, чтобы:
— клиент 1 не мог присоединиться к группе 239.2.2.2. Но при этом мог присоединиться к группе 239.0.0.x.
— клиент 2 не мог присоединиться к группе 239.1.1.1. Но при этом мог присоединиться к группе 239.0.0.x.

IGMP Snooping Proxy

У пытливого читателя может возникнуть вопрос по тому, как IGMP Snooping узнаёт все клиентские порты, учитывая, что на IGMP Query отвечает только один самый быстрый клиент, как мы говорили выше. А очень просто: IGMP-Snooping не позволяет сообщениям Report ходить между клиентами. Они отправляются только в восходящие порты к маршрутизаторам. Не видя Report от других получателей этой группы, клиент обязан ответить на Query в течение Max Response Time, указанном в этом Query.
В итоге в сети на 1000 узлов на один IGMP Query в течение секунд 10 (обычное значение Max Response Time) придёт 1000 Report’ов маршрутизатору. Хотя ему достаточно было бы и одного для каждой группы.
И происходит это каждую минуту.

В этом случае можно настроить проксирование IGMP-запросов. Тогда коммутатор не просто «слушает» проходящие пакеты, он их перехватывает.

Правила работы IGMP-Snooping могут отличаться для разных производителей. Поэтому рассмотрим их концептуально:

1) Если на коммутатор приходит самый первый запрос Report на группу, он отправляется вверх к маршрутизатору, а интерфейс вносится в список нисходящих. Если же такая группа уже есть, интерфейс просто добавляется в список нисходящих, а Report уничтожается.
2) Если на коммутатор приходит самый последний Leave, то есть других клиентов нет, этот Leave будет отправлен на маршрутизатор, а интерфейс удаляется из списка нисходящих. В противном случае просто удаляется интерфейс, Leave уничтожается.
3) Если IGMP Query приходит от маршрутизатора, коммутатор перехватывает его, отправляет в ответ IGMP Report для всех групп, которые в данный момент имеют получателей.
А дальше, в зависимости от настроек и производителя, либо этот же самый Query рассылается во все клиентские порты, либо коммутатор блокирует запрос от маршрутизатора и сам выступает в роли Querier, периодически опрашивая всех получателей.

Таким образом снижается и доля лишнего служебного трафика в сети и нагрузка на маршрутизатор.

Multicast VLAN Replication

Сокращённо MVR. Это механизм для тех провайдеров, кто практикует VLAN-per-user, например.
Вот типичный пример сети, где MVR жизненно необходим:

5 клиентов в разных VLAN’ах, и все хотят получать мультикастовый трафик одной группы 224.2.2.4. При этом клиенты должны оставаться изолированными друг от друга.

IGMP-Snooping учитывает, разумеется и VLAN’ы. Если пять клиентов в разных VLAN’ах запрашивают одну группу — это будет пять разных таблиц. Соответственно и к маршрутизатору идут 5 запросов на подключение к группе. И каждый сабинтерфейс из этих пяти на маршрутизаторе будет добавлен отдельно в OIL. То есть получив 1 поток для группы 224.2.2.4 он отправит 5 копий, несмотря на то, что все они идут в один сегмент.

Для решения этой проблемы и был разработан механизм Multicast VLAN Replication.
Вводится дополнительный VLAN — Multicast VLAN — в нём, соответственно, будет передаваться мультикастовый поток. Он «проброшен» непосредственно до последнего коммутатора, где трафик из него копируется во все клиентские интерфейсы, которые хотят получать этот трафик — это и есть репликация.
В зависимости от реализации репликация из Multicast VLAN может производиться в User-VLAN или в определённые физические интерфейсы.

А что с IGMP-сообщениями? Query от маршрутизатора, естественно, приходит по мультикастовому VLAN’у. Коммутатор их рассылает в клиентские порты. Когда Report или Leave приходит от клиента, коммутатор проверяет откуда именно (VLAN, интерфейс) и, если необходимо, перенаправляет в мультикастовый VLAN.
Таким образом обычный трафик изолирован и по-прежнему ходит до маршрутизатора в пользовательском VLAN’е. А мультикастовый трафик и IGMP-пакеты передаются в Multicast VLAN.

На оборудовании Cisco MVR и IGMP-Snooping настраиваются независимо. То есть можно отключить один и второй будет работать. Вообще же MVR основан на IGMP-Snooping и на коммутаторах других производителей для работы MVR может быть обязательным включение IGMP-Snooping.

Кроме того, IGMP-Snooping позволяет осуществлять на коммутаторах фильтрацию трафика, ограничивать количество групп, доступных пользователю, включение IGMP Querier, статическую настройку восходящих портов, перманентное подключение к какой-либо группе (этот сценарий есть в сопутствующем видео), быструю реакцию на изменение топологии путём рассылки дополнительных Query, SSM-Mapping для IGMPv2 итд.

Заканчивая разговор об IGMP-Snooping, хочется повторить — это необязательный функционал — всё и без него будет работать. Но это сделает сеть более предсказуемой, а жизнь инженера спокойнее.
Однако все плюсы IGMP Snooping можно обернуть и против себя. Один такой выдающийся случай можно почитать по ссылке.
К слову у той же Cisco есть протокол CGMP — аналог IGMP, который не нарушает принципы работы коммутатора, но он проприетарный и не сказать, что широко распространённый.

Итак, мой неутомимый читатель, мы приближаемся к концу выпуска и напоследок хочется показать, как может быть реализована услуга IPTV на стороне клиента.
Самый простой способ, к которому мы уже не раз обращались в этой статье — запустить плеер, который может принять мультикастовый поток из сети. На нём можно вручную задать IP-адрес группы и наслаждаться видео.
Другой программный вариант, который часто используют провайдеры — специальное приложение, обычно весьма кастомное, в котором зашит набор каналов, используемых в сети провайдера. Нет необходимости что-то задавать вручную — нужно просто переключать каналы кнопками.

Оба эти способа дают возможность смотреть потоковое видео только на компьютере.

Третий же вариант позволяет использовать телевизор, причём как правило, любой. Для этого в доме клиента ставит так называемый Set-Top-Box (STB) — коробочка, устанавливаемая на телевизор. Это шелезяка, которая включается в абонентскую линию и разделяет трафик: обычный юникаст она отдаёт в Ethernet или WiFi, чтобы клиенты имели доступ в Интернет, а мультикастовый поток передаётся на телевизор через кабель (DVI, RGB, антенный итд.).
Часто вы, кстати, можете увидеть рекламу, где провайдер предлагает свои приставки для подключения телевидения — это и есть те самые STB

Напоследок нетривиальная задачка по мультикасту (авторы не мы, в ответах будет ссылка на оригинал).

Самая простая схема:

С одной стороны сервер-источник, с дугой — компьютер, который готов принимать трафик.

Адрес мультикастового потока вы можете устанавливать сами.

И соответственно, два вопроса:
1. Что нужно сделать, чтобы компьютер мог получать поток и при этом не прибегать к мультикастовой маршрутизации?
2. Допустим, вы вообще не знаете, что такое мультикаст и не можете его настраивать, как передать поток от сервера к компьютеру?

Задача легко ищется в поисковике, но попробуйте решить её сами.

Незатронутыми в статье остались междоменная маршрутизация мультикастового трафика (MSDP, MBGP, BGMP), балансировка нагрузки между RP (Anycast RP), PGM, проприетарные протоколы. Но, я думаю, имея как точку старта эту статью, разобраться в остальном не составит труда.
Все термины, касающиеся мультикаста, вы можете найти в телекоммуникационном глоссарии lookmeup.

За помощь в подготовке статьи спасибо JDima…
За техническую поддержку спасибо Наташе Самойленко.
КДПВ нарисована Ниной Долгополовой — замечательным художником и другом проекта.

В пуле статей СДСМ ещё много интересного до окончания, поэтому не нужно хоронить цикл из-за долгого отсутствия выпуска — с каждой новой статьёй сложность значительно возрастает. Впереди почти весь MPLS, IPv6, QoS и дизайн сетей.

Как вы уже, наверно, заметили, у linkmeup появился новый проект — Глоссарий lookmeup (да, недалеко у нас ушла фантазия). Мы надеемся, что этот глоссарий станет самым полным справочником терминов в области связи, поэтому мы будем рады любой помощи в его заполнении. Пишите нам на info@linkmeup.ru

• Системное администрирование
• Сетевые технологии