Crc ошибки на порту коммутатора

Обновлено: 24.01.2025

In data communication, the receive end needs to detect whether any error occurs during data transmission. Common technologies for the error detection include parity check, checksum, and cyclic redundancy check (CRC). The transmit end calculates the verification code based on a certain algorithm and sends the verification code and message to the receive end. The receive end obtains the verification code from the received message based on the same algorithm and compares the verification code with the received verification code to determine whether the received message is correct.

That is, the CRC error packet statistics indicate the number of times the verification nodes obtained by the transmit and receive ends using the CRC mode do not match.

You can view the CRC error packet statistics in the output of the display interface command. Generally, CRC error packets indicate that service packets are lost on the link.

Procedure for Handling CRC Error Packets

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Run the display this interface command multiple times in the interface view to check the interface status, and check whether the discarded packet count and CRC error packet count at the physical layer keep increasing stably. The CRC error packets are usually caused by interference of network cables. If the error packet count keeps increasing, check the cable quality first. It is normal if a few CRC error packets are received. This is often caused by poor contact of network cables. In this case, remove and reinstall the cables.

Ensure that optical interfaces at both ends of a link work in the same auto-negotiation mode. If they work in non-auto-negotiation mode, ensure that the interfaces work at the same rate and in the same duplex mode.

It is recommended that idle fiber connectors be covered with dust-proof caps to keep the fiber connectors clean. An unclean fiber connector may degrade the quality of optical signals or even cause link failures or error codes on the link.

In the command output in step 2, the Transfer Distance field indicates the transmission distance supported the optical module. View this field to determine whether the optical fiber length is within the allowed transmission distance range of the optical module. For example, in the preceding command output, the transmission distance supported by the OM1 optical fiber is 30 m. If the actual transmission distance exceeds 30 m, use an optical fiber with a longer transmission distance.

Multimode optical modules must be used with multimode optical fibers. Single-mode optical modules are generally used with single-mode optical fibers, and can also be used with multimode optical fibers. If a single-mode optical module is used with a single-mode optical fiber, the transmission distance is often longer than 10 km.

Generally, a single-mode optical fiber is yellow, and a multimode optical fiber is orange.

Generally, the handle of a multimode optical module is black and that of a single-mode optical module is blue. You can also view the label attached to an optical module to check whether it is a single-mode or multimode optical module. SM and MM indicate single-mode and multimode, respectively.

If the optical modules have the same wavelength and the transmission distance between them is within the allowed range, but alarms on high or low optical power are still generated, the two optical modules may be from different vendors and of different types. Although they have same wavelength, their optical power specifications may be different due to different designs adopted by the vendors. This may also cause alarms on abnormal optical power. Replace the optical modules with optical modules of the same type certified for Huawei Ethernet switches.

Related Information

For more information about this problem and corresponding solutions, see the following document:

Нередко на сети хранения данных возникают такие неприятные вещи, как рост числа ошибок на портах и увеличение уровня затухания сигнала на sfp модулях. Принимая во внимание высокий уровень надежности SAN инфраструктуры, состоящей из двух и более фабрик, вероятность возникновения аварийной ситуации не так велика, но наложение негативных факторов может привести к потере данных или деградации производительности. К примеру, представьте себе ситуацию: на одной из фабрик проводится обновление FOS, все работает через вторую фабрику, а на ней между коммутатором к которому подключен дисковый массив и коммутатором к которому подключены серверы начинают быстро расти CRC ошибки на одном из транковых портов. Или еще хуже, пропадает линк из-за понижения уровня сигнала, вызванного повышением температуры SFP модуля, которая в свою очередь возросла из-за повысившейся утилизации данного канала. В таких случаях обычно говорят: «Ну кто же знал» или «100% надежных систем не бывает» и тд.

Грамотная архитектура + правильный мониторинг = отказоустойчивость

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

приведение архитектуры сети хранения данных в соответствие с «SAN best practices»
развертывание системы мониторинга

Что делать

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

Шаг первый, протокол сбора данных

Шаг второй, метод сбора данных

Для работы с ssh лучше всего адаптирован linux в связке bash+expect, этим методом можно подключаться по ssh с диалоговым вводом команд.

Шаг третий, где хранить

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

porterrshow.sh — сбор информации и поиск инкремента значений CRC ошибок
expect.tcl — подключение по ssh

и трех txt файлах:
temp.txt — буфер данных
switches.txt — список san свичей в формате имя логин пароль на каждой строке
crc.txt — отчет о найденных CRC ошибках

Select запрос ищет инкремент роста CRC ошибок по сравнению с данными полученными один час назад, соответственно запуск скрипта необходимо производить один раз в час, причем начать и закончить свою работу скрипт должен в одном и том же часу. Данное ограничение можно легко обойти, если ввести поле порядкового номера запуска скрипта, либо потерять в производительности и задать более сложное условие выборки значений времени. На сервере должны быть установлены пакеты expect, mysql и ssh клиент. В базе данных dbname должен присутствовать пользователь user с правами на чтение и запись в таблицу tablename. В таблице tablename получаем данные аналогичные выводу команды porterrshow на свиче + дата и время.

Данный пост о том, что будет если сварка оптики проведена некачественно, а контрольные измерения сфальсифицированы.
У заказчика устанавливали новое сетевое оборудование HP для внутренней LAN. Коммутаторы HP 5412zl объединенные 10Гб/с линками. Оптика была заранее подготовлена другим подрядчиком. После монтажа и настройки коммутаторов и системы мониторинга в логах одного коммутатора стали сыпаться ошибки:
W 03/03/15 09:33:04 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 09:34:05 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 09:44:00 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 09:53:54 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 09:58:00 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 10:01:25 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 10:05:52 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 10:08:36 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 10:09:17 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.
W 03/03/15 10:11:00 00329 FFI: AM1: port C3-Excessive CRC/alignment errors. See help.

Status and Counters - Port Counters for port C3

Name : _______trk3_______
MAC Address : 2c59e5-aaabbb
Link Status : Up
Totals (Since boot or last clear) :
Bytes Rx : 250,722,825 Bytes Tx : 1,573,512,656
Unicast Rx : 322,901,717 Unicast Tx : 330,113,038
Bcast/Mcast Rx : 2,627,746 Bcast/Mcast Tx : 63,041,624
Errors (Since boot or last clear) :
FCS Rx : 1,198,124 Drops Tx : 0
Alignment Rx : 0 Collisions Tx : 0
Runts Rx : 0 Late Colln Tx : 0
Giants Rx : 16,231 Excessive Colln : 0
Total Rx Errors : 1,214,355 Deferred Tx : 0
Others (Since boot or last clear) :
Discard Rx : 0 Out Queue Len : 0
Unknown Protos : 0
Rates (5 minute weighted average) :
Total Rx (Kbps) : 50,000 Total Tx (Kbps) : 50,048
Unicast Rx (Pkts/sec) : 38 Unicast Tx (Pkts/sec) : 39
B/Mcast Rx (Pkts/sec) : 2 B/Mcast Tx (Pkts/sec) : 25
Utilization Rx : 00.50 % Utilization Tx : 00.50 %

Transceiver in C3
Interface Index : 51
Type : SFP+LR
Model : J9151A
Connector Type : LC
Wavelength : 1310nm
Transfer Distance : 10.0km (9um),
Diagnostic Support : DOM

Status
Temperature : 32.945C
Voltage : 3.3211V
Tx Bias : 40.554mA
Tx Power : 0.6202mW, -2.075dBm
Rx Power : 0.0111mW , -19.546dBm

Уровень получаемого сигнала слишком слаб (для SFP), что приводит к потерям при передаче. Причиной стало плохая пайка кабеля в кассете оптического кросса.
Решение - переход на другое волокно в этом кабеле.

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

Счетчики ошибок при получении кадров (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

An estimate of the total number of collisions on this network segment.

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

Читайте также: