С чего начинается проблема на 25/100GbE

Диагностика проблем 25/100GbE почти всегда начинается одинаково: вы видите нестабильный линк, странные потери или скорость, которая не держится даже близко к ожидаемой. Важно не менять модуль или кабель «наугад», а сначала зафиксировать симптомы и собрать базовые данные. Это экономит часы и часто спасает от лишних замен.

Самые частые проявления такие:

линк флапает (то up, то down) или долго поднимается после перетыка
растут счетчики ошибок, но трафик иногда выглядит «нормально»
появляются потери пакетов, особенно под нагрузкой
скорость падает, начинаются ретрансляции, приложения жалуются на задержки
проблема «плавает» и пропадает после перекоммутации

На 25/100G мелкие физические дефекты быстро превращаются в заметные ошибки. Причина простая: меньше «запаса» по сигналу и выше требования к качеству тракта. Пыль на коннекторе, перегиб, не тот тип волокна, слабый контакт в разъеме или уставший модуль могут дать не постоянный обрыв, а рост ошибок (CRC/FEC), который потом выглядит как «проблемы сети».

Чаще всего путают четыре вещи: неисправный трансивер, плохой патчкорд, загрязнение (коннекторы и адаптеры) и проблему в порту или настройках. Например, модуль может быть исправен, но стоять на линии с неподходящим волокном, или же порт работает, но в конфигурации есть несовместимый режим скорости или FEC.

Перед любыми действиями соберите минимум фактов (лучше в заметку или тикет):

модель коммутатора и номер порта, где видна проблема
тип и модель модуля (SFP28/QSFP28, SR/LR/CR, vendor)
длина линии и тип среды (DAC, MMF/SMF, тип разъемов)
с какой стороны наблюдаются симптомы (один конец или оба)
когда началось и что меняли последним (патчкорд, кросс, модуль, настройки)

Простой пример: линк 100G поднимается, но под нагрузкой растут ошибки. Если вы сразу меняете модуль, вы можете «исправить» ситуацию случайно, просто потревожив загрязненный коннектор. Лучше сначала зафиксировать показатели и только потом трогать физику.

Что означают CRC и FEC простыми словами

CRC (обычно видите как CRC errors или input errors) - это сигнал, что кадры приходят поврежденными и не проходят проверку контрольной суммы. В Ethernet это почти всегда история про физику: оптика, медь, разъемы, загрязнение, плохой патч-корд, перегиб, несовместимый модуль, иногда плохой порт.

FEC (Forward Error Correction) - это встроенная «страховка» для линии. Линк может выглядеть нормальным, но в фоне исправлять мелкие ошибки на уровне символов. Поэтому счетчики FEC могут расти даже без потерь трафика и без явных жалоб приложений. Это особенно характерно для 25/100GbE, где запас по качеству сигнала меньше, а требования к оптике и волокну выше.

Как интерпретировать CRC и FEC вместе

Сами по себе числа мало что говорят. Важно, что именно растет и как быстро:

Растет FEC, а CRC стоит на месте: линия на грани, но коррекция справляется. Часто причина в слабом уровне сигнала, грязном коннекторе или неподходящем типе волокна.
Растут CRC (даже если FEC тоже растет): коррекция уже не спасает, кадры портятся. Обычно это физический дефект или плохая стыковка.
CRC появляются рывками при нагрузке или движении кабеля: похоже на плохой патч-корд, разъем или механический контакт.
Счетчики не растут, но жалобы есть: ищите выше по стеку (перегруз, дропы в очередях, MTU), а не в физике.

Почему важна динамика, а не одно число

Для диагностики проблем 25/100GbE полезнее смотреть скорость прироста: «ошибок в минуту» или «в час». Один раз увидели 100 CRC - не факт, что проблема текущая: это могло случиться вчера при перекоммутации.

Простой пример: после замены патч-корда FEC продолжает медленно расти, но CRC перестали увеличиваться. Это обычно значит, что стало лучше, но запас по сигналу все еще небольшой, и стоит проверить чистоту коннекторов и тип оптики.

Optical power: как читать уровни Tx/Rx

Tx optical power - это сколько света модуль отправляет в линию. Rx optical power - сколько света модуль реально получает обратно с другой стороны. Для диагностики важны оба значения: один конец может передавать нормально, но почти ничего не принимать, и тогда проблема будет не там, где вы смотрите.

Оптическая мощность обычно показывается в dBm. Это логарифмическая шкала, поэтому знак имеет значение: -2 dBm сильнее, чем -8 dBm. В mW наоборот все выглядит «положительно» (например, 0.5 mW), но на практике удобнее держаться dBm и не путать, что «больше» в смысле света - это ближе к нулю.

Нормальные диапазоны: где их брать

Не угадывайте «норму» по памяти. Правильные границы зависят от типа оптики (SR, LR, ER, DAC/AOC) и скорости (25G, 100G). Их берут из данных самого модуля: в выводе DOM/DDM обычно есть пороги (High/Low Alarm и High/Low Warn) для Rx и иногда для Tx. Если порогов нет, смотрят паспорт именно этой модели трансивера.

В задачах вроде «Диагностика проблем 25/100GbE» это критично: два модуля могут быть одинаковыми внешне, но иметь разные допустимые уровни.

Что говорят перекосы в показаниях

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

Если Rx «прыгает» (то выше, то ниже), это похоже на нестабильный контакт: плохо защелкнутый коннектор, микротрещина в волокне, натяжение кабеля в лотке.

Если и Tx, и Rx на грани (или в предупреждениях) сразу на обоих концах, обычно это несоответствие бюджета линии: слишком длинная трасса для этого типа оптики, неверный класс модулей, лишняя оптическая потеря.

Практический пример: на 100G линк Tx был стабилен, а Rx на одном конце на 6-7 dB слабее, чем ожидалось. После простой чистки коннекторов и переподключения Rx вернулся в норму, и CRC-ошибки исчезли без замены модулей.

Короткое правило перед заменой трансивера:

Сравните Rx на обоих концах и проверьте, не отличается ли он «на много».
Сверьте значения с порогами предупреждений/аварий модуля.
Если есть скачки Rx, начните с коннектора и механики кабеля.
Если уровни на грани, перепроверьте тип оптики под дистанцию.
Запишите Tx/Rx до и после действий, чтобы видеть, что реально изменилось.

Какие команды и счетчики смотреть на Cisco

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

Базовые команды для быстрой картины

Обычно хватает такого набора (названия команд могут немного отличаться между IOS XE и NX-OS, но смысл одинаковый):

show interface <int>: скорость/дуплекс, up/down, флаппинг, input/output errors, CRC, drops.
show interfaces <int> counters errors (или аналог): удобнее видеть именно CRC, symbol errors, input errors по строкам.
show interface <int> transceiver details: тип модуля, серийный номер, DOM-датчики (температура, напряжение, ток, Tx/Rx power).
show logging (фильтруйте по интерфейсу вручную): сообщения о link flap, несовместимости, ошибках модуля.
show controllers <int> (если доступно): низкоуровневые счетчики по физике, полезно при спорных случаях.

По FEC смотрите, включен ли он и есть ли исправления/неисправимые события. Если быстро растут именно uncorrectable FEC, связь может оставаться up, но трафик будет с потерями.

Что фиксировать перед заменами

Чтобы отличить "случилось" от "продолжается", сохраните значения дважды: сразу и через 3-5 минут под нагрузкой.

Время замера и имя интерфейса (с обеих сторон линка).
CRC/FCS и input/output errors: абсолютное число и прирост.
FEC corrected и uncorrectable: абсолютное число и прирост.
DOM: Tx/Rx power, температура, напряжение (сравните с типичным уровнем для вашей трассы).
События в логах: когда был flap и что написано про модуль.

Пример: на 100G линке CRC растут на одном конце, а на другом почти ноль. Одновременно Rx power на стороне с ошибками заметно ниже обычного, а FEC uncorrectable растет. Это часто указывает на физическую проблему (коннектор, загрязнение, изгиб, кабель), а не на "плохой" коммутатор. В интеграционных проектах в ЦОД (в том числе с серверными стойками и сетевой частью) такой снимок до любых действий экономит часы и помогает не менять модули вслепую.

Пошаговый алгоритм диагностики без лишних замен

Когда на 25/100GbE начинаются ошибки, больше всего времени теряется на хаотичные замены модулей и кабелей. Лучше действовать короткими циклами: зафиксировать базу, сравнить оба конца, потом делать только одну замену за раз.

Сначала запишите исходное состояние порта: поднят ли линк, какая скорость и тип интерфейса, есть ли флаппинг, когда был последний переход в up/down. На Cisco удобно начать с show interface <int> и show interface <int> transceiver details.

Дальше обязательно смотрите линию с двух сторон. То, что один конец передает (Tx), второй должен видеть как прием (Rx). Если на одном конце Rx на грани допустимого, а на другом все выглядит нормально, это уже подсказка: проблема может быть в волокне, коннекторе или патчкорде рядом с «плохим» концом.

Вот рабочий алгоритм, который обычно дает ответ за 10-20 минут:

Зафиксируйте базу: скорость, duplex, counters CRC, FEC (corrected/uncorrected), время аптайма, уровни Tx/Rx.
Сравните оба конца: рост ошибок должен коррелировать, а уровни Tx одного конца должны быть логичны относительно Rx другого.
Сбросьте счетчики и наблюдайте короткое окно 5-15 минут: clear counters interface <int> и снова снимите статистику. Важно не смешивать «старые» и «новые» ошибки.
Делайте минимальные перестановки по одному шагу: сначала патчкорд, затем модуль, затем порт (или перенос линка на соседний).
Подтвердите результат: уровни оптики стабильны, CRC не растет, uncorrected FEC не появляется, линк не флапает.

Пример: если после замены патчкорда Rx вырос на 2-3 dB и рост CRC остановился, модуль почти наверняка был исправен. Если же уровни Rx нормальные, но uncorrected FEC появляется сразу после сброса счетчиков, чаще виноват модуль или порт, а не кабель.

В проектах интеграции (в том числе при поставках и поддержке от GSE.kz) такой порядок помогает избежать лишних замен и быстрее собрать доказательства для гарантии или обслуживания.

Как отличить неисправный модуль от плохого кабеля

Когда на 25/100GbE растут ошибки (CRC, FEC) и линк то стабильный, то нет, обычно виноват один из трех: патчкорд/волокно, загрязнение коннекторов или сам трансивер. Реже - конкретный порт на коммутаторе. Смысл диагностики прост: понять, что именно "переезжает" вместе с проблемой при замене одного элемента.

Быстрые признаки по поведению Tx/Rx и счетчикам

Чаще всего плохой кабель или патчкорд выдает себя по Rx: уровень на приемнике низкий, может прыгать, а при легком касании кабеля или изгибе ошибки начинают сыпаться быстрее. Типичный сигнал - после замены короткого патча между кроссом и портом проблема исчезает, даже если модуль тот же.

Грязные или поврежденные коннекторы коварнее. После переподключений Rx может становиться хуже, а картина часто заметна с обеих сторон линии: на обоих концах растут FEC/CRC и одновременно проседает Rx. Если после очистки и аккуратной повторной посадки разъема показатели приходят в норму, модуль обычно ни при чем.

А вот неисправный модуль чаще дает "странности" по DOM: Tx неадекватный (слишком низкий или нестабильный без причины), модуль ощутимо греется, а счетчики ошибок растут даже при заведомо хорошем кабеле. Главный признак - проблема уезжает вместе с модулем на другой порт.

Еще один вариант - порт. Если вы ставите одинаковые модули, меняете патчи, а ошибки упорно остаются только на одном конкретном порту, стоит подозревать порт или его оптическую часть.

A/B тест, который дает однозначный вывод

Чтобы не запутаться, меняйте только один элемент за раз и фиксируйте, что именно менялось:

Возьмите "эталон": заведомо рабочий модуль и патч (лучше из того же типа и партии).
Поменяйте местами только патчкорды, модули оставьте как есть. Сдвинулась проблема - виноват патч или коннектор.
Верните патчи, а модули переставьте крест-накрест. Проблема переехала за модулем - модуль.
Если не переезжает ни за модулем, ни за патчем, переставьте линию в другой порт. Осталась на порту - порт.
Каждый шаг подтверждайте не только "линк поднялся", но и динамикой ошибок и Rx/Tx за одинаковый интервал времени.

Пример: на 100G CRC росли только ночью. Rx был на грани и менялся при касании патча в стойке. Перестановка модулей ничего не дала, а замена короткого патча между панелью и коммутатором полностью остановила рост ошибок. Это классический случай, когда диагностика проблем 25/100GbE упирается в механику, а не в электронику.

Оптика и волокно: совместимость и частые физические причины

В оптических линках 25/100GbE ошибки часто рождаются не в коммутаторе, а в несовместимости модуля и линии или в простой физике. Если FEC растет, а CRC то появляется, то исчезает, начните с базовой проверки оптики и волокна - это самый дешевый шаг в диагностике проблем 25/100GbE.

SR/LR/ER - это не про скорость, а про среду и дистанцию. SR обычно работает по многомоду (MM) на 850 нм, LR - по одномоду (SM) на 1310 нм, ER - на большие расстояния (часто 1550 нм) и может быть чувствителен к перегрузу по мощности на коротких линиях. Если поставить SR в одномод или наоборот, линк может не подняться вообще или будет нестабилен: Rx power будет слишком низким, а FEC начнет "подъедать" ошибки, пока не сорвется в линк-флап.

Отдельная история - полярность. При перепутанных Tx/Rx на двухволоконной оптике обычно видно простую картину: на одном конце Tx есть, а Rx почти ноль. Иногда патчкорд или адаптер уже "кроссует" пары, и добавочный кросс делает обратную перестановку. Это дает эффект "то работает, то нет" после замены одного короткого патча.

С 100G на MPO (параллельная оптика) типичные проблемы связаны с кассетами и переходниками. Неправильный тип (Type A/B/C), неверная ориентация ключа, не тот пиннинг (pinned/unpinned) - и часть полос (lanes) не получает свет. В итоге линк может подняться, но FEC будет расти очень быстро, потому что одна-две линии деградируют сильнее остальных.

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

Вот что стоит проверить перед заменой модулей:

Тип модуля и волокна: SR с MM, LR/ER с SM, совпадение длины волны и дистанции.
Полярность: не перепутаны ли Tx/Rx, нет ли лишнего "кросса" в патчах.
Для MPO: тип кассеты, ориентация, pinned/unpinned, чистота торца.
Механика трассы: радиус изгиба, натяжение, заломы у органайзеров.
Чистота коннекторов: даже новый патчкорд стоит протереть и осмотреть.

Простой пример: на 100G линк поднимается, но через час растет FEC и начинаются потери пакетов. Оказалось, MPO-кассета была Type A, а в линии ожидался Type B. Снаружи все выглядит "как обычно", но две полосы работали на грани по Rx, и любая вибрация превращалась в ошибки.

Типичные ошибки и ловушки при диагностике

Самая частая ошибка - воспринимать рост FEC как «линк сломан» и сразу менять модули, патчкорды и даже порт. FEC по смыслу показывает, что линия становится шумной, но не говорит, где именно проблема. На 25/100GbE FEC может расти из-за грязного коннектора, перегиба волокна, нестабильного питания модуля, перегрева или несовместимой оптики.

Вторая ловушка - смотреть на optical power без привязки к спецификации конкретного модуля. Одни трансиверы нормально работают при -10 dBm на Rx, другие уже на грани. Нельзя сравнивать «как на соседнем порту» и делать вывод. Сначала проверьте, какие диапазоны Tx/Rx заявлены для этого типа (SR, LR, DAC/AOC), а потом сопоставляйте с тем, что показывает интерфейс.

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

Еще один источник «призрачных» ошибок - температура. На Cisco можно увидеть температуру трансивера и иногда напряжение. Если модуль горячий, а в стойке плохой обдув, ошибки могут появляться только под нагрузкой или в жаркие часы.

Чтобы не попасть в ловушку со счетчиками, придерживайтесь простого правила наблюдения:

Сбросили счетчики только один раз и записали время
Наблюдайте фиксированный интервал (например, 10-15 минут) под похожей нагрузкой
Сравнивайте скорость роста CRC и FEC, а не абсолютные числа
Фиксируйте Tx/Rx power и температуру в начале и в конце
Не меняйте больше одного фактора за шаг

Пример: если CRC растет, а FEC почти нет, чаще подозревают «жесткую» физику (контакт, порт, кабель). Если FEC растет, но CRC почти нет, линия «тянет», но качество падает - сначала проверяют оптику, чистоту, изгибы и температурный режим.

Быстрый чеклист перед заменой оборудования

Когда на 25/100GbE растут ошибки и линк то «плавает», то поднимается, самое дорогое решение - начать менять все подряд. Этот чеклист помогает быстро сузить круг причин и не потерять исходные данные для сравнения.

Сначала зафиксируйте «снимок состояния» на обоих концах линии. Важно видеть не только факт ошибок, но и динамику: растут ли CRC, есть ли FEC-коррекции, меняется ли optical power Tx/Rx. Для Cisco обычно достаточно таких команд:

show interface <int> counters errors
show interface <int> transceiver details
show interface <int>

Дальше действуйте короткими шагами, меняя только одну вещь за раз:

Запишите текущие значения CRC/FEC и уровни Tx/Rx на обоих устройствах, плюс время и текущую нагрузку (например, бэкап или репликация).
Осмотрите физику: защелка модуля, посадка в порту, перегибы кабеля, натяжение, чистота коннекторов. Даже небольшая пыль на LC часто дает скачки Rx и FEC.
Меняйте по одному элементу в цепочке: сначала патчкорд (или DAC/AOC), потом модуль, затем порт. Если меняете модуль, переставьте его на другой порт и сравните поведение.
После каждого изменения сбросьте счетчики и наблюдайте 5-15 минут в одинаковых условиях. Без сброса легко перепутать старые ошибки с новыми.
В конце проверьте, что проблема не возвращается под нагрузкой: прогоните привычный трафик и убедитесь, что ошибки не накапливаются.

Практичный ориентир: если после замены патчкорда Rx стабилизировался и FEC перестал расти, чаще виновато соединение. Если ошибки «переезжают» вместе с модулем на другой порт, это сильный признак неисправного трансивера. Такой подход почти всегда ускоряет диагностику проблем 25/100GbE и снижает риск лишних замен.

Пример из практики: как нашли причину на 100G

Был 100G линк между двумя коммутаторами Cisco в одной стойке. Пользователи жаловались на редкие потери пакетов и «подвисания» приложений. По счетчикам на порту было видно, что FEC исправляет ошибки почти постоянно (corrected steadily растет), а раз в несколько минут появляются всплески CRC.

Первым делом сравнили оптические уровни Tx/Rx на обоих концах. Tx на обоих модулях выглядел нормальным и примерно одинаковым, а вот Rx отличался сильно: на стороне A прием был около -3 dBm (комфортно), а на стороне B прием гулял и иногда проваливался почти до порога low alarm. Это сразу сузило круг причин: если передача стабильная, а прием «на грани», чаще всего виноваты соединения по пути (патчкорд, загрязнение, плохой коннектор), а не «магия» в настройках.

Дальше сделали короткую серию перестановок, чтобы отделить «кабель» от «модуля»:

Поменяли местами патчкорды (A-B) и повторно посмотрели Rx.
Поменяли модули местами и снова сравнили Rx и рост ошибок.
Вернули исходные модули и поставили заведомо исправный патчкорд.

Картина получилась показательная: после замены патчкорда проблемный Rx «переехал» вместе с кабелем, а не вместе с модулем. Когда поставили другой патчкорд, Rx на обеих сторонах выровнялся, corrected FEC перестал расти так быстро, а всплески CRC исчезли.

Чтобы зафиксировать результат, оставили линк под рабочей нагрузкой на несколько часов и проверили три вещи: уровни Rx больше не прыгают, CRC не увеличивается, а FEC corrected растет медленно и без пиков (или не растет вовсе, зависит от линии и типа FEC). Такой подход в диагностике проблем 25/100GbE помогает не менять дорогие QSFP28 «наугад» и быстро находить виновника среди физики.

Следующие шаги: закрепить решение и не вернуть проблему

Когда вы нашли причину и ошибки FEC/CRC ушли, важно закрепить результат. На 25/100GbE проблема часто возвращается не потому, что “снова сломалось”, а потому что в стойке поменяли патчкорд местами, вставили модуль из другого заказа или тронули загрязненный коннектор.

Когда пора эскалировать

Эскалация нужна, если ошибки продолжаются после замены патчкорда и трансивера, а также если симптомы “переезжают” вместе с портом (например, на этом порту любой модуль начинает ошибиться). Еще один повод - подозрение на трассу: нестабильный Rx power, сильная асимметрия по парам/лейнам, или проблема появляется только при определенной укладке кабеля.

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

Точная модель устройства и версия ПО, номер порта, тип скорости (25G/100G).
Модель трансивера и серийный номер, а также для удаленной стороны (если доступно).
Показания DOM (Tx/Rx power, температура, напряжение) с обеих сторон, желательно в момент ошибки.
Счетчики ошибок (CRC, FEC corrected/uncorrected, symbol/align) за одинаковый интервал, например 10-15 минут под нагрузкой.
Что уже меняли и что менялось местами (модуль, патчкорд, порт, соседний слот).

Как снизить риск повторения

Хорошо работает простая дисциплина: стандартизировать патчкорды (тип, длина, производитель), вводить понятную маркировку “порт-порт”, и завести регламент чистки оптики и проверки коннекторов перед подключением. Если в эксплуатации много перемещений, полезно хранить патчкорды и модули в защитных колпачках и не оставлять торцы открытыми.

Если нужен комплексный подход (проверка линии, подбор совместимых SFP28/QSFP28, тестирование на стенде и последующая интеграция), это можно закрыть силами GSE.kz как производителя и системного интегратора, чтобы решение было повторяемым и документированным.