Добрый день, коллеги.

Прошу помощи в интересной ситуации.

Есть удаленный сегмент через транспорт. Транспорт дают qinq. Собственно есть циска 6503 на ней терминируются абоненты. Абонентские вланы еще раз запаковывается в куинку перед подачей в транспорт. И распаковываются на удаленной стороне.

Схема такая : с6503 - (uni)DGS-3120(nni) - QinQ Транспорт провайдера - (nni) DGS-3420 (uni) - DGS-3120 - домовой свитч - абонент

Все работает не один год.

Теперь этот сегмент переводится на vlan per user. Брас на mx80- терминирует QinQ. Пробуем переводить и получаем проблему.

mx80 - QinQ Транспорт провайдера - DGS-3420(vlan_translation этого влана чтобы не запаковывать в "старый" qinq) - (nni) DGS-3120 (uni) - домовой(влан на порт) - абонент.

В такой схеме значит видно дхцп дискавер от абонента на брасе, ему отсылается offer, который к нему не приходит.

Причем если домовой свитч включить сразу в DGS-3420 и сделать UNI порт - все работает.
Я думал что дело в vlan_translation replace на DGS-3420 - удалял "старый" qinq влан с порта в сторону 3120, переводил порт в NNI, удалял влан транслейшин - ничего.


DGS-3420 : 28 порт - аплинк,21 - в сторону DGS-3120. Остальные порту - упущу.

Старый QinQ VLAN - 2036
Новый QinQ VLAN - 2760

Остальные вланы тоже упущу для простоты.







DGS-3120 : порт 1 - аплинк, порт 24 - UNI порт в сторону свитча.






Ну и так не работает, происходит то, что написал выше. DHCP запросы на брас приходят, а ответы назад не доходят. При этом если домовой свитч включить сразу в 3420 - все работает как и должно. :

Тот же свитч, но включен в 10-й порт DGS-3420 :





Никаких фильтров DHCP, acl, dos/arp prevention нигде нет

В общем если на 3420 убрать "старый" куинку с порта в сторону 3120, перевести порт в NNI, удалить vlan_translation для "нового" куинку, и выключить ингресс чекинг в сторону 3120 - работает.

Придется переводить все скопом ночью.




P.S : можно ли создать ишью разработчикам, чтобы vlan_translation replace не ломало внутренние теги для qinq влана ?

Аналогичная проблема, есть задача обеспечить транспорт всех VLAN клиента через СПД провайдера, соответственно используем QinQ. Точки включения оборудования клиента в удаленных участках сети. Упрощенная пример-схема ниже:

CustomerX<-->(UNI)DES-3200-10_C1(NNI)<-->(UNI)DGS-3420-26SC_A2(NNI)<-->(NNI)DGS-3627G_A1(UNI)<-->(NNI)DES-3200-10_C1(UNI)<-->CustomerX

Коммутаторы узлов доступа (УД) : 3200-10, 3200-28.
Коммутаторы узлов агрегации (УА): DGS-3420-26SC, DGS-3627G.
SVID для услуги клиента 2201.

Add трансляция происходит на первом УД (3200-10) на UNI порту клиента (port1) и подается на NNI транк выше (port 10):
enable qinq
config qinq ports 1 role uni outer_tpid 0x8100 missdrop disable
config qinq ports 10 role nni outer_tpid 0x8100 missdrop disable
config vlan vlanid 2201 add untagged 1
config vlan vlanid 2201 add tagged 10

На УА осуществляем replace трансляцию для VLAN 2201 на UNI порту в сторону кольца с клиентом (port1) и подается на NNI транк выше (ports 10):
enable qinq
config qinq ports 1 role uni outer_tpid 0x8100 missdrop disable
config qinq ports 24 role nni outer_tpid 0x8100 missdrop disable
config vlan vlanid 2201 add tagged 1,10
create vlan_translation ports 1 replace cvid 2201 svid 2201

Собственно проблема только с коммутаторами УА серий 3420(A2) и 3120(A2). А конкретно в том, что replace трансляция на них отрабатывает не корректно, в одну сторону. То есть в FDB таблице на 3420/3120 mac-адреса оборудования клиента пришедшие с порта NNI будут в 2201, пример:
DGS-3420-26SC: # show fdb port 10
VID VLAN Name MAC Address Port Type Status
---- -------------------------------- ----------------- ----- ------- -------
2201 VLAN2201 00-40-8C-FE-94-D7 10 Dynamic Forward

А вот на входе в кольцо за UNI портом они уже в VLAN клиента без 2201, пример:
DES-3200-10:# show fdb mac_address 00-40-8C-FE-94-D7
VID VLAN Name MAC Address Port Type Status
---- -------------------------------- ----------------- ----- ------- -------
447 VLAN447 00-40-8C-FE-94-D7 10 Dynamic Forward

При всем при этом прямая часть трансляции работает, т.е. со стороны UNI порта УА DGS-3420-26SC_A2 (port 1) mac-адреса клиента в VLAN 2201.

Для сегментов сети? где в качестве УА используются DGS-3627G проблема не актуальна и трансляции осуществляются корректно.
Текущая версия прошивки на DGS-3420-26SC(A2) - 1.70.B018.

Присоединяюсь к просьбе коллеги.



P.S.
Сейчас на узлы агрегации в основном ставим именно DGS-3420-26SC, а тут такое =(, менять на DGS-3627G и отправлять назад не хотелось бы, понятно что проблема программная.

Просьба к сотрудникам поддержки D-Link отписаться по проблеме. Будет ли решение ее в новых версиях прошивок для A2, когда, или можно ставить крест на этой серии для использования под эту конкретную задачу?

Для DGS-3420 ориентировочно на этой неделе должна появиться прошивка, где это поведение меняется и можно будет с ней проверить ситуацию. Для DGS-3120 таких изменений, насколько мне известно, не планируется.

А почему? Для 3120 оно тоже очень нужно, так как он тоже позиционируется как свич полноценно поддерживающий QinQ. Уточните пожалуйста, хотя бы для Б1/4 ветки софта. Просто он реально нужно....

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

Хорошо, будем ждать. Просто у меня нет 3420, только собираюсь в скором времени их использовать. А вот 3120 уже приближается к 150 на сети....

В общем ждёмс и надеемся что всё будет работать как надо

Есть ли новая информация по прошивке с исправлениями проблемы для серии 3420?

Выслал Вам прошивку на почту.

Спасибо завтра протестируем. Сразу вопрос, а команда

не повлияет на portbased qinq для этого коммутатора? Например, если на порту UNI есть untagged VLAN 2203 (для приходящего трафика остальных клиентов) tagged VLAN 2201 и replace трансляция для q-in-q трафика SVID 2201 клиента, не возникнет ли ситуации когда после команды на УА

на УД в кольце в таблице FDB будут mac-адреса в VLAN2203, а не в клиентских? Честно говоря логика работы команды не ясна до конца, она избирательно работает только для selective qinq? Если можно поясните. Или стоит для начала на стенде самим проверить?

При активации этой команды поведение будет таким же, как на DGS-3627G, то есть на работу Port-Based Q-in-Q это не повлияет.

С новой версией прошивки Q-in-Q функционирует корректно, тесты - проблем не выявили. Новый механизм конфигурирования трансляций даже более удобен чем в серии DGS-3627G. Спасибо, еще бы аналогичную реализацию для DGS-3120.

Т.е. теперь через vlan_translation у вас проходят вланы с 2мя тэгами?

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