ConnectX-4 MCX456A-ECAT linkt nicht zu einem Cisco NCS über 100GBASE-LR4, obwohl Loopback auf beiden Seiten besteht
Wir betreiben ein Racks-Paar, das an einen carrier-seitigen Cisco NCS übergibt, und einer der 100G-Server-Uplinks ist seit dem Aufbau nie hochgekommen. Gleiches Ergebnis, nachdem der Server in einen anderen Schrank mit anderem Patchpanel umgezogen wurde, also behandle ich es nicht mehr als Einzelfall.
- Supermicro-Server, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, beide Ports frei
- generisches 100GBASE-LR4 QSFP28, Singlemode, 10 km Reichweite, je eines an jedem Ende
- Cisco NCS auf der Gegenseite, Dark Fibre zwischen den beiden Räumen
Der Teil, an dem ich hänge: Jedes Modul besteht für sich einen Loopback am eigenen Gerät. Wird die Faser direkt in dasselbe QSFP28 zurückgeschleift, meldet die NIC einen sauberen 100G-Link, und der NCS macht dasselbe auf seiner Seite. Die echte Strecke dazwischen, und es ist nichts da.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noWas wir schon versucht haben:
- beide Module gegen Ersatzteile aus derselben Charge getauscht, keine Änderung
- den Server umgezogen und über ein anderes Panel neu gepatcht
- einen Case beim NIC-Hersteller aufgemacht, die Antwort war ein Verweis auf die validierte Transceiver-Liste in den Firmware-Release-Notes, was nicht erklärt, warum der Loopback funktioniert
Gibt es bei LR4 auf dem ConnectX-4 etwas, das lokal linken lässt, aber nie über eine echte Strecke, oder jage ich hier dem falschen Ende nach?
Comments 3
Das liest sich nach einer verschmutzten Strecke, nicht nach einem Kompatibilitätsproblem.
Alles, was bisher getauscht wurde, sitzt auf der Seite, die schon als gut getestet galt, deshalb hat sich nichts geändert - die Strecke selbst ist das Einzige, was noch unangetastet ist. Also die Strecke abarbeiten:
Die validierte Transceiver-Liste, auf die man dich verwiesen hat, lohnt einen Blick, aber ein Modul, das im Loopback sauber hochkommt, wird bereits korrekt von der NIC angesteuert. Kompatibilitätslisten erklären Module, die rundweg abgelehnt werden, nicht Module, die lokal linken und über eine Strecke sterben.
Hilft Reinigen nicht, ist der nächste Schritt eine Lichtquelle mit Leistungsmesser an der Dark Fibre, oder ein OTDR, falls sich eines ausleihen lässt, bevor eine weitere NIC oder ein weiteres Optikpaar gekauft wird.
Ein Loopback beweist nur, dass ein Port sich selbst hören kann - Laser, Empfänger, Ratensettings. Er sagt nichts über das Glas zwischen euren beiden Räumen, und das ist der eine Teil, der noch nicht getestet wurde. Also, bevor die NIC wieder beschuldigt wird: Zahlen von beiden Enden holen, mit eingebauter echter Strecke - wie hoch ist die Rx-Leistung am NCS-Port, und wie hoch an der NIC? Rx unter der Low-Warn-Schwelle mit eingebauter Strecke ist der klassische Hinweis auf die Gegenseite oder den Pfad, nicht auf den lokalen Port. Auf der Linux-Seite sollte
ethtool -mdenselben Wert liefern, und falls es mitCannot get module EEPROM information: Input/output errorzurückkommt, das nicht als totes Modul lesen - bei mlx5 ist das meist firmwareseitiger Modulzugriff, undmst start,mst cable addund danachmlxcablesliefern die Werte trotzdem.Reinigen war die Lösung. Wir haben ein Scope auf die Endflächen gehalten, und beide Module plus beide Patchkabel waren verschmutzt; das Kabel durch das Panel zwischen den Räumen war das schlimmere von beiden. Alles auf dem Pfad gereinigt, neu gesteckt, und der 100G-Link zum NCS kam beim ersten Versuch hoch und ist seitdem oben geblieben.
Leicht genervt von mir selbst, so lange Zeit auf die Kompatibilitätsschiene verwendet zu haben, wenn das Loopback-Ergebnis die ganze Zeit gesagt hat, dass die Module in Ordnung waren und der Pfad nicht. Für alle, die später hier landen: Loopback beweist den Port, nicht die Faser.