Попытка определить, есть ли некоторая периодическая задержка между DC на каналах FC, но есть доступ только к счетчикам OID для DCX 8510. Поскольку это канал L1 через DWDM, от поставщика услуг нет статистики для измерения любых возможных проблем кроме подключения тестового набора, который всегда выходит чистым, поскольку проблема носит временный характер.
Когда возникает проблема, можно увидеть скачок значений этого OID, но попытаться найти по нему правильную информацию очень сложно.
swfcportrxbados
Любая помощь по лучшему объяснению этого OID и указатели на некоторую информацию, чтобы лучше понять выходы SNMP, были бы весьма признательны.
swFCPortRxBadOs отслеживает количество недействительных упорядоченных наборов, в большинстве случаев это ошибка физического или виртуального интерфейса, она также может применяться к объединительной плате.
Неверные упорядоченные наборы для DWDM или прямого FC, будь то Cisco или Broccade, часто являются результатом плохой работы хоста или узла. RAID-массив с длиной метки диска более 6 или около того на другой стороне DWDM может привести к тайм-ауту виртуального канала. Обычно это означает, что виртуальные каналы «застревают». Когда порт коммутатора исчерпывает все доступные кредиты, порт коммутатора, подключенный к устройству, должен хранить дополнительные исходящие кадры, пока устройство не вернет кредит для входа в буфер. Когда устройство не отвечает в течение тайм-аута, передающий коммутатор будет удерживать кадры дольше, что приведет к высокой занятости буфера. Это приводит к тому, что коммутатор снижает скорость, с которой он возвращает буферные кредиты другим передающим коммутаторам. Затем это распространяется через коммутаторы (потенциально несколько коммутаторов с устройствами, пытающимися отправить кадры на узлы или коммутаторы, подключенные к коммутатору с узлом или коммутатором с высокой задержкой) и влияет на производительность фабрики.
Возможные виновники
Неисправность физического уровня - неисправный или выходящий из строя SFP на другой стороне или на коммутаторе, на который вы смотрите.
Виртуальный канал "завис" - объяснение выше. Если виртуальный канал завис, значит, он не передает трафик или сигналы, и вы увидите, что счетчики er_bad_os увеличиваются.
Brocade рекомендует включить функцию "бутылочного горлышка" в FOS. Он сбросит VC (виртуальный канал), когда будет двухсекундное окно без трафика.
bottleneckmon –cfgcredittools -intport -recover onLrOnly
Когда один или несколько кредитов потеряны, он начнет искать свое окно для сброса VC.
Это отличный PDF-файл о передовых методах обеспечения отказоустойчивости Fabric http://www.brocade.com/downloads/documents/html_product_manuals/NOS_MIB_301/wwhelp/wwhimpl/common/html/wwhelp.htm#context=NOS_MIB_v301_HTML&file=5_sw-mib.06.4.html
используйте portstatushow для своего порта и посмотрите, получите ли вы er_bad_os 591691 Недействительный упорядоченный набор
Это может дать вам уверенность в том, что то, что вы испытываете, является недопустимым упорядоченным набором, поэтому вы можете начать устранение неполадок с вашими кредитами и буферами, в которых часто возникают проблемы этого типа.
Отличная статья о буферных кредитах. http://community.brocade.com/t5/Mainframe-Solutions/Buffer-Credits-and-Frame-Size-calculation-in-FOS-7-1/ba-p/455