0,0
рейтинг
26 июня 2014 в 16:18

Администрирование → Всё, что вы хотели знать о 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, энкодингами, и, походя, зацепим ещё чего из злободневного.
Алексей Стыценко @mongolio
карма
37,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (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
    Было любопытно, приобретая современную сетевую карту, какой стандарт она будет использовать для отправки кадров? Примет ли она ответный кадр в любом стандарте?

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