Для чего в кадре ethernet указывается контрольная сумма

Для чего в кадре ethernet указывается контрольная сумма

Описание технологии Ethernet

Форматы кадров Ethernet

Для успешной доставки информации получателю каждый кадр должен кроме данных содержать служебную информацию : длину поля данных, физические адреса отправителя и получателя, тип сетевого протокола и т.д.

Большинство сетевых администраторов не уделяет должного внимания типам кадров Ethernet, а это может явиться источником проблем. Например, если клиентское сетевое программное обеспечение настроено на неверный тип кадра, то пользователь не сможет взаимодействовать с сервером. За типом кадра приходится особенно внимательно следить в сетях Nowell NetWare, так как в новых версиях этой операционной системы тип кадра по умолчанию был изменён с 802.3 на 802.2. Кроме того, в корпоративных сетях применяются устройства от нескольких поставщиков, базирующихся на разных протоколах взаимодействия и использующих различные типы кадров.

Для того, чтобы рабочие станции имели возможность взаимодействовать с сервером в одном сегменте сети, они должны поддерживать единый формат кадра. Существует четыре основных разновидности кадров Ethernet :

Рассмотрим поля, общие для всех четырёх типов кадров (рис. 1).

Признак начала кадра (8 бит)

Адрес получателя (48 бит)

Адрес отправителя (48 бит)

Данные (переменная длина)

Контрольная сумма (32 бит)

Рис. 1. Общий формат кадров Ethernet

Поля в кадре имеют следующие значения :

Рассмотрим более подробно форматы кадров разных типов. Тип кадра Ethernet II используется многими протоколами верхнего уровня, такими как IPX, TCP/IP и Apple Talk. Данный тип кадра был разработан фирмами DEC, Intel и Xerox. Необходимо учитывать, что хотя данный тип кадра является наиболее широко используемым, он не одобрен организациями ISO и IEEE. Формат данного типа кадра отличается от рассмотренного выше только тем, что в поле «Длина/тип» всегда указывается тип протокола.

Сетевые операционные системы Nowell NetWare 2.x и 3.x (за исключением 3.12) по умолчанию используют кадры Ethernet 802.3. Хотя в названии этого кадра есть упоминание комитета IEEE, последний не имел никакого отношения к его разработке.

Данный тип кадра не содержит никакой информации о протоколе. Поле «Длина/тип» всегда указывает длину кадра. В результате нет стандартных методов идентификации сетевого протокола, которому принадлежит данный кадр. Однако, только в соответствии с концепцией фирмы Nowell, только протокол IPX может использоваться с данным типом кадров. Разработана специальная последовательность действий для определения того, что именно протокол IPX был инкапсулирован в кадр данного типа :

В результате стандартизации сетей Ethernet подкомитетом IEEE 802.3 появился кадр Ethernet 802.2. Этот кадр является базовым для операционных систем Nowell NetWare версий 3.12 и 4.х. В данном типе кадра сразу за адресом отправителя следует поле длины, имеющее такое же назначение. Кроме того, этот тип кадра содержит несколько дополнительных полей, рекомендованных подкомитетом IEEE 802.3. Эти поля распологаются за полем «Длина/тип» и имеют следующее назначение :

Формат кадра Ethernet 802.2 имеет некоторые недостатки, в частности, он содержит нечётное число байтов служебной информации. Это не совсем удобно для работы большинства сетевых устройств. Кроме того, для идентификации протокола сетевого уровня отводится 7 бит,что позволяет поддерживать «всего» 128 различных протоколов. Кадр Ethernet SNAP, являющийся дальнейшим развитием Ether n et 802.2, содержит следующие дополнительные поля (рис. 2) :

В совокупности эти два поля составляют дополнительное пятибайтовое поле для идентификации протокола.Это было сделано для увеличения числа поддерживаемых протоколов.

Источник

Технология Ethernet. Обзор, описание, формат кадра.

Приветствую всех снова на нашем сайте!

Вынужденная пауза в выходе новых статей подошла к концу и, собственно, этой статьей мы положим начало активнейшему периоду наполнения сайта новым контентом. С выбором темы для статьи было в этот раз все максимально просто — в далекие-далекие времена была обещана статья про работу с Ethernet, наконец-то настало время исполнить обещанное… Но начнем мы для начала с общего обзора и описания технологии и некоторых нюансов, связанных с работой. А уже в следующих статьях будет практическое использование.

Семейство технологий Ethernet.

Как в самом начале не привести максимально «стандартное» и распространенное определение… Вот оно: Ethernet — семейство технологий пакетной передачи данных между устройствами для компьютерных и промышленных сетей. А теперь уже переходим непосредственно к сути.

В сетевой модели OSI (про нее скоро тоже будет статья, а здесь появится ссылка на нее) Ethernet отвечает за 2 самых низких уровня — физический и канальный. Собственно, физический уровень определяет метод, который используется для непосредственной передачи двоичных данных. Канальный же, в свою очередь, обеспечивает упаковку полученных с физического уровня данных в структурированные кадры, а также контролирует их целостность и безошибочность.

Модификации Ethernet.

Классификация модификаций Ethernet в основном заключается в различиях двух факторов — используемого типа кабеля, а также возможной скорости передачи данных. Различают:

Как мы и отметили сразу, различаются, в первую очередь, скорость передачи данных и тип используемого кабеля. На заре развития Ethernet использовались исключительно коаксиальные кабели, и лишь затем появились варианты с витой парой и оптикой, что привело к значительному расширению возможностей. К примеру, использование витой пары дает одновременно:

Внутри указанных четырех модификаций (Ethernet, Fast Ethernet, Gigabit Ethernet, 10G Ethernet) присутствует дополнительное «внутреннее» разделение. Например, возьмем 10 Мбит/с Ethernet. Вот некоторые из стандартов, которые включает этот тип:

При этом различная физическая реализация подключения (разные кабели) приводят к возможности использования разных топологий сети. Для 10Base-5 максимально топорно:

А вот 10Base-T уже может использовать полнодуплексную передачу данных:

Здесь, как видите присутствует устройство под названием сетевой концентратор. Поэтому небольшое лирическое отступление на эту тему.

Зачастую термины сетевой концентратор, сетевой коммутатор и маршрутизатор перемешиваются и могут использоваться для описания одного и того же. Но строго говоря, все эти три термина относятся к абсолютно разному типу устройств:

Возвращаемся к схеме для стандарта 10Base-T… Поскольку для передачи и приема используются физически разные линии, то нет и препятствий для одновременного протекания данных процессов. Принцип же формирования данных остается неизменным практически для всех модификаций Ethernet, к обсуждению чего мы и переходим.

Кадр Ethernet.

Вся передаваемая информация поделена на пакеты/кадры, имеющие следующий формат:

Рассмотрим блоки подробнее:

Все поля, кроме поля данных, являются служебными.

Методика анализа контрольной суммы абсолютно стандартна: отправитель рассчитывает контрольную сумму на основе остальных данных кадра и добавляет рассчитанное значение к этому же отправляемому кадру. Получатель также рассчитывает контрольную сумму на основе принятых данных и сравнивает ее с принятой (которую рассчитывал отправитель). Несовпадение рассчитанного и принятого значений CRC — явный сигнал к тому, что данные повреждены и некорректны.

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

Кроме этого, возможна еще одна неприятная ситуация, так называемая коллизия — когда несколько узлов начинают передавать данные одновременно. Для предотвращения этого в Ethernet используется технология CSMA/CD — Carrier Sense Multiple Access with Collision Detection — множественный доступ с прослушиванием несущей и обнаружением коллизий. Эта тема тоже довольно-таки интересная, в связи с чем, принято волевое решение посвятить ей отдельную статью 🙂 Поэтому здесь и сейчас на этом не останавливаемся.

В первых по очередности двух полях кадра Ethernet содержатся MAC-адреса узлов сети — передатчика и приемника. Изначально при разработке первых версий технологии было предусмотрено, что любая сетевая карта должна иметь свой уникальный идентификатор. Роль этого идентификатора и играет MAC-адрес, состоящий из 6 байт.

При работе он позволяет идентифицировать все устройства в сети и определить, какому именно из них предназначен тот или иной кадр данных. Распределением MAC-адресов занимается регулирующий комитет IEEE Registration Authority, именно сюда производитель сетевого устройства должен обращаться для выделения ему некоего диапазона адресов, которые он сможет использовать для своей продукции.

И на этой ноте заканчиваем вводную теоретическую часть по Ethernet, в дальнейшем приступим к практическому использованию в своих устройствах. До скорого!

Источник

Всё, что вы хотели знать о 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). Мифы и рифы».

Источник

Канальный уровень сетевой модели OSI

5.2. Форматы кадров канального уровня

Формат кадра Ethernet

Формат кадров канального уровня практически одинаков для всех Ethernet совместимых технологий. Технология Ethernet предусматривает кадры четырех форматов, которые незначительно отличаются друг от друга. Один из форматов кадра (802.3) подуровня МАС приведен на рис. 5.3.

В локальных сетях адресация сообщений производится на основе МАС-адресов, которые «прошиты» в ПЗУ сетевых карт конечных узлов и на интерфейсах сетевых элементов. При запуске компьютера МАС-адрес из ПЗУ копируется в оперативную память ОЗУ. В современной аппаратуре программаторы позволяют изменять МАС-адреса, что снижает эффективность фильтрации трафика на основе МАС-адресов, т.е. снижает информационную безопасность.

Адрес, состоящий из всех единиц FF-FF-FF-FF-FF-FF, является широковещательным адресом (broadcast), когда передаваемая в кадре информация предназначена всем узлам локальной сети.

Младшие 24 разряда МАС-адреса (6 шестнадцатеричных разрядов) задают уникальный номер оборудования, например, номер сетевой карты. Старшие 24 разряда физического МАС-адреса, называемые уникальным идентификатором организации (OUI), присваиваются производителю оборудования институтом IEEE. Израсходовав все МАС-адреса, задаваемые младшими 24 разрядами, производитель оборудования должен получить новый идентификатор OUI от IEEE. Несмотря на то, что в МАС-адресе выделена старшая и младшая части, он считается, в отличие от IP-адреса, плоским (не иерархическим).

Поле L ( рис. 5.3) определяет длину поля данных Data, которое может быть от 46 до 1500 байт. Если поле данных меньше 46 байт, то оно дополняется до 46 байт.

Когда сетевое устройство принимает кадр, размер которого меньше минимального или больше максимального, то устройство отбрасывает такой кадр, поскольку считает, что кадр искажен в результате коллизии или воздействия помех.

Формат кадра протокола «точка-точка» РРР

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

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

Формат кадра беспроводной локальной сети

В технологиях беспроводных сетей стандарта 802.11, называемых также Wi-Fi (Wireless Fidelity),используется формат кадра, изображенный на рис. 5.6.

Также как в сетях Ethernet в сетях Wi-Fi на уровне управления логическим каналом LLC используется протокол 802.2. В формате кадра используются МАС-адрес назначения DA и МАС-адрес источника SA по 48 двоичных разряда. Концевик кадра содержит контрольную сумму FCS для проверки принятого кадра на наличие ошибок.

Обмен сообщениями в сетях Wi-Fi обычно производится через промежуточные устройства (беспроводные точки доступа). Поэтому в формате кадра 802.11 дополнительно предусмотрены:

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

Поле Длительность/Идентификатор используется по-разному, в зависимости от типа кадра. В этом поле указывается либо время, требуемое для передачи кадра, либо идентификатор станции, передавшей кадр.

Поле управления последовательностью размером в 2 байта состоит из двух частей: первые 4 бита задают номер фрагмента кадра; оставшиеся 12 бит задают номер последовательности, который был присвоен кадру.

В кадрах могут передаваться данные (пакет IP) или служебная информация, размещаемые в поле основного текста кадра (Frame Body).

Источник