Какую информацию содержит поле управления в пакете ethernet fast ethernet

Обновлено: 07.07.2024

В сети Fast Ethernet не предусмотрена физическая топология "шина", используется только "пассивная звезда" или "пассивное дерево". К тому же в Fast Ethernet гораздо более жесткие требования к предельной длине сети. Ведь при увеличении в 10 раз скорости передачи и сохранении формата пакета его минимальная длина становится в десять раз короче (5.12 икс против 51.2 мкс в Ethernet). Допустимая величина двойного времени прохождения сигнала по сети уменьшается в 10 раз.

Для передачи информации в сети Ethernet применяется стандартный код Манчестер-П. При этом один уровень сигнала нулевой, а другой – отрицательный, то есть постоянная составляющая сигнала не равна нулю. При отсутствии передачи потенциал в сети нулевой. Гальваническая развязка осуществляется аппаратурой адаптеров, репитеров и концентраторов. При этом приемопередатчик сети гальванически развязан от остальной аппаратуры с помощью трансформаторов и изолированного источника питания, а с кабелем сети соединен напрямую.

Рис. 5.2. Структура пакета сети Ethernet, (цифры показывают количество байт)

Доступ к сети Ethernet осуществляется по случайному методу CSMA/ CD, обеспечивающему полное равноправие абонентов. В сети используются пакеты переменной длины со структурой, представленной на рис. 5.2. Длина кадра Ethernet (то есть пакета без преамбулы) должна быть не менее 512 битовых интервалов, или 51.2 мкс (именно такова предельная величина двойного времени прохождения в сети). Предусмотрена индивидуальная, групповая и широковещательная адресация.

В пакет Ethernet входят следующие поля:

Преамбула состоит из 8 байт, первые семь из которых представляют собой код 10101010, а последний восьмой – код 10101011. В стандарте IEEE 802.3 этот последний байт называется признаком начала кадра (SFD – Start of Frame Delimiter) и образует отдельное поле пакета.
Адрес получателя (приемника) и адрес отправителя (передатчика) включают по 6 байт и строятся по стандарту, описанному в разделе 3.2. Эти адресные поля обрабатываются аппаратурой абонентов.
Поле управления (L/T – Length/Type) содержит информацию о длине поля данных. Оно может также определять тип используемого протокола. Принято считать, что если значение этого поля не больше 1500, то оно определяет длину поля данных. Если же его значение больше 1500, то оно определяет тип кадра. Поле управления обрабатывается программно.
Поле данных должно включать в себя от 46 до 1500 байт данных. Если пакет должен содержать менее 46 байт данных, то поле данных дополняется байтами заполнения. Согласно стандарту IEEE 802.3, в структуре пакета выделяется специальное поле заполнения (pad data – незначащие данные), которое может иметь нулевую длину, когда данных достаточно (больше 46 байт).
Поле контрольной суммы (FCS – Frame Check Sequence) содержит 32-разрядную циклическую контрольную сумму пакета (CRC) и служит для проверки правильности передачи пакета.

Таким образом, минимальная длина кадра (пакета без преамбулы) составляет 64 байта (512 бит). Именно эта величина определяет максимально допустимую двойную задержку распространения сигнала по сети в 512 битовых интервалов (51.2 мкс для Ethernet, 5.12 мкс для Fast Ethernet). Стандарт предполагает, что преамбула может уменьшаться при прохождении пакета через различные сетевые устройства, поэтому она не учитывается. Максимальная длина кадра равна 1518 байтам (12144 бита, то есть 1214.4 мкс для Ethernet, 121.44 мкс для Fast Ethernet). Это важно для выбора размера буферной памяти сетевого оборудования и для оценки общей загруженности сети.

Для сети Ethernet, работающей на скорости 10 Мбит/с, стандарт определяет четыре основных типа среды передачи информации:

10BASE5 (толстый коаксиальный кабель);
10 BASE2 (тонкий коаксиальный кабель);
1OBASE-T (витая пара);
10BASE-FL (оптоволоконный кабель).

Обозначение среды передачи включает в себя три элемента: цифра "10" означает скорость передачи 10 Мбит/с, слово BASE означает передачу в основной полосе частот (то есть без модуляции высокочастотного сигнала), а последний элемент означает допустимую длину сегмента: "5" – 500 метров, "2" – 200 метров (точнее, 185 метров) или тип линии связи: "Т" – витая пара (от английского "twisted-pair"), "F" – оптоволоконный кабель (от английского "fiber optic").

Точно так же для сети Ethernet, работающей на скорости 100 Мбит/с (Fast Ethernet) стандарт определяет три типа среды передачи:

100BASE-T4 (счетверенная витая пара);
100BASE-TX (сдвоенная витая пара);
100BASE-FX (оптоволоконный кабель).

Здесь цифра "100" означает скорость передачи 100 Мбит/с, буква "Т" означает витую пару, буква "F" – оптоволоконный кабель. Типы 1OOBASE-ТХ и 100BASE-FX иногда объединяют под именем 100BASE-X, а 100BASE-T4 и 100BASE-TX – под именем 100BASE-T.

Подробнее особенности аппаратуры Ethernet, а также алгоритма управления обменом CSMA/CD и алгоритма вычисления циклической контрольной суммы (CRC) будут рассмотрены далее в специальных разделах книги. Здесь же мы только отметим, что сеть Ethernet не отличается ни рекордными характеристиками, ни оптимальными алгоритмами, она уступает по ряду параметров другим стандартным сетям. Но благодаря мощной поддержке, высочайшему уровню стандартизации, огромным объемам выпуска технических средств, Ethernet резко выделяется среди других стандартных сетей, и поэтому любую другую сетевую технологию принято сравнивать именно с Ethernet.

Таким образом, получается, что метод CSMA /CD не только не предотвращает коллизии , наоборот, он их предполагает и даже провоцирует, а затем разрешает. Например, если заявки на передачу возникли у нескольких абонентов во время занятости сети, то после ее освобождения все эти абоненты одновременно начнут передачу и образуют коллизию . Коллизии появляются и в случае свободной сети, если заявки на передачу возникают у нескольких абонентов одновременно. В обоих случаях под словом "одновременно" понимается "в пределах интервала двойного прохождения сигнала по сети", то есть в пределах 512-битовых интервалов. Точно так же в пределах 512-битовых интервалов обнаруживаются все коллизии в сети.

Если коллизия обнаруживается раньше 480 – битового интервала, то в результате в сети образуются пакеты, длина которых меньше нижнего установленного предела в 512 – битовых интервалов (64 байта) даже с добавлением сигнала ПРОБКА. Такие пакеты (кадры) называются карликовыми (runt frames). Если же коллизия обнаруживается в конце 512-битового интервала (после 480 – битового интервала), то в результате может получиться пакет допустимой длины (вместе с сигналом ПРОБКА). Такие пакеты называть карликовыми не совсем корректно. Сигнал ПРОБКА, образующий 32 последних бита пакета, выступает в виде контрольной суммы пакета. Однако вероятность того, что ПРОБКА будет соответствовать правильной контрольной сумме пакета, бесконечно мала (примерно 1 случай на 4,2 миллиарда).

Коллизии (наложения пакетов в процессе передачи) могут и должны обнаруживаться до окончания передачи. Действительно, анализ принятого в конце каждого пакета поля FCS , фактически содержащего помехоустойчивый циклический код CRC ( Cyclic Redundancy Check ), привел бы к неоправданному снижению скорости передачи.

Практически коллизии обнаруживаются либо самим передающим абонентом, либо повторителями в сети, возможно, задолго до окончания передачи заведомо испорченного пакета. Если учесть, что длина пакетов в локальной сети типа Ethernet / Fast Ethernet может лежать в диапазоне от 64 до 1518 байт, то досрочное прекращение передачи и освобождение линии означает заметное повышение эффективности использования ее пропускной способности.

Первым признаком возникновения коллизии является факт получения сигнала ПРОБКА передающим абонентом во время передачи пакета. Другие признаки связаны с неверным форматом пакетов , передача которых была досрочно прекращена из-за возникновения коллизии :

длина пакета меньше 64 байт (512 бит);
пакет имеет неверную контрольную сумму FCS (точнее, неверный циклический код );
длина пакета не кратна восьми.

Наконец, в таких сетях как Ethernet используется код Манчестер-II и аппаратный способ определения коллизии , основанный на анализе отклонения среднего значения сигнала от нуля.

Даже при загруженной сети для одного абонента число подряд следующих коллизий обычно не превышает 3. Этому способствует случайный характер возникновения запроса на передачу и случайная дискретная величина отсрочки следующей попытки передачи при возникновении коллизии . Число коллизий тем больше, чем больше диаметр (размер) сегмента и чем дальше расположены друг от друга абоненты с интенсивным трафиком.

Оценка производительности сети

Вопрос об оценке производительности сетей, использующих случайный метод доступа CSMA /CD, не очевиден из-за того, что существуют несколько различных показателей. Прежде всего, следует упомянуть три связанные между собой показателя, характеризующие производительность сети в идеальном случае – при отсутствии коллизий и при передаче непрерывного потока пакетов, разделенных только межпакетным интервалом IPG . Очевидно, такой режим реализуется, если один из абонентов активен и передает пакеты с максимально возможной скоростью. Неполное использование пропускной способности в этом случае связано, кроме существования интервала IPG , с наличием служебных полей в пакете Ethernet (см. рис. 10.2).

Пакет максимальной длины является наименее избыточным по относительной доле служебной информации. Он содержит 12304 бит (включая интервал IPG ), из которых 12000 являются полезными данными.

Поэтому максимальная скорость передачи пакетов (или, иначе, скорость в кабеле – wire speed) составит в случае сети Fast Ethernet

$10^<8></p> \ бит/с/ \ 12304 бит \approx 8127,44 \ пакет/с.$

Пропускная способность представляет собой скорость передачи полезной информации и в данном случае будет равна

$8127,44 \ пакет/с \times 1500 \ байта \approx 12,2 \ Мбайт/с.$

Наконец, эффективность использования физической скорости передачи сети, в случае Fast Ethernet равной 100 Мбит/с, по отношению только к полезным данным составит

$8127,44 \ пакет/с \times 12000 \ бит/ 10^<8></p> \ бит/с \approx 98\%.$

При передаче пакетов минимальной длины существенно возрастает скорость в кабеле, что означает всего лишь факт передачи большого числа коротких пакетов. В то же время пропускная способность и эффективность заметно (почти в два раза) ухудшаются из-за возрастания относительной доли служебной информации.

Для реальных сетей, в частности Fast Ethernet с большим числом активных абонентов N пропускная способность на уровне 12,2 Мбайт/с для какого-либо абонента является пиковым, редко реализуемым значением. При одинаковой активности всех абонентов средняя пропускная способность для каждого из них составит 12,2/N Мбайт/с, а на самом деле может оказаться еще меньше из-за возникновения коллизий , ошибок в работе сетевого оборудования и влияния помех (в случае работы локальной сети в условиях, когда кабельная система подвержена влиянию больших внешних электромагнитных наводок). Влияние помех, так же как и поздних конфликтов (late collision ) в некорректных сетях, отслеживается с помощью анализа поля FCS пакета.

Для реальных сетей более информативен такой показатель производительности, как показатель использования сети (network utilization), который представляет собой долю в процентах от суммарной пропускной способности (не поделенной между отдельными абонентами). Он учитывает коллизии и другие факторы. Ни сервер, ни рабочие станции не содержат средств для определения показателя использования сети , этой цели служат специальные, не всегда доступные из-за высокой стоимости такие аппаратно-программные средства, как анализаторы протоколов .

Считается, что для загруженных систем Ethernet и Fast Ethernet хорошим значением показателя использования сети является 30%. Это значение соответствует отсутствию длительных простоев в работе сети и обеспечивает достаточный запас в случае пикового повышения нагрузки. Однако если показатель использования сети значительное время составляет 80. 90% и более, то это свидетельствует о практически полностью используемых (в данное время) ресурсах, но не оставляет резерва на будущее. Впрочем, для реальных сетей, к примеру Fast Ethernet, это скорее гипотетическая ситуация.

На рис. 10.2 приведена зависимость показателя использования сети от времени при условии, что предложенная нагрузка ( offered load), то есть текущий запрос на пропускную способность, линейно возрастает. Сначала показатель использования сети также линейно повышается, но затем конкуренция за владение средой передачи порождает коллизии , и рассматриваемый показатель достигает максимума (точка полной нагрузки на графике). При дальнейшем увеличении предложенной нагрузки показатель использования сети начинает уменьшаться, особенно резко после точки насыщения. Это "плохая" область работы сети. Считается, что сеть работает хорошо, если и предложенная нагрузка, и показатель использования сети высоки.

Рис. 10.2. Зависимость показателя использования сети от времени при линейном увеличении предложенной нагрузки (1 – наилучшая область работы, 2 – приемлемая, 3 – плохая)

Некоторые авторы предлагают для широко распространенного понятия "перегрузка" ( overload ) сетей на основе метода доступа CSMA /CD следующее определение: сеть перегружена, если она не может работать при полной нагрузке в течение 80% своего времени (при этом 20% времени показатель использования сети недопустимо мал из-за коллизий ). После точки насыщения наступает крах Ethernet (Ethernet collapse ), когда возрастающая предложенная нагрузка заметно превышает возможности сети. Стоит заметить, что реально маловероятно, чтобы предложенная нагрузка постоянно увеличивалась во времени и надолго превышала пропускную способность сети типа Fast Ethernet. Более того, любой детерминированный метод доступа не может обеспечить реализацию сколь угодно большой предложенной нагрузки, существующей продолжительное время. Если данный вариант детерминированного метода доступа не использует, как и метод CSMA /CD, систему приоритетов, то никакой из абонентов не может захватить сеть более чем на время передачи одного пакета, однако передача данных отдельными пакетами с долгими паузами между ними ведет к снижению скорости передачи для каждого абонента. Преимущество детерминированных методов состоит в возможности простой организации системы приоритетов, что полезно из-за наличия определенной иерархии в любом крупном коллективе.

Статья получилась довольно объёмная, рассмотренные темы — форматы 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 адрес отправителя. Всегда юникаст.

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). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

Не давая себе передышки, в 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.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

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

Замечание: Фреймы меньше 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 заголовков.

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.

Выгода соотношения Payload к заголовкам. Чем больше это соотношение, тем эффективней мы можем использовать линии связи. Конечно здесь разрыв будет не такой как в сравнении с использованием пакетов в 64 байт и 1518 байт для TCP сессий. Но свои 3-8 процентов, в зависимости от типа трафика выиграть можно.
Значительно меньшее количество заголовков генерирует меньшую нагрузку на Forwading Engine, также и на сервисные Engine. К примеру, frame rate для 10G линка загруженного фреймами по 1500 байт равен 812 744 фреймов в секунду, а тот же линк загруженный Jumbo фреймами в 9000 байт генерирует фрейм рейт всего лишь в 138 587 фрейм в секунду. На рисунке 7 приведены график из отчёта Alteon Networks (ссылка будет внизу статьи) утилизации CPU и гигабитного линка, в зависимости от типа используемого размера фрейма.
Увеличение TCP Throughput при изменении размера MTU — staff.psc.edu/rreddy/networking/mtu.html

Чем больше фрейм, тем дольше он будет передаваться (Рис. 8):
Буферы в памяти сетевых устройств заполняются быстрее, что может вызвать нежелательные последствия. По сути, решаемо на стадии проектирования оборудования, но увеличивает стоимость.
Проприетарная реализация у каждого производителя – все устройства должны поддерживать или одинаковые размеры Jumbo фрейма, или же наборы размеров.
Использование на больших участках сети находящихся под разным административным контролем, по сути, невозможно, из-за отсутствия механизма Jumbo Frame Discovery – промежуточный узел может не поддерживать 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). Мифы и рифы».