Comments 6
эффективная настройка QOS
К сожалению, не заметил в статье ничего про QoS, кроме упоминания факта «раскрашивания траффика». Очереди, их размеры, классы, шедулеры?
PIM Protocol реализован в режиме Sparse mode
Вы, наверное, имели в виду «настроен», а не «реализован».
В нашей сети применялась вторая версия протокола IGMP.
Применялась вторая версия потому, что?
На всём сетевом оборудовании использовалась версия проткола igmp v2.
Версия протокола 1 отличается тем, что в ней нет сообщений Leave. Если клиент не хочет получать мультикаст трафик группы, он просто перестаёт посылать Report в ответ на Query. Если не осталось клиентов, маршрутизатор по таймауту перестанет отправлять трафик.
Версия протокола 1 отличается тем, что в ней нет сообщений Leave. Если клиент не хочет получать мультикаст трафик группы, он просто перестаёт посылать Report в ответ на Query. Если не осталось клиентов, маршрутизатор по таймауту перестанет отправлять трафик.
настройка QOS-да это отдельная тема, очень интересная и объемная, ей нужно отдельный раздел посвещать. На Nag кстати неплохие советы есть, которые можно реализовать
Мультикаст адрес в статье и на скрине не совпадает. Да и сам адрес странный 239.255.0.A
Красить трафик не равно фильтровать. Крашенный трафик можно не обрабатывать вообще. крашенный трафик можно шейпить. Фильтровать это последнее что имеет смысл делать с крашеным трафиком. Тк это все таки приоретизация трафика — доставка, хоть и не в первой очереди.
Получив лив коммутатор не исключает порт, а шлет запрос, не осталось ли еще получателей, и не получив ответа — исключает (и то не сразу).
PIM — это не протокол.
В статье куча ошибок и не точностей. И совсем не понятно что именно она раскрывает и как приручает мультикаст примером конфига коммутатора доступа.
Даже как посмотреть join-ы на длинке не написали.
Красить трафик не равно фильтровать. Крашенный трафик можно не обрабатывать вообще. крашенный трафик можно шейпить. Фильтровать это последнее что имеет смысл делать с крашеным трафиком. Тк это все таки приоретизация трафика — доставка, хоть и не в первой очереди.
Получив лив коммутатор не исключает порт, а шлет запрос, не осталось ли еще получателей, и не получив ответа — исключает (и то не сразу).
PIM — это не протокол.
В статье куча ошибок и не точностей. И совсем не понятно что именно она раскрывает и как приручает мультикаст примером конфига коммутатора доступа.
Даже как посмотреть join-ы на длинке не написали.
Protocol Independent Multicast (PIM) — это группа протоколов, которые занимаются маршрутизацией мультикаст.
«Да и сам адрес странный 239.255.0.A» — Это пример
«Да и сам адрес странный 239.255.0.A» — Это пример
Эээээээ…
Нет. Клиент ничего не знает про PIM и PIM Join не отправляет.
IGMP Leave отправляет эндпоинт, какая функция реализована на коммутаторе? IGMP Leave?
Почему загружает именно CPU? Датаплейн не трогает?
И главное:
Где собственно анализ? Что из заголовка здесь вообще есть?
P.S. Лена еще давным-давно написала куда более понятный и логичный материал — habr.com/post/61466 вам стоило бы поучиться.
Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join.
Нет. Клиент ничего не знает про PIM и PIM Join не отправляет.
сли абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа.
IGMP Leave отправляет эндпоинт, какая функция реализована на коммутаторе? IGMP Leave?
Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования.
Почему загружает именно CPU? Датаплейн не трогает?
И главное:
Остановимся на анализе мультикаст-трафика через IGMP-протокол.
Где собственно анализ? Что из заголовка здесь вообще есть?
P.S. Лена еще давным-давно написала куда более понятный и логичный материал — habr.com/post/61466 вам стоило бы поучиться.
Sign up to leave a comment.
Приручаем multicast