QSA-Adapter in einem SONiC-QSFP28-Käfig: Die 10G-Optik linkt, meldet aber kein DDM
Wir setzen auf einem Whitebox-Switch mit SONiC einen Stapel 10G-Optik weiter ein, ein paar QSFP28-Käfige sind also mit QSA-Adaptern (10GTek QSA-100A) bestückt, die schlichte 10G-SFP+-Module tragen. Mechanisch und elektrisch ist das in Ordnung. Auf der Management-Seite bricht es zusammen.
- Switch: 1U-Whitebox, SONiC für diese Plattform gebaut
- Adapter: 10GTek QSA-100A, QSFP28-Käfig zu SFP+
- Optik: 10G-SFP+-Module aus einem ausgemusterten Access-Switch
- dieselbe Optik liest sich in einem nativen SFP+-Käfig auf einer anderen Box normal aus
Was ich an den adaptierten Ports sehe:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portBisher versucht:
- einen zweiten Adapter und eine zweite Optik eingesetzt, identisches Verhalten;
- das Paar in einen anderen QSFP28-Käfig verschoben, gleiches Ergebnis;
- bestätigt, dass die Optik in einem nativen SFP+-Port an anderer Stelle vollständige Diagnosedaten liefert.
Ist das fehlende Diagnosedaten etwas, das ein passiver Adapter schlicht nicht tragen kann, oder liegt das an der Switch-Software? Und falls Software: Wo gehört der Fix hin, in den Plattform-Layer oder in den generischen Transceiver-Code?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Bevor sich jemand in Plattform-Code vergräbt, eine Frage, die das hier in zwei Hälften teilt. Steck ein natives QSFP28-Modul in denselben Käfig: Bekommst du daraus Diagnosedaten, oder ist DDM auf diesem Port tot, egal was reinkommt?
Wenn das native Teil sauber ausliest, sind Käfig und I2C-Pfad gesund, und das Ganze läuft darauf hinaus, wie der Port-Treiber interpretiert, was über den Adapter ankommt. Wenn das native Teil ebenfalls leer zurückkommt, hör auf, den Rest des Threads zu lesen, du hast einen anderen Fehler, und der hat nichts mit Adaptern zu tun.
Gut bekannter und ziemlich langweiliger Unterschied im Management-Interface, und der Adapter ist hier nicht der Schuldige.
Auf der SFP-Seite sind zwei I2C-Adressen im Spiel: Identifikationsdaten liegen bei 0x50, die Diagnose-Map bei 0x51. Ein QSFP-Teil hält alles unter 0x50 und erreicht den Rest per Page-Wechsel. Ein Treiber, dem gesagt wurde, der Käfig sei QSFP, sucht also Pages an einer einzigen Adresse und fragt 0x51 nie irgendetwas. Die Identifikation kommt plausibel genug zurück, damit der Port hochkommt, Diagnose löst sich einfach nie auf, genau die Form dessen, was du gepostet hast.
Der Fix gehört in den Plattform-Layer, nicht in die Optik und nicht in den Adapter. Jede Plattform bringt ihre eigene SfpUtil-Implementierung mit; in deiner muss dieser Port als SFP-Käfig statt als QSFP-Käfig deklariert werden. Bis das jemand macht, bleibt DDM/DOM auf adaptierten Ports leer. Danach wird das Modul so gelesen, wie es in einem nativen SFP+-Käfig gelesen würde.
Ein lebender Link ohne irgendetwas dahinter in der Diagnose ist, wie falsche Software an diesen Ports aussieht. Es ist nicht, wie eine grenzwertige Optik aussieht.
Lohnt sich, die Standards zu benennen, dann ist die Trennung offensichtlich. Die SFP-Seite ist SFF-8472, wo Diagnose in einer eigenen Memory-Map unter der zweiten Adresse liegt. QSFP und QSFP28 folgen SFF-8636, neuere Teile CMIS, wo alles an einer einzigen Adresse hinter einer Page-Auswahl hängt.
Der Adapter kann das nicht überbrücken. Er ist ein passives mechanisches und elektrisches Teil, die Management-Leitungen laufen einfach durch ihn hindurch, und nichts übersetzt sie unterwegs. Der Host muss also gesagt bekommen, welches der beiden Speichermodelle gilt, bevor er ein einziges Byte liest, und der Adapter hat keine Möglichkeit, ihm das zu sagen.
Zum Vergleich: Dieselbe Problemklasse beißt auf Dell-ONIE-Hardware härter. Ein 407-BBRO-QSA mit einem 407-BBOU-10GBASE-SR-SFP+ drin (SFP-10GSR-85), in den 40G-Ports eines S4048-ON und in jedem Port eines S6010-ON, beide mit OpenSwitch OPX 3.1 dev2:
opx-ethtool identifiziert das Medium korrekt, markiert den Transceiver als enabled und qualified, Admin State up, unterstützte Geschwindigkeiten 1000, 10000 und 40000 Mbps, und der Port kommt trotzdem nie hoch, egal welche Speed, Duplex oder Autoneg konfiguriert ist, Defaults eingeschlossen. Jemand hat es im OPX-platform-config-Repository als Enhancement Request eröffnet, please make the QSA work here, und niemand hat je geantwortet. Er steht immer noch offen.
Kein Vendor-Lock und keine schlechte Optik. Dieser Käfig wird vom Network-OS einfach nie in den Adaptermodus versetzt, und keine Kombination von Interface-Einstellungen erledigt das für dich.
Verwandt, aber bitte die beiden Fälle nicht zusammenwerfen. Der Ausgangspost hat einen funktionierenden Link mit fehlender Diagnose: Der Datenpfad ist in Ordnung, nur das Management-Auslesen ist falsch, und das Patchen der Plattform-SfpUtil behebt es. Der Dell-Fall ist ein Port, der überhaupt nie hochkommt, weil das Port-Profil für diesen Käfig von vornherein nie angewendet wird. Das sitzt eine Ebene tiefer und braucht seinen eigenen Fix.
Wer in Eile Symptome abgleicht, könnte einen Tag damit verbrennen, Transceiver-Code umzuschreiben, während der eigene Port aus einem völlig unabhängigen Grund down ist.
Noch eine Variante von "der Adapter ist ein Software-Feature" statt eines mechanischen. Auf einem Z9264F-ON unter OS10 10.5.2.7 bedeutet der Einsatz von QSA28-Adaptern für 10G-SFP+-Medien, den Port in dasselbe Port-Group-Profil zu stecken, das ein 4x10G-Breakout-Kabel nutzt:
Port-Group-Profile auf dieser Plattform wirken auf Paare von QSFP28-Ports, das Anwenden deaktiviert also den Partnerport jedes Paars. Ein QSA28 ist ein einzelnes Interface, und du zahlst trotzdem den Preis eines Breakouts: 64 nutzbare Ports werden zu 32. Weder die OS10-Benutzerhandbücher noch das Dell-Optik-Datenblatt dokumentieren einen Single-Port-QSA-Modus.
Wenn du viel natives 10G auf dieser Box brauchst, plane den 2:1-Verlust von vornherein ein oder stell einen separaten 10G-Switch ins Rack.
Bevor jemand ein Tray von diesen Dingern bestellt, würde ich zwei Checks auf die Liste setzen. Erklärt das Network-OS für genau diese Plattform überhaupt QSA-Support, und wenn ja, was kostet dich das Einschalten: Ports, Diagnose, oder ein Profil, das den Nachbarkäfig mit runterzieht. Passform ist nie das Problem, jeder dieser Adapter geht anstandslos in den Käfig.
Die Fälle in diesem Thread unterscheiden sich nur darin, wie weit die Software geht. Auf SONiC bekommst du etwas, das du selbst fixen kannst, den Port als SFP deklarieren, und die Diagnose kommt zurück. Auf den Dell-Plattformen oben wartest du auf den Plattform-Code von jemand anderem, und Adapter oder Optik zu tauschen bewegt daran gar nichts.