Edgecore AS9716-32D: sfputil decodeert een 400G QSFP-DD-module als QSFP28 onder PDDF
We zetten in het lab een paar AS9716-32D op als 400G-spine, op een community-SONiC-image met de PDDF-platformlaag. De optiek is niet het probleem, de peer linkt prima, maar alles wat de switch erover zegt klopt niet.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- community-SONiC-build met PDDF voor dit platform
- 400G QSFP-DD-module (onderdeel van NeoPhotonics) in het eerste slot
Het uitlezen zelf lukt, de module wordt getoond, en het slot wordt gemeld als QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsBij die identifier-regel gaat het mis. Dit is een QSFP-DD-onderdeel, dus de bytes daaronder worden gedecodeerd tegen de SFF-8636-veldenset in plaats van de CMIS-veldenset, en de velden die volgen lezen als ruis.
Tot nu toe gecontroleerd:
- de module zelf is in orde, hetzelfde onderdeel leest correct uit op een ander platform en de andere kant ziet licht;
- opnieuw plaatsen en naar een ander slot verhuizen verandert niets, alle 400G-poorten gedragen zich identiek;
- in de PDDF-device-description staan deze slots gedeclareerd als QSFP28 en gebonden aan optoe1.
Is dat laatste punt het hele antwoord, hebben QSFP-DD-slots gewoon een ander optoe-device nodig, en is het aanpassen van de platformbeschrijving de geaccepteerde manier om dit op te lossen, of moet er ook iets hogerop het slottype leren kennen?
Comments 4
Jouw symptoom komt precies overeen met de binding, dus geen reden om verder naar de optiek te kijken.
De PDDF-device-description voor de AS9716-32D declareert de 400G-slots als QSFP28 en bindt ze aan optoe1. optoe1 legt de SFF-8636-EEPROM-indeling bloot die QSFP+ en QSFP28 gebruiken, dus een CMIS-module wordt via de verkeerde map uitgelezen en alles na de identifier ziet eruit als ruis. Het poorttype dat je ziet wordt helemaal niet gedetecteerd, het is gewoon wat de beschrijving zegt.
QSFP-DD volgt CMIS, en CMIS wordt bediend door optoe3. De oplossing is om beide velden in de PDDF-device-description voor die slots om te zetten: het type van QSFP28 naar QSFP-DD, en de driver van optoe1 naar optoe3. Ik heb dat geverifieerd op dezelfde doos met een 400G NeoPhotonics-onderdeel, en na de wijziging geeft
sfputil show eepromde module netjes gedecodeerd terug.Twee kanttekeningen. Het is platformdata, dus een image-upgrade zet de oude beschrijving gewoon terug tenzij de wijziging in de image zit die je zelf bouwt. En upstream is precies deze wijziging goedgekeurd, maar de pull request is gesloten zonder gemerged te worden, het werk is opgenomen in een latere wijziging, dus ga er niet van uit dat jouw image dit al heeft. Lees eerst de device description voor jouw platform, dan weet je binnen een minuut of je hier überhaupt achteraan moet.
Voordat je aan een platformbestand komt, post de raw dump:
sudo sfputil show eeprom -dop die poort. Als alle bytes er staan en alleen de interpretatie mis is, is dit een bindingprobleem en geen moduleprobleem, en dat onderscheid is tien minuten waard voordat iemand over een RMA begint.De andere helft heb je zelf al beantwoord. optoe1 is de SFF-8636-variant die QSFP+ en QSFP28 gebruiken, dus een CMIS-module die daardoorheen wordt gelezen komt vanaf de identifier verminkt naar buiten, precies de output die je hebt geplakt. Zodra de beschrijving optoe1 noemt voor een QSFP-DD-slot valt er aan de modulekant niets meer te verdenken.
Plak dus ook de relevante regels van de PDDF-device-description voor een van die slots. Dat vertelt ons of alleen het driverveld fout staat of ook het opgegeven slottype.
Dat was het. Slottype naar QSFP-DD, driver naar optoe3, reload, en de module decodeert nu netjes, waarbij
sfputil show eepromhet slot niet meer QSFP28 noemt. Ik heb de wijziging in de image gezet die we bouwen in plaats van de draaiende switch te patchen, precies vanwege het upgradepunt hierboven.Eerlijke noot voor wie dit later vindt: het lost op hoe de EEPROM gelezen wordt, meer niet. De rest van de transceiverafhandeling op dit platform heeft nog steeds zijn eigen eigenaardigheden en ik zou de doos niet volledig op orde noemen.
Nu je de resterende eigenaardigheden noemt, hier is er eentje die op hetzelfde platform op je wacht. Op onze AS9716-32D (x86_64-accton_as9716_32d-r0) met een SONiC-masterbuild toont
sudo sfputil show presencede bezette poorten als Present en leest hun EEPROM prima uit, terwijlshow interfaces transceiver presenceelke poort als Not present meldt. Syslog herhaalt:en het uitlezen van de EEPROM via de CLI faalt met RuntimeError('PddfEeprom is not Programmed'). Het duikt willekeurig op na een reboot en er is nooit een grondoorzaak gepost, dus sfputil blijft daar de enige presence-check die ik vertrouw.
Los daarvan, maar in dezelfde hoek: de twee commando's staan er ook om bekend het oneens te zijn over key-namen in de 202012-branch, wat opgeschoond is in 202205. Als jouw output alleen in bewoording verschilt en niet in inhoud, is dat waarschijnlijk alles.