Диагностика портов FC: счётчики, slow drain, проверка SFP

SAN-коммутатор считает всё, что идёт не так на порту, и счётчики чисто ложатся на физические причины — если знать, какой счётчик означает «грязный разъём», а какой — «хост не разгружает свои буферы». Здесь — счётчики на двух доминирующих платформах, на что указывает каждый, как проявляется перегрузка slow-drain и как прочитать сам SFP с коммутатора.

Счётчики

Счётчик (Brocade `porterrshow`)	Эквивалент Cisco MDS (`show interface fc… counters`)	Смысл	Указывает на
enc_out — ошибки кодирования вне кадров	invalid transmission words	плохие символы между кадрами	оптика, кабель, разъём, несовпадение скорости — классический счётчик физического уровня
enc_in — ошибки кодирования внутри кадров	invalid transmission words / CRC	испорченные символы внутри кадров	те же причины, тяжелее
crc_err	CRC errors	кадр не прошёл CRC	маргинальная линия: грязный торец, низкий Rx, умирающий SFP; на ISL проверять оба конца
crc_g_eof	CRC с хорошим EOF	ошибка CRC, но кадр завершён корректно — внесена выше этого порта	смотреть предыдущий хоп
too_shrt / too_long / bad_eof	кадр слишком короткий / длинный / плохой EOF	искажённые кадры	обычно следствие enc_in или неисправное устройство
link_fail	link failures	линк упал	выдернутый кабель, отказ SFP, питание, сброс дальнего конца
loss_sync / loss_sig	sync loss / signal loss	потеря сигнала или синхронизации слов	низкий Rx, LOS, флап — Флап линка
frjt / fbsy	F_RJT / F_BSY	фабрика отвергла/отложила кадры	фабрика или зонирование, не оптика
disc_c3 — отброшенные класса 3	timeout discards	кадры отброшены по таймауту в коммутаторе	slow drain / перегрузка
c3timeout tx/rx	—	направление таймаутов	таймауты tx: подключённое устройство медленное; rx: проблема выше
pcs_err (16G+)	—	ошибки блоков PCS 64B/66B	физический уровень на 16/32GFC
uncor_err (16G+ с FEC)	FEC uncorrected	FEC не смог починить блок	линия на пределе — VDM и метрики FEC
потеря кредитов (`portstatsshow`: tim_txcrd_z)	credit loss / tx credit not available	время с нулём кредитов на передачу	перегрузка или потерянные R_RDY на грязной линии

Правило: enc_out, crc_err, loss_sync, pcs_err растут при физической проблеме; disc_c3, c3timeout, tim_txcrd_z — при перегрузке; frjt/fbsy — при проблеме фабрики. Сбросьте счётчики, подождите и смотрите скорости, а не суммы.

Slow drain

Оконечное устройство, медленно возвращающее кредиты (перегруженный хост, умирающая HBA, несовпадение скоростей вдоль пути), держит кадры в буферах коммутатора; те выходят по таймауту и отбрасываются, а перегрузка распространяется назад через ISL на не связанные устройства. Это самая разрушительная проблема SAN, и поначалу она выглядит как случайная проблема производительности.

Признак	Где
tim_txcrd_z растёт на F_Port	устройство на этом порту медленно возвращает кредиты
disc_c3 / c3timeout tx на том же порту	кадры к этому устройству выходят по таймауту
disc_c3 на ISL и других F_Port	перегрузка распространилась
Алерты Bottleneck/MAPS «latency» (Brocade), `show logging onboard flow-control request-timeout`, обнаружение congestion-drop / slow-drain (Cisco)	инструменты платформы

Лечение: починить или изолировать медленное устройство (port fencing, карантин в низкоприоритетный виртуальный канал), укоротить таймауты congestion-drop на краевых портах, избегать ступеней скорости вдоль пути, держать переподписку ISL разумной (Дизайн SAN). Оптика почти никогда не причина slow drain — но маргинальная линия с потерянными R_RDY может его имитировать, поэтому сначала проверяйте enc_out/crc.

Проверка SFP с коммутатора

Задача	Brocade FOS	Cisco MDS / NX-OS
Идентификация и DDM SFP	`sfpshow <port>`	`show interface fc1/1 transceiver details`
Состояние и скорость порта	`portshow <port>`, `switchshow`	`show interface fc1/1`, `show interface brief`
Счётчики ошибок	`porterrshow`, `portstatsshow <port>`	`show interface fc1/1 counters [detailed]`
Сброс счётчиков	`portstatsclear` / `statsclear`	`clear counters interface fc1/1`
Тест линии	`portloopbacktest`, диагностика D_Port (`portcfgdport`, `portdporttest`)	`show interface fc1/1 transceiver details` + петля диагностическими средствами
Политика здоровья	MAPS (пороги по CRC, ITW, потере кредитов, мощности/температуре SFP)	политики port-monitor (мощность RX/TX, CRC, ITW, потеря кредитов)

sfpshow и детали трансивера показывают вендора, партномер, серийник, скорости и значения DDM с порогами — те же байты, что CodingBox читает на столе. Обе платформы помечают unsupported оптику; порт, застрявший в Mod_Inv, No_Module или «unsupported transceiver», — отказ политики, а не неисправность (Вендор-лок, Оптика FC).

Последовательность диагностики плохого порта FC

porterrshow / счётчики: физика (enc_out, crc, sync) против перегрузки (disc_c3, кредиты) против фабрики (rjt/bsy).
DDM SFP: Rx на обоих концах относительно окон класса (Типовые значения); тренд тока Tx на старение.
Почистить и осмотреть разъёмы; поменять патч-корд; перепроверить скорость счётчиков.
Скорость: принудительно опустить согласованную скорость на поколение, чтобы увидеть, прекратятся ли ошибки (маргинальная линия 32G может быть чистой на 16G) — Скорость и режимы.
Тест D_Port / петля, чтобы разделить коммутатор, SFP и кабель.
При перегрузке: искать медленное устройство по tim_txcrd_z, а не по порту, который жалуется.

В CodingBox

Подозрительный FC SFP, снятый с коммутатора, читается на столе: идентификация, коды скорости/среды FC, контрольные суммы и живой DDM на Check transceiver и DDM. Модуль, здоровый на столе и дающий ошибки в порту, переводит подозрение на кабель, разъём или дальний конец.