Конфигурация сегмента:

[хосты] <=N:1=> [DGS-3200 для комнат] <=N:1=> [DGS-3200 отдела] <=1:1=> [корп.свитч] <=1:N=> [ещё хосты]

Конфигурация связана с конфигурацией нашего сайта (и распределением ответственности между нами и IT корпорации), поменять её не получится.

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

"Корп.свитч" - это наша VLAN в корпоративной системе свитчей (Cisco), прямого контроля у нас над ней нет, как и гарантии, что наши запросы на изменения в ней будут сделаны точно и в срок. Multicast querier (IGMP v3) - там (unicast router тоже там, multicast routing пока отсутствует, но может появится со временем - тоже там).

IGMP snooping и filter_unregistered_groups на всех DGS включён. querier запрещён. Если разрешить querier он включается на одном из DGS, игнорируя querier корп.свитча, что приводит к невозможности подписки хостов, подключённых к DGS, на стримы с источников, подключённых к корп.свитчу.

Адресное пространство мультикаста - общее; диапазон мультикаст адресов распределён но источникам статически (организационно). Тем не менее, хочется технически локализовывать распространение мультикаст потоков (по умолчанию - весь сегмент, по нетмаске - в пределах свитча комнаты или свитча отдела), чтобы уменьшить нагрузку на корп.свитч. limited_multicast_group в этой конфигурации почему-то не работает:



- по-прежнему подписывает и шлёт пакеты на dynamic router port аплинка (например, 16). Если аплинк - DGS отдела, то этот трафик можно зарезать там на входе, через config access_profile, но это некрасиво и не работает, если нужно локализовать трафик в пределах отдела.

Вопрос: что могло быть сделано неправильно? Что могло было быть сделано лучше?

Ещё вопрос: в этой же конфигурации порт DGS корректно подписывается на мультикаст, когда он присоединяется к группе, но отписывается от него только через ~3 минуты после того, как он покидает группу. Вне зависимости от того, идёт ли мультикаст из соседнего порта (не детектируемого как роутер порт) или через аплинк с корп.свитча. Хост на порте посылает IGMP leave, querier посылает IGMP query раз в 1 минуту, на что хост на порте тоже корректно отвечает.

На всякий случай, со свитча отдела (остальные настроены так же):



Прошивки 1.11.B003 (на A1 версиях свитчей) и 1.11.B004 (на A2 версии), разницы в их поведении не наблюдается.

Пожалуйста, укажите порт, к которому подключён Streamer, и вывод команды "show multicast port_filtering_mode" с данного коммутатора.

_________________
С уважением,
Бигаров Руслан.

У DGS-3200 нет port_filtering_mode (по крайней мере, на этих прошивках).

vlan_filtering_mode, как я и писал, стоит в filter_unregistered_groups. И, судя по show utilization ports, работает как положено (если не считать трёхминутной задержки при отписке).

Если мультикаст приходит в тегированном виде, то лучше использовать ISM VLAN, это и магистраль разгрузит и контролировать раздачу мультикаста будет попроще.

_________________
С уважением,
Бигаров Руслан.

У нас все клиентские порты на свитчах (включая источники мультикаста) принадлежат одному и тому же Ethernet сегменту, одной и той же IP подсети и должны видеть друг друга при юникасте/броадкасте. Непонятно, как бы тут можно было бы использовать ISM VLAN, и как бы оно помогло решить проблемы (неработа limited_multicast_addr, по крайней мере, для router port, и поздняя отписка порта приёмника от мультикаста).

В этом случае iSM VLAN отпадает. Тогда единственное что можем порекомендовать, так это обновить прошивки на последние версии, они доступны на ftp.dlink.ru, только со сбросом конфига "reset" после перезагрузки, и последующей загрузки конфигурационного файла.

_________________
С уважением,
Бигаров Руслан.

Итак, DGS-3200-16, прошивка обновлена:
Firmware Version : Build 1.50.B019

Настройки:



на 9 порту источник, на 10 порту приёмник, на 16 порту аплинк (DGS-3200-10, у которого, соответственно, аплинк Cisco).

На аплинке - config igmp_snooping querier all state disable (Cisco в качестве querier). На DGS-3200-16 подписка на 10 порт работает, отписка - нет.

На аплинке - config igmp_snooping querier all state enable (DGS-3200-10 в качестве querier). На DGS-3200-16 подписка на 10 порт работает, отписка - тоже работает. Но на каналы, которые вещаются через Cisco, не подписаться.

Думаем, что дело может быть в том, что на D-Link-ах query_interval - 125, а на Cisco - 60. Ставим на обоих D-Link-ах


-- никакого эффекта. При Cisco в качестве querier отписка не работает, при DGS-3200-10 - работает.

Всё это время querier на DGS-3200-16, на котором смотрим подписку - выключен.

Запускаем wireshark и тупо смотрим разницу в 224.0.0.1 и 224.0.0.22 пакетах со стороны приёмника. В reports разницы вообще никакой. В queries разница в mac и ip адресах источника (естественно). Да, и ещё у Cisco ip identification field нулевой, а у DGS-3200-10 - нет. Всё.

Мистика...

Не совсем понятно, после igmp leave, коммутатор продолжает на клиентский порт пробрасывать мультикаст канал или только на uplink порт?

_________________
С уважением,
Бигаров Руслан.

Продолжает пробрасывать на клиентский порт до expiry time для группы, если аплинк с querier - Cisco. И отрабатывает fast leave корректно, если аплинк с querier - другой DGS.

Никаких других пакетов на адреса 224.0.0.0/24 (кроме query на 224.0.0.1 и report на 224.0.0.22) wireshark на клиенте не видит.

Т.е. если рассматривать схему:
[Cisco]---[DGS-3200-1]---[DGS-3200-2]
то с клиентом, подключённым во второй DGS-3200, всё отрабатывает нормально, а если к первому, то наблюдается описанная проблема?

Причём на обоих настройки:
reset
config ipif System dhcp
config igmp_snooping all state enable fast_leave enable
config igmp_snooping querier all state disable
enable igmp_snooping
config multicast vlan_filtering_mode all filter_unregistered_groups

_________________
С уважением,
Бигаров Руслан.

Нет. И клиент, и источник мультикаста в обоих случаях подключены к DGS-3200-2. Проблема возникает в зависимости от того, где расположен querier. Если на DGS-3200-1 - всё работает. Если на Cisco - не работает fast leave.

Подумал было, что проблема может быть связана с тем, что у Cisco ip адрес выше (мало ли... может, проверку на адрес querier авторы кода не туда влепили). Поменял ip адрес DGS-3200-1, чтобы был выше, чем у DGS-3200-2 - ни на что не повлияло. По прежнему, querier на DGS (на внешнем) - fast leave работает; querier на Cisco - leave игнорируется.

Я проверю и напишу по результатам.

_________________
С уважением,
Бигаров Руслан.

Есть новости?

На тестовом стенде не могу подтвердить такой проблемы, в случае использования другого (третьего) коммутататора в качестве querier в Вашей схеме fast leave у меня корректно отработал. Соответственно, мой стенд отличается от Вашего только тем, что я использовал вместо Cisco - DES-3528 и версией прошивки на DGS-3200 (появилась уже более актуальная). Попробуйте, пожалуйста, ситуацию с прошивкой, которую я Вам выслал на почту. Если обновление ПО не решит проблемы, то укажите есть ли у Вас еще querier в сети и мультикаст у Вас ходит только внутри этого участка, что Вы привели или топология сети, где используется мультикаст шире?