Halb kaputt ist meist schlimmer als ganz kaputt!

Eine erste Prüfung – nachdem ich mich über VPN mit dem Kundennetz verbunden hatte – ergab, dass die mir bekannten Subnetze in der Produktion allesamt erreichbar waren. Das Routing war aus meiner Perspektive unauffällig. Die IT-Abteilung vor Ort prüfte inzwischen verschiedene Meldungen im Netzwerkmanagement. Schließlich sagte einer: „Ich sehe bei einem Switch OSPF-Meldungen im Event Log!“

Das habe ich mir näher angesehen. Und richtig, alle paar Minuten meldete der Switch – ein Server Distribution Switch –, dass er einen benachbarten Router nicht mehr sehe. Jeweils kurz danach wurde der Router erneut erkannt, und so fort.

Wie waren die Kollegen vor Ort auf diese Meldung aufmerksam geworden? Im Netzwerkmanagement konnte man bei dem Switch ein kleines gelbes Dreieck erkennen, das auf einen „Minor Alarm“ hinwies. Auf einem Interface waren mehr fehlerhafte Pakete empfangen worden, als ein eingestellter Schwellwert zuließ. Die Prüfung ergab sehr schnell, dass es sich um genau dasjenige Interface handelte, auf welches sich auch die OSPF-Meldungen bezogen.

Was war zu tun, um den Fehler zu beheben? Wir haben einfach das betroffene Interface deaktiviert. Die Voraussetzung dafür war erfüllt, es gab eine Redundanz. Das Interface war eines von zweien, die den Server Distribution Switch mit dem Core verbanden. Nun wurden alle Pakete über dieses zweite Interface geroutet, das vermeintlich ohne Mängel war.

Ein gemeiner Fehler! Offensichtlich war ein Glasfaser-Transceiver defekt, sodass Pakete mit einer gewissen Wahrscheinlichkeit mit falscher Prüfsumme empfangen und also verworfen wurden. Das führte zu massiver Beeinträchtigung jeglicher Kommunikation über dieses Interface, wovon letztlich alle wichtigen Anwendungen betroffen waren.

Warum hatte das Routing-Protokoll OSPF die Verbindung nicht dauerhaft aus seiner Datenbank gelöscht? Das liegt an dem vielen Routing-Protokollen eigenen „Hello-Mechanismus“. Erst wenn mehrere Hello-Pakete in Folge verloren gehen, wird die Verbindung als inaktiv markiert.

Die Verkettung mehrerer Ereignisse führt zu einer Potenzierung der Wahrscheinlichkeiten. Nehmen wir die Paketverlustrate von 10% an. Dann beträgt die Wahrscheinlichkeit für den Verlust dreier aufeinanderfolgender Hello-Pakete 1/10³, also nur 0,1%.

Im Gegensatz dazu reicht der Empfang nur eines Hello-Pakets aus, damit das Routing-Protokoll die Verbindung wieder als aktiv markiert. Die Wahrscheinlichkeit dafür beträgt im genannten Beispiel 90%.

Fassen wir es noch einmal zusammen:

• Ein Glasfaser-Transceiver wird defekt und es entstehen Paketverluste.
• Die Paketverluste stören Anwendungen massiv.
• Die Redundanz wirkt nicht, weil das Routing-Protokoll die Störung kaum erkennen kann.
• Erst das Deaktivieren des Interface macht aus „halb kaputt“ ein „ganz kaputt“ und die Redundanz wirkt.

Die beschriebene Lösung war natürlich nur ein Workaround. Letztlich wurde im Rahmen eines späteren Wartungsfensters der defekte Transceiver getauscht und die Verbindung wieder in Betrieb genommen.

Was bleibt ist die Frage, wie man das Problem schneller hätte erkennen können. Warum hat das Netzwerkmanagement nicht bereits Alarm geschlagen, als die ersten Fehler auftraten? Hat es, nur hat keiner darauf reagiert, weil das Ereignis als „minor“ klassifiziert war. Minor Alarms gibt es in großen Netzen täglich zu hunderten und sie werden oft nachrangig behandelt. Ordnen Sie Interface Errors in eine höhere Alarm-Kategorie ein!

Am Ende wurde ich übrigens gefragt, ob man solche Ereignisse nicht mittels KI klassifizieren könne. Ich bin skeptisch und glaube, dass es dafür weiterhin der NI bedarf, der natürlichen Intelligenz. Zum Glück können Automaten uns nicht alles abnehmen. Doch helfen können sie, wenn man sie passend einrichtet.