Q in q vlan реферат

Обновлено: 05.07.2024

QinQ — технология, позволяющая тегировать траффик два раза, назначая ему сразу две метки. Зачем это надо, как настроить и какие грабли тут подстерегают — я решил описать в виде мини-статейки.
Предупреждаю сразу — если вы не относитесь к сетевикам-затейникам, то прочтение статьи может вызвать взрыв моска. …

Вообще разделение физических сетей на изолированные друг от друга виртуальные сетки или вланы (802.1q VLAN) существует уже давно. Протокол этот давно обкатан и одинаково работает везде. Но в какой-то момент стало понятно, что 12 бит для номера виртуальной сети — это всего лишь 4095 вланов. Кроме того, в сложных сетях согласование, учет и поддержание консистентных настроек для используемых номеров вланов вылился в отдельную проблему. Вдобавок, желая пропуская через свою сеть клиентский тегированный траффик, провайдерам совершенно не хотелось курить кривые и не шибко шустрые впн-ки, к тому же согласовывать свои номера вланов и номера вланов клиента — получалось далеко не всегда, и посему живительная идея пробрасывать пачку вланов между двумя точками сети, не разбираясь, что это за вланы и кто и зачем их настраивал — была востребована более чем. Поэтому разработчеги, не мудрствуя лукаво, сделали дешево и сердито — решили навешивать ещё одну метку.

Подобное извращение чаще всего встречается в двух случаях:
1). Там, где не хватило четырех с хером тысяч вланов. Это обычно провайдеры со схемой включения vlan-per-user. Схема достаточно жутенькая, но иногда встречается.
2). Там, где не удалось придти к соглашению о номерах вланов. Наиболее частый пример — это провайдеры и такие клиенты, у которых уже есть своя настроенная сеть с тегированным траффиком и сугубо со своими вланами, переделывать которую и портить костылями никому не хочется. В какой-то момент такие клиенты хотят построить единую сеть, и в этом случае клиент хочет, чтобы провайдер пробросил все его вланы каким-либо способом через свою сеть. QinQ — как раз один из таких методов.

Для примера посмотрим вот на такую схему:

Есть два клиента, у каждого из которых есть своя сложная сеть. И вот им приперло соединить свои филиалы в единую сеть, прозрачно пробросив свои вланы через сеть вышележащего прова. Понятно, что согласовать вланы и обойтись простым тегированием тут не выйдет. Влан 1 (он же влан по-умолчанию) у каждого клиента свой, а у провайдера — свой. Да и админ банка сильно удивится, если увидит в своем втором влане левый траффик от добывающей компании 😀 .

Клиенту тут сплошные удобства — ему не надо вообще задумываться про QinQ, он строит свои собственные вланы как он хочет.

Теперь посмотрим, как это работает. Смотреть будем Wireshark-ом, втыкая его в нужный порт на тестовом стенде. Скажу честно — без раскурки дампов траффика поначалу въехать может быть тяжеловато.
Простое одиночное тегирование по 802.1q, оно же влан-вульгарис, работает вот так:
[Eth-Header; type: 0x0800] [IP] —802.1q—>
[Eth-Header; type: 0x8100] [802.1q; VLAN: 2; type: 0x0800] [IP]
Я постарался выделить добавленный заголовок и изменившиеся значения типа полезной нагрузки. Тут никаких особых проблем нет.

QinQ повторяет подобный трюк еще раз, и вот тут мы встречаем самые первые грабли.
По стандарту QinQ (он же 802.1ad) должен работать вот так:
[Eth-Header; type: 0x8100] [802.1q; VLAN: 2; type: 0x0800] [IP] —QinQ—>
[Eth-Header; type: 0x88a8] [802.1ad; VLAN: 3015; type: 0x8100] [802.1q; VLAN: 2; type: 0x0800] [IP]
В дампе траффика это выглядит вот так:

Однако такой тип в L2-заголовке, хоть и прописан в стандарте, нормально понимают только некоторые типы железок.

Приснопамятная циска решила, что нехх мутить воду, и решила специальное значение type = 0x88a8 для QinQ-траффика не использовать, вместо этого навешивая два совершенно одинаковых 802.1q-заголовка подряд:
[Eth-Header; type: 0x8100] [802.1q; VLAN: 2; type: 0x0800] [IP] —Cisco-QinQ—>
[Eth-Header; type: 0x8100] [802.1q; VLAN: 3015; type: 0x8100] [802.1q; VLAN: 2; type: 0x0800] [IP]
В дампе траффика это выглядит вот так:

Так вот — это вызывает определенную попаболь при попытке состыковать оборудование разных производителей. Вещь неочевидная, и детально особо нигде не описанная. Формально и то, и другое — дважды тегированный траффик, но QinQ по стандарту имеет право называться только первый вариант. К сожалению, у циско тут нашлись последователи, так что тип 0х8100 в QinQ-траффике вполне себе живет и здравствует. Так что если у вас все настроено, но траффик не ходит или ходит как-то странно и местами — проверьте тип. Это особенно актуально, если на разных концах туннеля используется оборудование от разных производителей. Например, в датацентре может стоять теплая ламповая циска, а на втором конце туннеля в Урюпинске — D-Link или ещё что похуже.

Внутренние интерфейсы, смотрящие внутрь провайдерской сети, настраиваются как обычные транки, для которых разрешается прохождение вланов 3015 и 3016, выделенных QinQ-клиентам. О внутренних вланах клиента провайдеру как правило знать ничего не требуется, и в настройке там ничего интересного нет.

Итак, вы познали дзен L2-типов, прописали везде 0x8100 (на некоторых цисках — 0x9100 и даже 0x9200 для пущего кайфа 😀 :D), и тут вас подстерегают следующие грабли.

Остальные грабли более специфичны и фичасты, и по ним мы прогуляемся в процессе настройки.

На циске
Тут все достаточно просто. Убеждаемся, что SystemMTU — торт, создаем выделенный для клиента влан, в который завернем клиентские вланы, пропишем его на промежуточных транках, как обчно. Потом на порту, смотрящем в сторону ТвистГаза, пишем:

Посмотреть на содеянные безобразия —

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

Тут тоже лежит специальный бережно сохраненный костыль — у разных цисок набор допустимых к включению типов разный. Стороннее оборудование естественно иногда не понимает, что это за НЁХ с 0x9100 :cat: Собственно, всё. Более сложные случаи рассматриваются в документации, например на сайте циски.

Особый фактор риска — это управление в не-нативном влане c VLAN_iD != 1. Тут вероятность отстрелить себе яйца в процессе настройки гораздо выше.
Поехали настраивать. Скажу сразу — мы не используем асимметричные вланы, и как оно стыкуется с QinQ конкретно на д-линке — без малейшего понятия. Я предполагаю, что следующие две настройки у вас вот такие:

Настроим самый обычные вланы, какие мы делаем обычно, но назовем их понятным образом:

Вздрогнули, помолились, включаем:

Теперь настраиваем собственно QinQ. И вот мы получаем по лбу первыми граблями от д-линка. На свитче со включенным QinQ порт может быть в двух режимах — UNI и NNI. Д-линк прямо пишет в документации, что первый — для клиентского траффика, а NNI-порты должны смотреть в сторону ядра сети. После включения все порты однако будут именно в NNI-режиме. Отдельного Normal-режима или access-порта-вульгарис при включенном глобально qinq на д-линке не предусмотрено. Остерегайтесь граблей 😀

А что всё-таки делать с обычными клиентскими access-портами на этом же свитче ? Д-линк, насколько я понял, подразумевает их настройку как UNI, но в этом случае если клиент пошлет туда тегированный траффик — он отправится по нашей сети дважды тегированным. Если разобрать такой траффик будет некому — то для нас ничего страшного не случится. Если оставить их как NNI (то есть для тегированного траффика вторая метка не навешивается, режим включенный по умолчанию), то доступ порта к вланам все равно по-прежнему будет регулироваться настройками обычных вланов. В документации от д-линка этот вопрос освещен достаточно мутно. На DES-3200-10 обычный клиентский порт, добавленный как untagged в соответствующий клиентский влан, нормально работал как в UNI, так и в NNI-режиме. Я рекомендую оставить настройку в NNI, в этом случае вторая метка навешиваться точно не будет (нафиг эту головную боль на клиенстких портах), а членство во вланах регулироваться будет как обычно.

Тут грабли с TPiD встречаются нам ещё раз: при глобально действующем outer_tpid нужно ставить 0х8100. При любых других значениях обычные (не-QinQ) вланы работать не будут вовсе. Если кстати у вас управляющий влан — не нативен (то есть ходит тегированным), то смена outer_tpid на что-либо отличное от 0x8100 приведёт к невозможности приема одиночно тегированного траффика другим оборудованием, и соответственно к потере управления свитчем с последующим отлётом яиц в дальний космос. Да, д-линк такой д-линк. На свитчах типа DGS-3627G с этим получше — там в новых прошивках уже можно задавать TPiD для каждого порта отдельно. Не прошло и десяти лет.

Поскольку нам не интересно вмешиваться во внутренние теги (мы настраиваем Port-Based QinQ, про Selective QinQ пока не будем), то выключаем влан-трансляцию и доверие клиентским VLAN_iD:

Теперь надо решить, какой тип дважды тегированного траффика будет. У меня заработало на значении 0x8100 (dot1q-tunnel, который Cisco-QinQ), но поскольку у д-линка по умолчанию включен стандартный QinQ (0x88a8) — то меняем:

Чтобы включить назад стандартный QinQ, соответственно:

Тут тоже у д-линка лежит ещё одна кучка садово-огородного инвентаря. На куче железок поменять можно только тип исходящих кадров, и только для _всех_ портов сразу. Попытка сменить outer_tpid только для одного порта — сопровождается оповещением, что параметр сменен глобально.

Теперь переводим порт, смотрящий в сторону клиента, в режим навешивания второй метки для тегированного траффика:

После этого входящий в порт траффик будет независимо то наличия первой метки оборачиваться второй меткой из значения PVID для этого порта (именно для этого мы указали, что порт 8 — нетегированный в 3015-м влане) и отправляться в сеть внутри кадра с типом из outer_tpid.
Транк-порт оставляем в режиме NNI — там ничего трогать как правило не надо, разве что разрешить прохождение нового qinq-влана.

Какие ещё грабли могут подстерегать ? Могут возникнуть траблы с передачей нетегированного траффика внутри QinQ-туннеля. Решается вот такой командой для клиентского порта:

Опять же детали не скажу — тут надо много тестить, на каждой железке есть свои багофичи и прочие неисправимые преимущества.

Мониторинг траффика Wireshark-ом — это конечно няшно и красиво, но хотелось бы ещё иметь возможность активно вмешиваться в тестирование, генерируя поток нужного типа траффика со своего ноута и проверяя, куда и как это траффик ходит. Короче, нам надо уметь поднимать сабинтерфейсы для дважды тегированного траффика как на железках, которые это умеют, так и на тестовой машине со сниффером.
На маршрутизаторах циско сабинтерфейс для дважды тегированного траффика поднимается легко, красиво и непринужденно:

Вообщем, также как и обычные сабинтерфейсы, только в параметре encapsulation указываем ещё и second-dot1q .
Что касается д-линков, то там сабинтерфейсы для дважды тегированного траффика наши железки не умеют, увы.

На линуксе (Fedora17) QinQ-сабинтерефейс поднимается аналогично интерфейсу в одиночном влане, с помощью команды vconfig. Например, для анализа траффика в выше приведенной схеме делем вот так:

Этими командами мы создали для сетевой карты eth0 два сабинтерфейса для снятия внешних меток — eth0.3015 / eth0.3016 и еще четыре сабинтерфеса для qinq-траффика: eth0.3015.1, eth0.3015.2, eth0.3016.1 и eth0.3016.2 . Настройка параметров делается с помощью того же ifconfig:

На FreeBSD (8.2) мне удалось поднять только одиночно тегированный сабинтерфейс, фокус с QinQ не прошел. Фряха без проблем работает с сабинтерфейсами для обычных вланов, а вот с QinQ не вышло — сабинтерфейс на сабинтерфейсе уже не создается.

На винде разбор QinQ вам не грозит ни в каком виде и никак, даже если вы сделаете миньет Баллмеру. Там и обычные-то вланы нихера нативно не поддерживаются (только на некоторых сетевухах, криво и после продолжительного секаса с дровами), а про qinq даже не мечтайте, не в этой жизни. В контексте данной статьи Windows Server 2008 Datacenter Edition и Windows 95 для нас одинаково убоги и для тестирования абсолютно непригодны.

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

Функция Q-in-Q, также известная как Double VLAN, соответствует стандарту IEEE 802.1ad, который является расширением стандарта IEEE 802.1Q . Она позволяет добавлять в маркированные кадры Ethernet второй тег IEEE 802.1Q .

Благодаря функции Q-in-Q провайдеры могут использовать их собственные уникальные идентификаторы VLAN (называемые Service Provider VLAN ID или SP-VLANID) при оказании услуг пользователям, в сетях которых настроено несколько VLAN . Это позволяет сохранить используемые пользователями идентификаторы VLAN ( Customer VLAN ID или CVLAN ID), избежать их совпадения и изолировать трафик разных клиентов во внутренней сети провайдера.

Формат кадра Q-in-Q

На рис. 6.18 изображены форматы обычного кадра Ethernet, кадра Ethernet с тегом 802.1Q, кадра Ethernet с двумя тегами 802.1Q.

Инкапсуляция кадра Ethernet вторым тегом происходит следующим образом: тег, содержащий идентификатор VLAN сети провайдера (внешний тег), вставляется перед внутренним тегом, содержащим клиентский идентификатор VLAN . Передача кадров в сети провайдера осуществляется только на основе внешнего тега SP- VLAN ID, внутренний тег пользовательской сети CVLAN ID при этом скрыт.

Реализации Q-in-Q

Существует две реализации функции Q-in-Q: Port-based Q-in-Q и Selective Q-in-Q. Функция Port-based Q-in-Q по умолчанию присваивает любому кадру, поступившему на порт доступа граничного коммутатора провайдера, идентификатор SP-VLAN, равный идентификатору PVID порта. Порт маркирует кадр независимо от того, является он маркированным или немаркированным. При поступлении маркированного кадра в него добавляется второй тег с идентификатором, равным SP-VLAN. Если на порт пришел немаркированный кадр, в него добавляется только тег с SP-VLAN порта.

Функция Selective Q-in-Q является более гибкой по сравнению с Port-based Q-in-Q. Она позволяет:

маркировать кадры внешними тегами с различными идентификаторами SP- VLAN в зависимости от значений внутренних идентификаторов CVLAN;
задавать приоритеты обработки кадров внешних SP- VLAN на основе значений приоритетов внутренних пользовательских CVLAN;
добавлять к немаркированным пользовательским кадрам помимо внешнего тега SP- VLAN внутренний тег CVLAN.

Значения TPID в кадрах Q-in-Q

В теге VLAN имеется поле идентификатора протокола тега (TPID, Tag Protocol IDentifier), который определяет тип протокола тега. По умолчанию значение этого поля для стандарта IEEE 802.1Q равно 0x8100.

На устройствах разных производителей TPID внешнего тега VLAN кадров Q-in-Q может иметь разные значения по умолчанию. Для того чтобы кадры Q-in-Q могли передаваться по общедоступным сетям через устройства разных производителей, рекомендуется использовать значение TPID внешнего тега равное 0x88A8, согласно стандарту IEEE 802.1ad.

Роли портов в Port-based Q-in-Q и Selective Q-in-Q

Все порты граничного коммутатора, на котором используются функции Port-based Q-in-Q или Selective Q-in-Q, должны быть настроены как порты доступа (UNI) или Uplink-порты (NNI):

UNI (User-to-Network Interface) — эта роль назначается портам, через которые будет осуществляться взаимодействие граничного коммутатора провайдера с клиентскими сетями;
NNI (Network-to-Network Interface) — эта роль назначается портам, которые подключаются к внутренней сети провайдера или другим граничным коммутаторам.

Политики назначения внешнего тега и приоритета в Q-in-Q

Функция Selective Q-in-Q позволяет добавлять в кадры различные внешние теги VLAN , основываясь на значениях внутренних тегов. Для этого на портах UNI граничного коммутатора необходимо задать правила соответствия идентификаторов CVLAN идентификаторам SP- VLAN (vlan translation).

Помимо этого, на коммутаторах D-Link с поддержкой функции Q-in-Q, можно активизировать режим Missdrop. При настройке Selective Q-in-Q, включение этого режима позволит отбрасывать кадры, не подходящие ни под одно из правил соответствия идентификаторов. При настройке Port-based Q-in-Q, режим Missdrop надо отключать, чтобы порт коммутатора мог принимать кадры не подходящие ни под одно из правил vlan translation. В этом случае входящим кадрам будет присваиваться внешний тег равный PVID соответствующего порта UNI .

Значение приоритета внешнего тега по умолчанию равно значению приоритета внутреннего тега, если кадр является маркированным. Если приоритет в полученном кадре отсутствует, то в качестве приоритета вешнего тега будет использоваться приоритет соответствующего входного порта UNI .

Базовая архитектура сети с функцией Port-based Q-in-Q

На рис. 6.19 показана базовая архитектура сети провайдера услуг с функцией Port-based Q-in-Q. Граничные коммутаторы сети провайдера услуг PE-1 и PE-2 позволяют обрабатывать трафик виртуальных локальных сетей двух подключенных к ним клиентских сетей. Каждому клиенту провайдером присвоен уникальный идентификатор VLAN : SP- VLAN 50 для клиента A и SP- VLAN 100 для клиента B. При передаче кадра из клиентской сети в сеть провайдера, в его заголовок будет добавляться второй тег 802.1Q: для сети А - SP- VLAN 50, для сети В - SP- VLAN 100. При передаче кадра из сети провайдера в клиентскую сеть второй тег будет удаляться граничным коммутатором.

Q-in-Q – технология, позволяющая назначать два Vlan-тега Ethernet-фрейму. Активно используется провайдерами для увеличения количества доступных вланов или прозрачного пропускания клиентских тегированных вланов. Принцип работы хорошо виден на схеме:

В Linux настраивается следующим образом:

vconfig add eth0 10
ifconfig eth0.10 up
vconfig add eth0.10 20
ifconfig eth0.10.20 up

В данном случае тег 10 будет соответствовать OuterTag на схеме, а 20 – InnerTag .

Пример настройки коммутаторов D-Link приведу на базе небольшой схемы:

Допустим, маршрутизатор работает под Linux, и мы настроили его аналогично примеру выше. При этом транзитный коммутатор будет пропускать влан с тегом 10 обычным образом, ничего не подозревая про QinQ, агрегационный коммутатор будет заниматься назначением/снятием вторых тегов, а коммутатор доступа, также ничего не подозревая про QinQ будет отдавать агрегационному коммутатору влан с тегом 20. Рассмотрим настройку агрегационного коммутатора подробнее.

Сначала нужно включить QinQ. Это делается командой enable qinq . Учтите, что при этом всем портам будет назначена роль NNI, TPID будет установлен в 88a8, будет автоматически отключен GVRP. Также, перед включением QinQ нужно вручную отключить STP. GVRP и STP можно потом включить вручную, а при перезагрузке коммутатора все будет без проблем подниматься автоматически.

Теперь разберем смысл слов "роль порта", TPID. Роль порта определяет как функция QinQ будет вести себя на этом порту. В коммутаторах D-Link существуют две роли: UNI и NNI. Роль UNI (User Network Interface) назначается обыкновенным портам, откуда приходит нетегированный трафик или портам, откуда приходит трафик с одним тегом. Роль NNI (Network Node Interface) назначается портам, с которых приходит трафик с двойным тегом. Исходящий трафик с порта соответственно должен иметь такую же схему тегирования, как и входящий трафик. TPID – идентификатор протокола тегирования. Его положение в Ethernet-кадре видно на схеме. В нашем случае всегда будет использоваться 8100.

В нашей схеме порту, который связан с транзитным коммутатором, будет назначена роль NNI, а порту, который связан с коммутатором доступа, будет назначена роль UNI. Также для всех портов будет назначен TPID 8100. Делается это следующими командами:

config qinq ports 1 role nni tpid 0x8100
config qinq ports 2 role uni tpid 0x8100

Далее нужно сделать так, чтобы для трафика, приходящего с коммутатора доступа, тегированного одним тегом 20, назначался второй тег 10 и отправлялся далее на транзитный коммутатор. Для этого нужно создать на коммутаторе влан с тегом 10 (20 влан на агрегационном коммутаторе создавать не нужно) и назначить его тегом на 1 и 2 порты, а затем определить правила работы со вторыми тегами при помощи vlan_translation . Синтаксис команды vlan_translation выглядит так:

create vlan_translation ports

ports – указывает порты, на которых нужно модифицировать теги;
cvid – указывает одиночный тег фреймов, приходящих с определенных выше портов, к которым будет применяться правило;
add – указывает на необходимость добавления второго тега к фреймам, подходящим под условия ports и cvid ;
replace – указывает на необходимость замены одиночного тега на другой;
svid – определяет второй тег, который будет добавляться при использовании add , или одиночный тег, который будет подставляться вместо cvid при использовании replace .

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

Если вы используете STP, и кольцо замыкается на 2 и 3 портах, то 3 порт нужно настроить абсолютно также, как и 2. Использование vlan_trunk при этом ненужно, что позволяет изолировать кольца друг от друга и уменьшить проблему коллизий MAC-адресов.

Q-in-Q, так же это называют dot1q tunneling, это система двойного тегирования вланов. То есть, допустим у нас есть канал на некую техплощадку, на которой подключены клиенты, клиенты должны быть изолированы друг от друга с помощью vlan, но транспорт не позволяет обеспечить нужное количество вланов на каждого клиента, а владельцы транспорта дают один влан и как говорится крутись как хочешь. Вот для таких случаев замечательно подходит dot1q тунелирование, когда внутрь одного влана на входе упаковываются вланы, а на выходе транспорта распаковываются. Остается добавить, что не все виды коммутаторов поддерживают Q-in-Q, среди коммутаторов Cisco поддерживают Q-in-Q 35хх, 37xx, 45xx. Среди продуктов D-Link поддерживает Des-3825, тут Q-in-Q называется Double Vlan. И все коммутаторы производства ExtremeNetworks, они называют эту технологию vMan.

Схема коммутации для создания Q-in-Q будет выглядеть так:

На сервере (он является маршрутизатором для клиентов) терминируются все клиентские вланы(11,12, 13, 14, 15), порт GigabitEthernet 1/0/1 Switch 1, находится в режиме транка, и имеет такую конфигурацию:

interface GigabitEthernet1/0/1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 11-15 switchport mode trunk speed nonegotiate no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable !

Порт GigabitEthernet1/0/2 соенденен со Switch 2 порт GigabitEthernet1/0/1, нужно это для того, что бы отдать пакеты в порт который будет заворачивать весь трафик в Q-in-Q и имеет такую конфигурацию:

interface GigabitEthernet1/0/2 switchport trunk encapsulation dot1q switchport trunk allowed vlan 11-15 switchport mode trunk speed nonegotiate no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable !

Порт Switch2 GigabitEthernet1/0/1 находится в режиме Q-in-Q, то есть все приходящие пакеты инкапсулирует во влан 10, и для всех устройств находящихся далее по цепочке виден только один влан, в нашем случае влан 10. А конфигурация порта GigabitEthernet1/0/1 на втором свитче будет такая:

configure terminal interface GigabitEthernet1/0/1 description -== Q-IN-Q ==- switchport access vlan 10 switchport mode dot1q-tunnel switchport nonegotiate no mdix auto no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable

Теперь все приходящее на этот порт будет упаковываться внутрь 10-го влана и соответственно выходить через порт GigabitEthernet1/0/28, его настройки будут такие:

interface GigabitEthernet1/0/28 switchport trunk encapsulation dot1q switchport trunk allowed vlan 10 switchport mode trunk speed nonegotiate no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable !

Далее идет оборудование компании предоставляющей транспорт до нашей техплощадки, на схеме это все оборудование обозначено как некое облако, о содержимом которого мы ничего не знаем, да и знать нам не надо.
На удаленной техплощадке наш влан приходит в порт GigabitEthernet1/0/28 Switch3 с конфигурацией идентичной настроенной на Switch 2 порт GigabitEthernet1/0/28.

Трафик приходит на порт GigabitEthernet1/0/28 Switch3 имеющий двойной тег, то есть Q-in-Qшный, теперь его надо распаковать, соответственно порт GigabitEthernet1/0/1 находится в режиме Q-in-Q. Настройки его такие:

interface GigabitEthernet1/0/1 description -== Q-IN-Q ==- switchport access vlan 10 switchport mode dot1q-tunnel switchport nonegotiate no mdix auto no cdp enable spanning-tree bpdufilter enable spanning-tree bpduguard enable

Остался последний свитч Switch4, в который и включаются все клиенты. Со Switch3 он соенденен через порт GigabitEthernet1/0/1 со своей стороны и в GigabitEthernet1/0/1 на Switch3.
Настройки GigabitEthernet1/0/1 на Switch4 такие:

А настройки клиентских портов будут, для первого клиента во влан 11, порт GigabitEthernet1/0/2:

interface GigabitEthernet1/0/2 description -== FirstClient ==- switchport access vlan 11 switchport mode access

второго, подключенного в GigabitEthernet1/0/3, и ходящего по 12 влану, такие:

interface GigabitEthernet1/0/2 description -== SecondClient ==- switchport access vlan 12 switchport mode access

Ну и так далее, идентично для остальных клиентов.
На этом настройка закончена. Остается только добавить, что схему можно немного упростить физически, построив ее на основе 2 свичей вместо 4-х, для этого необходимо соорудить так называемый Q-in-Q Loop. Об этом я расскажу несколько позднее. И совсем необязательно применять для терминации клиентов равнозначные свитчи, им хватит и свитча попроще, но Q-in-Q прийдется строить все равно на базе как минимум Cisco Catalyst 35xx. Причем функция Q-in-Q в них не документирована, но работает.

> но Q-in-Q прийдется строить все равно на базе
> как минимум Cisco Catalyst 35xx. Причем функция
> Q-in-Q в них не документирована, но работает

By Nickolay, 22.12.2009 @ 10:18

Отличная статья, просто без воды на живом примере — автору респект

У меня под управлением сейчас есть толькл 29XX и 37ХХ, проверить не могу. Поэтому и достоверно ответить не могу. А на предыдущей работе строил на 35-й, только вот на какой модели и с каким IOS не помню.

Читайте также: