Edgecore AS5114-48X unter dentOS: SFP+ in Port 18 wird sauber erkannt, aber onlpdump bleibt bei RX_LOS
Wir haben im Laborrack ein paar ONIE-Boxen zum Testen stehen, eine davon ein Edgecore AS5114-48X-O-AC-F-EC mit dentOS. Port 18 soll einen 10G-Link zu einem benachbarten Switch tragen und weigert sich schlicht, hochzukommen, obwohl die Plattform das Modul eindeutig sieht.
- Switch: Edgecore AS5114-48X-O-AC-F-EC, dentOS (ARM64)
- Modul: Intel FTLX8571D3BCV-IT SFP+ in Port 18
- Duplex-LC-Patchkabel zum Gegenende, gleiche Charge wie die Kabel an den funktionierenden Ports
Der Kernel ist mit dem Modul völlig zufrieden, und der Plattform-Layer erkennt es, aber das Status-Bit erzählt eine andere Geschichte:
kernel: ... port 18: switched to inband/10gbase-r link mode
$ onlpdump
...
sfp @ 18 = Present
Status: 0x00000004 [ RX_LOS ]Was ich schon versucht habe:
- Modul neu gesteckt und beide Anschlüsse gereinigt
- TX und RX am Gegenende getauscht, dann das ganze Patchkabel gegen ein nachweislich funktionierendes ersetzt
- dasselbe Modul in einen anderen freien Port gesteckt, gleiches Bild dort
Das EEPROM liest sich also einwandfrei aus, und die MAC-Seite schaltet in 10gbase-r, aber der Empfänger sieht nie Licht. Wie trenne ich das sauber zwischen Modul, Faserstrecke und Plattform, wenn mir onlpdump nur ein Presence-Flag und eine Status-Bitmaske liefert und sonst nichts?
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 5
RX_LOS allein sagt nur, dass der Empfänger nicht genug Licht sieht. Bevor du also der Box die Schuld gibst: Was meldet das Gegenende? Wenn der Peer-Port DDM zeigt, lies dessen Tx-Leistung und bestätige, dass der Laser tatsächlich an ist und der Port nicht shut ist. Lohnt sich auch zu wissen, ob beide Seiten denselben Optik-Typ und Fasermodus fahren - ein Short-Reach-Modul gegenüber einem Long-Reach-Modul, oder die falsche Faser, sieht genau so aus.
Und hast du ein zweites Modul mit anderer Teilenummer in Port 18 probiert, oder nur dieses eine zwischen Ports verschoben?
Gegenende ist ein 10G-Port an einem anderen Switch, gleiche Short-Reach-Optik auf beiden Seiten. Dieser Port linkt problemlos mit einem anderen Modul über genau dasselbe Patchkabel, der Laser auf der Gegenseite lebt also, und die Faserstrecke ist Ende zu Ende in Ordnung. Port 18 ist admin up, und mit umgedrehtem Kabel bekomme ich das identische Ergebnis.
Das Ärgerliche ist, was ich lokal beobachten kann: onlpdump gibt mir Presence plus die Status-Bitmaske, und das war's. Ich habe keinen Rx-Wert auf der dentOS-Seite, um ihn mit dem Gegenende zu vergleichen, ich stecke also bei "da empfängt etwas nicht" fest, ohne zu wissen, welches Ende.
Vom Symptom zur Ursache, in der Reihenfolge, in der ich es angehen würde. Die Erkennung beweist nur den I2C/EEPROM-Pfad und die MAC-Verkabelung, sonst nichts. Die Kernel-Zeile zu inband/10gbase-r ist die Host-Seite, die sich selbst konfiguriert - das heißt nicht, dass auch nur ein einziges Photon angekommen ist. Bei gesetztem RX_LOS bleiben drei Verdächtige übrig: eine dunkle oder vertauschte Faser, ein Gegenende, das nicht sendet, und ein Empfänger, der auf dieser Plattform nicht funktioniert.
Die ersten beiden hast du schon gründlich durchleuchtet, also hör auf, Bits zu sammeln, und hol dir eine Zahl. Jeder Switch, der digitale Diagnosewerte ausgibt, reicht dafür. Auf EXOS ist das
show ports <port> transceiver information, was Temperatur, Versorgungsspannung, Laser-Bias, Tx- und Rx-Leistung liefert und jeden Wert außerhalb der Modul-Schwellen markiert, unddebug hal show optic port <port>ergänzt Hersteller, Teilenummer, Seriennummer, Anschlusstyp und Wellenlänge aus dem EEPROM. Ich bin damit mal einem toten 10G-Port an einem X460-G2-24x-10G4 hinterhergejagt und fand am Empfänger etwa -26,78 dBm, worauf kein 10G-Short- oder -Long-Reach-Empfänger einrastet.Wenn dir das Gegenende einen Rx-Wert liefern kann, während dein Modul sendet, erfährst du wenigstens, ob dessen Laser funktioniert. Was danach übrig bleibt, ist die Plattform, die dieses spezielle Teil nicht ansteuert.
Gleiche Box hier, und auf dieser Plattform ist Modul-Support pro Teil geregelt, nicht pro Standard. An unserem AS5114-48X kommt das Avago AFBR-703SDZ-IN2 Rev. G2.3 ganz ohne Tuning hoch - die Plattform meldet es als Intel Corp mit Seriennummer AA1329A5UTA, was auf den ersten Blick verwirrt.
Zwei Teile liefen bei uns nie im selben Switch an derselben Faser: das Intel FTLX8571D3BCV-IT Rev. A, das du hast, und ein OPNEXT TRS5020EN-S301. Beide wurden erkannt, beide saßen genau wie dein Port 18. Leih dir ein nachweislich funktionierendes Teil, bevor du einen weiteren Abend mit der Faserstrecke verbringst.
Lohnt sich, bei diesem Bit präzise zu sein: RX_LOS ist der eigene Loss-of-Signal-Ausgang des Moduls, wie in SFF-8472 definiert, und der Plattform-Layer zeigt ihn nur als Status 0x00000004 an. Es setzt unterhalb der LOS-Schwelle des Empfängers, sagt dir also "nicht genug Licht" und nie warum. Deshalb widersprechen sich ein makelloses EEPROM-Auslesen und eine tote optische Strecke auch nicht.
Der andere Grund, auf einem echten Rx-Wert zu bestehen: Dämpfung sieht in der CLI identisch zu Inkompatibilität aus. Ein Kollege hatte einen Zyxel-Port bei etwa -25,69 dBm sitzen, und die Lösung war das Patchkabel plus ein Patchpanel, das jemand verbastelt hatte, nicht das Modul. Wenn du auf der dentOS-Seite kein DDM lesen kannst, lies es vom Gegenende oder von einem Host - eine Bitmaske allein klärt das nicht.