Selon une analyse de l'incident effectuée par ThousandEyes, les pannes ayant provoqué une large indisponibilité d’Azure et de plusieurs services cloud de Microsoft pendant 90 minutes le 25 janvier, résultent des effets en cascade d'une republication rapide et répétée des préfixes de routage BGP (Border Gateway Protocol). Selon l‘éditeur spécialisé dans l’analyse réseau, propriété de Cisco, la panne est la conséquence d’une modification externe des tables de routage BGP par Microsoft qui a affecté les fournisseurs de services. Comme l’a expliqué ThousandEyes, plusieurs préfixes BGP de Microsoft ont été retirés complètement, puis republiés presque immédiatement. Le protocole BGP (Border Gateway Protocol) indique au trafic Internet la route à emprunter, et l'algorithme de sélection du meilleur chemin BGP détermine les routes optimales à utiliser pour le transfert du trafic. Selon ThousandEyes, le retrait des routes BGP avant la panne semble avoir eu un impact important sur les pairs directs. Si un chemin direct n'était pas disponible pendant les périodes de retrait, le meilleur chemin disponible suivant aurait été celui d'un fournisseur de transit. Une fois les chemins directs ré-publiés, l'algorithme de sélection du meilleur chemin BGP aurait choisi le chemin le plus court, ce qui aurait entraîné un retour à la route d'origine. 

Ces republications se sont répétées plusieurs fois, provoquant une instabilité importante du routage. « La situation a évolué rapidement, provoquant une forte instabilité dans les tables de routage de l'Internet mondial », a déclaré Kemal Sanjta, analyste principal de l'Internet chez ThousandEyes, dans une analyse de la panne de Microsoft diffusée sur le Web. « En conséquence, on peut voir que de nombreux routeurs ont exécuté l'algorithme de sélection du meilleur chemin, ce qui n'est pas vraiment une opération bon marché du point de vue de la consommation d'énergie », a ajouté l’analyste. Plus important encore, les changements de routage ont provoqué d'importantes pertes de paquets, empêchant les clients d'accéder à Microsoft Teams, Outlook, SharePoint et d'autres applications. « Microsoft est passé d'un fournisseur de transit à l'autre de manière très volatile avant d'installer le meilleur chemin, et a répété l’opération, ce qui n'est jamais bon pour l'expérience client », a encore déclaré M. Sanjta.

Une circulation difficile

En plus de ces changements rapides dans les chemins de routage, le trafic a été déplacé à grande échelle à travers les réseaux des fournisseurs de transit, une opération difficile à absorber pour les fournisseurs de services qui explique les niveaux de perte de paquets documentés par ThousandEyes. « Compte tenu de la popularité des services de Microsoft comme SharePoint, Teams et d'autres services touchés dans le cadre de cet incident, il est très probable que les fournisseurs de transit ont reçu des quantités assez importantes de trafic quand celui-ci a été détourné vers eux », a expliqué M. Sanjta. Selon la technologie de routage utilisée par ces FAI - réseau SDN ou ingénierie de trafic MPLS activée par le protocole de contrôle de réseau RSVP – « toutes ces solutions ont nécessité un certain temps pour réagir à l'afflux d'une grande quantité de trafic. Et dans le cas où elles n'ont pas eu suffisamment de temps pour réagir à cet accroissement de paquets, certaines interfaces ont été débordées du fait de leur surutilisation, entraînant finalement des chutes de trafic ». L'importante perte de paquets consécutive « a été certainement constatée par les clients et s’est traduite par une expérience vraiment médiocre », a ajouté l’analyste de ThousanEyes. 

En ce qui concerne les perturbations de la connectivité, ThousandEyes a déclaré que la portée et la rapidité des changements indiquent une mauvaise décision dans l’administration, impliquant probablement une technologie d'automatisation, qui a provoqué une déstabilisation des routes mondiales vers les préfixes de Microsoft. « Compte tenu de la rapidité de ces changements dans la table de routage, nous pensons que certains de ces changements ont été causés par une action automatisée du côté de Microsoft », a déclaré M. Sanjta. « Essentiellement, nous pensons qu'une certaine automatisation s'est déclenchée, qu'elle a réagi de manière inattendue du point de vue de l'ingénierie du trafic, et que cela s'est répété plusieurs fois », a ajouté l’analyste. La majeure partie des interruptions de service a duré environ 90 minutes, même si ThousandEyes a déclaré qu’elle avait repéré des problèmes de connectivité résiduels le jour suivant.

Les explications de Microsoft

L’éditeur de Redmont a déclaré qu'il publierait un compte rendu final plus détaillé de l'incident, probablement dans les deux prochaines semaines, après avoir terminé son examen interne. D'après ce que Microsoft a déclaré jusqu'à présent, un changement de configuration du réseau a provoqué la panne, qu'elle a d'abord reconnue dans un tweet posté à 7h31 UTC sur le compte Microsoft 365 Status Twitter (@MSFT365Status) : « Nous enquêtons sur des problèmes ayant un impact sur plusieurs services Microsoft 365 ». 90 minutes plus tard environ, le compte Twitter a posté : « Nous avons isolé le problème de configuration du réseau, et nous étudions la meilleure stratégie d'atténuation pour y remédier sans causer d'impact supplémentaire ». Et à 9h26 UTC : « Nous avons annulé un changement de configuration sur le réseau qui, selon nous, provoque un impact. Nous surveillons le service pendant que l'annulation prend effet ». 

La firme a partagé davantage de détails dans une analyse préliminaire post-incident publiée via sa page d'état Azure. « Entre 07h05 UTC et 12h43 UTC le 25 janvier 2023, les clients ont rencontré des problèmes de connectivité réseau, se manifestant par une longue latence réseau et/ou des délais d'attente lors des tentatives de connexion aux ressources hébergées dans les régions Azure, ainsi qu'à d'autres services, notamment Microsoft 365 et Power Platform. Alors que la plupart des régions et des services étaient rétablis à 09h00 UTC, les problèmes de perte de paquets intermittents ont été complètement atténués à 12h43 UTC. Cet incident a également eu un impact sur les services cloud Azure Government qui dépendaient d'Azure public cloud ».

Mise à jour planifiée malencontreusement étendue 

Selon Microsoft, une modification apportée à son réseau WAN a eu un impact sur la connectivité : « Dans le cadre d'un changement planifié visant à mettre à jour l'adresse IP d'un routeur WAN, une commande donnée au routeur a entraîné l'envoi de messages à tous les autres routeurs du WAN, les incitant à tous recalculer leurs tables d'adjacence et de transfert. Pendant ce processus de recalcul, les routeurs n'étaient pas en mesure de transmettre correctement les paquets en transit. La commande à l'origine du problème a des comportements différents selon les périphériques réseau, et la commande n'avait pas été vérifiée à l'aide de notre processus de qualification complet sur le routeur sur lequel elle a été exécutée ».