In einem vorläufigen Post Incident Review (PIR) hat Microsoft jetzt erklärt, warum es am 25. Januar zu globalen WAN-Problemen in der Microsoft-Cloud kam. Für die User machten sich die Probleme dadurch bemerkbar, dass sie zeitweise Teams, Microsoft 365, Power Platform und andere Dienste nicht oder nur mit verminderter Performance nutzen konnten. Bei der Verbindung zu diesen Services in der Azure Cloud traten hohe Latenzzeiten und/oder Timeouts auf, was zu zeitweiligen Paketverlusten führte. Laut Microsoft traten die Probleme zwischen 7:05 und 12:43 UTC auf.

Was schief lief

Doch was führte zu den globalen Ausfällen? Nach der Analyse von Microsoft führte eine fast schon lapidar anmutende Änderung zu den massiven Problemen: Ein WAN-Router sollte eine neue IP-Adresse erhalten. Nur diese Änderung ging gewaltig schief. Ein an den Router gegebener Befehl führte dazu, dass dieser Nachrichten an alle anderen Router im WAN sendete. Daraufhin berechneten alle Router ihre Adjacency- und Forwarding-Tabellen neu. Während dieser Neuberechnung waren die Router nicht in der Lage, die sie durchquerenden Pakete korrekt weiterzuleiten. Dies beeinträchtigte die Connectivity zwischen Clients im Internet und Azure, die Connectivity zwischen den Cloud-Regionen sowie die standortübergreifende Connectivity über Azure ExpressRoute zur Verbindung von Firmennetzen mit der Micosoft Cloud.

So reagierte Microsoft

Laut Microsoft zeigten sich ab 7:12 UTC erste DNS- und WAN bezogene Probleme. Daraufhin begann man alle kürzlich vorgenommenen Veränderungen zu überprüfen. Um 08:20 UTC, als die automatische Wiederherstellung stattfand, identifizierteMicrosoft den problematischen Befehl, der die Probleme auslöste. Laut Netzwerk-Telemetrie waren dann bis 09:00 UTC fast alle Netzwerkgeräte wieder einsatzbereit, ebenso die meisten Regionen und Dienste. Die letzten Netzwerkgeräte waren um 09:35 Uhr UTC wiederhergestellt.

Dass die User dennoch länger mit Störungen zu kämpfen hatten, lag laut Microsoft daran, dass die automatisierten Systeme zur Steuerung des WANs angehalten wurden. Dazu zählen etwa Systeme zum Erkennen und Entfernen von mit Schadsoftware infizierten Geräte sowie das Traffic-Engineering-System zur Optimierung des Datenflusses im Netz. Aufgrund der Unterbrechung dieser Systeme kam es auf einigen Pfaden im Netz ab 09:35 UTC zu erhöhten Paketverlusten, bis diese Systeme manuell neu gestartet wurden und das WAN wieder optimale Betriebsbedingungen aufwies. Diese Wiederherstellung konnte Microsoft um 12:43 Uhr UTC abschließen.

Lessons Learned

Als Lektion aus dem Vorfall hat Microsoft erst einmal die Ausführung potenziell gefährlicher Befehle auf den Netz-Devices geblockt. Zudem will Microsoft noch im Februar eine Safe Change Guideline einführen, die bei der Ausführung von Befehlen auf den Netz-Devices einzuhalten ist.