Протокол QinQ в vESR Eltex. Проверка работы.
pdf
Глава 19 vesr-gns3.pdf908.87 Kb
Настройка QinQ в
маршрутизаторе vESR Eltex
Это часть
текста главы 19, которая не вошла в вторую книгу "Руководство для
продвинутых". Почему будет показано ниже по тексту. План работы
предполагал дать вводный параграф что такое этот протокол QinQ. Для чего нужен
и где его лучше всего применить. Далее описание задачи и схема с решением.
текста главы 19, которая не вошла в вторую книгу "Руководство для
продвинутых". Почему будет показано ниже по тексту. План работы
предполагал дать вводный параграф что такое этот протокол QinQ. Для чего нужен
и где его лучше всего применить. Далее описание задачи и схема с решением.
Вводную часть здесь
опустим, поскольку уже сказано, что во вторую книгу (которая состоит из
выше опубликованных глав с 11 по 18-приведена нумерация, включающая первые
десять глав первой книги), этот текст не войдёт и не будет смущать неокрепший
ум неофита. перейдем сразу к схеме.
опустим, поскольку уже сказано, что во вторую книгу (которая состоит из
выше опубликованных глав с 11 по 18-приведена нумерация, включающая первые
десять глав первой книги), этот текст не войдёт и не будет смущать неокрепший
ум неофита. перейдем сразу к схеме.
1.1.
Что такое QinQ
QinQ — это технология, которая позволяет пакетам с
двойным тегом VLAN перемещаться по магистральной сети оператора.
Она стандартизирована в IEEE 802.1ad.
двойным тегом VLAN перемещаться по магистральной сети оператора.
Она стандартизирована в IEEE 802.1ad.
Принцип работы: тег VLAN частной сети
оборачивается в тег VLAN публичной сети. Когда пакеты проходят по сети, они
маршрутизируются в публичной сети на основе внешнего тега VLAN. Внутренний тег
VLAN рассматривается как данные и проходит по публичной сети вместе с ними.
оборачивается в тег VLAN публичной сети. Когда пакеты проходят по сети, они
маршрутизируются в публичной сети на основе внешнего тега VLAN. Внутренний тег
VLAN рассматривается как данные и проходит по публичной сети вместе с ними.
Основная область
применения технологии QinQ — сети передачи данных операторского
класса. Она предназначена для прозрачного пропуска трафика клиентов,
использующих в своих сетях VLAN, через сеть оператора.
применения технологии QinQ — сети передачи данных операторского
класса. Она предназначена для прозрачного пропуска трафика клиентов,
использующих в своих сетях VLAN, через сеть оператора.
Преимуществом применения
технологии QinQ для такой услуги является отсутствие необходимости согласования
тегов VLAN между клиентом и оператором. Это предоставляет клиенту практически
безграничные возможности по расширению своей сети передачи данных.
технологии QinQ для такой услуги является отсутствие необходимости согласования
тегов VLAN между клиентом и оператором. Это предоставляет клиенту практически
безграничные возможности по расширению своей сети передачи данных.
1.2.
Некоторые ограничения протокола QinQ
· Ограничение на количество
идентификаторов VLAN. Поле VID (VLAN Identifier) имеет размер 12 бит, что позволяет
заложить до 4096 VLAN. Однако значения 0 и 4095 (0x000 и 0xFFF)
зарезервированы, поэтому реальное количество VLAN — 4094.
идентификаторов VLAN. Поле VID (VLAN Identifier) имеет размер 12 бит, что позволяет
заложить до 4096 VLAN. Однако значения 0 и 4095 (0x000 и 0xFFF)
зарезервированы, поэтому реальное количество VLAN — 4094.
· Отсутствие полноценного
разделения доменов сетей пользователей и провайдера. QinQ не позволяет решить
эту проблему, а лишь позволяет преодолеть ограничение на количество
идентификаторов VLAN в сети.
разделения доменов сетей пользователей и провайдера. QinQ не позволяет решить
эту проблему, а лишь позволяет преодолеть ограничение на количество
идентификаторов VLAN в сети.
· Ограничение контроля над
MAC-адресами. Контролировать MAC-адреса с помощью только технологии QinQ
невозможно, так как коммутация кадров Ethernet в домене сети провайдера
основана на MAC-адресах из клиентской сети.
MAC-адресами. Контролировать MAC-адреса с помощью только технологии QinQ
невозможно, так как коммутация кадров Ethernet в домене сети провайдера
основана на MAC-адресах из клиентской сети.
· Необходимость увеличения L2
MTU на коммутаторе. К кадрам добавляется дополнительный заголовок 802.1q, поэтому
требуется увеличить L2 MTU как минимум на 4 байта.
MTU на коммутаторе. К кадрам добавляется дополнительный заголовок 802.1q, поэтому
требуется увеличить L2 MTU как минимум на 4 байта.
· Ограничения на некоторых
моделях коммутаторов. Например, на коммутаторе SNR-S2960-24G существует аппаратное
ограничение на нумерацию используемых тегируемых VLAN: можно использовать
только VLAN с номерами 1–127. На моделях серий S2962, S2965, S2982G, S2985G
отсутствует возможность добавить внешний тег QinQ на одном интерфейсе и снять
на другом.
моделях коммутаторов. Например, на коммутаторе SNR-S2960-24G существует аппаратное
ограничение на нумерацию используемых тегируемых VLAN: можно использовать
только VLAN с номерами 1–127. На моделях серий S2962, S2965, S2982G, S2985G
отсутствует возможность добавить внешний тег QinQ на одном интерфейсе и снять
на другом.
1.3.
Задача
Задача сделать общий
домен L2 для клиентов двух филиалов с vlan 10, vlan20 на каждой из сторон как
показано на схеме Рисунок 19-1.
Клиентами выступают РС и Линукс. Клиенты подключены к коммутатору доступа в
каждом из филиалов. На коммутаторах настроены access 10, access 20 в сторону
клиентов и транк на коммутатор доступа.
домен L2 для клиентов двух филиалов с vlan 10, vlan20 на каждой из сторон как
показано на схеме Рисунок 19-1.
Клиентами выступают РС и Линукс. Клиенты подключены к коммутатору доступа в
каждом из филиалов. На коммутаторах настроены access 10, access 20 в сторону
клиентов и транк на коммутатор доступа.
Рисунок 19-1. Схема проверки работы протокола QinQ
1.4.
Решение
На вход интерфейса gigabitethernet
1/0/2 маршрутизатора СЕ ( vesr Eltex c ОС v.1.24.1 на борту) пакеты от клиентов
локальной сети должны приходить уже с двумя полями: S-tag и C-tag.В этом и
состоит суть протокола QinQ - сделать паровозик, который провезет клиентские
VLAN через магистральные сети оператора связи. Для этого и нужны два этих
встроенных в GNS3 свитча. Один приклеит метку VLAN локальной сети, а другой
метку магистрали. На скринах экранов Рисункок 19-2 и 19-3 есть настройки
встроенных свитчей и показаны детали конфигурации портов.
1/0/2 маршрутизатора СЕ ( vesr Eltex c ОС v.1.24.1 на борту) пакеты от клиентов
локальной сети должны приходить уже с двумя полями: S-tag и C-tag.В этом и
состоит суть протокола QinQ - сделать паровозик, который провезет клиентские
VLAN через магистральные сети оператора связи. Для этого и нужны два этих
встроенных в GNS3 свитча. Один приклеит метку VLAN локальной сети, а другой
метку магистрали. На скринах экранов Рисункок 19-2 и 19-3 есть настройки
встроенных свитчей и показаны детали конфигурации портов.
Рисунок 19-2. Параметры настройки коммутатора доступа.
Рисунок 19-3. Параметры настройки коммутатора распределения.
Настройка самих маршрутизаторов стандартна-на интерфейсы IP адрес
не назначаются и отключен межсетевой экран. Необходимо увеличить размер фрейма
и MTU на
интерфейсах. Создается виртуальный коммутатор bridge 1 и VLAN 100. Это VLAN s-tag для сети оператора:
не назначаются и отключен межсетевой экран. Необходимо увеличить размер фрейма
и MTU на
интерфейсах. Создается виртуальный коммутатор bridge 1 и VLAN 100. Это VLAN s-tag для сети оператора:
bridge 1
vlan 100
mac-address
a2:00:00:00:0c:e2
a2:00:00:00:0c:e2
ip firewall
disable
disable
ip address
172.16.10.1/24
172.16.10.1/24
no
spanning-tree
spanning-tree
enable
exit
Адрес коммутатора устанавливается из диапазона адресов,
выдаваемых сервером DHCP:
выдаваемых сервером DHCP:
ip dhcp-server
ip dhcp-server pool LAN_VLAN10
network
172.16.10.0/24
172.16.10.0/24
default-lease-time 003:00:00
address-range 172.16.10.3-172.16.10.254
default-router
172.16.10.1
172.16.10.1
dns-server
77.88.8.8
77.88.8.8
exit
Сервер DHCP будет выдавать адреса как клиентам в локальной сети своего
филиала, так и клиентам локальной сети второго филиала, с которым установлена
связь через выделенную линию оператора и подключенную к субинтерфейсу Gigabitethernet 1/0/1.100:
филиала, так и клиентам локальной сети второго филиала, с которым установлена
связь через выделенную линию оператора и подключенную к субинтерфейсу Gigabitethernet 1/0/1.100:
interface gigabitethernet 1/0/1
description
"UPlink-to-PE1"
"UPlink-to-PE1"
spanning-tree disable
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/1.100
bridge-group 1
ip firewall
disable
disable
exit
Остановимся
немного подробнее на этом моменте. Привязку интерфейса Gigabitethernet к
bridge-group 1 применена для объединения нескольких физических интерфейсов в
один виртуальный интерфейс (bridge). Это позволяет:
немного подробнее на этом моменте. Привязку интерфейса Gigabitethernet к
bridge-group 1 применена для объединения нескольких физических интерфейсов в
один виртуальный интерфейс (bridge). Это позволяет:
Прозрачно
пересылать кадры Ethernet между разными интерфейсами в
пределах одной группы.
пересылать кадры Ethernet между разными интерфейсами в
пределах одной группы.
Объединить
широковещательные домены разных VLAN в одну подсеть на
уровне L2.
широковещательные домены разных VLAN в одну подсеть на
уровне L2.
Использовать
bridge как шлюз для подсети, подключённой к интерфейсам, и
маршрутизировать трафик далее.
bridge как шлюз для подсети, подключённой к интерфейсам, и
маршрутизировать трафик далее.
Некоторые особенности
работы:
работы:
Фильтрация
по VLAN — если в bridge добавлен хотя бы один
интерфейс в режиме switchport с сохранением тега (bridge-group x tagged), то на
всём bridge активируется режим фильтрации по VLAN. Трафик без VLAN-тега
сбрасывается.
по VLAN — если в bridge добавлен хотя бы один
интерфейс в режиме switchport с сохранением тега (bridge-group x tagged), то на
всём bridge активируется режим фильтрации по VLAN. Трафик без VLAN-тега
сбрасывается.
Снятие
VLAN-тега — при поступлении трафика из интерфейса в bridge
VLAN-тег снимается.
VLAN-тега — при поступлении трафика из интерфейса в bridge
VLAN-тег снимается.
Обратим внимание, что интерфейсы в данном случае в состоянии
router
port, а не switchport. Это будет важно
при анализе проблем в работе устройства.
router
port, а не switchport. Это будет важно
при анализе проблем в работе устройства.
Далее стандартно, в соответствие с документацией на
устройство настраиваются интерфейсы для работы с протоколом QinQ:
устройство настраиваются интерфейсы для работы с протоколом QinQ:
interface gigabitethernet 1/0/2
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2.100
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2.100.10
bridge-group 1
ip firewall
disable
disable
spanning-tree disable
exit
interface gigabitethernet 1/0/2.100.20
shutdown
bridge-group 2
ip firewall
disable
disable
spanning-tree disable
exit
Обратите внимание, что интерфейс gigabitethernet
1/0/2.100.20
1/0/2.100.20
отключен.
Это сделано для точного соответствия примеру настройки из
официальной документации Eltex.
Иными словами, в работе сейчас только один внутренний VLAN, соответствующий C-tag 10.
официальной документации Eltex.
Иными словами, в работе сейчас только один внутренний VLAN, соответствующий C-tag 10.
1.5.
Проверка
Для проверки работы L2 домена на виртуальных ПК в локальных сетях обоих филиалов
нужно ввести в консоли команду ip dhcp:
нужно ввести в консоли команду ip dhcp:
PC6> ip dhcp
DDORA IP 172.16.10.5/24 GW 172.16.10.1
PC6> sh ip
NAME :
PC6[1]
PC6[1]
IP/MASK :
172.16.10.5/24
172.16.10.5/24
GATEWAY :
172.16.10.1
172.16.10.1
DNS :
77.88.8.8
77.88.8.8
DHCP SERVER : 172.16.10.1
DHCP LEASE :
85840, 86400/43200/75600
85840, 86400/43200/75600
MAC :
00:50:79:66:68:04
00:50:79:66:68:04
LPORT :
10028
10028
RHOST:PORT :
127.0.0.1:10029
127.0.0.1:10029
MTU: :
1500
1500
PC6>
Это результат, полученный в локальной сети, внешней по
отношению к серверу DHCP.
Адрес получен, L2 домен
работает и бродкаст запросы проходят.
отношению к серверу DHCP.
Адрес получен, L2 домен
работает и бродкаст запросы проходят.
Проверяем прохождение пакетов по маршруту:
ce5# monitor gigabitethernet 1/0/2.100.10
09:00:36.214903 00:50:79:66:68:04 >
ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 406: (tos 0x10, ttl 16, id
0, offset 0, flags [none], proto UDP (17), length 392)
ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 406: (tos 0x10, ttl 16, id
0, offset 0, flags [none], proto UDP (17), length 392)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:50:79:66:68:04, length 364, xid 0xa9ff885d, Flags [none]
Client-Ethernet-Address 00:50:79:66:68:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 4: "PC61"
Client-ID Option 61, length 7: ether 00:50:79:66:68:04
09:00:36.226506 a2:00:00:00:0c:e4 >
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id
39179, offset 0, flags [DF], proto ICMP (1), length 48)
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id
39179, offset 0, flags [DF], proto ICMP (1), length 48)
172.16.10.1 > 172.16.10.5: ICMP echo request, id 6216, seq 0, length
28
09:00:36.227013 00:50:79:66:68:04 >
a2:00:00:00:0c:e4, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id
39179, offset 0, flags [DF], proto ICMP (1), length 48)
a2:00:00:00:0c:e4, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id
39179, offset 0, flags [DF], proto ICMP (1), length 48)
172.16.10.5 > 172.16.10.1: ICMP echo reply, id 6216, seq 0, length 28
09:00:37.227923 00:50:79:66:68:04 > ff:ff:ff:ff:ff:ff,
ethertype IPv4 (0x0800), length 406: (tos 0x10, ttl 16, id 0, offset 0, flags
[none], proto UDP (17), length 392)
ethertype IPv4 (0x0800), length 406: (tos 0x10, ttl 16, id 0, offset 0, flags
[none], proto UDP (17), length 392)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:50:79:66:68:04, length 364, xid 0xa9ff885d, Flags [none]
Client-Ethernet-Address
00:50:79:66:68:04
00:50:79:66:68:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 4: "PC61"
Client-ID Option 61, length 7: ether 00:50:79:66:68:04
09:00:37.242189 a2:00:00:00:0c:e4 >
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 tell 172.16.10.1, length 46
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 tell 172.16.10.1, length 46
09:00:38.239403 a2:00:00:00:0c:e4 >
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 tell 172.16.10.1, length 46
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 tell 172.16.10.1, length 46
09:00:38.247024 a2:00:00:00:0c:e4 >
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id
32709, offset 0, flags [DF], proto ICMP (1), length 48)
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id
32709, offset 0, flags [DF], proto ICMP (1), length 48)
172.16.10.1 > 172.16.10.6: ICMP echo request, id 22601, seq 0, length
28
09:00:38.250080 a2:00:00:00:0c:e4 >
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id
1017, offset 0, flags [DF], proto UDP (17), length 328)
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id
1017, offset 0, flags [DF], proto UDP (17), length 328)
172.16.10.1.67 > 172.16.10.6.68: BOOTP/DHCP, Reply, length 300, xid
0xa9ff885d, Flags [none]
Your-IP 172.16.10.6
Client-Ethernet-Address 00:50:79:66:68:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.10.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4:
172.16.10.1
172.16.10.1
Domain-Name-Server Option 6, length 4: 77.88.8.8
09:00:40.226804 00:50:79:66:68:04 >
a2:00:00:00:0c:e4, ethertype IPv4 (0x0800), length 406: (tos 0x10, ttl 16, id
0, offset 0, flags [none], proto UDP (17), length 392)
a2:00:00:00:0c:e4, ethertype IPv4 (0x0800), length 406: (tos 0x10, ttl 16, id
0, offset 0, flags [none], proto UDP (17), length 392)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:50:79:66:68:04, length 364, xid 0xa9ff885d, Flags [none]
Client-IP 172.16.10.6
Client-Ethernet-Address 00:50:79:66:68:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Server-ID Option 54, length 4: 172.16.10.1
Requested-IP Option 50, length 4: 172.16.10.6
Client-ID Option 61, length 7: ether 00:50:79:66:68:04
Hostname Option 12, length 4: "PC61"
Parameter-Request Option 55, length 4:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
09:00:40.238285 a2:00:00:00:0c:e4 >
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id
2006, offset 0, flags [DF], proto UDP (17), length 328)
00:50:79:66:68:04, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id
2006, offset 0, flags [DF], proto UDP (17), length 328)
172.16.10.1.67 > 172.16.10.6.68: BOOTP/DHCP, Reply, length 300, xid
0xa9ff885d, Flags [none]
Client-IP 172.16.10.6
Your-IP 172.16.10.6
Client-Ethernet-Address 00:50:79:66:68:04
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message
Option 53, length 1: ACK
Option 53, length 1: ACK
Server-ID
Option 54, length 4: 172.16.10.1
Option 54, length 4: 172.16.10.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.10.1
Domain-Name-Server Option 6, length 4: 77.88.8.8
09:00:41.224796 a2:00:00:00:0c:e4 >
00:50:79:66:68:04, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.5 tell 172.16.10.1, length 46
00:50:79:66:68:04, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.5 tell 172.16.10.1, length 46
09:00:41.232556 00:50:79:66:68:04 >
a2:00:00:00:0c:e4, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Reply 172.16.10.5 is-at 00:50:79:66:68:04, length 46
a2:00:00:00:0c:e4, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4
(len 4), Reply 172.16.10.5 is-at 00:50:79:66:68:04, length 46
09:00:41.235250 00:50:79:66:68:04 >
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 (ff:ff:ff:ff:ff:ff) tell 172.16.10.6,
length 50
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 (ff:ff:ff:ff:ff:ff) tell 172.16.10.6,
length 50
09:00:42.245793 00:50:79:66:68:04 >
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 (ff:ff:ff:ff:ff:ff) tell 172.16.10.6,
length 50
ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4
(len 4), Request who-has 172.16.10.6 (ff:ff:ff:ff:ff:ff) tell 172.16.10.6,
length 50
09:00:43.254472 00:50:79:66:68:04 > ff:ff:ff:ff:ff:ff,
ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request
who-has 172.16.10.6 (ff:ff:ff:ff:ff:ff) tell 172.16.10.6, length 50
ethertype ARP (0x0806), length 64: Ethernet (len 6), IPv4 (len 4), Request
who-has 172.16.10.6 (ff:ff:ff:ff:ff:ff) tell 172.16.10.6, length 50
К сожалению, встроенный монитор не дает нужной глубины и не
показывает протокол QinQ.
Хорошо виден только протокол работы DHCP. Он дает подтверждение прохождения бродкаст запросов, но нам
нужны S-tag и C-tag еще. Поэтому с помощью встроенного в GNS3 Wireshark включаем
захват пакетов на входе CT5
и на его выходном интерфейсах Gigabitethernet
1/0/2.100.10 и Gigabitethernet
1/0/1 соответственно:
показывает протокол QinQ.
Хорошо виден только протокол работы DHCP. Он дает подтверждение прохождения бродкаст запросов, но нам
нужны S-tag и C-tag еще. Поэтому с помощью встроенного в GNS3 Wireshark включаем
захват пакетов на входе CT5
и на его выходном интерфейсах Gigabitethernet
1/0/2.100.10 и Gigabitethernet
1/0/1 соответственно:
Рисунок 19-4. Дамп захвата пакетов на входе в маршрутизатор СЕ5 из
локальной сети.
локальной сети.
Рисунок 19-5. Дамп захвата пакетов на выходе из маршрутизатора СЕ5 в
сеть оператора.
сеть оператора.
На Рисунках 19-4 и 19-5 красными стрелками показаны важные
элементы на рисунке. Тип пакета, МАС адрес и отсутствие второго тэга в VLAN 10 в выходном потоке.
элементы на рисунке. Тип пакета, МАС адрес и отсутствие второго тэга в VLAN 10 в выходном потоке.
Соответственно наблюдается нормальная связность локальных
сетей друг с другом.
сетей друг с другом.
PC6> ping 172.16.10.3 -c 3
84 bytes from 172.16.10.3 icmp_seq=1 ttl=64
time=5.423 ms
time=5.423 ms
84 bytes from 172.16.10.3 icmp_seq=2 ttl=64
time=7.256 ms
time=7.256 ms
84 bytes from 172.16.10.3 icmp_seq=3 ttl=64
time=8.696 ms
time=8.696 ms
PC6>
Включаем интерфейс с второй VLAN 20 и перегружаем роутеры для чистой
проверки:
проверки:
ce5# config
ce5(config)# interface gigabitethernet 1/0/2.100.20
ce5(config-if-qinq)# no shutdown
ce5(config-if-qinq)# exit
ce5(config)# exit
ce5# commit
ce5# confirm
ce5# reload system
Do you really want to reload system now? (y/N): y
2025-11-02T09:39:17+00:00 %CLI-I-CRIT: user admin
from console input: reload system
from console input: reload system
2025-11-02T09:39:17+00:00 %SYS-C-REBOOT: CLI:
System reboot initiated by user admin from console at 2025-11-02 09:39:17
System reboot initiated by user admin from console at 2025-11-02 09:39:17
ce5#
ce4# config
ce4(config)# interface gigabitethernet 1/0/2.100.20
ce4(config-if-qinq)# no shutdown
ce4(config-if-qinq)# exit
ce4(config)# exit
ce4# commit
ce4# confirm
ce4# reload system
Do you really want to reload system now? (y/N): y
2025-11-02T09:39:17+00:00 %CLI-I-CRIT: user admin
from console input: reload system
from console input: reload system
2025-11-02T09:39:17+00:00 %SYS-C-REBOOT: CLI:
System reboot initiated by user admin from console at 2025-11-02 09:39:17
System reboot initiated by user admin from console at 2025-11-02 09:39:17
ce4#
Проверяем работу бродкаст запросов по протоколу DHCP в
первом филиале:
первом филиале:
PC4> ip dhcp
DDD
Can't find dhcp server
PC4>
Во втором филиале:
PC6> ip dhcp
DDD
Can't find dhcp server
PC6>
Адреса не получены, работа протокола DHCP не
завершена.
завершена.
При этом видно, что виртуальные коммутаторы обучаются
нормально и в таблице есть МАС адреса клиентов, полученные как локально с
внутреннего интерфейса , так и с внешнего от удаленной сети:
нормально и в таблице есть МАС адреса клиентов, полученные как локально с
внутреннего интерфейса , так и с внешнего от удаленной сети:
ce4# sh mac address-table bridge 1
VID MAC
Address Interface Type
Address Interface Type
-----
------------------
------------------------------
-------
------------------
------------------------------
-------
--
0c:c5:3e:7f:00:00
gigabitethernet 1/0/1.100
Dynamic
0c:c5:3e:7f:00:00
gigabitethernet 1/0/1.100
Dynamic
--
00:50:79:66:68:03
gigabitethernet 1/0/1.100
Dynamic
00:50:79:66:68:03
gigabitethernet 1/0/1.100
Dynamic
--
00:50:79:66:68:04
gigabitethernet 1/0/1.100
Dynamic
00:50:79:66:68:04
gigabitethernet 1/0/1.100
Dynamic
--
0c:e5:9f:2d:00:00
gigabitethernet 1/0/2.100.10
Dynamic
0c:e5:9f:2d:00:00
gigabitethernet 1/0/2.100.10
Dynamic
-- 00:50:79:66:68:05 gigabitethernet 1/0/2.100.20 Dynamic
5 valid mac entries
ce4#
ce5# sh mac address-table bridge 1
VID MAC
Address Interface Type
Address Interface Type
-----
------------------
------------------------------
-------
------------------
------------------------------
-------
--
0c:e5:9f:2d:00:00
gigabitethernet 1/0/1.100
Dynamic
0c:e5:9f:2d:00:00
gigabitethernet 1/0/1.100
Dynamic
--
a2:00:00:00:0c:e4
gigabitethernet 1/0/1.100
Dynamic
a2:00:00:00:0c:e4
gigabitethernet 1/0/1.100
Dynamic
--
0c:c5:3e:7f:00:00
gigabitethernet 1/0/2.100.10
Dynamic
0c:c5:3e:7f:00:00
gigabitethernet 1/0/2.100.10
Dynamic
--
00:50:79:66:68:04 gigabitethernet
1/0/2.100.10 Dynamic
00:50:79:66:68:04 gigabitethernet
1/0/2.100.10 Dynamic
--
00:50:79:66:68:03
gigabitethernet 1/0/2.100.20
Dynamic
00:50:79:66:68:03
gigabitethernet 1/0/2.100.20
Dynamic
5 valid mac entries
ce5#
Из вывода дампа видно, что бродкаст пакеты по домену ходят:
ce4# mon gigabitethernet 1/0/1
09:58:40.089205 0c:e5:9f:2d:00:00 > ff:ff:ff:ff:ff:ff,
ethertype 802.1Q (0x8100), length 346: vlan 100, p 0, ethertype IPv4, (tos 0x0,
ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
ethertype 802.1Q (0x8100), length 346: vlan 100, p 0, ethertype IPv4, (tos 0x0,
ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
0c:e5:9f:2d:00:00, length 300, xid 0x6c416f52, secs 725, Flags [none]
Client-Ethernet-Address 0c:e5:9f:2d:00:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 0c:e5:9f:2d:00:00
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 7:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP
Vendor-Class Option 60, length 12: "udhcp 1.23.1"
Hostname Option 12, length 3: "box"
09:58:40.123531 0c:c5:3e:7f:00:00 >
ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 335: vlan 100, p 0,
ethertype IPv4, (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP
(17), length 317)
ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 335: vlan 100, p 0,
ethertype IPv4, (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP
(17), length 317)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
0c:c5:3e:7f:00:00, length 289, xid 0xbc2ccb39, secs 701, Flags [none]
Client-Ethernet-Address 0c:c5:3e:7f:00:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255,
40:56:63:a2:00:02:00:00:ab:11:63:dd:34:ff:0f:33:be:3b
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, MTU, Static-Route, NTP
Option 120, Classless-Static-Route
MSZ Option 57, length 2: 1472
Hostname Option 12, length 6: "debian"
09:58:40.124164 a2:00:00:00:0c:e4 >
ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0,
ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.10.4 tell
172.16.10.1, length 28
ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0,
ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.10.4 tell
172.16.10.1, length 28
09:58:41.125711 a2:00:00:00:0c:e4 >
ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0,
ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.10.4 tell
172.16.10.1, length 28
ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0,
ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.10.4 tell
172.16.10.1, length 28
09:58:41.136686 a2:00:00:00:0c:e4 >
0c:c5:3e:7f:00:00, ethertype 802.1Q (0x8100), length 66: vlan 100, p 0,
ethertype IPv4, (tos 0x0, ttl 64, id 62636, offset 0, flags [DF], proto ICMP
(1), length 48)
0c:c5:3e:7f:00:00, ethertype 802.1Q (0x8100), length 66: vlan 100, p 0,
ethertype IPv4, (tos 0x0, ttl 64, id 62636, offset 0, flags [DF], proto ICMP
(1), length 48)
172.16.10.1 > 172.16.10.4: ICMP echo request, id 55366, seq 0, length
28
09:58:41.137308 a2:00:00:00:0c:e4 >
0c:c5:3e:7f:00:00, ethertype 802.1Q (0x8100), length 346: vlan 100, p 0,
ethertype IPv4, (tos 0x0, ttl 64, id 43182, offset 0, flags [DF], proto UDP
(17), length 328)
0c:c5:3e:7f:00:00, ethertype 802.1Q (0x8100), length 346: vlan 100, p 0,
ethertype IPv4, (tos 0x0, ttl 64, id 43182, offset 0, flags [DF], proto UDP
(17), length 328)
172.16.10.1.67 > 172.16.10.4.68: BOOTP/DHCP, Reply, length 300, xid
0xbc2ccb39, secs 701, Flags [none]
Your-IP 172.16.10.4
Client-Ethernet-Address 0c:c5:3e:7f:00:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.10.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.10.1
Domain-Name-Server Option 6, length 4: 77.88.8.8
Еще раз делаем захват пакетов с помощью встроенной утилиты Wireshark на входе и выходе
из интерфейсов как показано на рисунках 19-6 и 19-7. Тэги VLAN присутствуют
в пакетах. Но фильтрации по VLAN на коммутаторе нет и пакеты Offer уничтожаются
и не доходят до адресата.
из интерфейсов как показано на рисунках 19-6 и 19-7. Тэги VLAN присутствуют
в пакетах. Но фильтрации по VLAN на коммутаторе нет и пакеты Offer уничтожаются
и не доходят до адресата.
Рисунок 19-6. Дамп пакетов на входе
интерфейса локальной сети на СЕ5.
интерфейса локальной сети на СЕ5.
Рисунок 29-7. Дамп пакетов на выходе
интерфейса в сети оператора на СЕ5.
интерфейса в сети оператора на СЕ5.
К сожалению, получить такой же подробный и детальный дамп
пакетов с интерфейса виртуального коммутатора не представляется
возможным-команда monitor из набора команд CLI маршрутизатора даже с опцией detail не
дает полной картины.
пакетов с интерфейса виртуального коммутатора не представляется
возможным-команда monitor из набора команд CLI маршрутизатора даже с опцией detail не
дает полной картины.
Результат проверки работы протокола QinQ на
маршрутизаторе vESR
отрицательный.
маршрутизаторе vESR
отрицательный.
1.6.
Выводы
На основании проведенной лабораторной работы по проверке
возможности использования протокола QinQ на виртуальном маршрутизаторе Eltex vESR с
версией ОС 1.24.1 можно сделать вывод, что протокол не работоспособен. Причиной
является скорее всего требования режима switchport для интерфейсов, входящих в
виртуальный коммутатор bridge
1. Но согласно требованиям документации к маршрутизатору создание субинтерфейсу
для QinQ несовместимо с режимом switchport.
возможности использования протокола QinQ на виртуальном маршрутизаторе Eltex vESR с
версией ОС 1.24.1 можно сделать вывод, что протокол не работоспособен. Причиной
является скорее всего требования режима switchport для интерфейсов, входящих в
виртуальный коммутатор bridge
1. Но согласно требованиям документации к маршрутизатору создание субинтерфейсу
для QinQ несовместимо с режимом switchport.
Технические аспекты проблемы:
Архитектурное противоречие: vESR требует
режим routerport для QinQ субинтерфейсов, но при этом bridge-group функциональность
ожидает режим switchport для корректной фильтрации VLAN
режим routerport для QinQ субинтерфейсов, но при этом bridge-group функциональность
ожидает режим switchport для корректной фильтрации VLAN
Ограничение демультиплексирования: При активации второго
C-VLAN (20) нарушается механизм распределения пакетов между субинтерфейсами,
что указывает на проблему в таблице VLAN-фильтрации bridge
C-VLAN (20) нарушается механизм распределения пакетов между субинтерфейсами,
что указывает на проблему в таблице VLAN-фильтрации bridge
Селективная работоспособность: Протокол работает с
одним C-VLAN, но fails при добавлении второго, что характерно для ограничений в
реализации bridge learning mechanism
одним C-VLAN, но fails при добавлении второго, что характерно для ограничений в
реализации bridge learning mechanism
Методологические выводы:
Важность поэтапного тестирования: Лабораторная работа
демонстрирует критическую важность incremental testing сложных сетевых
конфигураций
демонстрирует критическую важность incremental testing сложных сетевых
конфигураций
Ценность cross-vendor проверки: Проблема была
выявлена благодаря сравнению с эталонной реализацией QinQ в Linux, что
подчеркивает важность мультивендорного подхода
выявлена благодаря сравнению с эталонной реализацией QinQ в Linux, что
подчеркивает важность мультивендорного подхода
Диагностика как навык: Работа показывает, что современному
инженеру необходимы навыки глубокой диагностики, выходящие за рамки стандартных
CLI команд
инженеру необходимы навыки глубокой диагностики, выходящие за рамки стандартных
CLI команд
Практические рекомендации:
Обходные решения: для подобных сценариев можно рассмотреть:
Разделение
на отдельные bridge-домены
на отдельные bridge-домены
Использование
физических интерфейсов вместо QinQ
физических интерфейсов вместо QinQ
Альтернативные
технологии (VXLAN, MPLS)
технологии (VXLAN, MPLS)
Критерии выбора оборудования: при проектировании
сетей с QinQ необходимо заранее тестировать multi-VLAN сценарии на целевом
оборудовании
сетей с QinQ необходимо заранее тестировать multi-VLAN сценарии на целевом
оборудовании
Зрелость реализации: Проблема характерна для edge-case
сценариев в проприетарных реализациях, где редко тестируются сложные
multi-tenancy конфигурации
сценариев в проприетарных реализациях, где редко тестируются сложные
multi-tenancy конфигурации
Эволюция технологий: Случай демонстрирует, что даже
стандартизированные протоколы могут иметь vendor-specific ограничения, что
требует тщательной валидации в конкретной среде
стандартизированные протоколы могут иметь vendor-specific ограничения, что
требует тщательной валидации в конкретной среде
Эта
глава ценна не только как описание конкретной проблемы, но и как методология
исследования сложных сетевых сценариев. Она показывает, что настоящая
экспертиза заключается не только в знании "как должно работать", но и
в умении диагностировать "почему не работает".
глава ценна не только как описание конкретной проблемы, но и как методология
исследования сложных сетевых сценариев. Она показывает, что настоящая
экспертиза заключается не только в знании "как должно работать", но и
в умении диагностировать "почему не работает".
1.7.
Коды конфигурации маршрутизаторов
Маршрутизатор в левой части схемы СЕ4
hostname ce4
syslog max-files 3
syslog file-size 512
syslog file tmpsys:syslog/default
severity
info
info
exit
syslog console
virtual-serial
exit
username admin
password
encrypted
$6$wo3HRAS4r3I9kFMn$U66TheH0rhaCXZ/tvZsb0zVVT/XM7zhxUSkENue7JV8oFX4n8SakchEwUXgbid/sqXAROmMQL3/lpn54i6rMM1
encrypted
$6$wo3HRAS4r3I9kFMn$U66TheH0rhaCXZ/tvZsb0zVVT/XM7zhxUSkENue7JV8oFX4n8SakchEwUXgbid/sqXAROmMQL3/lpn54i6rMM1
exit
system jumbo-frames
vlan 10
force-up
exit
vlan 20
force-up
exit
vlan 30
force-up
exit
vlan 100
force-up
exit
domain lookup enable
bridge 1
vlan 100
mtu 9600
mac-address
a2:00:00:00:0c:e4
a2:00:00:00:0c:e4
ip firewall
disable
disable
ip address
172.16.10.1/24
172.16.10.1/24
ip address
172.16.20.1/24 secondary
172.16.20.1/24 secondary
no
spanning-tree
spanning-tree
enable
exit
interface gigabitethernet 1/0/1
description
"UPlink-to-CE5"
"UPlink-to-CE5"
mtu 9600
spanning-tree disable
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/1.100
bridge-group 1
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2
mtu 9600
spanning-tree disable
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2.100
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2.100.10
bridge-group 1
ip firewall
disable
disable
spanning-tree disable
exit
interface gigabitethernet 1/0/2.100.20
shutdown
bridge-group 1
ip firewall
disable
disable
spanning-tree disable
exit
Маршрутизатор в правой части схемы СЕ5
hostname ce5
syslog max-files 3
syslog file-size 512
syslog file tmpsys:syslog/default
severity
info
info
exit
syslog console
virtual-serial
exit
username admin
password
encrypted
$6$wo3HRAS4r3I9kFMn$U66TheH0rhaCXZ/tvZsb0zVVT/XM7zhxUSkENue7JV8oFX4n8SakchEwUXgbid/sqXAROmMQL3/lpn54i6rMM1
encrypted
$6$wo3HRAS4r3I9kFMn$U66TheH0rhaCXZ/tvZsb0zVVT/XM7zhxUSkENue7JV8oFX4n8SakchEwUXgbid/sqXAROmMQL3/lpn54i6rMM1
exit
system jumbo-frames
vlan 10
force-up
exit
vlan 20
force-up
exit
vlan 30
force-up
exit
vlan 100
force-up
exit
domain lookup enable
bridge 1
vlan 100
mtu 9600
mac-address
a2:00:00:00:0c:e5
a2:00:00:00:0c:e5
ip firewall
disable
disable
ip address
172.16.10.254/24
172.16.10.254/24
no
spanning-tree
spanning-tree
enable
exit
interface gigabitethernet 1/0/1
description
"UPlink-to-CE4"
"UPlink-to-CE4"
mtu 9600
spanning-tree
disable
disable
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/1.100
bridge-group 1
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2
mtu 9600
spanning-tree disable
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2.100
ip firewall
disable
disable
exit
interface gigabitethernet 1/0/2.100.10
bridge-group 1
ip firewall
disable
disable
spanning-tree disable
exit
interface gigabitethernet 1/0/2.100.20
shutdown
bridge-group 1
ip firewall
disable
disable
spanning-tree disable
exit
security passwords default-expired
ip ssh server
ntp enable
ntp broadcast-client enable
licence-manager
host
address elm.eltex-co.ru
address elm.eltex-co.ru
exit