Edgecore AS9716-32D: sfputil decodiert ein 400G-QSFP-DD-Modul unter PDDF als QSFP28
Wir bringen im Labor ein Paar AS9716-32D als 400G-Spine hoch, auf einem Community-SONiC-Image mit PDDF-Plattformschicht. Die Optik ist nicht das Problem, der Peer verlinkt sauber, aber alles, was der Switch über sie sagt, ist falsch.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- Community-SONiC-Build mit PDDF für diese Plattform
- 400G-QSFP-DD-Modul (NeoPhotonics-Teil) in der ersten Cage
Das Auslesen selbst klappt, das Modul wird gelistet, und die Cage wird als QSFP28 gemeldet:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsGenau an der Identifier-Zeile fällt es auseinander. Das ist ein QSFP-DD-Teil, die Bytes darunter werden also gegen den SFF-8636-Feldsatz decodiert statt gegen CMIS, und die folgenden Felder lesen sich wie Rauschen.
Bisher geprüft:
- das Modul selbst ist in Ordnung, dasselbe Teil liest sich auf einer anderen Plattform korrekt aus, und das andere Ende sieht Licht;
- Neusetzen und Umstecken in eine andere Cage ändert nichts, alle 400G-Ports verhalten sich identisch;
- in der PDDF-Gerätebeschreibung sind diese Cages als QSFP28 deklariert und an optoe1 gebunden.
Ist dieser letzte Punkt schon die ganze Antwort, brauchen QSFP-DD-Cages einfach ein anderes optoe-Device, und ist das Bearbeiten der Plattformbeschreibung der anerkannte Weg, das zu fixen, oder muss etwas darüber auch noch den Cage-Typ lernen?
Comments 4
Dein Symptom passt exakt auf das Binding, an der Optik muss also nicht weitergesucht werden.
Die PDDF-Gerätebeschreibung für den AS9716-32D deklariert die 400G-Cages als QSFP28 und bindet sie an optoe1. optoe1 legt das SFF-8636-EEPROM-Layout offen, das QSFP+ und QSFP28 nutzen, ein CMIS-Modul wird also durch die falsche Map gelesen, und alles hinter dem Identifier sieht wie Rauschen aus. Der Port-Typ, den man sieht, wird gar nicht erkannt, er steht einfach so in der Beschreibung.
QSFP-DD folgt CMIS, und CMIS wird von optoe3 bedient. Der Fix ist, beide Felder in der PDDF-Gerätebeschreibung für diese Cages umzudrehen: den Typ von QSFP28 auf QSFP-DD, und den Treiber von optoe1 auf optoe3. Verifiziert an derselben Box mit einem 400G-NeoPhotonics-Teil, und nach der Änderung liefert
sfputil show eepromdas Modul sauber decodiert.Zwei Einschränkungen. Es sind Plattformdaten, ein Image-Upgrade setzt die alte Beschreibung also munter zurück, wenn die Änderung nicht im gebauten Image steckt. Und upstream wurde genau diese Änderung zwar abgenickt, aber der Pull Request wurde geschlossen, ohne gemerged zu werden, die Arbeit ist in eine spätere Änderung eingeflossen - also nicht davon ausgehen, dass das eigene Image das schon mitbringt. Erst die Gerätebeschreibung für die eigene Plattform lesen, dann weiß man in einer Minute, ob es da überhaupt etwas zu jagen gibt.
Bevor irgendeine Plattformdatei angefasst wird, den rohen Dump posten:
sudo sfputil show eeprom -dauf diesem Port. Wenn alle Bytes da sind und nur die Interpretation daneben liegt, ist das ein Binding-Problem und kein Modul-Problem, und dieser Unterschied ist zehn Minuten wert, bevor jemand von RMA anfängt.Die andere Hälfte ist schon selbst beantwortet. optoe1 ist die SFF-8636-Variante für QSFP+ und QSFP28, ein CMIS-Modul, das darüber gelesen wird, kommt also ab dem Identifier verstümmelt raus - genau die Ausgabe, die gepostet wurde. Sobald die Beschreibung für eine QSFP-DD-Cage optoe1 nennt, bleibt auf der Modulseite nichts mehr zu verdächtigen.
Also auch die relevanten Zeilen der PDDF-Gerätebeschreibung für eine dieser Cages posten. Das zeigt, ob nur das Treiberfeld falsch ist oder auch der deklarierte Cage-Typ.
Das war's. Cage-Typ auf QSFP-DD, Treiber auf optoe3, Reload, und das Modul decodiert jetzt sauber,
sfputil show eepromnennt die Cage nicht mehr QSFP28. Die Änderung kam ins Image, das wir bauen, statt den laufenden Switch zu patchen, genau wegen des Upgrade-Punkts von oben.Ein ehrliches Wort für alle, die das später finden: Es behebt, wie das EEPROM gelesen wird, mehr nicht. Der Rest der Transceiver-Verrohrung auf dieser Plattform hat noch seine eigenen Macken, die Box würde ich nicht als komplett sauber bezeichnen.
Wo die verbleibenden Macken erwähnt werden: Hier ist die, die auf derselben Plattform wartet. An unserem AS9716-32D (x86_64-accton_as9716_32d-r0) mit einem SONiC-Master-Build listet
sudo sfputil show presencedie bestückten Ports als Present und liest ihr EEPROM sauber, währendshow interfaces transceiver presencejeden Port als Not present meldet. Das Syslog wiederholt:und das Auslesen des EEPROM über die CLI schlägt mit RuntimeError('PddfEeprom is not Programmed') fehl. Es taucht zufällig nach einem Reboot auf, eine Ursache wurde nie gepostet, sfputil bleibt hier also der einzige Presence-Check, dem man trauen kann.
Unabhängig davon, aber im selben Bereich: Die beiden Befehle sind auch dafür bekannt, sich im 202012-Branch bei den Key-Namen zu widersprechen, was in 202205 aufgeräumt wurde. Wenn die eigenen Ausgaben sich eher im Wortlaut als im Inhalt unterscheiden, ist es wahrscheinlich genau das.