Cumulus Linux: LWL-Port nach Upgrade down – Negotiation failure richtig deuten

Auf einen Blick

Gilt für	NVIDIA-Spectrum-Switches mit Cumulus Linux 5.x (Beispiel: SN3420, Upgrade 5.16 → 5.18.3), LWL-Ports mit SFP28/QSFP28; Gegenseite VMware ESXi
Bereich	Netzwerk-Hardware
Dauer	ca. 10–15 Minuten für die Diagnose
Rechte	sudo auf dem Switch, Root/SSH auf dem ESXi-Host
Stand	November 2026

Bleibt unter Cumulus Linux ein LWL-Port nach einem Upgrade down, liegt die Ursache nicht zwangsläufig am Switch. In diesem Praxisfall kam ein 25G-Port auf einem NVIDIA SN3420 nach dem Update auf Cumulus Linux 5.18.3 nicht mehr hoch – gemeldet wurde „Negotiation failure“. Tatsächlich kam von der Gegenseite, einem VMware-ESXi-Host, schlicht kein Licht an. Ein kurzes Down/Up der vmnic auf dem ESXi brachte den Link zurück, ganz ohne Fahrt ins Rechenzentrum. Der Weg dorthin zeigt, warum man bei LWL-Ports zuerst auf die optischen Werte schaut, bevor man an Speed, Autonegotiation oder FEC dreht.

LWL-Port unter Cumulus Linux down: Der Switch sendet normal (TX −0,52 dBm), empfängt aber kein Licht (RX −40 dBm). „Negotiation failure“ ist nur die Folge – ein Down/Up der vmnic auf dem ESXi-Host holt den Link zurück.

Ausgangslage

• Switch: NVIDIA SN3420 mit Cumulus Linux, Upgrade von 5.16 auf 5.18.3
• Port: swp15, Transceiver FLEXOPTIX P.8525G.01 (SFP28, 25GBASE-SR)
• Gegenseite: VMware ESXi
• Symptom: Nach dem Upgrade kam swp15 nicht mehr hoch. Nur Ziehen und Neustecken des Transceivers vor Ort brachte den Link zurück.

Ziel war, das Problem ohne Einsatz vor Ort zu lösen.

Erster Blick: nv show interface

nv show interface swp15 zeigt einen Port, der administrativ up, operativ aber down ist – ohne Carrier und mit dem Hinweis „Negotiation failure“ (Auszug, Spalten operational und applied):

cumulus@switch:mgmt:~$ nv show interface swp15
...
link
  auto-negotiate              enabled
  speed                                                                  auto
  fec                         none                                       auto
  [flag]                      no-carrier
  state                       up                                         up
  oper-status                 down
  admin-status                up
  eyes                        0
  grade                       0
  troubleshooting-info        Negotiation failure
transceiver
  identifier                  SFP
  vendor-name                 FLEXOPTIX
  vendor-pn                   P.8525G.01
  temperature                 46.31 degrees C / 115.36 degrees F
  voltage                     3.2910 V
counters
  link
    carrier-up-count          0
    carrier-down-count        1

Der Transceiver wird erkannt, Temperatur und Spannung sind unauffällig. „Negotiation failure“ lenkt den Blick auf Autonegotiation, Speed und FEC – wie sich zeigte, eine falsche Fährte.

Was nicht geholfen hat

Versuch	Ergebnis
Modul-Reset per NVUE: nv action reset platform transceiver swp15	Reset laut Log erfolgreich, Port bleibt down
link state down, Speed fest auf 25G, Autoneg aus, link state up	Port bleibt down, weiterhin „Negotiation failure“
Zusätzlich FEC fest auf RS	Port bleibt down, operative FEC bleibt none

Die Log-Meldung zum Modul-Reset:

nvue-port-reset: The module reset was successfully completed on swp15.

Der Port-Status nach den festen Einstellungen (Auszug):

cumulus@switch:mgmt:~$ nv show interface swp15 link
                         operational              applied
-----------------------  -----------------------  --------
oper-status              down
auto-negotiate           disabled                 disabled
speed                    25G                      25G
fec                      none                     rs
[flag]                   no-carrier
troubleshooting-info     Negotiation failure

Auffällig: Trotz anderer Speed-, Autoneg- und FEC-Einstellung ändert sich am Fehlerbild nichts. Das ist ein erster Hinweis, dass das Problem unterhalb dieser Ebene liegt – auf der Bitübertragungsschicht (Layer 1 im OSI-Modell).

Vergleich mit einem funktionierenden Port

Der Nachbarport swp16 läuft mit den Standardwerten: Autoneg an, Speed und FEC auf auto. Er handelt 25G mit RS-FEC aus.

Wert	swp15 (down)	swp16 (up)
oper-status	down	up
auto-negotiate	disabled	enabled
speed (operational / applied)	25G / 25G	25G / auto
fec (operational / applied)	none / rs	rs / auto
Flags	no-carrier	lower-up
eyes / grade	0 / 0	55 / 14368
troubleshooting-info	Negotiation failure	No issue was observed

Der Vergleich zeigt, wie ein gesunder Link aussieht: Flag lower-up, Werte bei eyes und grade größer als 0. swp15 hat dagegen keinen Carrier und keine Signalqualität. Ein reines Konfigurationsproblem würde man so nicht erwarten.

Der entscheidende Befehl: l1-show und die RX-Power

sudo l1-show swp15 zeigt die Layer-1-Sicht inklusive der optischen Werte des Transceivers. Hier lag die Antwort (Auszug):

cumulus@switch:mgmt:~$ sudo l1-show swp15
Port:  swp15
  Module Info
      Vendor Name: FLEXOPTIX              PN: P.8525G.01
  Configured State
      Admin: Admin Up     Speed: 25G      MTU: 9216
      Autoneg: Off                        FEC: RS
  Operational State
      Link Status: Kernel: Down           Hardware: Down
      TX Power: ["{'mW': 0.8864, 'dBm': -0.52}"]
      RX Power: ["{'mW': 0.0001, 'dBm': -40.0}"]
      LLDP Neighbor:      None, None
  Port Hardware State:
      Compliance Code: 100GBASE-SR4 or 25GBASE-SR
      Cable Type: Optical Module (separated)
      Autodetect: FORCE - 25G
      Troubleshooting Info: Negotiation failure

Die beiden Zeilen, auf die es ankommt:

• TX Power −0,52 dBm: Der Switch sendet normal.
• RX Power −40,0 dBm: Es kommt kein Licht an. −40 dBm (0,0001 mW) ist praktisch der Messboden der Diagnosefunktion.

Ohne empfangenes Licht kann kein Link entstehen – egal, wie Speed, Autoneg oder FEC eingestellt sind. Der Fehler „Negotiation failure“ ist hier nur die Folge. Damit verlagerte sich die Suche auf die Gegenseite. Passend dazu meldet l1-show auch keinen LLDP-Nachbarn.

Dieselben Diagnosewerte (DDM/DOM) des Transceivers liefern auch nv show interface swp15 transceiver und sudo ethtool -m swp15.

RX-Power richtig einordnen

RX-Power (25GBASE-SR)	Bedeutung	Nächster Schritt
ca. −1 bis −8 dBm	normaler Empfang auf kurzer Multimode-Strecke	Link-Problem liegt eher bei Speed, FEC oder Autoneg
unter ca. −10 dBm	zu schwach – Grenze der Empfängerempfindlichkeit	Faser, Stecker und Patchfeld prüfen, Stirnflächen reinigen
−40 dBm bzw. -inf	kein Licht	Gegenseite sendet nicht, Faser unterbrochen oder Adern vertauscht

Die Werte sind Richtwerte nach IEEE 802.3by; maßgeblich sind das Datenblatt des Transceivers und dessen hinterlegte Alarm- und Warnschwellen.

Lösung auf der ESXi-Seite

Auf dem ESXi-Host reichte es, die betroffene vmnic kurz herunter- und wieder hochzufahren:

esxcli network nic down -n vmnicX
sleep 3
esxcli network nic up -n vmnicX

Danach kam swp15 wieder hoch. Welche vmnic betroffen ist, zeigt esxcli network nic list: Es ist die NIC, deren Link auf Down steht. Ist der Host nur über diese Uplinks erreichbar, vorher sicherstellen, dass Management-Netz und VMs über einen anderen Uplink laufen – etwa über einen zweiten Port im selben vSwitch.

Das erklärt auch, warum das Neustecken vor Ort geholfen hat: Es stößt offenbar auch die Gegenseite an, deren Sender nach dem Linkverlust während des Switch-Upgrades nicht wieder aktiv wurde. Den gleichen Effekt erreicht man remote direkt auf dem ESXi-Host. Tritt das Verhalten wiederholt auf, lohnt ein Blick auf Treiber- und Firmwarestand der Netzwerkkarte.

Erkenntnisse

1. Bei LWL-Ports zuerst l1-show ausführen. RX- und TX-Power sagen sofort, ob überhaupt Licht ankommt. Das spart das Herumprobieren an Speed, Autoneg und FEC.
2. „Negotiation failure“ nicht wörtlich nehmen. Die Meldung erschien auch mit abgeschaltetem Autoneg. Ursache war fehlendes Licht, keine gescheiterte Aushandlung.
3. RX −40 dBm bei normalem TX heißt: Gegenseite prüfen. Ein Modul-Reset auf dem Switch hat hier nichts geändert.
4. Mit einem funktionierenden Nachbarport vergleichen. eyes, grade und das Flag lower-up zeigen auf einen Blick, wie ein gesunder Link aussieht.
5. Testweise geänderte Einstellungen zurücksetzen. Nach der Lösung swp15 wieder auf die Standardwerte wie swp16 stellen:

nv unset interface swp15 link auto-negotiate
nv unset interface swp15 link speed
nv unset interface swp15 link fec
nv config apply -y

Checkliste für künftige Switch-Upgrades

• Nach dem Upgrade gezielt nach Ports suchen, die down sind (nv show interface, Spalte State).
• Bei LWL-Ports mit sudo l1-show swpN die RX-Power prüfen.
• Bei ESXi-Hosts zuerst die vmnic per esxcli neu starten, bevor jemand ins Rechenzentrum fährt.
• Erst wenn Licht ankommt, an Speed, Autoneg und FEC arbeiten.
• Port-Status und Transceiver-Werte dauerhaft überwachen, z. B. per SNMP – siehe Zabbix: Netzwerkgeräte per SNMP überwachen.

Cumulus Linux ist ein vollwertiges Debian-basiertes Linux auf dem Switch. Betrieb, Upgrades und Fehlersuche in solchen Umgebungen begleitet das Linux-Consulting von m.a.x. it.

Siehe auch

• Mellanox Interconnect und Switches – Hintergrund zu NVIDIA Networking (ehemals Mellanox)
• Glasfaser – Grundlagen zu Lichtwellenleitern
• Ethernet und OSI-Modell – wo Layer 1 einzuordnen ist
• VMware ESXi – der Hypervisor auf der Gegenseite
• Cisco Catalyst 9200: Software-Update im Install-Modus – Switch-Upgrades mit Rückfallebene

Links und Quellen

• NVIDIA: Cumulus Linux 5.18 – Switch Port Attributes (Speed, FEC, Autonegotiation, Transceiver-Werte)
• Linux-Consulting von m.a.x. it

Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen