Netzwerkstörung am 11.12.2023

Einordnung

Unsere ersten Gehversuche mit dem Betrieb eines eigenen Netzwerks machten wir im Jahre 2018, damals noch wesentlich abhängig von unserem damaligen Rechenzentrum. Diese ersten Gehversuche waren naturgemäß noch nicht mit unserem heutigen – doch sehr stabilen – Netzbetrieb vergleichbar. Wir durften in den ersten Jahren viel aus unseren Fehlern lernen und haben dann Anfang 2020 unser eigenes AS (Autonomes System) in Betrieb genommen – und hierbei noch mal richtig Zeit und Geld investiert, um alle Kinderkrankheiten unseres ersten Setups auszumerzen. Natürlich: Carrier (von denen wir mehrere haben) können ausfallen, Internetknotenpunkte wie der DE-CIX (an den wir seit Jahren direkt angeschlossen sind) gestört sein, … aber derartige Probleme lösen sich designbedingt von selbst binnen Sekunden oder Minuten und betreffen immer nur einzelne Pfade. Bis zum 11.12.2023, an dem das dataforest-Netzwerk nachmittags knapp acht Minuten komplett offline war, hatten wir keinen einzigen Totalausfall des jetzigen Netzwerksetups, welches somit über dreieinhalb Jahre durchlief. Fast wären es vier geworden.

Montag

Eine Monitoringmeldung unser Netzwerk betreffend geht für den Bereitschaftshabenden zwar zunächst meist mit einer erhöhten Alarmbereitschaft einher, ist aber in aller Regel dann doch nichts Wildes. In dem Fall war zwei Minuten nach Störungsbeginn aber klar, dass wir ein größeres Problem haben, sodass eine Nachalarmierung an alle verfügbaren Mitarbeiter erfolgte, um vor allem die vielen Anrufe auf unserer Hotline bewältigen zu können – was dank gut funktionierender Eskalationsprozesse auch gelungen ist. Da wir hier viele technisch interessierte Leser haben, wollen wir die wesentlichen Ergebnisse unserer Erst- und Zweitprüfung transparent mit euch teilen. Für alle, die das nicht interessiert, findet sich unten ein kurzes Fazit.

Meldet unser Monitoring „alles weg“ und lässt sich das dann auch noch bestätigen, geht der erste Griff (metaphorisch) zu unserem Managementnetz, welches wir „out of band“, also komplett unabhängig von unserem eigenen Netzwerk, betreiben. Dieser Aufbau ist extrem wichtig, um niemals selbst ausgesperrt zu werden, egal ob durch eine Fehlkonfiguration oder eben einen Netzwerkausfall. Für den absoluten Notfall ist hierüber auch ein Zugriff auf die seriellen Schnittstellen unserer Routing- und Switching-Infrastruktur möglich.

Da das Managementnetz erreichbar war, konnten wir einen Stromausfall schon mal ausschließen – was wohl jeden Administrator, trotz in unserem Fall 100% SLA auf Strom & Klima am Standort maincubes, erstmal erleichtert aufatmen lässt. Ein Login auf dem aktiven Router zeigte dann zunächst, dass ein Failover von der primären Routing Engine auf die Standby-Routing-Engine stattgefunden hatte – das kann mal vorkommen und ist in der Vergangenheit auch schon passiert (sowohl geplant als auch ungeplant), aber „by design“ fällt dadurch nichts aus – und ist es auch noch nie. Unser Netzwerkaufbau strebt eine Verfügbarkeit von nahezu 100% an, das heißt im Wesentlichen: Es gibt keine zentrale Komponente, deren Ausfall auf Hard- oder Softwareseite eine ernsthafte Störung verursachen dürfte. Was war also passiert?

Akutanalyse

Alle systemrelevanten Prozesse liefen, alle Linecards und Netzteile waren da und fehlerfrei in Betrieb, keinerlei Fehler – die unser Monitoring auch erfasst, aber derzeit noch via SNMP und damit etwas zeitverögert zugestellt worden wären – waren ersichtlich. Mal abgesehen von dem Alarm ob des Umstands, dass die Standby-Routing-Engine derzeit aktiv war – und selbst die zunächst totgeglaubte primäre Routing Engine lief noch und hatte auch keinen „spontanen Reboot“ oder Ähnliches hinter sich. Eine schlechte Vorahnung bestätigte sich:

root@re1-mx480.mc-fra01.as58212.net> show bgp summary 
error: the routing subsystem is not running

root@re1-mx480.mc-fra01.as58212.net> show route table inet.0
error: the routing subsystem is not running

Das ist wirklich keine Meldung, die man sehen möchte. Aber sie ergab im Kontext der vorherigen Prüfung der Prozesse Sinn, denn wir wussten bereits, dass der „Routing Protocoll Process“ (kurz „rpd“) gerade erst neu gestartet war. Ein validierender Blick in die Logs bestätigte, dass dieser soeben gecrasht und noch dabei war, sich zu erholen. Wir konnten absehen, dass gleich wieder alles online sein würde, und so war es dann auch. Seit Störungsbeginn waren zum Zeitpunkt dieser Erkenntnis etwa fünf Minuten für die Erstanalyse vergangen und zwei Minuten später kamen die ersten Recovery-Meldungen von Opsgenie. Im Endeffekt mussten wir hier also zur eigentlichen Entstörung gar nicht eingreifen – kein schöner Vorfall, aber die Selbstheilung hat schon mal ein Stück Vertrauen zurückgebracht.

Ursache(n) des Ausfalls

Wie zuvor beschrieben hatte ein Failover auf die Standby-Routing-Engine stattgefunden, und die Vermutung lag nahe, dass dieser Vorgang auch ursächlich war. Schnell war klar, dass dem nicht so gewesen ist – tatsächlich lief das Netzwerk nach dem Failover noch ziemlich exakt fünf Minuten weiter. Warum der Failover – und warum die fünf Minuten? Das waren die zentralen Fragen, die es zu klären galt.

Einmal ist keinmal

Unsere Junos-Konfiguration (Junos ist das Betriebssystem des Netzwerkausrüsters Juniper Networks) sieht vor, dass bei einem Crash des „rpd“, der ja bei diesem Vorfall die Hauptrolle spielt, ein Switchover auf die Standby-Routing-Engine durchgeführt wird, auch wenn der Rest der aktiven Routing Engine einwandfrei funktioniert. Das ist meistens (Ausnahmen bestätigen die Regel) Best Practice und wird bei uns auch so bleiben. Die Konfiguration sorgt dafür, dass bei so einem Crash alles ausfallfrei weiterläuft. Zwar brauchen die Linecards zum Weiterleiten von Datenpaketen erstmal keinen „rpd“, aber Routingprotokolle wie BGP würden ihren Zustand verlieren und das wiederum würde dann eben doch binnen kürzester Zeit mindestens zu einem Teilausfall führen. Das Setting ist also sinnvoll und hat hier auch exakt das getan, was es sollte, nämlich beim Crash ausfallfrei die Routing Engine gewechselt. Denn dadurch, dass sich die Routing Engines permanent synchronisieren, ist ein Wechsel jederzeit ausfallfrei möglich (und wurde von uns zu Wartungszwecken auch schon mehrfach problem- und ausfallfrei durchgeführt). Die erste Frage war damit geklärt.

Aber zweimal ist zweimal zu viel

Der Failover infolge des rpd-Crashes fand um 14:21 Uhr statt. Um 14:23 Uhr crashte der Prozess auch auf der Standby-Routing-Engine. Und da nahm das Unheil seinen Lauf: Der „rpd“ auf der primären Routing Engine war einfach noch nicht wieder vollständig gestartet, sodass die Routing Engine in Junos-Sprache schlichtweg „not ready for switchover“ war. Es blieben noch 1-2 Minuten Toleranzzeit, bis uns alle unsere BGP-Upstreams „vergessen“ und aus der Routingtabelle geworfen hatten, denn auf unserer Seite lief ja kein BGP mehr. Dass die Linecards den Traffic noch eine Weile „orientierungslos“ weitergeleitet haben, half uns auch nicht mehr, denn unser AS verschwand allmählich aus dem Internet.

Kernursache und Lösung

Dass der rpd mal crasht, kommt wie gesagt vor. Sehr selten. Dass er das mehrfach tut und das Netzwerk in der Folge abraucht, kommt eigentlich nicht vor und kam bei uns eben auch noch nie vor. Nach intensiver Analyse der uns vorliegenden Core-Dumps und Logfiles konnten wir einen Junos-Bug ausfindig machen, der eindeutig dem hier beobachteten Verhalten entspricht, und mit einem neueren Release behoben ist, welches wir später dann auch eingespielt haben.

Schlechtes Timing

Bereits am 03.12.2023 hatten wir eine sechsminütige Störung eines Virtualisierungsracks, wovon ca. 50% unserer SolusVM-basierten vServer-Hostsysteme betroffen waren – zum Glück jedoch keine anderen Produkte wie Dedicated Server oder Colocation. Dieses Netzwerkproblem war auf eine Fehlkonfiguration zurückzuführen. Am 10.12.2023 gegen 3 Uhr morgens hatte einer unserer Carrier einen Totalausfall, was 80% unserer IPv4-Netze für gut zwei Minuten betraf und sich am 20.12.2023 gegen 11 Uhr wiederholte. Keiner der Vorfälle hatte etwas mit unserem Netzwerkausfall, um den es in diesem Artikel geht, zu tun, aber wir verstehen natürlich, dass diese Häufung bei einigen Kunden allgemeine Fragen zur Netzwerkstabilität im Dezember aufgeworfen hat, und sind sehr bemüht, nun wieder eine lange Phase der Stabilität liefern zu können – mindestens bezugnehmend auf das, was innerhalb unseres Einflussbereiches liegt.

Fazit und Verbesserungspotenzial

Dass unser Setup nach fast vier Jahren jetzt mal ein Problem hatte, erschüttert unser Grundvertrauen in dieses nicht, denn Hard- und Software sind nicht fehlerfrei, solche Bugs kommen (selten) vor und lassen sich in aller Regel eben auch schnell lösen. Die von uns eingesetzte Juniper-MX-Reihe gilt seit beinahe zwei Jahrzehnten auf dem Markt als „rock solid“ für den Betrieb von hochverfügbarer Netzwerkinfrastruktur. Und so sind wir überzeugt davon, das Problem mit dem eingespielten Update auch wirklich behoben zu haben. Dennoch können wir ein paar Lehren daraus ziehen:

1. Release unserer Statusseite: Zugegebenermaßen nicht erst seit dieser Störung von euch und uns gewünscht, soll diese nun dennoch Anlass genug dazu sein, mit status.dataforest.net endlich eine vernünftige Lösung für die Kommunikation von Störungen und Wartungsarbeiten zu schaffen und den Mix aus Social Media und E-Mails in Rente zu schicken. Ab Anfang Januar 2024 wird diese nun der zentrale Dreh- und Angelpunkt sein. Selbstverständlich kann die Statusseite auch entsprechend abonniert werden (vorerst per E-Mail, Slack, Atom/RSS).
2. Suboptimal verlaufene Notfallwartung: Angekündigt hatten wir Paketverluste im Sekundenbereich für den 17.12.2023, 3:00 Uhr. Zum einen kam die Ankündigung sehr kurzfristig, was daran lag, dass der Bug am Abend zuvor nach einer Woche ohne Probleme plötzlich wieder mehrfach auftrat (zwar jeweils ausfallfrei, aber wir waren natürlich alarmiert). Künftig würden wir ein entsprechendes Softwareupdate möglichst sofort nach der Störung ankündigen und dann allenfalls bei akuter Notwendigkeit noch mal vorziehen. Zum anderen kam es dann doch zu einer ärgerlichen Ausfallzeit von vollen fünf Minuten, was daran lag, dass die Linecards des Routers vollständig neu starteten. Das war schlicht eine Fehlinterpretation auf unserer Seite, für die wir uns jetzt nur noch entschuldigen können. Künftig werden wir abwägen, ob wir für ein solches Update zur Vermeidung einer richtigen Downtime unsere Kunden und Carrier auf einen Ersatzrouter migrieren – oder schlicht mit einer größeren Downtime kalkulieren und diese nicht nur ausdrücklich ankündigen, sondern auch in eine noch unkritischere Zeit legen. Eine solche Migration ist aber, wenn man eine Downtime so gut wie vollständig vermeiden will, keineswegs eine Sache von Minuten, und daher nicht immer eine realistische Option.
3. Bessere Trennung von Edge- und Core-Routing: Auch das war unabhängig von der Störung bereits in Arbeit – künftig werden wir unser Edge-Routing, also das Terminieren der BGP-Sessions zu unseren Upstreams, vom Core-Routing, wo die eigentlichen Kunden-VLANs terminieren, physisch trennen. Im Falle von Störungen und derartigen Wartungsarbeiten wird dies die Konvergenzzeit reduzieren.

In diesem Sinne: Danke fürs Lesen und frohe Weihnachten!