Приручаем multicast

    Остановимся на анализе мультикаст-трафика через 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 позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.
    ICL Services
    94.69
    Цифровые технологии для бизнеса
    Share post

    Comments 6

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


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

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


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

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


      Применялась вторая версия потому, что?
        0
        На всём сетевом оборудовании использовалась версия проткола igmp v2.
        Версия протокола 1 отличается тем, что в ней нет сообщений Leave. Если клиент не хочет получать мультикаст трафик группы, он просто перестаёт посылать Report в ответ на Query. Если не осталось клиентов, маршрутизатор по таймауту перестанет отправлять трафик.
          0
          настройка QOS-да это отдельная тема, очень интересная и объемная, ей нужно отдельный раздел посвещать. На Nag кстати неплохие советы есть, которые можно реализовать
            0
            Мультикаст адрес в статье и на скрине не совпадает. Да и сам адрес странный 239.255.0.A

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

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

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

            В статье куча ошибок и не точностей. И совсем не понятно что именно она раскрывает и как приручает мультикаст примером конфига коммутатора доступа.
            Даже как посмотреть join-ы на длинке не написали.
              0
              Protocol Independent Multicast (PIM) — это группа протоколов, которые занимаются маршрутизацией мультикаст.
              «Да и сам адрес странный 239.255.0.A» — Это пример
                0
                Эээээээ…
                Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join.

                Нет. Клиент ничего не знает про PIM и PIM Join не отправляет.
                сли абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа.

                IGMP Leave отправляет эндпоинт, какая функция реализована на коммутаторе? IGMP Leave?
                Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования.

                Почему загружает именно CPU? Датаплейн не трогает?
                И главное:
                Остановимся на анализе мультикаст-трафика через IGMP-протокол.

                Где собственно анализ? Что из заголовка здесь вообще есть?

                P.S. Лена еще давным-давно написала куда более понятный и логичный материал — habr.com/post/61466 вам стоило бы поучиться.

                Only users with full accounts can post comments. Log in, please.