DGS-1210-28 IGMP Snooping

[Sector_nn]

Прошу подсказать по настройке IGMP Snooping на DGS-1210-28:

System hardware version : B1
System firmware version : 3.12.B056

Т.к. коммутатор Web Smart - настраиваю всё через WEB-интерфейс:

1. Поднял для Multicast VLAN-22: порт 1 - trunk (tagged), порты 2-3 access (untagged).
2. IGMP Snooping - Enabled, Report to all ports - disabled.
VLAN-22 IGMP Snooping:
State - Enabled
Querier - Disabled
Fast Leave - Enabled
3. Filter Unregistered Groups активировано для VLAN-1, 22

При таких настройках имею проблему с IGMP-Leave сообщениями от подписчиков: эти сообщения приходят на Multicast-роутер (Querier) с IP-адреса самого свича, который находится в другой подсети, соответственно роутер их игнорирует и не отписывает клиентов от групп при переключении каналов, порождая большой multicast-трафик с нескольких групп. При этом сам свич порты от групп нормально отсоединяет и переключает на новые группы.
Если выставляю Fast Leave - Disabled, то Leave - сообщения приходят на Multicast-роутер (Querier) от исходных IP-адресов клиентов, роутер успешно отписывает клиентов от групп. Но в этом случае уже свич не отписывает порты сразу, а делает это по таймауту, судя по всему при следующем "Membership Query, general" сообщении со стороны роутера, тем самым также временно нагружая порты ненужным трафиком.

На свиче другого вендора при аналогичных настройках Leave-сообщения отрабатываются корректно: свич их пересылает сразу, с исходного IP-адреса, и также сразу производит отключение порта от группы. Подскажите, как правильно настроить коммутатор для адекватной работы IGMP Snooping? Можно-ли как-то отключить трансляцию исходного IP-адреса в Leave-пакетах? Т.е. сделать так, чтобы свич не подменял IP-адрес источника на свой? Либо при отключенном Fast Leave делал отключение порта от группы хотя бы после query specific, а не general? Саппорт Dlink ответил, что баг имеет место быть, исправлять не будут т.к. девайс старый. Может кто сталкивался и есть какой-нибудь костыль/workaround?

Edited May 23, 2020 by Sector_nn

[pppoetest]

Не знаю как в 1210, в 3200 есть команда

config igmp_snooping multicast_vlan <vlan> replace_source_ip <ip> state enable

[Sector_nn]

В 1210 CLI обрезаный, там нет большей части конфигурационных комманд, только мониторинг базовый и всё.. :(

[Butch3r]

20 часов назад, Sector_nn сказал:

В 1210 CLI обрезаный, там нет большей части конфигурационных комманд, только мониторинг базовый и всё.. :(

ну так смотрите тоже самое в вебе, раз взяли кастрата

[Sector_nn]

В 25.05.2020 в 07:43, Butch3r сказал:

ну так смотрите тоже самое в вебе, раз взяли кастрата

В том и дело, что нету такого параметра в веб-морде.. =(

[pingz]

Если вы в начале пути лучше отказаться от мультикаста и перейти на юникаст. 

Если вы решили все же до конца идти по пути мультикаста тогда сегментируйте сеть и ставьте один квераир на 50-100 клиентов. 

Если клиент перелиснет 20-30 каналов около 60 секунд ему будет длится мультикаст в порт, что бы это сократить можно на сервере ограничить показ канала допустим на 3 секунды. 

[vurd]

43 минуты назад, pingz сказал:

Если вы в начале пути лучше отказаться от мультикаста и перейти на юникаст. 

Если вы решили все же до конца идти по пути мультикаста тогда сегментируйте сеть и ставьте один квераир на 50-100 клиентов. 

Если клиент перелиснет 20-30 каналов около 60 секунд ему будет длится мультикаст в порт, что бы это сократить можно на сервере ограничить показ канала допустим на 3 секунды. 

[alibek]

16 часов назад, pingz сказал:

Если вы в начале пути лучше отказаться от мультикаста и перейти на юникаст. 

Если вы решили все же до конца идти по пути мультикаста тогда сегментируйте сеть и ставьте один квераир на 50-100 клиентов. 

Очень странный совет.

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

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

У нас на всю сеть использовался один единственный querier — а больше и не нужно. Просто querier должен быть как можно ближе к источнику и ядру сети. А на всех коммутаторах доступа должен быть правильно настроен igmp snooping, с фильтрами, лимитами и прочим.

 

16 часов назад, pingz сказал:

Если клиент перелиснет 20-30 каналов около 60 секунд ему будет длится мультикаст в порт, что бы это сократить можно на сервере ограничить показ канала допустим на 3 секунды.

Есть и другие способы.

Есть коммутаторы с поддержкой preview (но тогда в сети все коммутаторы должны это уметь).

Есть fast-leave.

Есть ограничения по количеству активных подписок на порт.

[pingz]

@alibek  Фастлив хорошо работает на топологии звезда, если это кольцо нужно правильно подбирать оборудование.

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

@vurd  от вас я не увидел конструктивных пожеланий и предложений. Желч лить без причины не стоит

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

[Ivan_83]

В 23.05.2020 в 23:05, Sector_nn сказал:

На свиче другого вендора при аналогичных настройках Leave-сообщения отрабатываются корректно: свич их пересылает сразу, с исходного IP-адреса, и также сразу производит отключение порта от группы. Подскажите, как правильно настроить коммутатор для адекватной работы IGMP Snooping?

Так мучайте ТП вендора где это не работает.

 

В 27.05.2020 в 17:18, pingz сказал:

Если клиент перелиснет 20-30 каналов около 60 секунд ему будет длится мультикаст в порт, что бы это сократить можно на сервере ограничить показ канала допустим на 3 секунды.

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

[pppoetest]

DGS-1210-28 вроде не умеет в igmp аuth

[alibek]

Мне кажется, что речь не об igmp auth, а о том, что при пролистывании каналов пользователь генерирует много подписок.

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

[pingz]

@Ivan_83 сервер с медиапорталом например stalker там можно выставить задержку в секундах.

Клиент выбрал канал 22 и только после истечении задержки ему передадут ссылку на мультикаст.

Если клиент листанет 10-20 каналов быстро то мультикаст ему не будет предоставлен 

[sdy_moscow]

Нормальный клиент сам отпишется от потока.

[Sector_nn]

2 часа назад, alibek сказал:

Мне кажется, что речь не об igmp auth, а о том, что при пролистывании каналов пользователь генерирует много подписок.

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

Тут суть в том, что при переключении каналов клиентом свитч не отписывает порт от группы сразу. И по-этому если кто-то ещё смотрит этот канал и мультикаст приходит на свич, то клиент, переключивший канал ещё будет какое-то время получать ещё и старый канал (до следующего general query), т.к. querier не отключает его из-за другого клиента. 

 

37 минут назад, sdy_moscow сказал:

Нормальный клиент сам отпишется от потока.

Не отпишется, посколько на порту есть и другие клиенты: querier не отключит поток, пока от него не отпишутся все клиенты

[sdy_moscow]

@Sector_nn Если есть ЕЩЕ клиенты, то поток и так и так там будет. Причем здесь переключение каналов? Таймаут конечно не помешает.

[Sector_nn]

5 часов назад, sdy_moscow сказал:

@Sector_nn Если есть ЕЩЕ клиенты, то поток и так и так там будет. Причем здесь переключение каналов? Таймаут конечно не помешает.

Да, поток будет, но свич должен отписывать порт от группы (потока) при получении leave или хотя бы после specific query.