Содержание
- D-Link Switches: Tips & Tricks
- суббота, 27 декабря 2014 г.
- Значения счетчиков ошибок
- Счетчики ошибок при получении кадров (RX):
- CRC Error
- UnderSize
- OverSize
- Fragment
- Jabber
- Excessive Deferrral
- CRC Error
- Late Collision
- Excessive Collision
- Single Collision
- Collision
- Fsc error что это
- ether2 fcs error on link
- Fcs error on link mikrotik
- суббота, 27 декабря 2014 г.
- Значения счетчиков ошибок
- Счетчики ошибок при получении кадров (RX):
- CRC Error
- UnderSize
- OverSize
- Fragment
- Jabber
- Excessive Deferrral
- CRC Error
- Late Collision
- Excessive Collision
- Single Collision
- Collision
- Understand FCS Errors, Input Errors, or Packet Loss on Devices Connected to Multigigabit Ethernet Ports
- Available Languages
- Download Options
- Bias-Free Language
- Contents
- Introduction
- Prerequisites
- Requirements
- Components Used
- Background Information
- Problem Summary
D-Link Switches: Tips & Tricks
суббота, 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-линка.
Неплохая расшифровка значений счетчиков приведена тут.
Источник
Fsc error что это
ether2 fcs error on link
У меня такая же ошибка уже месяца полтора-два.
Делал то что и Вы, менял провода, порты, настройки.
Ждал новую прошивку, в ней было описание что вроде это пофиксили,
но увы, снова и снова. ошибки есть.
Кстати, думаю что это связано с насхлёстом одного уровня над другим.
У меня получается сделан бондинг (ether1 и ether2) , на этом бондинге подняты виланы (много) и уже на виланах идёт адресация. Также туннели висят на некоторых адресах.
Думаю что из-за вот этих 2х уровней абстракции + туннели и возникает. проблемы.
В другой конторе почти на 80% такая же конфигурация, но там ошибок нет. Так что думаю или дело в туннелях (там их нет, а бондинг и виланы есть),
или всё же с другой стороны микротика, на свиче что-то с портами Ethernet (мож свитч подыхает?)
Опишите Вашу конфигурацию. может найдём общие точки соприкосновения!?
Пару раз сталкивался с данной проблемой.
В первом случае заменил инжектор во втором случае больно пинал монтажника который кабель положил вдоль силовой линии да еще и обжал криво
Вобще года 3 тому назад я вложил несколько десятков тысяч денег в подбор кабеля. Перепробовал массу производителей от китайского овна до мега дорогих. Сейчас юзаю кабель для внешней прокладки от нетлан, еще ни разу не подвел. Соотношение цена/качество отличное
Источник
Fcs error on link mikrotik
Столкнулся с проблемой на MikroTik – ошибки в логах и отсутствие интернета на порту Ether1. Стал искать ответ в интернете, но решения не нашел. Существует предположение, что проблема появления ошибки interface,warning ether1 fcs error on link связана с наводками от кабелей 220v.
К сожалению, проблема не имеет стойкого графика появления. Цикл между ошибками разный, может быть неделя, а может быть и пару месяцев. Помогает либо полная перезагрузка MikroTik или отключение порта. До текущего момента мы делали это вручную, после был найден скрипт. К сожалению автора скрипта, найти не удалось. Но раз ошибка популярная, то думаю не лишним будет его указать, как решение проблемы.
На микротике RB951G-2HnD установлена последняя RouterOS 6.19.
Провайдер (Ростелеком) подключен в первый порт роутера, скорость соединения в микротике определяется, как 100 full duplex.
При поднятии PPPoE соединения с провайдером теряется около 40% пакетов через это соединение. Пробовал ping 8.8.8.8 и ping ya.ru и просто открывал сайты через http.
Важно, что при использовании старого оборудования (сервер на Intel Atom) таких потерь не обнаруживается. Пробовал подключать ноутбук с Ubuntu напрямую тоже все работает без проблем.
Что делал:
Менял MTU PPPoE соединения и flow control Ethernet port1.
Менял роутер для исключения не работоспособности железа.
Менял физический порт роутера на 5й эффект сохранялся.
На форуме микротика нашел схожую проблему, которая якобы исправлена в версии 6.11 RouterOS.
Также как и предложено на форуме микротика включил между микротиком и провайдером Dlink-DGS 1005d и потери пакетов исчезли.
Как исправить проблему с потерей пакетов? Хочу подключать напрямую, а не через доп. оборудование.
суббота, 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-линка.
Неплохая расшифровка значений счетчиков приведена тут.
Источник
Understand FCS Errors, Input Errors, or Packet Loss on Devices Connected to Multigigabit Ethernet Ports
Available Languages
Download Options
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Contents
Introduction
This document describes how to understand errors from devices connected to Multigigabit Ethernet (mGig) ports on Catalyst 9000 Series Switches.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on these platforms: Catalyst 9000 series switches with mGig capable ports.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
This document describes why you can encounter frame check sequence (FCS) errors, input errors, or packet loss with devices that connect to Multigigabit Ethernet (mGig) ports on Catalyst 9000 series switches due to interpacket gap (IPG) or interframe gap (IFG) tolerance.
In networking, a pause could be required between network packets or network frames. This time between packets is known as the IPG or IFG. This pause is necessary to allow for receiver clock recovery, which permits the receiver to prepare for another packet. The IFG/IPG standard value for Gigabit Ethernet is 12 bytes. However, from IEEE Standard 802.3, the minimum value for the IFG can be as low as 8 bytes or 64 BT (bit times). For reference, this is documented in 802.3-2000 — IEEE Standard for Information Technology — LAN/MAN — Specific Requirements.
Problem Summary
Multigigabit Ethernet technology is implemented on 10Gig PHYs on Cat9000 architecture. For example, when a connection is established through an mGig port at 1Gbps, if traffic bursts higher than the bandwidth of the interface, the C9600 utilizes port buffers to accommodate that excess traffic and dynamically decreases the IFG/IPG size to avoid any impact and ensure traffic throughput and switch performance. The issue arises when some peer devices are unable to handle the smaller IFG/IPG sizes and no longer recognize legitimate packets and drop this traffic, which results in input errors on their NIC or PHY, such as Cyclic Redundancy Check (CRC) or FCS errors. In certain scenarios the local mGig port (an interface from the mGig linecard C9600-LC-48TX) can also experience the same type of loss in the form of input errors (CRC, FCS) on the interface.
As shown in the table, the structure of an Ethernet packet, which includes the IPG/IFG field:
Layer
Preamble
Start Frame Delimeter
Destination MAC
Source MAC
802.1Q Tag
Ethertype (Ethernet II) or length (IEEE 802.3)
Payload
Frame Check Sequence (32 bit CRC)
Источник
Сообщения без ответов | Активные темы
| Автор | Сообщение |
|---|---|
|
Заголовок сообщения: От чего на порту комутатора могут появлятся FCSErrors ?
|
|
|
|
Простая связка, DES3526 —— COMPEX8——COMPEX8——DES1226G На 3526 порт, что смотрит на первый COMPEX8 Received(RX) есть такие ошибки не очень много, и потом на порту DES1226G что смотрит на COMPEX8 тоже в Received(RX) есть ошибки но уже по больше.
Мыльницы менялись на новые, ситуация не поменялась. |
| Вернуться наверх |
|
 |
Добавлено: Ср июн 25, 2008 11:32 
|
Demin Ivan |
Заголовок сообщения:
|
|
|
Вообщем по какой-то причине приходит небольшое кол-во битых пакетов. Настройки портов на обоих концах линка полностью совпадают? |
| Вернуться наверх |
|
|
|
kapa |
Заголовок сообщения:
|
|
|
грозозащиты менять (убирать) пробовали? |
| Вернуться наверх |
|
|
|
MsHOME |
Заголовок сообщения:
|
|
|
Менять или убирать грозозащиты не пробовали, ибо стрёмно. |
| Вернуться наверх |
|
|
|
MsHOME |
Заголовок сообщения:
|
|
|
Demin Ivan писал(а): Вообщем по какой-то причине приходит небольшое кол-во битых пакетов. Настройки портов на обоих концах линка полностью совпадают? Как видите настроить порты можна только на оконечных устройствах и там оно стоит в автоматическом режиме. |
| Вернуться наверх |
|
|
|
kapa |
Заголовок сообщения:
|
|
|
MsHOME писал(а): Менять или убирать грозозащиты не пробовали, ибо стрёмно. Даже, если они исправны, то дело моет быть в них. |
| Вернуться наверх |
|
|
|
MsHOME |
Заголовок сообщения:
|
|
|
Согласен, в тех описании грозозащит описано, что вносимые затухания равны 10 метрам кабеля. |
| Вернуться наверх |
|
|
Кто сейчас на форуме |
|
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21 |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
Столкнулся с проблемой на MikroTik – ошибки в логах и отсутствие интернета на порту Ether1. Стал искать ответ в интернете, но решения не нашел. Существует предположение, что проблема появления ошибки interface,warning ether1 fcs error on link связана с наводками от кабелей 220v.
К сожалению, проблема не имеет стойкого графика появления. Цикл между ошибками разный, может быть неделя, а может быть и пару месяцев. Помогает либо полная перезагрузка MikroTik или отключение порта. До текущего момента мы делали это вручную, после был найден скрипт. К сожалению автора скрипта, найти не удалось. Но раз ошибка популярная, то думаю не лишним будет его указать, как решение проблемы.
Скрипт выглядит так:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
/system script add dont—require—permissions=no name=interface owner=admin policy= read,write,test source=«:local HOST «8.8.8.8»r n:local PINGCOUNT «30»r n:local INT «ether1″r n:local DELAY «10s»r n:local sub1 ([/system identity get name])r n:local sub2 ([/system clock get time])r n:local sub3 ([/system clock get date])r n:local ADMINMAIL1 «kuda@flammlin.com»r n:if ([/ping $HOST interval=1 count=$PINGCOUNT] = 0) do={r n:log error «HOST $HOST is not responding to ping request, reseting $I NT interface …»r n/interface disable $INTr n:log error «$INT is now disabled, waiting $DELAY …»r n:delay $DELAYr n/interface enable $INTr n:delay $DELAYr n:log error «$INT is now enabled»r n:log warning «Sending Email alert to $ADMINMAIL1 for Link reset …» r n/tool e-mail send to=$ADMINMAIL1 subject=»$INT got reset @ $sub3 $s ub2 $sub1″ start-tls=yesr n} else {r n:log warning «HOST $HOST ping is ok, no need to take any action …»; r n}» |
В промежуток времени (задается через планировщик) происходит запуск скрипта, который пингует доступность 8.8.8.8.
|
/system scheduler add interval=10m name=interface on—event=interface policy= ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon |
В случае успешного пинга в логах происходит запись:
|
script,warning HOST 8.8.8.8 ping is ok, no need to take any action ... |
Если пинг 8.8.8.8 не работает, то происходит отключение интерфейса ether1, через задержку происходит включение интерфейса ether1.
Появляется соответствующая запись в логах:
|
script,error HOST 1.8.8.8 is not responding to ping request, reseting ether2 interface ... |
Так же на почту происходит отправка сообщения, что интерфейс ether1 был перезапущен.
Introduction
This document describes how to understand errors from devices connected to Multigigabit Ethernet (mGig) ports on Catalyst 9000 Series Switches.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on these platforms: Catalyst 9000 series switches with mGig capable ports.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
This document describes why you can encounter frame check sequence (FCS) errors, input errors, or packet loss with devices that connect to Multigigabit Ethernet (mGig) ports on Catalyst 9000 series switches due to interpacket gap (IPG) or interframe gap (IFG) tolerance.
In networking, a pause could be required between network packets or network frames. This time between packets is known as the IPG or IFG. This pause is necessary to allow for receiver clock recovery, which permits the receiver to prepare for another packet. The IFG/IPG standard value for Gigabit Ethernet is 12 bytes. However, from IEEE Standard 802.3, the minimum value for the IFG can be as low as 8 bytes or 64 BT (bit times). For reference, this is documented in 802.3-2000 — IEEE Standard for Information Technology — LAN/MAN — Specific Requirements.
Problem Summary
Multigigabit Ethernet technology is implemented on 10Gig PHYs on Cat9000 architecture. For example, when a connection is established through an mGig port at 1Gbps, if traffic bursts higher than the bandwidth of the interface, the C9600 utilizes port buffers to accommodate that excess traffic and dynamically decreases the IFG/IPG size to avoid any impact and ensure traffic throughput and switch performance. The issue arises when some peer devices are unable to handle the smaller IFG/IPG sizes and no longer recognize legitimate packets and drop this traffic, which results in input errors on their NIC or PHY, such as Cyclic Redundancy Check (CRC) or FCS errors. In certain scenarios the local mGig port (an interface from the mGig linecard C9600-LC-48TX) can also experience the same type of loss in the form of input errors (CRC, FCS) on the interface.
As shown in the table, the structure of an Ethernet packet, which includes the IPG/IFG field:
|
Layer |
Preamble |
Start Frame Delimeter |
Destination MAC |
Source MAC |
802.1Q Tag |
Ethertype (Ethernet II) or length (IEEE 802.3) |
Payload |
Frame Check Sequence (32 bit CRC) |
IPG/IFG |
|
7 octets |
1 octet |
6 octets |
6 octets |
4 octets |
2 octets |
46-1500 octets |
4 octets |
≥ 8 octets |
|
|
Layer 2 Ethernet Frame |
64-1522 octets |
||||||||
|
Layer 1 Bits |
72-1530 octets |
≥ 8 octets |
Software Changes
Cisco has made changes to software for mGig capable Catalyst switches to accommodate devices that do not tolerate variance in the IPG/IFG. These changes are documented in various Cisco bug IDs.
|
Platform(s) Affected |
Bug ID and Resolution Status |
|
C9200L |
Fully resolved, see ‘Cisco bug ID CSCvy72944’ for more information. |
|
C9300-48UN |
Fully resolved, see Cisco bug ID CSCvw65866 for more information. |
|
C9300-48UXM |
Fully resolved, see ‘Cisco bug ID CSCvr95643’ for more information. |
|
C9300-48UXM |
Fully resolved, see ‘Cisco bug ID CSCvr13950 ‘for more information. |
|
C9600-LC-48TX |
Resolution in progress: Under rare circumstances, customers can still encounter issues that would have been resolved, see ‘Cisco bug ID CSCvz67689’ for more information. As a result of the rare issues documented previously, additional fixes are required, see ‘Cisco bug ID CSCwb31319’ for more information. |
Note: Only registered Cisco clients can access the bugs listed in this document.
Workarounds
In some cases, these interoperability issues can be mitigated through hard-coding the mGig port to a lower speed (100Mbps vs 1Gbps), utilization of a different speed (100Mbps or 10Gbps vs 1Gbps), or the affected device is moved to a non-mGig capable port.