Aufbau des dataforest-Netzwerks (kurze Fassung)

Wir betreiben innerhalb Frankfurts mehrere Standorte, verbinden diese mit eigenen Glasfaserstrecken und lassen (bisher) alles auf dem Interxion-Campus (heute eigentlich Digital Realty) zusammenlaufen, wo wir unser zentrales Edge-Routing betreiben und DDoS-Angriffe filtern. Dort binden wir mehrere Carrier und zahlreiche Peerings an. Wir peeren sowohl über öffentliche Internet Exchange Points (IXPs) wie DE-CIX mit vielen anderen Netzbetreibern, als auch über sogenannte Private Network Interconnects (PNIs) mit Netzen, mit denen wir besonders viel Traffic austauschen. Beispielhaft dafür genannt seien hier Google und Cloudflare. Neben mehreren Juniper MX-Routern spielen unsere Aggregation-Switches eine zentrale Rolle, denn sie verbinden nach innen und nach außen alle Bestandteile unseres Netzwerks.

Wir haben das Netzwerk in der jetzigen Form vor knapp drei Jahren angefangen zu planen und vor zweieinhalb Jahren mit der Umsetzung begonnen. Zu dem Zeitpunkt nannten wir das Projekt liebevoll "Terabit-Backbone" (was schnell zu einer Untertreibung mutierte). Die Wahl fiel auf Juniper QFX5220-32CD als Aggregation-Switches, denn sie bieten pro Gerät 32x 400G und für uns war klar, dass wir unser neues Netzwerkkonzept mit 400G-Technik realisieren wollten, um für die Zukunft gerüstet zu sein. Zwar setzen wir im Coreswitching für unsere Serverlandschaft schon seit über fünf Jahren nur noch Arista ein, die im Bereich 40G und 100G preis-/leistungstechnisch die Nase vorn haben und wirklich überragend stabil laufen, aber für unseren neuen PoP mussten 400G-Switches her, und die Verfügbarkeit solcher war bei Juniper damals wesentlich besser.

Natürlich war auch damals schon klar, dass wir (wie schon zuvor, nur damals halt auf ein Rechenzentrum beschränkt) ein Netzwerk betreiben wollen, das auf Hochverfügbarkeit ausgelegt ist, also im Core- und Edge-Bereich keine zentralen Komponenten enthält, deren Ausfall oder Defekt desaströs enden könnte. Und das Redundanzkonzept funktioniert auch – wir hatten seit Betrieb unseres eigenen AS58212 noch nie einen hardwarebedingten Ausfall. Nun ist die Hardware leider nur ein Aspekt von vielen und es gibt Tausend Wege, sich das Netzwerk abzureißen – am besagten 23.10.2025 haben wir einen dieser Wege "erfolgreich" eingeschlagen. Dazu gleich mehr.

Beim Zusammenfügen mehrerer Juniper-Switches zu einem hochverfügbaren Geräteverbund gibt es zwei Möglichkeiten, und viele Hersteller bieten sehr vergleichbare Optionen an. Die erste, bei Juniper wohl gebräuchlichste und auch bekannteste, ist ein sogenanntes Virtual Chassis (VC). Hierbei übernimmt ein primärer Switch die Rolle der Control Plane inklusive Management (SSH) und die anderen Geräte im Verbund werden über diesen gesteuert, sind also selbst nicht mehr "managebar" per SSH. Die Config kommt komplett vom primären Switch. Fällt dieser hardwareseitig aus, ist das typischerweise kein Problem für ein VC – ein anderer Switch übernimmt die Rolle des “Chefs” und das Packet Forwarding läuft nach wenigen Sekunden einfach weiter. Wenn jedoch ein Softwarefehler auftritt, kann sich das VC auch mal derart auf die Nase legen, dass ohne “Strom raus und wieder rein” nichts mehr geht. Wir haben damit vor gut sechs bis sieben Jahren schon mal leidige Erfahrungen gemacht und wollten diese ungern wiederholen.

Wenig überraschend haben wir aus unseren Aggregation-Switches also kein VC gebildet. Stattdessen wurden die Switches per MC-LAG zusammengeschaltet. MC-LAG funktioniert konzeptionell anders: Hier bleiben beide Switches eigenständige Geräte mit eigener Control Plane, eigenem Management und eigener Software. Sie werden nur so gekoppelt, dass angeschlossene “Clients” (bei uns primär Router und DDoS-Filter) deren Links als einen einzigen LACP-Channel sehen und alle Links "Active/Active" nutzen können. Zwischen den Geräten läuft das Inter-Chassis Control Protocol (ICCP), das den Zustand der Links und Forwarding-Informationen abgleicht – ohne, dass das Ganze gleich zu einem einzigen Chassis "verschmilzt". Der große Vorteil: Stürzt die Software auf einem der beiden Switches ab oder verhält sich merkwürdig, ist der zweite im Zweifel davon weniger betroffen, weil er seine eigene Prozesswelt behält und unabhängig weiterarbeiten kann. Gerät das MC-LAG in eine Split-Brain-Situation (was bei unserem redundanten ICCP-Link plus konfiguriertem Fallback übers Managementnetz sehr unwahrscheinlich ist), ist klar geregelt, wie sich die Geräte verhalten und was passiert. Im Gegenzug ist das Setup komplexer, erfolgt für jeden LACP-Channel individuell und jede Konfiguration muss auf jedem Gerät einzeln gemacht werden.

Timeline der Störung

13:26:05 Uhr: Wir committen folgende Konfiguration auf beiden Switches:

[edit interfaces irb]
+    unit 97 {
+        family inet {
+            address 10.97.2.2/29;
+        }
+    }
[edit vlans vlan-97]
+  l3-interface irb.97;
+  mcae-mac-synchronize;

13:26:21 Uhr: Der "Layer 2 Address Learning Daemon" verabschiedet sich krachend; wegen des Bugs auf beiden Switches gleichzeitig:

(Originalausgabe um inhaltlich redundante Meldungen gekürzt und auf eines der Geräte beschränkt)

Oct 23 13:26:07 ca2.ix-fra8 audit [15352]: ANOM_ABEND auid=4294967295 uid=0 ses=4294967295 pid=15352 comm="l2ald" exe=" /usr/sbin/l2ald" sig=6 res=1
Oct 23 13:26:11 ca2.ix-fra8 systemd [1]: l2ald.service: Main process exited, code=dumped, status=6/abrt
Oct 23 13:26:35 ca2.ix-fra8 audit [17874]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=17874 comm="l2ald" exe=" /usr/sbin/l2ald” sig=6 res=1
Oct 23 13:27:13 ca2.ix-fra8 audit [21210]: ANOM_ABEND auid=4294967295 uid=0 ses=4294967295 pid=21210 comm="l2ald" exe=" /usr/sbin/l2ald" sig=6 res=1
Oct 23 13:27:41 ca2.ix-fra8 audit [22866]: ANOM_ABEND auid=4294967295 uid=0 ses=4294967295 pid=22866 comm="l2ald" exe=" /usr/sbin/l2ald" sig=6 res=1
Oct 23 13:27:45 ca2.ix-fra8 systemd [1]: l2ald.service: Main process exited, code=dumped, status=6/abrt
Oct 23 13:27:45 ca2.ix-fra8 systemd [1]: l2ald.service: Start request repeated too quickly.
Oct 23 13:27:45 ca2.ix-fra8 systemd [1]: Failed to start "Layer 2 Address Flooding and Learning Daemon on RE."
Oct 23 13:27:45 ca2.ix-fra8 sysman [9242]: SYSTEM_APP_FAILED_EVENT: App has failed re0-l2ald
Oct 23 13:27:45 ca2.ix-fra8 emfd-fpa [11097]: EMF_EVO_ALARM_SET: Alarm set: APP color=red, class=chassis, reason=Application l2ald fail on node Re0

Hier ist anzumerken, dass der Prozess nur auf ca2 offline blieb. Auf ca1 kam er nach mehreren identischen Crashs zurück. Geholfen hat das letztendlich nicht, denn durch das Fehlerbild waren am Ende trotzdem beide Geräte betroffen.

13:31:29 Uhr:

Unser Observium schickt Alerts zu ca2.ix-fra8 an den Bereitschaftshabenden, da dessen Chassis einen "Red"-Alarm meldet, der ebenfalls um 13:31 Uhr acknowledged wird. Als der Kollege um 13:33 Uhr am Rechner ist, ist die Störung bereits bekannt und der "Red"-Alarm wird nicht an die Netzwerkabteilung weitergegeben, was sich später als Fehler herausstellt. Mehr dazu im untenstehenden Maßnahmenplan.

13:33:08 Uhr:

Mindestens der Switch ca2 verliert seine MAC-Tabelle, weil der (gecrashte) l2ald diese nicht mehr aktuell halten kann. Als erste Folge zerlegt es den Inter-Chassis-Link des MC-LAGs. Wenigstens da sind sich beide Geräte absolut einig.

Oct 23 13:33:08 ca1.ix-fra8 bfdd [11707]: BFDD_STATE_UP_TO_DOWN: BFD Session 10.50.1.2 (IFL 0) State Up -> Down LD/RD (16/16) Up time:38w6d 07:42 Local Diag: ctlExpire Remote Diag: None Reason: Detect Timer Expiry.
Oct 23 13:33:08 ca2.ix-fra8 bfdd [11793]: BFDD_TRAP_MHOP_STATE_DOWN: local discriminator: 16, new state: down, peer addr: 10.50.1.1

Nun wäre das allein noch kein allzu großes Thema gewesen, doch das Problem sitzt ja tiefer: Das Learning der MAC-Adressen funktioniert nicht mehr. Wir gehen – mit an Sicherheit grenzender Wahrscheinlichkeit – davon aus, dass deshalb auch der Fallback über das Managementnetz, über welches sich die Switches immer noch hätten erreichen können (und per Konfiguration sollen), nicht funktioniert. Das ICCP ist jedenfalls down, zeigt unser Live-Debugging wenige Minuten später, und lässt sich auch ohne Weiteres nicht mehr online bekommen – egal über welchen Link.

Durch den undefinierten Zustand (Split-Brain) fliegen alle LACP-Channels auseinander, die Konnektivität unserer Router ist auf der Stelle weg:

Oct 23 13:33:08  ca1.ix-fra8 lacpd[11741]: LACP_INTF_MUX_STATE_CHANGED: ae10: et-0/0/8:0: Lacp state changed from COLLECTING_DISTRIBUTING to DETACHED, actor port state : |-|-|-|-|OUT_OF_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|DIS|COL|IN_SYNC|AGG|SHORT|ACT|
[…]
Oct 23 13:33:08  ca1.ix-fra8 lacpd[11741]: LACP_INTF_MUX_STATE_CHANGED: ae10: et-0/0/10:3: Lacp state changed from COLLECTING_DISTRIBUTING to DETACHED, actor port state : |-|-|-|-|OUT_OF_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|DIS|COL|IN_SYNC|AGG|SHORT|ACT|

In einer solchen Split-Brain-Situation – die niemals eintreten sollte – ist das kein Fehlverhalten, sondern zu erwarten, "works as designed": Ist das ICCP weg, aber beide Switches noch up, identifizieren sich diese angeschlossenen Geräten gegenüber nicht mehr als ein gemeinsamer LACP-Partner. Technisch funktioniert das so: Im Normalzustand senden beide Switches dieselbe System-ID (sagen wir 00:00:00:00:00:10), die wir in der Konfiguration – für jeden LACP-Channel eindeutig – festgelegt haben. Die Gegenseite sieht also: Alle Ports sind sich "einig" und dürfen Teil des LACP-Channels werden – alles gut. Nun befinden wir uns aber nicht mehr im Normalzustand – und beide hören auf, die konfigurierte, gemeinsame System-ID 00:00:00:00:00:10 zu benutzen und fallen jeweils auf ihre lokale Default-System-ID zurück. Angeschlossene Geräte sehen dann zwei verschiedene LACP-Partner und nehmen nur einen davon in den LACP-Channel auf. Dessen System-ID wird auch von angeschlossenen Geräten für das jeweilige LACP übernommen. Dabei muss das logische Interface flappen – so weit, so normal. Und das können wir auch an einem dort angebundenen Router nachvollziehen:

Oct 23 13:33:10  re0-mx10003.ix-fra8 lacpd[12200]: LACP_INTF_MUX_STATE_CHANGED: ae0: et-1/1/9: Lacp state changed from WAITING to ATTACHED, actor port state : |-|-|-|-|IN_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|-|-|IN_SYNC|AGG|SHORT|ACT|
[…]
Oct 23 13:33:10  re0-mx10003.ix-fra8 lacpd[12200]: LACP_INTF_MUX_STATE_CHANGED: ae0: et-0/1/0: Lacp state changed from WAITING to ATTACHED, actor port state : |-|-|-|-|IN_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|-|-|IN_SYNC|AGG|SHORT|ACT|

Genau die Hälfte der Links (von dem noch funktionierenden Switch) kam zurück ins ae0, damit war die Split-Brain-Situation behoben.

Das erwartete Verhalten wäre nun also eigentlich gewesen, dass das Netzwerk einfach mit halber Kapazität auf einem der Switches weiterläuft. Dies hätte zwar einen Ausfall verursacht, aber eben auch zur automatischen Recovery nach wenigen Minuten geführt, da "nur" alle internen und externen BGP- und OSPF-Sessions neu hätten aufgebaut werden müssen.

Wir wissen, warum das hier nicht funktioniert hat. Dazu später mehr – weiter in der Timeline.

13:33:08 Uhr:

Unser Monitoring meldet die Nichterreichbarkeit aller Router sowohl an den Bereitschaftshabenden als auch an die Netzwerkabteilung. Die Störung wird direkt mit der angepassten Konfiguration in Verbindung gebracht, auch wenn die Ursache nicht klar ist. Vermutet (und später eben bestätigt) wird keine fehlerhafte Konfiguration, sondern ein wie auch immer gearteter Junos-Bug.

13:33:36 – 14:34:00 Uhr:

Wir spielen die letzte Konfiguration per Rollback zurück.

Oct 23 13:33:36  ca1.ix-fra8 mgd[29499]: UI_LOAD_EVENT: User 'root' is performing a 'rollback 1'
Oct 23 13:33:43  ca2.ix-fra8 mgd[7077]: UI_LOAD_EVENT: User 'root' is performing a 'rollback 1

Da alle LACP-Channel nach dem (weitgehend erwartbaren) Flap wieder hochkommen, gehen wir zunächst davon aus, dass sich das Netzwerk nun erholen sollte. Entgegen der Erwartungshaltung geschieht dies jedoch nicht, im Gegenteil: Unser Monitoring meldet nach wenigen Minuten sämtliche BGP-Sessions als down.

13:35:04 Uhr:

Wir kommunizieren die Störung über unsere Statusseite, die wir nach wie vor zu abonnieren empfehlen.

13:36 Uhr:

Wir rufen alle verfügbaren Mitarbeiter, auch aus anderen Abteilungen, in die Support-Hotline, um möglichst alle Anrufe entgegennehmen zu können. Von 16 Anrufen können wir acht annehmen. Da unsere neue Hotline detaillierte Auswertungen zulässt, können wir später feststellen, dass fast alle Anrufer nach weniger als einer Minute "aufgegeben" haben. Ob das an unseren sonst (noch) schnelleren Reaktionszeiten liegt oder diese in der Zwischenzeit unsere Statusseite gecheckt haben, können wir nicht feststellen, aber unsere Begrüßung weist auf jeden Fall auf diese hin. Jedenfalls ist nur ein einziger Anrufer am Ende auf unserer Mailbox gelandet, die wiederum direkt im Ticketsystem mündet. Diese geht ran, wenn es kein “echter Mensch” schafft, das Gespräch innerhalb von zweieinhalb Minuten anzunehmen.

13:37 Uhr:

Keine Entstörung in Sicht – wir untersuchen das Problem weiter, inzwischen mit mehreren Personen, und stellen fest, dass die (LACP-)Interfaces aller angeschlossenen Router zwar wieder up sind, aber keinerlei "echte" Kommunikation möglich ist. Simpel gesagt, aber deshalb nicht weniger wahr: Innerhalb unseres iBGP-Netzes ist exakt nichts pingbar. Kein Router, der an diese Switches angeschlossen ist, erreicht einen anderen.

13:38:15 Uhr:

Die ersten unserer BGP-Sessions am DE-CIX kommen wieder online und schaffen abermals die trügerische Hoffnung, dass sich nun alles fängt und die Sache nur einen Moment brauchte. Im ersten Moment erscheint diese Annahme sogar schlüssig, denn wir haben in unserer MC-LAG-Konfiguration eine init-delay-time von 240 Sekunden konfiguriert – die zwar eigentlich nur relevant beim Reboot eines Members sein sollte, aber man steckt ja nicht drin. Zeitlich hätte es etwa gepasst, aber machen wir uns nichts vor, so exakt haben wir das in dem Moment auch weder überprüft noch nachgerechnet.

13:43 - 13:48 Uhr:

Wir müssen einsehen, dass sich hier gar nichts fängt. Es ist zwar etwas Traffic im Netz (etwa 10% vom vorherigen Niveau), wir sehen zusätzlich neben DE-CIX einzelne private Peerings und Transitkunden wieder up, aber der Großteil recovert eben nicht. In dem Moment ist nicht klar, woran das liegt. Inzwischen wissen wir es.

Als letzten Strohhalm – und weil das alles schon sehr nach "Bug" riecht, nicht, weil es logisch wäre – löschen wir alle Interfaces, die in den Stunden zuvor neu konfiguriert worden sind, aus der Konfiguration beider Switches. Ebenso resetten wir den Port-Channel zwischen den Switches, auf dem das ICCP läuft (oder vielmehr: laufen sollte). Das logische Interface hat nach wie vor volle Kapazität (800G), keinerlei Fehler, flappt nicht – aber das ICCP bleibt down, die Geräte können sich nicht einmal pingen.

13:49 - 13:53 Uhr:

Wir müssen einsehen, dass wir so nicht weiterkommen. Zeit für einen Emergency-Reboot beider Geräte.

Wir haben für den absoluten Notfall Zugriff auf die seriellen Schnittstellen (Konsolen) aller kritischen Netzwerkgeräte, so auch auf die dieser Switches. Bevor wir den Reboot auslösen, stellen wir sicher, dass der Zugriff funktioniert. Zwar erreichen wir die Geräte wunderbar per SSH und brauchen die serielle Konsole eigentlich nur, wenn genau das nicht mehr funktioniert, aber beim Reboot so kritischer Infrastruktur nicht "blind" zu sein, ist mehr als beruhigend und kann die Downtime im Falle weiterer Fehler signifikant reduzieren.

Wie erwartet (und regelmäßig proforma getestet) funktioniert unser Konsolenzugriff.

13:53 Uhr:

Die Reboots werden ausgelöst. Exemplarisch vom zweiten Switch:

Oct 23 13:53:47  ca2.ix-fra8.net mgd[7077]: UI_CMDLINE_READ_LINE: User 'root', command 'request system reboot '
Oct 23 13:53:48  ca2.ix-fra8.net sysman[9242]: SYSTEM_REBOOT_EVENT: Reboot [system] [reboot] []


13:56 Uhr:

Die Switches kommen nacheinander wieder online, erst ca1 (weil früher neugestartet), dann ca2.

Oct 23 13:56:50 ca2.ix-fra8.net eventd[10830]: SYSTEM_OPERATIONAL: System is operational

Da beide Member frisch gebootet sind, warten sie die init-delay-time ab, ehe die (logischen) Interfaces tatsächlich hochkommen. Die ist absichtlich so konfiguriert und entspricht der Juniper-Empfehlung, um nach dem Reboot eines Members zu verhindern, dass er sich in den Dienst stellt, ehe tatsächlich alles gestartet und "warm" ist. Quälende vier Minuten vergehen, während derer aber zumindest die physischen Interfaces schon mal sauber online kommen.

14:01:09 Uhr:

Die letzten physischen und logischen Interfaces kommen wieder online. Die BGP-Sessions auf allen dataforest-Routern starten bereits wieder, der Traffic im Netz steigt schlagartig an.

14:02:22 Uhr:

Alle internen und externen BGP-Sessions sind online ("established").

14:03 Uhr:

Wir melden die Wiederherstellung der Erreichbarkeit unseres Netzwerks auf unserer Statusseite.

14:09 Uhr:

Unser Netzwerk erreicht wieder ein normales Trafficniveau.

Ursachen, ungeschönt

Zunächst mal ist klar: Die Switches brauchen ein Softwareupdate, um den Junos-Bug auszumerzen. Das letzte Update haben wir im Februar gemacht und es ist etwas bitter, dass jetzt schon das nächste ansteht, aber der Fehler ist ja nun mal aufgetreten. Bis dahin lassen wir die Finger von vergleichbaren Konfigurationsänderungen.

Wir erinnern uns, dass ein paar Ports und BGP-Sessions nach wenigen Minuten wieder hochkamen und uns kurz glauben ließen, dass die Interfaces einmal kurz geflappt sind und sich dann von alleine erholt. Die spätere Analyse brachte dann sehr schnell Licht ins Dunkel, und das Ergebnis ist alles andere als kompliziert: Alles, was wieder anlief, hing am Switch ca1, dessen l2ald – wie in der Timeline beschrieben – nicht endgültig verendet war, sondern sich wieder gefangen hatte. Vielleicht dämmert es dem einen oder anderen jetzt langsam, warum es eben nicht zu einer Wiederherstellung unseres Netzwerks mit halber Bandbreite kam.

Wir haben uns ja zuvor den Logauszug eines Routers angesehen, bei dem alles funktioniert hatte, wie es sollte, und die Split-Brain-Situation binnen zwei Sekunden behoben war. Nun, die simple Wahrheit ist: Das war Zufall. Jedes angeschlossene Gerät, jeder Router unserer Carrier, der sich für einen der beiden Switches entscheiden musste, hat diese Entscheidung zufällig getroffen. Unsere eigenen Router auch. Und bei uns ist immer alles, was redundant sein muss, an beide Switches angeschlossen. Damit fielen eben auch eine Menge Entscheidungen auf den Switch ca2, und während der zwar absolut nicht mehr in der Lage war, MAC-Adressen zu lernen und damit erst das Weiterleiten produktiven Traffics zu ermöglichen, wirkte er leider nach außen quicklebending. Kurzum: Das war ein Fall, der sich mit LACP im Allgemeinen und damit leider auch mit unserem MC-LAG im Speziellen einfach nicht mehr abfangen lässt. Denn die Ports waren ja alle da.

Unser Fehler bei der Konzeption des POPs war, einen so spezifischen Fehler nicht in Betracht gezogen zu haben. Der Defekt eines beliebigen Switches hätte keinen Ausfall verursacht. Ein Crash des Betriebssystems ebenso nicht wie viele andere Dinge. Aber – dass ein Switch keine MAC-Adressen mehr lernt, während er gleichzeitig noch fließend Ethernet und vor allem LACP spricht, war zu viel.

Unser Fehler bei der Diagnose und damit zwar nicht Ursache der Störung, aber einer Downtime, die hätte kürzer sein können, war, die Chassis-Alarme der in Frage kommenden Geräte nicht noch mal manuell zu überprüfen, weil wir uns auf das Monitoring verlassen haben. Dieses hatte funktioniert, aber der Alert wurde intern nicht weitergegeben.

Aus beiden Fehlern haben wir Konsequenzen und Lehren gezogen.

Maßnahmen- und Zeitplan:

Zwei bittere, aber notwendige Erkenntnisse gleich vorweg:

1. Unser Interxion-PoP hätte nicht wegen eines Softwarefehlers ausfallen dürfen, aber selbst wenn der Interxion-PoP ausfällt, sollte das nicht zu einem vollständigen Netzwerkausfall führen. Bisher war unser Netzwerksetup nicht darauf ausgelegt, dass der ganze PoP ausfällt. Dass das eine Schwäche im Konzept ist, ist klar und war es auch vorher schon. Wie einige von unseren Socials wissen, haben wir im Juli ein weiteres Rechenzentrum, das Equinix FR4, bezogen. Was eigentlich in Kürze feierlich(er) verkündet werden sollte, sei hier nun in wenigen Sätzen zusammengefasst: Mit diesem Rechenzentrum eröffnen wir einen weiteren dataforest-PoP, der perspektivisch volle Redundanz zu unserem PoP bei Interxion / Digital Realty bieten wird. Bisher ist Equinix noch nicht vollständig in unser Backbone integriert, dort laufen allerdings schon erste 100G-Kundenserver und unsere dafür angemieteten Glasfasern zwischen Interxion und Equinix sind auch schon live und transportieren fleißig Traffic für euch. Dass uns der PoP ausgefallen ist, bevor wir mit Equinix vollständige Redundanz bieten konnten, ist doppelt bitter, aber nicht mehr zu ändern. (Designbedingt lief im Equinix wohlgemerkt alles ausfallfrei weiter – da dort erst wenige Kundenprojekte laufen, haben wir das auf der Statusseite nicht gesondert behandelt, viel besser macht es das für 99% unserer Kunden auch nicht.)
2. Letztendlich besteht in einem solcen MC-LAG-Setup immer noch eine kleine Abhängigkeit der Geräte untereinander. Und es gibt offensichtlich Dinge, die schiefgehen können. Daher haben wir uns dazu entschieden, im Edge-Bereich keinerlei zentralen Switches mehr im MC-LAG einzusetzen. Wir werden das bestehende Setup also Stück für Stück zurückbauen und den Verbund schließlich auflösen. Ab dann werden die Geräte komplett autark laufen und in keiner Weise mehr voneinander abhängig oder miteinander verkabelt sein. Der notwendige Umbau des Fundaments unseres Edge-Netzwerks ist nicht ohne, aber die einzig logische Konsequenz. Ein bisschen vereinfacht wird das dadurch, dass wir intern schon (seit wir uns "ready for Equinix" machen) nicht mehr auf große LACP-Channels über zwei Switches angewiesen sind, sondern Loadbalancing und Redundanz mit ECMP umsetzen. Auch mit einigen Upstreams (sowohl private Peerings als auch Transits) läuft das bereits so. Aber eine ganze Stange fehlt eben noch. Dort werden wir jetzt von LACP über zwei Switches auf einzelne Ports mit je eigenen BGP-Sessions migrieren müssen, um dort ebenfalls mit ECMP arbeiten zu können. Wir geben also keine Redundanz auf – wir setzen sie nur anders um.

Diese Erkenntnisse bestimmen gleichzeitig auch die zentralen To-dos für die nächste Zeit, aber es gibt noch mehr zu tun. Im Folgenden gewähren wir einen Einblick in das, was zum Zeitpunkt dieser Veröffentlichung schon geschafft ist, und das, was wir noch vor uns haben.

Oktober 2025 (erledigt):

• Vollumfängliche Analyse und Aufklärung der Störung, um diese 100%ig zu verstehen und Maßnahmen ableiten zu können
• Inbetriebnahme notwendiger Carrier und Peerings im Equinix (zum Start: Tata, NTT, Cloudflare und Google)
• Vernetzung der Standorte Interxion und Equinix über neu angemietete Glasfasern

November 2025 (erledigt):

• Diverse Monitoring-Anpassungen:
  
  • Alerts, die kritische Switches betreffen, müssen zusätzlich zur normalen Rufbereitschaft immer direkt an die Netzwerkabteilung gemeldet werden, um eine erneute verzögerte Diagnose zu verhindern. Dies war bisher nur für unsere Router der Fall und wurde nun auf alle Core- und Aggregation-Switches an allen Standorten erweitert.
  • Unser Observium überwacht die Netzwerkgeräte per SNMP, was relativ träge ist. Daher ging der Alert des seit 13:27:45 Uhr bekannten Chassis-Alarms erst um 13:31 Uhr bei uns ein. Wir haben daher für die kritischsten Geräte, darunter die hier betroffenen, zusätzlich deren Chassis-Alarme in unser Grafana implementiert, wo sie vom junos_exporter alle 30 Sekunden über eine persistente SSH-Verbindung bezogen werden. Diese Alerts gehen ebenso an die Rufbereitschaft und die Netzwerkabteilung gleichzeitig – 24/7/365. Durch diese Verbesserungen wäre in dieser Situation bereits um 13:28 Uhr ein Alert rausgegangen, direkt an die richtigen Leute. Ob das einen Ausfall in Gänze verhindert hätte, ist Spekulation, aber im Bereich des Möglichen. In jedem Fall hätte das die Debuggingzeit und damit den Ausfall verkürzt.
• Vernetzung der Standorte firstcolo und Equinix zur Vorbereitung der PoP-Redundanz
• Ausarbeitung der Schritte, die für ein schnelles Go-live von Equinix erforderlich sind
• Proof of Concept einer zukunftsfähigen MPLS-Implementierung in unser Netzwerk, auf das alle OSPF- und iBGP-Sessions migriert werden sollen

Dezember 2025 (in Arbeit):

• Kontaktaufnahme mit allen Transit- und Peering-Partnern, um Migration von LACP auf ECMP vorzubereiten
• Migration restlicher interner Links von LACP auf ECMP, um das MC-LAG auflösen zu können
• Umsetzung einer einheitlichen ECMP-Loadbalancing-Policy innerhalb unseres Netzwerks
• Vorbereitung aller Router und Switches im Edge-Netzwerk auf MPLS. Im Wesentlichen ist das eine MTU-Anpassung auf allen involvierten Interfaces. Aber da das mit einem Flap einhergeht, müssen wir vor Umstellung eines Interfaces den Traffic sauber runter migrieren, die Umstellung machen, und zurück migrieren, um (multiple) Ausfälle in Teilbereichen unseres Netzwerks zu vermeiden. Das haben wir uns in der dataforest-DNA als "Zero-Downtime-Prinzip" auf die Fahne geschrieben, und wir finden, dass der Nutzen den Mehraufwand rechtfertigt, solange es praktikabel ist.

Januar 2026 (geplant):

• Migration aller Transits und Peerings auf ECMP, um MC-LAG auflösen zu können
• Vernetzung der Standorte maincubes und Equinix zur Vorbereitung der PoP-Redundanz
• Migration aller OSPF- und iBGP-Sessions auf die neue MPLS-Umgebung
• Vollständiges GoLive des neuen POPs durch Herstellung der vollen Redundanz

Februar 2026 (geplant):

• Auflösen des MC-LAGs
• Vollständiger Switchover auf Equinix-PoP, um am Interxion-PoP verschiedene notwendige Wartungsarbeiten ausfallfrei und gefahrlos durchführen zu können. Dazu gehört natürlich auch das Einspielen des Softwareupdates, das den Bug behebt, der den Ausfall verursacht hat.
• Konfiguration von sogenanntem BGP RIB Sharding (BRS) auf allen Routern, um BGP-Konvergenzzeiten zu verbessern. Das ermöglicht eine schnellere vollständige Wiederherstellung der Erreichbarkeit nach Ausfall eines Routers, egal ob der von uns oder einem Upstream ist. Hierzu sind möglicherweise noch Softwareupdates notwendig, die wir rechtzeitig ankündigen.

Verantwortung, Schuld und eine Bitte

Wir sind sehr dankbar, von vielen Kunden dahingehend aufmunterndes Feedback bekommen zu haben, dass wir an diesem Bug ja nicht schuld seien. Das ehrt euch, und es stimmt, wir sind nicht schuld an dem Bug. Nun habt ihr als unsere Kunden aber keinen Vertrag mit Juniper Networks, sondern mit uns. Und es wird unserem eigenen Anspruch nicht gerecht, wenn unser Netzwerk – warum auch immer – quasi vollständig ausfällt. Wir möchten hier klar zwischen Schuld und Verantwortung unterscheiden, und die Verantwortung für das "Endprodukt" tragen wir. Daher verbuchen wir das nicht einfach unter "shit happens", updaten die Software, und machen weiter wie bisher, sondern überlegen uns, was wir ganz konkret hätten tun müssen, um so eine Art von Fehler korrekt abzufangen. In diesem Fall ist ein ganzer Sack an Maßnahmen herausgefallen.

Natürlich haben wir auch kritische Nachrichten bekommen, eine ganze Menge sogar. Und wir verstehen, dass so ein Ausfall immer schlecht ist. Trotzdem müssen wir hier einmal im Angesicht verschiedener Vorwürfe die Gelegenheit nutzen, klarzustellen, was man von uns erwarten kann – und was nicht:

Unser Netzwerk ist ausgelegt auf eine Verfügbarkeit von 99,99% – das ist unser Anspruch. Und dem sind wir offen gestanden nicht gerecht geworden, denn Ende November letzten Jahres gab es schon mal ein Problem durch einen großangelegten Netzwerkangriff und unterm Strich sind wir durch diese zwei Vorfälle bei ärgerlichen 99,98% gelandet. Vertraglich schulden wir den meisten unserer Kunden "nur" 99,9% im Jahresmittel, wobei sich das bei den meisten Produkten natürlich aus mehr Aspekten als nur der Netzwerkverfügbarkeit ergibt. Und ja: Jeder darf wesentlich mehr als 99,9% Netzwerkverfügbarkeit von uns erwarten. Wir tun alles Realistische dafür, in Richtung 100% zu kommen, aber wir können nicht versprechen, dass es nie wieder zu einer Störung kommt. Und daher tun wir das auch nicht. Was wir versprechen können, ist, dass wir Probleme wie dieses angemessen aufarbeiten. Dass wir kommunizieren, was passiert ist, und Verbesserungen ableiten, damit sich genau derselbe Fehler nicht wiederholt. Dennoch: Wer (nahezu) 100% Uptime braucht, muss das selbst in die Hand nehmen und darf nicht von einem einzelnen Provider abhängig sein. Es gibt nach bestem Wissen und Gewissen auf diesem Planeten noch kein Webhostingunternehmen mit 100% Verfügbarkeit. Wenn uns (wenige) Einzelne also vorwerfen, so eine Netzwerkstörung koste sie Zehntausende Euro, wollen wir das klar eingeordnet wissen: Dann liegt der Fehler nicht bei uns. Wir kennen die Branche nun über 15 Jahre und können selbstbewusst sagen, dass wir uns für unsere Kunden wirklich reinhängen und die Extrameile gehen. Nicht nur in Bezug auf die Verfügbarkeit, sondern beispielsweise auch gemessen an Reaktionszeiten bei Störungen, die 24/7/365 normalerweise im Sekundenbereich liegen. Wir ärgern uns wahrscheinlich selbst am meisten, wenn derartige Störungen trotz aller Vorsichtsmaßnahmen auftreten, aber wir können sie nicht 100%ig verhindern.

Ebenso eingehen wollen wir auf die "Forderung" mancher Kunden, jegliche Commits auf unseren Netzwerkgeräten nur noch nachts durchzuführen. Vorab: Unsere Meldung auf der Statusseite (“major outage when we committed a regular change in our edge network”) war nicht gut. Sie hat zu Missverständnissen geführt; konkret zur Annahme, wir hätten irgendeinen risikoreichen Major Change mitten am Tag deployed. Das tun wir grundsätzlich nicht: Wenn wir irgendwo ein Risiko sehen (also: absehen können, dass theoretisch etwas passieren könnte), kündigen wir entsprechende Wartungsarbeiten auf unserer Statusseite an. Aber wenn wir nach bestem Wissen und Gewissen null Impact erwarten, tun wir das nicht. Commits auf unseren Routern und Switches sind nichts Außergewöhnliches, sie finden täglich dutzendfach statt. Zur Auslieferung neuer Server, IP-Netze, BGP-Sessions und so weiter. Es gibt durchaus noch ein Mittelding, und dazu gehören viele Commits im Edge-Netzwerk, bei denen wir sagen "kann nichts passieren, aber der Commit hat Zeit und wir machen es daher lieber spät". Auch das passiert mehrfach pro Woche – störungsfrei, sonst würden wir das nicht machen.

Um unser Netzwerk auf die Integration des Equinix-POPs vorzubereiten, haben wir in den letzten Wochen Linecards geupgradet, mehrere Darkfibers und neue Upstreams in Betrieb genommen, Traffic auf diese migriert, andere Strecken zu Wartungszwecken abgeschaltet, und für die (modernisierte) Vernetzung unserer Standorte und Router angefangen MPLS zu implementieren. Nichts davon hat irgendwelche Probleme gemacht und genau das war bei dem hier schuldigen Commit auch unsere Annahme. Leider passieren die blödesten Dinge da, wo man sie am wenigsten erwartet. Und das während unsere angekündigten Wartungen zu 99% derart entspannt und nach Plan laufen, dass wir uns manchmal schon sorgen, mit Wartungsankündigungen unnötige "Overcommunication" zu betreiben.

Schlussendlich darf man auch nicht vergessen: Wir bedienen inzwischen Kunden in aller Welt – was des einen Nachtruhe ist, ist des anderen Primetime. Netzwerkstörungen sind also immer sehr ungünstig und daher auch immer zu vermeiden, und wenn uns das nicht gelingt, entsprechend aufzuarbeiten. So wie hier. Wir werden nicht aufhören, aus unseren Fehlern zu lernen und diese dadurch zu minimieren, aber wir wollen damit keine unrealistischen Hoffnungen auf 100% Uptime wecken. Mit einem kleinen Augenzwinkern: Auch die größten Cloud- und CDN-Anbieter der Welt gehen gerade in den letzten Wochen absolut nicht ausfallfrei durchs Leben – und das ist genauso in Ordnung.