Jetzt anrufen Kontaktformular
Mo–Fr 8:00–17:00 Uhr
netAlly LinkRunner 100G auf einem ausgezogenen Rack-Fachboden im Rechenzentrum, über eine gelbe Singlemode-Faser mit dem Patchfeld verbunden

25G Fehlersuche: wenn der Link leise degradiert

Ein Switch-Port meldet keinen einzigen Fehler. Keine CRC-Fehler, keine Discards, die Schnittstelle steht seit Wochen auf up. Und trotzdem fällt genau diese Verbindung eines Morgens aus, ohne Vorwarnung, ohne dass jemand etwas geändert hätte.

Warum 25 Gigabit pro Lane eine andere Baustelle sind

Eine 100G-Verbindung nach 100GBASE-SR4 oder CR4 besteht aus vier parallelen Lanes mit je rund 25,8 Gigabaud. Jede dieser Lanes ist ein eigener Übertragungskanal mit eigenem Fehlerbudget, und das Budget ist knapp.

Bei 1G und 10G war das Auge des Signals so weit offen, dass ein leicht verschmutzter Steckverbinder, eine gequetschte Faser oder ein Twinax-Kabel am Rand seiner Spezifikation folgenlos blieben. Bei 25 Gbit pro Lane ist dieser Puffer weg. Ein einzelner Fingerabdruck auf einer MPO-Stirnfläche, ein Patchkabel mit zu engem Biegeradius, ein Transceiver von zweifelhafter Herkunft: All das erzeugt jetzt reale Bitfehler, und zwar sofort.

Das Bemerkenswerte ist nicht, dass diese Fehler entstehen. Das Bemerkenswerte ist, dass du sie nicht siehst.

Makroaufnahme einer MTP/MPO-Stirnfläche mit zwölf polierten Faserkernen und sichtbaren Staubpartikeln auf der Ferrule

FEC repariert die Fehler, und genau das ist das Problem

Weil bei diesen Geschwindigkeiten mit Fehlern gerechnet wird, ist Fehlerkorrektur fest eingebaut. 100G-Verbindungen im NRZ-Verfahren nutzen Reed-Solomon-FEC in der Variante RS(528,514).

Das funktioniert so: 514 Datensymbole zu je zehn Bit werden um 14 Prüfsymbole ergänzt, zusammen ein Codewort aus 528 Symbolen. Der Empfänger kann daraus bis zu sieben fehlerhafte Symbole pro Codewort rekonstruieren. Nicht erkennen, sondern wirklich reparieren.

Was oben ankommt, ist also ein sauberer Ethernet-Frame. Die Prüfsumme stimmt, der MAC-Layer ist zufrieden, die Anwendung merkt nichts. Ob die Korrektur dafür null Symbole zurechtrücken musste oder sechs von sieben möglichen, macht für den weitergereichten Frame keinen Unterschied.

Für dich macht es den ganzen Unterschied. Der eine Zustand ist eine kerngesunde Strecke. Der andere ist eine Strecke, die ihre Reserve fast aufgebraucht hat.

Frontseite eines Rechenzentrums-Switches mit QSFP28-Ports, alle Link-LEDs leuchten ruhig grün

Deshalb schweigen die Zähler im Switch

Die Zähler, auf die im Alltag jeder schaut, sitzen hinter der Fehlerkorrektur. FCS- und CRC-Fehler, Input Errors, Discards: Sie alle zählen, was die FEC nicht mehr retten konnte.

Solange die Korrektur greift, bleiben sie bei null. Eine Verbindung, die permanent am Rand ihres Fehlerbudgets läuft, sieht im Monitoring exakt so aus wie eine, die frisch abgenommen wurde. Beide melden: alles in Ordnung.

Die Information, die du bräuchtest, existiert durchaus. Sie steckt in den FEC-Zählern selbst, in der Zahl korrigierter Codewörter und in der daraus abgeleiteten Pre-FEC-Bitfehlerrate, also der Fehlerrate vor der Korrektur. Nur werden diese Werte in kaum einem Monitoring erfasst. Viele Plattformen zeigen sie nur auf Nachfrage in der Kommandozeile, und wo sie im NMS auftauchen, ist selten ein Schwellwert darauf gesetzt.

Und dann fällt die Verbindung, nicht langsam, sondern auf einen Schlag

Man würde erwarten, dass eine langsam schlechter werdende Strecke sich langsam bemerkbar macht: erst ein paar Paketverluste, dann mehr, dann bricht es zusammen. Bei FEC-gesicherten Verbindungen ist es nicht so.

Fachleute sprechen von der FEC-Klippe. Unterhalb der Korrekturgrenze läuft die Strecke praktisch fehlerfrei. Wird die Grenze überschritten, kann der Empfänger die Codewörter nicht mehr rekonstruieren, und die Verbindung bricht ein. Dazwischen liegt fast nichts. Der Übergang von „unauffällig“ zu „gestört“ ist eine Kante, keine Rampe.

Praktisch heißt das: Die Temperatur steigt im Sommer um ein paar Grad, ein Transceiver altert, jemand zieht beim Aufräumen im Rack an einem Patchkabel. Eine dieser Kleinigkeiten schiebt die Strecke über die Kante, und was vorher wochenlang stabil aussah, ist von einer Minute auf die andere ein Ausfall. Ohne Vorlauf, ohne Warnung in irgendeinem Zähler.

Der zweite Fall: der Link kommt gar nicht erst hoch

Es gibt eine zweite Sorte Fehler, die genauso still ist, nur am anderen Ende des Prozesses.

Für 25G definiert der Standard mehr als eine Art der Fehlerkorrektur: das ältere Firecode-Verfahren nach Clause 74 und das stärkere Reed-Solomon-Verfahren nach Clause 108. Dazu kommt die Möglichkeit, ganz ohne FEC zu fahren. Welche Variante zum Einsatz kommt, hängt von Medium, Distanz, Transceiver und der Konfiguration beider Seiten ab.

Sind die beiden Enden unterschiedlich eingestellt, kommt kein Link zustande. Die Schnittstelle bleibt auf down, und die Meldung dazu lautet meist nur, dass kein Träger anliegt. Das ist die gleiche Meldung wie bei einem nicht eingesteckten Kabel, einer gebrochenen Faser oder einem defekten Transceiver.

Der Klassiker: Eine neue Strecke wird gezogen, der Port bleibt tot, und die nächsten zwei Stunden gehen dafür drauf, Kabel zu tauschen und Optiken zu wechseln, während in Wirklichkeit auf einer Seite Clause 74 und auf der anderen Clause 108 eingestellt ist. Zwei Kommandos hätten es erledigt, wenn jemand gewusst hätte, wo er hinschauen muss.

EZ Wired auf dem LinkRunner 100G: erkannter Switch-Port mit Portname, Geschwindigkeit und VLAN-Zuordnung
QSFP Insights auf dem LinkRunner 100G: ausgelesener Transceiver-Typ, Wellenlänge, Reichweite und Lane-Details

Was du stattdessen messen musst

Aus beidem folgt dasselbe: Du brauchst Sicht auf die Übertragungsschicht selbst, nicht auf ihre Zusammenfassung im Switch.

Konkret sind das vier Dinge.

Die FEC-Konfiguration beider Seiten, ausgelesen statt vermutet. Das erledigt die Frage nach dem toten Port in Sekunden statt in Stunden.

Die Zahl korrigierter Codewörter und die Pre-FEC-Fehlerrate. Das ist der eigentliche Gesundheitswert einer Verbindung. Er sagt dir, wie viel Reserve noch da ist, und zwar bevor die Reserve aufgebraucht ist.

Optik und Modul unter realen Bedingungen. Sendeleistung, Empfangsleistung, Modultyp, Betriebstemperatur. Und wichtig: gemessen mit denselben Transceivern und derselben Faser, die auch im Produktivbetrieb stecken. Eine Abnahme mit dem guten Messgerätekabel sagt wenig über die Strecke aus, die anschließend in Betrieb geht.

Der Weg über das gesamte Netz. Weil viele Störungen, die wie ein Leitungsproblem aussehen, in Wahrheit ein überlastetes Interface drei Sprünge weiter sind.

Warum das bisher selten gemacht wurde

Nicht aus Nachlässigkeit, sondern weil die Messtechnik dafür bislang ein eigenes Projekt war. Modulare Analysatoren für 100G stehen im Rack oder fahren auf einem Wagen, kosten ein Vielfaches und werden im laufenden Betrieb entsprechend selten ausgepackt.

Genau daran hat sich gerade etwas geändert. Der netAlly LinkRunner 100G bringt diese Messungen in ein Handgerät von 900 Gramm, das jemand mit auf die Etage nimmt.

Er liest die FEC-Einstellung und die Modulparameter am QSFP28-Port automatisch aus, über 25G, 40G, 50G und 100G hinweg, auf Single-Mode und Multimode, an Trunks, LC-Breakouts und MTP/MPO-Strecken. Er zeigt den Pfad über Switches und Router bis zum Ziel und markiert unterwegs überlastete Interfaces und fehlerhafte Ports. Und mit zwei Geräten misst er die tatsächlich erreichbare Leistung von Ende zu Ende, statt sie aus Zählern hochzurechnen.

Dazu gehört AllyCare Pro, NetAllys Software- und Servicepaket, das mit dem aktuellen Release von AllyCare zu AllyCare Pro geworden ist: Ally Intelligence liest die Messergebnisse, nennt die Ursache im Klartext und schlägt die nächsten Schritte vor, dazu Topologie-Karten in Link-Live, Rogue Device Identification mit Nmap-Scans und Remote View & Control, alle Software-Updates über die Laufzeit inklusive. Für Abnahme, QSFP28-Prüfung und Pfadanalyse reicht ein Gerät, für den Leistungsnachweis von Ende zu Ende arbeiten zwei zusammen. Welche Konfiguration zu deinen Strecken passt, klären wir gern mit dir.

Path Analysis auf dem LinkRunner 100G: Weg über Switches und Router mit Auslastung je Sprung
Zwei Hände halten den netAlly LinkRunner 100G vor einem offenen Glasfaser-Verteilerfeld

Was du mitnehmen solltest

Wenn du 25G- oder 100G-Strecken betreibst, ist die wichtigste Erkenntnis diese: Ein Switch-Port ohne Fehlerzähler ist kein Beweis für eine gesunde Verbindung. Er ist nur ein Beweis dafür, dass die Fehlerkorrektur ihre Arbeit noch schafft.

Drei Dinge, die sich sofort umsetzen lassen:

  1. Bei der Abnahme neuer Strecken nicht nur prüfen, ob der Link steht, sondern mit welcher Reserve. Die Pre-FEC-Fehlerrate gehört ins Abnahmeprotokoll.
  2. FEC-Zähler ins Monitoring aufnehmen, wo die Plattform sie hergibt. Ein Trend über Wochen verrät die schleichende Verschlechterung, die ein Momentanwert nicht zeigt.
  3. Bei einem Port, der partout nicht hochkommt, die FEC-Einstellung beider Seiten prüfen, bevor Kabel und Optiken getauscht werden.

Du willst wissen, wie viel Reserve deine Strecken tatsächlich haben? Sprich uns an, wir messen das mit dir gemeinsam an einer deiner Verbindungen.

Wie viel Reserve haben deine 25G- und 100G-Strecken?

Wir messen die Pre-FEC-Fehlerrate gemeinsam mit dir an einer deiner Verbindungen, mit deinen Optiken und deiner Faser.