- Форум
- /
- IT и телекоммуникации
- /
- Конфигурация сетевого оборудования
- /
- Настройка Q-in-Q VLAN на оборудовании Juniper EX3200 и Cisco Catalyst 3750
Настройка Q-in-Q VLAN на оборудовании Juniper EX3200 и Cisco Catalyst 3750
Rendering Error in layout Widget/Social: Call to a member function exists() on null. Please enable debug mode for more information.
9 года 9 мес. назад - 6 года 7 мес. назад #18
от PNV
Задача: Организовать три общих сети второго уровня для удалённых между собой площадок. Для этого необходимо прокинуть 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)
COM_KUNENA_MESSAGE_CREATED_NEW
Задача: Организовать три общих сети второго уровня для удалённых между собой площадок. Для этого необходимо прокинуть 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:
protocols {
rstp {
interface ge-0/0/2.0 {
disable;
}
}
После отключения 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:
ВНИМАНИЕ: Спойлер!
[ Нажмите, чтобы развернуть ]
[ Нажмите, чтобы скрыть ]
ge-0/0/1 {
mtu 1600;
unit 0 {
description QnQ_Loop;
family ethernet-switching {
port-mode trunk;
vlan {
members [ NET100 NET101 NET102 ];
}
}
}
}
ge-0/0/2 {
mtu 1600;
unit 0 {
description QnQ_Loop;
family ethernet-switching {
port-mode access;
vlan {
members QnQ;
}
}
}
}
ge-0/0/10 {
unit 0 {
description VLAN100;
family ethernet-switching {
port-mode access;
vlan {
members NET100;
}
}
}
}
ge-0/0/11 {
unit 0 {
description VLAN101;
family ethernet-switching {
port-mode access;
vlan {
members NET101;
}
}
}
}
ge-0/0/12 {
unit 0 {
description VLAN102;
family ethernet-switching {
port-mode access;
vlan {
members NET102;
}
}
}
}
ge-0/0/47 {
mtu 1600;
unit 0 {
description QnQ_to_ISP;
family ethernet-switching {
port-mode trunk;
vlan {
members QnQ;
}
}
}
}
protocols {
rstp {
interface ge-0/0/2.0 {
disable;
}
}
ethernet-switching-options {
dot1q-tunneling {
ether-type 0x8100;
}
vlans {
QnQ {
description QnQ;
vlan-id 369;
dot1q-tunneling {
customer-vlans 100-102;
NET100 {
vlan-id 100;
}
NET101 {
vlan-id 101;
}
NET102 {
vlan-id 102;
}
}
Конфигурация Cisco Catalyst 3750:
ВНИМАНИЕ: Спойлер!
[ Нажмите, чтобы развернуть ]
[ Нажмите, чтобы скрыть ]
vlan 100
name NET100
!
vlan 101
name NET101
!
vlan 102
name NET102
!
vlan 369
name QNQ
!
!
interface GigabitEthernet1/0/1
description QnQ_Loop
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 100-102
switchport mode trunk
ip mtu 1600
duplex full
!
!
interface GigabitEthernet1/0/2
description QnQ_Loop
switchport access vlan 369
switchport mode dot1q-tunnel
switchport nonegotiate
no spannng-tree
ip mtu 1600
duplex full
!
!
interface GigabitEthernet1/0/10
description NET100
switchport access vlan 100
switchport mode access
!
!
interface GigabitEthernet1/0/11
description NET101
switchport access vlan 101
switchport mode access
!
!
interface GigabitEthernet1/0/12
description NET102
switchport access vlan 102
switchport mode access
!
!
interface GigabitEthernet1/0/48
description to_ISP
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 369
switchport mode trunk
ip mtu 1600
!
!
Для проверки прохождения IP MTU = 1500, можно запустить ping до удаленной площадки с размером пакета 1500 байт без фрагментации по пути следования (df-bit), например:
(на cisco)
ping 10.10.0.3 size 1500 df-bit
ping 10.10.0.3 size 1500 do-not-fragment
Last edit: 6 года 7 мес. назад by PNV.
Спасибо сказали: mrlexy
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Вы здесь:
-
Главная
-
Форум
-
IT и телекоммуникации
-
Конфигурация сетевого оборудования
- Настройка Q-in-Q VLAN на оборудовании Juniper EX3200 и Cisco Catalyst 3750