Zusammenfassung

  • Die Unterbrechung im Oktober 2021 folgte auf geplante Anti-DDoS-Wartung, doch die Quellen führen den Ausfall selbst nicht auf einen DDoS-Angriff zurück; die Bedrohung motivierte den Change, war aber nicht dessen dokumentierte operative Ursache.
  • Laut OVHcloud ließ ein Befehl zur Umverteilung von BGP nach OSPF die vollständige Internet-Routingtabelle in das IGP gelangen, füllte die OSPF-Tabelle, belastete Arbeitsspeicher und Prozessor und machte IPv4-Routing unbrauchbar, während IPv6 erreichbar blieb.
  • Formale Freigaben existierten: OVHcloud nannte CAB, MOP und Peer Review. Verantwortlichkeit betrifft daher semantische Validierung, Begrenzung des Schadensradius, Beobachtung des laufenden Zustands und einen wirksamen Rückweg, nicht die Behauptung, der Change sei ungeprüft gewesen.
  • Die Wiederherstellung verlief gestuft: Das Konfigurationsproblem trat gegen 09:20 Uhr MEZ auf, der fehlerhafte Router wurde um 10:18 Uhr abgeschaltet, erste Dienste kehrten um 10:20 Uhr zurück, und das technische Krisenende wurde um 10:57 Uhr vermerkt.
  • Belegt ist ein Routing- und Erreichbarkeitsfehler mit breiter Wirkung. Nicht belegt sind eine exakte Zahl betroffener Kunden oder Dienste, Datenverlust, Feuer oder physische Zerstörung, eine vollständige Schadenssumme oder Copy-and-paste als abschließend erwiesene Ursache.

Sicherheitsmotiv und Ausfallursache sind nicht dasselbe

Am 13. Oktober 2021 begann OVHcloud mit geplanten Arbeiten an seiner produktiven Routing-Infrastruktur. Das erklärte Ziel war, den Anti-DDoS-Schutz in einer Phase intensiverer Angriffe zu verstärken. Diese Lage erklärt, warum das Unternehmen den Change durchführte. Sie ändert aber nicht die veröffentlichte Kausalkette: ein Konfigurationsbefehl, eine Umverteilung zwischen Routingprotokollen, eine unbeherrschte Vergrößerung des Routingzustands, Ressourcenüberlastung sowie gescheiterte Konvergenz und Rücknahme.

Diese Trennung ist für Verantwortlichkeit entscheidend. Würde jeder Ausfall während sicherheitsmotivierter Wartung dem äußeren Angreifer zugerechnet, verschwänden die internen Entscheidungen aus dem Blick, die den Schadensradius bestimmt haben. Die Quellen beschreiben für den Zeitpunkt der Unterbrechung keinen DDoS, der das Netz überlastete. Sie beschreiben eine Schutzmaßnahme, die im Inneren des Netzes einen nicht beabsichtigten Kontrollzustand erzeugte.

Auch das Wort Wartung macht den Eingriff nicht routinemäßig. Eine Änderung an der Grenze, an der Routen zwischen BGP und OSPF umverteilt werden, verbindet die externe Sicht auf Internetpfade mit dem internen Zustand der Erreichbarkeit. Ein Fehler an dieser Grenze bleibt nicht zwingend auf eine Konfigurationszeile beschränkt. Er kann sehr viele Routen in einen internen Bereich tragen, der dafür nicht ausgelegt ist, weitere Router zur Verarbeitung von Aktualisierungen zwingen und genau die Ressourcen verbrauchen, die zur Korrektur benötigt werden.

Wie Routingzustand die Kontrollebene überforderte

OVHcloud zufolge interpretierte ein Router einen Befehl nicht richtig. Dieser Befehl betraf die Umverteilung von BGP nach OSPF. In der Folge wurde die gesamte Internet-Routingtabelle in das interne Gateway-Protokoll des Unternehmens angekündigt. Die OSPF-Tabelle füllte sich, Arbeitsspeicher und Prozessor des Routers wurden überlastet, und eine Konvergenzschleife zwischen BGP und OSPF machte IPv4-Routing unbrauchbar.

Die Mechanik ist deshalb gefährlich, weil die beiden Protokolle unterschiedliche Aufgaben erfüllen. BGP trägt typischerweise eine große Sicht auf Pfade und Richtlinien zwischen autonomen Systemen. OSPF verteilt interne Topologie- und Erreichbarkeitsinformationen innerhalb einer Routingdomäne. Eine breite, unbegrenzte Übernahme von BGP-Routen in OSPF fügt nicht bloß Daten hinzu. Sie verändert die Menge an Zustand, die interne Geräte verbreiten, speichern und neu berechnen müssen.

Die Quellen nennen weder die genaue Routenzahl noch Gerätemodell, Softwarestand, Hersteller oder exakten Befehl. Daher wäre es unzulässig, einen bestimmten Anbieterfehler oder eine konkrete Parser-Eigenschaft als erwiesen darzustellen. Der gesicherte Kern ist enger und zugleich ausreichend: Der erzeugte Routingzustand überschritt die tragfähigen Grenzen, und die für Verarbeitung und Korrektur benötigten Ressourcen gerieten unter Druck.

Deshalb genügt eine Syntaxprüfung nicht. Ein Befehl kann formal gültig sein und exakt im MOP stehen, aber eine völlig andere Routemenge erzeugen als erwartet. Die stärkere Kontrolle prüft die Wirkung: Welche Präfixe dürfen die Grenze überqueren? Welche Adressfamilien sind zugelassen? Welche Filter und Attribute greifen? Welche Nachbarn erhalten die Information? Welcher unabhängige Grenzwert stoppt den Vorgang, bevor die OSPF-Datenbank anwächst?

Vorhandene Freigaben verhinderten den laufenden Zustand nicht

OVHcloud erklärte, der Change sei mit einem Change Advisory Board, einer Method of Procedure und einer Prüfung durch Kollegen vorbereitet worden. Diese Aussage darf nicht in ihr Gegenteil verkehrt werden. Die Quellen stützen weder die Behauptung eines völlig ungeplanten Eingriffs noch die eines allein handelnden Technikers ohne Prüfung. Zugleich verhinderten die genannten Kontrollen nicht, dass die Internettabelle in das IGP gelangte, und sie stellten keinen wirksamen Software-Rollback sicher.

Eine belastbare Prüfung hat mindestens vier getrennte Gegenstände. Erstens die Absicht: Welcher Sicherheits- oder Resilienznutzen wird verfolgt? Zweitens die Konfigurationssemantik: Welchen Zustand erzeugt jeder Befehl auf dem betroffenen Gerät und Softwarestand? Drittens die Ausbreitung: Welche Router und Protokolle empfangen oder verstärken diesen Zustand? Viertens die Wiederherstellung: Was bleibt verfügbar, wenn CPU, Speicher, Managementzugang oder Routingprozess des geänderten Geräts beeinträchtigt sind?

Eine Prüfung kann die Absicht richtig bewerten und dennoch die reale Wirkung verfehlen. Ein Kollege kann bestätigen, dass der Befehl der schriftlichen Anleitung entspricht, obwohl weder Anleitung noch Befehl eine entscheidende Begrenzung enthalten. Ein Change Board kann Geschäftsrisiken bewerten, ohne eine maschinell erzeugte Vorschau der resultierenden Routemenge zu sehen. Und ein dokumentierter Rollback-Befehl beweist noch nicht, dass er bei hoher Routenzahl und knappen Prozessorressourcen nutzbar ist.

Die Konsequenz ist nicht weniger menschliche Prüfung, sondern eine überprüfbare Prüfung. Vor der Ausführung sollten maximale Routenzahländerung, erlaubte Präfixfamilien, erwartete CPU- und Speicherbereiche, zulässiges Wachstum der OSPF-Datenbank und die erwartete externe Erreichbarkeit feststehen. Während der Ausführung muss eine Abweichung den nächsten Schritt stoppen. Eine Freigabe bleibt vorläufig, bis die beobachtete Route- und Dienstlage mit der Prognose übereinstimmt.

Eine Zeitleiste mit mehreren Wiederherstellungspunkten

Der detaillierte Bericht setzt den Beginn des geplanten Changes auf 09:05 Uhr MEZ. Um 09:18 Uhr erfolgten BGP-Isolierung und Konfigurationsarbeiten. Gegen 09:20 Uhr trat das Netzkonfigurationsproblem auf; um 09:21 Uhr wurde das Leistungsproblem des Routers erkannt und eskaliert. Bis 09:30 Uhr war der Rollback gescheitert, und die physische Isolation wurde als nächster Schritt gewählt.

Um 10:18 Uhr wurde der betroffene Router abgeschaltet. Zwei Minuten später, um 10:20 Uhr, kehrten nach der Netzkonvergenz erste Dienste zurück. OVHcloud markierte das Ende der technischen Krise um 10:57 Uhr. Eine frühere Mitteilung desselben Tages verwendete gröbere Zeitangaben von 09:12 Uhr für den Eingriff und 10:15 Uhr für die Isolation. Für die präzise Rekonstruktion ist die spätere detaillierte Zeitleiste maßgeblich; die frühe Fassung zeigt lediglich, wie sich die Kommunikation während des Ereignisses entwickelte.

Aus diesen Punkten sollte keine einzige undifferenzierte Ausfalldauer werden. IPv4-Erreichbarkeit versagte ungefähr ab 09:20 Uhr. Erste Dienste kamen um 10:20 Uhr zurück, aber die technische Stabilisierung dauerte bis 10:57 Uhr. „Eine Stunde Ausfall“ bezeichnet somit höchstens den Zeitraum bis zur ersten Rückkehr. „Ausfall bis 10:57 Uhr“ könnte dagegen fälschlich bedeuten, alle Dienste seien bis dahin vollständig unerreichbar geblieben.

Die Unterscheidung zwischen Eindämmung, erster Wiederherstellung und endgültiger Stabilisierung ist operativ relevant. Kunden und Einsatzleitung müssen wissen, ob der fehlerhafte Zustand entfernt ist, ob Routingnachbarschaften stabil sind, ob externe Dienstprüfungen erfolgreich sind und ob Status- und Supportkanäle funktionieren. Jeder Meilenstein verlangt einen eigenen Beleg.

IPv4 fiel aus, IPv6 blieb erreichbar

Der veröffentlichte Befund enthält eine wichtige Protokollgrenze. IPv4-Routing wurde unbrauchbar, während IPv6 erreichbar blieb. Daraus folgt weder, dass jeder IPv6-abhängige Dienst vollständig funktionierte, noch dass alle IPv4-Pfade identisch ausfielen. Es folgt aber, dass die Konnektivität nicht in jeder Adressfamilie gleichermaßen verschwand.

Eine nicht betroffene Adressfamilie kann einen Weg für Beobachtung, Management oder Statuskommunikation erhalten. Ob dieser Vorteil praktisch nutzbar ist, hängt von den Abhängigkeiten ab. Eine Anwendung kann am Rand IPv6 sprechen und dennoch ein IPv4-only-Backend benötigen. Ein Managementwerkzeug kann auf Netzebene erreichbar sein, aber an DNS, Identität oder einer weiteren nicht verfügbaren Komponente scheitern. Deshalb muss ein Betreiber vollständige Funktionen testen und nicht nur die Antwort einer Adresse.

Unabhängige Berichte beobachteten nicht erreichbare Kundenserver und Websites sowie Fehler auf OVHclouds eigener öffentlicher Website und bei der Statusseite. Das ist eine Warnung für die Kontinuität der Krisenkommunikation: Die Systeme, die einen Ausfall erklären sollen, können denselben Pfaden und Abhängigkeiten unterliegen wie die betroffene Produktion. Ein Anbieter muss deshalb vorab wissen, welcher Kommunikationskanal über eine unabhängige Infrastruktur und gegebenenfalls über die nicht betroffene Adressfamilie funktioniert.

Die IPv4/IPv6-Grenze begrenzt zugleich die zulässigen Schadensaussagen. Sie stützt ein Routing- und Erreichbarkeitsversagen, nicht die Zerstörung von Servern, den Verlust von Kundendaten oder einen physischen Rechenzentrumsvorfall. Ein Nutzer erlebt einen unerreichbaren Dienst möglicherweise ähnlich wie einen zerstörten Dienst. Für technische und rechtliche Verantwortlichkeit handelt es sich jedoch um grundverschiedene Befunde.

Breite Wirkung ohne erfundene Gesamtzahl

OVHcloud beschrieb Störungen im gesamten Netz und die Unfähigkeit, IPv4-Datenverkehr für die eigenen Websites korrekt zu verarbeiten. Unabhängige Medien sahen Kundenserver und -seiten unerreichbar werden, die öffentliche Seite des Unternehmens Fehler liefern und Statusinformationen ausfallen. Numerama sprach von Tausenden betroffenen Websites und nannte französische öffentliche sowie kommerzielle Beispiele.

Diese Beobachtungen belegen einen materiellen und breiten Erreichbarkeitseffekt. Sie sind aber keine geprüfte Vollerhebung. Die Quellen liefern keine abschließende Zahl betroffener Kunden, Dienste, Router, Länder, Transaktionen oder Umsätze. Benannte Websites sind Beispiele für Abhängigkeiten, nicht der gesamte Schadensradius. „Tausende“ ist eine zugeschriebene Größenbeschreibung und kein abgeglichener Kundenbestand.

Ebenso wenig belegt der Bericht Datenverlust, zerstörte Server, Feuer oder einen physischen Standortausfall. Der Oktober-Vorfall muss ausdrücklich vom Brand im Straßburger Rechenzentrum im März 2021 getrennt bleiben. Bilder oder Schadensbehauptungen aus diesem Ereignis würden aus einem Routingfehler eine andere Geschichte machen und die Kontrolle aus dem Blick nehmen, die hier tatsächlich versagte.

Ein Anbieter benötigt mehrere Beweisschichten, um Wirkung sauber zu bestimmen. Routentelemetrie kann Rücknahmen und Instabilität zeigen. Externe Probes zeigen Erreichbarkeit. Supportsysteme zeigen Kundenmeldungen. Dienst-, Abhängigkeits- und Abrechnungsdaten helfen, die Exposition einzuordnen. Keine Schicht liefert allein eine vollständige Zahl. Ein reifer Bericht erklärt, wie diese Signale zusammengeführt wurden und wo Unsicherheit verbleibt.

Der Rollback war vorgesehen, die Isolation brachte Kontrolle zurück

Der versuchte Software-Rollback scheiterte. Der öffentliche Bericht lässt offen, ob Ressourcenüberlastung, Befehlsverhalten, Zugriffsprobleme, Konvergenzdynamik oder ein anderer nicht veröffentlichter Faktor dafür verantwortlich war. Eine genaue Erklärung wäre Spekulation. Belegt ist, dass die vorgesehene logische Rücknahme den Betriebszustand nicht wiederherstellte und das Team deshalb zur physischen Isolation überging.

Um 10:18 Uhr wurde der fehlerhafte Router abgeschaltet; um 10:20 Uhr begannen erste Dienste während der erneuten Konvergenz zurückzukehren. Die zeitliche Nähe beweist nicht jedes verborgene Detail, verbindet in der Betreiberzeitleiste aber die Entfernung des Routers mit dem Beginn der Wiederherstellung. Der Rettungsweg bestand darin, einen Teilnehmer auszuschließen, dessen Zustand im laufenden Betrieb nicht sicher korrigiert werden konnte.

Daraus folgt eine konkrete Kontrollanforderung. Kritische Routing-Changes brauchen einen Isolationsweg, der nicht vom Zustand der betroffenen Kontrollebene abhängt. Dazu können Out-of-band-Management, fernsteuerbare Stromversorgung, unabhängiger Konsolenzugang, vorab autorisierte Abschaltung von Peers oder ein Vor-Ort-Eingriff gehören. Welche Kombination angemessen ist, hängt von Topologie und Risiko ab. Sie muss aber funktionieren, wenn normales Routing, CPU, Speicher oder Managementzugang bereits beeinträchtigt sind.

Isolation braucht zudem ein vorher geprüftes Folgenmodell. Das Entfernen eines Routers kann fehlerhaften Zustand beseitigen, aber auch Kapazität oder Verbindungen entziehen. Betreiber müssen wissen, welche Nachbarn neu konvergieren, wie viel Reserve verbleibt, ob Route Reflectors oder IGP-Nachbarn weitere Unruhe verstärken und welche Dienste vorübergehend geopfert werden. Eindämmung darf nicht erst im Krisenmoment entworfen werden.

Rollback und Wiederherstellung sind verschiedene Behauptungen. Eine Konfiguration kann auf einen früheren Stand zurückkehren, während alte Routen, überlastete Prozesse oder Konvergenz fortbestehen. Umgekehrt kann die Isolation den Dienst zurückbringen, ohne zu erklären, warum der ursprüngliche Rollback scheiterte. Nachzuweisen sind daher getrennt: Befehlsausführung, Rückgang der Routenzahl, stabile Nachbarschaften, Ende-zu-Ende-Erreichbarkeit und abschließende technische Stabilität.

Was der Befund offenlässt

Die Quellen nennen weder Gerätemodell und Softwareversion noch Hersteller, exakten Befehl, Parser-Verhalten, genaue Routenzahl oder vollständige Topologie. Sie weisen keinem einzelnen Techniker Entscheidungsverantwortung zu und belegen nicht, was eine bestimmte Person zu einem bestimmten Zeitpunkt wusste. Eine Behauptung über individuelles Fehlverhalten oder einen bestimmten Produktdefekt wäre daher nicht fair belegt.

Ein Teil der Berichterstattung erwähnte einen später gelöschten Beitrag der Unternehmensleitung und brachte einen Copy-and-paste-Fehler ins Spiel. Der spätere ausführliche OVHcloud-Bericht bestätigt dies nicht als endgültige Ursache. Belastbar ist die Aussage, dass ein Router einen Befehl nicht richtig interpretierte und die daraus folgende Umverteilung den Routingausfall erzeugte. Jede weitere Präzisierung muss zugeschrieben und vorläufig bleiben.

Der Befund belegt auch keinen Kundendatenverlust, keine physische Zerstörung, keinen Brand, keine vollständige wirtschaftliche Schadenssumme und keine exakte Zahl betroffener Kunden. Er zeigt nicht, dass ein DDoS den Ausfall verursachte, und er zeigt nicht, dass CAB, MOP oder Peer Review fehlten.

Diese Grenzen schwächen die Schlussfolgerung nicht. Sie machen sie genauer. Ein geplanter, geprüfter und sicherheitsmotivierter Change erzeugte einen Kontrollzustand, der Routingressourcen überforderte, IPv4-Erreichbarkeit störte, dem Software-Rollback widerstand und physische Isolation erforderte. Eine verantwortliche Antwort muss deshalb semantische Routenvalidierung, durchgesetzte Grenzen, unabhängigen Managementzugang, wirksame Stopprechte und dienstbasierte Wiederherstellungsbelege zeigen.

Quellen