Résumé

  • Le 13 octobre 2021, une modification de maintenance sur un routeur de la dorsale OVHcloud à Vint Hill, en Virginie, a provoqué une perturbation mondiale d’IPv4.
  • Selon OVHcloud, un problème d’interprétation d’une commande de redistribution BGP vers OSPF a fait entrer la table Internet complète dans le domaine OSPF.
  • BGP et OSPF répondent à des objectifs différents : leur interconnexion doit être traitée comme une transition d’état privilégiée, limitée par direction, volume, famille de routes et portée.
  • Une configuration approuvée et une réponse positive de l’équipement ne prouvent pas que l’état effectivement exécuté soit sûr.
  • La preuve opérationnelle doit rapprocher configuration rendue, état BGP et OSPF, LSDB, RIB, FIB, adjacences, ressources des routeurs et accessibilité externe en IPv4 comme en IPv6.
  • L’échec du retour arrière à distance montre que la gestion hors bande, l’accès console, la commande électrique et l’isolement physique répété à l’avance appartiennent au système de responsabilité.
  • Le maintien d’une accessibilité IPv6 constitue un indice de séparation partielle, mais ne démontre pas l’indépendance complète des architectures IPv4 et IPv6.
  • Une reprise ne devrait être close que lorsque la politique prévue, les routes réellement installées et l’accessibilité mesurée depuis l’extérieur concordent.

Une maintenance devenue incident de plan de contrôle

L’incident étudié est précisément délimité. Il s’agit de la perturbation mondiale du réseau IPv4 d’OVHcloud survenue le 13 octobre 2021 pendant une intervention sur un routeur situé à Vint Hill, en Virginie. Il ne faut pas la confondre avec l’incendie du centre de données de Strasbourg survenu la même année, avec une attaque subie par un client, avec une autre panne ultérieure d’OVHcloud ni avec un événement de routage sans rapport.

D’après le compte rendu public de l’entreprise, les travaux ont commencé à 09 h 05 UTC. Leur objectif déclaré était de renforcer la résistance du réseau aux attaques par déni de service distribué. Cette finalité est importante, mais elle ne change pas la nature de ce qui s’est ensuite produit : l’événement n’était pas une attaque DDoS. Rien dans le dossier public retenu ici ne permet non plus de parler de cyberattaque, de détournement BGP ou d’action hostile sur le routeur.

À 09 h 18, l’équipe a isolé de BGP le routeur de Vint Hill, puis a mis à jour sa configuration. À 09 h 20, selon OVHcloud, un problème d’interprétation d’une commande concernant la redistribution de BGP vers OSPF a entraîné l’introduction de la table de routage Internet complète dans OSPF. La précision « selon OVHcloud » est essentielle : elle indique la provenance de l’explication sans prétendre disposer de la configuration privée, des journaux complets de l’équipement ou d’une reproduction indépendante.

OVHcloud a signalé une instabilité d’OSPF ainsi qu’une pression sur les ressources processeur et mémoire de routeurs de la dorsale. L’impact annoncé était mondial pour IPv4, tandis qu’IPv6 demeurait accessible. L’entreprise a tenté un retour arrière à distance, mais celui-ci n’a pas abouti. Des équipes ont alors déconnecté physiquement le routeur et l’ont mis hors tension. La restauration s’est faite par étapes, à mesure que la dorsale reconvergeait. Le compte rendu indique un rétablissement étendu à 10 h 57 UTC.

Cette chronologie ne décrit donc pas une simple erreur immédiatement annulée. Elle montre une modification dont les conséquences ont touché le plan de contrôle, ont rendu inopérante la voie de retour à distance et ont obligé l’opérateur à déplacer la frontière de reprise jusqu’au monde physique. Entre le lancement des travaux et le rétablissement étendu, plusieurs types de vérité ont divergé : l’intention approuvée, la configuration saisie, l’interprétation qu’en a faite l’équipement, l’état propagé par les protocoles et l’accessibilité constatée par les utilisateurs.

BGP et OSPF : deux domaines aux hypothèses différentes

BGP et OSPF parlent tous deux de joignabilité, mais cela ne signifie pas qu’ils soient interchangeables. BGP est conçu pour diffuser des informations de routage entre systèmes autonomes et pour appliquer des politiques à ces échanges. Il doit composer avec une grande quantité de préfixes, des attributs de chemin, des décisions locales et des relations administratives entre réseaux distincts.

OSPF est un protocole à état de liens destiné à un domaine administratif intérieur. Ses routeurs échangent des informations afin de construire une représentation cohérente de la topologie utile au calcul des chemins. OSPF dispose aussi de mécanismes pour représenter des routes externes. L’existence de ces mécanismes ne signifie toutefois pas que l’injection massive d’informations externes soit sans danger. Une possibilité prévue par un protocole n’est pas une autorisation opérationnelle illimitée.

La différence concerne notamment le volume d’état, la manière dont cet état se propage et les hypothèses de convergence. Dans un domaine à état de liens, une modification peut devoir être diffusée, enregistrée dans la base d’état des liens, examinée par plusieurs routeurs et intégrée à de nouveaux calculs. Introduire un ensemble de routes de l’échelle d’Internet peut donc modifier brutalement la charge sur la mémoire, le processeur, les files de traitement et les adjacences.

Une route individuellement valide peut participer à un ensemble collectivement dangereux. La syntaxe d’un préfixe, d’un masque ou d’un attribut ne répond pas à la question décisive : combien de routes deviennent éligibles, dans quelle direction, vers quel domaine et avec quelle portée de propagation ? C’est pourquoi la cardinalité doit être considérée comme une propriété de sécurité opérationnelle. Une règle qui devait sélectionner quelques routes et qui en sélectionne un très grand nombre ne produit pas seulement une différence quantitative. Elle fait passer le système dans une autre classe de comportement.

Les RFC consacrées à BGP, à OSPF et à l’importation d’informations BGP dans OSPF donnent le vocabulaire nécessaire pour comprendre cette frontière. Elles décrivent des comportements de protocole et des points de contrôle. Elles ne révèlent ni la topologie privée d’OVHcloud en 2021, ni le logiciel utilisé, ni la commande exacte, ni les mécanismes réellement déployés après l’incident.

La redistribution comme transition privilégiée

La redistribution de routes n’est pas une simple opération de copie. Elle transforme un état accepté dans un domaine de contrôle en un état publiable dans un autre domaine dont les hypothèses sont différentes. Elle mérite, à ce titre, le même degré de discipline qu’une opération privilégiée sur une infrastructure critique.

Avant l’activation, l’opérateur devrait pouvoir répondre de façon vérifiable à quatre questions. Premièrement, quel est l’ensemble admissible ? Il faut identifier les familles d’adresses, les préfixes, les longueurs de masque, les communautés, les étiquettes ou les autres propriétés qui rendent une route éligible. Deuxièmement, quelle est la direction autorisée ? Une redistribution de BGP vers OSPF ne doit pas être confondue avec le chemin inverse ni avec une redistribution bidirectionnelle.

Troisièmement, quelle cardinalité est prévue et quelle limite absolue déclenche un refus ? Une politique qui devrait exporter dix routes mais qui en sélectionne dix mille doit être bloquée avant propagation, même si chacune de ces routes est formellement acceptable. Quatrièmement, quelle est la portée maximale ? Une modification peut-elle toucher un seul routeur de test, une région, un groupe borné d’équipements ou la dorsale entière ?

Ces questions doivent produire des contraintes exécutables, et non rester dans une description de changement. Un dossier peut indiquer correctement l’objectif tout en laissant ouverte une sélection dangereuse. Une seconde personne peut approuver une intention exacte sans voir la configuration rendue après expansion des modèles, héritage des paramètres ou interprétation par la plate-forme. L’équipement peut accepter la commande et renvoyer un message de succès alors que l’état résultant viole les limites prévues.

L’incident illustre ainsi la différence entre commande acceptée et transition sûre. La preuve ne s’arrête ni au formulaire d’approbation ni à l’accusé de réception du routeur. Elle doit suivre la modification jusque dans l’état réellement exécuté : politique active, nombre de routes admises, informations présentes dans OSPF, entrées de la LSDB, routes retenues dans la RIB, routes installées dans la FIB, adjacences encore stables et trafic effectivement transmissible.

Volume d’état, propagation et instabilité

Le compte rendu public attribue l’incident à l’introduction de la table Internet complète dans OSPF et mentionne une instabilité du protocole ainsi qu’une pression sur le processeur et la mémoire de routeurs de la dorsale. Ces éléments sont confirmés au niveau général. Le nombre exact de routes, le type et le nombre précis d’annonces OSPF, la séquence interne de saturation ou le comportement d’un logiciel particulier ne le sont pas.

Plusieurs mécanismes sont techniquement plausibles sans pouvoir être affirmés comme reconstruction de l’incident. Un grand ensemble de routes externes peut augmenter la taille de l’état conservé par les routeurs. Sa diffusion peut multiplier le travail de transmission, de réception et de traitement. Des changements répétés peuvent provoquer des recalculs, des mises à jour de tables ou des retards dans le maintien des adjacences. La pression sur les ressources peut ensuite perturber les protocoles qui devraient précisément stabiliser le réseau.

Il faut conserver une distinction nette entre ces explications générales et le fait documenté. Le fait est qu’OVHcloud a rapporté une redistribution de la table Internet complète vers OSPF, une instabilité OSPF et une pression sur les ressources de la dorsale. Les explications détaillées sur les files d’attente, la planification des processus, les types d’annonces ou le comportement de la FIB restent des hypothèses à vérifier sur les équipements concernés.

Cette prudence n’affaiblit pas l’analyse de responsabilité. Au contraire, elle montre quelles données l’opérateur devrait préserver. Des instantanés horodatés de la LSDB, des compteurs de routes par origine, des relevés de RIB et de FIB, les variations d’adjacences, les courbes de processeur et de mémoire ainsi que les journaux de configuration auraient permis de relier la transition à ses conséquences sans dépendre uniquement d’une narration ultérieure.

Ce que l’intention approuvée ne démontre pas

Une maintenance peut avoir un objectif raisonnable et néanmoins produire un état dangereux. Ici, le but déclaré était de renforcer la résistance aux DDoS. Cela ne prouve ni que la modification était mal conçue dans son ensemble ni qu’elle aurait été nécessairement efficace si elle s’était déroulée comme prévu. Cela établit seulement le contexte annoncé du changement.

La responsabilité opérationnelle commence lorsque l’on refuse de confondre trois niveaux. Le premier est l’intention : ce que l’équipe voulait obtenir. Le deuxième est la configuration rendue : le résultat complet après application des modèles, variables et règles propres à l’environnement. Le troisième est l’état courant : ce que les protocoles et les tables de transfert ont effectivement adopté.

Un système de changement fiable compare ces trois niveaux. Il peut, par exemple, calculer avant activation la liste exacte des routes qui deviendraient admissibles. Il peut refuser une différence supérieure à une limite définie. Il peut vérifier que la règle ne s’applique qu’au sens prévu. Il peut déployer d’abord sur un périmètre canari et attendre des observations stables. Enfin, il peut retirer automatiquement le changement si le nombre de routes, la charge ou les adjacences quittent leur enveloppe attendue.

Sans cette chaîne, l’approbation risque de devenir une preuve administrative d’un objet qui n’existe plus au moment de l’exécution. Ce qui compte pour le réseau n’est pas la description du changement, mais le code de configuration finalement rendu, la manière dont l’équipement l’interprète et l’état qu’il propage.

IPv4 touché, IPv6 accessible : une séparation partielle

OVHcloud a indiqué un impact mondial sur IPv4 tandis qu’IPv6 demeurait accessible. Cette différence est importante parce qu’elle fournit un indice observable de séparation entre certains chemins ou états. Elle suggère qu’au moins une partie du service IPv6 n’a pas suivi exactement le même mode de défaillance que le service IPv4.

Il serait toutefois excessif d’en déduire une indépendance architecturale complète. Deux familles d’adresses peuvent utiliser des sessions, des processus ou des politiques distincts tout en partageant des routeurs, des liens, des alimentations, des systèmes de gestion, des outils d’automatisation, des équipes ou des capacités de calcul. Elles peuvent aussi présenter des différences du côté des clients, des opérateurs d’accès et des systèmes de noms.

Le maintien d’IPv6 répond donc à une question limitée : une accessibilité IPv6 a continué d’être observée selon le compte rendu. Il ne répond pas, à lui seul, aux questions sur l’étendue géographique, la qualité de service, la disponibilité de toutes les applications ou le degré de séparation physique et administrative.

Une analyse sérieuse devrait distinguer quatre plans. Le plan de contrôle décide quelles routes sont connues et préférées. Le plan de transfert transmet les paquets selon les entrées installées. Le plan de gestion permet d’administrer les équipements. Le plan d’observation mesure l’état depuis l’intérieur et depuis l’extérieur. Une séparation utile doit être évaluée dans chacun de ces plans, et non déduite d’un seul résultat d’accessibilité.

La bonne leçon n’est donc pas qu’IPv6 aurait constitué une solution de secours universelle. Elle est que l’observation séparée d’IPv4 et d’IPv6 permet de caractériser plus précisément le rayon d’impact. Les tests de changement et de reprise doivent conserver cette distinction, avec des sondes externes, des préfixes de référence et des chemins de mesure indépendants pour chaque famille.

L’échec du retour arrière et la frontière physique

Le retour arrière à distance n’a pas fonctionné pendant l’instabilité. Le dossier public ne permet pas d’identifier la cause exacte de cet échec. Il serait imprudent d’affirmer que le processeur était entièrement saturé, qu’une session de gestion particulière était rompue ou qu’un mécanisme précis empêchait la commande. On peut seulement constater que la voie distante n’a pas fourni la reprise attendue.

Cette limitation est déjà suffisante pour une conclusion majeure : une procédure de retour arrière qui dépend du même équipement, du même plan de contrôle ou du même chemin de gestion que la modification n’est pas entièrement indépendante. Elle peut fonctionner dans les essais ordinaires et disparaître précisément lorsque le risque qu’elle doit contenir se réalise.

À Vint Hill, l’isolement physique et la mise hors tension du routeur ont constitué la frontière de reprise efficace, selon OVHcloud. Cela ne doit pas être présenté comme une faiblesse intrinsèque du geste physique. L’isolement matériel est parfois le moyen le plus certain de retirer un équipement fautif. La question de responsabilité est de savoir s’il avait été préparé comme une capacité contrôlée ou s’il n’est devenu disponible qu’au prix d’une improvisation.

Une architecture de reprise robuste prévoit plusieurs niveaux indépendants : réseau de gestion ayant son propre routage, console série ou équivalent, accès distant au système de commande électrique, capacité de retirer les liens concernés, présence ou intervention physique mobilisable, et procédure répétée dans des conditions réalistes. Chaque niveau doit être testé contre la défaillance des autres.

L’accès hors bande ne peut pas être qualifié d’indépendant uniquement parce qu’il utilise une interface distincte. Il faut examiner son alimentation, son chemin de télécommunication, son système d’identité, ses dépendances DNS, son routage, ses outils d’authentification et ses points de concentration. Une console accessible par un réseau qui traverse la dorsale perturbée n’est pas réellement hors bande pour ce scénario.

La commande électrique doit elle aussi être encadrée. Couper un équipement peut retirer l’origine d’un état nocif, mais cela modifie la topologie et déclenche une nouvelle convergence. La procédure doit donc anticiper les chemins de remplacement, les charges transférées et l’ordre de réintroduction. La reprise par étapes rapportée par OVHcloud souligne précisément que l’arrêt de la source ne rend pas instantanément le réseau sain.

Pourquoi l’isolement ne suffit pas à déclarer la reprise

Une fois l’équipement déconnecté ou éteint, l’état qu’il a diffusé peut encore exister ailleurs pendant un certain temps. Les routeurs doivent retirer les informations devenues invalides, recalculer leurs décisions et installer de nouvelles entrées. Les sessions et adjacences doivent se stabiliser. Les chemins externes doivent redevenir utilisables.

La clôture de l’incident ne devrait donc pas reposer uniquement sur le fait que le routeur problématique a été neutralisé. Elle exige au moins trois concordances. La première porte sur la politique : la redistribution active correspond-elle de nouveau à l’intention approuvée ? La deuxième porte sur l’état installé : les RIB, FIB et bases OSPF contiennent-elles l’ensemble attendu, sans résidu anormal ? La troisième porte sur le résultat externe : les préfixes et services sont-ils effectivement joignables depuis plusieurs réseaux en IPv4 et en IPv6 ?

Ces trois vérités peuvent diverger. Une politique corrigée peut coexister temporairement avec un état ancien. Une RIB peut sembler correcte tandis que certaines entrées de transfert ou certains chemins externes restent défaillants. Une sonde unique peut réussir alors qu’une région ou une famille d’adresses demeure isolée.

Le rétablissement étendu annoncé à 10 h 57 UTC constitue un jalon public utile. Il ne doit pas être transformé en affirmation selon laquelle chaque client, chaque chemin et chaque dépendance étaient simultanément revenus à la normale. L’expression « rétablissement étendu » respecte mieux la portée de l’information disponible.

Les limites automatiques avant activation

La première protection devrait porter sur l’ensemble de routes sélectionné. Avant toute modification, le système peut calculer le nombre prévu de routes par famille, source, type et destination de redistribution. Ce résultat doit être comparé à une valeur attendue et à un plafond absolu.

Le plafond ne doit pas être seulement une alerte. Pour une transition aussi sensible, son dépassement devrait empêcher l’activation. Si le système attend un petit ensemble et en découvre un volume de l’échelle d’Internet, la bonne action est le refus, non la diffusion suivie d’une observation.

La direction doit être encodée avec la même rigueur. Les règles de redistribution doivent être explicitement unidirectionnelles lorsqu’elles sont conçues ainsi, et les boucles potentielles doivent être analysées. Les routes réintroduites doivent pouvoir être identifiées par des marques ou des propriétés vérifiables afin d’éviter qu’un état ne traverse plusieurs fois une frontière.

Un contrôle utile examine également l’impact estimé sur les ressources. Il ne s’agit pas de prétendre prédire exactement le comportement de chaque routeur, mais de définir une enveloppe : nombre maximal de routes, croissance maximale de la LSDB, variation acceptable de la mémoire, charge processeur soutenable, taux de modifications et stabilité des adjacences.

Les documents actuels d’OVHcloud sur son réseau et ses offres de connectivité utilisent un vocabulaire de dorsale mondiale, de points de présence, de connectivité de couche 3 fondée sur BGP, d’ECMP, de BFD et de limites explicites sur les préfixes dans certains services destinés aux clients. Ces documents montrent que des frontières de routage peuvent être exprimées sous forme de contraintes mesurables. Ils ne démontrent pas que le routeur de Vint Hill utilisait ces mêmes mécanismes en 2021, ni que les contrôles actuels répondent à cet incident précis.

Canaris, arrêts automatiques et observation en direct

Une limite correcte peut encore être mal appliquée. Le déploiement devrait donc commencer sur un équipement canari ou un groupe strictement borné. Le canari ne doit pas être un routeur dont la défaillance affecterait immédiatement une grande partie de la dorsale. Son rôle est de confronter la configuration rendue à un état réel tout en limitant la propagation.

Le passage à l’étape suivante devrait dépendre de critères observables : nombre de routes BGP reçues et sélectionnées, nombre de routes redistribuées, évolution de la LSDB, stabilité des adjacences OSPF, contenu de la RIB et de la FIB, utilisation du processeur et de la mémoire, pertes de paquets et accessibilité externe.

Ces critères nécessitent des valeurs de référence recueillies avant la modification. Sans état initial, une hausse de mémoire ou une variation de routes peut être difficile à interpréter. Les mesures doivent être horodatées, associées à l’identifiant du changement et conservées assez longtemps pour permettre une analyse après coup.

L’arrêt automatique doit être conçu avec prudence. Il ne suffit pas d’envoyer une nouvelle commande de retour arrière par le même chemin. Le système doit déterminer si la voie de gestion reste utilisable et prévoir une escalade vers un mécanisme indépendant. L’automatisation ne remplace pas la stratégie de reprise ; elle exécute une stratégie dont les dépendances ont été explicitées.

L’évidence nécessaire à une responsabilité vérifiable

Pour qu’une modification de dorsale soit vérifiable, l’opérateur devrait pouvoir produire une chaîne d’éléments cohérente. Elle commence par la demande de changement : objectif, périmètre, risques, critères d’arrêt et procédure de reprise. Elle se poursuit avec la configuration rendue, et non seulement le modèle ou les lignes modifiées.

Viennent ensuite la réponse de l’équipement et les observations de l’état courant. La réponse de l’interface confirme au mieux qu’une demande a été reçue ou acceptée. Elle ne prouve pas que les routes attendues ont été les seules à entrer dans OSPF. Il faut donc conserver les compteurs et les ensembles de routes, les changements de LSDB, les décisions de RIB et les entrées de FIB.

Les adjacences renseignent sur la stabilité du domaine de contrôle. Les mesures de processeur et de mémoire indiquent si l’équipement reste dans son enveloppe. Des sondes externes testent le résultat que les seuls appareils internes ne peuvent pas prouver : l’accessibilité réelle depuis plusieurs réseaux, en IPv4 et en IPv6.

La valeur de cette chaîne tient à sa continuité. Si l’approbation est archivée dans un outil, la configuration ailleurs et les mesures dans un troisième système sans horodatage commun, il devient difficile d’établir quel état correspond à quelle étape. Une responsabilité sérieuse associe chaque preuve à une chronologie et à un périmètre précis.

Communication publique et besoins des clients

Le compte rendu d’OVHcloud apporte plusieurs informations significatives : la chronologie, le lieu du changement, l’interaction entre BGP et OSPF, l’échec du retour arrière à distance, l’intervention physique et la distinction entre IPv4 et IPv6. Ces éléments permettent une analyse plus précise qu’une formulation générique sur un « incident réseau ».

Pour les clients, comprendre le rayon d’impact exige toutefois des données adaptées à leur propre dépendance. Ils ont besoin de savoir quelles familles d’adresses étaient touchées, quelles régions ou catégories de services pouvaient être concernées, quels jalons de restauration ont été atteints et comment vérifier leur propre rétablissement.

Un client ne peut pas conclure que son service était sain simplement parce que la dorsale était en cours de reconvergence. Il doit rapprocher les annonces de l’opérateur de ses journaux applicatifs, de ses mesures de disponibilité, de ses routes observées, de ses dépendances DNS et de ses tests effectués depuis plusieurs réseaux.

Inversement, les observations d’un client ne permettent pas à elles seules de reconstruire l’état interne de la dorsale. La responsabilité est distribuée : l’opérateur doit expliquer et mesurer son infrastructure, tandis que le client doit conserver les preuves de ses propres symptômes et de sa reprise. Les deux ensembles se complètent sans se remplacer.

Une grille de responsabilité pour les changements de dorsale

Une modification impliquant une frontière entre protocoles peut être évaluée selon une grille simple.

Intention définie. Le but technique, le périmètre et les familles de routes concernées sont explicités. Les termes vagues tels que « améliorer le routage » ne suffisent pas.

Configuration rendue. L’opérateur conserve le résultat complet qui sera interprété par l’équipement, y compris les valeurs héritées, les filtres développés et les différences avec l’état précédent.

Ensemble admissible calculé. La liste ou le nombre exact des routes éligibles est calculé avant activation. La direction et la portée de redistribution sont vérifiées.

Cardinalité plafonnée. Un dépassement entraîne un blocage technique. Le plafond est suffisamment bas pour distinguer l’intention d’un ensemble accidentel de l’échelle d’Internet.

Déploiement borné. Un canari ou une petite cohorte reçoit la modification en premier. L’étape suivante n’est autorisée qu’après une période de stabilité définie.

État courant observé. BGP, OSPF, LSDB, RIB, FIB, adjacences, processeur et mémoire sont comparés aux valeurs attendues.

Résultat externe mesuré. Des sondes indépendantes contrôlent IPv4 et IPv6 depuis plusieurs origines. Le succès d’une seule sonde n’est pas considéré comme une preuve globale.

Retour arrière indépendant. La gestion hors bande, la console, l’alimentation et l’isolement physique ne partagent pas toutes les dépendances du plan modifié.

Reprise répétée. Les équipes ont exercé les procédures, les autorisations et l’accès physique avant l’incident, avec une documentation à jour.

Clôture réconciliée. L’incident n’est fermé que lorsque la politique prévue, l’état installé et la joignabilité externe sont cohérents.

Cette grille ne permet pas de juger rétrospectivement des personnes sans informations internes. Elle sert à demander des preuves adaptées au niveau de risque d’un changement capable d’affecter une dorsale mondiale.