Оригинальный 160-9103-900 SFP+ поднимается в UCTF на Ciena 3930 - где список сертифицированных модулей
Ввожу в эксплуатацию 10G хэндофф для заказчика на 3930, который уже стоял на площадке. Модуль родной ciena'вский, со своего склада, порт действительно поднимается - но операционное состояние UCTF вместо Ena, и аварийный сигнал о несертифицированном трансивере висит постоянно. Приёмо-сдаточные испытания требуют чистого списка аварий, так что сдать объект в таком виде я не могу.
- Ciena 3930, ПО как поставлено на площадку
- Ciena 160-9103-900 SFP+ 10G
- одномодовая пара до NTU заказчика, короткое расстояние
> port xcvr show
Port 1 ... Oper State: UCTFЧто пробовал:
- переустанавливал модуль и переставлял на другой порт - тот же результат
- поставил второй 160-9103-900 с того же склада - точно такой же UCTF
- убедился, что линк реально пропускает трафик, то есть проблема не оптическая
Я рассчитывал, что модуль под брендом Ciena в коммутаторе Ciena - это единственная комбинация, которая никогда не спорит. Как узнать, какие модели трансиверов реально сертифицирует запущенное ПО, и что нужно сделать, чтобы статус "несертифицирован" ушёл?
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 4
Именно так, и на этом многие спотыкаются, потому что все думают, что проверка про производителя. Это не так. Коммутатор сравнивает кодировку, зашитую в модуль, со списком моделей, которые сертифицирует именно этот релиз ПО. Модуль производства Ciena, модели которого нет в этом списке, поднимается в UCTF, а модуль от вендора совместимой оптики, чья кодировка совпадает с записью в списке, поднимается чисто.
Последовательность действий такая:
Возьмите из первой команды запись, подходящую по скорости и дальности, и заказывайте модули с такой кодировкой. У нас был точно такой же UCTF на 3930, поставили ModuleTek 10G LR SFP+ с кодировкой XCVR-S10V31, которая есть в списке поддерживаемых - порт поднялся с операционным состоянием Ena и без индикации несертифицированности, и больше на коммутаторе ничего не трогали.
Стоит оговорить перед сдачей заказчику: это совпадение по кодировке, а не заявление о поддержке от вендора, так что если коробка на контракте - сначала проверьте, что говорит соглашение про оптику не от Ciena. Другой путь - релиз ПО, в котором 160-9103-900 всё-таки есть в списке, но на живом сервисе заказчика апгрейд обычно обходится дороже из двух вариантов.
Выполните
port xcvr show supportedи поищите свою модель в выводе. Команда выводит модели и линейные скорости, которые релиз на коробке готов сертифицировать, и только этот список имеет значение - а не то, что написано на корпусе.Выложите, что там выводится, или хотя бы скажите, есть ли в списке 160-9103-900. Если нет - ответ уже есть, и то, что модуль подлинный Ciena, тут ни при чём. Также стоит сказать, какой релиз SAOS стоит на 3930 - список привязан к релизу, и коробка, простоявшая на площадке какое-то время, вполне может быть на релизе старше, чем тот, где этот партномер уже появился.
Выполнил. Список длинный, но 160-9103-900 в нём нет - прошёл дважды. ПО - то, с которым коробка пришла, релиз никто не трогал с момента установки, и
port xcvr showпо-прежнему показывает порт в UCTF.То есть подлинная деталь Ciena несертифицирована на коммутаторе Ciena, потому что этот релиз её не знает. Не тот ответ, что я ожидал, но он объясняет, почему второй модуль с того же склада повёл себя точно так же.
Стоит добавить сценарий отказа, где дело вообще не в кодировке, потому что гоняться за кодировкой - дорогое удовольствие. На ME3600X с 15.3(1)S у меня было
%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supportedи err-disable по gbic-invalid на 10G модулях.service unsupported-transceiverиno errdisable detect cause gbic-invalidничего не меняли, модули вообще не появлялись вshow inventory,show interfaceне печатал тип среды вообще, а оптический измеритель не видел выхода Tx с них. Это была бракованная партия - модули, снятые с другого работающего ME3600, заработали сразу же. Отсутствие типа среды плюс отсутствие Tx-света - это аппаратная проблема, и никакая команда разблокировки тут не поможет.Другая крайность - кодировка, некорректная именно для платформы: сторонние 80 км DWDM SFP+ в ASR 9001 так и не поднялись, показывая generic PID, и
transceiver permit pid allих не спас, потому что IOS XR ждал PID вида DWDM-SFP10G-xx.yy из матрицы оптики этой платформы. Поставщик перекодировал партию, и они заработали. Ваш случай где-то посередине: кодировка валидна, просто её нет в списке этого релиза.