Добрый день!

Может уже обсуждалось - не нашел...

Строим port-based Q-in-Q (аналог цисковского dot1q-tunnel)




В 15-й порт включен коммутатор с несколькими клиентскими vlan-ами. Далее по сети vlan 4005 отдается через 76-ю циску на Cat3560G. На последнем этот vlan "распаковывается" и отдается опять же в клиентское оборудование.

Уникаст бегает на ура, все ок. А вот с мультикастом проблема. Он ходит только если глобально на свиче выключить igmp_snooping.
Отключение снупинга только в vlan-е 4005, изменение параметров фильтрации мультикаста ни к чему не приводит. Проверено на трех разных прошивках, включая последнюю.

С подобным же транспортом в 14-м порту та же самая история. При этом, если 'multicast filtering_mode forward_unregistered_groups'
или 'forward_all_groups' дропов на порту нет. Если включить снупинг и режим фильтрации поставить 'filter_unregistered_groups' - появляются дропы мультикаст пакетов на порту.

Свитч стоит в 10-G кольце. Сейчас снупинг полностью отключен дабы клиент мог работать, но хотелось бы понять что это - баг или фича такая?

Для клиента построено несколько включений q-in-q, но все кроме этого принимаются в каталисты и проблем нет. А вот этому включению "не повезло".

При текущей схеме мультикаст клиентский и он-же заворачивается во второй тег?
Попробуйте вместо Port-Based Q-in-Q использовать Selective, может быть в этом случае получится нормально запустить.

да мультикаст едет в клиентских vlan-ах. затем им дописывается второй тег. беда в том, что со стороны dgs-а даже igmp join-ы не пролазят.
selective не годится. мне нужна полная независимость от клиентских vlan-ов. тем более, что так уже работает в других местах и ломать эту схему низзя. да и не правильно это. а жить с отключенным снупингом тоже не правильно...

Up! Есть у Д-линка мысли на эту тему?

Уточните, пожалуйста, у Вас на этом же DGS-3627G есть аналогичные вланы с мультикастом и на них проблема не наблюдается или проблема для любого влана с мультикастом, проходящего через DGS-36xx в аналогичной схеме?

Проблема только с тем мультикастом, который идет в клиентских vlan-ах, приходящих в UNI порт.
Таких транспортов на этом свиче сейчас два - один клиентский, второй был построен для тестирования.
Что интересно, в другом городе есть похожий транспорт, но там прошивка версии 2.82.B23 и та же версия железа A1.
Снуппинг включен и на свиче, и в q-in-q-шном vlan-е. Все работает и dgs даже по команде 'sh igmp_snoop forwarding'
показывает адреса групп и источников трафика. Режим фильтрации мультикаста - forward_all_groups.

Завтра попробую посавить эту прошивку у себя и еще раз протестировать. Но очевидно, что что-то поломалось
между 2.82.B23 и 2.84.B31 и 2.84.B38.

Вообще, при режиме фильтрации forward_all_groups прохождение мультикаста никак не должно ограничиваться. Жду Ваших результатов и если проблема останется, то пришлите мне, пожалуйста, полный конфигурационный файл коммутатора для анализа.

Вобщем даунгрейд прошивки тоже не помог. При чем вообще сначала мультикаст с двумя тегами не хотел ехать, но теперь уже в другую сторону - т.е. джоины проходили а вот поток назад нет. Выяснил так же, что на аппаратной ревизии A1G1 та же проблема. Б\м вменяемо оно работает, если использовать нетегированный трафик по отношению к UNI порут. Т.е. в порт UNI включаем свитч с транковым портом и на нем некоторый влан отдаем untagged. В этом случае даже с включенным снуппингом работает (но тоже как-то не всегда и сразу происходит регистрация получателя группового трафика). По финишу имеем картину с эффектом, который невозможно 100% повторить. Почему, например в другом городе работает, а тут я не могу повторить это...

Сузил топологию до минимума. один DGS-3627G A1G1 прошивка 2.84.B31. два порта объявлены UNI.




В порт 15 включен DES-3010G, в него клиент с vlc в vlan101. этот vlan отдается тагом в сторону DGS-a. Так же тагом он из 16-го порта уходит в сторону другого свича - ES3528M. В последний включен роутер. так вот если из этой цепочки удалить DGS - все работает без проблем. С DGS-ом посередине - нет. При этом даже не важно включен или выключен igmp_snooping глобально или на этом vlan-e 4005. фильтрация мультикаста forward_all_groups.

Если я в эту схему вместо DGS-а ставлю Cat 3560G c такими настройками портов:



тоже все работает как и положено.

Полный конфиг свича не пришлю. Поймите правильно.

В таком случае пришлите, пожалуйста, конфигурацию Вашего тестового стенда, чтобы можно было воспроизвести проблему.

Для сборки стенда не нашел свободного 3627 по сему заменил его 3612. Конфиги выслал. При включенном снуппинге мультикаст работает только в одном vlan-е - в конфиге свича SW-2 это vlan ADMIN (VID=100). Он в сторону DGS-а отдается
нетегированным. Попытки гонять мультикаст в vlan-ах USER{1,2} терпят фиаско. Если выключить снупинг глобально и подождать некоторое время (2-3 минуты), мультикаст начинает работать и в этих vlan-ах.

На стенде у меня это не воспроизводится. Один коммутатор я подключил к 1-ому порту DGS-3612G, второй к порту 2 и между клиентами, подключенными в DES-3026 мультикаст ходит по всем вланам (vid 100, 101 и 102).
Конфигурацию DGS-3612G я не менял, однако прошивку использовал вот эту: http://dl.dropbox.com/u/41324937/D-Link_Firmwares/DGS-3600_Series/DGS-3600_Series.zip

Залил указанную прошивку и.. ничего не изменилось.
Более того, покопав дальше вылезли грабли еще и с ipv6, который (как известно) тоже сильно зависит от мультикаста.
С включением снупинга перестает работать multicast и не просходит обновление адресов ipv6 по SLAAC. Но это отдельно буду разбираться.

Как тестировали Вы? Чем посылали мультикаст, чем принимали, какие адреса групп использовались, какие при этом были MAC-адреса?
В нашем случае адреса групп мапятся в MAC-и 01:00:5e:29:xx:xx.

Я получаю 100% воспроизводимую картину. Включаю снупинг и через 30-60 секунд join-ы уже не проходят, member query тоже не проходят.
Выключаю снупинг и через 30-60 секунд снова все восстанавливается. Вот включив снупинг начал писать ответ, прошло примерно две минуты, роутер послал member query и не получил ни одного ответа. Соотв. перестал слать поток и на клиенте картинка зависла.

у меня складывается такое впечатление, что при возникновении проблемной ситуации свитч блокирует трафик именно на групповые адреса с MAC-ами 01:00:5e:00:00:xx - т.е. тот диапазон, корорый вообще блокировать не должен.


update: в дополнительном vlan-е (3800) поднял OSPF. Соседство устанавливается как при выключенном снупинге, так и при включенном.
При очистке ospf процесса соседство восстанавливается. Чем дальше, тем как в сказке...

Опишите, пожалуйста, выполняемые Вами операции по шагам. Свою схему я уже кратко описал выше, добавлю, что мультикаст и вещался и принимался программой VLC. Адрес группы использовался 239.1.1.2

Да уже ж все описано... Взял DSG-3612g, включил на нем QinQ, на двух портах сделал тип UNI, tpid 0x8100. Создал влан 4005 и отдал его антагом
в два предидущих. включил jumbo frames. включил igmp_snooping глобально и в влан-е 4005. включаю это дело в разрыв между двумя свичами с набором влан-ов. после этого на клиентской машине запускаю vlc и пытаюсь посмотреть iptv. join с виндовой машины уходит, на свиче куда она включена появляется соотв. запись (sh igmp_snoop group), а вот сквозь DGS этот join уже не проходит и на дальнем свиче не появляется соотв. запись и до роутера тоже запрос не доходит. после этого выключаю igmp_snooping в влан-е 4005. жду какое-то время. снова пытаюсь посмотреть уже другой канал чтобы заведомо сформировать join для нового адреса группы - тишина. выключаю глобально снупинг. проходит некоторое время - 30-60 секунд. включаю новый канал - трафик поехал картинка есть. снова включаю снупинг глобально - и через максимум две минуты - картинка прерывается, мультикаст поток перестал литься. происходит это потому, что на очередной запрос от роутера ответы от клиента и первого свича через DGS блокируются. Т.е. вероятно сам мультикаст поток бы лился дальше, но блокировка служебного трафика вынуждает роутер прекратить вещание.

проблемы с включенным глобально снупингом нет только в том случае, если клиентский влан по отношению к DGS-у идет нетегированным.

с другой стороны в другом влан-е нормально живет OSPF, который (как известно) использует групповые адреса 224.0.0.5, 224.0.0.6.

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

К слову еще интересный вопрос. При конфигурировании qinq есть команда для установки outer_tpid. Но в тексте конфига она не появляется
при этом. И вот:



Что не так?