Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря

    Статья получилась довольно объёмная, рассмотренные темы — форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.

    Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.

    Форматы Ehternet фреймов.


    1) Ethernet II



    Рис. 1

    Preamble – последовательность бит, по сути, не являющаяся частью ETH заголовка определяющая начало Ethernet фрейма.

    DA (Destination Address) – MAC адрес назначения, может быть юникастом, мультикастом, бродкастом.

    SA (Source Address) – MAC адрес отправителя. Всегда юникаст.

    E-TYPE (EtherType) – Идентифицирует L3 протокол (к примеру 0x0800 – Ipv4, 0x86DD – IPv6, 0x8100- указывает что фрейм тегирован заголовком 802.1q, и т.д. Список всех EtherType — standards.ieee.org/develop/regauth/ethertype/eth.txt )

    Payload – L3 пакет размером от 46 до 1500 байт

    FCS (Frame Check Sequences) – 4 байтное значение CRC используемое для выявления ошибок передачи. Вычисляется отправляющей стороной, и помещается в поле FCS. Принимающая сторона вычисляет данное значение самостоятельно и сравнивает с полученным.

    Данный формат был создан в сотрудничестве 3-х компаний – DEC, Intel и Xerox. В связи с этим, стандарт также носит название DIX Ethernet standard. Данная версия стандарта была опубликована в 1982г (первая версия, Ehernet I – в 1980г. Различия в версиях небольшие, формат в целом остался неизменным). В 1997г. году данный стандарт был добавлен IEEE к стандарту 802.3, и на данный момент, подавляющее большинство пакетов в Ethernet сетях инкапсулированы согласно этого стандарта.

    2) Ethernet_802.3/802.2 (802.3 with LLC header)



    Рис. 2

    Как вы понимаете, комитет IEEE не мог смотреть спокойно, как власть, деньги и женщины буквально ускользают из рук. Поэтому, занятый более насущными проблемами, за стандартизацию технологии Ethernet взялся с некоторым опозданием (в 1980 взялись за дело, в 1983 дали миру драфт, а в 1985 сам стандарт), но большим воодушевлением. Провозгласив инновации и оптимизацию своими главными принципами, комитет выдал следующий формат фрейма, который вы можете наблюдать на Рисунке 2.

    Первым делом обращаем внимание на то, что “ненужное” поле E-TYPE преобразовано в поле Length, которое указывало на количество байт следующее за этим полем и до поля FCS. Теперь, понять у кого длинее можно было уже на втором уровне системы OSI. Жить стало лучше. Жить стало веселее.

    Но, указатель на тип протокола 3его уровня был нужен, и IEEE дало миру следующую инновацию — два поля по 1 байту — Source Service Access Point(SSAP) и Destination Service Access Point (DSAP). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

    Замечание: В жизни же это мало пригодилось и SSAP/DSAP значения обычно совпадают. К примеру SAP для IP – 6, для STP — 42 (полный список значений — standards.ieee.org/develop/regauth/llc/public.html)

    Не давая себе передышки, в IEEE зарезервировали по 1 биту в SSAP и DSAP. В SSAP под указание command или response пакета, в DSAP под указание группового или индивидуального адреса (см. Рис. 6). В Ethernet сетях эти вещи распространения не получили, но количество бит в полях SAP сократилось до 7, что оставило лишь 128 возможных номера под указание вышестоящего протокола. Запоминаем этот факт, к нему мы ещё вернёмся.

    Было уже сложно остановиться в своём стремлении сделать лучший формат фрейма на земле, и в IEEE фрейм формате появляется 1 байтное поле Control. Отвечающее, не много, не мало, за Connection-less или же Connection-oriented соединение!

    Выдохнув и осмотрев своё детище, в IEEE решили взять паузу.

    Замечание: Рассматриваемые 3 поля — DSAP, SNAP и Control и являются LLC заголовком.

    3) «Raw» 802.3



    Рис. 3

    Данный «недостандарт» явил в мир Novell. Это были лихие 80-ые, все выживали, как могли, и Novell не был исключением. Заполучив ещё в процессе разработки спецификации стандарта 802.3/802.2, и лёгким движением руки выкинув LLC заголовок, в Novell получили вполне себе неплохой фрейм формат (с возможность измерения длины на втором уровне!), но одним существенным недостатком – отсутствием возможности указания вышестоящего протокола. Но, как вы уже могли догадаться, работали там ребята не глупые, и по здравому размышлению выработали решение – «а обратим ка мы свои недостатки в свои же достоинства», и ограничили этот фрейм-формат исключительно IPX протоколом, который сами же и поддерживали. И задумка хорошая, и план был стратегически верный, но, как показала история, не фортануло.

    4) 802.3 with SNAP Header.

    Время шло. В комитет IEEE приходило осознание того, что номера протоколов и деньги кончаются. Благодарные пользователи засыпали редакцию письмами, где 3-х байтный LLC заголовок ставился в один ряд с такими великими инновациями человечества, как оборудование собаки 5ой ногой, или же с рукавом, который можно использовать для оптимизации женской анатомии. Выжидать дальше было нельзя, настало время заявить о себе миру повторно.


    Рис. 4

    И в помощь страждущим от нехватки номеров протоколов (их всего могло быть 128 – мы упоминали), IEEE вводит новый стандарт фрейма Ethernet SNAP (Рис. 4). Основное нововведение — добавление 5-ти байтного поля Subnetwork Access Protocol (SNAP), которое в свою очередь состоит из двух частей – 3х байтного поля Organizationally Unique Identifier (OUI) и 2х байтного Protocol ID (PID) — Рис. 5.


    Рис. 5

    OUI или же vendor code – позволяет идентифицировать пропиетарные протоколы указанием вендора. К примеру, если вы отловите WireShark`ом пакет PVST+, то в поле OUI увидите код 0x00000c, который является идентификатором Cisco Systems (Рис. 6).


    Рис. 6

    Замечание: Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP, протоколы CDP, VTP, DTP.

    Поле PID это, по сути, то же поле EtherType из DIX Ethernet II — 2 байта под указание протокола вышестоящего уровня. Так как ранее, для этого использовались DSAP и SSAP поля LLC заголовка, то для указания того, что тип вышестоящего протокола нужно смотреть в поле SNAP, поля DSAP и SSAP принимают фиксированное значение 0xAA (также видно на Рис. 6)

    Замечание: При использовании для переноса IP пакетов формата фрейма LLC/SNAP, IP MTU снижается с 1500 до 1497 и 1492 байт соответственно.

    По заголовкам в формате фрейма в принципе всё. Хотел бы обратить внимание на ещё один момент в формате фрейма – размер payload. Откуда взялся этот диапазон — от 46 до 1500 байт?

    Размер L3 Payload.


    Откуда взялось нижнее ограничение, знает, пожалуй, каждый, кто хотя бы читал первый курикулум CCNA. Данное ограничение является следствием ограничения в размер фрейма в 64 байта (64 байта – 14 байт L2 заголовок — 4 байта FCS = 46 байт ) накладываемого методом CSMA/CD – время требуемое на передачу 64 байт сетевым интерфейсом является необходимым и достаточным для определения коллизии в среде Ethernet.
    Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

    А вот откуда взялись эти пресловутые 1500 байт, вопрос сложнее. Я нашел следующее объяснение — предпосылок на введение верхнего ограничения размера фрейма было несколько:
    • Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где Collision домен не ограничивался портом, и все станции должны были ждать завершения передачи, это было серьёзной проблемой.
    • Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в collision домене будут вынуждены опять ожидать.
    • Ограничения, накладываемые памятью используемой под интерфейс буферы – на тот момент (1979г) увеличение буферов значительно удорожало стоимость интерфейса.
    • Ограничение, вносимое полем Length/Type – в стандарте закреплено, что все значения выше 1536 (от 05-DD до 05-FF.) указывают на EtherType, соответственно длина должна быть меньше 05-DC. (У меня правда есть подозрение, что это скорее следствие, чем предпосылка, но вроде инфа от разработчиков стандарта 802.3)

    Итого, в стандарте 802.3 размер фрейма ограничивался 1518 байтами сверху, а payload 1500 байтами (отсюда и дефолтный размер MTU для Ethernet интерфейса).

    Замечание: Фреймы меньше 64 байт называются Runts, фреймы больше 1518 байт называются Giants. Просмотреть кол-во таких фреймов полученных на интерфейсе можно командой show interface gigabitEthernet module/number и show interface gigabitEthernet module/number counters errors. Причём до IOS 12.1(19) в счётчики шли как фреймы с неверным, так и верным CRS (хотя вторые не всегда дропались – зависит от платформы и условий). А вот начиная с 12.1.(19) отображаются в этих счётчиках только те runt и giant фреймы, которые имеют неверный CRS, фреймы меньше 64 байт, но с верным CRS (причина возникновения обычно связана с детегированием 802.1Q или источником фреймов, а не проблемами физического уровня) с этой версии попадают в счётчик Undersize, дропаются они, или же форвардятся дальше, зависит от платформы.

    Эволюция размеров Ethernet заголовков.

    С развитием технологий и спецификаций линейки IEEE 802 претерпевал изменения и размер фрейма. Основные дальнейшее изменения размера фрейма (не MTU!):
    • 802.3AC — увеличивает максимальный размер фрейма до 1522 – добавляется Q-tag – несущий информацию о 802.1Q (VLAN tag) и 802.1p (биты под COS)
    • 802.1AD — увеличивает максимальный размер фрейма до 1526, поддержка QinQ
    • 802.1AH (MIM) – Provider Bridge Backbone Mac in Mac + 30 байт к размеру фрейма
    • MPLS – увеличиваем размер фрейма на стек меток 1518 + n*4, где n – количество меток в стеке.
    • 802.1AE – Mac Security, к стандартным полям добавляются поля Security Tag и Message Authentication Code + 68 байт к размеру фрейма.


    Все эти фреймы увеличенного размера группируются под одни именем – Baby-Giant frames. Негласное верхнее ограничение по размерам для Baby-Giant – это 1600 байт. Современные сетевые интерфейсы будут форвардить эти фреймы, зачастую, даже без изменения значения HW MTU.

    Отдельно обратим внимание на спецификации 802.3AS — увеличивает максимальный размер фрейма до 2000 (но сохраняет размер MTU в 1500 байт!). Увеличение приходится на заголовок и трейлер. Изначально увеличение планировалось на 128 байт – для нативной поддержки стандартом 802.3 вышеперечисленных расширений, но в итоге сошлись на 2х тысячах, видимо, чтобы два раза не собираться (или как говорят в IEEE – this frame size will support encapsulation requirements of the foreseeable future). Стандарт утвержден в 2006 году, но кроме как на презентациях IEEE, я его не встречал. Если у кого есть что добавить здесь (и не только здесь) – добро пожаловать в комменты. В целом тенденция увеличения размера фрейма при сохранении размера PAYLOAD, порождает у меня в голове смутные сомнения в правильности выбранного направления движения.

    Замечание: Немного в стороне от перечисленного обосновался FCoE фрейм – размер фрейма до 2500 байт, зачастую, эти фреймы называются mini-jumbo. Для их саппорта необходимо включать поддержку jumbo-frame.

    И последний «бастард» Ethernet это Jumbo Frame (хотя если перевести Jumbo, то вырисовывается скорее Ходор – отсылка к Game of Thrones). Под это описание попадают все фреймы превосходящие размером стандарт в 1518 байт, за исключением рассмотренных выше. Jumbo пакеты никак не отражены в спецификациях 802.3 и поэтому реализация остаётся на совести каждого конкретного вендора. Тем не менее, Jumbo фреймы существуют столько же, сколько существует Ethernet. Определено это следующим:
    1. Выгода соотношения Payload к заголовкам. Чем больше это соотношение, тем эффективней мы можем использовать линии связи. Конечно здесь разрыв будет не такой как в сравнении с использованием пакетов в 64 байт и 1518 байт для TCP сессий. Но свои 3-8 процентов, в зависимости от типа трафика выиграть можно.
    2. Значительно меньшее количество заголовков генерирует меньшую нагрузку на Forwading Engine, также и на сервисные Engine. К примеру, frame rate для 10G линка загруженного фреймами по 1500 байт равен 812 744 фреймов в секунду, а тот же линк загруженный Jumbo фреймами в 9000 байт генерирует фрейм рейт всего лишь в 138 587 фрейм в секунду. На рисунке 7 приведены график из отчёта Alteon Networks (ссылка будет внизу статьи) утилизации CPU и гигабитного линка, в зависимости от типа используемого размера фрейма.
    3. Увеличение TCP Throughput при изменении размера MTU — staff.psc.edu/rreddy/networking/mtu.html


    Рис. 7

    Есть у этой медали и обратная сторона:
    1. Чем больше фрейм, тем дольше он будет передаваться (Рис. 8):
    2. Буферы в памяти сетевых устройств заполняются быстрее, что может вызвать нежелательные последствия. По сути, решаемо на стадии проектирования оборудования, но увеличивает стоимость.
    3. Проприетарная реализация у каждого производителя – все устройства должны поддерживать или одинаковые размеры Jumbo фрейма, или же наборы размеров.
    4. Использование на больших участках сети находящихся под разным административным контролем, по сути, невозможно, из-за отсутствия механизма Jumbo Frame Discovery – промежуточный узел может не поддерживать Jumbo Frame совсем или определенный размер.


    Рис.8

    В сумме, плюсы и минусы использования Jumbo фреймов дают нам недвусмысленное указание, где мы можем использовать такой размер фрейма. И так, в каких же приложениях в датацентре мы можем использовать Jumbo Frame к всеобщей выгоде? Выходит такой примерно список (дополнения приветствуются):
    • В серверных кластерах
    • При бэкапировании
    • Network File System (NFS) Protocol
    • iSCSI SANs
    • FCoE SANs


    Замечание: Верхнее ограничение размера есть и у Jumbo MTU. Оно определяется размером поля FCS (4 байт) и алгоритмом Cyclic Redundancy Check и равняется 11 455 байт. На практике же, Jumbo MTU обычно ограничен размером в 9216 байт, на некоторых платформах в 9000 байт, на более старом железе в 8092 байт (речь о Cisco).

    Фух, в принципе всё. Что хотел рассмотреть по теории, рассмотрели. По конфигурации размеров MTU и теории с финтами стоящими за этими тремя буквами, прошу в мою прошлую статью – «Maximum Transmission Unit (MTU). Мифы и рифы».

    В заключение обещанный линк на отчёт Alteon Networks «Extended Frame Sizes for Next Generation Ethernets» — staff.psc.edu/mathis/MTU/AlteonExtendedFrames_W0601.pdf, и небольшой анонс на следующую статью – в ней мы падём ещё ниже — на физический уровень, и будем разбираться с тяжелым наследием CSMA/CD, энкодингами, и, походя, зацепим ещё чего из злободневного.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 22
    • +4
      Стиль бодрый, автор молодец!
      • 0
        «SA (Source Address) – MAC адрес отправителя. Всегда юникаст.» — может, «всегда должен быть юникаст»?
        • 0
          Мой вариант вполне допустим. А вот конструкция с «должен быть», в данном контексте, звучит как машинный перевод с английского.
          • 0
            Хм. Возможно. Но учитывая, что в сеть можно отправить любую ересь, это хороший вопрос «Всегда юникаст» и «Должен быть юникаст». Потому как при «всегда юникаст» кто-то может начать рассчитывать на это зазря.
            • +1
              Понятно, что можно сделать cat /dev/urandom > /dev/eth0. Но мы рассматриваем стандартный заголовок, ИМХО не стоит зря утяжелять текст конструкциями с «должен быть».
            • 0
              увы, но нет.

              Есть разница между «всегда юникаст, потому что протокол устроен так, что другого не сунешь» и «всегда юникаст, потому что туда всегда пишут юникаст и если засунуть мультикаст, то непонятно как интерпретировать»
          • 0
            Может я промаргал, но есть ли в Ethernet коды ИСПРАВЛЯЮЩИЕ ошибки или только FCS, которое, как я правильно понял автора, лишь ОБНАРУЖИВАЮТ ошибки, но не исправляют их.

            Если нет, то получается надёжность и скорость Ethernet каналов такова, что дешевле переслать кадр, чем заниматься ECC кодированием.
            • +1
              Это общее явление во всех системах связи. Дело в том, что любой код, работающий в режиме обнаружения ошибок, является примерно в два раза более устойчивым к этим самым ошибкам, чем он же, но работающий в режиме коррекции.

              Так, код Хемминга способен скорректировать всего одну ошибку — но если отказаться от коррекции, то он сможет обнаружить две. Если же использовать модификацию, способную обнаруживать парные ошибки — то в режиме чистого обнаружения она сможет обнаружить тройные ошибки.

              Как следствие, при достаточной надежности канала связи получается куда дешевле повторно отправлять битые пакеты, чем корректировать их.
            • 0
              Мне всегда было любопытно, можно ли гонять 802.1q (это Ethernet II фрейм в котором EtherType=0x8100) c проставленными VLAN ID=1 и что будет с такими фреймами?
              • 0
                Конечно можно, они ничем не отличаются от фреймов с любым другим vlan id. Native vlan на порту может быть какой угодно, не обязательно 1. Кроме того, команда «vlan dot1q tag native» включает тегирование всех фреймов на транковых портах.
                • 0
                  Можно, я сам их гонял на лабораторной работе. Вот с VLAN 0 ситуация хуже — у половины коммутаторов такой VLAN является служебным, означая отсутствие тэга, а у другой половины он является вполне рабочим.

                  (Под «половиной» коммутаторов я понимаю три из шести находящихся в лаборатории сетевых технологий кафедры ЭВМ ЮУрГУ)
                  • 0
                    Собственно, а почему бы и нет? Главное, чтобы коммутатор переваривал vlan 1 в качестве trunk на порту.
                    С dot1q обычно другая картина — его пытаются пропихнуть в обычный access-порт с задранным mtu. Вот тут уже интересней
                  • 0
                    iSCSI и FCoE понятно. А что такое NSF?
                    • 0
                      Спасибо, что указали. Поправил.
                      • –1
                        Видимо, не везде поправили :-)
                    • +1
                      А что такое SFD, которое отделилось от Preamble, начиная с рисунка 2?
                      • 0
                        Start of Frame Delimiter. Добавлю к тексту с расшифровкой.
                      • 0
                        На практике же Jumbo фрейм обычно ограничен размером в 9126 байт (на более старом железе в 8092 байт).

                        Ни разу не встречал 9126 — это особенность Cisco? А как же 9014 и 16128? Последние уже даже в datasheet'ах пишут к PHY микросхемам.
                        • +1
                          Опс, 9216 байт, и не Jumbo фрейм, а Jumbo MTU — исправлю в тексте. Да, это у Cisco, встречал ещё у них jumbo MTU ровно 9000, которые и дадут размер фрейма в 9014. 16128 не встречал. Сейчас погуглил и увидел, что Интеловские карточки поддерживают. Попробую выяснить как обходится ограничение с CRC, и добавлю к топику.
                          • +1
                            ну после 11 455 байт просто увеличивается вероятность не детектируемой ошибки. Предполагается, что передаваемые данные, в случае искажения, будут исправлены вышестоящими протоколами.
                        • 0
                          "… или же с рукавом, который можно использовать для оптимизации женской анатомии. "
                          Смеялсо очень, хотя, вроде бы банальность. Не часто такие перлы в технических статьях встретишь. Вкупе с доступностью изложения это меня покорило.

                          Как там говорили, в лихие нулевые… Афтар, пешы исчо.
                          • 0
                            Было любопытно, приобретая современную сетевую карту, какой стандарт она будет использовать для отправки кадров? Примет ли она ответный кадр в любом стандарте?

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.