Остановимся на анализе мультикаст-трафика через IGMP-протокол. Рассмотрим реализацию работы протокола IGMP, работы протокола PIM, отправки JOIN-запросов. После анализа проблемы была разработана оптимальная конфигурация сетевого оборудования, эффективная настройка QOS. Данная задача появилась после обнаружения проблемы в сети, такой как прерывание сигнала у клиентов, наличие фризов и прерывание звука.

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



Пользователь имеет подписку на следующую группу IP-адресов: 224.0.0.0 до 239.255.255.255. PIM Protocol реализован в режиме Sparse mode. Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join. Если клиенты не отправляют Join, то трафик им отправляться не будет. PIM Sparse Mode включен на двух интерфейсах. В сторону источника мультикаст-трафика и в сторону клиента. На стороне клиента имеет цифровой ресивер или абонентское устройство —IPTV-приставка.

Для справки: dense mode предполагает, что мультикаст-трафик идет до абонента, и неважно, подписывается ли он на определенный канал. Мультикаст идет во все порты, потом, если он не нужен по месту назначения, то отправляется служебный пакет PIM Prune, и трафик перестает идти по этой ветке.

IGMP-протокол реализуется в сторону клиента. PIM-протокол устанавливает соседство с другими маршрутизаторами. Для этого применяются служебные сообщения PIM Hello.

В нашей сети применялась вторая версия протокола IGMP.



Абонентское устройство, которое решает получить multicast-трафик, отправляет запрос в сообщении IGMP Membership Report (так называемый репорт).



Если абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа. IGMP Membership Group-Specific Query — повторное сообщение коммутатором в сеть о том, есть ли клиентские устройства, которые будут запрашивать мультикаст-трафик. Если их нет, то передача трафика прекращается.



IGMP snooping реализуется на сетевом оборудовании, отдельного включения функции недостаточно, необходима дополнительная настройка. После включения данной функции управляемые коммутаторы могут анализировать трафик — мультикаст-поток.

Если коммутатор обнаруживает IGMP-пакет, то он вносит порт в список мультикаст-групп. Если от абонента идет сообщение IGMP Leave, то коммутатор удаляет порт из подписчиков групп.
IGMP snooping позволяет предотвращать мультикаст шторм. Если функция IGMP snooping не включена, то оборудование ретранслирует multicast-трафик во все порты, которые находятся в одном VLAN. Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования. IGMP snooping улучшает работу сети.

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

Проверить корректность работы мультикаст-вещания можно путем анализа трафика через Wireshark, после включения телевидения через VLC-медиаплеер. В настройках VLC указываем, к примеру, udp:@239.255.0.A:5500. Для передачи потока используется UDP протокол, далее идет мультикаст адрес, далее порт.



При разработке QOS учитывалось, что «красить» трафик желательно ближе к ядру сети. Его необходимо красить ближе к Randezvous Point. (Ну это для нашего случая)

На коммутаторах уровня доступа у нас применялись следующие настройки:



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

Комментарии (5)


  1. xcore78
    07.11.2018 19:59

    эффективная настройка QOS


    К сожалению, не заметил в статье ничего про QoS, кроме упоминания факта «раскрашивания траффика». Очереди, их размеры, классы, шедулеры?

    PIM Protocol реализован в режиме Sparse mode


    Вы, наверное, имели в виду «настроен», а не «реализован».

    В нашей сети применялась вторая версия протокола IGMP.


    Применялась вторая версия потому, что?


  1. catersplay Автор
    07.11.2018 22:31

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


  1. catersplay Автор
    07.11.2018 22:39

    настройка QOS-да это отдельная тема, очень интересная и объемная, ей нужно отдельный раздел посвещать. На Nag кстати неплохие советы есть, которые можно реализовать


  1. DeeZ
    08.11.2018 14:09

    Мультикаст адрес в статье и на скрине не совпадает. Да и сам адрес странный 239.255.0.A

    Красить трафик не равно фильтровать. Крашенный трафик можно не обрабатывать вообще. крашенный трафик можно шейпить. Фильтровать это последнее что имеет смысл делать с крашеным трафиком. Тк это все таки приоретизация трафика — доставка, хоть и не в первой очереди.

    Получив лив коммутатор не исключает порт, а шлет запрос, не осталось ли еще получателей, и не получив ответа — исключает (и то не сразу).

    PIM — это не протокол.

    В статье куча ошибок и не точностей. И совсем не понятно что именно она раскрывает и как приручает мультикаст примером конфига коммутатора доступа.
    Даже как посмотреть join-ы на длинке не написали.


  1. catersplay Автор
    08.11.2018 16:16

    Protocol Independent Multicast (PIM) — это группа протоколов, которые занимаются маршрутизацией мультикаст.
    «Да и сам адрес странный 239.255.0.A» — Это пример