La panne BGP de Cloudflare en 2022: un test de responsabilité opérationnelle

Résumé

• Le 21 juin 2022, Cloudflare indique qu’un changement de configuration réseau a provoqué une panne dans 19 centres de données utilisant son architecture Multi-Colo PoP. Ces emplacements représentaient environ quatre pour cent de son réseau, mais portaient une part importante du trafic. Cloudflare attribue environ la moitié des requêtes totales pendant l’incident au trafic affecté, tout en notant que l’impact utilisateur variait selon les emplacements.[1]
• Le changement prévu visait à normaliser les communautés BGP informatives sur des préfixes annoncés au niveau local du site. Sur les routeurs de la dorsale MCP, une réorganisation des termes de politique a placé un terme lié aux préfixes désactivés avant les termes qui devaient annoncer des routes site-local critiques pour les services. Le résultat a retiré ces préfixes.[1]
• Ce retrait a supprimé davantage qu’une simple joignabilité externe. Cloudflare indique que ses serveurs ne pouvaient pas communiquer normalement ni atteindre les origines clients, et que sa couche Multimog de répartition de charge ne pouvait plus déplacer les requêtes entre les clusters de calcul des MCP touchés. Les clusters plus petits ont alors reçu un trafic similaire à celui des plus grands et ont été surchargés.[1]
• Les ingénieurs ont aussi eu des difficultés à atteindre les emplacements touchés pour annuler le changement. Des procédures de secours ont dû être utilisées. Lors de la restauration, des ingénieurs ont parfois écrasé les réversions des autres, ce qui a fait réapparaître le problème de façon sporadique avant la reprise finale de la dernière localisation.[1]
• Le processus Cloudflare comprenait déjà un ticket de changement, un dry-run, une revue par les pairs et un déploiement étagé. La défaillance de contrôle était plus spécifique: aucune des premières étapes de déploiement n’exerçait un emplacement MCP. La première vérification représentative est arrivée lorsque l’étape finale a atteint toutes les spines MCP.[1]
• Les communautés BGP sont des métadonnées utilisées par la politique de routage. Elles ne prouvent pas qu’une politique d’export est correctement ordonnée ni que les préfixes requis restent annoncés. La validation d’origine RPKI vérifie si un AS d’origine est autorisé pour un préfixe; elle ne validerait pas cet ordre interne de termes, la sélection de canari ou la procédure de rollback.[10][11][12][14][15][16]
• L’exigence de responsabilité doit donc porter sur une preuve opérationnelle: la configuration candidate avant et après, un ensemble de préfixes requis vérifiable par machine, une simulation de politique de route, un canari spécifique au MCP, un comportement de commit-confirm, une connectivité de gestion indépendante, un propriétaire unique de rollback, des journaux de changement par localisation et des observations externes de routes conciliées avec les logs routeur.
• Les collecteurs de routes publics peuvent aider à établir les annonces et retraits visibles, mais ne peuvent pas révéler chaque préfixe privé site-local ni chaque décision de politique interne. Les données opérationnelles des opérateurs restent nécessaires.[17][18][19]
• Le registre public ne permet pas d’établir une intention malveillante, une négligence, une infraction réglementaire, chaque préfixe affecté, chaque client perdu, ou si toutes les corrections annoncées restent encore déployées. Ces limites doivent rester explicites.

Un changement examiné peut rester un changement non testé

Les organisations d’infrastructure utilisent souvent les étiquettes de processus comme raccourci pour des contrôles. Un changement a été saisi dans un ticket. Un dry-run a été achevé. Plusieurs ingénieurs l’ont revu. Le déploiement a été progressif. Chaque affirmation peut être vraie alors que le risque opérationnel demeure non testé.

Le récit de Cloudflare sur sa panne du 21 juin 2022 rend cette distinction particulièrement claire. Le changement a été validé par un ticket de demande de modification, incluait un dry-run, a reçu une revue par les pairs et a suivi une procédure de déploiement par étapes. Les premières étapes n’ont pas provoqué de panne. La défaillance est apparue lorsque le déploiement a atteint les 19 emplacements utilisant l’architecture Multi-Colo PoP, que Cloudflare appelait MCP. Aucune des étapes antérieures n’avait exercé un emplacement MCP.

La première étape représentative de la topologie de routage concernée était aussi l’étape qui a appliqué la configuration à toutes les spines MCP.[1]

Ce n’est pas un argument pour dire que tickets, revues, dry-runs ou stagings sont inutiles. Cela signifie que chaque contrôle doit être associé à une revendication précise. Un ticket enregistre une autorisation et une intention. Une revue enregistre que des personnes nommées ont examiné une représentation du changement. Un dry-run enregistre ce qu’un outil a calculé contre un modèle ou un état d’appareil spécifié. Un déploiement en étapes limite la portée seulement si chaque étape est représentative d’un domaine de défaillance distinct et suffisamment réduite pour s’arrêter avant la suivante.

La question de responsabilité n’est donc pas: «Le processus existait-il?». Elle est: «Qu’est-ce que chaque étape de processus prouve?». Lors de cet incident, les premières étapes ont prouvé que le changement ne perturbait pas les emplacements en ancienne architecture. Elles n’ont pas prouvé que la politique conserverait les annonces requises sur les spines MCP. Un résultat vert sur un emplacement non représentatif ne pouvait pas répondre à la question déterminante.

Ce point importe parce qu’une configuration de réseau est une autorité opérationnelle exécutable. Un terme de route-policy ne se contente pas de décrire où le trafic doit aller. Son ordre détermine quelles routes un routeur annonce ou retient. Une fois engagé, la configuration modifie le graphe de connectivité utilisé par les serveurs, les pairs, les origines, les opérateurs et les systèmes de reprise. La différence entre une addition de métadonnées sans impact et une panne majeure peut tenir à une branche de politique évaluée avant une autre.

Le rapport de Cloudflare ne doit pas être réduit au slogan d’une mauvaise configuration ayant causé une panne. La leçon utile est plus étroite et plus exigeante: les contrôles de changement doivent être liés à l’architecture, aux invariants de routes, aux domaines de défaillance et aux accès de reprise. Une procédure par étapes qui ignore l’architecture concernée peut donner l’apparence de prudence sans apporter de preuve sur le système qui peut réellement tomber en panne.

Le changement prévu était informatif; le changement effectif était la connectivité

Cloudflare a indiqué que l’objectif était de standardiser les communautés BGP attachées à un sous-ensemble de préfixes annoncés, en ajoutant spécifiquement des communautés informatives aux préfixes site-local. Les communautés BGP sont des attributs que les opérateurs utilisent pour étiqueter des routes et influencer la politique de routage. La spécification des communautés standard définit un moyen de regrouper des destinations afin que les décisions de routage puissent s’appliquer à une classe de routes plutôt qu’à un préfixe unique. Les Large Communities étendent le format pour les besoins opérationnels modernes.[1][11][12]

Les ajouts prévus n’étaient pas décrits comme une tentative de retirer des routes de service. Cloudflare les a qualifiés d’informations inoffensives sur les routeurs standards présentés dans son rapport. La conséquence notable est apparue sur les spines routeurs MCP. Un diff de configuration a réordonné des termes dans une politique d’export agrégée. Un terme lié aux préfixes désactivés est passé avant des termes qui annonçaient des routes site-local pour les services et fonctions internes. Comme les termes de politique sont évalués séquentiellement, la correspondance antérieure a empêché la logique d’annonce suivante de s’exécuter.[1]

C’est la différence entre l’intention sémantique et le comportement effectif. L’auteur d’un changement peut vouloir attacher des métadonnées. Un réviseur peut voir des ajouts de communautés. Un ticket peut porter le titre "standardize communities". Aucune de ces représentations ne commande au routeur. Le routeur évalue la politique résultante dans l’ordre. Si la configuration générée ou rendue change cet ordre, l’effet opérationnel est celui que le moteur de politique exécute.

Le BGP fournit lui-même le mécanisme de connectivité. Les réseaux annoncent des préfixes pour signaler aux pairs que des adresses sont joignables via un chemin. Ils retirent des routes quand cette connectivité n’est plus disponible ou ne doit plus être annoncée. Un préfixe retiré peut disparaître de chemins sélectionnés, rendant les adresses associées injoignables via ce chemin. La spécification BGP-4 définit ces sémantiques d’annonce et de retrait; elle ne connaît pas l’intention business d’un terme de politique donné.[10]

Cette distinction crée une exigence de preuve. L’approbation d’un changement doit être liée à la configuration candidate exacte que le routeur évaluera, pas seulement à une demande de niveau supérieur ou à un modèle généré. Le dossier de revue doit montrer:

1. La politique rendue exacte avant et après le changement.
2. L’ordre d’évaluation de chaque terme concerné.
3. L’ensemble des routes attendues comme acceptées, rejetées, annoncées et retirées.
4. L’origine de chaque préfixe dans cet ensemble.
5. Les rôles d’appareil et les architectures sur lesquelles la politique s’exécutera.
6. Une simulation ou un résultat de laboratoire avec des routes représentatives.
7. Les chemins de gestion et de rollback qui restent joignables si la sortie de politique est erronée.

Sans ces liens, la revue peut vérifier la demande tout en manquant l’effet compilé. La responsabilité de l’infrastructure suit la configuration consommée par le système en production.

Les préfixes site-local faisaient partie du chemin de service

Le terme "site-local" peut sembler secondaire, comme si les routes affectées n’étaient que des entrées de maintenance sans conséquence client. Le rapport de Cloudflare montre le contraire. Ces préfixes permettaient la communication entre ses machines et autorisaient les serveurs à atteindre les origines clientes. Leur retrait a interrompu ces chemins.[1]

Cloudflare a également lié ces préfixes à Multimog, un système interne d’équilibrage de charge utilisé dans les emplacements MCP. Multimog ne pouvait plus acheminer les requêtes entre les serveurs des MCP car la connectivité nécessaire avait disparu. Des clusters de tailles différentes ont alors reçu des charges similaires. Les clusters plus petits ont été surchargés.[1]

Ce mécanisme est important parce qu’il explique pourquoi un sous-ensemble de retraits de routes peut avoir un effet de service bien plus large que ne suggère le simple comptage des préfixes manquants. Un préfixe peut soutenir une dépendance partagée par de nombreux services. S’il transporte une connectivité d’origine, une communication inter-cluster interne ou un chemin d’équilibrage de charge, son retrait modifie la répartition du travail dans le système. Un service peut encore recevoir du trafic en bordure tout en perdant les routes internes nécessaires pour traiter ou transférer ce trafic en sécurité.

L’événement teste la façon dont un opérateur classe la criticité des routes. Un registre des préfixes ne doit pas s’arrêter à la propriété ou à l’autorisation d’origine. Il doit enregistrer le rôle opérationnel:

• Le préfixe est-il orienté vers Internet, réservé à la gestion, site-local, orienté origine client ou inter-cluster?
• Quels routeurs et politiques l’annoncent?
• Quels services en dépendent?
• Quels contrôles de surveillance prouvent qu’il est joignable?
• Quelles localisations partagent le même modèle de politique?
• Que se passe-t-il si la route disparaît alors que le trafic entrant continue?
• L’accès de gestion utilise-t-il la même famille de routes ou la même politique?
• Quel chemin alternatif est censé porter la dépendance?

Ce registre n’est pas souverain sur le réseau. Il ne crée pas une route. Il crée un registre consultable de l’état attendu. Les opérateurs peuvent le comparer à la base d’informations de routage, à la base d’informations de transfert, aux collecteurs externes, aux sondes actives et aux résultats de service. Un registre exact, unique, contrôlé par changements et lié à un comportement observé rend un retrait détectable avant que les clients deviennent le système de détection.

L’effet Multimog montre aussi pourquoi la capacité a besoin d’un contexte de topologie. Cloudflare a indiqué que les emplacements MCP touchés contenaient des clusters de tailles différentes. Quand le transfert interne a échoué, les plus petits clusters ont reçu un trafic similaire aux plus gros. Un tableau de capacité affichant la capacité totale d’un site pouvait donc surestimer la capacité réellement exploitable. La défaillance de route retirait le mécanisme de répartition qui rendait cette capacité agrégée accessible.

Une revue fondée sur la preuve poserait aussi la question: chaque MCP disposait-il d’un mode dégradé testé? Pouvait-on drainer le trafic vers l’extérieur quand Multimog perdait la connectivité site-local? Les plus petits clusters pouvaient-ils se protéger via des contrôles d’admission? Le canari de politique de route incluait-il des sondes sur l’accès d’origine, le transfert inter-cluster et l’accès de gestion, et pas seulement la santé des sessions BGP? Le rapport public identifie la dépendance, mais ne publie pas chaque contrôle protecteur.

19 emplacements révélaient une concentration dans un réseau distribué

Cloudflare a indiqué que les 19 emplacements MCP représentaient environ quatre pour cent de son réseau alors que la panne affectait environ 50 pour cent des requêtes totales. Il a également souligné que l’impact variait selon la géographie: certains utilisateurs ne pouvaient pas atteindre des propriétés utilisant Cloudflare, tandis que d’autres emplacements continuaient de fonctionner normalement.[1]

Ces chiffres doivent rester attribués et ne doivent pas être convertis en nombre de personnes, clients, sites web ou pertes financières. Ils appuient une leçon de topologie. Un réseau peut être géographiquement distribué alors que le trafic reste concentré sur un petit ensemble d’emplacements à haute capacité. Le nombre d’emplacements n’est pas équivalent à la part de trafic, aux dépendances clients, à la capacité de peering ou à la connectivité d’origine qu’ils transportent.

Le programme MCP visait à améliorer la résilience dans les emplacements les plus chargés. Cloudflare a décrit une architecture de type Clos avec une couche de routage additionnelle et un maillage de connexions spine. L’architecture permettait d’activer ou de désactiver des parties d’un réseau interne pour la maintenance ou la gestion de pannes. Ce sont des objectifs de résilience légitimes. L’incident n’établit pas que l’architecture était intrinsèquement défaillante.[1]

Il montre toutefois qu’un chemin de politique commun peut connecter des emplacements physiquement séparés. Si la même politique de route rendue atteint toutes les spines MCP dans une seule étape finale, le modèle de politique devient un domaine commun de défaillance. La diversité physique ne supprime pas cette dépendance de contrôle partagée.

C’est un schéma récurrent de responsabilité réseau. Les opérateurs peuvent disposer de plusieurs routeurs, infrastructures, opérateurs d’accès et chemins, mais une seule automatisation de modèle, un système d’identifiants, une politique de route, un contrôleur ou une étape de déploiement peuvent encore créer une défaillance en mode commun. La diversité doit être mesurée à la surface de contrôle qui a provoqué l’incident.

Pour un déploiement MCP, une cartographie utile comprendrait:

Ce tableau évite qu’une première étape à faible risque soit confondue avec une étape représentative. Un canari doit être petit, mais doit exercer la fonction et l’architecture réellement modifiées. Si le seul site représentatif transporte trop de trafic pour servir de canari, c’est déjà une faiblesse opérationnelle et architecturale qui requiert un jumeau de laboratoire, une évaluation en shadow, un domaine représentatif plus petit ou des invariants statiques plus stricts avant la production.

Perdre la connectivité de gestion a transformé le problème de reprise

Cloudflare a dit que le retrait de route a rendu plus difficile l’accès des ingénieurs aux emplacements touchés et l’annulation de la configuration. Des procédures de secours ont été utilisées pour reprendre la main.[1]

Ce point appartient au centre de l’analyse. Un changement réseau n’est pas réversible en toute sécurité simplement parce qu’une commande de rollback existe. L’opérateur doit encore pouvoir s’authentifier, atteindre l’appareil, déterminer l’état correct et coordonner le rollback alors que le réseau est dégradé. Si le trafic de gestion dépend des routes modifiées, le chemin de reprise partage le domaine de défaillance.

Un accès indépendant n’exige pas nécessairement un réseau global séparé pour chaque appareil. Il exige une conception raisonnée qui survive à la défaillance testée. Les options peuvent inclure des serveurs de console sur un réseau de gestion routé séparément, des liens carrier hors bande, une automatisation locale capable d’exécuter un rollback chronométré, des fonctions commit-confirm de dispositif, un accès terminal sécurisé, ou un canal de contrôle dont la connectivité ne dépende pas de la politique candidate.

Chaque option a des limites. Un carrier hors bande peut partager une installation ou une alimentation. Un serveur console peut dépendre du même fournisseur d’identité ou du même service DNS. Un minuteur commit-confirm peut être annulé trop tôt ou ne pas restaurer l’état dépendant complet. L’automatisation locale peut appliquer une mauvaise base. La responsabilité opérationnelle exige des exercices prouvant que le chemin choisi fonctionne sous la condition de perte exacte.

Le test pertinent pour cet incident est simple: retirer ou supprimer l’ensemble de routes qui fournit la connectivité site-local et de gestion ordinaire dans un environnement MCP représentatif, puis vérifier que les opérateurs peuvent encore inspecter l’état et restaurer la configuration approuvée. L’exercice doit mesurer le temps d’accès, le temps d’identification de l’invariant défaillant, le temps de démarrage du rollback, le temps de restauration des annonces requises et le temps de confirmation de reprise de service.

Une capture d’écran d’une connexion réussie un jour normal ne suffit pas. L’essai doit retirer la dépendance qui a échoué. Une preuve en environnement opérationnel a plus de poids qu’un schéma qui libellé "sortie de bande".

Le rapport public n’identifie pas chaque procédure de secours utilisée par Cloudflare, ce qui est compréhensible pour des raisons de sécurité et d’exploitation. La topologie sensible et les identifiants ne doivent pas être publiés. Une organisation peut toutefois conserver des preuves auditables sous contrôle: horodatages d’exercice, étendues d’appareil, attestations indépendantes, sondes de route, critères de succès et exceptions.

L’autorité de rollback a échoué comme contrôle de coordination

La chronologie de Cloudflare indique que les réversions finales ont été retardées parce que des ingénieurs réseau ont écrasé les changements des autres. Certaines réversions ont annulé des réversions précédentes, ce qui a causé la réapparition sporadique du problème.[1]

Ce n’est pas seulement une note de faute humaine. Cela révèle une propriété de sérialisation manquante dans la réponse à incident. En cas de panne à fort impact, plusieurs ingénieurs peuvent avoir un accès légitime et des raisons solides d’agir. Si le système de modification ne fournit pas un état cible d’autorité unique, une propriété visible, des verrous par appareil et un journal partagé de progression, les travaux parallèles peuvent provoquer des oscillations.

La leçon opérationnelle n’est pas qu’une seule personne doit réagir à chaque fois. L’investigation, l’observation de route, la communication client, les tests de service et la préparation du rollback peuvent avancer en parallèle. La mutation du même état de routage doit être coordonnée. Le système doit rendre difficile qu’un technicien réintroduise la configuration qu’un autre vient d’enlever.

Des contrôles utiles incluent:

• Un incident commander déclaré et un propriétaire réseau de changement.
• Un commit de destination de reprise gelé.
• Des verrous par appareil ou par domaine de politique pendant le rollback.
• Un orchestrateur unique enregistrant chaque tentative et rollback terminé.
• Des minuteurs commit-confirm qui restaurent automatiquement l’état antérieur si la confirmation de gestion est perdue.
• Des observateurs en lecture seule qui vérifient la reprise des routes et du service sans modifier la configuration.
• Une règle selon laquelle les changements manuels d’urgence sont réconciliés dans la configuration d’autorité avant la reprise de l’automatisation normale.
• Une transmission explicite des responsabilités quand la propriété change entre équipes ou régions.

Ces contrôles doivent produire un registre par emplacement. Pour chaque MCP, le dossier doit indiquer l’identifiant de la mauvaise configuration, la commande ou le commit de rollback, l’exécuteur, l’heure de début et de fin, l’accusé réception appareil, le résultat de la table de routes, la connectivité de gestion, la sonde de service et toute modification ultérieure touchant la même politique. Le registre rend les interférences visibles et soutient une déclaration fiable de récupération du dernier site.

La remédiation de Cloudflare a inclus un rollback commit-confirm automatisé et une meilleure application de l’espacement/staging.[1] Un mécanisme commit-confirm est particulièrement pertinent quand un changement de route peut retirer l’accès de gestion. Le routeur peut restaurer automatiquement l’état antérieur sauf si l’opérateur confirme le nouvel état après la validation de la connectivité et des invariants.

Le commit-confirm n’est pas magique. Le délai doit être suffisamment long pour les validations, mais assez court pour limiter l’impact. L’état antérieur lui-même doit être sûr. La confirmation ne doit pas être automatisée uniquement sur un signal faible. Les changements multi-appareils exigent des sémantiques coordonnées afin qu’un routeur ne revienne pas en arrière tandis qu’un autre reste candidat. Le mécanisme demande encore des exercices et de la preuve.

Le processus existait; ses obligations de preuve étaient incomplètes

Le rapport de Cloudflare dit explicitement que le changement avait un ticket, un dry-run, un déploiement progressif et plusieurs réviseurs pairs.[1] Cela rend l’incident utile pour les organisations qui disposent déjà d’un vocabulaire de gestion des changements mature.

Une réponse postmortem faible ajouterait une autorisation supplémentaire. Plus de signatures peuvent ralentir la livraison sans tester la condition manquante. Les preuves pointent vers quatre questions plus fortes.

Premièrement, quelles entrées le dry-run a-t-il utilisées? Si la politique rendue a été calculée pour une ancienne architecture, il ne pouvait pas révéler l’effet d’ordre de termes MCP. Un dry-run devrait inclure chaque rôle de politique affecté par la logique de génération, notamment les rôles avec des modèles différents ou une héritabilité distincte.

Deuxièmement, quelles assertions le dry-run a-t-il évaluées? Une configuration syntaxiquement valide peut encore retirer des préfixes requis. La validation doit comparer les sorties de route, pas seulement les résultats de parsing. L’outil devrait échouer si des préfixes site-local, de gestion, orientés origine ou de service changeaient de manière inattendue.

Troisièmement, comment les groupes de déploiement ont-ils été définis? L’ordre géographique seul ne détecte pas une panne propre à l’architecture si toutes les phases précoces utilisent l’ancienne conception. Les groupes devraient refléter le matériel, le logiciel, la topologie, le rôle de politique, la version du plan de contrôle, la part de trafic et le chemin de gestion.

Quatrièmement, qu’est-ce qui a arrêté la progression? Un déploiement étagé est efficace seulement s’il prévoit des fenêtres d’observation explicites et des gates automatiques. Le système a besoin d’une preuve que le canari conservait routes requises, connectivité d’origine, équilibrage interne, accès de gestion et succès de service avant de passer au groupe suivant.

La revue entre pairs a des obligations similaires. Les réviseurs doivent disposer du diff rendu pour tous les rôles, des sorties de route attendues, d’une matrice de canari, d’un plan de rollback et d’une preuve que le chemin de reprise est indépendant. Demander aux réviseurs d’inférer cela depuis un ticket de haut niveau réintroduit la même lacune.

L’objectif n’est pas une perfection bureaucratique. Il s’agit de lier le processus au mécanisme de défaillance. Pour une politique BGP, la revendication opérationnelle est que les préfixes spécifiés restent annoncés aux pairs spécifiés pendant que les attributs voulus changent. Cette revendication peut être testée mécaniquement.

Les invariants de route transforment l’intention en test

Un invariant de route est une assertion qui doit rester vraie avant, pendant et après un changement. Les exemples incluent:

• Chaque spine MCP annonce le jeu approuvé de préfixes site-local.
• Les préfixes de gestion restent joignables depuis des points d’accès indépendants désignés.
• Les sondes de connectivité d’origine client réussissent depuis chaque cluster de calcul.
• L’équilibrage interne peut déplacer des requêtes entre des clusters de tailles différentes.
• Aucun préfixe public inattendu n’est annoncé.
• Aucun préfixe protégé n’est retiré.
• Le nombre et les attributs des routes modifiées correspondent au périmètre de changement approuvé.

L’ensemble de préfixes requis doit provenir d’un registre opérationnel exact, lié à la propriété de service. Il ne devrait pas s’agir d’une liste informelle copiée dans un ticket unique. Identité du préfixe, rôle, origine, pairs attendus, métadonnées de sécurité et historique des changements nécessitent une propriété durable.

Avant validation, une simulation de politique peut évaluer le candidat contre des routes et contextes de pairs représentatifs. Après un commit canari, le système peut comparer la table d’informations de route du routeur et la vue de routes annoncées avec l’invariant. Des sondes actives peuvent tester les chemins de service. Les collecteurs externes peuvent fournir une vue séparée des annonces publiques.[17][18][19]

La comparaison doit distinguer les changements attendus des changements inattendus. Si le but est d’ajouter des communautés, la présence de route doit rester stable tandis que les attributs évoluent dans le jeu approuvé. Un retrait de préfixes site-local requis devient alors un échec immédiat de la gate, pas un symptôme en attente d’erreurs HTTP globales.

Les invariants de route améliorent aussi la communication en incident. Plutôt que d’annoncer que "le réseau se rétablit", les opérateurs peuvent déclarer que les annonces requises sont restaurées dans un nombre défini de localisations, que la connectivité de gestion est revenue, que le transfert interne passe, et que le succès des requêtes clients reste dans une fourchette établie. Chaque affirmation a une preuve et une limite.

Il existe un risque de fausse confiance. L’ensemble d’invariants peut être incomplet. Une route peut être présente mais forwarder incorrectement. Une vue plan de contrôle peut différer de la data plane. C’est pourquoi les contrôles de route doivent être associés à des sondes de forwarding et de service. La suite de tests doit être mise à jour quand un incident révèle une dépendance non représentée.

Les communautés BGP n’ont pas causé la panne à elles seules

Il serait inexact de résumer l’incident par: "les communautés BGP ont cassé Cloudflare." Les communautés sont des métadonnées attachées aux routes. Les opérateurs les utilisent pour la politique, le marquage, l’ingénierie de trafic et la signalisation opérationnelle. Les RFC 1997 et RFC 8092 définissent les formats de communautés; elles ne dictent pas l’ordre de politique de Cloudflare.[11][12]

Les ajouts de communautés faisaient partie du contexte de changement. Le mécanisme de panne était l’ordre effectif des termes de politique sur les spines MCP et le retrait consécutif de préfixes site-local requis.[1] La distinction compte car la remédiation doit cibler le contrôle défaillant et non stigmatiser un mécanisme standard.

Les communautés peuvent améliorer la responsabilisation quand leur signification est documentée, unique et appliquée de manière cohérente. Elles peuvent identifier des classes de route, le traitement attendu, l’état de maintenance, la géographie ou la relation client. Mais ces labels n’ont de valeur que si l’évaluation de politique préserve le résultat requis. Une communauté indiquant "site local" ne maintient pas une route annoncée quand un terme antérieur la rejette.

Le même principe s’applique aux noms de changements et commentaires. Les libellés lisibles par humain soutiennent la revue, mais c’est la politique d’exécution qui détermine la connectivité. Un opérateur doit pouvoir tracer d’une définition de communauté jusqu’à l’ensemble de routes, les branches de politique, les annonces attendues et les résultats observés. Si la trace s’arrête à la documentation, la preuve opérationnelle est incomplète.

RPKI est important, mais pas la réparation directe

RPKI permet d’associer des ressources IP à des AS d’origine autorisés. La validation d’origine de route permet à un routeur de classer une annonce selon que l’origine et la longueur du préfixe sont cohérentes avec une Route Origin Authorization. La RFC 6480 décrit l’architecture et la RFC 6811 décrit la validation d’origine.[15][16]

Ces contrôles abordent une question différente de la panne de juin 2022. RPKI peut aider à déterminer si l’AS de Cloudflare était autorisé à annoncer un préfixe public. Elle ne détermine pas si un terme d’export interne devrait annoncer un préfixe site-local, si les termes sont correctement ordonnés, si un canari MCP est représentatif ou si l’accès de rollback est indépendant.

Une route autorisée peut être retirée accidentellement. Une origine valide ne prouve pas la disponibilité. À l’inverse, une route site-local interne peut ne jamais être visible dans un RPKI public ni dans des collecteurs externes. Présenter RPKI comme une correction universelle obscurcirait la vraie défaillance de contrôle.

RPKI doit pourtant figurer dans le modèle de preuve parce que l’autorisation des ressources réseau, la politique de route et la continuité opérationnelle interagissent. Un opérateur doit maintenir des enregistrements de ressources précises et des métadonnées de sécurité, tout en validant séparément le comportement de politique et la connectivité de service. L’intégrité du registre et la preuve de code en exécution sont complémentaires, pas substituables.

Cette frontière est aussi utile pour la responsabilité publique. Un postmortem peut préciser si un incident relève de l’autorisation d’origine, d’une fuite de route, d’un détournement, d’un retrait de politique interne ou un autre mécanisme de routage. Une classification précise évite de traiter chaque événement BGP de la même manière et soutient la bonne remédiation.

Les observations externes de route sont utiles mais incomplètes

RIPE NCC’s Routing Information Service collecte des données BGP de pairs, et RIS Live expose des flux de mises à jour. BGPStream de CAIDA fournit des outils pour travailler avec des données de routage issues de nombreux collecteurs. Ces systèmes aident les chercheurs et opérateurs à observer annonces, retraits, changements de chemins et restauration visibles depuis les points de vue entités.[17][18][19]

Pour un incident sur préfixes publics, les observations externes peuvent répondre à des questions importantes:

• Quand un préfixe a-t-il disparu de collecteurs sélectionnés?
• Quels pairs ou régions ont observé le retrait?
• Quand les annonces sont-elles revenues?
• Les chemins ou attributs ont-ils changé après restauration?
• L’événement correspond-il à la chronologie publique de l’opérateur?

Le postmortem de juin 2022 concerne également les préfixes site-local et le comportement interne MCP, en plus de la panne de service observée publiquement. Les collecteurs publics peuvent ne pas voir toutes les routes pertinentes. Ils n’exposent pas les termes de politique privés, les configurations candidates de routeur, la connectivité de gestion interne ou l’état de Multimog. L’absence d’un signal externe ne prouve pas la santé du système privé.

Cette limite ne doit pas servir à rejeter la preuve externe. Elle définit la tâche de réconciliation. Les opérateurs peuvent conserver logs routeurs, commits de configuration, instantanés de routes annoncées, résultats de sondes actives et télémétrie de service. Les collecteurs publics offrent une couche indépendante. Un relevé crédible indique où les vues concordent, où la visibilité diffère, et pourquoi.

La preuve devrait être horodatée avec une horloge cohérente. Mises à jour de routage, commits de configuration, déclarations d’incident, réversions, sondes de connectivité et erreurs client peuvent autrement paraître désordonnées. La synchronisation temporelle et les logs immuables sont des contrôles de responsabilité car ils préservent la séquence nécessaire à l’évaluation de la réponse.

Les chiffres d’impact ont leurs propres frontières

Cloudflare a dit que les 19 emplacements MCP représentaient environ quatre pour cent de son réseau, mais que la panne affectait 50 pour cent des requêtes totales. La société a aussi publié un graphe de volume de requêtes et une vue de bande passante sortante.[1]

Les chiffres montrent une concentration de trafic sur des sites à haute capacité. Ils n’établissent pas que la moitié de tous les internautes, de tous les clients Cloudflare ou de tous les sites web était entièrement indisponible. Le trafic de requêtes n’est pas un décompte de population. Certains emplacements ont continué à fonctionner normalement, et les effets clients dépendaient de la géographie et du chemin de service.

Un compte d’impact responsable doit distinguer:

• Les requêtes qui ont échoué.
• Les requêtes retardées ou retentées.
• Les localisations qui ont perdu les routes requises.
• Les clusters qui ont été surchargés.
• Les origines client devenues injoignables depuis les sites touchés.
• Les services qui ont continué depuis des localisations non affectées.
• Le temps vers la première reprise et le temps jusqu’au rollback final.
• Les erreurs résiduelles après restauration de route.

Le rapport public fournit de solides informations sur plusieurs de ces dimensions mais pas un inventaire complet par client. L’article ne doit pas fabriquer une précision inexistante.

Pour les incidents futurs, un opérateur peut améliorer la transparence en publiant dénominateurs et incertitudes. Si 50 pour cent des requêtes ont été affectées, il faut définir l’intervalle de mesure, le critère de succès, le traitement des retrys, la géographie et si le chiffre inclut le trafic redirigé vers d’autres sites. Des métriques claires permettent aux clients de comparer cette déclaration à leurs propres logs.

La responsabilité suit le contrôle, pas l’exposition de marque

Cloudflare contrôlait la politique de route, la procédure de déploiement, le groupement MCP, le périmètre du dry-run, les matériaux de revue, l’accès de gestion, l’automatisation et la coordination de rollback. Son postmortem admet que la panne était son erreur et non une attaque.[1] Ces faits font de Cloudflare l’opérateur central dans l’analyse de responsabilité.

Cela ne signifie pas que chaque conséquence soit juridiquement attribuable ou que chaque ingénieur ait partagé la même responsabilité. Le registre public ne prouve pas la faute individuelle ni la négligence. La gouvernance doit associer les contrôles aux équipes et systèmes:

• Le propriétaire de l’architecture réseau a défini les rôles et domaines de défaillance MCP.
• Le propriétaire de politique a défini les termes d’export et la gestion des communautés.
• Le propriétaire d’automatisation a généré et distribué la configuration.
• Le propriétaire de changement a sélectionné les étapes et fenêtres d’observation.
• Les réviseurs ont évalué les éléments de preuve fournis.
• L’incident commander a coordonné la reprise.
• Les équipes appareil et plateforme ont fourni rollback et mécanismes commit-confirm.
• Les équipes de service ont surveillé l’atteinte d’origine, Multimog, la charge des clusters et les requêtes clients.
• La direction a défini une concentration de trafic acceptable et le risque de changement.

Les fournisseurs de routeurs et logiciels influencent les mécanismes de sécurité disponibles, mais le rapport public de Cloudflare n’attribue pas la réorganisation des termes à un défaut de fournisseur. Les instances de normes définissent le comportement des protocoles, mais n’exploitent pas les politiques de Cloudflare. Les clients s’appuyaient sur le service et ne contrôlaient pas la configuration interne site-local des routes.

Les clients conservent une responsabilité sur leur architecture de dépendance. Une organisation dont un service public dépend d’un chemin CDN ou DNS d’autorité doit comprendre cette dépendance, tester des accès alternatifs lorsque cela est possible et définir une communication quand le fournisseur devient injoignable. Cette responsabilité ne transfère pas le contrôle des routeurs Cloudflare au client, ni ne rend toute dépendance évitable.

Régulateurs et grands acheteurs peuvent demander des preuves sans imposer des topologies sensibles. Ils peuvent demander si le fournisseur applique des canaris représentatifs de l’architecture, des invariants de route, un accès de gestion indépendant et une restitution sérialisée. Les contrats peuvent définir la divulgation et la preuve de reprise. Ils devraient éviter d’exiger des configurations privées en public quand une revue protégée peut servir l’objectif.

Un dossier de preuves opérationnel

La clôture post-incident la plus solide n’est pas l’assurance que l’exacte même erreur ne se reproduira pas. C’est un dossier borné montrant ce qui a changé et comment les nouveaux contrôles fonctionnent.

Ce dossier sépare les enregistrements de la preuve opérationnelle. Un registre de préfixes est utile car il préserve l’unicité, la propriété, le rôle, les pairs attendus, les métadonnées de sécurité et l’historique des changements. Il n’est pas l’autorité qui fait transiter les paquets. La simulation de politique est utile car elle prédit le comportement; le canari et l’état de route en direct ont encore besoin d’être observés. Un postmortem public est utile car il décrit l’événement; il ne prouve pas que chaque engagement ultérieur reste actif.

Les détails sensibles peuvent être protégés. Les adresses de gestion exactes, identifiants, topologie et configuration de routeur peuvent créer un risque de sécurité s’ils sont publiés. Des auditeurs indépendants, régulateurs ou clients sous confidentialité peuvent les examiner. La divulgation publique peut résumer les résultats de contrôle, les jalons et les limites non résolues.

Les frontières de comparaison comptent

Cloudflare a connu d’autres incidents de routage et de configuration. Les traiter comme une seule panne générique fragiliserait l’analyse.

L’événement de juin 2019 concernait une fuite externe de route. Ce n’est pas la panne MCP de 2022.

La panne de juillet 2020 était une panne de règles routeur. Son mécanisme direct diffère de l’événement MCP de 2022 lié au retrait de préfixes site-local.

L’événement de mars 2025 impliquait un ROA défectueux. Les routes 2022 étaient retirées par politique interne; le registre public ne décrit pas de ROA défectueux comme cause.

La panne de fonctionnalité 2025 de Cloudflare n’était pas un événement de politique d’export BGP.

Ces cas partagent une leçon abstraite: de petites entrées de contrôle peuvent acquérir une portée globale. Les preuves et réparations spécifiques diffèrent. La responsabilité réseau exige de nommer le protocole, la couche, l’autorité, le chemin de propagation et la limite de reprise qui ont réellement échoué.

Ce que le registre public ne prouve pas

Le postmortem de Cloudflare est détaillé, mais il s’agit d’un récit de première partie. Il fournit la source publique la plus solide sur le mécanisme et la chronologie, tout en laissant des éléments matériels privés.

Le registre public ne divulgue pas tous les préfixes retirés, les configurations complètes de routeur, le ticket de changement intégral, les commentaires des réviseurs, le code d’automatisation, la topologie privée ou la conception d’accès de gestion, ni l’ensemble des dépendances de service. Il ne montre pas l’ensemble complet du RIB ou de l’état de forwarding pour chaque appareil.

Les graphiques publics de trafic ne permettent pas d’identifier chaque client affecté, utilisateur, type de requête, origine ou conséquence financière. L’article ne doit pas inférer de crédits de service, de revenus perdus, de pénalités réglementaires ou de négligence client.

Le postmortem indique que l’incident était l’erreur de Cloudflare et non une attaque. Il n’établit pas une intention malveillante, une dissimulation, une conduite criminelle ou une faute individuelle. Il n’établit pas non plus, à lui seul, un standard juridique de diligence.

La section remédiation annonce un travail planifié et immédiat. Elle ne prouve pas que chaque canari spécifique MCP, chaque refonte de politique, chaque automatisation d’étagement ou mécanisme commit-confirm reste déployé et efficace aujourd’hui. La documentation actuelle peut expliquer l’architecture et les contrôles, mais elle ne doit pas être traitée comme preuve de l’état exact de 2022.

RIPE NCC et BGPStream peuvent fournir des observations routage indépendantes, mais les preuves publiques disponibles ne donnent pas une reconstruction complète en collecteur de chaque retrait de site-local. La visibilité externe a des limites.

Ces inconnues n’empêchent pas l’analyse de responsabilité. Elles définissent les questions auxquelles les détenteurs de preuve doivent répondre et évitent de transformer un postmortem technique en accusation non supportée.

Questions pour opérateurs, conseils, clients et auditeurs

Les opérateurs réseau devraient demander:

• Quelles politiques de route diffèrent selon l’architecture ou le rôle du routeur?
• Le dry-run rend-il tous les rôles affectés?
• Quels préfixes doivent rester annoncés pendant le changement?
• Les listes de préfixes requis sont-elles versionnées, détenues et liées aux dépendances de service?
• Le simulateur de politique évalue-t-il des routes et un ordre de termes représentatifs?
• Le premier canari est-il petit et représentatif de l’architecture?
• Quelle fenêtre d’observation et quel gate automatique stoppent la progression?
• Les opérateurs peuvent-ils atteindre les appareils après suppression des routes de gestion ordinaires?
• Le commit-confirm restaure-t-il un état multi-appareils cohérent?
• Qui possède la mutation lors d’un rollback d’incident?
• Des équipes en lecture seule peuvent-elles observer routes et service sans modifier la configuration?

Les conseils et comités de risque devraient demander:

• Quelle part du trafic dépend du domaine de contrôle commun le plus chargé?
• La distribution géographique masque-t-elle une dépendance commune de politique ou d’automatisation?
• Quelles dépendances de gestion, identité, DNS, énergie et transport sont partagées entre les chemins primaire et de reprise?
• Quels éléments de preuve démontrent des exercices récurrents plutôt qu’une correction ponctuelle?
• Comment les métriques d’impact client sont-elles définies et conciliées avec les preuves de route et de service?

Les clients devraient demander:

• De quels services dépendent leur accès via Cloudflare (reachability, DNS, CDN, sécurité, accès, origine)?
• Une communication critique peut-elle continuer si le fournisseur et son statut deviennent indisponibles?
• Des fournisseurs alternatifs ou des chemins vers l’origine directe sont-ils techniquement et opérationnellement testés?
• Quels compromis de sécurité découlent d’un basculement ou d’un contournement?
• Quels journaux établissent l’impact propre du client sans supposer une panne universelle?

Les réviseurs et auditeurs devraient demander:

• Ont-ils inspecté la politique exacte rendue, et pas seulement la demande?
• Le canari correspondait-il à la topologie MCP et à la politique de spine?
• Les routes site-local et de gestion figuraient-elles dans les invariants?
• Les mesures indépendantes et les logs routeur étaient-elles cohérentes?
• Deux ingénieurs pouvaient-ils réécrire les réversions mutuellement?
• Chaque correction est-elle associée à un test courant et un registre d’exceptions?

Ces questions ne présupposent pas qu’une panne à zéro soit possible. Elles testent si une classe connue d’erreur de routage est bornée, observable et récupérable.

Conclusion: une étape n’est aussi fiable que le système qu’elle représente

La panne de Cloudflare en juin 2022 a commencé par un changement réseau contrôlé. Le changement avait un ticket, un dry-run, une revue par pairs et plusieurs étapes de déploiement. Il a quand même retiré des préfixes site-local critiques en atteignant une architecture MCP que les étapes initiales n’avaient pas exercée. Le retrait a rompu la connectivité serveur et origine, désactivé la redistribution interne de charge, surchargé les plus petits clusters et compromis le chemin de gestion nécessaire à la récupération. Des réversions concurrentes ont ensuite provoqué des réapparitions sporadiques.[1]

L’incident a fait du déploiement réseau BGP un test de responsabilité. Une étape n’est pas une preuve parce qu’elle précède une autre étape. Elle doit représenter la topologie pertinente, le rôle de politique, le logiciel, les entrées de route, la concentration de trafic et la dépendance de gestion. Ses critères de réussite doivent inclure les routes et services qui doivent rester disponibles.

Le modèle de remédiation est concret. Lier l’approbation à la configuration rendue. Maintenir un registre exact des préfixes requis et de leurs rôles opérationnels. Simuler la sortie de politique. Utiliser un canari spécifique MCP. Observer annonces, forwarding, connectivité d’origine, équilibrage interne et accès de gestion. Protéger le rollback avec commit-confirm et un propriétaire de changement d’autorité unique. Réconcilier les journaux privés routeur avec des mesures publiques indépendantes quand la visibilité le permet.

Les communautés BGP, RPKI, collecteurs de routes, tickets et schémas contribuent à la preuve. Aucune ne remplace le résultat opérationnel. Les communautés étiquettent les routes; l’ordre de politique contrôle les décisions. RPKI valide l’autorisation d’origine; elle ne prouve pas la disponibilité ni la correction interne de politique. Les collecteurs observent des vues externes sélectionnées; ils ne révèlent pas toute dépendance privée. Les tickets documentent l’intention; ils ne maintiennent pas une route annoncée.

Cette couche de réalité est la leçon durable. Un réseau distribué est résilient quand ses chemins actifs, ses politiques de contrôle, ses accès de gestion et ses mécanismes de rollback préservent le service sous une panne représentative. La preuve n’est pas le nom du processus. C’est la route qui reste joignable, le canari qui bloque la progression et la reprise qu’une équipe peut compléter sans qu’une autre la défasse.

Sources

1. Cloudflare, "Panne de Cloudflare le 21 juin 2022":https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
2. Cloudflare, rapport d'impact 2022:https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
3. Cloudflare, "Cloudflare Backbone: Fast Lane on the Busy Internet Highway":https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
4. Cloudflare, "The backbone behind Cloudflare’s Connectivity Cloud":https://blog.cloudflare.com/backbone2024/
5. Cloudflare, "Load Balancing without Load Balancers":https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
6. Cloudflare, Référence d’architecture CDN:https://developers.cloudflare.com/reference-architecture/architectures/cdn/
7. Cloudflare, adresses IP et réseau anycast:https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
8. Cloudflare, politique de peering:https://www.cloudflare.com/peering-policy/
9. PeeringDB, dossier réseau Cloudflare:https://www.peeringdb.com/net/4224
10. IETF / RFC Editor, RFC 4271, Border Gateway Protocol 4:https://www.rfc-editor.org/rfc/rfc4271
11. IETF / RFC Editor, RFC 1997, BGP Communities Attribute:https://www.rfc-editor.org/rfc/rfc1997
12. IETF / RFC Editor, RFC 8092, BGP Large Communities Attribute:https://www.rfc-editor.org/rfc/rfc8092
13. IETF / RFC Editor, RFC 8326, Graceful BGP Session Shutdown:https://www.rfc-editor.org/rfc/rfc8326
14. IETF / RFC Editor, RFC 7454, BGP Operations and Security:https://www.rfc-editor.org/rfc/rfc7454
15. IETF / RFC Editor, RFC 6811, BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
16. IETF / RFC Editor, RFC 6480, RPKI Architecture:https://www.rfc-editor.org/rfc/rfc6480
17. RIPE NCC, manuel RIS Live:https://ris-live.ripe.net/manual/
18. RIPE NCC, Routing Information Service:https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
19. CAIDA, BGPStream:https://bgpstream.caida.org/
20. Cloudflare, "What is BGP?":https://www.cloudflare.com/learning/security/glossary/what-is-bgp/