Добрый день.

Столкнулись с слегка неочевидной проблемой на DGS-3627G при работе с QinQ.

Суть в следующем: создан SVLAN, допустим, 821, в котором поднимаются вверх клиентские CVLAN (QinQ). Соответственно, на порту для коммутатора доступа настроен QinQ UNI-режим, VLAN 821 тегированным.

Есть VLAN управления, допустим, 820. Также настроен тегированным, создан VLAN translation: cvid 820 replace svid 820 - т.е. VLAN пробегает вниз без двойного тегирования.

В итоге вроде бы все хорошо: сверху сам 3627G и все коммутаторы доступа через VLAN820 видны, снизу коммутаторы доступа также пингуют весь внешний мир. Но... есть одно "но".

Коммутаторы доступа не видят сам 3627G. Т.е. ping с коммутаторов доступа на 3627G проваливается, и наоборот тоже.

Вывод - vlan_translation явно не учитывает CPU-порта, и трафик с UNI-портов до CPU не доходит.

Вопрос - как можно сделать так, чтобы трафик с VLAN'ов UNI-портов все-таки доходил до CPU на соответствующие ipif? Создать какую-то трансляцию?

Для чего это нужно - для возможности дать вниз multicast по IGMP, просто при включенном QinQ коммутаторы доступа банально не видят 3627, и не могут взять с него группы.

Что посоветуете?

P.S. В связи с этой же проблемой невозможно использовать IGMP snooping на 3627G, поскольку он не видит запросов на группы с портов КД.

_________________
Regards,
Senior NOC Engineer,
Alexey Asemov.

Q-in-Q функция L2, и если Вы хотите её использовать и маршрутизировать клиентский трафик одновременно, то ни чего не получится. Это может делать только BRAS.

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

Речь не совсем о том. Мне не нужно маршрутизировать клиентский трафик из QinQ VLAN.

Есть у меня VLAN, который идет параллельно QinQ с одним тегом. Для него создан vlan_translation, который позволяет не добавлять к этому VLAN второй тег. К сожалению, на CPU-порт трафик с этого VLAN, приходящий "снизу", не попадает.

Исправимо ли это?

_________________
Regards,
Senior NOC Engineer,
Alexey Asemov.

Я уже написал, что при использовании Q-in-Q коммутатор не будет маршрутизировать трафик.

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

del, duplicate

_________________
Regards,
Senior NOC Engineer,
Alexey Asemov.

Для IGMP удалось ситуацию разрешить путем плясок с бубном, правда при этом мультикаст приходится спускать в SVLAN, в котором идут CVLAN'ы, но это уже мелочи жизни.

_________________
Regards,
Senior NOC Engineer,
Alexey Asemov.

По поводу решения.

Применимо только для multicast, ради которого все и затевалось.
Заставить нижестоящие коммутаторы доступа "видеть" вышестоящий QinQ-коммутатор не получится.

Вкратце: снупинг с QinQ на 3627 работать без PIM/IGMP нормально не будет, можете не пробовать - все уже попробовано и 100% не работает.

Однако с PIM завести можно, и будет работать как IGMP, так и снупинг поверх этого IGMP (во всяком случае все запрошенные группы и порты видно в show igmp_snooping groups/forwarding - а это признак нормальной работы). Как делается:

Допустим, мультикаст спускается в SVLAN X _только_ до 3627, клиенты идут в SVLAN Y, т.е. порт с коммутатором доступа DES-3028 в QinQ имеет роль UNI, настроенный GVRP PVID = Y и сидит в tagged VLAN Y. VLAN X вниз не спускаем.

На КД настраиваем multicast VLAN для SVLAN Y (хитрость - если включен multicast_trunk - перед созданием multicast VLAN его надо выключить, иначе создать не даст, после - включить назад), делаем source port = порт, поднимающийся на 3627, задаем member ports, и - вот здесь одна важная вещь: обязательно ставим на порт, который у нас source port, GVRP PVID = Y. Включаем снупинг, на порт источника вешаем forward unregistered groups, на порты клиентов - filter unregistered groups. CVLAN'ы клиентов не трогаем.

После этого на 3627 создаем ipif'ы IPTV-S для VLAN X (это у нас источник), и IPTV-C для SVLAN Y - это у нас клиенты (какие у них IP - зависит от того, как вы им их выдаете, и настроена ли трансляция IP в multicast vlan на КД). Включаем IGMP _только_ для IPTV-C, включаем PIM для IPTV-S и IPTV-C (именно для обоих), пишем ipmrout'ы для адресов IPTV-S и IPTV-C на наш RP источника. Включаем IGMP snooping, для SVLAN X и SVLAN Y, делаем multicast filtering mode в forward unregistered groups на SVLAN X, и filter unregistered groups на SVLAN Y.

Все. На этом все должно заработать.

_________________
Regards,
Senior NOC Engineer,
Alexey Asemov.