SONiC decodeert een CMIS 4.0 QSFP-DD naar verminkte vendorvelden terwijl SFF-modules prima parsen

Op welke branch zit je? Er zijn bekende inconsistenties in keynamen tussen show interfaces transceiver eeprom en sfputil in 202012 die in 202205 zijn rechtgezet, en het is de moeite waard om dat uit te sluiten voor je dieper graaft.

Post de output van sudo sfputil show eeprom -d voor dezelfde poort. Als sfputil je dezelfde verminkte strings geeft, zit de fout in het gedeelde decodepad. Geeft het in plaats daarvan een fout, dan zit je in ander territorium - we hebben platforms waar het gewoon Cannot get Module EEPROM data: Invalid argument antwoordt en nooit zo ver komt dat er iets gedecodeerd wordt.

Beide gedraaid: sudo sfputil show eeprom -d en show interfaces transceiver eeprom -d op dezelfde poort. Identieke verminking, dezelfde velden, dezelfde rommel waar het serienummer zou moeten staan. Nergens een Invalid argument, de uitlezing zelf gaat zonder klagen door.

De twee commando's zijn het dus met elkaar eens, ze zijn het alleen eens over het verkeerde antwoord. Aangrenzende QSFP28-poorten blijven bij beide schoon, wat het specifiek voor dit CMIS-onderdeel doet lijken in plaats van voor het platform.

Dat patroon is de handtekening van een parser die wordt toegepast op een geheugenmap die hij niet begrijpt: een partnummer dat in het vendornaamveld zit, een onleesbaar serienummer, connector en encoding verschoven. Een kapotte module of een kapotte I2C-uitlezing geeft je een fout of een blok nullen, geen keurig verkeerde strings.

Het decodepad zit in sonic_platform_base/sonic_sfp/sfputilbase.py, en daar worden de drie identiteitsstrings gehaald uit offsets die hardcoded zijn tegen de legacy SFF-map, wat er ook in zit. Een CMIS 4.0 QSFP-DD houdt zijn identiteitsblok niet op die adressen - de CMIS 4.0-spec beschrijft het in sectie 8.3 - dus de code leest echte bytes uit de juiste module, alleen niet de bytes die hij denkt te lezen, en print wat er toevallig in dat bereik zit. Dat is ook waarom niets ooit netjes faalt: geen enkele stap kijkt naar de identifier-byte en schakelt over naar een CMIS-layout.

De praktische conclusie is dat niets minder dan een parser die de CMIS-map begrijpt dit goed krijgt, en tot dat in jouw branch landt is de CLI-output voor dit onderdeel niet inventory-grade. Lees voor de assetdatabase de pagina's raw uit en decodeer ze zelf in plaats van de CLI af te schrapen.

Voor de raw-uitlezing is de optoe-driver wat je wilt: die legt SFP-, QSFP- en CMIS-EEPROM's bloot voor direct lezen en schrijven, zodat je de bytes kunt pakken en in je eigen script decoderen. Dat is op dit moment het enige wat ik aan een assetdatabase zou voeren voor CMIS-onderdelen.

Één waarschuwing als je naar offsets gaat zoeken. De tabel die iedereen aanhaalt is de SFF-tabel - A0h bytes 20-35 voor de vendornaam, 40-59 voor PN, rev en SN. Dat zijn precies de offsets die jouw rommel op een CMIS-module produceren, dus hergebruik ze daar niet. Zelfde voorzichtigheid op een Linux-host als bench-tool: ethtool -m voor de gedecodeerde weergave en ethtool -e voor raw bytes zijn prima voor SFP-onderdelen, maar controleer wat jouw build daadwerkelijk begrijpt voor je de velden vertrouwt die hij print voor CMIS.

CMIS-afhandeling is op meer plekken mager dan alleen de EEPROM-decoder. We hebben een tray InnoLight 800G QSFP-DD-optics in dienst genomen, T-DP8CNH-NNO en T-DP8CNT-NNO, en zowat elke tweede insertie leverde ons een dode poort op: datapaths meldden DataPathDeactivated, het log droeg een timeout voor 'ConfigSuccess', en van daaraf was de poort permanent down - geen retry, niets dat hem uit zichzelf terugbracht.

De boosdoener bleek decommission_all_datapaths() in cmis.py te zijn. Die doorloopt de hele sequentie achter elkaar - DEINIT, application ID op 0 gezet, dan INIT - en controleert nooit of een stap daadwerkelijk effect heeft gehad voordat de volgende begint. Onze onderdelen hebben precies die bevestiging nodig, dus blijft de datapath half geconfigureerd staan en zit de state machine gewoon zijn timer uit. Een echte fix moet asynchroon wachten, want je kunt niet blokkeren binnen de inline CMIS-state machine van xcvrd, en voor zover ik weet had niemand die geland. Andere bug, zelfde thema: een CMIS-pad geplakt op code die voor SFF-onderdelen geschreven is.

Eén correctie op de richting waarin dit afdrijft, want de twee faalwijzen worden voortdurend door elkaar gehaald. Cannot get Module EEPROM data: Invalid argument, of een QSFP die na een power cycle uit sfputil verdwijnt totdat de driver gefixt is, of een platform dat get_transceiver_info gewoon niet implementeert - dat zijn platform- en drivergaten, en die houden je tegen voordat er ook maar iets gedecodeerd wordt.

Wat hier beschreven wordt is het tegenovergestelde: een complete, geslaagde uitlezing die daarna met de verkeerde veldindeling geïnterpreteerd wordt. Ga hier geen modules voor verwisselen of driverversies voor najagen. De bytes in die module zijn prima, en elke tool die ze als CMIS decodeert zal je het serienummer op het label laten zien.