Простите за название блога с кликбейтом, но я говорю серьезно. Одна из самых неприятных вещей при поиске и устранении неисправностей в сети - это проблема с максимальным размером передаваемого блока данных (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. Имеется девять записей: три для IPv4, три для IPv6 и три для "TAG", что означает MPLS. Как показано на схеме ранее, VLAN 10 - это собственный Ethernet, VLAN 11 имеет один тег 802.1Q, а VLAN 12 - два тега 802.1Q. В столбце адреса отображается соответствующая информация о следующем хопе, основанная на схеме юникастовой маршрутизации. Пока что это не очень интересно. Давайте углубимся в описание IPv4 на Ethernet0/0.10, немаркированном интерфейсе. Можно выполнить фильтрацию на основе типа соединения (IPv4, IPv6 или MPLS), идентификатора интерфейса и некоторых других полей. Используя ключевое слово "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). Видно, что MAC R2 - это первые 6 байт, а MAC R1 - это вторые 6 байт, что является верным. Для особо скептически настроенных, вот захват пакетов, доказывающий, что маршрутизатор действительно сообщает правду. Я выделил 14-байтовую строку инкапсуляции Ethernet, которая точно совпадает с выводом "show adjacency", рассмотренным ранее. Давайте попробуем другой пример, на этот раз посвященный смежности IPv6 через VLAN 11. Это соединение использует один тег 802.1Q. Какие различия вы можете увидеть? Во-первых, длина инкапсуляции теперь составляет 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. Спрошу еще раз, что изменилось? Длина инкапсуляции снова увеличилась на 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. Оверхед второго уровня составляет всего 4 байта. Большинство сетевиков не часто задумываются об инкапсуляции PPP (я точно не задумываюсь), но это действительно является верным решением. Вот изображение захвата пакета; поля адреса, управления и протокола в сумме составляют 4 байта и четко отображаются в выводе выше. То же самое справедливо и для всех других инкапсуляций второго уровня, поддерживаемых устройством. На вершине этого PPP соединения находится GRE туннель под названием Tunnel23. Туннель поддерживает IPv4, IPv6 и MPLS, о чем свидетельствуют приведенные ниже результаты. Давайте сосредоточимся на смежности MPLS, поскольку это приводит к самому интересному. Несмотря на то, что можно использовать ключевое слово "detail", как мы это делали, давайте попробуем вместо него использовать ключевое слово "encapsulation". Это открывает некоторые дополнительные возможности в отношении туннельных соединений, которые лично я считаю полезными. Как обычно, вывод включает длину инкапсуляции, за которой следует длинная шестнадцатеричная строка. Основной оверхед 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, не стоит беспокоиться. Пока сосредоточьтесь на оверхеде, связанном с инкапсуляцией. Посмотрите на эту чудовищную строку шестнадцатеричных символов. Знакомо? Должно быть, потому что первые 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. Справочные конфигурации: Материал подготовлен в рамках курса «Дизайн сетей ЦОД».  Всех желающих приглашаем на открытый урок «VxLan EVPN — настройка iBGP в overlay». Рассмотрим плюсы и минусы реализации iBGP, преимущества перед eBGP.  >> РЕГИСТРАЦИЯ Переводчик, редактор