Zusammenfassung

  • OVHcloud begann nach eigenen Angaben am 13. Oktober 2021 um 09:05 UTC mit Wartungsarbeiten an einem Backbone-Router in Vint Hill im US-Bundesstaat Virginia.
  • Um 09:20 UTC gelangte laut dem öffentlichen Vorfallsbericht infolge eines Problems bei der Interpretation eines Befehls die vollständige Internet-Routingtabelle aus BGP in OSPF.
  • BGP und OSPF bilden unterschiedliche Routing-Domänen mit verschiedenen Annahmen über Richtlinien, Zustandsmengen, Verteilung und Konvergenz.
  • Eine Redistribution zwischen diesen Domänen ist ein privilegierter Zustandsübergang. Richtung, zulässige Routenmenge, Kardinalität und Ausbreitungsbereich müssen vor der Aktivierung technisch begrenzt sein.
  • Die OSPF-Instabilität führte laut OVHcloud zu CPU- und Speicherbelastung im Backbone, zu globalen IPv4-Störungen und zugleich zu fortbestehender IPv6-Erreichbarkeit.
  • Der gescheiterte Fern-Rollback machte die physische Trennung und das Ausschalten des Routers zur wirksamen Wiederherstellungsgrenze.
  • Eine Wiederherstellung ist erst belastbar belegt, wenn beabsichtigte Richtlinie, installierter Routingzustand und von außen gemessene Erreichbarkeit wieder übereinstimmen.

Ein eng begrenzter Vorfall mit weitreichender Bedeutung

Diese Analyse behandelt ausschließlich den globalen IPv4-Netzwerkvorfall bei OVHcloud am 13. Oktober 2021. Sie verbindet ihn weder mit dem Brand im Rechenzentrum Straßburg im März desselben Jahres noch mit späteren Ausfällen oder Angriffen auf Kunden. Der Vorfall war nach der öffentlichen Darstellung von OVHcloud kein DDoS-Angriff, kein Cyberangriff, kein BGP-Hijacking und kein klassisches interdomaines Route Leak. Auslöser war eine vom Betreiber vorgenommene Konfigurationsänderung an einem Backbone-Router in Vint Hill, Virginia.

Gerade diese Abgrenzung ist für eine sachliche Rechenschaftsanalyse wichtig. Die Arbeiten sollten nach Angaben des Unternehmens die Widerstandsfähigkeit des Netzes gegen DDoS-Angriffe stärken. Daraus folgt jedoch nicht, dass während des Vorfalls tatsächlich ein solcher Angriff stattfand. Ebenso wenig gibt der öffentliche Bericht Anlass zu der Behauptung, ein externer Akteur habe den Router verändert. Der dokumentierte Kern ist ein durch den Betreiber ausgelöster Kontrollebenenfehler während einer Wartungsmaßnahme.

Die Bedeutung des Ereignisses liegt deshalb nicht in einer außergewöhnlichen Angriffstechnik, sondern in einer vertrauten betrieblichen Frage: Wie beweist ein Backbone-Betreiber, dass eine autorisierte Änderung nur den vorgesehenen Teil des Routingzustands verändern kann? Ein genehmigtes Wartungsfenster, ein plausibles Ziel und eine vom Gerät akzeptierte Konfiguration beantworten diese Frage nicht. Sie beschreiben Absicht und Prozessschritte. Rechenschaft setzt zusätzlich voraus, dass der resultierende Zustand messbar innerhalb vorher festgelegter Grenzen bleibt.

Der öffentliche Bericht benennt eine Interaktion zwischen BGP und OSPF, den zeitlichen Verlauf, die Auswirkungen auf Ressourcen im Backbone, einen fehlgeschlagenen Fern-Rollback sowie die anschließende physische Intervention. Diese Angaben ermöglichen eine fundierte Analyse der Kontrollgrenzen. Sie erlauben aber keine Rekonstruktion aller internen Einzelheiten. Weder Hersteller und Softwareversion des Routers noch die genaue Befehlssyntax, die Zahl der betroffenen Routen, interne Entscheidungswege oder die private Topologie sind öffentlich belegt. Wo die verfügbaren Fakten enden, muss auch die Tatsachenbehauptung enden.

Chronologie: Von der Wartung zur physischen Isolation

Nach der veröffentlichten Darstellung begann OVHcloud am 13. Oktober 2021 um 09:05 UTC mit Arbeiten an einem Router in Vint Hill. Als Zweck nannte das Unternehmen die Stärkung der DDoS-Widerstandsfähigkeit seines Netzes. Das ist der Ausgangspunkt der Ereigniskette: eine geplante Änderung an einem aktiven Bestandteil des globalen Backbones, nicht die Reaktion auf einen zu diesem Zeitpunkt bestätigten Angriff.

Um 09:18 UTC isolierte das Team den Router laut OVHcloud von BGP und aktualisierte seine Konfiguration. Die BGP-Isolation ist ein wichtiger Teil der Chronologie, darf aber nicht mit vollständiger Isolation des Geräts von allen übrigen Routing- und Managementpfaden gleichgesetzt werden. Ein Router kann von einer Protokolldomäne getrennt sein und dennoch über andere Adjazenzen, Schnittstellen oder Verwaltungswege Einfluss auf das Netz behalten. Welche konkreten Pfade in Vint Hill noch bestanden, ist aus dem öffentlichen Material nicht vollständig ableitbar.

Um 09:20 UTC kam es nach Angaben von OVHcloud zu einem Problem bei der Interpretation eines Befehls für die Redistribution von BGP-Routen nach OSPF. Dadurch gelangte die vollständige Internet-Routingtabelle in das interne Routingprotokoll. Diese Formulierung stammt aus der öffentlichen Ereignisdarstellung des Unternehmens. Sie belegt nicht die exakte technische Syntax und auch keine bestimmte Implementierungsursache. Sie belegt jedoch die entscheidende Richtung des unerwünschten Zustandsübergangs: Informationen aus der BGP-Domäne wurden in einem Umfang in OSPF eingebracht, für den die interne Domäne nicht vorgesehen war.

OVHcloud berichtete anschließend von OSPF-Instabilität sowie von CPU- und Speicherbelastung bei Routern im Backbone. Die Auswirkungen waren global für IPv4 spürbar, während IPv6 weiterhin erreichbar blieb. Diese Differenz ist stärker als eine pauschale Aussage, „das gesamte Internet“ oder „alle Dienste“ seien ausgefallen. Sie zeigt einen breiten, aber nicht vollständig protokollübergreifenden Ausfall. Die öffentliche Darstellung lässt hingegen keine belastbare Quantifizierung sämtlicher betroffener Kunden, einzelner Geschäftsverluste oder regionaler Unterschiede zu.

Der naheliegende erste Wiederherstellungsschritt war ein Fern-Rollback. Nach Angaben von OVHcloud scheiterte dieser Versuch. Damit wurde eine zentrale Schwäche sichtbar: Der reguläre Verwaltungs- oder Kontrollpfad konnte die Änderung nicht zuverlässig zurücknehmen, während der Routingzustand bereits instabil war. Das Team musste den Router physisch trennen und ausschalten. Die physische Intervention war damit nicht nur eine begleitende Maßnahme, sondern die wirksame Grenze, an der die weitere Ausbreitung des fehlerhaften Zustands beendet wurde.

Die Wiederherstellung erfolgte anschließend schrittweise. Nach dem Entfernen des betroffenen Routers mussten sich Routingzustände und Adjazenzen im Backbone neu ordnen. OVHcloud meldete eine breite Wiederherstellung bis 10:57 UTC. „Breite Wiederherstellung“ sollte dabei nicht mit dem Beweis verwechselt werden, dass zu exakt diesem Zeitpunkt jeder einzelne Dienst und jeder externe Pfad wieder seinen Sollzustand erreicht hatte. Die Zeitmarke beschreibt den vom Unternehmen gemeldeten allgemeinen Wiederherstellungsstand nach gestaffelter Rekonvergenz.

Diese Abfolge ist für die Bewertung aussagekräftiger als eine vereinfachte Erzählung von Fehlkonfiguration und Rücknahme. Die Rücknahme aus der Ferne funktionierte gerade nicht. Erst die physische Isolation schuf einen stabilen Ausgangspunkt für die Rekonvergenz. Die Rechenschaftsfrage lautet daher nicht nur, warum der problematische Zustand entstehen konnte. Ebenso wichtig ist, warum die vorgesehene Rückkehr zum vorherigen Zustand von derselben instabilen Infrastruktur abhing.

BGP und OSPF: Zwei Domänen mit unterschiedlichen Aufgaben

BGP und OSPF bearbeiten beide Erreichbarkeitsinformationen, erfüllen aber unterschiedliche Rollen. BGP ist das zentrale Protokoll für den Austausch von Routinginformationen zwischen autonomen Systemen. Seine Entscheidungen beruhen nicht allein auf kürzesten Pfaden. Sie können Richtlinien, Pfadattribute, Nachbarschaftsbeziehungen und administrative Präferenzen abbilden. Im Internetmaßstab trägt BGP eine große Menge aggregierter Erreichbarkeitsinformationen, die aus vielen voneinander unabhängigen Netzen stammen.

OSPF ist dagegen ein Interior Gateway Protocol für eine administrative Domäne. Router innerhalb eines OSPF-Bereichs verteilen Link-State-Informationen und berechnen daraus ihre Sicht auf die interne Topologie. OSPF besitzt Mechanismen für externe Routen, doch das macht das Protokoll nicht zu einem beliebig skalierbaren Behälter für sämtliche aus dem Internet gelernte BGP-Informationen. Die Annahmen über Zustandsverteilung, Flooding, Berechnung und Konvergenz unterscheiden sich erheblich.

Diese Differenz ist keine bloße Frage der Protokollnamen. Sie bildet eine operative Sicherheitsgrenze. In BGP kann eine Route Teil eines politischen und administrativen Auswahlprozesses sein. Wird sie in OSPF überführt, erhält sie eine andere Repräsentation und wird innerhalb einer anderen Zustandsmaschine verbreitet. Die Wirkung hängt nun von OSPF-Flächen, Adjazenzen, externen Routinginformationen, Berechnungen und den verfügbaren Ressourcen der beteiligten Router ab.

Die einschlägigen RFCs beschreiben diese Protokollrollen und die dafür vorgesehenen Kontrollmechanismen. RFC 4271 definiert die grundlegende BGP-Funktionsweise. RFC 2328 beschreibt OSPFv2 einschließlich externer Routen, während RFC 5340 OSPFv3 behandelt. RFC 1745 macht deutlich, dass der Import von BGP-Informationen in OSPF eine kontrollierte Richtlinienentscheidung sein muss. Diese Dokumente erklären das technische Vokabular und die Grenzen. Sie beweisen jedoch weder die private OVHcloud-Topologie von 2021 noch eine konkrete Konfiguration auf dem Router in Vint Hill.

Die Aussage, die vollständige Internet-Routingtabelle sei in OSPF gelangt, beschreibt vor diesem Hintergrund einen Wechsel der Zustandsdomäne. Auch wenn jede einzelne übernommene Route formal darstellbar gewesen sein sollte, folgt daraus keine sichere Gesamtwirkung. Ein System kann syntaktisch gültige Einträge erhalten und trotzdem an ihrer Zahl, Änderungsrate, Verteilung oder Verarbeitung scheitern. Semantische Sicherheit entsteht nicht aus der bloßen Annahme eines Befehls.

Das erklärt auch, warum der Vorfall nicht als klassisches interdomaines Route Leak bezeichnet werden sollte. Bei einem typischen Route Leak werden Routen entgegen der vorgesehenen Beziehung zwischen autonomen Systemen weitergegeben. OVHcloud beschrieb dagegen eine interne Redistribution von BGP nach OSPF. Die unerwünschte Bewegung verlief über eine Protokollgrenze innerhalb des Betreiberkontexts. RFC 7908 und RFC 9234 bieten wichtige Begriffe und Schutzideen für interdomaines Routing, ersetzen aber nicht die genaue Klassifizierung dieses Ereignisses.

Redistribution als privilegierter Zustandsübergang

Route Redistribution wird häufig als Konfigurationsfunktion behandelt: Eine Richtlinie erlaubt ausgewählten Routen aus Protokoll A den Eintritt in Protokoll B. Aus Rechenschaftssicht ist sie jedoch ein privilegierter Zustandsübergang. Sie verändert, welche Routinginformationen eine Domäne akzeptiert, wie diese Informationen dargestellt werden und in welchem Umfang sie sich über weitere Geräte ausbreiten können.

Vier Dimensionen müssen vor der Aktivierung begrenzt werden. Erstens ist die zulässige Menge zu bestimmen: Welche Präfixe oder Routenklassen dürfen überhaupt die Grenze passieren? Zweitens braucht es eine feste Richtung: Ist nur BGP nach OSPF vorgesehen, nur OSPF nach BGP oder ein präzise kontrolliertes Verhältnis? Drittens muss die Kardinalität begrenzt werden: Wie viele Routen dürfen maximal erzeugt, akzeptiert oder weiterverteilt werden? Viertens muss der Ausbreitungsbereich feststehen: Welche Geräte, OSPF-Bereiche oder Testkohorten dürfen den neuen Zustand zunächst sehen?

Diese Grenzen sollten nicht nur in einem Änderungsantrag stehen. Sie müssen in ausführbaren Kontrollen erscheinen. Ein Filter ohne messbare Obergrenze kann zwar unerwünschte Kategorien ausschließen, bietet aber möglicherweise keinen Schutz vor einer unerwartet großen Menge innerhalb der zugelassenen Kategorie. Eine maximale Präfixzahl ohne Richtungsprüfung kann wiederum einen falschen Übergang nicht zuverlässig verhindern. Ein sicherer Entwurf kombiniert Auswahlkriterien, Mengenbegrenzung, Richtung, räumlichen Umfang und automatische Abbruchbedingungen.

Der OVHcloud-Vorfall zeigt, warum der vom Menschen beabsichtigte Sinn eines Befehls nicht genügt. Eine Freigabe kann korrekt dokumentiert sein und trotzdem von der tatsächlich gerenderten Gerätekonfiguration abweichen. Ein Gerät kann eine Eingabe erfolgreich bestätigen und anschließend einen unerwarteten laufenden Zustand erzeugen. Zwischen Entwurf, Darstellung, Geräteannahme und Wirkung liegen mehrere überprüfbare Übergänge.

Eine belastbare Änderungskette müsste deshalb mindestens die genehmigte Absicht, die konkrete Kandidatenkonfiguration, die auf dem Gerät gerenderte Konfiguration und den beobachteten Routingzustand miteinander verknüpfen. Bei Redistribution gehören dazu nicht nur Textunterschiede in einer Konfiguration. Erforderlich sind Messwerte zu BGP- und OSPF-Routen, zu neu erzeugten externen OSPF-Einträgen, zur Link-State-Datenbank, zur Routing Information Base und zur Forwarding Information Base.

Die Veränderung dieser Werte muss zeitlich mit dem Änderungsschritt korrelierbar sein. Steigt die Zahl externer OSPF-Routen unmittelbar nach der Aktivierung über den genehmigten Grenzwert, darf die nächste Ausrollungsstufe nicht beginnen. Verändern sich Adjazenzen unerwartet, wächst die Link-State-Datenbank sprunghaft oder überschreiten CPU und Speicher den zulässigen Bereich, muss ein automatischer Abbruch oder eine vorher definierte Isolation ausgelöst werden.

Eine solche Abbruchlogik darf nicht ausschließlich auf demselben Steuerungspfad liegen, dessen Stabilität gerade gefährdet wird. Sonst kann der Fehler genau den Mechanismus unbrauchbar machen, der ihn zurücknehmen soll. Der gescheiterte Fern-Rollback in Vint Hill ist deshalb kein nebensächliches Detail, sondern Teil des Kerns. Er zeigt, dass Rücknehmbarkeit als eigenständige Systemeigenschaft geprüft werden muss.

Kardinalität, Flooding und Konvergenz

Der plausible technische Mechanismus hinter der gemeldeten OSPF-Instabilität lässt sich erklären, ohne nicht veröffentlichte Einzelheiten zu erfinden. OSPF verteilt Link-State-Informationen innerhalb seiner vorgesehenen Bereiche. Router führen eine Link-State-Datenbank, verarbeiten Aktualisierungen und berechnen daraus Routingentscheidungen. Externe Routen können in diesen Prozess eingebunden werden. Eine unerwartet große Menge solcher Informationen erhöht den zu speichernden und zu verarbeitenden Zustand.

Das allein beweist noch nicht, welcher konkrete interne Schritt auf welchem Gerät zuerst scheiterte. Möglich sind Belastungen durch Erzeugung, Flooding, Speicherung, Aktualisierung, Berechnung oder Installation von Routen. Ebenso können instabile Nachbarschaften und wiederholte Aktualisierungen die Belastung verstärken. Der öffentliche Bericht nennt OSPF-Instabilität sowie CPU- und Speicherprobleme im Backbone, legt aber keine vollständige Telemetrie oder gerätespezifische Fehlerkette offen.

Gerade deshalb sollte eine Rechenschaftsanalyse zwischen bestätigtem Ergebnis und technisch plausibler Erklärung unterscheiden. Bestätigt ist die vom Unternehmen gemeldete Bewegung der vollständigen Internet-Routingtabelle von BGP nach OSPF, gefolgt von OSPF-Instabilität und Ressourcenbelastung. Plausibel ist, dass die Zustandsmenge und ihre Verteilung die vorgesehenen Betriebsgrenzen überschritten. Nicht belegt sind eine genaue Routenzahl, bestimmte LSA-Typen oder -Mengen, ein spezieller Softwarefehler oder ein bestimmtes Verhalten eines nicht genannten Herstellers.

Kardinalität ist in diesem Zusammenhang eine Kontrollgröße, keine nachträgliche Statistik. Ein Betreiber muss vor einer Änderung festlegen, welche maximale Zahl von Routen die Grenze passieren darf. Der Grenzwert sollte deutlich unter dem liegen, was Geräte theoretisch im Labor speichern können. Er muss auch Änderungsraten, Rekonvergenz, Reserven und die gleichzeitige Verarbeitung anderer Ereignisse berücksichtigen.

Dass gegenwärtige OVHcloud-Unterlagen für kundenbezogene Netzwerkdienste unter anderem explizite Präfixgrenzen beschreiben, zeigt die grundsätzliche Verfügbarkeit dieses Kontrollvokabulars. Die Dokumente erläutern außerdem heutige Begriffe wie BGP-basierte Layer-3-Konnektivität, ECMP und BFD. Sie dürfen jedoch nicht als Nachweis behandelt werden, dass der betroffene Router 2021 genau dieselben Regeln oder Produktmechanismen verwendete. Ihr Wert liegt im gegenwärtigen Kontext: Routinggrenzen lassen sich als messbare Invarianten ausdrücken.

Auch Konvergenz ist nicht einfach ein binärer Zustand. Nach dem Entfernen eines fehlerhaften Knotens müssen Protokolle Nachbarschaften und Pfade neu bewerten. Währenddessen können verschiedene Router unterschiedliche Sichtweisen besitzen. RIB und FIB können zeitweise voneinander abweichen, und externe Erreichbarkeit kann sich nach Ziel, Standort und IP-Version unterschiedlich entwickeln. Eine belastbare Wiederherstellungsmeldung braucht deshalb mehr als die Information, dass OSPF wieder Adjazenzen aufgebaut hat.

Auswirkungen und die Bedeutung der IPv6-Kontinuität

OVHcloud meldete eine globale Beeinträchtigung von IPv4, während IPv6 weiter erreichbar blieb. Diese Beobachtung ist wertvoll, weil sie gegen die vereinfachte Annahme eines vollständig einheitlichen Ausfalls spricht. Mindestens ein Teil der Protokoll-, Routing- oder Weiterleitungsstruktur blieb so getrennt, dass IPv6 nicht in gleicher Weise ausfiel.

Die fortbestehende IPv6-Erreichbarkeit beweist jedoch keine vollständige architektonische Unabhängigkeit. IPv4 und IPv6 können getrennte Routinginformationen besitzen und zugleich Hardware, Stromversorgung, Management, optische Pfade, Telemetrie oder operative Verfahren teilen. Die beobachtete Kontinuität zeigt eine partielle Trennung im Ergebnis. Welche internen Abhängigkeiten tatsächlich getrennt oder gemeinsam waren, ist aus den öffentlichen Angaben nicht vollständig ersichtlich.

Eine ernsthafte Untersuchung müsste deshalb mehrere Ebenen unterscheiden. Auf der Kontrollebene wäre zu prüfen, welche BGP- und OSPF-Prozesse für IPv4 und IPv6 beteiligt waren. Auf der Datenebene wäre festzustellen, welche Weiterleitungseinträge vorhanden waren und ob Pakete tatsächlich die vorgesehenen Pfade nahmen. Auf der Managementebene wäre zu klären, ob die gleichen Verwaltungswege und Geräte verwendet wurden. Auf der Beobachtungsebene wäre zu untersuchen, ob externe Proben beide Protokollfamilien unabhängig gemessen haben.

Kundenauswirkungen lassen sich ebenfalls nicht allein aus dem globalen Charakter des Vorfalls ableiten. Der öffentliche Bericht stützt die Aussage eines breiten IPv4-Ereignisses, aber keine detaillierte Liste betroffener Kunden, Dienste oder finanzieller Verluste. Solche Behauptungen würden zusätzliche Nachweise aus Kundenmessungen, Supportfällen, Serviceprotokollen oder unabhängigen Beobachtungen benötigen.

Kunden benötigen deshalb eine differenzierte Beweiskette. Dazu gehören Zeitreihen externer IPv4- und IPv6-Erreichbarkeit, BGP-Sichtbarkeit, Paketverlust, Latenz und dienstbezogene Fehler. Diese Daten müssen mit der internen Änderungs- und Wiederherstellungschronologie vergleichbar sein. Erst die Verbindung beider Perspektiven zeigt, ob die gemeldete Netzstabilisierung auch bei den tatsächlich genutzten Diensten ankam.

Warum der Fern-Rollback nicht die letzte Verteidigung sein darf

Ein Rollback wird häufig als Umkehrung einer Konfigurationsänderung verstanden. Diese Vorstellung setzt voraus, dass das Gerät erreichbar bleibt, Befehle verarbeitet, die benötigte Konfiguration verfügbar ist und das Netz den Verwaltungsverkehr zuverlässig transportiert. Bei einem Kontroll Ebenenfehler können genau diese Voraussetzungen verloren gehen.

OVHcloud teilte mit, dass der Fern-Rollback scheiterte. Die öffentliche Darstellung erklärt nicht sämtliche internen Ursachen dieses Scheiterns. Es wäre daher unzulässig, einen bestimmten Ausfall des Managementnetzes, ein Herstellerproblem oder einen Bedienfehler zu behaupten. Fest steht lediglich, dass die entfernte Rücknahme nicht wirksam war, während die Instabilität anhielt.

Damit wird die Unabhängigkeit des Wiederherstellungspfads zu einer prüfbaren Rechenschaftsanforderung. Ein unabhängig gerouteter Managementzugang sollte nicht auf den BGP- oder OSPF-Zustand angewiesen sein, der verändert wird. Konsolenzugriff muss auch dann möglich bleiben, wenn der normale IP-Pfad nicht funktioniert. Fernsteuerbare Stromversorgung kann eine letzte kontrollierte Trennung erlauben. Wo physische Isolation erforderlich sein kann, müssen Zuständigkeiten, Zugang, Kommunikationswege und Reihenfolge vorher geübt sein.

Die physische Trennung des Routers in Vint Hill war nach dem öffentlichen Bericht wirksam. Daraus folgt nicht, dass physische Intervention immer die bevorzugte Rückfalloption ist. Sie ist langsamer, standortabhängig und kann zusätzliche Risiken erzeugen. Ihre Bedeutung liegt darin, dass sie außerhalb des instabilen Routingzustands lag. Ein verantwortbarer Entwurf versucht, diese Unabhängigkeit bereits durch Out-of-Band-Management, Konsole, Stromkontrolle und klar definierte Isolation zu erreichen.

Auch Stub-Router-Mechanismen, wie sie in RFC 3137 und RFC 6987 beschrieben werden, können als Kontrollvokabular für Wartung und reduzierte Transitnutzung dienen. BFD gemäß RFC 5880 kann Fehler schneller erkennen. Keine dieser Techniken ist jedoch ein pauschaler Beweis für sichere Redistribution, und keine Quelle belegt, welche davon in Vint Hill eingesetzt wurde. Sie beantworten unterschiedliche Teile des Problems und müssen in einem konkreten Entwurf gemeinsam geprüft werden.

Wann eine Wiederherstellung tatsächlich abgeschlossen ist

Eine erfolgreiche Geräteantwort beweist nicht, dass die gewünschte Richtlinie läuft. Eine stabile OSPF-Adjazenz beweist nicht, dass die richtige Routenmenge installiert ist. Eine normalisierte CPU-Auslastung beweist nicht, dass externe Kundenpfade wieder funktionieren. Jede dieser Beobachtungen deckt nur einen Teil der Wiederherstellung ab.

Ein belastbarer Abschluss benötigt Übereinstimmung auf drei Ebenen. Erstens muss die beabsichtigte Richtlinie klar sein: Welche Routen dürfen in welcher Richtung zwischen den Protokollen wechseln? Zweitens muss der installierte Zustand dieser Richtlinie entsprechen: RIB, FIB, Link-State-Datenbank, Adjazenzen und Routenzahlen dürfen keine unerwarteten Einträge oder Mengen zeigen. Drittens muss externe Erreichbarkeit bestätigen, dass IPv4- und IPv6-Datenverkehr aus mehreren unabhängigen Perspektiven funktioniert.

Diese drei Ebenen sollten zeitlich zusammengeführt werden. Ein Änderungsprotokoll muss erkennen lassen, wann die Freigabe erfolgte, wann die Konfiguration gerendert und angewendet wurde, wann sich die Routingtabellen veränderten, wann Warnschwellen überschritten wurden und wann externe Messpunkte eine Verschlechterung oder Erholung sahen. Ohne gemeinsame Zeitbasis bleiben interne und externe Beobachtungen schwer vergleichbar.

Der Abschluss braucht außerdem eine Haltephase. Ein Netz kann unmittelbar nach der Rekonvergenz stabil wirken und anschließend durch zeitversetzte Aktualisierungen oder erneute Adjazenzwechsel wieder instabil werden. Die Dauer dieser Beobachtungsphase sollte vorab definiert sein und sich an Topologie, Protokolltimern und erwarteter Ausbreitung orientieren. Die öffentlichen Quellen nennen keinen solchen konkreten Zeitraum für OVHcloud; hier handelt es sich um eine empfohlene Kontrolle.

Zur Abschlussentscheidung gehört schließlich die Dokumentation verbleibender Unsicherheit. Wenn keine externen Messungen für eine Region verfügbar sind, sollte dies offen benannt werden. Wenn die RIB konsistent erscheint, die FIB-Prüfung aber unvollständig ist, darf der Befund nicht als vollständig verifiziert gelten. Rechenschaft bedeutet nicht, Unsicherheit zu beseitigen, sondern sie sichtbar zu machen und ihre Folgen für Entscheidungen zu begrenzen.

Ein Rechenschaftsrahmen für Backbone-Änderungen

Der Vorfall legt einen Rechenschaftsrahmen nahe, der eine Änderung nicht nach ihrer administrativen Freigabe, sondern nach ihren nachweisbaren Zustandsübergängen bewertet. Der erste Prüfpunkt ist der Umfang. Das Wartungsobjekt, die betroffenen Protokolle, die erlaubten Routenfamilien und die maximale Ausbreitung müssen eindeutig definiert sein.

Der zweite Prüfpunkt ist die Kandidatenkonfiguration. Vor der Aktivierung muss der Betreiber zeigen können, wie abstrakte Richtlinien in konkrete Gerätekonfiguration übersetzt werden. Dazu gehören Filter, Routenkennzeichnungen, Richtungen, Grenzwerte und das Verhalten bei Überschreitung. Eine reine Textprüfung ist nicht ausreichend, wenn die tatsächliche Interpretation vom Gerätekontext abhängt.

Der dritte Prüfpunkt ist ein begrenzter Erstempfänger. Eine risikoreiche Redistribution sollte zunächst auf einem Canary-Gerät, in einer isolierten Umgebung oder in einer kleinen, kontrollierten Kohorte getestet werden. Dieser Schritt ist nur dann sinnvoll, wenn der Canary dieselben entscheidenden Pfade und Zustandsübergänge abbildet, ohne bereits den globalen Backbone zu gefährden.

Der vierte Prüfpunkt sind automatische Stoppsignale. Routenanzahl, Änderungsrate, Link-State-Datenbank, Adjazenzen, CPU, Speicher, RIB, FIB sowie externe Erreichbarkeit müssen vorab definierte Normal- und Abbruchbereiche besitzen. Der Abbruch sollte nicht erst erfolgen, wenn Menschen mehrere voneinander getrennte Alarme zusammenführen.

Der fünfte Prüfpunkt ist die unabhängige Rücknahme. Out-of-Band-Zugriff, Konsole, Stromsteuerung und physische Isolation müssen so ausgelegt sein, dass sie nicht vom veränderten Routingzustand abhängen. Ihre Funktionsfähigkeit ist vor der Änderung zu testen. Ein theoretisch vorhandener Konsolenpfad, dessen Zugangsdaten, Verbindung oder Zuständigkeit im Ereignisfall unklar sind, ist keine verlässliche Kontrolle.

Der sechste Prüfpunkt ist externe Beobachtung. Interne Telemetrie kann zeigen, dass Router erwartete Zustände melden. Nur unabhängige Messpunkte können bestätigen, dass Netze und Dienste von außen tatsächlich erreichbar sind. Für einen globalen Anbieter sollten die Proben verschiedene Regionen, Upstreams und beide IP-Versionen umfassen.

Der siebte Prüfpunkt ist nachvollziehbare Kommunikation. Kunden sollten erfahren, welcher Teil des Netzes betroffen ist, welche Aussagen bestätigt sind und welche noch untersucht werden. Im OVHcloud-Fall war die Unterscheidung zwischen IPv4-Beeinträchtigung und fortbestehendem IPv6-Zugang besonders relevant. Eine pauschale Statusmeldung hätte diese wichtige Grenze verdeckt.

Der achte Prüfpunkt ist die Schlussprüfung nach der Wiederherstellung. Der Betreiber muss nicht nur zeigen, dass die Symptome verschwunden sind. Er muss belegen, dass die beabsichtigte Richtlinie, der laufende Routingzustand und die externen Beobachtungen wieder übereinstimmen. Erst dann ist die Wiederherstellung als kontrollierter Abschluss statt als bloße Rückkehr der Erreichbarkeit nachvollziehbar.