Am 20. Mai 2025 um 7 Uhr UTC ereignete sich eine Störung, die die Stabilität des globalen Internets deutlich beeinflusste. Ein bestimmtes Border Gateway Protocol (BGP) Update wurde verbreitet, das eine Kettenreaktion unerwarteter und unerwünschter Reaktionen bei verschiedenen, weit verbreiteten BGP-Implementierungen auslöste. Die Folge war ein massiver Ausfall einer Vielzahl an internetseitigen BGP-Sitzungen, der in manchen Fällen zu kurzzeitigen Verbindungsverlusten führte, in anderen Fällen jedoch für ein allgemeines Routing-Chaos sorgte. Die Tragweite dieser Störung verdeutlicht einmal mehr, wie empfindlich das Rückgrat des Internets auf unvorhergesehene Softwarefehler reagieren kann.
Das Border Gateway Protocol ist die Grundlage der Funktionsweise des Internets. Es regelt den Informationsaustausch zwischen autonomen Systemen (AS), also eigenständigen Netzwerken, damit Daten auf dem effizientesten Weg leiten werden können. Ein Fehler im BGP-Handling ist daher potenziell folgenschwer, da er Veränderungen in den Routing-Tabellen erzwingt und damit Einfluss auf die erreichbaren Netzwerke hat. Im vorliegenden Vorfall stand eine besondere Variante eines BGP-Updates mit der sogenannten BGP Prefix-SID-Attribut im Mittelpunkt. Dieses Attribut wird gemäß RFC8669 hauptsächlich zur Steuerung interner Routingpfade eingesetzt und ist in der Regel nicht in der globalen Internet-Routing-Tabelle zu finden.
Wesentlich problematisch war nicht nur das Auftauchen dieses Attributes im Internet-Routing, sondern auch dessen fehlerhafte und korruptierte Form, bei der alle enthaltenen Daten auf Null gesetzt waren. Während viele Betriebssysteme wie Cisco IOS-XR und Nokia SR-OS korrekte Filtermechanismen aktiviert hatten, die solche fehlerhaften Updates unterbinden, führte die spezielle Kombination aus Juniper Networks JunOS und Arista EOS zu ungewollten Auswirkungen. JunOS trug die fehlerhaften Nachrichten weiter, ohne sie zu blockieren, während Arista EOS daraufhin mehrere BGP-Sitzungen zurücksetzte. Da viele Transit-Provider Juniper-Hardware verwenden, führte dies zu einer dominanten Verbreitung des Problems. Kunden von Arista EOS, die mit transitierenden JunOS-basierten Routern verbunden sind, erlebten dadurch Verbindungsabbrüche, die je nach Netzwerkumgebung bis zu zehn Minuten andauern konnten.
Ein weiterer Verstärker war die Rolle von Hutchison Global Communications Limited (AS9304), die über eine starke Präsenz an vielen Internet Exchange Points (IXPs) verfügt. Die fehlerhaften Updates wurden dort über sogenannte IXP-Router verteilt, die oft den Routing-Daemon Bird verwenden. Bird fehlte die Fähigkeit, mit BGP Prefix-SID Attributen umzugehen, sodass dieser Fehler ohne Filterung weiterverbreitet und die Instabilität somit erheblich verstärkt wurde. Die Entdeckung der beteiligten autonomen Systeme zeigt, dass mehrere AS als Quelle der problematischen Routenupdates in Betracht kommen. Signifikant sind hierbei Starcloud Information Limited (AS135338) und Hutchison Global Communications (AS9304), die vermutlich das fragliche Attribut in das Routing eingeführt haben.
Bemerkenswert ist, dass einige der betroffenen Präfixe, darunter 156.230.0.0/16 und verschiedene aus dem Bereich 163.171.
x.x, von diesen AS nicht direkt verwaltet werden, was darauf hinweist, dass die Attribute wahrscheinlich von Transitnetzwerken und nicht von den ursprünglichen Ursprung-AS gesetzt wurden. Diese Fälle demonstrieren eine Gefahr, die entsteht, wenn interne BGPattribute ungewollt in das globale Routing gelangen. In den meisten Netzwerken werden interne Sessionings vom externen (eBGP) Segment getrennt. Eine mögliche Ursache für das Leck war eine falsch konfigurierte externe BGP-Verbindung, die fälschlicherweise als interne (iBGP) behandelt wurde, was zur Weitergabe interner Attribute führte.
Die Auswirkungen waren erheblich und weltweit spürbar. Anhand von Datenanalyse der BGP-Routenänderungen zeigte sich ein ungewöhnlich hoher Routingwechsel, insbesondere bei rund 100 Netzwerken. Darunter finden sich namhafte Unternehmen und Netzwerkanbieter wie SpaceX Starlink, Zscaler, Bytedance, Disney Worldwide Services oder auch verschiedene regionale Provider. Die Analyse der Datenmenge während dieses Zeitraums zeigt eine drastische Zunahme der Routingänderungen von üblichen 20.000 bis 30.
000 Updates pro Sekunde auf gut 150.000 Nachrichten pro Sekunde innerhalb eines kurzen Zeitfensters. Ein klares Indiz für eine starke Verwirrung im Internet-Routing. Diese Situation stellte nicht nur die technische Infrastruktur, sondern auch die Netzbetreiber vor große Herausforderungen. Die Tatsache, dass die Probleme durch Fehler in der Fehlerbehandlung verschiedener Hersteller verstärkt wurden, zeigt den dringenden Bedarf an robusteren Protokoll-Implementierungen.
Juniper selbst dokumentiert, dass das BGP-Error-Tolerance-Verhalten von JunOS nicht auf alle Teile einer BGP-Nachricht prüft, obwohl die Software durchaus in der Lage wäre, das defekte Attribut als fehlerhaft zu erkennen. Stattdessen wird das fehlerhafte Update weitergereicht, um einen eigenen Sitzungsabbruch zu vermeiden – auf Kosten der Stabilität anderer Netze. Auch Arista EOS zeigte Schwächen und resetete Sitzungen, anstatt den fehlerhaften Update elegant zu verwerfen. Andere Systeme wie IOS-XR und Nokia SR-OS agierten hier deutlich resilienter. Dieser Vorfall verdeutlicht die enormen Risiken, die ein einzelner falsch formulierter BGP-Update erreichen kann, wenn sich unzureichende Fehlerprüfungen mit weit verbreiteten Implementierungen kombinieren.
Darüber hinaus unterstreicht der Vorfall die kritische Bedeutung von Internet Exchange Points (IXPs) im Routing-Ökosystem. Durch die Verbreitung fehlerhafter Updates an IXPs können Störungen exponentiell wachsen, denn viele Netzwerke sind hier eng miteinander verbunden. Die Rolle von Bird als weiterverteilender Route-Server ohne Unterstützung für BGP Prefix-SID auf mehreren großen IXPs führte dazu, dass der Schaden außerordentlich schnell und umfassend wurde. In der Auswertung und im Monitoring des Internets wird zunehmend deutlich, wie wichtig ein umfassendes und koordiniertes Fehlermanagement ist. Betreiber sollten nicht nur auf ihre eigenen Systeme und Implementierungen achten, sondern auch auf die Handhabung von Fehlern bei ihren Peers und Transitprovidern.
Diese Vernetzung erzeugt eine Verantwortung, die über den eigenen Netzwerkbereich hinausreicht. Das Thema BGP und seine Einführung als Grundlage für das globale Internet bleibt hochkomplex und dynamisch. Der Vorfall im Mai 2025 zeigt dabei auch das stetige Risiko von Fehlern, die beinahe unbemerkt entstehen und dramatische Auswirkungen haben können. Gleichzeitig wird klar, dass abgestimmte Verbesserungen etwa in der Behandlung von ungültigen oder unerwarteten Attributen die Stabilität merklich verbessern könnten. Die Ereignisse mahnen Anbieter und Betreiber, den Fokus auf die Implementierung von RFC7606, der BGP Error-Toleranz spezifiziert, zu intensivieren.
Auch sollte über die Einführung und Verbreitung zusätzlicher Monitoring- und Filtermechanismen nachgedacht werden, die derartige Attribut-Ausreißer frühzeitig erkennen und eliminieren. Eine stärkere Zusammenarbeit zwischen Hardware-Herstellern, Netzbetreibern und Forschern könnte helfen, proaktiv auf solche Vorfälle zu reagieren und die Widerstandsfähigkeit des Internets zu erhöhen. Angesichts der zunehmenden Digitalisierung und der steigenden Zahl kritischer Dienste, die auf IP-basierte Kommunikation angewiesen sind, sind die Risiken von Internet-Ausfällen nicht nur ein technisches Problem. Die Auswirkungen können sich unmittelbar auf gesellschaftliche Bereiche ausweiten, von Notfalldiensten über Medienversorgung bis hin zu globalen Wirtschaftsströmen. Für alle, die eigene Netzwerke betreiben, bietet sich die Möglichkeit, durch die Teilnahme an öffentlich zugänglichen Routing-Datenkollektiven wie bgp.
