ufm Опубликовано 11 декабря, 2011 · Жалоба Приветствую. Есть ли люди, которые используют в своей практике QinQ на длинках? У меня какое-то глубинное недопонимание данной технологии. Допустим на свиче включено QinQ. Есть четыре порта (1,2,3,4). Порты 1 и 2 - UNI. 3 и 4 - NNI. На все порты приходит VLAN 10. На 1 и 3 - tagged, на 2 и 4 - untagged. И тут у меня ступор в мозгу. Ступор в том, что я непонимаю что в данном случае делает tagged и untagged с портом. Если есть понимающие люди - помогите, пожалуйста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 12 декабря, 2011 (изменено) · Жалоба Мы изучали механизм 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 фрейм выйдет "как есть", без навешивания каких-либо тегов. Т.е. фрейм выйдет без верхнего тега, но с нижним, и в итоге пойдёт дальше тегированным нижним тегом. Изменено 12 декабря, 2011 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 12 декабря, 2011 (изменено) · Жалоба Мы изучали механизм 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 Изменено 12 декабря, 2011 пользователем h1vs2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 12 декабря, 2011 · Жалоба Мы изучали механизм 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 12 декабря, 2011 (изменено) · Жалоба вот пару подробных понятных статей 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. Но по причине ограниченного доступа, хотелось бы услышать от людей, которые с этим сталкивались. Изменено 12 декабря, 2011 пользователем h1vs2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 12 декабря, 2011 · Жалоба На сколько я понял - оба порта nni и просто тегированные вланы (ну и TPID = 0x8100) - у меня как раз делают то, что Вам нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 12 декабря, 2011 · Жалоба На сколько я понял - оба порта nni и просто тегированные вланы (ну и TPID = 0x8100) - у меня как раз делают то, что Вам нужно. Это и хотел услышать, спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 декабря, 2011 (изменено) · Жалоба Если с 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. Изменено 13 декабря, 2011 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
h1vs2 Опубликовано 13 декабря, 2011 · Жалоба Если надо с NNI на UNI отдать трафик с сохранением тега - делается привязка VLAN к портам, и затем create vlan_translation cvid XXX replace svid XXX на UNI-порту. В итоге трафик, вошедший на NNI с тегом XXX, выйдет с UNI также с тегом XXX. Ну и назад - то, что войдёт с UNI с тегом XXX, выйдет на NNI также с тегом XXX. С пакетом при это ничего не случится, и MTU его не увеличится, правильно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 декабря, 2011 (изменено) · Жалоба Размер фрейма при этом не изменяется. Размер фрейма изменяется: а) при двойном тегировании (QinQ) без vlan_translation/replace, когда трафик с UNI проходит на NNI или наоборот. При этом при прохождении с NNI на UNI фрейм уменьшается на 4 байта, при прохождении с UNI на NNI - вырастает на 4 байта (размер тега). б) при одиночном тегировании, когда фрейм уходит с Native VLAN (безтеговый) на Tagged VLAN, также прирастает на 4 при выходе на Tagged, убывает на 4 при выходе в Native. Изменено 13 декабря, 2011 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 17 декабря, 2011 · Жалоба Еще вопрос к знающим людям (кстати, спасибо за предыдущие ответы - немного в мозгу прояснилось, но как видимо не до конца). Есть порт 9. На него приходит нетегированный трафик. Есть порт 1. С него этот трафик должен уходить как 2010.247 Я делают так: 9 порт переводится в состояние UNI. PVID=247 VLAN=247 untagged 1 порт переводится в состояние NNI VLAN=2010 tagged добавлено правило трансляции для 9 порта - add cvid 247 spvid 2010 Не работает. Я понимаю, что я делаю что-то не так принципиально. Т.е. я могу, конечно, подёргать за все подряд пока не получится то что мне надо, но хотелось бы, всё таки, понимать как оно внутри тикает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 18 декабря, 2011 (изменено) · Жалоба надо трансляцию вида cvid 247 add svid 247 на 9 порту (100% не уверен - возможно так вообще нельзя делать, и работать не будет) тогда у вас на входе UNI по идее вместо антега навесится 247 тег, и далее он выйдет в 1 порт, на котором навесится 2010 - т.е. outer будет 2010, inner - 247 единственное что не помню - так это точный механизм трансляций, и работают ли трансляции на антеге. на неделе сунусь в доки и на стенд, погляжу, вопрос интересный Изменено 18 декабря, 2011 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 18 декабря, 2011 · Жалоба надо трансляцию вида 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. Блин, ну почему длинки не написали _внятную_ документацию. :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 декабря, 2011 · Жалоба Надо на стенде поглядеть. Трансляции у него двухсторонние, по логике работы вешаются именно на UNI, но перемаркировка видимо идёт где-то в фабрике между входом с порта и выходом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 19 декабря, 2011 · Жалоба Поддержка длинка ответила так: "Вы не совсем так делаете. Если на входе трафик не тегирован, а на выходе должен содержать два тега, то нужно использовать параметр add_inner_tag." Попробую на днях - отпишусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 20 декабря, 2011 · Жалоба Получилось ровно на половину. Т.е.на 1 порт трафик приходит с двумя тегами. А вот уходит с 9 порта как-то непонятно как. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 21 декабря, 2011 · Жалоба ДЛинковский саппорт подтвердил странность поведения свича и обещал связаться со штабквартирой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ufm Опубликовано 9 февраля, 2012 · Жалоба Для интересующихся: бага была поправлена в прошивке 2.00.B026 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Prihod Опубликовано 4 апреля, 2020 · Жалоба В 09.02.2012 в 12:24, ufm сказал: Для интересующихся: бага была поправлена в прошивке 2.00.B026 Решилась ли в итоге бага? на какой прошивке? и какими командами? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 4 апреля, 2020 · Жалоба 8, мать его, лет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 4 апреля, 2020 · Жалоба 8 часов назад, vurd сказал: 8, мать его, лет Некроманты.. Мать их... ;-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 4 апреля, 2020 · Жалоба 2 минуты назад, AlKov сказал: Некроманты.. Мать их... ;-) Правильно говорит « некропостеры»;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 4 апреля, 2020 · Жалоба 19 минут назад, sirmax сказал: Правильно говорит « некропостеры»;) Да-да. Согласен. Старый стал, не поспеваю за изменяющейся феней терминологией. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...