Edgecore AS5114-48X на dentOS: SFP+ в порту 18 нормально распознаётся, но onlpdump застревает на RX_LOS
Держим пару устройств ONIE в лабораторной стойке для тестирования, и одно из них - Edgecore AS5114-48X-O-AC-F-EC на dentOS. Порт 18 должен нести линк 10G до соседнего коммутатора, но он просто отказывается подниматься, хотя платформа явно видит модуль.
- Коммутатор: Edgecore AS5114-48X-O-AC-F-EC, dentOS (ARM64)
- Модуль: Intel FTLX8571D3BCV-IT SFP+ в порту 18
- Дуплексный патч-корд LC до дальнего конца, из той же партии, что и корды на рабочих портах
Ядро вполне довольно модулем, и уровень платформы его распознаёт, но бит состояния говорит другое:
kernel: ... port 18: switched to inband/10gbase-r link mode
$ onlpdump
...
sfp @ 18 = Present
Status: 0x00000004 [ RX_LOS ]Что уже сделал:
- переустановил модуль и почистил оба разъёма
- поменял TX и RX местами на дальнем конце, затем заменил весь патч-корд на заведомо исправный
- переставил тот же модуль в другой свободный порт - картина та же
То есть EEPROM читается нормально, и сторона MAC переключается в 10gbase-r, но приёмник вообще не видит света. Как чисто разделить это между модулем, волоконным хозяйством и платформой, если onlpdump даёт мне только флаг присутствия и битовую маску состояния и больше ничего?
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
RX_LOS сам по себе говорит только о том, что приёмник не видит достаточно света, так что прежде чем винить устройство: что сообщает дальний конец? Если у соседнего порта есть DDM, посмотрите его мощность Tx и убедитесь, что лазер реально включён, а порт не в shutdown. Также стоит знать, совпадают ли обе стороны по типу оптики и режиму волокна - модуль малой дальности напротив модуля большой дальности, или неверное волокно, выглядит ровно так же.
И пробовали ли вы второй модуль другого партномера в порту 18, или только этот один, переставленный между портами?
Дальний конец - это порт 10G на другом коммутаторе, с обеих сторон одинаковая оптика малой дальности. Этот порт нормально линкуется с другим модулем через тот же самый патч-корд, так что лазер соседа жив, а волоконный путь исправен из конца в конец. Порт 18 в состоянии admin up, и с перевёрнутым кордом результат идентичен.
Раздражает то, что я могу наблюдать локально: onlpdump даёт мне присутствие плюс битовую маску состояния, и это всё. У меня нет показателя Rx на стороне dentOS, чтобы сравнить с дальним концом, так что я застрял на «что-то не принимает», не зная, с какого конца.
От симптома к причине, в том порядке, в котором я бы это разбирал. Обнаружение доказывает исправность пути I2C/EEPROM и разводки MAC, и ничего больше. Строка ядра про inband/10gbase-r - это хостовая сторона настраивает саму себя, она не означает, что прилетел хотя бы один фотон. При взведённом RX_LOS остаются три подозреваемых: тёмное или перепутанное волокно, дальний конец, который не передаёт, и приёмник, который не работает на этой платформе.
Вы уже сильно поднажали на первые два, так что перестаньте собирать биты и получите цифру. Подойдёт любой коммутатор, печатающий цифровую диагностику. На EXOS это
show ports <port> transceiver information, которая даёт температуру, напряжение питания, ток смещения лазера, мощность Tx и Rx и помечает любое значение вне порогов модуля, аdebug hal show optic port <port>добавляет вендора, партномер, серийный номер, коннектор и длину волны из EEPROM. Я так гонялся за мёртвым портом 10G на X460-G2-24x-10G4 и обнаружил примерно -26,78 дБм на приёмнике, на что не захватится ни один приёмник 10G малой или большой дальности.Если дальний конец может дать вам показание Rx, пока ваш модуль передаёт, вы хотя бы узнаете, работает ли его лазер. То, что останется после этого, - платформа, не управляющая именно этой деталью.
У нас то же устройство, и на этой платформе поддержка модулей - по конкретной детали, а не по стандарту. На нашем AS5114-48X Avago AFBR-703SDZ-IN2 rev G2.3 поднимается вообще без всякой настройки - платформа сообщает его как Intel Corp с серийным номером AA1329A5UTA, что поначалу сбивает с толку.
Две детали у нас никогда не заработали в том же коммутаторе на том же волокне: Intel FTLX8571D3BCV-IT rev A, тот, что у вас, и OPNEXT TRS5020EN-S301. Оба распознавались, оба сидели ровно как ваш порт 18. Одолжите заведомо исправную деталь, прежде чем тратить ещё один вечер на волоконное хозяйство.
Стоит быть точным насчёт этого бита: RX_LOS - это собственный выход потери сигнала модуля, определённый в SFF-8472, а уровень платформы просто отображает его как статус 0x00000004. Он взводится ниже порога LOS приёмника, так что сообщает «недостаточно света» и никогда не сообщает почему. Именно поэтому идеально чистое чтение EEPROM и мёртвый оптический тракт сосуществуют без противоречия.
Ещё одна причина настаивать на реальном значении Rx: затухание из CLI выглядит идентично несовместимости. У коллеги был порт Zyxel с показателем около -25,69 дБм, и решением оказался патч-корд плюс патч-панель, которую кто-то переделал, а не модуль. Если не можете прочитать DDM на стороне dentOS, прочитайте с дальнего конца или с хоста - одна битовая маска этого не решит.