[wtyd]

Раньше с ку-ин-ку не сталкивались. Собрали небольшой стенд. Пока понимание такое: придётся по всей сети раскинуть один влан, который в терминологии длинка называется SP-VLAN. В него на краях сети на уровне доступа будут инкапсулироваться все клиентские вланы. Во всех свичах доспута, куда подключен клиент, надо сделать все порты nni, а порты этого клиента как uni, так же надо подать в порты этого клиента его SP-VLAN в нетегированном виде. На этих портах клиент сможет заюзать все 4096 вланов, фильтрации со стороны провайдера никакой.

 

1. Это всё или ещё что-то надо сделать ?

 

2. Обязательно ли, чтобы тип фрейма был 0х88a8 ? Например, DES-3028 не позволяет задать 0x8100 для q-in-q. Пролезут ли фреймы типа 0х88a8 через промежуточные коммутаторы ? Это мы пока не проверяли.

 

3. Клиент почему-то хочет, чтобы в одном месте у него были вланы с номерами 3,5,7,9 , а в другом 4,6,8 , а в третьем ещё какой-то набор. Вланы надо отдать в теге там, где их несколько, где клиент хочет один влан -- надо отдать без тега. Это вообще можно сделать на одном провайдерском свиче доступа ? Я понял, что свич умеет снимать один тег и всё, дальше вся пачка вланов вылетает клиенту и дальше уже проблемы/оборудование клиента должно разгребать. Но клиент скорее всего захочет, чтобы у него вообще проблем не было и ничего делать с его стороны было бы не нужно :-).

 

4. Теоретический вопрос. Вот мы десятилетиями занимались сегментированием сети на вланы для наведения порядка и для уменьшения броадкастовых доменов, а тут один влан по всей сети надо раскидать -- один большой броадкаст домен. Понятно, что разные клиентские вланы друг друга не увидят, но броадкаста-то меньше не станет -- весь броадкаст со всех клиентских вланов будет носиться по всей сети в провайдерском влане. С этим можно что-то сделать ? Пока мы собрались просто забить на этот факт. С этим вообще бывают проблемы или все так и живут с броадкастом ?

[Serejka]

1. disable stp, enable jumbo

2. ethertype 0x8100 это стандарт dot1q, его отлично жуют вообще любые железки не подозревающие о том что на самом деле фрейм dot1ad. Когда запускали первые линки, с 0x88a8 были какие-то бока, сильно в подробности не вдавались, строилось через транспортную сеть партнёра, который берёт l2 mpls у магистрала, и удалённый сайт за 120 км. В итоге dlinkу сказал работать с 8100, кроме dlink и extreme, сходу и не вспомню где вообще можно поменять ethertype - так что наш корпоративный стандарт 8100 для всего qinq. (отлично жуют eltex,cisco, linksys и тд)

 

3. Сделайте прозрачное 1ad клиенту, и в ус не дуйте, если есть такая возможность. В ином случае клиент будет вас постоянно просить прописывать, переписывать и тд ему вланы.

 

Прозрачно это конфиг вида (Для 3120)

config qinq ports 1:24  outer_tpid 0x8100
config qinq ports 1:23 role uni outer_tpid 0x8100

create vlan Transport_vlan tag 3001
config vlan Transport_vlan add tagged 1:24
config vlan Transport_vlan add untagged 1:23 advertisement disable

 

Всё что прилетело в 23 порт с любыми тегами окажется внутри транспортного и улетит в аплинк.

 

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

 

 

4. Клиент желает чтобы вы ему построили L2 сеть, я считаю, что это не ваше дело - чем он там будет заниматься, режьте полосу согласно договора, ну и storm-control.

 

 

апд. Третий пункт скорее всего разруливается так же через selective qinq - но у нас пока нет необходимости кроить на этом.

апд2. По поводу 3028 - в глаза сего монстра не видел, но у 1210-28ME - с этим проблем никаких.

[wtyd]

Спасибо за ответ. Тоже в сторону 8100 стали уже думать. Прикрутили к стенду не-длинк -- работать перестало :-). Точнее так: поставили как бы просто транзитный свич e-core ECS3510-28T, прокинули через него транспортный влан и ... всё заработало, но через влан номер 1 :-). Почему-то кора при виде 88a8 скидывает фрейм в первый влан и потом обратно его "обувает" правильно. Смотрел по таблице мак-аддресов, может просто отображается неправильно, но всёравно это нам не подходит. Включать qinq на корке в данном случае не следует, т.к. свич-то транзитный, но ради интереса включали в разных комбинациях -- не работает :-). фреймы теряются в е-коре. В вимком письмо написал с описанием проблемы. Поэтому решили, что *надо* юзать 8100, хоть это и потребует замены с десяток мутаторов.

 

Кстати, на самой корке ещё надо попробовать ... но скорее всего заработает нормально с 0x8100.

[Avad0n]

wtyd, странно, у нас через пачку оборудования (в том числе и через Edge-Core ES3510ma) бегают qinq вланы упакованые на d-link dgs-3120-24sc с tpid 0x88a8 и проблем не замечали. На Ёжике только включили jumbo и всё. Скорее всего на вашем ECS3510-28T , какой то нюанс с софтом.

Изменено 9 ноября, 2016 пользователем Avad0n

[wtyd]

wtyd, странно, у нас через пачку оборудования (в том числе и через Edge-Core ES3510ma) бегают qinq вланы упакованые на d-link dgs-3120-24sc с tpid 0x88a8 и проблем не замечали. На Ёжике только включили jumbo и всё. Скорее всего на вашем ECS3510-28T , какой то нюанс с софтом.

 

ES3510ma более старая модель, там всё уже вылизано и проверено :-). Софт у нас в ECS3510-28T последний с фтп вимкома, конфиг почти дефолтный -- лаба же, только тестируемая конфигурация. Т.е. один транспортный влан и всё :-), это потом уже ради интереса стали qinq включать и смотреть.

 

Интересно, можно ли как-то от длинков получить спец прошивку для DES-3028, где тип фрейма 0x8100 ? Или это в микросхеме так сделано, что 0х8100 нельзя выставить ? Другие номера, если правильно помню, можно поставить, но что из этого выйдет далее ... не можем же мы все виды свичей проверять :-).

[rdc]

2. Обязательно ли, чтобы тип фрейма был 0х88a8? Например, DES-3028

Это косяк 3028 (и 1228/ME revision A, что то же самое) - он при включении qinq может ставить какой угодно tpid, но только не 8100.

Прошивкой не исправляется, это недоработка чипа.

На всех последующих моделях без проблем ставится 8100.

 

где клиент хочет один влан -- надо отдать без тега. Это вообще можно сделать на одном провайдерском свиче доступа?

А это называется add_inner_tag. Есть в относительно современных моделях.

Но даже если его нет, это можно сделать петлёй, потратив два порта.

[wtyd]

2. Обязательно ли, чтобы тип фрейма был 0х88a8? Например, DES-3028

Это косяк 3028 (и 1228/ME revision A, что то же самое) - он при включении qinq может ставить какой угодно tpid, но только не 8100.

Прошивкой не исправляется, это недоработка чипа.

На всех последующих моделях без проблем ставится 8100.

 

где клиент хочет один влан -- надо отдать без тега. Это вообще можно сделать на одном провайдерском свиче доступа?

А это называется add_inner_tag. Есть в относительно современных моделях.

Но даже если его нет, это можно сделать петлёй, потратив два порта.

 

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

 

При add_inner_tag другие клиентские вланы по идее должны вылетать в сторону клиента в тегированном виде (например, тут походий вопрос http://forum.dlink.ru/viewtopic.php?f=2&t=164812), этого можно избежать ? Т.е. надо чтобы клиенту отдавался только один его влан какой клиент скажет. Было бы замечательно :-).

 

Ещё интересует название аналогичной add_inner_tag фичи у других вендоров, у cisco и e-core, например.

Изменено 11 ноября, 2016 пользователем wtyd

[Serejka]

Ещё интересует название аналогичной add_inner_tag фичи у других вендоров, у cisco и e-core, например.

 

это фича уровня selective-qinq

[wtyd]

Ещё интересует название аналогичной add_inner_tag фичи у других вендоров, у cisco и e-core, например.

 

это фича уровня selective-qinq

 

selective-qinq хочет тегированный фрейм чтобы засунуть его в указанный SP-VLAN -- ему нужно откуда-то узнавать номер влана. На e-core сегодня попробовал, не получается двойной таг снимать на одном порту, пробовал разные native vlan на порту указывать -- на зависит от номера native.

 

На форуме вимкома нашёл тему -- подтверждают (давно ещё это было :-)). Для технологии qinq нужет ещё один типа клиентский коммутатор, который будет второй тег снимать и фильтровать "остальные" клиентские вланы. add_inner_tag у длинка скорее всего только снимает указанный второй таг, но не фильтрует остальные клиентские вланы. Подходящего длинка под рукой нет, проверить это пока не могу.

[rdc]

Для технологии qinq нужет ещё один типа клиентский коммутатор, который будет второй тег снимать и фильтровать "остальные" клиентские вланы.

Либо ещё два порта на имеющемся коммутаторе, с петлёй между ними. Работает так же.

[wtyd]

Для технологии qinq нужет ещё один типа клиентский коммутатор, который будет второй тег снимать и фильтровать "остальные" клиентские вланы.

Либо ещё два порта на имеющемся коммутаторе, с петлёй между ними. Работает так же.

 

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