Какую функцию выполняет поле fcs в кадре ethernet
В компьютерных сетях кадр Ethernet представляет собой блок данных протокола канального уровня и использует базовые транспортные механизмы физического уровня Ethernet . Другими словами, блок данных в канале Ethernet передает кадр Ethernet в качестве полезной нагрузки. [1]
Кадру Ethernet предшествует преамбула и разделитель начального кадра (SFD), которые являются частью пакета Ethernet на физическом уровне . Каждый кадр Ethernet начинается с заголовка Ethernet, который содержит MAC-адреса назначения и источника в качестве первых двух полей. Средняя часть фрейма — это данные полезной нагрузки, включая любые заголовки для других протоколов (например, Интернет-протокола ), переносимые в фрейме. Кадр заканчивается последовательностью проверки кадра (FCS), которая представляет собой 32-битную проверку циклическим избыточным кодом , используемую для обнаружения любого повреждения данных при передаче.
Максимальная пропускная способность
Мы можем рассчитать накладные расходы протокола для Ethernet в процентах (размер пакета, включая IPG).
Мы можем рассчитать эффективность протокола для Ethernet
Максимальная эффективность достигается при наибольшем разрешенном размере полезной нагрузки и составляет:
для нетегированных кадров, поскольку размер пакета составляет максимум 1500 октетов полезной нагрузки + 8 октетов преамбулы + 14 октетов заголовка + 4 октета трейлера + минимальный интервал между пакетами, соответствующий 12 октетам = 1538 октетов. Максимальная эффективность:
при использовании тегов 802.1Q VLAN.
Пропускная способность может быть рассчитана из эффективности
где чистая скорость передачи данных физического уровня (проводная скорость передачи данных) зависит от стандарта физического уровня Ethernet и может составлять 10 Мбит/с, 100 Мбит/с, 1 Гбит/с или 10 Гбит/с. Следовательно, максимальная пропускная способность для 100BASE-TX Ethernet составляет 97,53 Мбит/с без 802.1Q и 97,28 Мбит/с с 802.1Q.
Использование канала — понятие, которое часто путают с эффективностью протокола. Он рассматривает только использование канала, не принимая во внимание характер передаваемых данных — либо полезную нагрузку, либо служебную информацию. На физическом уровне канал связи и оборудование не различают кадры данных и кадры управления. Мы можем рассчитать использование канала :
Общее время учитывает время прохождения по каналу туда и обратно, время обработки на хостах и время передачи данных и подтверждений. Время, потраченное на передачу данных, включает данные и подтверждения.
Ethernet II
Фрейм Ethernet II (также известный как DIX Ethernet , названный в честь DEC , Intel и Xerox , основных участников его разработки [8] ), определяет двухоктетное поле EtherType в кадре Ethernet , которому предшествуют MAC-адреса назначения и источника, которые идентифицирует протокол верхнего уровня, инкапсулированный данными кадра. Например, значение EtherType 0x0800 указывает на то, что кадр содержит дейтаграмму IPv4 . Аналогично, EtherType 0x0806 указывает на кадр ARP , 0x86DD указывает на IPv6 .кадр, а 0x8100 указывает на наличие тега IEEE 802.1Q (как описано выше).
Поскольку этот промышленный стандарт прошел формальный процесс стандартизации IEEE , поле EtherType было изменено на поле длины (данных) в новом стандарте 802.3. [g] Поскольку получателю по-прежнему необходимо знать, как интерпретировать кадр, стандарт требует, чтобы заголовок IEEE 802.2 следовал за длиной и указывал тип. Много лет спустя стандарт 802.3x-1997 и более поздние версии стандарта 802.3 официально одобрили оба типа кадрирования. Кадрирование Ethernet II является наиболее распространенным в локальных сетях Ethernet из-за его простоты и меньших накладных расходов.
Чтобы некоторые кадры, использующие кадрирование Ethernet II, и некоторые кадры, использующие исходную версию кадрирования 802.3, могли использоваться в одном и том же сегменте Ethernet, значения EtherType должны быть больше или равны 1536 (0x0600). Это значение было выбрано потому, что максимальная длина поля полезной нагрузки кадра Ethernet 802.3 составляет 1500 октетов (0x05DC). Таким образом, если значение поля больше или равно 1536, кадр должен быть кадром Ethernet II, причем это поле является полем типа. [9] Если оно меньше или равно 1500, это должен быть кадр IEEE 802.3, причем это поле является полем длины. Значения между 1500 и 1536, исключая, не определены. [10] Это соглашение позволяет программному обеспечению определять, является ли кадр кадром Ethernet II или кадром IEEE 802.3, обеспечивая сосуществование обоих стандартов на одном физическом носителе.
IEEE 802.2 ООО
Некоторые протоколы, например разработанные для стека OSI , работают непосредственно поверх инкапсуляции IEEE 802.2 LLC, которая предоставляет сетевые сервисы как с установлением соединения, так и без установления соединения.
Инкапсуляция IEEE 802.2 LLC в настоящее время не получила широкого распространения в обычных сетях, за исключением крупных корпоративных установок NetWare , которые еще не перешли на NetWare over IP . В прошлом многие корпоративные сети использовали IEEE 802.2 для поддержки мостов прозрачной трансляции между сетями Ethernet и Token Ring или FDDI .
Существует интернет-стандарт для инкапсуляции трафика IPv4 в кадры IEEE 802.2 LLC SAP/SNAP. [12] Он почти никогда не реализуется в Ethernet, хотя используется в FDDI, Token Ring, IEEE 802.11 (за исключением диапазона 5,9 ГГц , где используется EtherType) [13] и других локальных сетях IEEE 802 . IPv6 также может передаваться через Ethernet с использованием IEEE 802.2 LLC SAP/SNAP, но, опять же, он почти никогда не используется.
Конец кадра — физический уровень
Конец кадра обычно обозначается символом конца потока данных на физическом уровне или потерей несущего сигнала; примером является 10BASE-T , где принимающая станция обнаруживает конец переданного кадра по потере несущей. Более поздние физические уровни используют явный конец данных или символ или последовательность конца потока , чтобы избежать двусмысленности, особенно когда несущая постоянно отправляется между кадрами; примером является Gigabit Ethernet с его схемой кодирования 8b/10b , в которой используются специальные символы, которые передаются до и после передачи кадра. [6] [7]
IEEE 802.2 SNAP
Изучив заголовок LLC 802.2, можно определить, следует ли за ним заголовок SNAP. Заголовок LLC включает в себя два восьмибитных поля адреса, которые в терминологии OSI называются точками доступа к услугам (SAP); когда для исходного и целевого SAP установлено значение 0xAA, за заголовком LLC следует заголовок SNAP. Заголовок SNAP позволяет использовать значения EtherType со всеми протоколами IEEE 802, а также поддерживает пространства идентификаторов частных протоколов.
В IEEE 802.3x-1997 стандарт IEEE Ethernet был изменен, чтобы явно разрешить использование 16-битного поля после MAC-адресов для использования в качестве поля длины или поля типа.
Набор протоколов AppleTalk v2 для Ethernet (« EtherTalk ») использует инкапсуляцию IEEE 802.2 LLC + SNAP.
Структура
Пакет данных в сети и кадр в качестве полезной нагрузки состоят из двоичных данных. Ethernet передает данные со старшим октетом (байтом) первым; однако внутри каждого октета наименее значащий бит передается первым. [а]
Внутренняя структура кадра Ethernet указана в IEEE 802.3. [1] В таблице ниже показан полный пакет Ethernet и кадр внутри в том виде, в котором он был передан, для размера полезной нагрузки до MTU 1500 октетов. [b] Некоторые реализации Gigabit Ethernet и другие высокоскоростные варианты Ethernet поддерживают более крупные кадры, известные как jumbo-кадры .
Необязательный тег 802.1Q занимает дополнительное место в кадре. Размеры полей для этой опции указаны в скобках в таблице выше. IEEE 802.1ad (Q-in-Q) позволяет использовать несколько тегов в каждом кадре. Этот вариант здесь не показан.
Пакет Ethernet – физический уровень
Преамбула и разделитель начального кадра
Кадр Ethernet внутри пакета Ethernet, где SFD отмечает конец преамбулы пакета и указывает начало кадра. [3]
Пакет Ethernet начинается с преамбулы из семи октетов и разделителя начального кадра (SFD) из одного октета . [с]
Преамбула состоит из 56-битного (семибайтового) шаблона чередующихся 1 и 0 бит, что позволяет устройствам в сети легко синхронизировать часы своих приемников, обеспечивая синхронизацию на уровне битов. За ним следует SFD, чтобы обеспечить синхронизацию на уровне байтов и пометить новый входящий кадр. Для вариантов Ethernet, передающих последовательные биты вместо более крупных символов , (некодированный) передаваемый по сети битовый шаблон для преамбулы вместе с частью SFD кадра имеет вид 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011; [3] : разделы 4.2.5 и 3.2.2 Биты передаются по порядку слева направо. [3] : разделы 4.2.5
SFD — это восьмибитное (однобайтовое) значение, которое отмечает конец преамбулы, которая является первым полем пакета Ethernet, и указывает начало кадра Ethernet. SFD предназначен для разрыва битовой комбинации преамбулы и сигнализации о начале фактического кадра. [3] : раздел 4.2.5 Сразу после SFD следует MAC-адрес назначения , который является первым полем в кадре Ethernet. SFD — это двоичная последовательность 10101011 (0xD5, десятичное число 213 в порядке первого бита LSB Ethernet). [3] : разделы 3.2.2, 3.3 и 4.2.6.
Схема приемопередатчика физического уровня (сокращенно PHY) требуется для подключения Ethernet MAC к физической среде. Соединение между PHY и MAC не зависит от физической среды и использует шину из семейства интерфейсов, независимых от среды ( MII , GMII , RGMII , SGMII , XGMII ). Микросхемы приемопередатчика Fast Ethernet используют шину MII, которая представляет собой четырехбитную (один полубайт ) шину, поэтому преамбула представлена в виде 14 экземпляров 0x5, а SFD — 0x5 0xD (в виде полубайтов). Гигабитный Ethernetчипы приемопередатчика используют шину GMII, которая представляет собой восьмибитный интерфейс, поэтому последовательность преамбулы, за которой следует SFD, будет иметь вид 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5 (в виде байтов).
Межпакетный интервал — физический уровень
Межпакетный интервал (IPG) — это время простоя между пакетами. После отправки пакета передатчики должны передать не менее 96 бит (12 октетов) состояния незанятой линии перед передачей следующего пакета.
Тип кадра | Ethertype или длина | Полезная нагрузка начинается с двух байтов |
---|---|---|
Ethernet II | ≥ 1536 | Любой |
Novell необработанный IEEE 802.3 | ≤ 1500 | 0xFFFF |
IEEE 802.2 ООО | ≤ 1500 | Другой |
IEEE 802.2 SNAP | ≤ 1500 | 0xAAAA |
Существует несколько типов кадров Ethernet:
- Кадр Ethernet II, или кадр Ethernet версии 2, [f] или кадр DIX, является наиболее распространенным типом, используемым сегодня, поскольку он часто используется непосредственно Интернет-протоколом. Нестандартный вариационный кадр NovellIEEE 802.3 Logical Link Control (LLC) Кадр протокола доступа к подсети (SNAP) IEEE 802.2
Различные типы кадров имеют разные форматы и значения MTU , но могут сосуществовать на одном и том же физическом носителе. Различие между типами кадров возможно на основе таблицы справа.
Кроме того, все четыре типа кадров Ethernet могут опционально содержать тег IEEE 802.1Q для идентификации того, к какой VLAN он принадлежит, и его приоритета ( качества обслуживания ). Эта инкапсуляция определена в спецификации IEEE 802.3ac и увеличивает максимальный кадр на 4 октета.
Тег IEEE 802.1Q, если он присутствует, помещается между полем Source Address и EtherType или Length. Первые два октета тега представляют собой идентификатор протокола тега (TPID) со значением 0x8100. Оно расположено в том же месте, что и поле EtherType/Length в кадрах без тегов, поэтому значение EtherType 0x8100 означает, что кадр помечен, а истинное поле EtherType/Length находится после Q-тега. За TPID следуют два октета, содержащие информацию управления тегами (TCI) (приоритет IEEE 802.1p ( качество обслуживания ) и идентификатор VLAN). За Q-тегом следует остальная часть кадра, используя один из типов, описанных выше.
Рантовые рамы
Рант-кадр — это кадр Ethernet, длина которого меньше минимальной длины IEEE 802.3, равной 64 октетам. Рант-кадры чаще всего вызываются коллизиями ; другими возможными причинами являются неисправная сетевая карта , опустошение буфера , несоответствие дуплекса или проблемы с программным обеспечением. [14]
мало чего в этом понимаю, объясните пожалста, хоть в 4 строчки.
нужно сдавать работу в институт, а ответ на этот вопрос не знаю..
в нете тоже мало чего нашел..
Поле P (Preamble, преамбула) состоит из семи байт 10101010 и используется для синхронизации. Преамбула кадра Ethernet II содержит также поле SFD.
Поле SFD (Start of Frame Delimiter, разделитель начала кадра) имеет значение 10101011 и указывает на то, что следующий байт принадлежит заголовку кадра.
Поле DA (Destination Address, адрес назначения) содержит адрес одного из трех типов:
-индивидуальный (unicast) адрес – первый бит старшего байта равен 0, указывает на единственного получателя (представляет собой его MAC-адрес); уникальность адресов обеспечивают производители сетевого оборудования: во втором и третьем байте хранится номер фирмы-изготовителя, а остальные заполняются изготовителем; некоторые сетевые адаптеры позволяют устанавливать для них произвольный MAC-адрес;
-широковещательный (broadcast) адрес – состоит из всех единиц (0xFFFFFFFFFFFF), указывает на то, что данный кадр должен быть получен всеми узлами сети;
-групповой (multicast) адрес – первый бит старшего байта равен 1, в остальных битах хранится номер группы узлов, для которых предназначен данный кадр.
Поле SA (Source Address, адрес источника) содержит MAC-адрес отправителя кадра (всегда индивидуальный адрес).
Поле Type (тип) указывает на протокол верхнего уровня, чьи данные передаются в кадре (фактически, выполняет функции полей DSAP и SSAP из заголовка кадра LLC).
Поле Length (длина) содержит размер поля Data (в байтах).
Поле Data (данные) содержит данные, переданные протоколом верхнего уровня.
Поле FCS (Frame Check Sequence, контрольная последовательность кадра) содержит контрольную сумму кадра, вычисленную по алгоритму CRC-32.
Поля DSAP, SSAP и Control составляют заголовок LLC-кадра.
Поле ProtID (идентификатор протокола) позволяет использовать кадры Ethernet для передачи данных более широкого множества протоколов верхнего уровня. Это поле состоит из двух под полей: трехбайтного OUI (Organizationally Unique Identifier, организационно-уникальный идентификатор), хранящего номер организации, контролирующей коды протоколов во втором (двухбайтном) подполе Type (тип). IEEE присвоен OUI = 0x00000.
Минимальный размер кадра Ethernet — 64 байта, максимальный — 1518 байт. К этому количеству относятся все байты, начиная с поля «MAC-адрес назначения» и заканчивая полем «Контрольная последовательность кадра (FCS)». Поле «Преамбула» при описании размера кадра не включено.
Поля «Преамбула» и «Начало ограничителя кадра»
Поля «Преамбула» (7 байт) и «Начало ограничителя кадра» (SFD), которое также называется «Начало кадра» (1 байт), используются для синхронизации отправляющих и получающих устройств. Эти первые восемь байт кадра необходимы для привлечения внимания получающих узлов. По существу, первые несколько байт сообщают получателям о необходимости приготовиться к поступлению нового кадра.
Поле «MAC-адрес назначения»
Это 6-байтное поле является идентификатором для предполагаемого получателя. Как вы помните, этот адрес используется уровнем 2, чтобы помочь устройствам определить, адресован ли кадр именно им. Адрес в кадре сравнивается с MAC-адресом в устройстве. В случае совпадения устройство принимает кадр. Адрес может быть для отправки одному узлу (unicast), группе узлов (multicast) или широковещательной рассылки (broadcast).
Поле «МАС-адреса источника»
Это 6-байтное поле определяет сетевую плату или интерфейс, отправившие кадр. Адрес должен быть индивидуальным адресом устройства (unicast).
Поле «EtherType»
Это 2-байтное поле определяет протокол вышестоящего уровня, инкапсулированный в кадр Ethernet. Характерные значения — значения в шестнадцатеричном формате 0x0800 для IPv4, 0x86DD для IPv6 и 0x806 для ARP.
Поле «Данные»
Это поле (46-байт) содержит инкапсулированные данные более высокого уровня — в общем случае произвольную PDU 3 уровня, чаще всего это будет пакет IPv4. Длина всех кадров должна быть не менее 64 байт. В случае инкапсуляции небольшого пакета используются дополнительные биты, которые называются символами-заполнителями, для увеличения размера кадра до этого минимального значения.
Поле FCS (Контрольная последовательность кадра)
Поле FCS (Контрольная последовательность кадра) (4 байта) используется для обнаружения ошибок в кадре. В нем используется циклический избыточный код (CRC). Отправляющее устройство вносит результат вычисления CRC в поле FCS кадра. Принимающее устройство получает кадр и вычисляет CRC для обнаружения ошибок. Если расчеты совпадают, ошибки отсутствуют. Несовпадение расчетов означает изменение данных в процессе передачи; как следствие, кадр отбрасывается. Данные могут измениться в результате искажения электрических сигналов, которые представляют биты.
Любой кадр с длиной менее 64 байтов считается «фрагментом коллизии» или «карликовым кадром» и автоматически отклоняется принимающими станциями. Кадры с длиной более 1500 байт называются Jumbo-кадрами (значительно превышающие допустимый размер) или Baby Giant (слегка превышающие допустимый размер).
Если размер передаваемого кадра меньше минимального значения или больше максимального значения, получающее устройство сбрасывает такой кадр. Отброшенные кадры, скорее всего, являются результатом коллизий или других нежелательных сигналов и, следовательно, считаются недействительными.
Статья получилась довольно объёмная, рассмотренные темы — форматы 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). Мифы и рифы».
В заключение обещанный линк на отчёт Alteon Networks «Extended Frame Sizes for Next Generation Ethernets» — staff.psc.edu/mathis/MTU/AlteonExtendedFrames_W0601.pdf, и небольшой анонс на следующую статью – в ней мы падём ещё ниже — на физический уровень, и будем разбираться с тяжелым наследием CSMA/CD, энкодингами, и, походя, зацепим ещё чего из злободневного.
Поля кадра Преамбула (7 байтов) и Начальный разграничитель кадров (SFD) (1 байт) в Ethernet используются для синхронизации между передающим и принимающим устройствами. Эти первые восемь байтов фрейма используются, чтобы привлечь внимание узлов получения. По существу первые несколько байтов говорят получателям подготовиться принимать новый кадр.
Поле MAC-адрес Назначения
Поле MAC Адрес Назначения (6 байтов) является идентификатором для предполагаемого получателя. Как Вы можете вспомнить, этот адрес используется Уровнем 2, чтобы помочь устройствам в определении, адресуется ли им данный фрейм. Адрес во фрейме сравнивается с MAC-адресом устройства. Если адреса совпадают, устройство принимает фрейм.
Поле MAC-адрес Источника
Поле MAC Адрес Назначения (6 байтов) идентифицирует отправляющий NIC или интерфейс фрейма. Коммутаторы также используют этот адрес, чтобы добавить его к своим таблицам сопоставления. Роль коммутаторов будет обсуждаться позже в этой рубрике.
Поле Длина/Тип
Эти два применения поля были официально объединены в 1997 в стандарте IEEE 802.3x, потому что оба применения были распространены. Поле Тип Ethernet II включается в текущее определение фрейма 802.3. Когда узел принимает кадр, он должен исследовать поле Длина, чтобы определить, какой протокол более высокого уровня в нем присутствует. Если значение двух октетов больше или равно, чем шестнадцатеричное число 0x0600 или десятичное число 1536, то содержимое поля Данные декодируется согласно обозначенному типу протокола. Если значение поля меньше или равно, чем шестнадцатеричное число 0x05DC или десятичное число 1500, поле Длина используется для указания использования формата кадра IEEE 802.3. Таким образом различаются кадры Ethernet II и 802.3.
Поля Данные и Набивка
Поля Данные и Набивка (46 - 1500 байтов) содержат инкапсулированные данные от более высокого уровня, который является типичным PDU Уровня 3, обычно, пакетом IPv4. Все фреймы должны быть по крайней мере 64 байта длиной. Если инкапсулируется пакет меньшего размера, используется Набивка, чтобы увеличить размер кадра до этого минимального размера.
Содержание
Novell необработанный IEEE 802.3
«Необработанный» формат кадра Novell 802.3 был основан на ранней работе IEEE 802.3. Novell использовала это как отправную точку для создания первой реализации собственного сетевого протокола IPX через Ethernet. Они не использовали заголовок LLC, а запускали пакет IPX сразу после поля длины. Это не соответствует стандарту IEEE 802.3, но, поскольку IPX всегда имеет FF в качестве первых двух октетов (в то время как в IEEE 802.2 LLC этот шаблон теоретически возможен, но крайне маловероятен), на практике это обычно сосуществует в сети с другими реализациями Ethernet. за заметным исключением некоторых ранних форм DECnet , которые из-за этого запутались.
Novell NetWare использовала этот тип фрейма по умолчанию до середины девяностых, и, поскольку NetWare была тогда очень широко распространена, а IP — нет, в какой-то момент большая часть мирового трафика Ethernet проходила через «сырой» 802.3, несущий IPX. Начиная с NetWare 4.10, NetWare по умолчанию использует IEEE 802.2 с LLC (тип кадра NetWare Ethernet_802.2) при использовании IPX. [11]
Кадр — канальный уровень
Заголовок
Заголовок содержит MAC-адреса получателя и источника (каждый длиной шесть октетов), поле EtherType и, необязательно, тег IEEE 802.1Q или тег IEEE 802.1ad .
Поле EtherType имеет длину два октета и может использоваться для двух разных целей. Значения 1500 и ниже означают, что он используется для указания размера полезной нагрузки в октетах, а значения 1536 и выше указывают, что он используется как EtherType, чтобы указать, какой протокол инкапсулирован в полезную нагрузку кадра. При использовании в качестве EtherType длина кадра определяется расположением межпакетного промежутка и допустимой последовательностью проверки кадра (FCS).
Тег IEEE 802.1Q или IEEE 802.1ad , если он присутствует, представляет собой поле из четырех октетов, которое указывает на принадлежность к виртуальной локальной сети (VLAN) и приоритет IEEE 802.1p . Первые два октета тега называются идентификатором идентификатора протокола тега ( TPID ) и удваиваются как поле EtherType, указывающее, что кадр помечен либо 802.1Q, либо 802.1ad. 802.1Q использует TPID 0x8100. 802.1ad использует TPID 0x88a8.
Полезная нагрузка
Полезная нагрузка — это поле переменной длины. Его минимальный размер определяется требованием минимальной длины передаваемого кадра в 64 октета. [d] С учетом заголовка и FCS минимальная полезная нагрузка составляет 42 октета при наличии тега 802.1Q [e] и 46 октетов при его отсутствии. Когда фактическая полезная нагрузка меньше минимальной, соответственно добавляются октеты заполнения. Стандарты IEEE определяют максимальную полезную нагрузку в 1500 октетов. Нестандартные Jumbo-кадры позволяют использовать более крупные полезные нагрузки в сетях, созданных для их поддержки.
Последовательность проверки кадра
Последовательность проверки кадра (FCS) представляет собой проверку циклическим избыточным кодом (CRC) из четырех октетов , которая позволяет обнаруживать поврежденные данные во всем кадре, полученном на стороне получателя. В соответствии со стандартом значение FCS вычисляется как функция полей защищенного кадра MAC: адреса источника и получателя, поля длины/типа, данных клиента MAC и заполнения (то есть всех полей, кроме FCS).
Согласно стандарту, это вычисление выполняется с использованием алгоритма CRC32 BZIP2 со сдвигом влево (poly = 0x4C11DB7, начальный CRC = 0xFFFFFFFF, CRC дополняется после, значение проверки = 0x38FB2284). Стандарт устанавливает, что данные передаются младшим значащим битом (бит 0) первым, в то время как FCS передается первым старшим значащим битом (бит 31). [3] : раздел 3.2.9 . Альтернативой является вычисление CRC с использованием сдвига вправо CRC32 (poly = 0xEDB88320, начальный CRC = 0xFFFFFFFF, CRC дополняется после завершения, значение проверки = 0x2144DF1C), в результате чего CRC является инвертирование битов FCS и передача сначала как данных, так и младшего бита CRC, что приводит к идентичным передачам.
В стандарте указано, что приемник должен вычислять новую FCS по мере получения данных, а затем сравнивать полученную FCS с FCS, рассчитанной приемником. Альтернативой является вычисление CRC как для полученных данных, так и для FCS, что приведет к фиксированному ненулевому значению «проверки». (Результат не равен нулю, поскольку CRC дополняется во время генерации CRC). Поскольку данные принимаются первым младшим значащим битом, и чтобы избежать буферизации октетов данных, приемник обычно использует CRC32 со сдвигом вправо. Это делает значение «проверки» (иногда называемое «магической проверкой») 0x2144DF1C. [5]
Однако аппаратная реализация CRC с логическим сдвигом вправо может использовать сдвиговый регистр с линейной обратной связью со сдвигом влево в качестве основы для вычисления CRC, инвертирования битов и получения проверочного значения 0x38FB2284. Поскольку дополнение CRC может быть выполнено после вычисления и во время передачи, то, что остается в аппаратном регистре, является недополняемым результатом, поэтому остаток для реализации сдвига вправо будет дополнением 0x2144DF1C = 0xDEBB20E3, а для сдвига влево реализация, дополнение 0x38FB2284 = 0xC704DD7B.
Читайте также: