Каков максимальный размер кадра ethernet собираемого компьютером для отправки по сети
Уровень MAC стандарта Gigabit Ethernet использует тот же самый протокол передачи CSMA/CD что и его предки Ethernet и Fast Ethernet. Основные ограничения на максимальную длину сегмента (или коллизионного домена) определяются этим протоколом.
В Fast Ethernet был оставлен такой же минимальный размер кадра, как в Ethernet. Это сохранило совместимость, но привело к значительному уменьшению диаметра коллизионного домена.
Опять же в силу преемственности стандарт Gigabit Ethernet должен поддерживать те же минимальный и максимальный размеры кадра, которые приняты в Ethernet и Fast Ethernet. Но поскольку скорость передачи возрастает, то соответственно уменьшается и время передачи пакета аналогичной длины. При сохранении прежней минимальной длины кадра это привело бы к уменьшению диаметра сети, который не превышал бы 20 метров, что могло быть мало полезным. Поэтому, при разработке стандарта Gigabit Ethernet было принято решение увеличить время канала. В Gigabit Ethernet оно составляет 4096 BT и в 8 раз превосходит время канала Ethernet и Fast Ethernet. Но, чтобы поддержать совместимость со стандартами Ethernet и Fast Ethernet, минимальный размер кадра не был увеличен, а было добавлено к кадру дополнительное поле, получившее название «расширение носителя».
Расширение носителя (carrier extension)
Символы в дополнительном поле обычно не несут служебной информации, но они заполняют канал и увеличивают «коллизионное окно». В результате, коллизия будет регистрироваться всеми станциями при большем диаметре коллизионного домена.
Кадр Gigabit Ethernet с полем расширения носителя
Пакетная перегруженность (Packet Bursting)
Пакетная перегруженность: а) передача кадров; б) поведение полосы пропускания
Как максимальной единицей передачи информации в интернете стали 1500 байт
Ethernet повсюду, и десятки тысяч производителей выпускают оборудование с его поддержкой. Однако почти у всех этих устройств есть одно общее число – MTU:
MTU (Maximum Transmission Unit) [максимальная единица передачи] определяет максимальный размер отдельного пакета данных. В общем случае, когда вы обмениваетесь сообщениями с устройствами вашей LAN, MTU будет иметь размер порядка 1500 байт, а весь интернет почти целиком тоже работает с размером 1500 Б. Однако это не означает, что эти технологии связи не могут передавать пакетов большего размера.
К примеру, у 802.11 (шире известного как WiFi) MTU равен 2304 б, а если ваша сеть использует FDDI, тогда ваш MTU равен 4352 б. У самого Ethernet есть концепция «гигантских кадров», когда MTU можно назначить размер до 9000 б (при поддержке такого режима NIC, коммутаторами и роутерами).
Однако в интернете это не особенно нужно. Поскольку основные магистрали интернета в основном состоят из соединений Ethernet, де-факто неофициальный максимальный размер пакета выставлен в 1500 Б, чтобы избежать фрагментации пакетов на других устройствах.
Само по себе число 1500 странное – можно было бы ожидать, что константы в мире компьютеров будут основаны на степенях двойки, например. Так откуда взялись 1500 Б и почему мы их до сих пор используем?
Волшебное число
Первый большой прорыв Ethernet в мир произошёл в форме стандартов 10BASE-2 (тонкий) и 10BASE-5 (толстый), числа в которых говорят о том, сколько сотен метров может покрывать отдельный сегмент сети.
Поскольку в то время конкурирующих протоколов было множество, а у железа имелись свои ограничения, создатель формата признаёт, что требования к памяти буфера пакетов сыграли свою роль в появлении волшебного числа 1500:
Оглядываясь назад, становится ясно, что максимум большего размера, возможно, был бы лучшим решением, однако если бы мы увеличили стоимость NIC (сетевых контроллеров) на ранних этапах, это не дало бы Ethernet так широко распространиться.
Однако это не вся история. В работе «Ethernet: распределённая коммутация пакетов в локальных компьютерных сетях» 1980 года приведён один из ранних анализов эффективности использования в сетях пакетов большого размера. В то время это было особенно важно для сетей Ethernet, поскольку те либо могли соединять все системы одним коаксиальным кабелем, либо состоять из хабов, способных в один момент времени отправлять по одному пакету для всех узлов одного сегмента.
Нужно было выбрать число, которое давало бы не слишком высокие задержки при передаче сообщений в сегментах (иногда довольно загруженных), и при этом не слишком бы увеличивало число пакетов.
Судя по всему, инженеры в то время выбрали число 1500 Б (около 12000 бит) как наиболее «безопасный» вариант.
С тех пор появлялись и исчезали различные другие системы передачи сообщений, однако среди них самое низкое значение MTU было у Ethernet с его 1500 Б. Превышать минимальное значение MTU в сети – значит, либо вызывать фрагментацию пакетов, либо заниматься PMTUD [поиск максимального размера пакета для выбранного пути]. У обоих вариантов были свои особые проблемы. Даже если иногда крупные производители ОС опускали значение MTU ещё ниже.
Фактор эффективности
Теперь нам известно, что MTU в интернете ограничен размером в 1500 Б по большей части из-за старых показателей задержек и ограничений оборудования. Насколько сильно это сказывается на эффективности интернета?
Если посмотреть на данные с крупной точки обмена интернет-трафиком AMS-IX, мы увидим, что не менее 20% передаваемых пакетов имеют максимальный размер. Можно также посмотреть на общий трафик LAN:
Если скомбинировать оба графика, получится что-то вроде следующего (оценка трафика для каждого диапазона размеров пакетов):
Или, если посмотреть на трафик всех этих заголовков и прочей служебной информации, мы получим тот же график с другим масштабом:
Довольно большая часть пропускной способности тратится на заголовки для пакетов из самого крупного класса размеров. Поскольку на пике трафика наибольшие накладные расходы составляют 246 Гб/с, можно предположить, что если бы мы все перешли на «гигантские кадры», когда такая возможность ещё существовала, эти накладные расходы составляли бы всего около 41 Гб/с.
Но, думаю, сегодня для крупнейшей части интернета этот поезд уже ушёл. И хотя некоторые провайдеры работают с MTU равным 9000, большая часть его не поддерживает, а попытки изменить что-то глобально в интернете раз от раза оказывались чрезвычайно трудным делом.
Буквально несколько дней здесь был задан вопрос на тему размера кадра в Ethernet. Вопрос был задан дилетантски, больше походил на copy-paste из какого-то сборника задач, получил несколько жалоб, и модераторы его снесли. Однако я успел оставить довольно широкий ответ. Чтобы мой ответ и время, потраченное на него, не пропадали в пустую, я сделаю копию того вопроса, и сам напишу к нему ответ.
Собственно сам вопрос: откуда взялся минимальный размер Ethernet-кадра?
Эксперты приглашаются к обсуждению)
Минимальное значение фрейма для обычного Ethernet равно 64 байта. Это известная вещь. Но вокруг этого образовалось множество легенд и домыслов.
Это прямая пропорция к размеру пакета и обратная к скорости распространения сигнала: чем больше размер кадра, тем больше дистанция, чем больше пропускная способность, тем меньше дистанция. Это чисто математическая формула, естественно, дальше она ограничивается физикой распространения сигнала.
Теперь как это было реализовано. Формат кадра для 10/100М Ethernet представляет следующий вид:
Pad-добиваем нулями до минимального размера кадра. Делается это на MAC-уровне (читай, на L2, привет, модель OSI).
А для 1000Base-T уже добавляем еще и поле Carier Extension. Причем из интересного, в отличие от Pad Field, оно уже забивается не нулями, а специальной последовательностью символов, генерирующихся на PHY уровне (опять привет, модель OSI).
А для 1000Base-T уже добавляем еще и поле Carier Extension. Причем из интересного, в отличие от Pad Field, оно уже забивается не нулями, а специальной последовательностью символов, генерирующихся на PHY уровне (опять привет, модель OSI).
Если не знаешь ответов на эти вопросы, а читать стандарты и серьезную литературу по теме лень — прошу под кат.
Кто-то считает, что это очевидные вещи, другие скажут, что скучная и ненужная теория. Тем не менее на собеседованиях периодически можно услышать подобные вопросы. Мое мнение: о том, о чем ниже пойдет речь, нужно знать всем, кому приходится брать в руки «обжимку» 8P8C (этот разъем обычно ошибочно называют RJ-45). На академическую глубину не претендую, воздержусь от формул и таблиц, так же за бортом оставим линейное кодирование. Речь пойдет в основном о медных проводах, не об оптике, т.к. они шире распространены в быту.
Технология Ethernet описывает сразу два нижних уровня модели OSI. Физический и канальный. Дальше будем говорить только о физическом, т.е. о том, как передаются биты между двумя соседними устройствами.
Технология Ethernet — часть богатого наследия исследовательского центра Xerox PARC. Ранние версии Ethernet использовали в качестве среды передачи коаксиальный кабель, но со временем он был полностью вытеснен оптоволокном и витой парой. Однако важно понимать, что применение коаксиального кабеля во многом определило принципы работы Ethernet. Дело в том, что коаксиальный кабель — разделяемая среда передачи. Важная особенность разделяемой среды: ее могут использовать одновременно несколько интерфейсов, но передавать в каждый момент времени должен только один. С помощью коаксиального кабеля можно соединит не только 2 компьютера между собой, но и более двух, без применения активного оборудования. Такая топология называется шина. Однако если хотябы два узла на одной шине начнут одновременно передавать информацию, то их сигналы наложатся друг на друга и приемники других узлов ничего не разберут. Такая ситуация называется коллизией, а часть сети, узлы в которой конкурируют за общую среду передачи — доменом коллизий. Для того чтоб распознать коллизию, передающий узел постоянно наблюдает за сигналов в среде и если собственный передаваемый сигнал отличается от наблюдаемого — фиксируется коллизия. В этом случае все узлы перестают передавать и возобновляют передачу через случайный промежуток времени.
Диаметр коллизионного домена и минимальный размер кадра
Теперь давайте представим, что будет, если в сети, изображенной на рисунке, узлы A и С одновременно начнут передачу, но успеют ее закончить раньше, чем примут сигнал друг друга. Это возможно, при достаточно коротком передаваемом сообщении и достаточно длинном кабеле, ведь как нам известно из школьной программы, скорость распространения любых сигналов в лучшем случае составляет C=3*10 8 м/с. Т.к. каждый из передающих узлов примет встречный сигнал только после того, как уже закончит передавать свое сообщение — факт того, что произошла коллизия не будет установлен ни одним из них, а значит повторной передачи кадров не будет. Зато узел B на входе получит сумму сигналов и не сможет корректно принять ни один из них. Для того, чтоб такой ситуации не произошло необходимо ограничить размер домена коллизий и минимальный размер кадра. Не трудно догадаться, что эти величины прямо пропорциональны друг другу. В случае же если объем передаваемой информации не дотягивает до минимального кадра, то его увеличивают за счет специального поля pad, название которого можно перевести как заполнитель.
Таким образом чем больше потенциальный размер сегмента сети, тем больше накладных расходов уходит на передачу порций данных маленького размера. Разработчикам технологии Ethernet пришлось искать золотую середину между двумя этими параметрами, и минимальным размером кадра была установлена величина 64 байта.
Витая пара и дуплексный режим рабты
Витая пара в качестве среды передачи отличается от коаксиального кабеля тем, что может соединять только два узла и использует разделенные среды для передачи информации в разных направлениях. Одна пара используется для передачи (1,2 контакты, как правило оранжевый и бело-оранжевый провода) и одна пара для приема (3,6 контакты, как правило зеленый и бело-зеленый провода). На активном сетевом оборудовании наоборот. Не трудно заметить, что пропущена центральная пара контактов: 4, 5. Эту пару специально оставили свободной, если в ту же розетку вставить RJ11, то он займет как раз свободные контакты. Таким образом можно использовать один кабели и одну розетку, для LAN и, например, телефона. Пары в кабеле выбраны таким образом, чтоб свести к минимуму взаимное влияние сигналов друг на друга и улучшить качество связи. Провода одной пару свиты между собой для того, чтоб влияние внешних помех на оба провода в паре было примерно одинаковым. Для соединения двух однотипных устройств, к примеру двух компьютеров, используется так называемый кроссовер-кабель(crossover), в котором одна пара соединяет контакты 1,2 одной стороны и 3,6 другой, а вторая наоборот: 3,6 контакты одной стороны и 1,2 другой. Это нужно для того, чтоб соединить приемник с передатчиком, если использовать прямой кабель, то получится приемник-приемник, передатчик-передатчик. Хотя сейчас это имеет значение только если работать с каким-то архаичным оборудованием, т.к. почти всё современное оборудование поддерживает Auto-MDIX — технология позволяющая интерфейсу автоматически определять на какой паре прием, а на какой передача.
Возникает вопрос: откуда берется ограничение на длину сегмента у Ethernet по витой паре, если нет разделяемой среды? Всё дело в том, первые сети построенные на витой паре использовали концентраторы. Концентратор (иначе говоря многовходовый повторитель) — устройство имеющее несколько портов Ethernet и транслирующее полученный пакет во все порты кроме того, с которого этот пакет пришел. Таким образом если концентратор начинал принимать сигналы сразу с двух портов, то он не знал, что транслировать в остальные порты, это была коллизия. То же касалось и первых Ethernet-сетей использующих оптику (10Base-FL).
Зачем же тогда использовать 4х-парный кабель, если из 4х пар используются только две? Резонный вопрос, и вот несколько причин для того, чтобы делать это:
Не смотря на это на практике часто используют 2х-парный кабель, подключают сразу 2 компьютера по одному 4х-парному, либо используют свободные пары для подключения телефона.
Gigabit Ethernet
В отличии от своих предшественников Gigabit Ethernet всегда использует для передачи одновременно все 4 пары. Причем сразу в двух направлениях. Кроме того информация кодируется не двумя уровнями как обычно (0 и 1), а четырьмя (00,01,10,11). Т.е. уровень напряжения в каждый конкретный момент кодирует не один, а сразу два бита. Это сделано для того, чтоб снизить частоту модуляции с 250 МГц до 125 МГц. Кроме того добавлен пятый уровень, для создания избыточности кода. Он делает возможной коррекцию ошибок на приеме. Такой вид кодирования называется пятиуровневым импульсно-амплитудным кодированием (PAM-5). Кроме того, для того, чтоб использовать все пары одновременно для приема и передачи сетевой адаптер вычитает из общего сигнала собственный переданный сигнал, чтоб получить сигнал переданный другой стороной. Таким образом реализуется полнодуплексный режим по одному каналу.
Дальше — больше
10 Gigabit Ethernet уже во всю используется провайдерами, но в SOHO сегменте не применяется, т.к. судя по всему там вполне хватает Gigabit Ethernet. 10GBE качестве среды распространения использует одно- и многомодовое волокно, с или без уплотнением по длине волны, медные кабели с разъемом InfiniBand а так же витую пару в стандарте 10GBASE-T или IEEE 802.3an-2006.
40-гигабитный Ethernet (или 40GbE) и 100-гигабитный Ethernet (или 100GbE). Разработка этих стандартов была закончена в июле 2010 года. В настоящий момент ведущие производители сетевого оборудования, такие как Cisco, Juniper Networks и Huawei уже заняты разработкой и выпуском первых маршрутизаторов поддерживающих эти технологии.
В заключении стоит упомянуть о перспективной технологии Terabit Ethernet. Боб Меткалф, создатель предположил, что технология будет разработана к 2015 году, и так же сказал:
Чтобы реализовать Ethernet 1 ТБит/с, необходимо преодолеть множество ограничений, включая 1550-нанометровые лазеры и модуляцию с частотой 15 ГГц. Для будущей сети нужны новые схемы модуляции, а также новое оптоволокно, новые лазеры, в общем, все новое
UPD: Спасибо хабраюзеру Nickel3000, что подсказал, про то что разъем, который я всю жизнь называл RJ45 на самом деле 8P8C. UPD2:: Спасибо пользователю Wott, что объяснил, почему используются контакты 1,2,3 и 6.
Всё, что вы хотели знать о 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. Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.
Замечание: Фреймы меньше 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 заголовков.
Все эти фреймы увеличенного размера группируются под одни именем – 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.
Замечание: Верхнее ограничение размера есть и у Jumbo MTU. Оно определяется размером поля FCS (4 байт) и алгоритмом Cyclic Redundancy Check и равняется 11 455 байт. На практике же, Jumbo MTU обычно ограничен размером в 9216 байт, на некоторых платформах в 9000 байт, на более старом железе в 8092 байт (речь о Cisco).
Фух, в принципе всё. Что хотел рассмотреть по теории, рассмотрели. По конфигурации размеров MTU и теории с финтами стоящими за этими тремя буквами, прошу в мою прошлую статью – «Maximum Transmission Unit (MTU). Мифы и рифы».
