SONiC decodifica un QSFP-DD CMIS 4.0 in campi vendor illeggibili mentre i moduli SFF vengono letti correttamente

Su quale branch sei? Ci sono incongruenze note nei nomi delle chiavi tra show interfaces transceiver eeprom e sfputil nella 202012, risolte nella 202205, e vale la pena escluderle prima di scavare più a fondo.

Posta l'output di sudo sfputil show eeprom -d per la stessa porta. Se sfputil ti dà le stesse stringhe illeggibili, il difetto è nel percorso di decodifica condiviso. Se invece dà errore, sei in un territorio diverso - abbiamo piattaforme dove risponde semplicemente Cannot get Module EEPROM data: Invalid argument e non arriva nemmeno a decodificare nulla.

Ho eseguito entrambi: sudo sfputil show eeprom -d e show interfaces transceiver eeprom -d sulla stessa porta. Illeggibilità identica, stessi campi, stessa spazzatura dove dovrebbe esserci il seriale. Nessun Invalid argument da nessuna parte, la lettura in sé va a buon fine senza lamentarsi.

Quindi i due comandi concordano tra loro, solo che concordano sulla risposta sbagliata. Le porte QSFP28 adiacenti restano pulite con entrambi, il che fa sembrare la cosa specifica di questa parte CMIS piuttosto che della piattaforma.

Quel pattern è la firma di un parser applicato a una mappa di memoria che non capisce: un partnumber che siede nel campo del nome vendor, un seriale illeggibile, connector ed encoding spostati. Un modulo rotto o una lettura I2C rotta ti danno un errore o un blocco di zeri, non stringhe ordinatamente sbagliate.

Il percorso di decodifica vive in sonic_platform_base/sonic_sfp/sfputilbase.py, e lì le tre stringhe identificative vengono prelevate da offset fissati contro la mappa SFF legacy, qualunque cosa sia effettivamente inserita. Un QSFP-DD CMIS 4.0 non tiene il proprio blocco identificativo a quegli indirizzi - la specifica CMIS 4.0 lo descrive nella sezione 8.3 - quindi il codice sta leggendo byte genuini dal modulo giusto, solo non quelli che crede di leggere, e stampa qualunque cosa occupi quell'intervallo. Ed è anche per questo che non fallisce mai in modo pulito: nessun passaggio guarda il byte identificatore e passa a un layout CMIS.

La conclusione pratica è che niente di meno di un parser che capisca la mappa CMIS otterrà il risultato giusto, e finché quello non arriva sul tuo branch l'output della CLI per questa parte non è da livello inventario. Per il database degli asset, leggi le pagine grezze e decodificale da solo invece di fare scraping della CLI.

Per la lettura grezza, quello che ti serve è il driver optoe: espone gli EEPROM SFP, QSFP e CMIS per lettura e scrittura diretta, quindi puoi tirare fuori i byte e decodificarli nel tuo script. Al momento è l'unica cosa che darei in pasto a un database degli asset per parti CMIS.

Un avvertimento se vai a cercare gli offset. La tabella che tutti citano è quella SFF - A0h byte 20-35 per il nome vendor, 40-59 per PN, rev e SN. Sono esattamente gli offset che producono la tua spazzatura su un modulo CMIS, quindi non riusarli lì. Stessa cautela su un host Linux usato come strumento da banco: ethtool -m per la vista decodificata e ethtool -e per i byte grezzi vanno bene per le parti SFP, ma controlla cosa capisce davvero la tua build prima di fidarti dei campi che stampa per il CMIS.

La gestione del CMIS è debole in più punti del solo decoder EEPROM. Abbiamo messo in servizio un vassoio di ottiche InnoLight QSFP-DD 800G, T-DP8CNH-NNO e T-DP8CNT-NNO, e circa un inserimento su due ci lasciava con una porta morta: i datapath riportavano DataPathDeactivated, il log portava un timeout per 'ConfigSuccess', e da lì la porta restava giù in modo permanente - nessun retry, niente che la riportasse su da sola.

Il colpevole si è rivelato essere decommission_all_datapaths() in cmis.py. Percorre l'intera sequenza una dopo l'altra - DEINIT, application ID azzerato a 0, poi INIT - e non controlla mai che un passaggio abbia davvero avuto effetto prima di avviare il successivo. Le nostre parti richiedono esattamente quella conferma, quindi il datapath resta mezzo configurato e la state machine si limita ad aspettare che scada il suo timer. Una correzione vera deve aspettare in modo asincrono, dato che non puoi bloccare dentro la state machine CMIS inline di xcvrd, e l'ultima volta che ho controllato nessuno ne aveva ancora fatto atterrare una. Bug diverso, stesso tema: un percorso CMIS avvitato su codice scritto per parti SFF.

Una correzione alla direzione verso cui sta scivolando questo discorso, perché le due modalità di guasto si confondono di continuo. Cannot get Module EEPROM data: Invalid argument, oppure un QSFP che sparisce da sfputil dopo un power cycle finché il driver non viene corretto, oppure una piattaforma che semplicemente non implementa get_transceiver_info - quelle sono lacune di piattaforma e driver, e ti fermano prima che avvenga qualsiasi decodifica.

Quello descritto qui è l'opposto: una lettura completa e riuscita che viene poi interpretata con il layout dei campi sbagliato. Non scambiare moduli né rincorrere versioni di driver per questo. I byte dentro quel modulo stanno bene, e qualsiasi strumento che li decodifichi come CMIS ti mostrerà il seriale dell'etichetta.