Ошибки на интерфейсах в Cisco || CRC || Collisions || Input/Output rate || Giants || Runts || throttles || Discards
Сетевым инженерам при поиске неполадок рекомендуется использовать многоуровневый подход (уровни с 1-7), в большинстве случаев они начинают смотреть более высокие уровни, игнорируя первый, который иногда гораздо более важен.
[slimterm]RT1R#show interface FastEthernet6/1
FastEthernet6/1 is up, line protocol is up (connected)
Hardware is C6k 100Mb 802.3, address is 0009.11f3.8848 (bia 0009.11f3.8848)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:14, output 00:00:36, output hang never
Last clearing of «show interface» counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1117058 packets input, 78283238 bytes, 0 no buffer
Received 1117035 broadcasts, 0 runts, 0 giants, 0 throttles
79 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
285811 packets output, 27449284 bytes, 0 underruns
6 output errors, 0 collisions, 2 interface resets
0 babbles, 1 late collision, 0 deferred
0 lost carrier, 0 no carrier
1 output buffer failures, 0 output buffers swapped out[/slimterm]
| Значение | Описание |
| FastEthernet6/1 is up, line protocol is up (connected) | Первое «up» относится к состоянию физического уровня интерфейса. Сообщение «line protocol up» отображает состояние уровня канала передачи данных интерфейса и говорит, что интерфейс может отправлять и получать информацию в реальном времени. Если в статусе administratively down то интерфейс был отключен администратором. |
| Hardware | Указывает тип и адрес аппаратного обеспечения |
| Internet address | Задает Internet адрес за которым следует маска подсети |
| MTU | Максимальная единица передачи интерфейса. По умолчанию 1500 байт |
| BW | Пропускная способность интерфейса в килобитах в секунду. |
| DLY | Задержка интерфейса в микросекундах. |
| Reliability | Надежность интерфейса как части 255 (255/255 — 100-процентная надежность), рассчитанная как экспоненциальная средняя за 5 минут. |
| Load | Нагрузка на интерфейс как часть 255 (255/255 полностью насыщена), рассчитанная как экспоненциальная средняя за 5 минут. |
| Encapsulation | Метод инкапсуляции, назначенный интерфейсу. |
| ARP type | Назначенный тип Address Resolution Protocol |
| Loopback | Указывает, установлена ли петля. |
| Keepalive | Указывает, установлены ли keepalives. |
| Last input | Выдает количество часов, минут и секунд с момента успешного приема последнего пакета интерфейсом. Это полезно для того, чтобы знать, когда произошёл сбой на интерфейсе. |
| Last output | Выдает количество часов, минут и секунд, прошедших с момента последней успешной передачи пакета интерфейсом. |
| Output | Указывает количество часов, минут и секунд, прошедших с момента успешной отправки последнего пакета интерфейсом. Это полезно для того, чтобы знать, когда произошёл сбой на интерфейса. |
| Output hang | Количество часов, минут и секунд (или никогда) с момента последнего сброса интерфейса из-за слишком долгой передачи. Когда количество часов в любом из последних полей превышает 24 часа, печатается количество дней и часов. Если это поле переполняется, печатаются звездочки |
| Output queue, input queue, drops | Выдает количество пакетов в выходных и входных очередях. За каждым номером следует косая черта, максимальный размер очереди и количество drop пакетов в полной очереди. |
| Five minute input rate, Five minute output rate | Среднее число бит и пакетов, переданных / принятых в секунду за последние 5 минут. |
| Packets input | Выдает общее количество безошибочных пакетов, полученных системой |
| Bytes input | Дает общее количество байтов, включая данные и инкапсуляцию MAC, в пакеты без ошибок, полученные системой. |
| No buffers | Количество входных пакетов, сброшенных из-за отсутствия буферов. Сравните с проигнорированным. |
| Broadcasts/Multicasts | Количество broadcast или multicast пакетов, полученных интерфейсом. |
| Runts | Фрэймы, принятые короче 64 байт |
| Giants | Полученные фрэймы размером более 1518 байт |
| Throttles | Количество раз, когда интерфейс запрашивал другой интерфейс в маршрутизаторе для замедления, возможно из-за перегрузки буфера или процессора. |
| Input error | Всего no buffer, runts, giants, CRCs, frame, overrun, ignored, и aborts. Это может не уравновешиваться с другими показателями. |
| CRC | Ошибка проверки циклического избыточности на входном пакете. |
| Frame | Число полученных кадров, которые не заканчивались на границе 8-битного байта |
| Overrun | Количество раз, когда аппаратура приемника не могла передать принятые данные в аппаратный буфер, потому что скорость ввода превышала способность приемника обрабатывать данные. |
| Ignored | Пакеты сброшены, потому что аппаратному буферу интерфейса не хватало внутренних буферов. Эти буферы отличаются от системных буферов, упомянутых ранее. |
| Input packets with dribble condition detected | Выдает ошибку бита, которая указывает, что кадр является слишком длинным. Этот счетчик ошибок кадров увеличивается только для информационных целей; Маршрутизатор принимает фрейм. |
| Packets output | Показывает общее количество сообщений, передаваемых системой. |
| Bytes | Показывает общее количество байтов, включая данные и инкапсуляцию MAC, переданных системой. |
| Under runs | Количество раз, которое передатчик работал быстрее, чем может обрабатывать маршрутизатор. Это может никогда не сообщаться на некоторых интерфейсах. |
| Dribble condition detected | Ошибка бита указывает, что кадр является слишком длинным. Этот счетчик ошибок кадров увеличивается только для информационных целей; Маршрутизатор принимает фрейм. |
| Output errors | Сумма всех выходных ошибок. Это может не совпадать с ошибкой вывода |
| Collisions | Количество фреймов, которые были успешно переданы после одной коллизии. (Передано со второй попытки.) |
| Interface resets | Количество попыток сброса интерфейса. Обычно результат пропущенных keepalives. |
| Output buffer failures | Количество раз, когда пакет не выводился из очереди вывода из-за нехватки MEMD памяти. |
| Output buffers swapped out | Количество пакетов, хранящихся в основной памяти, когда очередь на выходе заполнена; Перестановка буферов в основную память предотвращает отбрасывание пакетов при переполнении выходного потока. Значение высоко, когда трафик замусорен. |
| Babbles | Количество переданных фреймов больше 1518 байт |
| Deferred | Количество кадров, которые были успешно переданы после их ожидания, поскольку носитель был занят. |
| Late collision | Коллизия, которая возникает после того, как интерфейс начал передавать свой фрейм |
| No carrier | Количество раз, когда пересылка пакетов не прошла во время передачи. |
| Lost carrier | Количество раз, когда пересылка была остановлена при передаче. |
Более полную информацию Вы сможете просмотреть по следующим ссылкам:
Устранение неполадок на портах коммутатора
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Блог по сетевым технологиям и решениям
Поиск по этому блогу
понедельник, 9 марта 2015 г.
CRC ошибки на оптическом SFP порту коммутатора HP 5412zl
Данный пост о том, что будет если сварка оптики проведена некачественно, а контрольные измерения сфальсифицированы.
У заказчика устанавливали новое сетевое оборудование 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.
Что означает, что порт С3 отбрасывает кадры по причине неверной контрольной суммы.
Вот вывод статистики самого интерфейса:
# sh int 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 %
Видно, что на 323 миллиона принятых кадров, 1.2 миллиона были отброшено. При том, что нормой считается 1 кадр на 5000, здесь явное превышение этого порога.
Так как порт оптический то возможно посмотреть данные о самом SFP трансивере:
# sh interfaces transceiver c3 de
Transceiver in C3
Interface Index : 51
Type : SFP+LR
Model : J9151A
Connector Type : LC
Wavelength : 1310nm
Transfer Distance : 10.0km (9um),
Diagnostic Support : DOM
Типы ошибок (dlink)
Posted on 30 июля, 2014
RX (recive) — принимать пакеты приходящие от клиента
TX (transmit) передавать — пакеты приходящие к клиенту
Типы ошибок:
CRC Error — ошибки проверки контрольной суммы
Undersize — возникают при получение фрейма размером 61-64 байта.
Фрейм передается дальше, на работу не влияет
Oversize — возникают при получении пакета размером более 1518 байт и правильной контрольной суммой
Jabber — возникает при получении пакета размером более 1518 байт и имеющего ошибки в контрольной сумме
Drop Pkts — пакеты отброшенные в одном из трех случаев:
Какие пакеты входят в Drop Packets при выводе show error ports?
Переполнение входного буфера на порту
Пакеты, отброшенные ACL
Проверка по VLAN на входе
Fragment — количество принятых кадров длиной менее 64 байт (без преамбулы и начального ограничителя кадра, но включая байты FCS — контрольной суммы) и содержащих ошибки FCS или ошибки выравнивания.
Excessive Deferral — количество пакетов, первая попытка отправки которых была отложена по причине занятости среды передачи.
Collision — возникают, когда две станции одновременно пытаются передать кадр данных по общей сред
Late Collision — возникают, если коллизия была обнаружена после передачи первых 64 байт пакета
Excessive Collision — возникают, если после возникновения коллизии последующие 16 попыток передачи пакета окончались неудачей. данный пакет больше не передается
Single Collision — единичная коллизия
D-Link Switches: Tips & Tricks
суббота, 27 декабря 2014 г.
Значения счетчиков ошибок
Не всегда понятно что может означать та или иная ошибка при передаче. Ниже моя попытка объяснить значение счетчиков ошибок, которые регистрирует коммутатор.
Счетчики ошибок при получении кадров (RX):
CRC Error
Counts otherwise valid packets that did not end on a byte (octet) boundary.
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.
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.
Счетчик ошибок при отправке кадров (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
Неплохая расшифровка значений счетчиков приведена тут.
Бесплатный мониторинг CRC ошибок
Нередко на сети хранения данных возникают такие неприятные вещи, как рост числа ошибок на портах и увеличение уровня затухания сигнала на sfp модулях. Принимая во внимание высокий уровень надежности SAN инфраструктуры, состоящей из двух и более фабрик, вероятность возникновения аварийной ситуации не так велика, но наложение негативных факторов может привести к потере данных или деградации производительности. К примеру, представьте себе ситуацию: на одной из фабрик проводится обновление FOS, все работает через вторую фабрику, а на ней между коммутатором к которому подключен дисковый массив и коммутатором к которому подключены серверы начинают быстро расти CRC ошибки на одном из транковых портов. Или еще хуже, пропадает линк из-за понижения уровня сигнала, вызванного повышением температуры SFP модуля, которая в свою очередь возросла из-за повысившейся утилизации данного канала. В таких случаях обычно говорят: «Ну кто же знал» или «100% надежных систем не бывает» и тд.
Грамотная архитектура + правильный мониторинг = отказоустойчивость
Итак проблема обозначена, необходимо разработать комплекс мер по повышению отказоустойчивости сети хранения данных, его можно разделить на два этапа:
Что делать
И так, задача поставлена, необходимо найти путь решения, часто это может осложняться отсутствием денег в бюджете на этот год, или неосведомленностью интегратора о существовании подходящего ПО, но это не проблема т.к. все необходимые компоненты есть в свободном доступе и требуется лишь заставить это все работать.
Разберем реализацию мониторинга CRC ошибок на портах SAN свичей brocade, большинство остальных параметров можно мониторить аналогичным образом.
Шаг первый, протокол сбора данных
Информацию о числе CRC ошибок можно получать с коммутаторов разными способами (snmp, https, telnet и ssh) мой выбор пал на последний т.к. telnet не безопасен и его лучше отключать, https сложен для извлечения конкретных значений, а snmp дерево может значительно меняться как на разных свичах, так и при переходе на новый FOS.
Шаг второй, метод сбора данных
Для работы с 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 на свиче + дата и время.
