Настройка Q-in-Q VLAN на оборудовании Juniper EX3200 и Cisco Catalyst 3750

Задача: Организовать три общих сети второго уровня для удалённых между собой площадок. Для этого необходимо прокинуть VLANs 100,101,102 между двумя территориально-распределёнными площадками. На одной из площадок используется коммутатор Juniper EX3200, на второй - Cisco Catalyst 3750. При этом провайдер предоставляет выделенный канал второго уровня (VLAN 369) на всём протяжении от одной площадки до другой.


Т.к. на каждой из площадок стоит по одному управляемому коммутатору, с поддержкой dot1q-tunneling, то на каждом из коммутаторов необходимо создать так называемую "технологическую Q-in-Q петлю" для возможности двойного упаковывания кадров в VLAN. Т.е.на каждом из коммутаторов тегированные кадры с интерфейса ge-0/0/1 упаковываются в туннельный VLAN369 через интерфейс ge-0/0/2. Далее с интерфейса ge-0/0/48 кадры упакованные в двойной VLAN отправляются на коммутатор провайдера. При создании технологической петли необходимо отключать протокол spanning-tree для интерфейсов задействованных в петле, т.к. при создании петли один из интерфейсов автоматически заблокируется. Это можно увидеть при помощи команды show spanning-tree interface (для juniper):

ge-0/0/2.0 128:560 128:559 32768.50c58da05100 20000 BLK BULK

Из примера видно, что интерфейс в заблокировался после создания петли: BLK

Часть конфига Juniper для отключения spannig-tree на интерфейсе ge-0/0/2:
После отключения spanning-tree, состояние интерфейса можно снова проверить:

ge-0/0/2.0 128:560 128:559 32768.50c58da05100 20000 DIS DIS

Протокол spanning-tree для интерфейса ge-0/0/2 в состоянии DIS (disabled)


Если бы на схеме использовалось по два коммутатора на каждой из площадок, то технологической петли можно избежать, т.к. тегированные кадры (транковый интерфейс) с одного коммутатора можно напрямую направить в интерфейс второго коммутатора с настроенным dot1q-tunneling.

И ещё одна очень важная заметка: т.к. в сети с dot1q-tunneling используется по сути VLAN в VLAN'е, то размер кадров проходящих ч/з второй VLAN (туннельный) увеличивается на 4 байта по сравнению со стандартным кадров 1500 байт (MTU 1500). Поэтому на всём протяжении канала от площадки до площадки необходимо увеличивать размер MTU на транзитных интерфейсах всех промежуточных коммутаторов провайдера минимум до 1504 байт. Это очень важно, т.к. трафик чувствительный к размеру кадров и пакетов может просто "резаться" на 4 байта, что в свою очередь приведёт к неработоспособности приложений. В моём примере размер MTU QnQ-интерфейсов выставлен в 1600 байт.

На моей практике таким чувствительным оказался трафик VmWare ESX между vCenter и гипервизорами (хостами) ESX: гипервизоры удалённой площадки просто отказывались коннектиться к vCenter. Ситуация исправилась увеличением стандартного размера кадра (MTU=1500) транзитных интерфейсов до 1504 байт. Можно конечно наоборот уменьшить размер MTU на интерфейсах самих серверов приложений, но это уже на усмотрение каждого.
Там где используются Jumbo-frames соответственно ничего дополнительно настраивать не нужно.

Ниже приведены конфиги коммутаторов обеих территориально-распределённых площадок:

Конфигурация Juniper EX-3200:




Конфигурация Cisco Catalyst 3750:



Для проверки прохождения IP MTU = 1500, можно запустить ping до удаленной площадки с размером пакета 1500 байт без фрагментации по пути следования (df-bit), например:

(на cisco)(на juniper)