Edgecore AS5114-48X su dentOS: lo SFP+ nella porta 18 viene enumerato correttamente ma onlpdump resta su RX_LOS

RX_LOS da solo dice solo che il ricevitore non vede abbastanza luce, quindi prima di dare la colpa al box: cosa riporta il lato remoto? Se la porta remota espone il DDM, leggi la sua potenza Tx e conferma che il laser sia davvero acceso e la porta non sia in shutdown. Vale la pena sapere anche se entrambi i lati usano lo stesso tipo di ottica e la stessa modalità di fibra - un modulo short reach che guarda un long reach, o la fibra sbagliata, ha esattamente questo aspetto.

E hai provato un secondo modulo con un partnumber diverso nella porta 18, o solo questo spostato tra le porte?

Il lato remoto è una porta 10G su un altro switch, stesse ottiche short reach su entrambi i lati. Quella porta si aggancia tranquillamente con un modulo diverso sulla stessa identica bretella, quindi il laser remoto è vivo e il percorso in fibra è buono end to end. La porta 18 è admin up, e ottengo lo stesso identico risultato con il cavo invertito.

La parte fastidiosa è quello che riesco a osservare in locale: onlpdump mi dà la presenza più la bitmask di stato, e basta. Non ho nessun valore Rx sul lato dentOS da confrontare col lato remoto, quindi resto bloccato su "qualcosa non riceve" senza sapere quale dei due lati.

Dal sintomo alla causa, nell'ordine in cui ci lavorerei io. Il rilevamento dimostra solo il percorso I2C/EEPROM e l'impianto MAC, nient'altro. La riga del kernel su inband/10gbase-r è il lato host che si autoconfigura - non significa che sia arrivato un solo fotone. Con RX_LOS asserito restano tre sospetti: una fibra spenta o incrociata, un lato remoto che non trasmette, e un ricevitore che non funziona su questa piattaforma.

Hai già spinto forte sui primi due, quindi smetti di raccogliere bit e procurati un numero. Va bene qualsiasi switch che stampi diagnostica digitale. Su EXOS è show ports <port> transceiver information, che dà temperatura, tensione di alimentazione, bias del laser, potenza Tx e Rx e segnala ogni valore fuori dalle soglie del modulo, e debug hal show optic port <port> aggiunge vendor, partnumber, seriale, connettore e lunghezza d'onda dall'EEPROM. Ho inseguito così una porta 10G morta su un X460-G2-24x-10G4 e ho trovato circa -26,78 dBm al ricevitore, valore su cui nessun ricevitore short o long reach a 10G si aggancerà mai.

Se il lato remoto può darti una lettura Rx mentre il tuo modulo trasmette, almeno impari se il suo laser funziona. Quello che resta dopo è la piattaforma che non pilota questa parte specifica.

Stesso box qui, e su questa piattaforma il supporto dei moduli è per singola parte, non per standard. Sul nostro AS5114-48X l'Avago AFBR-703SDZ-IN2 rev G2.3 si alza senza nessuna messa a punto - la piattaforma lo riporta come Intel Corp con seriale AA1329A5UTA, il che a prima vista confonde parecchio.

Due parti non ci hanno mai funzionato sullo stesso switch sulla stessa fibra: l'Intel FTLX8571D3BCV-IT rev A che hai tu, e un OPNEXT TRS5020EN-S301. Entrambi venivano rilevati, entrambi si comportavano esattamente come la tua porta 18. Fatti prestare una parte di sicura funzionalità prima di passare un'altra serata sull'impianto in fibra.

Vale la pena essere precisi su questo bit: RX_LOS è l'uscita di loss-of-signal propria del modulo come definita in SFF-8472, e il layer di piattaforma la espone semplicemente come stato 0x00000004. Si asserisce sotto la soglia LOS del ricevitore, quindi ti dice "non abbastanza luce" e mai il perché. Ed è anche per questo che una lettura EEPROM perfettamente pulita e un percorso ottico morto coesistono senza contraddizioni.

L'altro motivo per insistere su un numero Rx reale: dalla CLI l'attenuazione sembra identica all'incompatibilità. Un collega aveva una porta Zyxel ferma intorno a -25,69 dBm, e la correzione è stata la bretella più un patch panel che qualcuno aveva rimaneggiato, non il modulo. Se non puoi leggere il DDM sul lato dentOS, leggilo dal lato remoto o da un host - una bitmask da sola non risolverà la questione.