Есть задача обеспечить каждый узел доступа (DES-3200-28, DES-3200-52) своим собственным абонентским vlan'ом.
Каждый такой узел доступа имеет доступ к другим узлам через DGS-3627G в топологии "Звезда".
На абсолютно всех коммутаторах на всех портах проброшены vlan'ы 1,2,3,4,5 тагом и 32 антагом в котором сидят абоненты.
Предполагаю, что у 3627 необходимо на каждый порт, ведущий на 3200, прокинуть антагом индивидуальный vlan (прим. 101-124) и объединить их дополнительным тэгом 32. И важно чтобы остальные vlan'ы не объединялись доп.вланом.
Подскажите, пожалуйста, какие настройки Q-in-Q должны быть на каждом коммутаторе в цепочке:
-(19)DGS-3627G<10.90.90.1>(24)-(24)DGS-3627G<10.90.90.2>(1)-(25)DES-3200-28<10.90.90.101>

P.S. Желательно не включать Q-in-Q на 3200.
P.P.S. на 10.90.90.1 19-й порт глядит на циску, на которой будет настроен Q-in-Q, поэтому туда нужно передать в NNI. И между DGS-3627G тоже NNI.

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

Заранее спасибо.

Добрый день.

Пожалуйста, ознакомьтесь с документом:
ftp://ftp.dlink.ru/pub/Trainings/Switch ... ective.pdf

_________________
С уважением,
Бигаров Руслан.

Ознакомились. Но по этому документу я и не понял, можно ли вешать Q-in-Q только на определенные vlan'ы проброшенные антагом.

Т.е. у Вас все клиенты на коммутаторах доступа сидят в VLAN tag 32 и трафик нативно доходит до DGS-3627G<10.90.90.2>, на котором Вы хотите сегментировать данных трафик по разным VLAN-ам (прим. 101-124) со своими интерфесами? Я правильно понял задачу?

А далее через L3 Вы хотите их до кошки пробросить или как L2?

_________________
С уважением,
Бигаров Руслан.

Да, хотим сегментировать и пробросить как L2.

Тогда Q-in-Q не нужен для решения данной задачи. Достаточно распаковать на нужном порту как untagged нужный VLAN tag, а магистральный(ые) порт(ы) добавить как tagged.

_________________
С уважением,
Бигаров Руслан.

Не при 4k+ количестве коммутаторов

У Вас 4k+ коммутаторов агрегации?

_________________
С уважением,
Бигаров Руслан.

У нас в перспективе 4k+ коммутаторов доступа, которые должны быть изолированы друг от друга абонентскими vlan'ами, но не vlan'нами 1,2,3,4,5

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

Я писал про настройки на коммутаторах агрегации, а не на доступе.

_________________
С уважением,
Бигаров Руслан.

Но мы же собираемся изолировать именно коммутаторы доступа друг от друга. А их равно примерно количеству портов на узлах агрегации, которых больше 100. Умножаем это на 24 и получается крайне большое количество портов = vlan'ов.

Т.е. Вы хотите решение: с SP-VLAN-ом у вас ассоциируется коммутатор агрегации, а с C-VLAN-ами - его порты? При чём C-VLAN-ы будут одинаковыми на всех коммутаторах агрегации?

_________________
С уважением,
Бигаров Руслан.

Примерно так и есть, да. только еще сильнее группируя SP-Vlan. К голове подключается ~20 коммутаторов агрегации, а к ним еще по 5~10 таких же, к которым уже подключаются коммутаторы доступа. Так вот у нас в идеале должно быть эти ~20 SP-VLAN и тогда уже в них C-Vlan = количеству портов в каждой группе узлов агрегации к которым подключаются узлы доступа.

Пример: есть SP-VLAN = 32, который объединяет в себе 5 узлов агрегации, у которых 109 портов к которым подключаются коммутаторы доступа, а знач каждый дом попадает в свой C-VLAN (101-210).
И самое главное, чтобы SP-VLAN 32 был только у тех vlan'ов, которые проброшены на порты untag'ом, остальные vlan'ы пропускать как есть.
На соседнем районе у которого SP-VLAN = 33, C-VLAN так же будут в диапазоне 101-210 при таком же количестве коммутаторов агрегации.

Тогда на нативный трафик навешивается C-VLAN с помощью:
config qinq ports <portlist> role uni add_inner_tag <hex 0x1-0xffff>

SP-VLAN навешивается с помощью Port-Based Q-in-Q.

Служебный можно с помощью правил VLAN Translation Replace.

_________________
С уважением,
Бигаров Руслан.