Диагностика портов Brocade FC SAN

Когда я писал свой цикл статей по Brocade, я уже затрагивал тему диагностики SAN подключений:

• Brocade SAN Часть 7: Базовое решение проблем
• Brocade SAN Часть 12: Мониторинг производительности и проблем в фабрике

Но разбор ошибок portErrShow остался как-то в стороне, и я решил исправить это упущение. Тем более, что по факту это первое, куда стоит бросить свой взгляд в поиске проблем.

Зачем нужен portErrShow

portErrShow — первая команда, куда стоит смотреть в случае проблем в фабрике: она выводит сводку счётчиков ошибок по всем портам коммутатора в компактной табличной форме, и сразу показывает, какие проблемы на портах. Но конечно же эту информацию нужно уметь читать.

Значения полей

frames tx / frames rx количество переданных и полученных фреймов. Сами по себе ошибками не являются, но служат базой: без них непонятно, много ли ошибок относительно общего трафика порта.

enc in количество нечитаемых фреймов с ошибками кодирования 8b/10b внутри границ фрейма (RX). Обычно указывает на неисправность в среде передачи — SFP, кабель, патч-панель. Единичные значения на нормальном линке — нормальное состояние и допускаются по спецификации.

crc err количество фреймов с ошибками CRC (RX). Появляется на всех портах, через которые проходит уже битый фрейм — счётчик может расти не только на порте-источнике проблемы, но и транзитом по всей фабрике. Источник отслеживается по счётчикам crc g_eof и enc in.

crc g_eof фреймы с CRC-ошибкой, но с корректным EOF (End of Frame), впервые обнаруженные именно на этом порту. Как только коммутатор фиксирует такой фрейм, он его помечает, чтобы остальные порты по пути не засчитывали его повторно. Это лучший индикатор того, что проблема (SFP, кабель, порт устройства) находится именно здесь, а не транзитом.

too shrt фрейм короче минимально допустимого размера (менее 38 байт, то есть 7 слов включая SOF/EOF). Индикатор нестабильного линка либо проблемы на передающей стороне.

too long фрейм длиннее максимально допустимого размера (более 2148 байт после SOF без EOF). Также индикатор нестабильного линка — обычно следствие повреждённого EOF.

bad eof фреймы с повреждённым полем EOF. Как правило означает, что линк терял синхронизацию и во время ре-синхронизации “отрезал” часть фрейма вместе с EOF. Частый признак неисправного SFP.

enc out ошибки 8b/10b кодирования вне границ фрейма. Счётчик растёт во время согласования скорости при подключении устройства (в старых версиях FOS — до 7.1). Сам по себе не всегда означает проблему, но быстрый устойчивый рост обычно указывает на неисправность линка. enc out без сопутствующих ошибок — типичный признак загрязнённого коннектора/кабеля.

disc c3 количество отброшенных фреймов Class 3. По официальному описанию команды это сумма четырёх счётчиков portStatsShow: er_rx_c3_timeout, er_tx_c2_timeout, er_c2_dest_unreach и er_other_disc. Счётчик суммирует не только таймауты, но и недостижимость получателя и ряд прочих причин отбрасывания. Небольшой рост — норма. Заметный рост — индикатор проблем с производительностью: перегруженные ISL, slow-drain устройства. Диагностируется совместно с bottleneckmon и portStatsShow.

link fail порт перешёл в состояние Link Fail без явной потери синхронизации: не дождался ответа в течение таймаута Link Reset Protocol (R_T_TOV). Часто сопровождается loss sync или loss sig и может указывать на проблему в ОС подключённого устройства.

loss sync потеря синхронизации на порту. Возникает при получении 4 подряд повреждённых transmission word (каждое такое слово увеличивает enc in или enc out). Указывает на физическую проблему линка.

loss sig потеря оптического или электрического сигнала. По официальному описанию команды счётчик, помимо прочего, растёт при каждом физическом извлечении SFP из порта. Часто означает, что устройство на другом конце перезагружается, выключается или физически отключён кабель/SFP.

c3timeout tx / rx количество фреймов класса 3, отброшенных по таймауту на передаче/приёме. Один из главных индикаторов slow-drain device.

uncor err количество блоков, не исправленных механизмом FEC (Forward Error Correction). Сам по себе, без сопутствующих CRC/enc out/bad eof, говорит о том, что линк не идеален, но эффект пока минимален.

bad_os (er_bad_os) счётчик “неверных ordered set” — в стандартный вывод portErrShow не входит, смотреть его нужно через portStatsShow. Резко растёт на портах 8 Гбит/с, если для подключённого устройства не настроено правильное значение FillWord; обычно растёт вместе с enc out.

Вывод: половина ошибок portErrShow описывает физику линка, другая половина доставку и производительность. Это разделение очень важно понимать для дальнейшей диагностики и устранения проблемы: физику лечат заменой SFP/кабеля, производительность/доставку пакетов — анализом топологии и нагрузки.

Типовые сочетания ошибок и что они означают

На практике счётчики почти никогда не читаются по одному — важны сочетания.

enc out + link fail + loss sync (возможно + loss sig). Классическая картина перезагрузки хоста или сброса линка на другой стороне: устройство ушло в офлайн и снова договаривается о скорости.

Только enc out, без остальных ошибок. Обычно означает загрязнённый оптический разъём или деградировавший кабель. Первое действие — почистить и осмотреть оптику/SFP с обеих сторон линка.

crc err + crc g_eof на одном порту. Фрейм заходит на порт уже с плохим CRC, но именно на этом порту впервые зафиксирован — источник проблемы (SFP / кабель / интерфейс подключённого устройства) физически здесь.

crc err без crc g_eof. Порт лишь ретранслирует уже битый фрейм, полученный откуда-то ещё в фабрике. Нужно искать порт, на котором тот же фрейм даёт crc g_eof — это и есть источник.

c3timeout + disc c3. Указывает не на физическую проблему линка, а на перегрузку/производительность: слишком долгая доставка фреймов, congestion на ISL, slow-drain устройство на другом конце фабрики. Физический ремонт здесь не поможет — нужен анализ топологии, ISL-загрузки и, при наличии, включение bottleneck detection.

uncor err в одиночку. Ранний признак деградации оптики/кабеля, ещё не переросший в CRC или enc out — стоит превентивно проверить и почистить коннекторы.

Практическая методика диагностики

1. Сбросить счётчики перед анализом. portErrShow показывает накопленные с момента последнего сброса значения, поэтому старые события легко принять за текущую проблему. Команды statsClear и slotStatsClear обнуляют счётчики. После сброса стоит подождать несколько часов и снять показания заново.
2. Смотреть на сочетания, а не на отдельные счётчики. Как мы уже разобрали, один и тот же счётчик означает разное в зависимости от того, что растёт вместе с ним.
3. Разделять проблему физики и производительность. Ошибки enc in/out, crc err, too shrt/long, bad eof, loss sync/sig, link fail, pcs err, uncor err — про физику линка (SFP, кабель, патч-панель, разъём). Ошибки disc c3 и c3timeout — про перегрузку и задержки доставки.
4. Дополнительные команды, которые дополняют portErrShow:
   • portStatsShow — детализация вплоть до отдельных типов discard’ов (er_rx_c3_timeout, er_other_disc и т.д.);
   • portShow — полное состояние порта: скорость, режим, физический статус, SFP;
   • switchShow, nsShow, topologyShow — контекст фабрики при поиске проблем маршрутизации/topology.

Buffer-to-Buffer Credit: когда дело не в ошибках, а в задержках

Счётчики disc c3 и c3timeout растут не только из-за физических проблем, но и из-за нехватки BB кредитов — механизма управления потоком в FC. Если принимающий порт не успевает освобождать буферы (slow-drain устройство, перегруженный ISL), у передающей стороны заканчиваются кредиты. Фреймы стоят в очереди и в итоге отбрасываются по таймауту, при этом сам линк физически исправен: ошибок кодирования и CRC нет.

portBufferShow показывает распределение буферов по портам и помогает понять, не упёрся ли порт в лимит выделенных кредитов (актуально для длинных ISL и портов с включённым QoS). Если c3timeout/disc c3 растут на фоне полностью чистых «физических» счётчиков — это почти всегда про BB кредиты.

Диагностика трансивера: sfpShow и diagShow

Когда enc out, enc in или uncor err растут без явной внешней причины, стоит посмотреть не на счётчики, а на сам трансивер:

sfpShow — модель SFP, поддерживаемая скорость, текущие показания: мощность передатчика и приёмника, температура, напряжение и т.д. Очень часто тут можно увидеть аномальные показатели Tx/Rx, которые говорят о физической неисправности SFP.

Низкоуровневый журнал порта: portLogDump / portLogShow

portErrShow даёт только текущую накопленную сумму ошибок, без привязки ко времени. portLogDump и portLogShow показывают одни и те же данные из логов коммутатора. portLogShow пожалуй более удобен для чтения.

Это не просто “история включений/выключений порта”, а детальный трейс. Журнал фиксирует несколько типов событий:

• disable/enable
• pstate
• scn
• Tx/Rx
• reject/busy
• errlog

Лог фиксирует не только смену состояния линка, но и трафик на уровне отдельных фреймов и обменов.

Что стоит запомнить

• portErrShow — быстрый первый проход по фабрике: одна команда сразу показывает все ошибки на портах.
• Читать счётчики связками, не по одному — один и тот же счётчик значит разное в зависимости есть ли иные ошибки на этом порту и по какому конкретно параметру.
• Обнулять статистику перед анализом. Это на самом деле частая ситуация в моей практике, когда заказчик присылает статистику с коммутатора, которую сбрасывали неизвестно когда и portErrShow просто весь в ошибках по всем портам и совершенно не ясно на что именно нужно смотреть именно в данной ситуации. Так же часто бывает, что заказчики сбрасывают статистику порта и выключают его, дабы избежать влияния на производительность. Но 0 на счётчике совершенно не поможет в анализе проблемы.
• На новые линки перед вводом в эксплуатацию стоит диагностировать при помощи D_Port.