Небольшой текст из главы 18.
· Проверка
и диагностика сервиса L2VPN Martini mode
Убедимся в установлении соседства по протоколу LDP и
выведем информацию по статусу виртуального канала (pseudowire) между PE1 и PE2:
выведем информацию по статусу виртуального канала (pseudowire) между PE1 и PE2:
PE2# sh mpls ldp neighbor
Peer LDP ID: 1.1.1.1; Local LDP ID 2.2.2.2
State: Operational
TCP
connection: 1.1.1.1:646 -
2.2.2.2:57411
connection: 1.1.1.1:646 -
2.2.2.2:57411
Messages sent/received: 10/10
Uptime
(d,h:m:s): 00,00:03:36
(d,h:m:s): 00,00:03:36
LDP
discovery sources:
discovery sources:
gigabitethernet 1/0/1
2.2.2.2 -> 1.1.1.1
PE2#
Состояние соседства установлено. Выделено красным.
PE2# show mpls l2vpn pseudowire
Neighbor PW ID Sig Type Status
---------------------------------------
---------- --- ---------- ------
---------- --- ---------- ------
1.1.1.1 100 LDP Ethernet Up
PE2#
Соседство по протоколу LDP установлено, pseudowire
перешел в статус 'UP' ( выделено зеленым). Настройка l2vpn типа p2p завершена.
перешел в статус 'UP' ( выделено зеленым). Настройка l2vpn типа p2p завершена.
Проверяем работу нашего широковещательного домена,
включающего локальные сети обоих филиалов. Для этого ответим на следущие
вопросы:
включающего локальные сети обоих филиалов. Для этого ответим на следущие
вопросы:
1. DHCP DISCOVER доходит до
сервера? ✓
сервера? ✓
2. DHCP OFFER возвращается
клиенту? ✓
клиенту? ✓
3. ARP-резолвинг работает внутри
VLAN? ✓
VLAN? ✓
4. Есть ли L3-связность после
настройки? ✓
настройки? ✓
Устройства в них должны получить IP адреса от
сервера на маршрутизаторе СЕ1.
сервера на маршрутизаторе СЕ1.
Для регистрации запросов к серверу DHCP включаем
захват пакетов на интерфейсе Gigabitethernet
1/0/2 на маршрутизатора СЕ1 на котором включен сервер:
захват пакетов на интерфейсе Gigabitethernet
1/0/2 на маршрутизатора СЕ1 на котором включен сервер:
CE1# monitor gigabitethernet 1/0/2 destination-mac
ff:ff:ff:ff:ff:ff etailed
ff:ff:ff:ff:ff:ff etailed
Проверяем на ПК1:
PC1>
ip dhcp
ip dhcp
DDORA IP 172.16.1.7/24
GW 172.16.1.1
GW 172.16.1.1
PC1>
sh ip
sh ip
NAME : PC1[1]
IP/MASK : 172.16.1.7/24
GATEWAY : 172.16.1.1
DNS : 77.88.8.8
DHCP
SERVER : 172.16.1.1
SERVER : 172.16.1.1
DHCP
LEASE : 86400, 86400/43200/75600
LEASE : 86400, 86400/43200/75600
MAC : 00:50:79:66:68:00
LPORT : 10012
RHOST:PORT : 127.0.0.1:10013
MTU: : 1500
PC1>
IP адрес, полученный виртуальным ПК1 выделен красным, а МАС адрес
-зеленым.
-зеленым.
Смотрим на захваченные пакеты в консоли маршрутизатора
СЕ1:
СЕ1:
10:33:38.218256
00:50:79:66:68:00 >
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)
00:50:79:66:68:00 >
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: [udp
sum ok] BOOTP/DHCP, Request from 00:50:79:66:68:00, length 364, xid 0x53b145b,
Flags [none] (0x0000)
sum ok] BOOTP/DHCP, Request from 00:50:79:66:68:00, length 364, xid 0x53b145b,
Flags [none] (0x0000)
Client-Ethernet-Address
00:50:79:66:68:00
00:50:79:66:68:00
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message
Option 53, length 1: Discover
Option 53, length 1: Discover
Hostname Option 12, length 4:
"PC11"
"PC11"
Client-ID Option 61, length 7:
ether 00:50:79:66:68:00
ether 00:50:79:66:68:00
Сервер DHCP на СЕ1 работает и выдает IP алреса.
Делаем такую же проверку на виртуальном ПК2 в локальной
сети второго филиала:
сети второго филиала:
PC2>
ip dhcp
ip dhcp
DDD
Can't
find dhcp server
find dhcp server
PC2>
Пакетыс запросом до сервера не доходят.Адрес не получен.
Проверяем состояние бриджей на СЕ1 и СЕ2:
Проверяем состояние бриджей на СЕ1 и СЕ2:
CE1#
sh int status bridge 1
sh int status bridge 1
Interface
'br1' status information:
'br1' status information:
Description: --
Operational state: Up
Administrative state: Up
Track ID: --
Supports broadcast: Yes
Supports multicast: Yes
MTU: 1500
MAC address:
a2:00:00:00:00:00
a2:00:00:00:00:00
Last change (d,h:m:s):00,01:07:22
Mode: routerport
CE1#
CE2#
sh int status bridge 1
sh int status bridge 1
Interface
'br1' status information:
'br1' status information:
Description: --
Operational state: Up
Administrative state: Up
Track ID: --
Supports broadcast: Yes
Supports multicast: Yes
MTU: 1400
MAC address:
a2:00:00:00:00:00
Last change (d,h:m:s):00,01:08:42
Mode: routerport
CE2#
Красным выделены полученные МАС адреса и они одинаковые.
Причем , если создать еще один бридж на СЕ1:
CE1#
config
config
CE1(config)#
bridge 5
bridge 5
CE1(config-bridge)#
enable
enable
CE1(config-bridge)#
exit
exit
CE1(config)#
exit
exit
CE1#
commit
commit
CE1#
confirm
confirm
CE1#
sh int status bridge
sh int status bridge
Interface Admin Link
MTU MAC address Last change Mode
MTU MAC address Last change Mode
State State (d,h:m:s)
-------------------- -----
----- ----- ----------------- ------------- ------------
----- ----- ----------------- ------------- ------------
br1 Up Up
1500 a2:00:00:00:00:00 00,01:13:22
routerport
1500 a2:00:00:00:00:00 00,01:13:22
routerport
br5 Up Down
1500 a2:00:00:00:00:00 00,00:00:21 routerport
1500 a2:00:00:00:00:00 00,00:00:21 routerport
CE1#
Видно, что маршрутизатор выдает один и тот же МАС адрес.
Соответственно его поведение сразу меняется:
2025-10-13T10:56:37+00:00
%SYSTEM-W-KERNEL: [ 2397.008823] br1: received packet on gi1/0/1.100 with own
address as source address
%SYSTEM-W-KERNEL: [ 2397.008823] br1: received packet on gi1/0/1.100 with own
address as source address
· Конфликт
MAC-адресов между устройствами
Суть проблемы:
Когда CE1 и CE2 имеют bridge-интерфейсы с одинаковым MAC-адресом, возникает
конфликт в сети.
Когда CE1 и CE2 имеют bridge-интерфейсы с одинаковым MAC-адресом, возникает
конфликт в сети.
Механизм работы:
CE1 отправляет
пакет со своего br1 с MAC-адресом a2:00:00:00:00:00
пакет со своего br1 с MAC-адресом a2:00:00:00:00:00
Пакет достигает
CE2 через интерфейс gi1/0/1.100
CE2 через интерфейс gi1/0/1.100
CE2 анализирует
пакет и обнаруживает:
пакет и обнаруживает:
Source MAC: a2:00:00:00:00:00
Сравнивает с MAC своего br1: a2:00:00:00:00:00
Результат:
адреса идентичны!
адреса идентичны!
CE2 генерирует ошибку:
text
br1:
received packet on gi1/0/1.100 with own address as source address
received packet on gi1/0/1.100 with own address as source address
Перевод: "br1 получил пакет на порту gi1/0/1.100 с
собственным адресом в качестве адреса отправителя"
собственным адресом в качестве адреса отправителя"
Почему это
критично:
критично:
Устройство "не понимает", как пакет от его
собственного MAC мог прийти извне
собственного MAC мог прийти извне
Нарушается фундаментальное правило уникальности
MAC-адресов
MAC-адресов
Может привести к сбоям в работе протоколов и потере связи
Аналогия:
Представьте, что вы получили письмо, где в графе "отправитель"
указано ваше же имя и адрес. Вы понимаете, что это невозможно и указывает на
ошибку в системе.
Представьте, что вы получили письмо, где в графе "отправитель"
указано ваше же имя и адрес. Вы понимаете, что это невозможно и указывает на
ошибку в системе.
Решение: Назначить
уникальные MAC-адреса для bridge-интерфейсов на каждом устройстве.
уникальные MAC-адреса для bridge-интерфейсов на каждом устройстве.
Назначаем вручную МАС адреса на бридж 1 маршрутизатора
СЕ1:
СЕ1:
CE1(config)#
no bridge 5
no bridge 5
CE1(config)#
bridge 1
bridge 1
CE1(config-bridge)#
CE1(config-bridge)#
mac-address a2:00:00:00:0c:e1
mac-address a2:00:00:00:0c:e1
CE1(config-bridge)#
exit
exit
CE1(config)#
exit
exit
CE1# commit
CE1# confirm
CE1#
sh int status bridge
sh int status bridge
Interface Admin Link
MTU MAC address Last change Mode
MTU MAC address Last change Mode
State State (d,h:m:s)
-------------------- -----
----- ----- ----------------- ------------- ------------
----- ----- ----------------- ------------- ------------
br1 Up Up
1500 a2:00:00:00:0c:e1
00,01:45:32 routerport
1500 a2:00:00:00:0c:e1
00,01:45:32 routerport
CE1#
Назначаем вручную МАС адреса на бридж 1 маршрутизатора
СЕ2:
СЕ2:
CE2#
config
config
CE2(config)#
bridge 1
bridge 1
CE2(config-bridge)#
mac-address a2:00:00:00:0c:e2
mac-address a2:00:00:00:0c:e2
CE2(config-bridge)#
exit
exit
CE2(config)#
exit
exit
CE2#
commit
commit
CE2#
confirm
confirm
CE2#
CE2#
sh int status bridge
sh int status bridge
Interface Admin Link
MTU MAC address Last change Mode
MTU MAC address Last change Mode
State State (d,h:m:s)
-------------------- -----
----- ----- ----------------- ------------- ------------
----- ----- ----------------- ------------- ------------
br1 Up Up
1400 a2:00:00:00:0c:e2
00,02:00:12 routerport
1400 a2:00:00:00:0c:e2
00,02:00:12 routerport
CE2#
Перегружаем устройства для полной очистки. И снова
проверяем прохожение пакетов с запросами по домену с виртуального ПК3 из локальной
сети второго филиала:
проверяем прохожение пакетов с запросами по домену с виртуального ПК3 из локальной
сети второго филиала:
PC3>
ip dhcp
ip dhcp
DORA IP 172.16.1.6/24
GW 172.16.1.1
GW 172.16.1.1
PC3>
sh ip
sh ip
NAME : PC3[1]
IP/MASK : 172.16.1.6/24
GATEWAY : 172.16.1.1
DNS : 77.88.8.8
DHCP
SERVER : 172.16.1.1
SERVER : 172.16.1.1
DHCP
LEASE : 84801, 84806/42403/74205
LEASE : 84801, 84806/42403/74205
MAC : 00:50:79:66:68:02
LPORT : 10016
RHOST:PORT : 127.0.0.1:10017
MTU:
: 1500
: 1500
PC3>
МАС адрес и IP адрес, а так же флаги запросов DHCP выделены
жирной рамкой.Проверяем протокол мониторинга в консоли СЕ1:
жирной рамкой.Проверяем протокол мониторинга в консоли СЕ1:
09:46:33.469813
00:50:79:66:68:02 > 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)
00:50:79:66:68:02 > 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: [udp
sum ok] BOOTP/DHCP, Request from 00:50:79:66:68:02, length 364, xid 0xc8ca100a,
Flags [none] (0x0000)
sum ok] BOOTP/DHCP, Request from 00:50:79:66:68:02, length 364, xid 0xc8ca100a,
Flags [none] (0x0000)
Client-Ethernet-Address
00:50:79:66:68:02
00:50:79:66:68:02
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length
1: Discover
Hostname Option 12, length 4:
"PC31"
"PC31"
Client-ID Option 61, length 7:
ether 00:50:79:66:68:02
ether 00:50:79:66:68:02
Широковещательные запросы проходят в растянутой локальной
сети между офисом и филиалами.
сети между офисом и филиалами.
Наиболее наглядно такую диагностику можно наблюдать ,
если включить захват пакетов в GNS3
на линке , соединяющем маршрутизаторы СЕ1 и РЕ1. Для этого открыть окно GNS3, на схеме сети установи
курсор мыши на линию , соединяющую интерфес Ethernet1 РЕ1 с Ethernet0
CT1. Линия при этом
станет красной. Нажать правую кнопку мыши-выбрать из выпавшего меню StartCapture-откроется окно
программы захвата пакетов WireShark
( устанавливается вместе с программой GNS3). После команды IP DHCP в
консоли ПК1 появится протокол захвата как на Рисунке 18-5:
если включить захват пакетов в GNS3
на линке , соединяющем маршрутизаторы СЕ1 и РЕ1. Для этого открыть окно GNS3, на схеме сети установи
курсор мыши на линию , соединяющую интерфес Ethernet1 РЕ1 с Ethernet0
CT1. Линия при этом
станет красной. Нажать правую кнопку мыши-выбрать из выпавшего меню StartCapture-откроется окно
программы захвата пакетов WireShark
( устанавливается вместе с программой GNS3). После команды IP DHCP в
консоли ПК1 появится протокол захвата как на Рисунке 18-5:
Рисунок 4-18-5. Окно прораммы захвата пакетов WireShark.
Ответы на первые два вопроса получены утвердительные-DHCP сервер
получает широковещетельный запрос на адрес
ff:ff:ff:ff:ff:ff и отвечавет на него.
получает широковещетельный запрос на адрес
ff:ff:ff:ff:ff:ff и отвечавет на него.
Проверяем работу широковещательного домена на пакетах ARP
и PING
для проверки связности VLAN.
Для этого нужно знать MAC адрес устройства в локальной широковещательной сети.
Например. устройства MicroCoreLinux6.4-2
в локальной сети за интерфейсом Gigabitethernet
1/0/2 маршрутизатора СЕ2 в филиале:
и PING
для проверки связности VLAN.
Для этого нужно знать MAC адрес устройства в локальной широковещательной сети.
Например. устройства MicroCoreLinux6.4-2
в локальной сети за интерфейсом Gigabitethernet
1/0/2 маршрутизатора СЕ2 в филиале:
gns3@box:~$ ip add | grep eth0 -A 2 | grep link -A
2
2
link/ether 0c:94:a2:32:00:00
brd ff:ff:ff:ff:ff:ff
inet 172.16.1.4/24
brd 172.16.1.255 scope global eth0
brd 172.16.1.255 scope global eth0
valid_lft forever preferred_lft forever
gns3@box:~$
MAC адрес выделен красным, а полученый по DHCP ( по псевдопроводу VPWS VLAN 100 от сервера на
маршрутизаторе СЕ1 другого филиала)-зеленым.
маршрутизаторе СЕ1 другого филиала)-зеленым.
Для проверки используется утилита ARPING на
устройстве MicroCoreLinux6.4-1
на противоположном конце псевдопровода в локальной сети за интерфейсом Gigabitethernet 1/0/2 CE1:
устройстве MicroCoreLinux6.4-1
на противоположном конце псевдопровода в локальной сети за интерфейсом Gigabitethernet 1/0/2 CE1:
gns3@box:~$ sudo arping 172.16.1.4
ARPING to 172.16.1.4 from 172.16.1.3 via eth0
Unicast reply from 172.16.1.4 [c:94:a2:32:0:0] 3.504ms
<skip>
Unicast
reply from 172.16.1.4 [c:94:a2:32:0:0] 7.603ms
reply from 172.16.1.4 [c:94:a2:32:0:0] 7.603ms
^CSent 6 probe(s) (1 broadcast(s))
Received 6 reply (0 request(s), 0 broadcast(s))
gns3@box:~$
Красным велен IP адрес , зеленым-МАС адрес. Они
совпадают с определенными на другой стороне. Поверим IP связность VLAN:
совпадают с определенными на другой стороне. Поверим IP связность VLAN:
PC3>
ping 172.16.1.3 -c 3
ping 172.16.1.3 -c 3
84
bytes from 172.16.1.3 icmp_seq=1 ttl=64 time=8.634 ms
bytes from 172.16.1.3 icmp_seq=1 ttl=64 time=8.634 ms
84
bytes from 172.16.1.3 icmp_seq=2 ttl=64 time=9.719 ms
bytes from 172.16.1.3 icmp_seq=2 ttl=64 time=9.719 ms
84
bytes from 172.16.1.3 icmp_seq=3 ttl=64 time=7.622 ms
bytes from 172.16.1.3 icmp_seq=3 ttl=64 time=7.622 ms
PC3>
trace 172.16.1.3 -P 6
trace 172.16.1.3 -P 6
trace
to 172.16.1.3, 8 hops max (TCP), press Ctrl+C to stop
to 172.16.1.3, 8 hops max (TCP), press Ctrl+C to stop
1
172.16.1.3 7.813 ms 3.182 ms
3.990 ms
172.16.1.3 7.813 ms 3.182 ms
3.990 ms
PC3>
Широковещательные запросы в домене ходят и есть IP связность.
Задача решена успешно.
Задача решена успешно.
mpls l2vpn gns3 vesr eltex