CRS226 сообщает no-link и sfp-rx-lose yes на аплинке с кодировкой Cisco SFP-10G-LR
Приняли на обслуживание небольшой узел агрегации, и один из аплинков 10G не поднимается с тех пор, как в нём заменили модуль. Модуль числится несовместимым с CRS226, так что подозрение сразу пало на это, но показания не выглядят как отвергнутый модуль.
- MikroTik CRS226 на узле агрегации, модуль в sfp-sfpplus1
- Fiberworks SFP-10G-LR, с кодировкой Cisco
- одномодовая пара на удалённый узел, скоммутирована через две панели по пути
/interface ethernet monitor sfp-sfpplus1
status: no-link
sfp-rx-lose: yesТемпература и напряжение питания в том же выводе читаются совершенно нормально, и модуль явно определяется - это не показание пустого слота.
Уже сделано с нашей стороны:
- переустановил модуль и почистил оба коннектора
- переставил в другой порт SFP+, вывод идентичен
- проверил конфигурацию порта, ничего не форсировано, ничего не отключено
Так что это: CRS226 тихо отвергает модуль с кодировкой Cisco и сообщает об этом как no-link, или sfp-rx-lose означает то, что я думаю, и нужно отправлять кого-то на дальний конец?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Ваш собственный вывод уже ответил на вопрос о совместимости. Модуль, который коммутатор отверг бы, вообще не сообщал бы температуру и напряжение - полное показание монитора означает, что CRS226 прочитал модуль и прекрасно с ним разговаривает. А
sfp-rx-lose: yes- это собственная индикация потери сигнала модуля: он не видит света на приёмном волокне. Нет света на входе - нет линка, что бы там ни говорила кодировка.Так что это проблема инфраструктуры, а не совместимости. Порядок действий, который я бы выбрал:
К слову, тот же тип модуля работает в CRS226 на CCR здесь уже месяцами, так что сама пара - не проблема.
Что на дальнем конце, и показывает ли та сторона свой порт как поднятый? Если удалённый передатчик включён, вы бы ожидали хоть какую-то принимаемую мощность, а не чистую потерю сигнала.
Две дешёвые проверки, прежде чем кто-то поедет на объект. Поменяйте местами две жилы на своей патч-панели и посмотрите, останется ли флаг на месте. И попросите дальнюю сторону прочитать свой собственный модуль: если оба конца сообщают потерю приёма, пара повреждена где-то посередине, либо кто-то развёл не те жилы на одной из этих панелей.
Стоит разделять два вида неисправности, пока вы там. Полное отсутствие света - это ваш случай, и он простой. Более неприятный вариант - свет, который едва присутствует: один из пары оптических аплинков у нас зафиксировал аварию Rx power low на -20.2 дБм против порога -18.4 дБм и накопил 46 тысяч входных ошибок и 42 тысячи ошибок CRC, пока линк номинально оставался поднятым.
show interface transceiver detailиshow interface counters errorsрассказали эту историю.Полевая работа в любом случае одна и та же - почистить и осмотреть оба торца, измерить TX и RX, поискать слишком длинный участок, плохую сварку или дешёвый патч-корд, и заменить модуль, если уровни остаются низкими. У нас я так и не установил точного виновника, так что воспринимайте это как направление, а не как вердикт.
Ещё пункт для чек-листа дальнего конца: приёмник может умереть сам по себе, при полностью исправном волокне.
У Cisco есть уведомление о партии, FN-72192, касающееся партии QSFP-40G-LR4 - также продававшихся как QSFP-40G-LR4-S и WSP-Q40GLR4L - которые вышли с завода с приёмным детектором, слегка смещённым от нужного положения. Уведомление касается модулей с серийным номером, начинающимся на ACW, и датой выпуска в диапазоне ACW2415xxxx-ACW2449xxxx: на них приёмная сторона деградирует, и линк падает. Названная в уведомлении платформа - серия ASR 900. Обработка - замена при отказе, так что это проверка серийника и обращение в поддержку, а не что-то настраиваемое.
Часть, которая обобщается на ваш случай: раннее предупреждение - это значение приёма в данных DOM, которое равномерно сползает вниз, а не падает обрывом. Хороший аргумент в пользу того, чтобы графировать DOM на каждом аплинке, а не читать его один раз, когда что-то уже сломалось.
Насчёт доверия показаниям - в основном да, но не слепо. Ходил по кругу случай со стиком Huawei GPON ONT в слоте SFP+ MikroTik, сообщавшим очень низкую принимаемую мощность при скорости загрузки, застрявшей ниже 20 Мбит/с на гораздо более быстром тарифе, и так и не установили, виновато показание или сама линия. Так и осталось открытым.
На обычной паре LR, как у вас, я бы принял показания монитора за чистую монету. На нестандартных модулях в слоте SFP+ стоит получить второе показание с другого конца, прежде чем планировать выезд по этому поводу.