QinQ и dlink 3200_28 и 3627G

[hijke]

Здравствуйте!

 

Имеется задачка. Хотелось бы выслушать мнения по поводу ее реализации.

Имеется домовая сеть в которой на доступе стоят DES-3200 и DGS-3627G на аггрегации. Сеть в виде колец замыкаемых на аггрегации.

DGS'ы между собой включены звездой через опорный узел. На кольцах настроен RSTP,бегает один PPPoE vlan , один management vlan и отдельные vlan для отдельных клиентов - юриков.

Поступила задача прогнать через сеть 2 влана клиента:

L2 канал с сохранением значений пользовательских VLAN-ID, наша сеть должна обеспечивать пропуск пользовательского MTU = 1522 Bytes (IP MTU + Ethernet frame + 802.1q tag),маркировка клиентом возможна только DSCP.

 

Имеется несколько точек подключения куда нужно догонять эти вланы. На всех этих конечных точках будут стоять DES-3200_28

После чтения форума и презентации выяснилось что нужно использовать port-based qinq.

Хотелось уточнить в правильном ли направлении мыслю.

Со стороны клиента на наш untag порт будет забирать от клиента его трафик с двумя разными vlan и на этом же коммутаторе упаковывать их в один внешний vlan (например VID-666) и гнать его до места стыка.

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

Jumbo frame так же на всех коммутаторах включать нужно ?

Вроде как еще используется GVRP , можно ли обойтись без него если руками на всех транзитных коммутаторах добавить этот 666 vlan?

И вообще в правильном направлении мыслю?)

 

P.S пока начиню пробовать все на стендне клиентский SW - DES-3200 - DGS-3420TC(за неимением в запасе 3627G) - DES-3200 - SW клиента

[dazgluk]

В целом верно, но:

1. DSCP тут абослютно не причем, маркировка клиентом будет осуществляться средствами 802.1Q, то есть его тегами

2. QinQ нужно включать только на крайних устройствах, но будте аккуратны, Dlink ведут себя странно и команда enable qinq на некоторых моделях включит UNI (режим упаковки) на все порты, после этого вы сможете достучаться к нему только с консолью :)

3. Jumbo frame нужно включить на всем пути.

4. MTU считается с учетом IP заголовка, следовательно вам нужен всего лишь 1504 + верхний тег (как правило тоже уже учитывается на железе)

[hijke]

А клиентские vlan на своих граничных коммутаторах заводить нужно?

[Butch3r]

Нет, делаете порты untag со своими вланами и переводите их в режим UNI. tpid 0x8100.

[hijke]

В нашем случае это будет один порт.

получается мы на свой один untag порт можем принять тэгированный трафик с двумя вланами от клиента и обернуть его своим тегом?

[folko]

На DGS-3627Gи на 3200-28 включи qinq

Только есть нюанс при включении - в момент включения q-in-q надо зашатдаунить клиентские порты,выключить STP

conf ports 1-20 st dis

disable stp

Далее инкрементарно залить настройки - не то будет беда :)

download cfg_fromTFTP Х.Х.Х.Х src_file increment_sv.txt increment

 

файл с такой начинкой

#-------------------------------------------------------------------------------

 

# DGS-3627G Gigabit Ethernet Switch

 

# Configuration

 

#

 

# Firmware: Build 2.52.B45

 

# Copyright© 2009 D-Link Corporation. All rights reserved.

 

#-------------------------------------------------------------------------------

 

 

 

enable qinq

config qinq ports 1-20 role uni missdrop disable tpid 0x8100

config qinq ports 20-22 role nni missdrop disable tpid 0x8100

 

 

#-------------------------------------------------------------------

 

# End of configuration file for DGS-3627G

 

#-------------------------------------------------------------------

Далее создаешь обычные VLAN, в кольцо подаешь в транке и делаешь реплейс самого в себя

create vlan_translation ports 1 cvid 666 replace svid 666

 

на свитче доступа проделай то же самое, но делай теперь не реплейс

create vlan_translation ports 1 cvid 500 add svid 666

create vlan_translation ports 1 cvid 501 add svid 666

[hijke]

Извините, не совсем понял про реплейс самого в себя(

При таком описании какое Вы дали второй тег будет навешиваться уже на уровне доступа?

Еще важно бы знать на доступе висят PPPoE клиенты в своем влане, их эта вся эпопея никак не затронет?

[folko]

Не затронет :)

Реплейс сам в себя и даелется чтобы догнать безболезненно в свитчу доступа.

Реплейсите на узле 3627, добавлеяете в SVLAN на доступе.

Так же, реплейс надо делать только на UNI портах, на NNI нет необходимости.

[hijke]

Вот с шатдауном клиентских портов грустно получается) Особенно на уровне аггрегации ,если все порты погасить то рухнут кольца с клиентами((

А почему на аггрегации с 1 по 20 порт они будут uni, разве не nni?

 

Схемка для наглядности кстати)

http://s019.radikal.ru/i603/1308/f4/b11810098787.jpg

[folko]

А почему на агрегации с 1 по 20 порт они будут uni, разве не nni?

Ну у каждого свои схемы :)

 

UNI все порты что смотрят в кольца, аплинк/даунлинк - NNI

Особенность такова, что глючит 3627 во время включения qinq при включенном STP, а именно перестает работать L3(менеджмент, сервисы), включать не через increment-заливку.

 

Даунтайм будет минимальный, абоненты заметят прерывание, но не более если все подготовить.

!!!Еще забыл упомянуть - если включите qinq - надо будет и для существующих VLAN сделать реплейсы самих в себя!!!

[hijke]

Мда , слегка заморочливо получается)

Реплейсы самих в себя это что то вроде костыля получается?

Edited August 16, 2013 by hijke

[Butch3r]

Я вообще ничего не понял. Для чего выключать абонентские порты. Выложите схему, но скажу так - ничего выключать не нужно

1. на порта нужно прописать tpid 0x8100

2. написать enable qinq

3. на нужны портах включить UNI и всё

[hijke]

Схема тремя сообщениями выше.

Вообще по стандарту на коммутаторе доступа все порты антегом в PPPoE влане находятся.

После включения qinq они переходят в режим NNI - это на клиентов никак не повлияет?

От клиентов приходит не тегированный трафик.

Edited August 16, 2013 by hijke

[Butch3r]

Схема тремя сообщениями выше.

Вообще по стандарту на коммутаторе доступа все порты антегом в PPPoE влане находятся.

После включения qinq они переходят в режим NNI - это на клиентов никак не повлияет?

От клиентов приходит не тегированный трафик.

nni это обычные порты. Все их свойства сохраняются без изменений

Схемы "3 поставим выше" не вижу

 

edited: прортёр глаза и схему увидел:

1. делаем config qinq ports 1-28 role nni outer_tpid 0x8100

2. делаем enable qinq

после того, как включили qinq переводим порты, смотрящие в сторону абонента в режим uni

если нужно ограничить пропуск абонентских вланов то пишем соотвествующие правила (по умолчанию через порт пойдет все абонентские вланы)

 

p.s. лучше проверить на стенде, потому что у длинков со старой прошивкой есть нюансы с включением qinq (enable qinq).

Edited August 16, 2013 by Butch3r

[hijke]

Спасибо. На стенде как раз и пробую.

Все прошивки перед тем как собрать стенд на всех коммутаторах обновил до актуальной.

config qinq ports 1-28 role nni outer_tpid 0x8100 - получается все что nni будет оборачиваться во второй тег?

А далее как указать какой именно тег навешивать(я имею в ввиду команду)? Не через vlan_translations?

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

Edited August 17, 2013 by hijke

[Butch3r]

Нет, nni это обычный порт, который не добавляет второй тэг

[folko]

Согласен, не полностью описал ситуацию. Выключение портов не обязательно.Выключаю кольца в связи с тем, что во время реконфигурации очень лагает STP и валят петли. В остальном все верно.

 

NNI это транковые порты, UNI - access -ные.

Примерную схему реализации сервиса я описал.

Не забываем о заливке средствами increment, по влиянию я описал, по крайней мере у меня наблюдается проблема с софтом DGS36xxRun_2.84.B03.

 

Так же, если используете LinkAGG - тоже есть нюансы с включением qinq.

[hijke]

Те если потом указать 1 порт как NNI, то все вланы которые в него будут приходить будут оборачиваться вторым тегом уже на этом порту,я правильно понимаю?

[Butch3r]

Те если потом указать 1 порт как NNI, то все вланы которые в него будут приходить будут оборачиваться вторым тегом уже на этом порту,я правильно понимаю?

да нет же. Сделайте все порты NNI и напишите enable qinq. Получите всё тоже самое, как было до enable qinq. Т.е. все весь трафик будет ходить как и ходил.

 

После этого на порту абонента, которому нужен транспорт вланов необходимо прописать unt vlan И поменять настройки порта:

config qinq ports xxx role uni outer_tpid 0x8100

 

Если нужен четки форвардинг определенных вланов то настраиваете vlan_translation и делаете missdrop enable

[hijke]

Все , понял. Всем большое спасибо за помощь )

Буду пробовать на стенде , потом на рабочей схеме )

Edited August 18, 2013 by hijke

[hijke]

Вроде как завелось, на двух концах как минимум буки пингуют друг друга. Но при отключении jumbo frame на границных коммутаторах пинг не пропадет.

Не подскажете как можно проверить прохождение больших пакетов?

[Butch3r]

ping -l 2000 ip например

[hijke]

Так пробовали , все проходит, буки например пингуют друг друга.

НО если поставить ключ -f то ни 1500 ни 2000 не проходят пинги.

Если ключ -f не использовать то сколько не поставь размер пакета они по ходу будут фрагментироваться.

[dazgluk]

в Windows, ключ -l указывает payload пинга, без учета заголовков, соответственно прохождение ping -l 1472 -f говорит об MTU в 1500 байт.

 

И кстати, если у вас буки пингуют друг друга с фрагментацией, говорит о том - что 1500MTU проходит, поскольку фрагментируют они в 1500 байт и понятия не имеют о том что идут через QinQ

[hijke]

Нужно проверить на стенде проходит ли пакет 1522 байта. Поэтому и начали с пингов.