QinQ в DLink

[ufm]

Приветствую.

 

Есть ли люди, которые используют в своей практике QinQ на длинках?

У меня какое-то глубинное недопонимание данной технологии.

 

Допустим на свиче включено QinQ. Есть четыре порта (1,2,3,4). Порты 1 и 2 - UNI. 3 и 4 - NNI. На все порты приходит VLAN 10. На 1 и 3 - tagged, на 2 и 4 - untagged.

И тут у меня ступор в мозгу. Ступор в том, что я непонимаю что в данном случае делает tagged и untagged с портом.

Если есть понимающие люди - помогите, пожалуйста.

[Alex/AT]

Мы изучали механизм QinQ на длинках, постараюсь его описать. Кто знает какие-то ещё детали - подтвердите или опровергните про навешивание / снятие тегов свитчом, эксперименты с UNI/NNI показывают, что всё работает именно так, как описано.

 

QinQ и тегирование на длинках 36xx/3028-52/3200-xx работает так:

 

Сначала рассмотрим типовые порты, NNI:

 

NNI - это "сетевой", бэкбонный порт.

 

Когда на порт NNI приходит фрейм с тегом - если Ingress Checking включен, VLAN в теге сверяется с разрешенными тегами на порту. Если тег разрешен - фрейм пропускается в фабрику, если запрещен - дропается. Если Ingress Checking выключен - пропускаются все фреймы. Фрейм помечается номером VLAN, в котором он вошёл. Тег VLAN - снимается, в фабрику фрейм попадает без тега, но с внутренним маркером VLAN согласно тегу.

 

Когда на порт NNI приходит фрейм без тега - он пропускается в Native VLAN по "GVRP" PVID, и помечается номером PVID. Никаких тегов на данном этапе не навешивается.

 

Когда фрейм выходит с порта NNI, на него вешается тег согласно внутреннему маркеру VLAN. Если VLAN = PVID на порту, то тег не навешивается, и фрейм уходит нетегированным. В случае включенного QinQ фрейм тегируется не стандартным маркером VLAN (TPID = 0x8100), а тем, что указан как QinQ "outer" TPID.

 

Теперь об UNI:

 

UNI - это "тупой" клиентский порт.

 

Когда на UNI приходит фрейм, он всегда запихивается в VLAN, который установлен как "GVRP" PVID. Никаких тегов на данном этапе не снимается.

 

Когда фрейм из VLAN по PVID выходит с UNI, он выходит "как есть", без каких-либо преобразований.

 

Итого:

 

Фреймы, идущие с NNI на NNI, идут "как обычно" - в своих VLAN, без искажений. Разве что может поменяться TPID при включенном QinQ, поскольку на входе тег снимается, на выходе - навешивается согласно TPID исходящего порта и внутреннего маркера VLAN.

 

Фреймы, вошедшие на порты UNI, по фабрике пройдут вместе с тегом, и при выходе на NNI на них будет навешен дополнительный "верхний" тег VLAN (за исключением случая, когда этот VLAN - Native для порта NNI). Т.е. фрейм пойдёт с двумя тегами, в том VLAN, который указан на "GVRP" PVID порта UNI.

 

Фреймы, идущие между двумя UNI, сидящими по "GVRP" PVID в одном VLAN, войдут и выйдут "как есть", без изменений.

 

С фреймами, вошедшими с порта NNI, и выходящими по VLAN в UNI, произойдет следующее: на порту NNI при входе "верхний" тег будет снят. При выходе с UNI фрейм выйдет "как есть", без навешивания каких-либо тегов. Т.е. фрейм выйдет без верхнего тега, но с нижним, и в итоге пойдёт дальше тегированным нижним тегом.

Edited December 12, 2011 by Alex/AT

[h1vs2]

Мы изучали механизм QinQ на длинках, постараюсь его описать. Кто знает какие-то ещё детали - подтвердите или опровергните про навешивание / снятие тегов свитчом, эксперименты с UNI/NNI показывают, что всё работает именно так, как описано.

 

QinQ и тегирование на длинках 36xx/3028-52/3200-xx работает так:

 

Сначала рассмотрим типовые порты, NNI:

 

NNI - это "сетевой", бэкбонный порт.

 

Когда на порт NNI приходит фрейм с тегом - если Ingress Checking включен, VLAN в теге сверяется с разрешенными тегами на порту. Если тег разрешен - фрейм пропускается в фабрику, если запрещен - дропается. Если Ingress Checking выключен - пропускаются все фреймы. Фрейм помечается номером VLAN, в котором он вошёл. Тег VLAN - снимается, в фабрику фрейм попадает без тега, но с внутренним маркером VLAN согласно тегу.

 

Когда на порт NNI приходит фрейм без тега - он пропускается в Native VLAN по "GVRP" PVID, и помечается номером PVID. Никаких тегов на данном этапе не навешивается.

 

Когда фрейм выходит с порта NNI, на него вешается тег согласно внутреннему маркеру VLAN. Если VLAN = PVID на порту, то тег не навешивается, и фрейм уходит нетегированным. В случае включенного QinQ фрейм тегируется не стандартным маркером VLAN (TPID = 0x8100), а тем, что указан как QinQ "outer" TPID.

 

Теперь об UNI:

 

UNI - это "тупой" клиентский порт.

 

Когда на UNI приходит фрейм, он всегда запихивается в VLAN, который установлен как "GVRP" PVID. Никаких тегов на данном этапе не снимается.

 

Когда фрейм из VLAN по PVID выходит с UNI, он выходит "как есть", без каких-либо преобразований.

 

Итого:

 

Фреймы, идущие с NNI на NNI, идут "как обычно" - в своих VLAN, без искажений. Разве что может поменяться TPID при включенном QinQ, поскольку на входе тег снимается, на выходе - навешивается согласно TPID исходящего порта и внутреннего маркера VLAN.

 

Фреймы, вошедшие на порты UNI, по фабрике пройдут вместе с тегом, и при выходе на NNI на них будет навешен дополнительный "верхний" тег VLAN (за исключением случая, когда этот VLAN - Native для порта NNI). Т.е. фрейм пойдёт с двумя тегами, в том VLAN, который указан на "GVRP" PVID порта UNI.

 

Фреймы, идущие между двумя UNI, сидящими по "GVRP" PVID в одном VLAN, войдут и выйдут "как есть", без изменений.

 

С фреймами, вошедшими с порта NNI, и выходящими по VLAN в UNI, произойдет следующее: на порту NNI при входе "верхний" тег будет снят. При выходе с UNI фрейм выйдет "как есть", без навешивания каких-либо тегов. Т.е. фрейм выйдет без верхнего тега, но с нижним, и в итоге пойдёт дальше тегированным нижним тегом.

 

Извините, вопрос как раз актуальный мне и по теме : как vlan, который не qinq и приходит с порта nni тегированым отдать в другой порт тоже тегированым, в котором будет только этот vlan?

 

Порт должен быть NNI, или UNI? - тот, в который отдаю.

 

Надо ли делать на этом порту vlan_translation pvid vlanX svid vlanX ?

 

С uni и vlan translation пробовали, но не работает. Вернее работает, но трафика идет всего 10+ мегабит - у меня теория по этому поводу: там стоит свитч, который не умеет jumbo frames, и когда порт в его сторону uni и настроен vlan translation, то хоть тег и не меняется, но mtu увеличивается и он их дропает. У меня нет доступа туда, проверить могу только способом "работает/не работает".

P.S.: коммутатор DGS-3120

Edited December 12, 2011 by h1vs2

[alexaaa]

Мы изучали механизм QinQ на длинках, постараюсь его описать. Кто знает какие-то ещё детали - подтвердите или опровергните про навешивание / снятие тегов свитчом, эксперименты с UNI/NNI показывают, что всё работает именно так, как описано.

 

QinQ и тегирование на длинках 36xx/3028-52/3200-xx работает так:

 

Сначала рассмотрим типовые порты, NNI:

 

NNI - это "сетевой", бэкбонный порт.

 

Когда на порт NNI приходит фрейм с тегом - если Ingress Checking включен, VLAN в теге сверяется с разрешенными тегами на порту. Если тег разрешен - фрейм пропускается в фабрику, если запрещен - дропается. Если Ingress Checking выключен - пропускаются все фреймы. Фрейм помечается номером VLAN, в котором он вошёл. Тег VLAN - снимается, в фабрику фрейм попадает без тега, но с внутренним маркером VLAN согласно тегу.

 

Когда на порт NNI приходит фрейм без тега - он пропускается в Native VLAN по "GVRP" PVID, и помечается номером PVID. Никаких тегов на данном этапе не навешивается.

 

Когда фрейм выходит с порта NNI, на него вешается тег согласно внутреннему маркеру VLAN. Если VLAN = PVID на порту, то тег не навешивается, и фрейм уходит нетегированным. В случае включенного QinQ фрейм тегируется не стандартным маркером VLAN (TPID = 0x8100), а тем, что указан как QinQ "outer" TPID.

 

Теперь об UNI:

 

UNI - это "тупой" клиентский порт.

 

Когда на UNI приходит фрейм, он всегда запихивается в VLAN, который установлен как "GVRP" PVID. Никаких тегов на данном этапе не снимается.

 

Когда фрейм из VLAN по PVID выходит с UNI, он выходит "как есть", без каких-либо преобразований.

 

Итого:

 

Фреймы, идущие с NNI на NNI, идут "как обычно" - в своих VLAN, без искажений. Разве что может поменяться TPID при включенном QinQ, поскольку на входе тег снимается, на выходе - навешивается согласно TPID исходящего порта и внутреннего маркера VLAN.

 

Фреймы, вошедшие на порты UNI, по фабрике пройдут вместе с тегом, и при выходе на NNI на них будет навешен дополнительный "верхний" тег VLAN (за исключением случая, когда этот VLAN - Native для порта NNI). Т.е. фрейм пойдёт с двумя тегами, в том VLAN, который указан на "GVRP" PVID порта UNI.

 

Фреймы, идущие между двумя UNI, сидящими по "GVRP" PVID в одном VLAN, войдут и выйдут "как есть", без изменений.

 

С фреймами, вошедшими с порта NNI, и выходящими по VLAN в UNI, произойдет следующее: на порту NNI при входе "верхний" тег будет снят. При выходе с UNI фрейм выйдет "как есть", без навешивания каких-либо тегов. Т.е. фрейм выйдет без верхнего тега, но с нижним, и в итоге пойдёт дальше тегированным нижним тегом.

 

Извините, вопрос как раз актуальный мне и по теме : как vlan, который не qinq и приходит с порта nni тегированым отдать в другой порт тоже тегированым, в котором будет только этот vlan?

 

Порт должен быть NNI, или UNI? - тот, в который отдаю.

 

Надо ли делать на этом порту vlan_translation pvid vlanX svid vlanX ?

 

С uni и vlan translation пробовали, но не работает. Вернее работает, но трафика идет всего 10+ мегабит - у меня теория по этому поводу: там стоит свитч, который не умеет jumbo frames, и когда порт в его сторону uni и настроен vlan translation, то хоть тег и не меняется, но mtu увеличивается и он их дропает. У меня нет доступа туда, проверить могу только способом "работает/не работает".

P.S.: коммутатор DGS-3120

вот пару подробных понятных статей

http://blog.peter.am/index.php/2011/01/22/q-in-q-linux-d-link

и

http://worm.org.ua/2011/10/qinq-dlink-des381028/#more-920

[h1vs2]

вот пару подробных понятных статей

http://blog.peter.am/index.php/2011/01/22/q-in-q-linux-d-link

и

http://worm.org.ua/2011/10/qinq-dlink-des381028/#more-920

 

Извините, Вы меня не поняли. У меня работает qinq ! У меня вполне конкретный вопрос, который данные мануалы не охватывают.

 

Если же нужно оставить влан с одиночным тегом (например 100) и пропустить на транзитный коммутатор, 
то нужно будет создать этот влан на агрегационном коммутаторе, назначить тегом на 1 и 2 порты и указать правило create vlan_translation ports 2 cvid 100 add svid 100.

 

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

 

Я могу проверить чисто эмпирически, вариантов осталось всего два: порт должен быть nni, и vlan просто тегом на оба порта, или тоже самое + vlan translation. Но по причине ограниченного доступа, хотелось бы услышать от людей, которые с этим сталкивались.

Edited December 12, 2011 by h1vs2

[ufm]

На сколько я понял - оба порта nni и просто тегированные вланы (ну и TPID = 0x8100) - у меня как раз делают то, что Вам нужно.

[h1vs2]

На сколько я понял - оба порта nni и просто тегированные вланы (ну и TPID = 0x8100) - у меня как раз делают то, что Вам нужно.

 

Это и хотел услышать, спасибо.

[Alex/AT]

Если с NNI на NNI или с UNI на UNI - ничего делать не надо, просто прибить VLAN к портам, и убедиться, что TPID на обоих портах выставлен правильно (стандарт - 0x8100).

 

Если надо с NNI на UNI отдать трафик с сохранением тега - делается привязка VLAN к портам, и затем create vlan_translation cvid XXX replace svid XXX на UNI-порту. В итоге трафик, вошедший на NNI с тегом XXX, выйдет с UNI также с тегом XXX. Ну и назад - то, что войдёт с UNI с тегом XXX, выйдет на NNI также с тегом XXX.

Edited December 13, 2011 by Alex/AT

[h1vs2]

Если надо с NNI на UNI отдать трафик с сохранением тега - делается привязка VLAN к портам, и затем create vlan_translation cvid XXX replace svid XXX на UNI-порту. В итоге трафик, вошедший на NNI с тегом XXX, выйдет с UNI также с тегом XXX. Ну и назад - то, что войдёт с UNI с тегом XXX, выйдет на NNI также с тегом XXX.

 

С пакетом при это ничего не случится, и MTU его не увеличится, правильно?

[Alex/AT]

Размер фрейма при этом не изменяется.

 

Размер фрейма изменяется:

а) при двойном тегировании (QinQ) без vlan_translation/replace, когда трафик с UNI проходит на NNI или наоборот. При этом при прохождении с NNI на UNI фрейм уменьшается на 4 байта, при прохождении с UNI на NNI - вырастает на 4 байта (размер тега).

б) при одиночном тегировании, когда фрейм уходит с Native VLAN (безтеговый) на Tagged VLAN, также прирастает на 4 при выходе на Tagged, убывает на 4 при выходе в Native.

Edited December 13, 2011 by Alex/AT

[ufm]

Еще вопрос к знающим людям (кстати, спасибо за предыдущие ответы - немного в мозгу прояснилось, но как видимо не до конца).

 

Есть порт 9. На него приходит нетегированный трафик.

Есть порт 1. С него этот трафик должен уходить как 2010.247

 

Я делают так:

9 порт переводится в состояние UNI.

PVID=247

VLAN=247 untagged

 

1 порт переводится в состояние NNI

VLAN=2010 tagged

 

добавлено правило трансляции для 9 порта - add cvid 247 spvid 2010

 

Не работает. Я понимаю, что я делаю что-то не так принципиально. Т.е. я могу, конечно, подёргать за все подряд пока не получится то что мне надо, но хотелось бы, всё таки, понимать как оно внутри тикает.

[Alex/AT]

надо трансляцию вида cvid 247 add svid 247 на 9 порту (100% не уверен - возможно так вообще нельзя делать, и работать не будет)

тогда у вас на входе UNI по идее вместо антега навесится 247 тег, и далее он выйдет в 1 порт, на котором навесится 2010 - т.е. outer будет 2010, inner - 247

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

Edited December 18, 2011 by Alex/AT

[ufm]

надо трансляцию вида cvid 247 add svid 247 на 9 порту (100% не уверен - возможно так вообще нельзя делать, и работать не будет)

тогда у вас на входе UNI по идее вместо антега навесится 247 тег, и далее он выйдет в 1 порт, на котором навесится 2010 - т.е. outer будет 2010, inner - 247

Меня смущает один момент - а как оно узнает что этот пакет надо закидывать на первый порт? Ведь по идее в таком варианте нет нигде никакого намёка на то, что пакет пришедший через 9 порт с навешенным на него 247 вланом надо запихивать в 1 порт, где на него еще 2010 навесят.

 

Есть еще такой пункт как - "Add Inner Tag" при настройке порта. Возможно он мне поможет?

 

А еще встречал такое интересное упоминание:

"На одном коммутаторе серии DGS-36xx всего можно создать 768 правил vlan_translation.

Обходится это ограничение с помощью настройки PVID и отключением функции “missdrop disable” на UNI порту. При данных настройках все входящие фреймы с тегом 802.1Q будут метиться SPVID = PVID."

 

Возникает два вопроса - будет ли это работать для других свичей, и что будет с пакетом если на порту включу missdrop enable, повешу untagged vlan 247 на порт и пропишу 2010 в pvid

 

P.S. Блин, ну почему длинки не написали _внятную_ документацию. :(

[Alex/AT]

Надо на стенде поглядеть. Трансляции у него двухсторонние, по логике работы вешаются именно на UNI, но перемаркировка видимо идёт где-то в фабрике между входом с порта и выходом.

[ufm]

Поддержка длинка ответила так:

"Вы не совсем так делаете. Если на входе трафик не тегирован, а на выходе должен содержать два тега, то нужно использовать параметр add_inner_tag."

Попробую на днях - отпишусь.

[ufm]

Получилось ровно на половину. Т.е.на 1 порт трафик приходит с двумя тегами. А вот уходит с 9 порта как-то непонятно как.

[ufm]

ДЛинковский саппорт подтвердил странность поведения свича и обещал связаться со штабквартирой.

[ufm]

Для интересующихся: бага была поправлена в прошивке 2.00.B026

[Prihod]

В 09.02.2012 в 12:24, ufm сказал:

Для интересующихся: бага была поправлена в прошивке 2.00.B026

Решилась ли в итоге бага? на какой прошивке? и какими командами?

[vurd]

8, мать его, лет

[AlKov]

8 часов назад, vurd сказал:

8, мать его, лет

Некроманты.. Мать их... ;-)

[sirmax]

2 минуты назад, AlKov сказал:

Некроманты.. Мать их... ;-)

Правильно говорит « некропостеры»;)

[AlKov]

19 минут назад, sirmax сказал:

Правильно говорит « некропостеры»;)

Да-да. Согласен. Старый стал, не поспеваю за изменяющейся феней терминологией. :-)