Простите за название блога с кликбейтом, но я говорю серьезно. Одна из самых неприятных вещей при поиске и устранении неисправностей в сети - это проблема с максимальным размером передаваемого блока данных (MTU)
Одна из самых раздражающих проблем в сети - это ограничение в виде максимального размера полезного блока данных одного пакета, который может быть передан протоколом без фрагментации (MTU). Для тех, кому это незнакомо, MTU - верхняя граница размера датаграммы, которая может быть в данном интерфейсе. На разных уровнях модели OSI также существуют различные MTU: MTU Ethernet, MTU MPLS, MTU IPv4/v6 и другие. Даже в протоколе управления передачей (TCP) есть понятие максимального размера сегмента (MSS), которое действует аналогичным образом. Сложность определения этих верхних границ возрастает по мере добавления дополнительных элементов инкапсуляции: туннельных заголовков, тегов VLAN, меток MPLS... список можно продолжать.
Рассмотрим приведенную ниже топологию. В линейной топологии три маршрутизатора используют различные типы соединений. R1 имеет три логических соединения с R2: собственный Ethernet, одинарный 802.1Q тег и двойной 802.1Q тег (QinQ). Каждое из этих соединений также работает под управлением протокола распределения меток (LDP) для обмена метками MPLS. R2 имеет одно соединение Point-to-Point Protocol (PPP) с R3, которое служит в качестве андерлея для Generic Routing Encapsulation (GRE) между этими двумя устройствами. OSPFv3 работает вместе с LDP на всех соединениях, кроме PPP-подключения R2-R3, для обмена маршрутами IPv4 и IPv6. Адресация локального канала IPv6 соответствует формату fe80::X, где X - идентификатор маршрутизатора; для краткости он не изображен.
Настал момент, которого вы все ждали. Базовой командой является "show adjacency", которая отображает таблицу смежности Cisco Express Forwarding (CEF). Меня в меньшей степени интересует обсуждение внутренней архитектуры маршрутизатора/структуры данных и в большей - объяснение того, как эта команда поможет операторам реальных сетей. Рассмотрим приведенный ниже вывод "show adjacency" маршрутизатора R1.
R1#show adjacency
Protocol Interface Address
IP Ethernet0/0.10 10.0.10.2(16)
TAG Ethernet0/0.10 10.0.10.2(5)
IPV6 Ethernet0/0.10 FE80::2(9)
IP Ethernet0/0.11 10.0.11.2(16)
TAG Ethernet0/0.11 10.0.11.2(5)
IPV6 Ethernet0/0.11 FE80::2(9)
IP Ethernet0/0.12 10.0.12.2(16)
TAG Ethernet0/0.12 10.0.12.2(5)
IPV6 Ethernet0/0.12 FE80::2(9)Имеется девять записей: три для IPv4, три для IPv6 и три для "TAG", что означает MPLS. Как показано на схеме ранее, VLAN 10 - это собственный Ethernet, VLAN 11 имеет один тег 802.1Q, а VLAN 12 - два тега 802.1Q. В столбце адреса отображается соответствующая информация о следующем хопе, основанная на схеме юникастовой маршрутизации. Пока что это не очень интересно. Давайте углубимся в описание IPv4 на Ethernet0/0.10, немаркированном интерфейсе. Можно выполнить фильтрацию на основе типа соединения (IPv4, IPv6 или MPLS), идентификатора интерфейса и некоторых других полей.
R1#show adjacency Ethernet0/0.10 link ipv4 detail
Protocol Interface Address
IP Ethernet0/0.10 10.0.10.2(16)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 0
Encap length 14
AABBCC000200AABBCC0001000800
ARPИспользуя ключевое слово "detail", маршрутизатор предоставляет дополнительные сведения. Чтобы не отвлекаться на поиск и устранение неисправностей MTU, мы ограничимся рассмотрением деталей инкапсуляции. Согласно полученным данным, длина инкапсуляции составляет 14 байт, за которыми следует шестнадцатеричная строка из 28 символов. Так получилось, что стандартный заголовок Ethernet имеет длину 14 байт, без учета деталей первого уровня, таких как преамбула и циклическая проверка избыточности (CRC). Первые 6 байт представляют MAC-адрес назначения (MAC, привязанный к 10.0.10.2), следующие 6 байт представляют MAC-адрес источника (MAC R1 на Ethernet0/0), а последние 2 байта представляют Ethertype 0x0800. Этот код указывает на то, что Ethernet фрейм будет нести полезную нагрузку IPv4. Вам придется поверить мне на слово относительно Ethertype 0x0800 (уверяю, что не обманываю), но мы можем верифицировать MAC-адреса, проверив кэш протокола определения адреса IPv4 (ARP).
R1#show ip arp Ethernet0/0.10
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.10.1 - aabb.cc00.0100 ARPA Ethernet0/0.10
Internet 10.0.10.2 13 aabb.cc00.0200 ARPA Ethernet0/0.10Видно, что MAC R2 - это первые 6 байт, а MAC R1 - это вторые 6 байт, что является верным. Для особо скептически настроенных, вот захват пакетов, доказывающий, что маршрутизатор действительно сообщает правду. Я выделил 14-байтовую строку инкапсуляции Ethernet, которая точно совпадает с выводом "show adjacency", рассмотренным ранее.
Давайте попробуем другой пример, на этот раз посвященный смежности IPv6 через VLAN 11. Это соединение использует один тег 802.1Q.
R1#show adjacency Ethernet0/0.11 link ipv6 detail
Protocol Interface Address
IPV6 Ethernet0/0.11 FE80::2(9)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 0
Encap length 18
AABBCC000200AABBCC0001008100000B
86DD
IPv6 NDКакие различия вы можете увидеть? Во-первых, длина инкапсуляции теперь составляет 18 байт. Для сетей VLAN с одним тегом требуется стандартный 14-байтовый заголовок Ethernet, описанный выше, плюс 4-байтовая инкапсуляция 802.1Q. Первые 12 байт одинаковы (MAC-адреса источника и назначения), а затем идет 0x8100. Это Ethertype для 802.1Q, сигнализирующий о том, что следующие 4 байта будут тегом VLAN. Биты с 5 по 16 (всего 12 бит) сигнализируют о значении VLAN, которое равно 0x00B (десятичное 11). Последние 2 байта заголовка 802.1Q включают Ethertype следующего заголовка в стеке инкапсуляции. Значение 0x86DD представляет Ethertype IPv6, указывая на то, что эти Ethernet фреймы содержат полезную нагрузку IPv6. На рисунке ниже я выделил 4-байтовый тег VLAN. Прямо перед ним вы видите 14-байтовый заголовок Ethernet, заканчивающийся значением 0x8100, сигнализирующим о наличии инкапсуляции 802.1Q.
Давайте попробуем более сложный пример. Мы запросим R1 о его MPLS смежности на интерфейсе VLAN 12, который использует туннелирование QinQ.
R1#show adjacency Ethernet0/0.12 link mpls detail
Protocol Interface Address
TAG Ethernet0/0.12 10.0.12.2(5)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 0
Encap length 22
AABBCC000200AABBCC0001008100000C
8100000D8847
ARPСпрошу еще раз, что изменилось? Длина инкапсуляции снова увеличилась на 4 байта и теперь составляет 22 байта. Это сделано для учета дополнительного тега VLAN. Первые 12 байт остались прежними, за ними следует первый Ethertype 0x8100 для 802.1Q. VLAN ID внешнего тега - 0x00C (десятичное 12), а VLAN ID внутреннего тега - 0x00D (десятичное 13). Как и теги MPLS, теги VLAN могут быть сложены в стопку таким же образом, но не забудьте учесть 4-байтовую длину каждого из них. Последние 2 байта внутреннего заголовка VLAN - 0x8847. Это Ethertype для юникастового MPLS, верно указывающий на полезную нагрузку. Помните, что "show adjacency" не покажет стек тегов MPLS, так как он различается для каждого пункта назначения, но позже я покажу вам, как это можно выяснить. Вот снимок экрана Wireshark, я выделил самый внутренний тег VLAN со значением 13 и его Ethertype юникастового MPLS. Внешний тег VLAN 12 можно увидеть в 4 байтах, которые ему предшествуют.
Давайте на минутку отвлечемся от лаборатории. Почему это важно? Предположим, вы - поставщик услуг, предлагающий услуги частной линии Ethernet (EPL) между R1 и R2. Клиент ожидает получить услугу по транспортировке с сохранением тегов VLAN на протяжении всего маршрута. Кроме того, клиент хочет отправить до 2 тегов VLAN, и если предположить, что оператор использует псевдопровод с сигналом LDP, вам придется также учитывать инкапсуляцию MPLS, дополнительное контрольное слово и собственную инкапсуляцию второго уровня. Надеюсь, понятно, почему эта команда полезна; она четко показывает, сколько накладных расходов добавляется на втором уровне.
Это не ограничивается только Ethernet. Рассмотрите приведенный ниже вывод. Здесь показаны детали инкапсуляции на PPP-ссылке к R3 с позиции R2.
R2#show adjacency Serial1/0 link ipv4 detail
Protocol Interface Address
IP Serial1/0 point2point(16)
5 packets, 640 bytes
epoch 0
sourced in sev-epoch 0
Encap length 4
FF030021
P2P-ADJОверхед второго уровня составляет всего 4 байта. Большинство сетевиков не часто задумываются об инкапсуляции PPP (я точно не задумываюсь), но это действительно является верным решением. Вот изображение захвата пакета; поля адреса, управления и протокола в сумме составляют 4 байта и четко отображаются в выводе выше. То же самое справедливо и для всех других инкапсуляций второго уровня, поддерживаемых устройством.
На вершине этого PPP соединения находится GRE туннель под названием Tunnel23. Туннель поддерживает IPv4, IPv6 и MPLS, о чем свидетельствуют приведенные ниже результаты.
R2#show adjacency Tunnel23
Protocol Interface Address
IP Tunnel23 point2point(11)
TAG Tunnel23 point2point(4)
IPV6 Tunnel23 point2point(6)Давайте сосредоточимся на смежности MPLS, поскольку это приводит к самому интересному. Несмотря на то, что можно использовать ключевое слово "detail", как мы это делали, давайте попробуем вместо него использовать ключевое слово "encapsulation". Это открывает некоторые дополнительные возможности в отношении туннельных соединений, которые лично я считаю полезными.
R2#show adjacency Tunnel23 link mpls encapsulation
Protocol Interface Address
TAG Tunnel23 point2point(4)
Encap length 24
4500000000000000FF2F0C79C0A81702
C0A8170300008847
Provider: TUNNEL
Protocol header count in macstring: 2
HDR 0: ipv4
dst: static, 192.168.23.3
src: static, 192.168.23.2
prot: static, 47
ToS: static, 0
ttl: static, 255
df: static, cleared
per packet fields: ident tl chksm
HDR 1: gre
prot: static, 0x8847
per packet fields: noneКак обычно, вывод включает длину инкапсуляции, за которой следует длинная шестнадцатеричная строка. Основной оверхед GRE на базе IPv4 (без ключа, контрольной суммы и номеров последовательности) имеет длину 24 байта и состоит из 20-байтового заголовка IPv4 и 4-байтового заголовка GRE. Отображаются оба заголовка, перечисленные как "HDR 0" и "HDR 1" соответственно. Все детали заголовка IPv4 расположены по отдельности в чистом формате, что может помочь при поиске неисправностей конечной точки туннеля. Затем отображаются детали GRE. Идентификатор протокола равен 0x8847, что указывает на то, что туннель будет передавать пакеты MPLS. В этом примере я бы рекомендовал настроить туннель Tunnel23 с IP MTU равным 1476 байт, вычисленным путем вычитания 24 из 1500 (при условии, что PPP соединение имеет IP MTU равное 1500 байт). Я бы использовал это же значение и для MTU MPLS.
Осталось обсудить последний нюанс, связанный с MPLS, особенно в отношении туннелей и других уровней инкапсуляции. Предположим, что за R3 находится большая сеть MPLS, и какое-то удаленное устройство хочет отправить трафик с коммутацией меток через R3 в направлении R1. R3 получит MPLS-инкапсулированный трафик, обратится к своей информационной базе пересылки меток (LFIB) и обнаружит, что выходной интерфейс к loopback на R1 проходит через Tunnel23. Приведенный ниже результат доказывает это. Если вы не эксперт по MPLS, не стоит беспокоиться. Пока сосредоточьтесь на оверхеде, связанном с инкапсуляцией.
R3#show mpls forwarding-table 10.0.0.1 32 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
3000 2001 10.0.0.1/32 0 Tu23 point2point
MAC/Encaps=24/28, MRU=1476, Label Stack{2001}
4500000000000000FF2F0C79C0A81703C0A8170200008847 007D1000
No output feature configuredПосмотрите на эту чудовищную строку шестнадцатеричных символов. Знакомо? Должно быть, потому что первые 24 байта идентичны тем, что мы только что рассмотрели в случае с GRE смежностью. Последний 4-байтовый фрагмент представляет собой shim-заголовок MPLS. Первые 20 битов этого заголовка (т.е. первые 5 символов) представляют значение метки MPLS 0x007D1 (десятичное 2001). Это значение отображается как исходящая метка, и низкоуровневый шестнадцатеричный дамп просто подтверждает это. Последние 12 битов являются переменными для каждого пакета и включают S-бит (нижняя часть стека), экспериментальные биты и значения времени жизни пакета (TTL); LFIB использует нули в качестве заполнителей. Тем не менее, общая инкапсуляция по этому пути с коммутацией меток составляет 28 байт и может быть еще больше, если в стек помещаются дополнительные метки (4 байта на метку). На скриншоте ниже я выделил метку MPLS, чтобы вы могли увидеть, куда она попадает в шестнадцатеричном дампе данных. Она идет сразу после 0x8847 в конце заголовка GRE и непосредственно перед полезной нагрузкой IPv4.
В качестве бонуса позвольте мне научить вас полезному трюку с Wireshark. Обратите внимание, что каждая строка шестнадцатеричных данных содержит 32 символа или 16 байт. Счетчики строк увеличиваются на 16 путем добавления 0x0010 каждый раз. Метка MPLS - это последний фрагмент данных перед началом IP-заголовка в строке 0x0020. Это означает, что перед MPLS-инкапсулированным IP-пакетом имеется ровно 32 байта оверхеда: 4 байта PPP, 24 байта GRE и 4 байта MPLS. Подводя итог, я написал этот блог, чтобы добавить простой, но мощный инструмент в ваш инструментарий. Я регулярно использую "show adjacency" и его варианты для подтверждения своих предположений о длине инкапсуляции второго уровня. Вы избавите себя и своих клиентов от многих душевных терзаний, если с первого раза правильно определите MTU! Если вам понравился этот блог и мой непосредственный, сфокусированный на технике стиль обучения, то вам понравится моя серия курсов Cisco Advanced Routing на Pluralsight.
Справочные конфигурации:
# R1
version 15.6
!
hostname R1
!
!
no aaa new-model
!
!
!
no ip icmp rate-limit unreachable
!
!
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
mpls label range 1000 1999
!
!
!
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
ipv6 address FC00::1/128
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface Ethernet0/0
description TO R2
no ip address
!
interface Ethernet0/0.10
encapsulation dot1Q 10 native
ip address 10.0.10.1 255.255.255.0
ipv6 address FE80::1 link-local
mpls ip
ospfv3 1 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
interface Ethernet0/0.11
encapsulation dot1Q 11
ip address 10.0.11.1 255.255.255.0
ipv6 address FE80::1 link-local
mpls ip
ospfv3 1 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
interface Ethernet0/0.12
encapsulation dot1Q 12 second-dot1q 13
ip address 10.0.12.1 255.255.255.0
ipv6 address FE80::1 link-local
mpls ip
ospfv3 1 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
router ospfv3 1
!
address-family ipv4 unicast
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
!
mpls ldp router-id Loopback0
!
end# R2
version 15.6
!
hostname R2
!!
no aaa new-model
!
!
!
!
!
no ip icmp rate-limit unreachable
!
!
!
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
mpls label range 2000 2999
!
!
!
!
interface Loopback0
ip address 10.0.0.2 255.255.255.255
ipv6 address FC00::2/128
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface Tunnel23
ip address 10.2.3.2 255.255.255.0
ipv6 address FE80::2 link-local
mpls ip
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
tunnel source 192.168.23.2
tunnel destination 192.168.23.3
!
interface Ethernet0/0
description TO R1
no ip address
!
interface Ethernet0/0.10
encapsulation dot1Q 10 native
ip address 10.0.10.2 255.255.255.0
ipv6 address FE80::2 link-local
mpls ip
ospfv3 1 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
interface Ethernet0/0.11
encapsulation dot1Q 11
ip address 10.0.11.2 255.255.255.0
ipv6 address FE80::2 link-local
mpls ip
ospfv3 1 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
interface Ethernet0/0.12
encapsulation dot1Q 12 second-dot1q 13
ip address 10.0.12.2 255.255.255.0
ipv6 address FE80::2 link-local
mpls ip
ospfv3 1 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
interface Serial1/0
ip address 192.168.23.2 255.255.255.0
encapsulation ppp
serial restart-delay 0
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospfv3 1
!
address-family ipv4 unicast
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
mpls ldp router-id Loopback0
!
end# R3
hostname R3
!
no aaa new-model
!
!
!
!
no ip icmp rate-limit unreachable
!
!
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
mpls label range 3000 3999
!
!
!
!
interface Loopback0
ip address 10.0.0.3 255.255.255.255
ipv6 address FC00::3/128
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
!
interface Tunnel23
ip address 10.2.3.3 255.255.255.0
ipv6 address FE80::3 link-local
mpls ip
ospfv3 1 ipv6 area 0
ospfv3 1 ipv4 area 0
tunnel source 192.168.23.3
tunnel destination 192.168.23.2
!
interface Ethernet0/0
no ip address
shutdown
!
interface Ethernet0/1
no ip address
shutdown
!
interface Ethernet0/2
no ip address
shutdown
!
interface Ethernet0/3
no ip address
shutdown
!
interface Serial1/0
ip address 192.168.23.3 255.255.255.0
encapsulation ppp
serial restart-delay 0
!
interface Serial1/1
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/2
no ip address
shutdown
serial restart-delay 0
!
interface Serial1/3
no ip address
shutdown
serial restart-delay 0
!
router ospfv3 1
!
address-family ipv4 unicast
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
mpls ldp router-id Loopback0
!
endМатериал подготовлен в рамках курса «Дизайн сетей ЦОД».
Всех желающих приглашаем на открытый урок «VxLan EVPN — настройка iBGP в overlay». Рассмотрим плюсы и минусы реализации iBGP, преимущества перед eBGP. >> РЕГИСТРАЦИЯ