для чего нужно значение crc в поле fcs кадра

Канальный уровень сетевой модели 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).

Источник

Артём Санников

Языки программирования

Базы данных

Программное обеспечение

Операционные системы

Мобильная разработка

Менеджеры пакетов

Сетевые технологии

CMS системы

Математика

SEO продвижение

Социальные сети

Психология

Хостинг провайдер

Смартфоны

Поля кадра Ethernet. CCNA Routing and Switching.

Минимальный размер кадра 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 (слегка превышающие допустимый размер).

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

Источник: Академия Cisco.

Другие статьи из категории «CCNA: Introduction to Networks»

Комментарии

Автор, у Вас ошибка в тексте.

Поле «EtherType»
Это 2-байтное поле определяет протокол вышестоящего уровня, инкапсулированный в кадр Ethernet. Характерные значения — значения в шестнадцатеричном формате 0x800 для IPv4, 0x86DD для IPv6 и 0x806 для ARP.»

Правильное значение в шестнадцатеричном формате для IPv4 будет 0x0800.
А вы написали 0x800

я в этом нифига не шарю, но разве 0x806 тоже верно для ARP. эм.

Источник

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

Источник

Ребята, очень нужна помощь

вопрос-Структура кадра ETHERNET. Назначение его полей.

мало чего в этом понимаю, объясните пожалста, хоть в 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.

Можешь выбрать ответ как лучший. (Так совет.)

Источник

fcs errors что это

FCS (Frame check sequence) — четырёхбайтное значение CRC, используемое для выявления ошибок передачи. Вычисляется отправляющей стороной и помещается в поле FCS. Принимающая сторона вычисляет данное значение самостоятельно и сравнивает с полученным.

Данный формат был создан в сотрудничестве трёх компаний — DEC, Intel и Xerox. В связи с этим стандарт также носит название DIX Ethernet standard. Данная версия стандарта была опубликована в 1982г (первая версия, Ehernet I — в 1980 г. Различия в версиях небольшие, формат в целом остался неизменным). В 1997 г. году данный стандарт был добавлен IEEE к стандарту 802.3 и на данный момент подавляющее большинство пакетов в Ethernet-сетях инкапсулированы согласно этому стандарту.

A frame check sequence (FCS) refers to an error-detecting code added to a frame in a communications protocol. Frames are used to send payload data from a source to a destination.

Contents

Purpose [ edit ]

All frames and the bits, bytes, and fields contained within them, are susceptible to errors from a variety of sources. The FCS field contains a number that is calculated by the source node based on the data in the frame. This number is added to the end of a frame that is sent. When the destination node receives the frame the FCS number is recalculated and compared with the FCS number included in the frame. If the two numbers are different, an error is assumed and the frame is discarded.

Implementation [ edit ]

The FCS is often transmitted in such a way that the receiver can compute a running sum over the entire frame, together with the trailing FCS, expecting to see a fixed result (such as zero) when it is correct. For Ethernet and other IEEE 802 protocols, this fixed result, also known as the magic number or CRC32 res >[3] When transmitted and used in this way, the FCS generally appears immediately before the frame-ending delimiter.

Types [ edit ]

By far the most popular FCS algorithm is a cyclic redundancy check (CRC), used in Ethernet and other IEEE 802 protocols with 32 bits, in X.25 with 16 or 32 bits, in HDLC with 16 or 32 bits, in Frame Relay with 16 bits, [4] in Point-to-Point Protocol (PPP) with 16 or 32 bits, and in other data link layer protocols.

суббота, 27 декабря 2014 г.

Значения счетчиков ошибок

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

Счетчики ошибок при получении кадров (RX):

CRC Error

Counts otherwise valid packets that did not end on a byte (octet) boundary.

Счетчик ошибок контрольной суммы (CRC). В свою очередь, является суммой счетчиков Alignment Errors и FCS Errors.
FCS (Frame Check Sequence) Errors — ошибки в контрольной последовательности кадра. Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт) и получены без ошибок кадрирования или коллизий.
Alignment Errors — ошибки выравнивания (некорректной длины кадра). Счетчик регистрирует кадры с ошибками FCS, при этом кадры имеют корректный размер (от 64 до 1518 байт), но были получены с ошибками кадрирования.
В случае, если кадр был классифицирован как имеющий ошибку Alignment Error, счетчик FCS при этом не увеличивается. Иными словами, инкрементируется либо счетчик FCS либо Aligment, но не оба сразу.

UnderSize

The number of packets detected that are less than the minimum permitted packets size of 64
bytes and have a good CRC. Undersize packets usually indicate collision fragments, a normal
network occurrence.

Счетчик кадров с правильной контрольной суммой и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.

OverSize

Counts valid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.

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

Fragment

The number of packets less than 64 bytes with either bad framing or an invalid CRC. These
are normally the result of collisions.

Счетчик кадров с неправильной контрольной суммой или структурой кадра и размером менее 64 байт. Такие кадры могут возникать в результате коллизий в сети.

Jabber

Counts invalid packets received that were longer than 1518 octets and less than the
MAX_PKT_LEN. Internally, MAX_PKT_LEN is equal to 1536.

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

Счетчик ошибок при отправке кадров (TX):

Excessive Deferrral

Counts the number of packets for which the first transmission attempt on a particular
interface was delayed because the medium was busy.

Счетчик кадров, первая попытка отправки которых было отложена из-за занятости среды передачи.

CRC Error

Counts otherwise valid packets that did not end on a byte (octet) boundary.

Счетчик ошибок контрольной суммы (CRC). На практике никогда не увеличивается.

Late Collision

Counts the number of times that a collision is detected later than 512 bit-times into the
transmission of a packet.

Счетчик случаев когда коллизия обнаруживалась после передачи первых 64 байт (512 бит) кадра.

Excessive Collision

Excessive Collisions. The number of packets for which transmission failed due to excessive
collisions.

Счетчик кадров, отправка которых не удалась из-за чрезмерного количества колизий.

Single Collision

Single Collision Frames. The number of successfully transmitted packets for which
transmission is inhibited by more than one collision.

Счетчик успешно отправленных кадров, передача которых вызвала более одной коллизии.

Collision

Моно добавить, что на практике RX CRC обычно является результатом деградации среды передачи (медный кабель или оптоволокно), а TX-коллизии — результатом неправильного согласования скорости соединения, например half-линка.

Неплохая расшифровка значений счетчиков приведена тут.

Источник