Edgecore AS9716-32D: sfputil decodifica un modulo QSFP-DD da 400G come QSFP28 sotto PDDF
Stiamo portando su una coppia di AS9716-32D come spine a 400G in laboratorio, su un'immagine SONiC della community con il layer di piattaforma PDDF. L'ottica non è il problema, il peer fa link senza problemi, ma tutto quello che lo switch dice su di essa è sbagliato.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- build SONiC della community con PDDF per questa piattaforma
- modulo QSFP-DD da 400G (parte NeoPhotonics) nel primo slot
La lettura in sé va a buon fine, il modulo viene elencato, e lo slot viene riportato come QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsÈ la riga dell'identifier dove la cosa si rompe. Questa è una parte QSFP-DD, quindi i byte sottostanti vengono decodificati contro il set di campi SFF-8636 invece di quello CMIS, e i campi che seguono si leggono come rumore.
Controllato finora:
- il modulo in sé è a posto, la stessa parte si legge correttamente su un'altra piattaforma e l'altro capo vede la luce;
- riposizionarlo e spostarlo in un altro slot non cambia nulla, tutte le porte a 400G si comportano allo stesso modo;
- nella device description di PDDF questi slot sono dichiarati come QSFP28 e legati a optoe1.
Quest'ultimo punto è tutta la risposta, gli slot QSFP-DD hanno semplicemente bisogno di un device optoe diverso, e modificare la platform description è il modo giusto per sistemarlo, oppure c'è qualcosa più sopra che deve anch'esso imparare il tipo di slot?
Comments 4
Il tuo sintomo corrisponde esattamente al binding, quindi non serve guardare oltre nell'ottica.
La device description di PDDF per l'AS9716-32D dichiara gli slot a 400G come QSFP28 e li lega a optoe1. optoe1 espone il layout EEPROM SFF-8636 usato da QSFP+ e QSFP28, quindi un modulo CMIS viene letto con la mappa sbagliata e tutto ciò che segue l'identifier si legge come rumore. Il tipo di porta che vedi non viene rilevato affatto, è semplicemente quello che dice la description.
QSFP-DD segue il CMIS, e il CMIS è servito da optoe3. La correzione è invertire entrambi i campi nella device description di PDDF per quegli slot: il tipo da QSFP28 a QSFP-DD, e il driver da optoe1 a optoe3. L'ho verificato sulla stessa macchina con una parte NeoPhotonics da 400G, e dopo la modifica
sfputil show eepromrestituisce il modulo decodificato correttamente.Due avvertenze. È dato di piattaforma, quindi un upgrade dell'immagine rimette volentieri a posto la vecchia description a meno che la modifica non sia nell'immagine che ti costruisci tu. E a monte questa stessa modifica è stata approvata ma la pull request è stata chiusa senza essere mergiata, il lavoro è stato assorbito in una modifica successiva, quindi non dare per scontato che la tua immagine la porti già. Leggi prima la device description della tua piattaforma e saprai in un minuto se stai inseguendo qualcosa o no.
Prima di toccare qualsiasi file di piattaforma, posta il dump grezzo:
sudo sfputil show eeprom -dsu quella porta. Se tutti i byte ci sono e solo l'interpretazione è sbagliata, questo è un problema di binding e non un problema di modulo, e quella distinzione vale dieci minuti prima che qualcuno inizi a parlare di RMA.L'altra metà te la sei già risposto da solo. optoe1 è la variante SFF-8636 usata per QSFP+ e QSFP28, quindi un modulo CMIS letto attraverso di esso esce storpiato a partire dall'identifier, che è esattamente l'output che hai incollato. Una volta che la description indica optoe1 per uno slot QSFP-DD non resta nulla da sospettare sul lato modulo.
Quindi posta anche le righe rilevanti della device description di PDDF per uno di quegli slot. Questo ci dice se è sbagliato solo il campo del driver o anche il tipo di slot dichiarato.
Era proprio quello. Tipo di slot a QSFP-DD, driver a optoe3, reload, e ora il modulo si decodifica correttamente, con
sfputil show eepromche non chiama più lo slot QSFP28. Ho messo la modifica nell'immagine che costruiamo invece di patchare lo switch in produzione, proprio per il discorso dell'upgrade di cui sopra.Una nota onesta per chi lo trova più avanti: sistema solo il modo in cui viene letta l'EEPROM, niente di più. Il resto dell'idraulica dei transceiver su questa piattaforma ha ancora le sue stranezze e non definirei la macchina completamente a posto.
Visto che citi le stranezze rimaste, ecco quella che ti aspetta sulla stessa piattaforma. Sul nostro AS9716-32D (x86_64-accton_as9716_32d-r0) con una build master di SONiC,
sudo sfputil show presenceelenca le porte popolate come Present e ne legge bene l'EEPROM, mentreshow interfaces transceiver presenceriporta ogni porta come Not present. Il syslog ripete:e la lettura dell'EEPROM tramite CLI fallisce con RuntimeError('PddfEeprom is not Programmed'). Compare a caso dopo un reboot e non è mai stata pubblicata una causa radice, quindi lì l'unico controllo di presenza di cui mi fido resta sfputil.
Non c'entra ma è nella stessa zona: i due comandi sono noti anche per non essere d'accordo sui nomi delle chiavi nel branch 202012, ripulito nel 202205. Se i tuoi output differiscono nella dicitura più che nel contenuto, probabilmente è solo quello.