Adattatore QSA in una cage QSFP28 SONiC: l'ottica 10G si aggancia ma non riporta DDM
Stiamo riutilizzando un mucchio di ottiche 10G su uno switch whitebox con SONiC, quindi alcune cage QSFP28 sono equipaggiate con adattatori in stile QSA (10GTek QSA-100A) che portano semplici moduli SFP+ 10G. Meccanicamente ed elettricamente va tutto bene. È il lato gestionale dove crolla tutto.
- switch: whitebox 1U, SONiC compilato per quella piattaforma
- adattatori: 10GTek QSA-100A, cage QSFP28 verso SFP+
- ottiche: moduli SFP+ 10G tolti da uno switch di accesso dismesso
- le stesse ottiche si leggono normalmente in una cage SFP+ nativa su un altro box
Cosa vedo sulle porte adattate:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portProvato finora:
- ho sostituito con un secondo adattatore e una seconda ottica, comportamento identico;
- ho spostato la coppia in una diversa cage QSFP28, stesso risultato;
- ho verificato che le ottiche riportano diagnostica completa in una porta SFP+ nativa altrove.
I dati diagnostici mancanti sono qualcosa che un adattatore passivo semplicemente non può veicolare, oppure è una questione del software dello switch? E se è software, dove va collocata la correzione: nel layer di piattaforma o nel codice transceiver generico?
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 7
Prima che qualcuno si metta a scavare nel codice di piattaforma, una domanda che divide tutto in due. Metti un modulo QSFP28 nativo in quella stessa cage: ottieni diagnostica, oppure il DDM è morto su quella porta a prescindere da cosa ci inserisci?
Se la parte nativa si legge bene, la cage e il percorso I2C sono sani e tutto si riduce a come il driver di porta interpreta quello che arriva attraverso l'adattatore. Se anche la parte nativa torna vuota, smetti di leggere il resto del thread, hai un guasto diverso e non ha niente a che fare con gli adattatori.
Differenza ben nota e piuttosto noiosa nell'interfaccia di gestione, e qui l'adattatore non è il colpevole.
Sul lato SFP sono in gioco due indirizzi I2C: i dati identificativi vivono a 0x50, la mappa diagnostica a 0x51. Una parte QSFP tiene tutto sotto 0x50 e raggiunge il resto cambiando pagina. Quindi un driver a cui è stato detto che la cage è QSFP va a caccia di pagine su un unico indirizzo e non chiede mai nulla a 0x51. L'identificazione torna abbastanza plausibile da far alzare la porta, la diagnostica semplicemente non si risolve mai, che è esattamente la forma di quello che hai postato.
La correzione va collocata nel layer di piattaforma, non nell'ottica e non nell'adattatore. Ogni piattaforma porta con sé la propria implementazione di SfpUtil; nella tua, quella porta va dichiarata come cage SFP invece che QSFP. Finché qualcuno non lo fa, il DDM/DOM sulle porte adattate resta vuoto. Dopo, il modulo viene letto come sarebbe letto in una cage SFP+ nativa.
Un link attivo senza niente dietro nella diagnostica è l'aspetto che ha il software sbagliato su queste porte. Non è l'aspetto che ha un'ottica al limite.
Vale la pena nominare gli standard, perché a quel punto la divisione è ovvia. Il lato SFP è SFF-8472, dove la diagnostica vive nella propria mappa di memoria raggiunta al secondo indirizzo. QSFP e QSFP28 seguono SFF-8636, e le parti più recenti il CMIS, dove tutto pende da un unico indirizzo dietro una selezione di pagina.
L'adattatore non può fare da ponte su questo. È una parte meccanica ed elettrica passiva, i fili di gestione ci passano dritti attraverso e niente li traduce lungo il percorso. Quindi all'host bisogna dire quale dei due modelli di memoria si applica prima che legga anche un solo byte, e l'adattatore non ha modo di dirglielo.
Per contrasto, la stessa classe di problema su hardware Dell ONIE morde più forte. Un QSA 407-BBRO con dentro un SFP+ 10GBASE-SR 407-BBOU (SFP-10GSR-85), nelle porte 40G di un S4048-ON e in qualsiasi porta di un S6010-ON, entrambi con OpenSwitch OPX 3.1 dev2:
opx-ethtool identifica correttamente il media, segna il transceiver come enabled e qualified, admin state up, velocità supportate 1000, 10000 e 40000 Mbps, e la porta non si alza comunque mai, qualunque siano velocità, duplex o autoneg configurati, valori predefiniti inclusi. Qualcuno l'ha aperta sul repository OPX platform-config come richiesta di miglioramento, per favore fate funzionare il QSA qui, e nessuno ha mai risposto. È ancora lì aperta.
Non è un vendor lock e non è un'ottica difettosa. Quella cage semplicemente non viene mai messa in modalità adattatore dal network OS, e nessuna combinazione di impostazioni di interfaccia lo farà al posto tuo.
Correlato, ma per favore non mettete insieme i due casi. Quello che ha il post originale è un link funzionante con diagnostica mancante: il data path va bene, solo la lettura gestionale è sbagliata, e patchare lo SfpUtil di piattaforma la risolve. Il caso Dell è una porta che non si alza affatto, perché il profilo di porta per quella cage non viene proprio applicato. Quello sta un livello più sotto e richiede una correzione propria.
Chi abbina i sintomi in fretta rischia di bruciarsi una giornata a riscrivere codice del transceiver mentre la sua porta è giù per un motivo completamente diverso.
Un'altra variante di "l'adattatore è una funzione software" piuttosto che meccanica. Su uno Z9264F-ON con OS10 10.5.2.7, usare adattatori QSA28 per media SFP+ 10G significa mettere la porta nello stesso profilo port-group che usa un cavo breakout 4x10G:
I profili port-group su quella piattaforma agiscono su coppie di porte QSFP28, quindi applicarlo disabilita la porta gemella di ogni coppia. Un QSA28 è un'unica interfaccia e paghi comunque un prezzo a forma di breakout: 64 porte utilizzabili diventano 32. Né le guide utente di OS10 né il foglio tecnico delle ottiche Dell documentano una modalità QSA a porta singola.
Se ti serve molto 10G nativo su quel box, metti in conto in anticipo la perdita 2:1 oppure metti in rack uno switch 10G separato.
Prima che qualcuno ordini un vassoio di questi cosi, metterei due controlli in lista. Il network OS dichiara supporto QSA per quella esatta piattaforma, e se sì, cosa ti costa accenderlo: porte, diagnostica, o un profilo che si trascina dietro la cage vicina. L'inserimento fisico non è mai il problema, ognuno di questi adattatori entra nella cage senza fiatare.
I casi in questo thread differiscono solo per quanto lontano arriva il software. Su SONiC hai qualcosa che puoi correggere da solo, dichiari la porta come SFP e la diagnostica torna. Sulle piattaforme Dell qui sopra stai aspettando il codice di piattaforma di qualcun altro, e scambiare adattatori o ottiche non sposterà minimamente le cose.