Received pause frames ошибка на портах

Для просмотра статистики работы порта используется команда

console# sh interfaces counters {interface }

Например, просмотр статистики с порта GigabitEthernet 0/12

console# sh interfaces counters GigabitEthernet 0/12

Статистика по принятым и переданным пакетам:

InOctets — Количество принятых байтов.

InUcastPkts -Количество принятых одноадресных пакетов.

InMcastPkts — Количество принятых многоадресных пакетов.

InBcastPkts — Количество принятых широковещательных пакетов.

OutOctets — Количество переданных байтов.

OutUcastPkts — Количество переданных одноадресных пакетов.

OutMcastPkts — Количество переданных многоадресных пакетов.

OutBcastPkts — Количество переданных широковещательных пакетов.

А также счетчики ошибок на interface:

Добрый день!

На коммутаторах SNR-S3650G-48S растут счётчики pause frame.

Пример:

Сделан сброс счётчиков на порту Ethernet1/0/11.

За 4 часа значение input счётчика Pause frame увеличилось с 0 до 2072.

Скорость передачи трафика на порту не поднималась выше 1,4 мбит/с (см. скрин во вложении)

Конфиг порта:

Interface Ethernet1/0/11
bandwidth control 307200 both
switchport mode trunk
switchport trunk allowed vlan 1;406;805

О коммутаторе:

 #sh ver
 SNR-S3650G-48S Device, Compiled on Nov 03 10:13:33 2014
 CPU Mac f8:f0:82:10:1c:0d
 Vlan MAC f8:f0:82:10:1c:0c
 SoftWare Version 7.0.3.5(B0207.0019)
 BootRom Version 7.1.5
 HardWare Version 1.0.1
 CPLD Version N/A
 Serial No.:SW032610D610000187
 Copyright (C) 2014 NAG LLC
 All rights reserved
 Last reboot is warm reset.
 Uptime is 29 weeks, 5 days, 2 hours, 43 minutes

Интерфейс

#sh interface Ethernet1/0/11
Interface brief:
 Ethernet1/0/11 is up, line protocol is up
 Ethernet1/0/11 is layer 2 port, alias name is test, index is 11
 Hardware is SFP, address is f8-f0-82-10-1c-0d
 PVID is 1
 MTU 1500 bytes, BW 1000000 Kbit
 Time since last status change:2w-4d-3h-43m-5s  (1568585 seconds)
 Encapsulation ARPA, Loopback not set
 Auto-duplex: Negotiation full-duplex, Auto-speed: Negotiation 1G bits
 FlowControl is off, MDI type is auto
Transceiver info:
 SFP found in this port, manufactured by OEM, on (null) 00 0.
 Type is 1000BASE-LX.  Serial number is SK130930130051.
 Link length is 3000 m for Single Mode Fiber.
 Nominal bit rate is 1300 Mb/s.
 Laser wavelength is 1310 nm.
Statistics:
 5 minute input rate 1672 bits/sec, 0 packets/sec
 5 minute output rate 8428 bits/sec, 12 packets/sec
 The last 5 second input rate 150 bits/sec, 0 packets/sec
 The last 5 second output rate 7914 bits/sec, 13 packets/sec
 Input packets statistics:
   90950 input packets, 10269217 bytes, 0 no buffer
   88698 unicast packets, 180 multicast packets, 0 broadcast packets
   0 input errors, 0 CRC, 0 frame alignment, 0 overrun, 0 ignored,
   0 abort, 0 length error, 2072 pause frame
 Output packets statistics:
   303433 output packets, 339803505 bytes, 0 underruns
   235756 unicast packets, 30487 multicast packets, 37190 broadcast packets
   0 output errors, 0 collisions, 0 late collisions, 0 pause frame

С Ethernet1/0/11 по оптике запущен DGS-1100-06/ME на котором Flow control отключён.

Есть и другие клиенты на чьих портах при аналогичной схеме подключения input счётчики Pause frame, у некоторых увеличиваются, а у некоторых остаются неизменными либо как у топикстартера незначительно увеличиваются.

Изменено 21 июня, 2015 пользователем alexdirty

Я как-то никогда не задумывался о том, как работает протокол LACP. Знаю, что делает, для чего нужен, а как передаются его сообщения никогда не интересовало.

Но некоторое время назад мне на глаза попался дамп трафика между двумя маршрутизаторами, где как раз были запросы LACP. Пробежал по нему мельком и глаз зацепился за незнакомое слово — Slow-Protocols.
На удивление информации об этом стандарте на русском языке я практически не нашёл. Есть только отсылки к тому, что это часть стандарта 802.3.

А меж тем вещь-то интересная, тем более, что охватывает не только LACP.
Вот об этом я и хотел устроить краткий ликбез под катом и рассказать ещё, какие проблемы можно словить при определённых условиях.

Итак, есть такой класс протоколов, которые призваны контролировать различные аспекты Ethernet, иначе говоря, Flow Control. Они являются частью стандарта 802.3 и делятся на два вида:

• Быстрые. Они должны отрабатывать моментально для предотвращения снижения производительности и перерыва в предоставлении сервисов вообще. Как правило они реализуются аппаратно. Собственно, представитель этого класса — механизм PAUSE – когда порт устройства получает трафика больше, чем может обработать, он отсылает PAUSE Frame противоположному узлу с просьбой понизить скорость отправки.
  

  Случаться такое может при подключении друг к другу разноскоростных интерфейсов — например FE в GE. Либо при настройке ограничения скорости на портах коммутаторов. Случаются даже казусы, но мне с такими проблемами дела иметь не приходилось.

  Однажны я сталкивался с Pause Frame в их несвойственном поведении. В тот день счётчики полученных PAUSE Frames стремительно росли на интерфейсах, система мониторинга тонула в авариях,

  дождь не прекращался 7-е сутки. Начали анализировать: количество трафика на данных интерфейсах едва переваливало за пару процентов, ни дропов, ни ошибок. Причём, что самое удивтельное, на противоположном конце устройство не отправляло эти самые PAUSE Frames — счётчики Pause Frame Output по нулям. Какая-то фанатастика, потому что промежуточных устройств даже транзитных нет.
  Путём глубокой отладки с участием разработчиков тогда выяснилось, что это какие-то внутренние железные заморочки — чип коммутации имеет маленький буфер и отправляет на линейную плату Pause Frames, чтобы она снизила активность, но всё это хитрым образом разруливается внутри коробки и никак не влияет на сервисы.

  Мехнизм «Паузы» — это технология для полнодуплексных ликнов. Для Half-Duplex существует Back Pressure. Он весьма строгий и не просто заставляет притормозить, а блокирует передачу данных, потому что фактически сообщает передающему коммутатору, что имеет место коллизия и нужно прекратить свои тщетные попытки. Но кого это сейчас волнует?

• Медленные – те самые Slow Protocols. У них не такие большие аппетиты на частоту отправки и задержки. Они реализуются программно. OAM и LACP относятся именно к этому виду.
  Для них используется специальный MAC-адрес: – 0180-с200-0002, и EtherType 8809.

Далее весьма вольный перевод данного документа, который является дополнением к стандарту 802.3.

Ограничения
Во-первых, на такого вида протоколы накладываются следующие ограничения:

1) Передавать не более 10 кадров в секунду
2) Максимальное число протоколов с EtherType 8809 — десять. Теоретически их может быть больше, но для них уже будет указан другой тип в заголовке Ethernet.
3) Размер кадра «медленных» протоколов ограничен 128 байтами. *Не сказать, что выполняется честно — OAMPDU, например, спокойно может превышать этот размер.

Вышеуказанные ограничения преследуют простую цель — уменьшить объём служебного трафика в сети.

Как для протоколов более высокого уровня существуют специально выделенные мультикастовые IP-адреса (224.0.0.5 для OSPF, например), так и «медленным» протоколам назначили отдельный мультикастовый MAC-адрес: 01-80-C2-00-00-02.

Данный МАС-адрес принадлежит диапазону выделенному ISO/IEC 15802-3 для протоколов, ограниченных одним линком. Фактически это означает, что кадры, передающиеся на данный адрес не могут быть перенаправлены за пределы данного конкретного линка.

Вполне возможно, что могут существовать «медленные» протоколы, которые требуют юникастовой пересылки кадра — это не воспрещается. То есть адрес 01-80-C2-00-00-02 — это не требование — это пожелание.
«Медленный» протокол может использовать другой МАС-адрес, но никакой другой протокол, кроме «медленного», не может использовать данный (01-80-C2-00-00-02).

Как уже я заметил выше, тип протоколов группы «Slow Protocols» (EtherType) — 8809. Далее определяются подтипы — subtypes для конкретных представителей сего славного класса:

Подтипы

Как видите, выделено 8 бит под подтип. О типе 10 поговорим чуть ниже, а с остальными всё понятно:
1 — обычный знакомый нам LACP

2 — также часть механизма LAG для балансировки нагрузки, упорядоченного получения кадров и оптимизации управления линками LAG.
3 — протоколы Ethernet OAM.

Как нужно вести себя при получении кадра Slow Protocols

1) Отбросить все кадры, в которых указаны запрещённые подтипы Slow protocols
2) Пропустить кадры, которые несут известные Slow протоколы (с известными подтипами) и передать их соответсвующим службам.
3) Пропустить кадры, которые несут валидные, но неизвестные протоколы и передать их MAC-клиенту.

OSSPDU

По сути, два известных нам сейчас протокола, которые используют этот стандарт — это LACP и OAM, но вообще-то есть возможность создать собственный «медленный» протокол по своим нуждам. Это и есть тот самый пункт десять — OSSP — Organization Specific Slow Protocol.

Это относится к приложению 57B, которое описывает рекомендации к реализации каких-то специфических протоколов.

Как и у других протоколов есть свои названия их кадров (LACPDU, OAMPDU, BPDU), у OSSP есть неки обобщённый термин для этих целей — OSSPDU.

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

В общем я убрал это поглубже.

Вот и весь сказ об этих нехитрых, но малоописанных в рунете протоколах.

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

Файл pcap для ковыряния.

Часть 1   Часть 2

Содержание

Самые распространенные команды по устранению неполадок портов и интерфейсов для CatOS и Cisco IOS
Основные сведения о выходных данных счетчиков портов и интерфейсов для CatOS и Cisco IOS
     Команды Show Port для CatOS и Show Interfaces для Cisco IOS
     Команды Show Mac для CatOS и Show Interfaces Counters для Cisco IOS
     Команды Show Counters для CatOS и Show Counters Interface для Cisco IOS
     Команда Show Controller Ethernet-Controller для Cisco IOS
     Команда Show Top для CatOS
Распространенные сообщения о системных ошибках
     Сообщения об ошибках в модулях WS-X6348
     %PAGP-5-PORTTO / FROMSTP и %ETHC-5-PORTTO / FROMSTP
     %SPANTREE-3-PORTDEL_FAILNOTFOUND
     %SYS-4-PORT_GBICBADEEPROM: / %SYS-4-PORT_GBICNOTSUPP
     Команда отклонена: [интерфейс] не является коммутационным портом

---

Основные сведения о выходных данных счетчиков портов и интерфейсов для CatOS и Cisco IOS

На большинстве коммутаторов имеется механизм отслеживания пакетов и ошибок, происходящих в интерфейсах и портах. Распространенные команды, используемые для нахождения сведений этого типа, описываются в разделе Самые распространенные команды по устранению неполадок портов и интерфейсов для CatOS и Cisco IOS данного документа.

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

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

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

В дуплексном режиме значение счетчиков ошибок последовательности FCS, контрольной суммы CRC, выравнивания и пакетов с недопустимо малой длиной должно быть минимальным. Если соединение работает в режиме полного дуплекса, счетчик конфликтов неактивен. Если показания счетчиков ошибок последовательности FCS, контрольной суммы CRC, выравнивания или пакетов с недопустимо малой длиной увеличиваются, проверьте соответствие дуплексных режимов. Для определения дуплексного режима вы можете обратиться в компанию выполняющую регулярное обслуживание сетевых устройств и компьютеров вашей организации. Несоответствие дуплексных режимов возникает, когда коммутатор работает в дуплексном режиме, а подключенное устройство — в полудуплексном, или наоборот. Следствиями несоответствия дуплексных режимов являются чрезвычайно медленная передача, периодические сбои подключения и потеря связи. Другие возможные причины ошибок канала передачи данных в полнодуплексном режиме — дефекты кабелей, неисправные порты коммутатора, программные или аппаратные неполадки сетевой платы. Дополнительные сведения см. в разделе Распространенные проблемы портов и интерфейсов данного документа.

Команды Show Port для CatOS и Show Interfaces для Cisco IOS

Команда show port {mod/port} используется в ОС CatOS в модуле Supervisor. Альтернатива этой команды — команда show port counters {mod/port}, которая отображает только счетчики ошибок портов. Описание выходных данных счетчиков ошибок см. в таблице 1.

   Switch> (enable) sh port counters 3/1  
   Port  Align-Err  FCS-Err    Xmit-Err   Rcv-Err    UnderSize
  ----- ---------- ---------- ---------- ---------- ---------
   3/1           0          0          0          0         0
   Port  Single-Col Multi-Coll Late-Coll  Excess-Col Carri-Sen Runts     Giants
  ----- ---------- ---------- ---------- ---------- --------- --------- ---------
   3/1          0         0         0           0            0         0         0
 

Команда show interfaces card-type {slot/port} — эквивалентная команда для Cisco IOS в модуле Supervisor. Альтернативой данной команды (для коммутаторов серии Catalyst 6000, 4000, 3550, 2970 2950/2955 и 3750) является команда show interfaces card-type {slot/port} counters errors , которая отображает счетчики ошибок интерфейсов.

Примечание: Для коммутаторов серии 2900/3500XL используйте только команду show interfaces card-type {slot/port} с командной show controllers Ethernet-controller .

 Router#sh interfaces fastEthernet 6/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

Команда show interfaces выдает на экран выходные данные до описанной здесь точки (по порядку):

• up, line protocol is up (connected) — Первое «up» относится к состоянию физического уровня интерфейса. Сообщение «line protocol up» показывает состояние уровня канала передачи данных для данного интерфейса и означает, что интерфейс может отправлять и принимать запросы keepalive.

• MTU – максимальный размер передаваемого блока данных (MTU) составляет 1500 байт для Ethernet по умолчанию (максимальный размер блока данных кадра).

• Full-duplex, 100Mb/s (полнодуплексный, 100 Мбит/с) — текущая скорость и режим дуплексирования для данного интерфейса. Но это не позволяет узнать, использовалось ли для этого автоматическое согласование.

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

• Последнее обнуление счетчиков «show interface» — время последнего применения команды clear counters после последней перезагрузки коммутатора. Команда clear counters используется для сброса статистики интерфейса.

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

• Очередь входа — число пакетов в очереди входа. Size/max/drops = текущее число кадров в очереди/максимальное число кадров в очереди (до начала потерь кадров)/фактическое число потерянных кадров из-за превышения максимального числа кадров. Сбросы используется для подсчета выборочного отбрасывания пакетов на коммутаторах серии Catalyst 6000 с ОС Cisco IOS. (Счетчик сбросов может использоваться, но его показания не увеличиваются на коммутаторах серии Catalyst 4000 с Cisco IOS.) Выборочное отбрасывание пакетов — механизм быстрого отбрасывания пакетов с низким приоритетом в случае перегрузки ЦПУ, чтобы сохранить некоторые вычислительные ресурсы для пакетов с высоким приоритетом.

• Общее число выходных сбросов – количество пакетов, сброшенных из-за заполнения очереди выхода. Типичной причиной этого может быть коммутация трафика из канала с высокой пропускной способностью в канал с меньшей пропускной способностью, либо коммутация трафика из нескольких входных каналов в один выходной канал. Например, если большой объем пульсирующего трафика поступает в гигабитный интерфейс и переключается на интерфейс 100 Мбит/с, это может вызвать увеличение отбрасывания исходящего трафика на интерфейсе 100 Мбит/с. Это происходит потому, что очередь выхода на указанном интерфейсе переполняется избыточным трафиком из-за несоответствия скорости входящей и исходящей полосы пропускания.

• Очередь выхода — число пакетов в очереди выхода. Size/max означает текущее число кадров в очереди/максимальное количество кадров, которое может находиться в очереди до заполнения, после чего начинается отбрасывание кадров.

• Пятиминутная скорость ввода/вывода – средняя скорость ввода и вывода, которая наблюдалась интерфейсом за последние пять минут. Чтобы получить более точные показания за счет указания более короткого периода времени (например, для улучшения обнаружения всплесков трафика), выполните команду интерфейса load-interval <секунды>.

В остальной части выходных данных команды show interfaces отображаются показания счетчиков ошибок, которые аналогичны или эквивалентны показаниям счетчиков ошибок в CatOS.

Команда show interfaces card-type {slot/port} counters errors эквивалентна команде Cisco IOS для отображения счетчиков портов для CatOS. Описание выходных данных счетчиков ошибок см. в таблице 1.

Router#sh interfaces fastEthernet 6/1 counters errors     
Port        Align-Err    FCS-Err   Xmit-Err    Rcv-Err   UnderSize    OutDiscards  Fa6/1               
                 0           0        0          0            0          0    
Port      Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen     Runts    Giants  Fa6/1
                 0        0        0         0           0         0       0

Таблица 1.

Сведения о счетчиках ошибок CatOS содержатся в выходных данных команды show port или show port counters для коммутаторов серии Cisco Catalyst 6000, 5000 и 4000. Сведения о счетчиках ошибок Cisco IOS содержатся в выходных данных команды show interfaces или show interfaces card-type x/y counters errors для коммутаторов серии Catalyst 6000 и 4000

Счетчики (в алфавитном порядке)	Описание и распространенные причины увеличения значений счетчиков ошибок
Align-Err	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Количество ошибок выравнивания определяется числом полученных кадров, которые не заканчиваются четным числом октетов и имеют неверную контрольную сумму CRC. Распространенные причины: они обычно являются результатом несоответствия дуплексных режимов или физической проблемы (такой как прокладка кабелей, неисправный порт или сетевая плата). При первом подключении кабеля к порту могут возникнуть некоторые из этих ошибок. Кроме того, если к порту подключен концентратор, ошибки могут вызвать конфликты между другими устройствами концентратора. Исключения для платформы: ошибки выравнивания не подсчитываются в Catalyst 4000 Series Supervisor I (WS-X4012) или Supervisor II (WS-X4013).
Перекрестные помехи	Описание: Cisco IOS sh interfaces счетчик. Счетчик CatOS, указывающий на истечение срока таймера передачи сбойных пакетов. Сбойный пакет — это кадр длиной свыше 1518 октетов (без кадрирующих битов, но с октетами FCS), который не заканчивается четным числом октетов (ошибка выравнивания) или содержит серьезную ошибку FCS).
Carri-Sen	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Значение счетчика Carri-Sen (контроль несущей) увеличивается каждый раз, когда контроллер Ethernet собирается отослать данные по полудуплексному соединению. Контроллер обнаруживает провод и перед передачей проверяет, не занят ли он. Распространенные причины: это нормально для полудуплексного сегмента Ethernet.
конфликты	Описание: Cisco IOS sh interfaces счетчик. Число конфликтов, произошедших до того, как интерфейс успешно передал кадр носителю. Распространенные причины: это нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством.
CRC	Описание: Cisco IOS sh interfaces счетчик. Значение данного счетчика увеличивается, когда контрольная сумма CRC, сгенерированная исходящей станцией ЛВС или устройством на дальнем конце, не соответствует контрольной сумме, рассчитанной по принятым данным. Распространенные причины: обычно это означает проблемы с шумами или передачей в интерфейсе ЛВС или самой ЛВС. Большое значение счетчика CRC обычно является результатом конфликтов, но может указывать на физическую неполадку (такую как проводка кабелей, неправильный интерфейс или неисправная сетевая плата) или несоответствие дуплексных режимов.
deferred	Описание: Cisco IOS sh interfaces счетчик. Число кадров, успешно переданных после ожидания освобождения носителя. Распространенные причины: они обычно наблюдаются в полудуплексных средах, в которых несущая уже используется при попытке передачи кадра.
pause input	Описание: Cisco IOS show interfaces счетчик. Приращение значения счетчика «pause input» означает, что подключенное устройство запрашивает приостановку трафика, когда его буфер приема почти заполнен. Распространенные причины: приращение показаний этого счетчика служит в информационных целях, так как коммутатор принимает данный кадр. Передача пакетов с запросом приостановки прекращается, когда подключенное устройство способно принимать трафик.
input packetswith dribble condition	Описание: Cisco IOS sh interfaces счетчик. Битовая ошибка указывает, что кадр слишком длинный. Распространенные причины: приращение показаний счетчика ошибок в кадрах служит в информационных целях, так как коммутатор принимает данный кадр.
Excess-Col	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Количество кадров, для которых передача через отдельный интерфейс завершилась с ошибкой из-за чрезмерного числа конфликтов. Избыточный конфликт возникает, когда для некоторого пакета конфликт регистрируется 16 раз подряд. Затем пакет отбрасывается. Распространенные причины: чрезмерное количество конфликтов обычно обозначает, что нагрузку на данный сегмент необходимо разделить между несколькими сегментами, но может также указывать на несоответствие дуплексных режимов с присоединенным устройством. На интерфейсах, сконфигурированных в качестве полнодуплексных, конфликты наблюдаться не должны.
FCS-Err	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Число кадров допустимого размера с ошибками контрольной последовательности кадров (FCS), но без ошибок кадрирования. Распространенные причины: обычно это указывает на физическую проблему (такую как прокладка кабелей, неисправный порт или сетевая плата), однако также может означать несоответствие дуплексных режимов.
кадр	Описание: Cisco IOS sh interfaces счетчик. Число неправильно принятых пакетов с ошибками контрольной суммы CRC и нецелым числом октетов (ошибка выравнивания). Распространенные причины: обычно это вызвано конфликтами или физической проблемой (например, проводкой кабелей, неисправным портом или сетевой платой), а также может указывать на несоответствие дуплексных режимов.
Кадры с недопустимо большой длиной	Описание: CatOS sh port и Cisco IOS sh interfaces и sh interfaces counters errors. Полученные кадры, размеры которых превышают максимально допускаемые стандартом IEEE 802.3 (1518 байт для сетей Ethernet без поддержки jumbo-кадров) и обладают неверной последовательностью FCS. Распространенные причины: во многих случаях это следствие поврежденной сетевой интерфейсной платы. Попробуйте найти проблемное устройство и удалить его из сети. Исключения для платформ: коммутаторы серии Catalyst Cat4000 с Cisco IOS версии, предшествующей 12.1(19)EW, показания счетчика кадров с недопустимо большой величиной увеличиваются в случае кадра размером > 1518 байтов. После версии 12.1(19)EW кадры giant в выходных данных команды show interfaces учитываются только в случае приема кадра размером > 1518 байтов с неверной последовательностью FCS.
ignored	Описание: Cisco IOS sh interfaces счетчик. Количество полученных пакетов, проигнорированных интерфейсом из-за недостатка места во внутренних буферах оборудования интерфейса. Распространенные причины: широковещательный шторм и всплески помех могут вызвать рост показаний данного счетчика.
Ошибки ввода	Описание: Cisco IOS sh interfaces счетчик. Распространенные причины: в счетчике учитываются ошибки кадров, кадры с недопустимо маленькой или недопустимо большой величиной, кадры, отброшенные из-за переполнения буфера, несоответствия значения контрольной суммы CRC или перегрузки, а также проигнорированные пакеты. Другие ошибки, относящиеся к входным данным, также могут увеличивать количество ошибок ввода; некоторые датаграммы могут содержать несколько ошибок. Поэтому эта сумма может не совпадать с суммой перечисленных ошибок ввода. Также см. раздел Ошибки ввода в интерфейсе уровня 3, подключенном к порту коммутатора уровня 2.
Late-Col	Описание: CatOS sh port и Cisco IOS sh interfaces и sh interfaces counters errors. Количество обнаруженных конфликтов в определенном интерфейсе на последних этапах процесса передачи. Для порта со скоростью 10 Мбит/с это позднее, чем время передачи 512 битов для пакета. В системе со скоростью передачи данных 10 Мбит/с 512 битовых интервалов соответствуют 51,2 микросекунды. Распространенные причины: это ошибка, в частности, может указывать на несоответствие дуплексных режимов. В сценарии с несоответствием дуплексных режимов на стороне с полудуплексным режимом наблюдается поздний конфликт. Во время передачи со стороны с полудуплексным режимом на стороне с дуплексным режимом выполняется одновременная передача без ожидания своей очереди, что приводит к возникновению позднего конфликта. Поздние конфликты также могут указывать на слишком большую длину кабеля или сегмента Ethernet. На интерфейсах, сконфигурированных в качестве полнодуплексных, конфликты наблюдаться не должны.
lost carrier	Описание: Cisco IOS sh interfaces счетчик. Число потерь несущей во время передачи. Распространенные причины: проверьте исправность кабеля. Проверьте физическое соединение на обеих сторонах.
Multi-Col	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Число множественных конфликтов произошедших до того, как порт успешно передал кадр носителю. Распространенные причины: это нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством.
no buffer	Описание: Cisco IOS sh interfaces счетчик. Число принятых пакетов, которые отвергнуты из-за отсутствия буферного пространства. Распространенные причины: сравните со счетчиком пропущенных пакетов. Часто такие ошибки вызываются широковещательными штормами.
Отсутствует несущая	Описание: Cisco IOS sh interfaces счетчик. Сколько раз несущая отсутствовала во время передачи. Распространенные причины: проверьте исправность кабеля. Проверьте физическое соединение на обеих сторонах.
Out-Discard	Описание: количество исходящих пакетов, которые выбраны для отбрасывания несмотря на отсутствие ошибок Распространенные причины: одна возможная причина отбрасывания таких пакетов — освобождение буферного пространства.
output buffer failuresoutput buffers swapped out	Описание: Cisco IOS sh interfaces счетчик. Число буферов с ошибками и число выгруженных буферов. Распространенные причины: порт размещает пакеты в буфере Tx, когда скорость поступающего в порт трафика высока и порт не может обработать такой объем трафика. Порт начинает пропускать пакеты в случае заполнения буфера Tx, при этом увеличиваются значения счетчиков недогрузок и сбоев выходных буферов. Увеличение значений счетчиков сбоев выходных буферов может означать, что порты работают с минимальными настройками скорости и/или дуплексного режима, или через порт проходит слишком большой объем трафика. Например, рассмотрите сценарий, в котором гигабайтный многоадресный поток пересылается 24 портам с пропускной способностью 100 Мбит/с. Если выходной интерфейс перегружен, обычно наблюдаются сбои выходного буфера, число которых растет вместе с числом выходящих отброшенных пакетов (Out-Discards). Сведения об устранении неполадок см. в разделе Отложенные кадры (Out-Lost или Out-Discard) данного документа.
output errors	Описание: Cisco IOS sh interfaces счетчик. Сумма всех ошибок, препятствовавших целевой передаче датаграмм от заданного интерфейса.
overrun (переполнение)	Описание: сколько раз аппаратному оборудованию приемника не удалось поместить принятые данные в аппаратный буфер. Распространенные причины: входящая скорость трафика превысила способность приемника к обработке данных.
packets input/output	Описание: Cisco IOS sh interfaces счетчик. Общее количество безошибочных пакетов, полученных и переданных на данном интерфейсе. Мониторинг приращений показаний этих счетчиков полезен при проверке правильного прохождения трафика через интерфейс. Счетчик байтов включает эти данные и инкапсуляцию MAC-адресов в безошибочные пакеты, принятые и переданные системой.
Rcv-Err	Описание: CatOS show port или show port counters и Cisco IOS (только для коммутаторов серии Catalyst 6000) «sh interfaces counters error». Распространенные причины: см. исключения для платформ. Исключения для платформ: коммутаторы серии Catalyst 5000 rcv-err = сбои буферов приема. Например, кадры недопустимо маленькой или недопустимо большой величины или ошибки последовательности FCS (FCS-Err) не приводят к увеличению значения счетчика rcv-err. Значение счетчика rcv-err для 5K увеличивается только в случае избыточного трафика. В отличие от коммутаторов серии Catalyst 5000 на коммутаторах серии Catalyst 4000 значение rcv-err равно сумме всех ошибок приема, т.е. значение счетчика rcv-err увеличивается в случае регистрации таких ошибок, как прием интерфейсом кадров с недопустимо маленькой или недопустимо большой величиной или ошибки последовательности FCS.
Кадры с недопустимо маленькой величиной	Описание: CatOS sh port и Cisco IOS sh interfaces и sh interfaces counters errors. Принятые кадры с размером меньше минимального размера кадра IEEE 802.3 (64 байта для Ethernet) и неверной контрольной суммой CRC. Распространенные причины: это может быть вызвано несоответствием дуплексных режимов и физическими проблемами, такими как неисправный кабель, порт или сетевая плата на присоединенном устройстве. Исключения для платформ: на коммутаторах серии Catalyst 4000 с Cisco IOS версии, предшествующей версии 12.1(19)EW, кадры с недопустимо маленькой величиной — это кадры размера undersize. Undersize = кадр < 64 байтов. Значение счетчика кадров с недопустимо маленькой величиной увеличивается при получении кадра размером менее 64 байтов. После версии 12.1(19)EW кадр с недопустимо маленькой величиной = фрагмент. Фрагмент — это кадр < 64 байта с неверной контрольной суммой CRC. В результате значение счетчика кадров с недопустимо маленькой величиной увеличивается в show interfacesвместе со счетчиком фрагментов в show interfaces counters errors при получении кадра < 64 байтов с неверной контрольной суммой CRC.
Single-Col	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Число конфликтов, произошедших до того, как интерфейс успешно передал кадр носителю. Распространенные причины: это нормальное явление для полудуплексных интерфейсов, но не для полнодуплексных интерфейсов. Быстрый рост числа конфликтов указывает на высокую загрузку соединения или возможное несоответствие дуплексных режимов с присоединенным устройством.
underruns	Описание: сколько раз скорость передатчика превышала возможности коммутатора. Распространенные причины: это может происходить в случае высокой пропускной способности, когда через интерфейс проходит большой объем пульсирующего трафика от многих других интерфейсов одновременно. В случае недогрузки возможен сброс интерфейса.
Undersize	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Полученные фреймы с размером меньше минимального размера фрейма в стандарте IEEE 802.3, равного 64 байтам (без битов кадрирования, но с октетами FCS), но хорошо сформированных во всем остальном. Распространенные причины: проверьте устройство, отправляющее такие кадры.
Xmit-Err	Описание: CatOS sh port и Cisco IOS sh interfaces counters errors. Это указывает на заполнение внутреннего буфера отправки (Tx). Распространенные причины: часто ошибки Xmit-Err возникают из-за передачи трафика из канала с высокой пропускной способностью в канал с меньшей пропускной способностью или трафика из нескольких входящих каналов в один исходящий. Например, если большой объем пульсирующего трафика поступает в гигабитный интерфейс и переключается на интерфейс на 100 Мбит/с, на 100-мегабитном интерфейсе это может вызывать приращение значения счетчика Xmit-Err. Это происходит потому, что выходной буфер заданного интерфейса переполняется избыточным трафиком из-за несоответствия скорости входящей и исходящей полосы пропускания.

Команды Show Mac для CatOS и Show Interfaces Counters для Cisco IOS

Команда show mac {mod/port} полезна при использовании CatOS в модуле Supervisor для отслеживания входящего и исходящего трафика данного порта в соответствии с показаниями счетчиков приема (Rcv) и передачи (Xmit) для трафика одноадресной, многоадресной и широковещательной рассылки. Эти выходные данные получены от Catalyst 6000, использующего CatOS:

Console> (enable) sh mac 3/1      Port     Rcv-Unicast          Rcv-Multicast        Rcv-Broadcast 

  -------- -------------------- -------------------- --------------------    

3/1                      177               256272                 3694     

 Port     Xmit-Unicast         Xmit-Multicast       Xmit-Broadcast

   -------- -------------------- -------------------- --------------------  

  3/1                       30               680377                  153     

 Port     Rcv-Octet            Xmit-Octet  

 -------- -------------------- -------------------- 

  3/1                 22303565             48381168      MAC   

   Dely-Exced MTU-Exced  In-Discard Out-Discard 

  -------- ---------- ---------- ---------- -----------  

  3/1              0          0     233043          17     

 Port  Last-Time-Cleared  

 ----- --------------------------    

3/1  Sun Jun 1 2003, 12:22:47 

В данной команде также используются следующие счетчики ошибок: Dely-Exced, MTU-Exced, In-Discard и Out-Discard.

• Dely-Exced — количество кадров, отклоненных данным портом из-за чрезмерной задержки передачи данных через коммутатор. Показания данного счетчика растут только при очень интенсивном использовании порта.

• MTU Exceed — это показатель того, что одно из устройств на данном порту или сегменте передает объем данных больше, чем разрешено размером кадра (1518 байт для сети Ethernet без поддержки jumbo-кадров).

• In-Discard – результат обработки допустимых входящих кадров, которые были отброшены, поскольку их коммутация не требовалась. Это может быть нормальным, если концентратор подключен к порту и два устройства на данном концентраторе обмениваются данными. Порт коммутатора продолжает видеть данные, но не переключает его (так как в таблице CAM отображается MAC-адрес обоих устройств, связанных с одним и тем же портом). Поэтому трафик отбрасывается. Значение данного счетчика также увеличивается в случае порта, настроенного в качестве магистрали, если данная магистраль блокирует некоторые сети VLAN, или в случае порта, который является единственным членом некоторой сети VLAN.

• Out-Discard (Число отбрасываемых исходящих пакетов) – число исходящих пакетов, которые выбраны для отбрасывания несмотря на отсутствие ошибок. Одна из возможных причин отбрасывания таких пакетов — освобождение буферного пространства.

• In-Lost — на коммутаторах серии Catalyst 4000; этот счетчик представляет собой сумму всех пакетов с ошибками, полученных данным портом. С другой стороны на коммутаторах серии Catalyst 5000 счетчик In-Lost отслеживает сумму всех сбоев буферов приема.

• Out-Lost — на коммутаторах серии Catalyst 4000 и 5000 учитываются исходящие кадры, которые были потеряны до пересылки (из-за недостатка буферного пространства). Обычно это вызывается перегрузкой порта.

Команда show interfaces card-type {slot/port} counters используется при выполнении Cisco IOS в модуле Supervisor.

Команда show counters [mod/port] предоставляет еще более подробную статистику для портов и интерфейсов. Эта команда доступна для CatOS, а эквивалентная ей команда show counters interface card-type {slot/port} была введена в Cisco IOS версии 12.1(13)E только для коммутаторов серии Catalyst 6000. Эти команды отображают 32- и 64-разрядные счетчики ошибок для каждого порта или интерфейса. Дополнительные сведения см. в документации по командам CatOS show counters.

Команда Show Controller Ethernet-Controller для Cisco IOS

На коммутаторах серии Catalyst 3750, 3550, 2970, 2950/2955, 2940 и 2900/3500XL используйте команду «show controller ethernet-controller» для отображения выходных данных счетчика трафика и счетчика ошибок, которые аналогичны выходным данным команд sh port, sh interface, sh mac и show counters для коммутаторов серии Catalyst 6000, 5000 и 4000.

Счетчик	Описание	Возможные причины
Переданные кадры
Отброшенные кадры	Общее количество кадров, попытка передачи которых прекращена из-за недостатка ресурсов. В это общее количество входят кадры всех типов назначения.	Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного интерфейса. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный интерфейс.
Устаревшие кадры	Число кадров, передача которых через коммутатор заняла более двух секунд. По этой причине они были отброшены коммутатором. Это случается только в условиях экстремально высокой нагрузки.	Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного коммутатора. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный коммутатор. Может потребоваться изменение топологии сети, чтобы снизить нагрузку трафиком данного коммутатора.
Deferred frames (отложенные кадры)	Общее число кадров, первая попытка передачи которых была отложена из-за трафика в сетевом носителе. В это общее число входят только кадры, которые в последствии передаются без ошибок и конфликтов.	Отбрасывание кадров вызвано чрезмерной нагрузкой трафика, направленного к данному коммутатору. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный коммутатор. Может потребоваться изменение топологии сети, чтобы снизить нагрузку трафика на данный коммутатор.
Collision frames (кадры с конфликтами)	В счетчиках кадров с конфликтами содержится число пакетов, одна попытка передачи которых была неудачной, а следующая — успешной. Это означает, что в случае увеличения значения счетчика кадров с конфликтами на 2, коммутатор дважды неудачно пытался передать пакет, но третья попытка была успешной.	Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного интерфейса. Если в этих полях наблюдается рост числа пакетов, уменьшите нагрузку на данный интерфейс.
Excessive collisions (частые конфликты)	Значение счетчика частых конфликтов возрастает после возникновения 16 последовательных поздних конфликтов. Через 16 попыток отправки пакета, он отбрасывается, а значение счетчика возрастает.	Увеличение значения этого счетчика указывает на проблему с проводкой, чрезмерно загруженную сеть или несоответствие дуплексных режимов. Чрезмерная загрузка сети может быть вызвана совместным использованием сети Ethernet слишком большим числом устройств.
Late collisions (поздние конфликты)	Поздний конфликт возникает, когда два устройства передают одновременно, но конфликт не обнаруживается ни одной из сторон соединения. Причина этого заключается в том, что время передачи сигнала с одного конца сети к другому превышает время, необходимое, чтобы поместить целый пакет в сеть. Два устройства, вызвавшие поздний конфликт, никогда не видят пакет, отправляемый другим устройством, пока он не будет полностью помещен в сеть. Поздние конфликты обнаруживаются передатчиком только после истечения первого временного интервала для передачи 64 байтов. Это связано с тем, что конфликты обнаруживаются только при передаче пакетов длиннее 64 байтов.	Поздние конфликты являются следствием неправильной прокладки кабелей или несовместимого числа концентраторов в сети. Неисправные сетевые платы также могут вызывать поздние конфликты.
Хорошие кадры (1 конфликт)	Общее число кадров, которые испытали только один конфликт, а затем были успешно переданы.	Конфликты в полудуплексной среде — обычное ожидаемое поведение.
Хорошие кадры (> 1 конфликта)	Общее число кадров, которые испытали от 2 до 15 конфликтов включительно, а затем были успешно переданы.	Конфликты в полудуплексной среде — обычное ожидаемое поведение. По мере приближения к верхнему пределу данного счетчика для таких кадров возрастает риск превышения 15 конфликтов и причисления к частым конфликтам.
Отброшенные кадры сети VLAN	Число кадров, отброшенных интерфейсом из-за задания бита CFI.	Биту Canonical Format Indicator (CFI) в TCI кадра 802.1q задается значение 0 для канонического формата кадра Ethernet. Если биту CFI задано значение 1, это указывает на наличие поля сведений о маршрутизации (RIF) или неканонического кадра Token Ring, который отброшен.
Received Frames (принятые кадры)
No bandwidth frames (кадры с недостатком пропускной способности)	Только 2900/3500XL. Количество раз, которое порт принимал пакеты из сети, но у коммутатора не было ресурсов для его принятия. Это случается только в условиях высокой нагрузки, но может произойти и в случае всплесков трафика на нескольких портах. Таким образом, небольшое число в поле «No bandwidth frames» – не повод для беспокойства. (Оно должно оставаться намного меньше одного процента принятых кадров.)	Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного интерфейса. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный интерфейс.
No buffers frames (кадры без буфера)	Только 2900/3500XL. Количество раз, которое порт принимал пакеты из сети, но у коммутатора не было ресурсов для его принятия. Это случается только в условиях высокой нагрузки, но может произойти и в случае всплесков трафика на нескольких портах. Таким образом, небольшое число в поле «No buffers frames» – не повод для беспокойства. (Оно должно оставаться намного меньше одного процента принятых кадров.)	Отбрасывание кадров вызвано чрезмерной нагрузкой трафиком данного интерфейса. Если в этом поле наблюдается рост числа пакетов, уменьшите нагрузку на данный интерфейс.
No dest, unicast (одноадресные пакеты без назначения)	Это число одноадресных пакетов, которые не были пересланы данным портом другим портам.	Ниже дается краткое описание случаев, когда значение счетчиков «No dest» (unicast, multicast и broadcast) может возрастать. Если порт является точкой доступа и подключен к магистральному порту Inter-Switch Link Protocol (ISL), счетчик «No dest» принимает очень большие значения, так как все входящие ISL-пакеты не пересылаются. Это недопустимая конфигурация. Если порт блокирован протоколом STP, большинство пакетов не пересылается, что приводит к увеличению пакетов без назначения. Сразу после того, как порт установил соединение, в течение очень короткого промежутка времени (менее одной секунды) входящие пакеты не пересылаются. Если данный порт находится в некоторой сети VLAN, а все остальные порты коммутатора этой сети VLAN не принадлежат, все входящие пакеты отбрасываются, а значение счетчика увеличивается. Значение счетчика также возрастает при определении адреса назначения пакета в порту, в котором этот пакет был принят. Если пакет был принят в порту 0/1 с MAC-адресом назначения X, а коммутатор уже определил, что MAC-адрес X находится в порту 0/1, значение счетчика увеличивается, а пакет отбрасывается. Это может происходить в следующих ситуациях. Если концентратор подключен к порту 0/1, а подключенная к нему рабочая станция передает пакеты другой рабочей станции, подключенной к этому же концентратору, порт 0/1 никуда не пересылает этот пакет, так как MAC-адрес находится в том же порту. Это также может произойти, если для определения MAC-адресов коммутатор, подключенный к порту 0/1, начинает наводнять пакетами все свои порты. Если на другом порту той же сети VLAN настроен статический адрес, а для принимающего порта статический адрес не задан, то пакет отбрасывается. Например, если статическое сопоставление MAC-адреса X было настроено в порту 0/2 для пересылки трафика порту 0/3, то пакет должен быть получен портом 0/2 или будет отброшен. Если пакет отправляется от любого другого порта в сети VLAN, которой принадлежит порт 0/2, то пакет отбрасывается. Если порт является защищенным, пакеты с запрещенными исходными MAC-адресами не пересылаются, а значение счетчика увеличивается.
No dest, multicast (многоадресные пакеты без назначения)	Это число многоадресных пакетов, которые не были пересланы данным портом другим портам.
No dest,broadcast (широковещательные пакеты без назначения)	Это число широковещательных пакетов, которые не были пересланы данным портом другим портам.
Alignment errors (ошибки выравнивания)	Ошибки выравнивания определяются числом полученных кадров, которые не заканчиваются четным количеством октетов и имеют неверную контрольную сумму CRC.	Ошибки выравнивания вызываются неполным копированием кадра в канал, что приводит к фрагментированным кадрам. Ошибки выравнивания являются результатом конфликтов при несоответствии дуплексных режимов, неисправном оборудовании (сетевой плате, кабеле или порте), или подключенное устройство генерирует кадры, не завершающиеся октетом, или с неверной последовательностью FCS.
FCS errors (ошибки FCS)	Число ошибок последовательности FCS соответствует числу кадров, принятых с неверной контрольной суммой (CRC) в кадре Ethernet. Такие кадры отбрасываются и не передаются на другие порты.	Ошибки FCS являются результатом конфликтов в случае несоответствия дуплексных режимов, неисправного оборудования (сетевая плата, кабель или порт) или кадров с неверной последовательностью FCS, формируемых подключенным устройством.
Undersize frames (неполномерные кадры)	Это общее число принятых пакетов с длиной менее 64 октетов (без битов кадрирования, но с октетами FCS) и допустимым значением FCS.	Это указывает на поврежденный кадр, сформированный подключенным устройством. Убедитесь, что подключенное устройство функционирует правильно.
Oversize frames (кадры избыточного размера)	Число принятых портом из сети пакетов с длиной более 1514 байтов.	Это может указывать на сбой оборудования либо проблемы конфигурации режима магистрального соединения для dot1q или ISL.
Collision fragments (фрагменты с конфликтами)	Общее число кадров с длиной менее 64 октетов (без битов кадрирования, но с октетами FCS) и неверным значением FCS.	Увеличение значения этого счетчика указывает на то, что порты настроены на полудуплексный режим. Установите в настройках дуплексный режим.
Overrun frames (кадры с переполнением)	Количество раз, которое оборудованию приемника не удалось поместить принятые данные в аппаратный буфер.	Входящая скорость трафика превысила способность приемника к обработке данных.
VLAN filtered frames (кадры, отфильтрованные по сети VLAN)	Общее число кадров, отфильтрованных по типу содержащейся в них информации о сети VLAN.	Порт можно настроить на фильтрацию кадров с тегами 802.1Q. При получении кадра с тегом 802.1Q он фильтруется, а значение счетчика увеличивается.
Source routed frames (кадры с маршрутом источника)	Общее число полученных кадров, которые были отброшены из-за задания бита маршрута источника в адресе источника собственного кадра.	Этот тип маршрутизации источников определен только для Token Ring и FDDI. Спецификация IEEE Ethernet запрещает задание этого бита в кадрах Ethernet. Поэтому коммутатор отбрасывает такие кадры.
Valid oversize frames (допустимые кадры избыточного размера)	Общее число полученных кадров с длиной, превышающей значение параметра System MTU, но с правильными значениями FCS.	В данном случае собирается статистика о кадрах с длиной превышающей настроенное значение параметра System MTU, размер которых можно увеличить с 1518 байтов до размера, разрешенного для инкапсуляции Q-in-Q или MPLS.
Symbol error frames (кадры с ошибками символа)	В Gigabit Ethernet (1000 Base-X) используется кодирование 8B/10B для преобразования 8-битных данных из MAC-подуровня (уровень 2) в 10-битный символ для отправки по проводу. Когда порт получает символ, он извлекает 8-битные данные из данного символа (10 битов).	Символьная ошибка означает, что интерфейс обнаружил прием неопределенного (недопустимого) символа. Небольшое число символьных ошибок можно игнорировать. Большое число символьных ошибок может указывать на неисправность устройства, кабеля или оборудования.
Invalid frames, too large (недопустимые кадры, слишком большие)	Кадры с недопустимо большой величиной или полученные кадры с неверной последовательностью FCS, размер которых превышает размер максимального кадра в IEEE 802.3 (1518 байт для сетей Ethernet без поддержки jumbo-кадров).	В большинстве случаев это является следствием поврежденной сетевой интерфейсной платы. Попробуйте найти проблемное устройство и удалить его из сети.
Invalid frames, too small (недопустимые кадры, слишком маленькие)	Кадры с недопустимо маленькой величиной или кадры, размером менее 64 байта (с битами FCS, но без заголовка кадра) и недопустимым значением FCS или ошибкой выравнивания.	Это может произойти из-за несоответствия дуплексных режимов и физических проблем, таких как неисправный кабель, порт или сетевая плата на подключенном устройстве.

Команда Show Top для CatOS

Команда show top позволяет собирать и анализировать данные о каждом физическом порте коммутатора. Данная команда для каждого физического порта отображает следующие данные:

• уровень загрузки порта (Uti %)

• число входящих и исходящих байтов (Bytes)

• число входящих и исходящих пакетов (Pkts)

• число входящих и исходящих пакетов широковещательной рассылки (Bcst)

• число входящих и исходящих пакетов многоадресной рассылки (Mcst)

• число ошибок (Error)

• число ошибок переполнения буфера (Overflow)

Примечание: При вычислении уровня загрузки порта данная команда объединяет строки Tx и Rx в один счетчик, а также определяет пропускную способность в дуплексном режиме при вычислении процента загруженности. Например, порт Gigabit Ethernet работает в дуплексном режиме с пропускной способностью 2000 Мбит/с.

Число ошибок (in Errors) представляет сумму всех пакетов с ошибками, полученных данным портом.

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

Также см. значения счетчиков «In-Lost» и «Out-Lost» в выходных данных команды show mac .

Распространенные сообщения о системных ошибках

В Cisco IOS иногда используется различный формат для системных сообщений. Для сравнения можно проверить системные сообщения CatOS и Cisco IOS. Описание выпусков используемого программного обеспечения см. в руководстве Сообщения и процедуры восстановления. Например, можно прочитать документ Сообщения и процедуры восстановления для ПО CatOS версии 7.6 и сравнить его с содержимым документа Сообщения и процедуры восстановления для выпусков Cisco IOS 12.1 E.

Сообщения об ошибках в модулях WS-X6348

Просмотите следующие сообщения об ошибках.

• Coil Pinnacle Header Checksum (контрольная сумма заголовка Coil/Pinnacle)

• Ошибка состояния компьютера Coil Mdtif

• Ошибка контрольной суммы пакета Coil Mdtif.

• Ошибка «Coil Pb Rx Underflow»

• Ошибка четности Coil Pb Rx

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

%SYS-5-SYS_LCPERR5:Module 9: Coil Pinnacle Header Checksum Error - Port #37

При появлении этого типа сообщений или в случае сбоя группы портов 10/100 в модулях WS-X6348 см. в следующих документах дальнейшие советы по устранению неполадок в зависимости от используемой операционной системы.

%PAGP-5-PORTTO / FROMSTP и %ETHC-5-PORTTO / FROMSTP

В CatOS используйте команду show logging buffer для просмотра сохраненных сообщений журнала. Для Cisco IOS используйте команду show logging .

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

В программном обеспечении CatOS версии 7.x или выше «PAGP-5» изменено на «ETHC-5», чтобы сделать данное сообщение более понятным.

Это сообщение характерно для коммутаторов серии Catalyst 4000, 5000 и 6000 с ПО CatOS. Для коммутаторов с ПО Cisco IOS нет сообщений об ошибках, эквивалентных данному.

%SPANTREE-3-PORTDEL_FAILNOTFOUND

Это сообщение не указывает на проблему с коммутатором. Оно обычно возникает вместе с сообщениями %PAGP-5-PORTFROMSTP.

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

Это сообщение характерно для коммутаторов серии Catalyst 4000, 5000 и 6000 с ПО CatOS. Для коммутаторов с ПО Cisco IOS нет сообщений об ошибках, эквивалентных данному. 

%SYS-4-PORT_GBICBADEEPROM: / %SYS-4-PORT_GBICNOTSUPP

Наиболее распространенная причина появления этого сообщения заключается в установке несертифицированного стороннего (не Cisco) конвертера GBIC в модуль Gigabit Ethernet. У такого конвертера GBIC нет памяти Cisco SEEPROM, что приводит к созданию сообщения об ошибке.

GBIC-модули WS-G5484, WS-G5486 и WS-G5487, используемые с WS-X6408-GBIC, также могут вызвать появление таких сообщений об ошибках, однако реальных проблем с данными платами и GBIC-модулями нет, а для программного обеспечения есть обновленное исправление.

Команда отклонена: [интерфейс] не является коммутационным портом

В коммутаторах, поддерживающих и интерфейсы L3, и коммутационные порты L2, сообщение Команда отклонена: [интерфейс] не является коммутационным портом отображается при попытке ввода команды, относящейся к уровню2, для порта, который настроен в качестве интерфейса уровня 3.

Чтобы преобразовать данный интерфейс из режима уровня 3 в режим уровня 2, выполните команду настройки интерфейса switchport. После применения этой команды настройте для данного порта требуемые свойства уровня 2.

Часть 4

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

Помогите локализовать проблемму — ошибки с udp-пакетами

Помогите локализовать проблемму — ошибки с udp-пакетами

Сообщение midn » 10.08.2009 14:30

Может, не совсем в этот форум — но очень интересная ситуация.
Есть программа для сбора flow — flow-tools. Она собирает т.н. Flow-траффик с маршрутизаторов. На сервере поднимается демон — flow-capture. При запуске указывается порт udp, на котором он будет принимать пакеты, директорию, где складывать файлы, период ротации и пр.
Была машина — 32 bit x86, 4 Gb памяти, debian 3.0. Там стоял flow-capture версии 0.66

Обьем данных, что идет на этот порт — довольно большой. В сутки в сжатом виде собирается порядка 80 Gb. Скорость на интерфейсе — порядка 20-25Mbit/s.

Сейчас поставили более мощную машину — x86_64, Centos 5.2 x86_64,
8 Gb памяти. В разы мощней старой машины. Обновили и версию flow-tools — поставил 0.68-4. Перевели сбор флоу на новую машину — и получили неприятный сюрприз. Размер файла раз в 10-20 стал меньше, чем за аналогичный период времени, но на старой машине.
Стал копать.
Ifconfig -a показывает 0 ошибок на примем и передачу.
А вот netstat -su (статистика по udp-пакетам) показал

Udp:
2712928083 packets received
3743615 packets to unknown port received.
14582447 packet receive errors
60633183 packets sent
Раздел
packet receive errors
увеличивался чуть ли не 1000 пакетов в сек.

Перезапуск программы ничего не дал.

Стал подкручивать параметры ядра.

Итак,
uname -a
2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

в файле sysctl.conf

# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536

# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
kernel.sem = 250 32000 100 128
kernel.msgmni = 2878
net.ipv4.ip_local_port_range = 1024 65000
fs.file-max = 65536
fs.aio-max-nr = 4194304
kernel.shmmni = 4096

net.core.wmem_default = 4194304
net.core.wmem_max = 16777216
net.core.rmem_default = 8388608
net.core.rmem_max = 67108864
net.ipv4.tcp_rmem = 8388608 12582912 16777216
net.ipv4.tcp_wmem = 8388608 12582912 16777216
net.ipv4.tcp_mem = 8388608 12582912 16777216

net.ipv4.udp_wmem_min = 4194304
net.ipv4.udp_rmem_min = 8388608
net.ipv4.udp_mem = 8388608 33554432 67108864

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600

# For huge UDP traffic
net.unix.max_dgram_qlen = 120

net.core.netdev_max_backlog = 30000 # number of unprocessed input packets before
# kernel starts dropping them, default 300

Перезапустил машину — какое-то время все было нормально.
netstat -su показывал, что поле packet receive errors не меняется. А потом раз — и опять то же самое. Перезапустил программу — опять все нормально. Потом опять раз — и та же беда.
На старой машине стоял компилятор gcc-3
На новой —
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)

И на старой было 32 битная программа, на новой машине я собрал 64-битную версию.
Решил постепенно идти — вначале собрал 32-битную версию программы — не помогло. Взял со старой машины бинарный файл, запустил — то же самое — работает, работает — может днями работать нормально — а потом раз — и пошел расти packet receive errors.

Собрал на старой машине gcc-3 пакет версии 0.68-4 (было подозрение, что может с компилятором 4 версии что не так, ибо пакет 0.68 4 версией компилятора не собирается). Тоже не помогло.

Ситуация такая — работает прогрмма, периодически проверяется, не растет ли поле packet receive errors. Если оно резко растет — то надо перезапускать программу. Перезапуск программы на какое-то время спасает — но потом опять растут ошибки —
и надо перезапускать.
Насколько я понял —
ifconfig -a — он показывает, что на уровне драйвера сетевой платы ошибок в приеме пакетов нет

RX packets:8498323782 errors:0 dropped:0 overruns:0 frame:2

А вот netstat -su — это уже дальше по стэку — ошибки на уровне udp.
Т.е., либо сама программа, либо где-то на уровне ядра начинается резкое либо сбрасывание этих пакетов, либо они начинают портиться.

И тут вопрос — это проблема с программой или все же на уровне ядра может быть какая-то ошибка или какой-то параметр надо подркутить? Как это посмотреть?
Я, увы, не настолько силен в отладчике ядра — но может есть какие-то более-менее понятные методы, как посмотреть — какая программа или какой уровень ядра порождает эти ошибки?

Источник

Receive Packet Errors with VDS Health Check and Jumbo Frames

My team setup a new VDS in a greenfield site with 9000 MTU (at the VDS level) since the new location was jumbo frame enabled. Management, VMotion, NFS, and FT vmkernels were set to 9000 MTU and there were some guest distributed port groups. We ended up dropping the MTU for the Management vmkernel to 1500 when we found some routers in that location that did not support 9000. We enabled VDS health check for VLAN/MTU to verify that we were getting the appropriate MTU and VLANs to our hosts.

The linux team had a vlan that was being used by physical servers as well as VMs. On the physical servers they had configured their nic for 1500 MTU.

For some reason, they started to see excessive Rx Errors
RX packets:74975060 errors:254276 dropped:0 overruns:0 frame:254276

This was setting off their monitoring and giving them some grief.
Suspecting something with jumbo frames, they increased the MTU on a physical server to 9000 and ran wireshark.
They identified broadcast or multicast packets that were larger than 1500 and all started with “00:50:56” which is the manufacturer code for VMware.

We attempted to identify if there was a VM or a VMkernel sending these broadcasts, but we could not find a MAC address that matched the ones from the Wireshark.

The Linux team looked at the capture again and noticed that the packet type was “unknown (0x8922)” which lead to the forums.

Apparently 0x8922 broadcasts and the random MACs are used by VDS Health Check to validate VLAN and MTUs.

Remember earlier when I said we setup the VDS at 9000 MTU? Apparently that includes all of the distributed port groups as well. The way that the VLAN and MTUs are verified is that a broadcast packet is sent with the MTU that the VDS is set to (in this case 9000) across that VLAN/DPG. If the host on the other end receives it without fragmenting, then VMware knows that the VLAN is good and the MTU is good. If the packet is received but it had to be fragmented, then the VLAN is good but the MTU is not. If there is no packet received, then the VLAN is most likely not trunked in.

We don’t see this issue on the VMs probably because VMware either filters those out or has some sort of smarts to know that these shouldn’t be counted as errors for the VMs.

The problem is that the physical servers don’t know what that 0x8922 packet is, and since they are set to 1500 MTU, end up with Rx errors.

So the solution?

• The obvious solution (for me) would be to change the VDS global setting to 1500 MTU so that the port groups are checked at 1500, the VMkernels can remain at 9000 while the default for the switch is 1500 (see kb). You would have to be careful to create the VMkernels at 9000 though since this is not the default (not a problem for us since we use host profiles for this location).
  • Unfortunately I did try this in non-prod and I saw hosts flicker on and off (I believe setting the MTU will cause the hosts to disconnect the networks and reconnect to renegotiate at the new MTU) and some hosts didn’t take the change at all. This could be due to the use of LACP in this environment, or it could just be something specific to MTU changes
• A solution from the linux side would be to separate the physical servers onto a dedicated subnet. Re-ip ing the hosts and moving to nics to a new VLAN isn’t the easiest of tasks though.
• The last solution (more of a stopgap) would be to just turn off VDS Health Check for VLAN/MTU. I did open a SR with VMware to see if I could only do a VLAN check at a lower MTU or tweak the MTU checks per portgroup (blog post courtesy of virtuallyghetto William Lam. Unfortunately the only thing that can be done is to change the frequency of the VLAN/MTU check (response from Vmware below):
  • 1) Is there a way to do ONLY VLAN checking and not MTU?

    No. Even at the api level you enable them together.
    You can modify the interval of the check, for instance you can set it to check once per hour, so there wouldn’t be so many errors on the physical hosts.
    Please review http://blogs.vmware.com/vsphere/2012/12/configuring-vds-network-health-check-interval-using-vsphere-api.html for a description on a perl script that can do it
    Also, please note that at GSS we don’t provide or test script as a rule.

    2) Is there a way to change the MTU check per portgroup?
    No. The MTU is set at the dvSwitch level, and all portgroups share the same MTU.
    You could create a new vDS switch with the portgroups you want to have 1500 MTU, but you would need extra uplinks for this.

At the end of the day I ended up turning off VDS Health Check for VLAN/MTU since it was the easiest thing to do. It’s really not a long term solution though since ensuring VLAN (and MTU) consistency is really important (we’ve been bitten in the past). I am hoping that I can bring up a new VDS and try to migrate hosts between the two, though I realize that this may be difficult with LACP.

Источник

Total Packets Received with MAC Errors

• Mark as New
• Bookmark
• Subscribe
• Subscribe to RSS Feed
• Permalink
• Print
• Report Inappropriate Content

Does anyone know what «Total Packets Received with MAC Errors» errors are?

I am getting a load of these on a GS728TP coming in to a fiber interface, and I cant find any reference anywhere on the web as to what exactly these types of error are.

Is it the source or destination MAC of the packet that is causing the problem?

Has anyone got any ideas on how to pin down further where these errors might be coming from?

• Mark as New
• Bookmark
• Subscribe
• Subscribe to RSS Feed
• Permalink
• Print
• Report Inappropriate Content

Thanks very much, it is odd that phrase doesn’t turn up anywhere in google if it’s in your manual, but there we go.

Swapping out the patch cable seems to be what has fixed it anyway.

• Mark as New
• Bookmark
• Subscribe
• Subscribe to RSS Feed
• Permalink
• Print
• Report Inappropriate Content

Welcome to the community!

As per page 214 of the GS728TP software administration manual here, the Total Packets Received with MAC Errors is the total number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.

If you want to find out on what ports are the packets with MAC errors are received, I suggest you to set up port mirroring on the GS728TP switch. Select a port(s) as a source port(s) on the GS728TP switch. Then, select another port as a destination port on the GS728TP switch where a PC with Wireshark installed in it is directly connected. Run Wireshark and observe. It would be best that Wireshark would capture the packets with MAC errors from the source port(s).

Kindly read pages 223-224 of the GS728TP software administration manual here on how to set up port mirroring. You may download Wireshark on this link. As reference, you may check this link I found online on how to use Wireshark.

For the captured packets to be analyzed, kindly open a chat or online support ticket with NETGEAR Support regarding your concern. Attach the captured packets from Wireshark on the support ticket you have opened for it to be analyzed by the NETGEAR Support team.

Источник

Adapter Cards Counters

On This Page

Adapter cards counters are used to provide information on Operating System, application, service or the drivers’ performance. Counters can be used for different system debugging purposes, help to determine system bottlenecks and fine-tune system and application performance. The Operating System, network, and devices provide counter data that the application can consume to provide users with a graphical view of the system’s performance quality.

WinOF-2 counters hold the standard Windows CounterSet API that includes:

• Network Interface
• RDMA activity
• SMB Direct Connection

Mellanox WinOF-2 Port Traffic

Mellanox WinOF-2 Port Traffic counters set consists of counters that measure the rates at which bytes and packets are sent and received over a port network connection. It includes counters that monitor connection errors.

Shows the number of bytes received by network adapter. The counted bytes include framing characters.

Shows the rate at which kilobytes are received by a network adapter. The counted kilobytes include framing characters.

Shows the number of packets received by a network interface.

Shows the rate at which packets are received by a network interface.

Shows the number of bytes sent by a network adapter. The counted bytes include framing.

Shows the rate at which kilobytes are sent by a network adapter. The counted kilobytes include framing characters.

Shows the number of packets sent by a network interface.

Shows the rate at which packets are sent by a network interface.

Shows the total of bytes handled by a network adapter. The counted bytes include framing characters.

Shows the total rate of kilobytes that are sent and received by a network adapter. The counted kilobytes include framing characters.

Shows the total of packets handled by a network interface.

Shows the rate at which packets are sent and received by a network interface.

The total number of successfully received control frames.

Note: This counter is relevant only for ETH ports

Packets Outbound Errors

Shows the number of outbound packets that could not be transmitted because of errors found in the physical layer.a

Packets Outbound Discarded

Shows the number of outbound packets to be discarded in the physical layer, even though no errors had been detected to prevent transmission. One possible reason for discarding packets could be to free up buffer space.

Packets Received Errors

Shows the number of inbound packets that contained errors in the physical layer, preventing them from being deliverable.

Packets Received Frame Length Error

Shows the number of inbound packets that contained error where the frame has length error. Packets received with frame length error are a subset of packets received errors.a

Packets Received Symbol Error

Shows the number of inbound packets that contained symbol error or an invalid block. Packets received with symbol error are a subset of packets received errors.

Packets Received Bad CRC Error

Shows the number of inbound packets that contained bad CRC error. Packets received with bad CRC error are a subset of packets received errors.

Packets Received Discarded

No Receive WQEs — Packets discarded due to no receive descriptors posted by driver or software.

Number of RSC abort events. That is, the number of exceptions other than the IP datagram length being exceeded. This includes the cases where a packet is not coalesced because of insufficient hard-ware resources.

RSC Coalesced Events

Number of RSC Coalesced events. That is, the total number of packets that were formed from coalescing packets.

Note: This counter is relevant only for ETH ports

RSC Coalesced Octets

Number of RSC Coalesced bytes.

Note: This counter is relevant only for ETH ports

RSC Coalesced Packets

Number of RSC Coalesced Packets.

Note: This counter is relevant only for ETH ports

RSC Average Packet Size

RSC Average Packet Size is the average size in bytes of received packets across all TCP connections.

Note: This counter is relevant only for ETH ports

Mellanox WinOF-2 VF Port Traffic

Mellanox WinOF2 VF Port Traffic counters exist per each VF and are created according to the adapter’s configurations. These counters are created upon VFs configuration even if the VFs are not up.

Mellanox WinOF-2 VF Port Traffic counters set consists of counters that measure the rates at which bytes and packets are sent and received over a virtual port network connection that is bound to a virtual PCI function. It includes counters that monitor connection errors.

This set is available only on hypervisors and not on virtual network adapters.

These counters set is relevant only for ETH ports.

Shows the rate at which bytes are received over each network VPort. The counted bytes include framing characters.

Bytes Received Unicast/Sec

Shows the rate at which subnet-unicast bytes are delivered to a higher-layer protocol.

Bytes Received Broadcast/Sec

Shows the rate at which subnet-broadcast bytes are delivered to a higher-layer protocol.

Bytes Received Multicast/Sec

Shows the rate at which subnet-multicast bytes are delivered to a higher-layer protocol.

Packets Received Unicast/Sec

Shows the rate at which subnet-unicast packets are delivered to a higher-layer protocol.

Packets Received Broadcast/Sec

Shows the rate at which subnet-broadcast packets are delivered to a higher-layer protocol.

Packets Received Multicast/Sec

Shows the rate at which subnet-multicast packets are delivered to a higher-layer protocol.

Shows the rate at which bytes are sent over each network VPort. The counted bytes include framing characters.

Bytes Sent Unicast/Sec

Shows the rate at which bytes are requested to be transmitted to subnet-unicast addresses by higher-level protocols. The rate includes the bytes that were discarded or not sent.

Bytes Sent Broadcast/Sec

Shows the rate at which bytes are requested to be transmitted to subnet-broadcast addresses by higher-level protocols. The rate includes the bytes that were discarded or not sent.

Bytes Sent Multicast/Sec

Shows the rate at which bytes are requested to be transmitted to subnet-multicast addresses by higher-level protocols. The rate includes the bytes that were discarded or not sent.

Packets Sent Unicast/Sec

Shows the rate at which packets are requested to be transmitted to subnet-unicast addresses by higher-level protocols. The rate includes the packets that were discarded or not sent.

Packets Sent Broadcast/Sec

Shows the rate at which packets are requested to be transmitted to subnet-broadcast addresses by higher-level protocols. The rate includes the packets that were discarded or not sent.

Packets Sent Multicast/Sec

Shows the rate at which packets are requested to be transmitted to subnet-multicast addresses by higher-level protocols. The rate includes the packets that were discarded or not sent.

Packets Outbound Discarded

Shows the number of outbound packets to be discarded even though no errors had been detected to prevent transmission. One possible reason for discarding a packet could be to free up buffer space.

Packets Outbound Errors

Shows the number of outbound packets that could not be transmitted because of errors.

Packets Received Discarded

Shows the number of inbound packets that were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.

Packets Received Errors

Shows the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol.

Mellanox WinOF-2 Port QoS

Mellanox WinOF-2 Port QoS counters set consists of flow statistics per (VLAN) priority. Each QoS policy is associated with a priority. The counter presents the priority’s traffic, pause statistic.

These counters set is relevant only for ETH ports.

The number of bytes received that are covered by this priority. The counted bytes include framing characters (modulo 2^64).

The number of kilobytes received per second that are covered by this priority. The counted kilobytes include framing characters.

The number of packets received that are covered by this priority (modulo 2^64).

The number of packets received per second that are covered by this priority.

The number of bytes sent that are covered by this priority. The counted bytes include framing characters (modulo 2^64).

The number of kilobytes sent per second that are covered by this priority. The counted kilobytes include framing characters.

The number of packets sent that are covered by this priority (modulo 2^64).

The number of packets sent per second that are covered by this priority.

The total number of bytes that are covered by this priority. The counted bytes include framing characters (modulo 2^64).

The total number of kilobytes per second that are covered by this priority. The counted kilobytes include framing characters.

The total number of packets that are covered by this priority (modulo 2^64).

The total number of packets per second that are covered by this priority.

Sent Pause Duration

The total duration of packets transmission being paused on this priority in microseconds.

Sent Pause Frames

The total number of pause frames sent from this priority to the far-end port.

The untagged instance indicates the number of global pause frames that were sent.

Received Pause Frames

The number of pause frames that were received to this priority from the far-end port.

The untagged instance indicates the number of global pause frames that were received.

Received Pause Duration

The total duration that far-end port was requested to pause for the transmission of packets in microseconds.

RDMA Activity

RDMA Activity counters set consists of NDK performance counters. These performance counters allow you to track Network Direct Kernel (RDMA) activity, including traffic rates, errors, and control plane activity.

RDMA Accepted Connections

The number of inbound RDMA connections established.

RDMA Active Connections

The number of active RDMA connections.

RDMA Completion Queue Errors

This counter is not supported, and always is set to zero.

RDMA Connection Errors

The number of established connections with an error before a consumer disconnected the connection.

RDMA Failed Connection Attempts

The number of inbound and outbound RDMA connection attempts that failed.

RDMA Inbound Bytes/sec

The number of bytes for all incoming RDMA traffic. This includes additional layer two protocol overhead.

RDMA Inbound Frames/sec

The number, in frames, of layer two frames that carry incoming RDMA traffic.

RDMA Initiated Connections

The number of outbound connections established.

RDMA Outbound Bytes/sec

The number of bytes for all outgoing RDMA traffic. This includes additional layer two protocol overhead.

RDMA Outbound Frames/sec

The number, in frames, of layer two frames that carry outgoing RDMA traffic.

Mellanox WinOF-2 Congestion Control

Mellanox WinOF-2 Congestion Control counters set consists of counters that measure the DCQCN statistics over the network adapter.

These counters set is relevant only for ETH ports.

Notification Point — CNPs Sent Successfully

Number of congestion notification packets (CNPs) successfully sent by the notification point.

Notification Point — RoCEv2 DCQCN Marked
Packets

Number of RoCEv2 packets that were marked as congestion encountered.

Reaction Point — Current Number of Flows

Current number of Rate Limited Flows due to RoCEv2 Congestion Control.

Reaction Point — Ignored CNP Packets

Number of ignored congestion notification packets (CNPs).

Reaction Point — Successfully Handled CNP Packets

Number of congestion notification packets (CNPs) received and handled successfully.

Mellanox WinOF-2 Diagnostics

Mellanox WinOF-2 Diagnostics counters set consists of the following counters:

Number of resets requested by NDIS.

Link State Change Events

Number of link status updates received from the hardware.

Link State Change Down Events

Number of events received from the hardware, where the link state was changed to down.

Minor Stall Watermark Reached

Number of times the device detected a stalled state for a period longer than device_stall_minor_watermark.

Note: This counter is relevant only for ETH ports

Critical Stall Watermark Reached

Number of times the port detected a stalled state for a period longer than device_stall_critical_watermark.

Note: This counter is relevant only for ETH ports

Head of Queue timeout Packet discarded

Number of packets discarded by the transmitter due to Head-Of-Queue Lifetime Limit timeout.

Note: This counter is relevant only for ETH ports

Stalled State Packet discarded

Number of packets discarded by the transmitter due to TC in Stalled state.

Note: This counter is relevant only for ETH ports

Requester CQEs flushed with error

Number of requester CQEs flushed with error flowing queue transition to error state.

Send queues priority

The total number of QP/SQ priority/SL update events.

Async EQ Overrun

The number of times an EQ mapped to Async events queue encountered overrun queue.

Completion EQ Overrun

The number of times an EQ mapped to Completion events queue encountered overrun queue.

Current Queues Under Processor Handle

The current number of queues that are handled by the processor due to an Async error (e.g. retry exceeded) or due to a CMD error (e.g. 2eer_qp cmd).

Total Queues Under Processor Handle

The total number of queues that are handled by the processor due to an Async error (e.g. retry exceeded) or due to a CMD error (e.g. 2eer_qp cmd),

Queued Send Packets

Number of send packets pending transmission due to hardware queues overflow.

Send Completions in Passive/Sec

Number of send completion events handled in passive mode per second.

Receive Completions in Passive/Sec

Number of receive completion events handled in passive mode per second.

Packets Received dropped due to Steering

Number of packets that completed the NIC Receive FlowTable steering and were discarded due to lack of match rule in Flow Table.

Copied Send Packets

Number of send packets that were copied in slow path.

Correct Checksum Packets In Slow Path

Number of receive packets that required the driver to perform the checksum calculation and resulted in success.

Bad Checksum Packets In Slow Path

Number of receive packets that required the driver to perform checksum calculation and resulted in failure.

Undetermined Checksum Packets In Slow Path

Number of receive packets with undetermined checksum result.

Watch Dog Expired/Sec

Number of watch dogs expired per second.

Requester time out received

Number of time out received when the local machine generates outbound traffic.

Requester out of order sequence NAK

Number of Out of Sequence NAK received when the local machine generates outbound traffic, i.e. the number of times the local machine received NAKs indicating OOS on the receiving side.

Requester RNR NAK

Number of RNR (Receiver Not Ready) NAKs received when the local machine generates outbound traffic.

Responder RNR NAK

Number of RNR (Receiver Not Ready) NAKs sent when the local machine receives inbound traffic.

Responder out of order sequence received

Number of Out of Sequence packets received when the local machine receives inbound traffic, i.e. the number of times the local machine received messages that are not consecutive.

Responder duplicate request received

Number of duplicate requests received when the local machine receives inbound traffic.

Requester RNR NAK retries exceeded errors

Number of RNR (Receiver Not Ready) NAKs retries exceeded errors when the local machine generates outbound traffic.

Responder Local Length Errors

Number of times the responder detected local length errors

Requester Local Length Errors

Number of times the requester detected local length errors

Responder Local QP Operation Errors

Number of times the responder detected local QP operation errors

Local Operation Errors (a.k.a Requester Local QP Operation Errors)

Responder Local Protection Errors

Number of times the responder detected memory protection error in its local memory subsystem

Requester Local Protection Errors

Number of times the requester detected a memory protection error in its local memory subsystem

Responder CQEs with Error

Number of times the responder flow reported a completion with error

Requester CQEs with Error

Number of times the requester flow reported a completion with error

Responder CQEs Flushed with Error

Number of times the responder flow completed a work request as flushed with error

Requester CQEs Flushed with Error

Number of times the requester completed a work request as flushed with error

Requester Memory Window Binding Errors

Number of times the requester detected memory window binding error

Requester Bad Response

Number of times an unexpected transport layer opcode was returned by the responder

Requester Remote Invalid Request Errors

Number of times the requester detected remote invalid request error

Responder Remote Invalid Request Errors

Number of times the responder detected remote invalid request error

Requester Remote Access Errors

Number of times the requester detected remote access error

Responder Remote Access Errors

Number of times the responder detected remote access error

Requester Remote Operation Errors

Number of times the requester detected remote operation error

Requester Retry Exceeded Errors

Number of times the requester detected transport retries exceed error

Counts the QPs attached to a CQ with overflow condition

Received RDMA Write requests

Number of RDMA write requests received

Received RDMA Read requests

Number of RDMA read requests received

Implied NAK Sequence Errors

Number of times the Requester detected an ACK with a PSN larger than the expected PSN for an RDMA READ or ATOMIC response. The QP retry limit was not exceeded

Dropless Mode Entries

The number of times entered dropless mode.

Dropless Mode Exits

The number of times exited dropless mode.

Transmission Engine Hang Events

The number of sx execution engine hang events.

MTT Entries Used For QP

Number of Memory Translation Table (MTT) entries used for QPs.

MTT Entries Used For CQ

Number of Memory Translation Table (MTT) entries used for CQs.

MTT Entries Used For EQ

Number of Memory Translation Table (MTT) entries used for EQs.

MTT Entries Used For MR

Number of Memory Translation Table (MTT) entries used for MRs.

CPU MEM-Pages (4K) Mapped By TPT For QP

Total number of CPU memory pages (4K) mapped by TPT for QPs.

CPU MEM-Pages (4K) Mapped By TPT For CQ

Total number of CPU memory pages (4K) mapped by TPT for CQs.

CPU MEM-Pages (4K) Mapped By TPT For EQ

Total number of CPU memory pages (4K) mapped by TPT for EQs.

CPU MEM-Pages (4K) Mapped By TPT For MR

Total number of CPU memory pages (4K) mapped by TPT for MRs.

Mellanox WinOF-2 Diagnostics Ext 1

Mellanox WinOF-2 Diagnostics Ext 1 counters set consists of the following counters:

The number of times RoCE traffic reached timeout due to adaptive retransmission.

The number of times RoCE slow restart option was used.

The number of times RoCE slow restart generated CNP packets.

The number of times RoCE slow restart changed its state to slow restart.

The number of times SW has calculated the checksum.

Mellanox WinOF-2 Device Diagnostic

Mellanox WinOF-2 Device Diagnostic counters are global for the device used. Therefore, all the adapter cards associated with the device will have the same counters’ values.

Mellanox WinOF-2 Device Diagnostic counters set consists of the following counters:.

The number of access to L0 MTT that were missed

The rate of access to L0 MTT that were missed

The number of access to L0 MTT that were hit

The rate of access to L0 MTT that were hit

The number of access to L1 MTT that were missed

The rate of access to L1 MTT that were missed

The number of access to L1 MTT that were hit

The rate of access to L1 MTT that were hit

The number of access to L0 MKey that were missed

The rate of access to L0 MKey that were missed

The number of access to L0 MKey that were hit

The rate of access to L0 MKey that were hit

The number of access to L1 MKey that were missed

The rate of access to L1 MKey that were missed

The number of access to L1 MKey that were hit

The rate of access to L1 MKey that were hit

RXS no slow path credits

No room in RXS for slow path packets

RXS no fast path credits

No room in RXS for fast path packets

RXT no slow path credits

No room in RXT for slow path packets

RXT no fast path credits

No room in RXT for fast path packets

Slow path packets slice load

Number of slow path packets loaded to HCA as slices from the network

Fast path packets slice load

Number of fast path packets loaded to HCA as slices from the network

Steering pipe 0 processing time

Number of clocks that steering pipe 0 worked

Steering pipe 1 processing time

Number of clocks that steering pipe 1 worked

WQE address translation back-pressure

No credits between RXW and TPT

Receive WQE cache miss

Number of packets that got miss in RWqe buffer L0 cache

Receive WQE cache hit

Number of packets that got hit in RWqe buffer L0 cache

Slow packets miss in LDB L1 cache

Number of slow packet that got missed in LDB L1 cache

Slow packets hit in LDB L1 cache

Number of slow packet that got hit in LDB L1 cache

Fast packets miss in LDB L1 cache

Number of fast packet that got missed in LDB L1 cache

Fast packets hit in LDB L1 cache

Number of fast packet that got hit in LDB L1 cache

Packets miss in LDB L2 cache

Number of packet that got missed in LDB L2 cache

Packets hit in LDB L2 cache

Number of packet that got hit in LDB L2 cache

Slow packets miss in REQSL L1

Number of slow packet that got missed in REQSL L1 fast cache

Slow packets hit in REQSL L1

Number of slow packet that got hit in REQSL L1 fast cache

Fast packets miss in REQSL L1

Number of fast packet that got missed in REQSL L1 fast cache

Fast packets hit in REQSL L1

Number of fast packet that got hit in REQSL L1 fast cache

Packets miss in REQSL L2

Number of packet that got missed in REQSL L2 fast cache

Packets hit in REQSL L2

Number of packet that got hit in REQSL L2 fast cache

No PXT credits time

Number of clocks in which there were no PXT credits

EQ slices busy time

Number of clocks where all EQ slices were busy

CQ slices busy time

Number of clocks where all CQ slices were busy

MSIX slices busy time

Number of clocks where all MSIX slices were busy

QP done due to VL limited

Number of QP done scheduling due to VL limited (e.g. lack of VL credits)

QP done due to desched

Number of QP done scheduling due to de-scheduling (Tx full burst size)

QP done due to work done

Number of QP done scheduling due to work done (Tx all QP data)

QP done due to limited

Number of QP done scheduling due to limited rate (e.g. max read)

QP done due to E2E credits

Number of QP done scheduling due to e2e credits (other peer credits)

Packets sent by SXW to SXP

Number of packets that were authorized to send by SXW (to SXP)

Number of steering lookups that were hit

Number of steering lookups that were miss

Steering processing time

Number of clocks that steering pipe worked

No send credits for scheduling time

The number of clocks that were no credits for scheduling (Tx)

No slow path send credits for scheduling time

The number of clocks that were no credits for scheduling (Tx) for slow path

TPT indirect memory key access

The number of indirect mkey accesses

Mellanox WinOF-2 PCI Device Diagnostic

Mellanox WinOF-2 PCI Device Diagnostic counters set consists of the following counters:

PCI back-pressure cycles

The number of clocks where BP was received from the PCI, while trying to send a packet to the host.

PCI back-pressure cycles/Sec

The rate of clocks where BP was received from the PCI, while trying to send a packet to the host.

PCI write back-pressure cycles

The number of clocks where there was lack of posted outbound credits from the PCI, while trying to send a packet to the host.

PCI write back-pressure cycles/Sec

The rate of clocks where there was lack of posted outbound credits from the PCI, while trying to send a packet to the host.

PCI read back-pressure cycles

The number of clocks where there was lack of non-posted outbound credits from the PCI, while trying to send a packet to the host.

PCI read back-pressure cycles/Sec

The rate of clocks where there was lack of non-posted outbound credits from the PCI, while trying to send a packet to the host.

PCI read stuck no receive buffer

The number of clocks where there was lack in global byte credits for non-posted outbound from the PCI, while trying to send a packet to the host.

Available PCI BW

The number of 128 bytes that are available by the host.

The number of 128 bytes that were received from the host.

The number of physical layer PCIe signal integrity errors. The number of transitions to recovery due to Framing errors and CRC (dlp and tlp). If the counter is advancing, try to change the PCIe slot in use.

Note: Only a continues increment of the counter value is considered an error.

The number of physical layer PCIe signal integrity errors. The number of transition to recovery initiated by the other side (moving to Recovery due to getting TS/EIEOS). If the counter is advancing, try to change the PCIe slot in use.

Note: transitions to recovery can happen during initial machine boot. The counter should not increment after boot.

Note: Only a continues increment of the counter value is considered an error.

TX PCI non-fatal errors

The number of PCI transport layer Non-Fatal error msg sent. If the counter is advancing, try to change the PCIe slot in use.

TX PCI fatal errors

The number of PCIe transport layer fatal error msg sent. If the counter is advancing, try to change the PCIe slot in use.

Mellanox WinOF-2 VF Diagnostics

Mellanox WinOF2 VF Diagnostics counters exist per each VF and are created according to the adapter’s configurations. These counters are created upon VFs configuration even if the VFs are not up.

Mellanox WinOF2 VF Diagnostics counters set consists of VF diagnostic and debug counters. This set is available only on the hypervisors and not on the virtual network adapters:

Async EQ Overrun

The number of times an EQ mapped to Async events queue encountered overrun queue.

Completion EQ Overrun

The number of times an EQ mapped to Completion events queue encountered overrun queue.

Current Queues Under Processor Handle

The current number of queues that are handled by the processor due to an Async error (e.g. retry exceeded) or due to a CMD error (e.g. 2eer_qp cmd).

Total Queues Under Processor Handle

The total number of queues that are handled by the processor due to an Async error (e.g. retry exceeded) or due to a CMD error (e.g. 2eer_qp cmd).

Packets Received dropped due to Steering

Number of packets that completed the NIC Receive FlowTable steering and were discarded due to lack of match rule in Flow Table.

Packets Received dropped due to VPort Down

Number of packets that were steered to a VPort, and discarded because the VPort was not in a state to receive packets

Packets Transmitted dropped due to VPort Down

Number of packets that were transmitted by a vNIC, and discarded because the VPort was not in a state to transmit packets.

Number of commands issued by the VF and failed.

Mellanox WinOF-2 VF Internal Traffic

Mellanox WinOF-2 VF Internal Traffic Counters set consists of counters that measure the rates at which bytes and packets are sent and received over each core of a virtual port that is bound to a virtual PCI function.

This set is available only on hypervisors, and each virtual network adapter should be allowed to update its counters by using the mlx5cmd tool.

The virtual network adapter driver should support internal traffic counter set exposure, to make it available on hypervisor.

The number of packets received by this virtual adapter at specific core.

The number of bytes received by this virtual adapter at specific core. The counted bytes don’t include framing characters (modulo 2^64)

The number of packets sent by this virtual adapter at specific core.

The number of bytes sent by this virtual adapter at specific core. The counted bytes don’t include framing characters (modulo 2^64)

Controlling VF Internal Traffic

VF Internal Traffic Counters can be controlled using the mlx5cmd.exe tool. The tool enables the user to make the virtual network adapter’s traffic counters per core available or unavailable for performance monitoring consumers.

These counters set is relevant only for ETH ports.

Mellanox WinOF-2 Rss Counters set provides monitoring for hardware RSS behavior. These counters are accumulative and collect packets per type (IPv4 or IPv6 only, IPv4/6 TCP or UDP), for tunneled and non-tunneled traffic separately, and when the hardware RSS is functional or dysfunctional.

The counters are activated upon first addition into perfmon, and are stopped upon removal.

Setting «RssCountersActivatedAtStartup» registry key to 1 in the NIC properties will cause the Rss counters to collect data from the startup of the device.

All Rss counters are provided under the counter set “Mellanox Adapter Rss Counters”.

Each Ethernet adapter provides multiple instances:

• Instance per vPort per CPU in HwRSS mode is formatted: + vPort_ CPU_
• Instance per network adapter per CPU in native Rss per CPU is formatted: CPU_

Shows the number of received packets that have RSS hash calculated on IPv4 header only

Shows the number of received packets that have RSS hash calculated on IPv4 and TCP headers

Shows the number of received packets that have RSS hash calculated on IPv4 and UDP headers

Shows the number of received packets that have RSS hash calculated on IPv6 header only

Shows the number of received packets that have RSS hash calculated on IPv6 and TCP headers

Shows the number of received packets that have RSS hash calculated on IPv6 and UDP headers

Encapsulated Rss IPv4 Only

Shows the number of received encapsulated packets that have RSS hash calculated on IPv4 header only

Encapsulated Rss IPv4/TCP

Shows the number of received encapsulated packets that have RSS hash calculated on IPv4 and TCP headers

Encapsulated Rss IPv4/UDP

Shows the number of received encapsulated packets that have RSS hash calculated on IPv4 and UDP headers

Encapsulated Rss IPv6 Only

Shows the number of received encapsulated packets that have RSS hash calculated on IPv6 header only

Encapsulated Rss IPv6/TCP

Shows the number of received encapsulated packets that have RSS hash calculated on IPv6 and TCP headers

Encapsulated Rss IPv6/UDP

Shows the number of received encapsulated packets that have RSS hash calculated on IPv6 and UDP headers

NonRss IPv4 Only

Shows the number of IPv4 packets that have no RSS hash calculated by the hardware

Shows the number of IPv4 TCP packets that have no RSS hash calculated by the hardware

Shows the number of IPv4 UDP packets that have no RSS hash calculated by the hardware

NonRss IPv6 Only

Shows the number of IPv6 packets that have no RSS hash calculated by the hardware

Shows the number of IPv6 TCP packets that have no RSS hash calculated by the hardware

Shows the number of IPv6 UDP packets that have no RSS hash calculated by the hardware

Encapsulated NonRss IPv4 Only

Shows the number of encapsulated IPv4 packets that have no RSS hash calculated by the hardware

Encapsulated NonRss IPv4/TCP

Shows the number of encapsulated IPv4 TCP packets that have no RSS hash calculated by the hardware

Encapsulated NonRss IPv4/UDP

Shows the number of encapsulated IPv4 UDP packets that have no RSS hash calculated by the hardware

Encapsulated NonRss IPv6 Only

Shows the number of encapsulated IPv6 packets that have no RSS hash calculated by the hardware

Encapsulated NonRss IPv6/TCP

Shows the number of encapsulated IPv6 TCP packets that have no RSS hash calculated by the hardware

Encapsulated NonRss IPv6/UDP

Shows the number of encapsulated IPv6 UDP packets that have no RSS hash calculated by the hardware

Shows the number of received packets that have RSS hash calculated with unknown RSS hash type

Encapsulated Rss Misc

Shows the number of received encapsulated packets that have RSS hash calculated with unknown RSS hash type

Shows the number of packets that have no RSS hash calculated by the hardware for no apparent reason

Encapsulated NonRss Misc

Shows the number of encapsulated packets that have no RSS hash calculated by the hardware for no apparent reason

Mellanox WinOF-2 Receive Datapath

Mellanox WinOF-2 Receive Datapath counters set provides queue counters per receive. These counters are available in Native, VMQ and SR-IOV mode. These counters provide visibility into the driver when running traffic. The counters are activated upon first addition into perfmon, and are stopped upon removal. Each Ethernet adapter provides multiple instances. An instance per vPort per queue number is formatted as one of the below depending on the mode set (Native or VMQ/SR-IOV):

Packets processed in interrupt mode

Number of packets processed in Interrupt mode.

Packets processed in polling mode

Number of packets processed in Polling mode.

Consumed max receives

Number of times we processed our max packet limit (128 packets default).

Number of traffic profile transitions

Number of times we transition to different traffic profiles.

Packets in low resource mode

Number of times we indicated packets with low resource. In this mode, driver has ownership of packet immediately.

DpcWatchDog (SingleDpc) Starvation

This counter is incremented each time DPC timer limit is hit (or nearing).

DpcWatchDog (TotalDpc) Starvation

This counter is incremented each time DPC watchdog limit is hit (or nearing).

Drops due to completion queue errors

Packets dropped by driver due to CQE errors.

Number of receive buffers posted

Current number of RX buffers posted onto the ring.

Interrupts on incorrect cpu

DPC not running on correct CPU.

Cpu where Receive completions are being processed.

Drops due to invalid packet size

Number of packets dropped by driver as packet was greater than acceptable MTU size.

Average packet count per indicate

Average number of packets indicated per call to the operating system.

Number of interrupts

Number of interrupts generated to process RX completions.

Mellanox WinOF-2 Transmit Datapath

Mellanox WinOF-2 Transmit Datapath counters set provides queue counters per transmit. These counters are available in Native, VMQ and SR-IOV mode. These counters provide visibility into the driver when running traffic. The counters are activated upon first addition into perfmon, and are stopped upon removal. Each Ethernet adapter provides multiple instances. An instance per vPort per queue number is formatted as one of the below depending on mode (Native or VMQ/SR-IOV):

Cpu where transmit completions are being processed.

Transmit ring is full

Number of times we had to queue our packets as we could not find free slots in ring to post.

Transmit copy packets

Number of times we got a packet with more fragments we can support.

Number of packets posted

Number of packets posted so far.

Number of packets completed

Number of packets completed.

OS call to build SGL failed

Number of failed OS calls to build scatter gather list.

Drops due to invalid packet size

Number of packets dropped by driver due to invalid length (example: less than 14 bytes).

Number of packets posted in bypass mode

Number of packets detected by driver as forwarded.

Average packet count per indicate

Average Number of packets indicated per call to OS.

Interrupts on incorrect cpu

DPC not running on correct CPU.

Mellanox WinOF-2 Port Diagnostics

Mellanox WinOF-2 Port Diagnostics counters set contains physical layer statistical counters. This set exists for every adapter in the PF, it is not supported in the VF.

RX Error Lane0 phy

The number error bits on lane 0

RX Error Lane0 phy/Sec

The rate of changing of the lane 0 counter

RX Error Lane1 phy

The number error bits on lane 1

RX Error Lane1 phy/Sec

The rate of changing of the lane 1 counter

RX Error Lane2 phy

The number error bits on lane 2

RX Error Lane2 phy/Sec

The rate of changing of the lane 2 counter

RX Error Lane3 phy

The number error bits on lane 3

RX Error Lane3 phy/Sec

The rate of changing of the lane 3 counter

The total amount of traffic that could have been received on the port

RX Kbits phy/Sec

The rate of changing of the above counter

RX PCS Corrected Bits phy

The number of symbol errors that wasn’t corrected by FEC correction algorithm or that FEC algorithm was not active on this interface

RX PCS Corrected Bits phy/Sec

The rate of changing of the above counter

RX PCS Symbol Error phy

The number of corrected bits on this port according to active FEC (RS/FC).

If this counter is increasing, it implies that the link between the NIC and the network is suffering from high BER

Источник

умолчанию –

No Refresh.

Frame Check Sequence (FCS) Errors — Количество ошибок последовательности проверки кадра, полученных на выбранном интерфейсе.

Single Collision Frames – Количество одиночных коллизий в кадрах, полученных на выбранном интерфейсе.

Late Collisions – Количество поздних коллизий, полученных на выбранном интерфейсе.

Excessive Collisions – Количество чрезмерных коллизий, полученных на выбранном интерфейсе.

Internal MAC Transmit Errors – Количество внутренних ошибок управления доступом к передающей среде при передаче через выбранный интерфейс.

Oversize Packets – Количество принятых пакетов размером больше 1518 байт (без учета битов кадра, но с учетом байтов FCS), не имеющих других 
ошибок

.

Internal MAC Receive Errors – Количество внутренних ошибок управления доступом к передающей среде при приеме через выбранный интерфейс.

Received Pause Frames — Количество кадров паузы, полученных через выбранный интерфейс.

Transmitted Pause Frames — Количество кадров паузы, отправленных через выбранный интерфейс.

Отображение статистики базы 

Etherlike для интерфейса 

1.

Откройте страницу 

Etherlike Statistics.

2.

Выберите интерфейс

.

Появится статистика для выбранного интерфейса

.

GVRP Statistics (Статистика GVRP)

Страница

GVRP Statistics (Статистика GVRP) позволяет просмотреть статистику коммутатора, относящуюся к GVRP.

Чтобы открыть эту страницу

, выберите в дереве Statistics/RMON® Table Views® GVRP Statistics .

 Рисунок 

8-3. Статистика GVRP

На странице 

GVRP Statistics есть следующие поля:

Interface – Выберите физический интерфейс (устройство, порт) или интерфейс LAG, для которого требуется просмотреть статистику.

Refresh Rate – Интервал обновления статистики на экране. Возможные значения: No Refresh (без обновления), 15, 30 и 60 секунд. Значение по 
умолчанию –

No Refresh.

Атрибуты 

(счетчики) в таблице статистики GVRP для полученных и отправленных данных 

Join Empty – отображает статистику по сообщениям Join Empty протокола GVRP.

Empty – Отображает статистику по сообщениям Empty протокола GVRP.

Leave Empty – Отображает статистику по сообщениям Leave Empty протокола GVRP.

Join In – Отображает статистику по сообщениям Join In протокола GVRP.