Всё, что вы хотели знать о 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, энкодингами, и, походя, зацепим ещё чего из злободневного.
    Share post

    Similar posts

    Comments 32

      +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 и что будет с такими фреймами?
              • UFO just landed and posted this here
                  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
                          Так и не добавили…
                        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
                            Было любопытно, приобретая современную сетевую карту, какой стандарт она будет использовать для отправки кадров? Примет ли она ответный кадр в любом стандарте?
                              0
                              Интересно: если формат DIX обходится без длины кадра, то как он определяет, что кадр кончился? На сколько я помню, если вышестоящий кадр меньше 46 байт, то он будет дополнен заполнителем. Как узнать сколько такого заполнителя прилетело?
                              И ещё более интересно — если без длины можно обойтись, то зачем её впендюрили в SNAP?
                                0
                                На уровне кодирования Ethernet есть символы начала и конца кадра.
                                Заполнять кадр до 64 байт требуется от источника, т. е. если ниже это просто нестандартно и может быть не принято на стандартном оборудовании.
                                Некоторые устройства умеют принимать такие кадры.
                                  0
                                  Ну допустим — конец кадра Ethernet мы услышим (хотя «символа конца кадра» там, кажется нет). Но если в payload лежал пакет длинной 1 байт — как мы это узнаем? Он ведь был дополнен до 46. Как мы узнаем, что он был именно один?

                                  А если у нас есть способ это узнать, то зачем нужно длину выносить в отдельное поле Length?
                                    0
                                    В 100Мб Ethernet'е символы можно посмотреть здесь: JK — старт, TR — конец.
                                    Если брать формат LLC, то дополнение на поле размера не влияет, если Ethernet II, то если необходимо передавать информацию о размере данных, это обязанность вышележащего протокола.
                                      0
                                      Да, точно JK и TR это какие-то выкидыши 100BASE-X. Остальным стандартам достаточно услышать, что наступила межкадровая пауза.

                                      > если необходимо передавать информацию о размере данных, это обязанность вышележащего протокола
                                      Так и начал подозревать. Не понятно только, почему в одном случае это делегировали на уровень выше, а в другом — сами решили разбираться.
                                        0
                                        Насколько мне известно, по паузам работает только 10 мегабитный Ethernet, а последующие уже используют специальные контрольные символы.
                                        > Не понятно только, почему в одном случае это делегировали на уровень выше, а в другом — сами решили разбираться.
                                        Так вся статья про это — полустихийное формирование условий, которые потом просто увековечили в стандартах.
                                0
                                «Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP»

                                Нет. WireShark указывает, что для STP используется значение 0x42 в полях SSAP и DSAP. SNAP заголовка в пакетах он не усматривает. Если только для проприетарных реализаций.

                                Кстати, в статье не сказано, как машина отличает формат 802.3 LLC от SNAP. А всё дело в том, что xSAP заполняются магическими байтами 0xAA. Тем самым бездарно их просирая.
                                Не говоря ж и о том, что кодирование OUI в SNAP изначально избыточно, так как было придумано для множества серий MAC, принадлежащих одному производителю.
                                  0
                                  OUI нисколько не избыточно, это единственный способ формировать кадры проприетарных и тестовых протоколов, которые не пересекутся с другими.
                                    0
                                    На текущий момент за Cisco Systems зарегистрировано 935 OUI (только что подсчитал).
                                    За каждый OUI может быть закодировано 64к протоколов (PID). Итого Cisco Systems может безболезненно разработать 61,2 млн. протоколов.

                                    Всё-таки, ИМХО, это очень избыточно. Поле OUI могло бы быть сокращено на 1 байт (в каждом из триллиона пакетов ежедневно), если бы не поленились вести отдельный реестр разработчиков протоколов, где одному вендору соответствовал бы один (ну два!) кода.

                                Only users with full accounts can post comments. Log in, please.