Zusammenfassung

  • Am 25. Januar 2023 löschte ein bei Kapazitätsarbeiten in Madrid verwendeter, nicht für alle Router-Plattformen qualifizierter Befehl auf der Plattform eines Herstellers IGP-Informationen über das lokale Gerät hinaus. Um 07:08 UTC begann dadurch eine weitreichende IGP-Neuberechnung mit anschließender BGP-Neubekanntgabe und die erste Welle der Kundenbeeinträchtigung.
  • Derselbe Vorgang wurde 33 Minuten später manuell am zweiten Madrider Router ausgeführt, weil der ausführende Techniker nicht über die aktiven Alarme informiert worden war. Die zweite Welle macht deshalb auch die Verbindung zwischen Überwachung, Einsatzführung und der Befugnis zum Stoppen laufender Änderungen zu einer zentralen Verantwortungsfrage.
  • Die meisten Geräte, Regionen und Dienste hatten sich bis 09:05 UTC erholt, die letzte Netzwerkausrüstung bis 09:25. Angehaltene WAN-Zustands- und Traffic-Engineering-Systeme mussten jedoch manuell neu gestartet werden, bevor Microsoft um 12:43 die vollständige Entschärfung meldete. Die Wiederherstellung verlief in Schichten und nicht durch einen einzigen sofort wirksamen Rollback.

Eine örtlich begrenzte Aufgabe erreichte eine globale Routing-Domäne

Der Vorfall begann bei geplanten Arbeiten zur Erweiterung der Kapazität von Microsofts globalem Weitverkehrsnetz in Madrid. Zwei neue Router sollten neue IP-Adressen erhalten und in die internen und externen Routing-Domänen IGP und BGP aufgenommen werden. Der physische Arbeitsort war eng begrenzt. Die tatsächliche logische Reichweite des dabei verwendeten Befehls war es nicht.

Microsofts abschließender Bericht beschreibt ein Standardverfahren, das vor dem Ereignis geändert, anschließend aber nicht erneut getestet worden war. Zudem fehlten vorgeschriebene Prüfungen vor und nach der Ausführung. Das Verfahren enthielt einen Befehl zum Leeren der IGP-Datenbank. Auf den Geräten zweier Hersteller wirkte er lokal; auf der Plattform eines dritten Herstellers erstreckte sich seine Standardwirkung über alle per IGP verbundenen Router.

Microsofts System zur Befehlsautorisierung hatte dieses plattformspezifische globale Verhalten nicht als zu sperrenden Vorgang klassifiziert. Mit der ersten Ausführung um 07:08 mussten WAN-Router ihre interne Topologie und Erreichbarkeit neu berechnen. BGP-Router gaben Internetpräfixe anschließend erneut bekannt und validierten sie, während sich die verfügbaren Pfade veränderten.

Das ist der im endgültigen Bericht festgehaltene interne Mechanismus. Die Störung war nicht lediglich eine allgemein formulierte Cloud-Unterbrechung. Ohne die IGP-Leerung, die Neuberechnung der Topologie, die BGP-Neubekanntgaben und die wechselnden Weiterleitungspfade fehlt die zentrale Erklärung für den Kundeneffekt. Die Verantwortungsfrage lautet daher nicht nur, weshalb ein Mensch einen Befehl eingab. Sie lautet, weshalb Verfahren und Autorisierung den tatsächlichen Umfang dieses Befehls auf jeder eingesetzten Plattform nicht nachweisen konnten, bevor er die laufende Routing-Domäne erreichte.

Berechtigung und Qualifikation beantworten verschiedene Fragen

Eine Arbeitsbeschreibung hält die Absicht eines Vorgangs fest. Ein Router führt dagegen die Semantik der tatsächlich laufenden Software aus. Wenn Hersteller denselben oder einen ähnlich bezeichneten Befehl unterschiedlich auslegen, begrenzen weder der Name des Arbeitsschritts noch eine textbasierte Freigabeliste automatisch dessen Wirkung.

Autorisierung beantwortet, ob eine Person handeln darf. Qualifikation muss beantworten, was das Netz auf einer bestimmten Plattform, Softwareumgebung und Geräterolle bei dieser Handlung tun wird. Ein erlaubter Befehl kann im konkreten Kontext weiterhin unsicher sein. Der Madrider Vorfall zeigt genau diese Lücke: Das Kontrollsystem erkannte den herstellerspezifischen globalen Effekt nicht, obwohl der Befehl ausführbar war.

Die Quellen nennen weder Hersteller noch Gerätemodelle, Softwareversionen oder den genauen Wortlaut des Befehls. Es wäre deshalb nicht vertretbar, einen Anbieter oder ein Produkt zu beschuldigen. Belegt ist nur der entscheidende Unterschied: lokal auf zwei Plattformen, IGP-weit auf einer dritten. Die Rechenschaftspflicht liegt darin, solche Unterschiede vor dem Einsatz zu testen und ihre Ergebnisse an Plattform und Rolle zu binden.

Die fehlenden Vor- und Nachprüfungen verschärften das Problem. Vor einer risikoreichen WAN-Änderung sollte der erwartete Umfang überprüfbar benannt sein: Welche Geräte, Nachbarschaften, Routing-Domänen und Präfixe dürfen sich bewegen? Nach und während der Ausführung sollte der reale Zustand mit diesem Korridor verglichen werden. Eine Abweichung muss den nächsten Schritt sperren können und darf nicht bloß als später auszuwertender Alarm enden.

Das sind aus dem Ereignis abgeleitete Anforderungen an eine Kontrollarchitektur, keine Behauptung, eine einzelne Prüfung hätte jedes denkbare Versagen verhindert. Ihr Wert liegt darin, Wirkungsumfang falsifizierbar zu machen. Der laufende Zustand ist die Realitätsschicht: Er entscheidet über die Reichweite, nicht die Bezeichnung des Tickets und nicht allein die Berechtigung des Bedieners.

Öffentliche BGP-Daten zeigten die Wirkung, nicht die interne Ursache

ThousandEyes beobachtete, wie Microsoft-Präfixe zurückgezogen und erneut bekannt gegeben wurden. Verkehr wechselte teilweise von direkten Peering-Verbindungen zu Transit-Anbietern, begleitet von erheblichem Paketverlust. Kentik registrierte zwei Einbrüche des aggregierten Verkehrs und stark unterschiedliche Folgen nach Pfad und Region; einige Präfixe waren beeinträchtigt, andere transportierten weiterhin Daten.

Diese Messungen sind wichtig, weil sie den Vorfall an der für Kunden und Nachbarn sichtbaren Netzgrenze dokumentieren. Zugleich setzen sie der Schlussfolgerung eine klare Grenze. Öffentliche BGP-Instabilität verrät weder den internen Befehl noch den Entscheidungsweg, der ihn zuließ. Sie beweist keinen BGP-Hijack, keinen externen Angriff und keinen grundsätzlichen Entwurfsfehler des Protokolls. Kentik wies darauf hin, dass die sichtbare Instabilität wahrscheinlich ein Symptom des internen Fehlers und nicht dessen Ursache war.

BGP blieb dennoch ein wesentlicher Teil der kundenwirksamen Kette. Während die interne Topologie neu berechnet wurde, mussten Grenzrouter Präfixe erneut ankündigen und validieren. Pfade änderten sich, ein Teil des Verkehrs verlagerte sich vom direkten Peering zum Transit. Für Kunden äußerte sich diese Bewegung als höhere Latenz, Zeitüberschreitung, zeitweiliger Paketverlust oder auf einzelnen Pfaden als vollständiger Verlust der Verbindung.

Die externen Beobachtungen und der interne Bericht erfüllen unterschiedliche Beweisfunktionen. Der abschließende Bericht beschreibt Befehl, Verfahren und proprietäre Systeme. Die unabhängigen Messungen zeigen, ob die behauptete Kette mit dem am Internet sichtbaren Routen- und Verkehrsverhalten übereinstimmt. Keine Ebene sollte die andere ersetzen.

Diese Trennung betrifft auch frühe Hypothesen. Während die Sachlage noch unvollständig war, wurde extern erwogen, ob Automatisierung den Vorgang wiederholt haben könnte. Das war eine plausible Untersuchungsfrage, ist aber nicht die maßgebliche Schlussfolgerung. Der spätere und genauere Abschlussbericht hält fest, dass der Vorgang am zweiten Router erneut ausgeführt wurde.

Zwei manuelle Vorgänge erzeugten zwei Wellen

Der Ausfall war keine einzige automatische Kaskade. Microsofts Überwachung erkannte innerhalb weniger Minuten DNS- und WAN-Symptome und erzeugte um 07:11 Alarme. Der in Madrid arbeitende Techniker wurde darüber jedoch nicht informiert. 33 Minuten nach dem ersten Vorgang führte er denselben Arbeitsschritt am zweiten Router aus. Dadurch entstand eine zweite Beeinträchtigungswelle.

ThousandEyes und Kentik sahen zwei voneinander unterscheidbare Routen- oder Verkehrsstörungen, was zu dieser zeitlichen Trennung passt. Ihre Messungen können weder den Bediener noch den internen Kommunikationsweg identifizieren. Dass die zweite Ausführung manuell und unter demselben nicht qualifizierten Verfahren stattfand, ergibt sich aus Microsofts endgültiger Untersuchung.

Die 33 Minuten legen eine Kontrollgrenze zwischen Änderungsausführung und Incident Response offen. Das Monitoring erkannte ein Problem, und die Reaktion hatte begonnen. Die Information erreichte aber nicht die Stelle, die denselben Mechanismus erneut auslösen konnte. Einzelne Funktionen waren aktiv; das Gesamtsystem verwandelte den Alarm dennoch nicht in eine Unterbrechung der laufenden Arbeit.

Ein Alarm schützt nur begrenzt, wenn er die Zustandsmaschine der Änderung nicht beeinflussen kann. Bei WAN-Arbeiten mit großem möglichen Wirkungsbereich muss eine Grenzverletzung den Ablauf pausieren, den nächsten Schritt entziehen, eine neue Freigabe verlangen oder die Entscheidungsgewalt an die Einsatzführung übertragen können. Welche dieser Kontrollen damals vorhanden war, ist nicht vollständig öffentlich dokumentiert. Die bekannte Benachrichtigungslücke reicht jedoch aus, um den Stopppfad als Verantwortungsfläche zu bestimmen.

Individuelle Schuldzuweisung würde diese Analyse verengen. Der Techniker wird nicht genannt; sein vollständiger Konsolenkontext und seine Absicht sind nicht bekannt. Belegt sind dagegen Systemeigenschaften: ein verändertes, nicht erneut getestetes Verfahren, fehlende Prüfungen, eine unvollständige Klassifizierung des Befehls und ein Alarmweg, der die zweite Ausführung nicht stoppte. Diese Eigenschaften kann eine Infrastrukturorganisation untersuchen und verändern.

Die globale Reichweite bedeutete keine gleichförmige Wirkung

Der Vorfall betraf Internet-zu-Azure-Verkehr, Verkehr zwischen Regionen und standortübergreifende Verbindungen über ExpressRoute, VPN und Virtual WAN. Abhängige Angebote, darunter Teile von Microsoft 365 und Power Platform sowie Azure-Government-Dienste mit Abhängigkeit vom öffentlichen Azure, waren ebenfalls betroffen.

Die Kundenerfahrung variierte jedoch dynamisch nach Quelle, Ziel und Pfad. Gemeldet wurden Latenz, Zeitüberschreitungen, zeitweiliger Paketverlust und auf einigen Pfaden ein vollständiger Verbindungsverlust. Indien und Teile Nordamerikas gehörten zu den Bereichen mit längerer Wiederherstellung. Das Material belegt nicht, dass jede Azure-Region, jeder Dienst, jeder Kunde oder jede Internetroute einheitlich ausgefallen wäre.

Diese Uneinheitlichkeit passt zu einem Netz, in dem Präfixe zurückgezogen, erneut bekannt gegeben, validiert und über andere Pfade transportiert werden. Ein globaler Durchschnitt kann lokale Restschäden verdecken. Ein hoher Wiederherstellungsanteil bedeutet nicht automatisch, dass jedes relevante Quelle-Ziel-Paar wieder funktioniert. Für die Betriebssicherheit sind daher Pfadindikatoren ebenso wichtig wie zusammengefasste Verfügbarkeitswerte.

Die verfügbaren Quellen liefern keine geprüfte Zahl betroffener Nutzer oder Kunden, keine vollständige Liste aller Dienste und Regionen und keinen belastbaren finanziellen Schaden. Sie belegen weder Kundendatenverlust noch böswilliges Handeln. Die technische Wirkung lässt sich substantiell beschreiben, ohne diese Lücken durch erfundene Reichweiten oder Schadenssummen zu füllen.

Wiederherstellung verlief in mehreren Schichten

Während die automatische Routing-Konvergenz bereits voranschritt, identifizierten Ingenieure den problematischen Befehl bis 08:20. Bis 09:05 hatten sich nahezu alle Netzwerkgeräte, Regionen und Dienste erholt. Um 09:25 war auch die letzte Netzwerkausrüstung wiederhergestellt. Der Vorfall war damit aber noch nicht vollständig beendet.

An einzelnen Standorten bestand überdurchschnittlicher Paketverlust fort, weil WAN-Zustands- und Traffic-Engineering-Systeme angehalten waren. Sie mussten manuell neu gestartet werden. Erst um 12:43 erklärte Microsoft sämtliche Probleme für vollständig entschärft. Das offizielle Kundenwirkungsfenster reicht deshalb von 07:08 bis 12:43, auch wenn der größte Teil der Dienste erheblich früher zurückkehrte.

Zeitgenössische Berichte gaben Microsofts frühe Hinweise auf Routing-Änderungen und einen Rollback wieder. Diese Aussagen dokumentieren den damaligen Informationsstand, ersetzen aber nicht die vollständigere spätere Sequenz aus automatischer Konvergenz, weitgehender Dienstwiederkehr, Erholung der letzten Ausrüstung und manuellem Neustart unterstützender Systeme.

Ein Rollback allein beweist keine vollständige operative Wiederherstellung. Pakete können wieder fließen, während die Systeme zur Erkennung ungesunder Pfade und zur Verkehrssteuerung noch nicht funktionieren. Ein belastbarer Abschluss muss deshalb mindestens drei Zustände unterscheiden: breite Erreichbarkeit, Wiederkehr der verbleibenden Geräte und Pfade sowie Rückkehr der Zustands- und Steuerungsfunktionen in einen bekannten Betriebszustand.

Diese Trennung verhindert auch einen irreführend kurzen Zeitstrahl. 09:05 bezeichnet die weitgehende Wiederherstellung von Geräten, Regionen und Diensten; 09:25 die letzte Netzwerkausrüstung; 12:43 die unterstützenden Systeme und den verbleibenden Paketverlust. Jede Zeit beantwortet eine andere operative Frage.

Der Befund betrifft das System, nicht ein juristisches Urteil

Die vier Quellen tragen eine eng umrissene technische Kette: Ein verändertes, nicht erneut getestetes Verfahren enthielt einen Befehl mit herstellerabhängigem Umfang. Seine Ausführung löste eine breite IGP-Neuberechnung aus; BGP-Ankündigungen und Pfade veränderten sich; Kunden erlebten ungleichmäßige Konnektivitätsprobleme. Bevor der ausführende Techniker die Alarme erhielt, wurde der Vorgang manuell wiederholt. Die Erholung folgte anschließend mehreren technischen Stufen.

Der Datensatz begründet weder ein Gerichts- oder Behördenurteil noch Fahrlässigkeit, Vertragsbruch oder eine Entschädigungspflicht. Er reicht auch nicht aus, um jede Entscheidung einer namentlich bestimmten Person zuzuordnen oder alle eventuell wirksamen Kompensationskontrollen zu bewerten. Diese Grenzen schützen die Genauigkeit des Befunds; sie schwächen die nachgewiesene Kontrolllücke nicht.

Microsoft nannte als geplante Abhilfen unter anderem die Prüfung und Sperrung hochwirksamer Befehle über Hersteller und Rollen hinweg, mehr Sichtbarkeit genehmigter und nicht qualifizierter Geräteaktivität für Bereitschaftsteams, verpflichtende Schulung und Bestätigung sowie die Prüfung noch offener Verfahren durch ein Change Advisory Board. Das sind veröffentlichte Zusagen. Die hier verwendeten Quellen weisen nicht unabhängig nach, dass sie abgeschlossen wurden oder später wirksam waren.

Die belastbare Schlussfolgerung bleibt daher auf den Vorfall begrenzt: Sichere Routing-Änderungen erfordern nachgewiesenen Ausführungsumfang auf jeder Plattform, beobachtbare Grenzen für IGP- und BGP-Zustand, eine direkte Verbindung von Alarmen zu einer wirksamen Stoppbefugnis und Wiederherstellungskriterien, die auch die unterstützenden Zustands- und Traffic-Engineering-Systeme einschließen.

Quellen