Résumé

  • Le 4 avril 2023, Virgin Media UK, identifiée par les observateurs techniques sous le numéro AS5089, a connu deux perturbations majeures qui ont altéré la joignabilité de son réseau et de ses services depuis l'Internet global. [1][2]
  • Cloudflare a observé un trafic tombant à presque zéro vers 00h30 UTC, suivi d'une reprise instable. ThousandEyes a décrit un premier incident entre environ 00h30 et 07h00 UTC et un second entre 15h20 et 17h30 UTC environ. [1][2]
  • ThousandEyes a attribué la majeure partie de la perte de trafic observée à l'absence de routes BGP viables vers le réseau Virgin Media. Il a également observé une autre situation: certains fournisseurs conservaient des routes vers AS5089, mais le trafic était abandonné à la bordure Virgin Media. [2]
  • Ces observations établissent les modes de défaillance de routage et de transfert. Elles n'établissent pas la commande, le périphérique, le fournisseur, la personne, l'activité de maintenance, la cyberattaque ou toute autre cause profonde qui a déclenché l'incident.
  • La récurrence plus tard le même jour place les preuves de restauration au cœur du problème. La réapparition d'une route n'est pas équivalente à une reprise de service stable, et un statut interne vert ne prouve pas que divers réseaux externes peuvent joindre et traverser la bordure.
  • La responsabilité découle du contrôle effectif. Virgin Media contrôlait l'annonce des routes, leur retrait, la politique de bordure, le transfert interne, le séquencement de la restauration, la communication de l'incident et l'indemnisation des clients. Les pairs contrôlaient leur propre sélection de chemin et leurs preuves. Les fournisseurs de mesures ont fourni des observations indépendantes mais n'ont pas pu reconstituer l'état interne non divulgué.
  • Les enregistrements actuels de PeeringDB, dérivés de RIPE et de routage identifient AS5089 et son contexte d'interconnexion. Ils ne sont pas des copies figées de l'état du réseau le 4 avril 2023 et ne doivent pas être utilisés comme télémesure d'incident. [6][7][8][9][10][11]
  • Les RFC 4271, RFC 7454, RFC 8212 et MANRS fournissent un contexte protocolaire et opérationnel. Aucun ne prouve quels contrôles Virgin Media avait déployés ni qu'un contrôle spécifique aurait empêché l'événement. [12][13][14][15]
  • Un enregistrement de responsabilité crédible doit aligner trois horloges: disponibilité des routes, transfert de paquets et service visible par le client. Il doit préserver les observations exactes, qualifier les inférences, exposer les inconnues et documenter les preuves que seul l'opérateur pouvait produire.

L'incident se composait de deux perturbations, pas d'un jour vague de panne

Les grandes pannes réseau sont souvent résumées à une heure de début, une heure de fin et un nombre de clients. Ce format est pratique, mais il peut effacer le mécanisme qui détermine la responsabilité. La perturbation Virgin Media se comprend mieux comme deux périodes observées, plusieurs étapes de reprise instable et au moins deux modes de défaillance visibles de l'extérieur.

La vue du trafic de Cloudflare a situé le premier effondrement majeur aux alentours de 00h30 UTC le 4 avril. Le trafic associé à Virgin Media est tombé à presque zéro. Le service n'est pas revenu par une transition nette. Le graphique et le compte rendu qui l'accompagne ont décrit une reprise partielle, de nouvelles chutes et une autre perturbation ultérieure. L'importance de cet enregistrement ne tient pas au fait que Cloudflare pouvait voir tous les clients de Virgin Media. Il ne le pouvait pas. Sa valeur réside dans le fait qu'un grand réseau externe a observé un changement brutal du trafic impliquant le système autonome Virgin Media. [1]

ThousandEyes a décrit le premier incident comme se déroulant entre environ 00h30 et 07h00 UTC. Il a enregistré des retraits de routes BGP, une perte de trafic et des périodes de reprise intermittentes. Le deuxième incident a débuté vers 15h20 UTC et s'est résolu vers 17h30 UTC. Il partageait des caractéristiques externes similaires. Cette chronologie étaye l'affirmation que la joignabilité a échoué deux fois. Elle ne prouve pas que le même composant interne ou le même changement a déclenché les deux événements. [2]

Les reportages contemporains ont rendu compte de la dimension orientée client. The Register a signalé une perturbation généralisée du haut débit et une reconnaissance de Virgin Media que les clients rencontraient des problèmes. Cette preuve aide à établir que les observations de routage correspondaient à un impact sur le service. Elle ne transforme pas les signalements sociaux ni les déclarations d'entreprise en post-mortem technique complet. [3]

La distinction entre deux perturbations est importante car une récupération a eu lieu entre elles. Un opérateur qui annonce la restauration du service après le premier événement fait une déclaration opérationnelle: le réseau est de nouveau joignable, achemine correctement le trafic et est suffisamment stable pour supporter le trafic attendu. Une récurrence ultérieure peut révéler que le déclencheur n'a pas été supprimé, que les critères de récupération étaient trop étroits ou qu'un défaut distinct mais lié est resté. Le dossier public ne nous dit pas quelle explication est la bonne.

Cet article ne combine donc pas tous les symptômes en une séquence inventée. Il traite les périodes observées comme un cas de responsabilité délimité. La première question est ce que le monde extérieur pouvait voir. La deuxième est ce que seul Virgin Media pouvait savoir. La troisième est quelles preuves devraient relier ces deux points de vue.

AS5089 est une frontière opérationnelle, pas un détail de marque

Un numéro de système autonome identifie un réseau qui présente une politique de routage cohérente aux autres réseaux. Il ne décrit pas chaque routeur interne, câble, segment d'accès ou produit commercial. Il établit en revanche une frontière utile pour la responsabilité interdomaine: les autres réseaux échangent des informations de joignabilité avec le système autonome et acheminent le trafic en fonction des chemins résultants.

Les sources techniques identifient Virgin Media UK par AS5089. Les données actuelles de PeeringDB décrivent Virgin Media sous cet ASN et enregistrent une empreinte d'interconnexion, un AS-SET et des informations de peering public. Les outils actuels BGP et dérivés de RIPE associent également AS5089 à Virgin Media Limited et montrent les ressources réseau annoncées. Ces enregistrements permettent de rattacher l'événement à l'identité réseau correcte. [6][7][8][9][10][11]

Ils doivent être utilisés avec précaution. Une page PeeringDB actuelle peut changer après qu'un opérateur a mis à jour son enregistrement. Les préfixes actuels peuvent différer de ceux annoncés en avril 2023. Un statut RPKI présent ne dit à lui seul rien sur le statut d'une route pendant la perturbation. Un objet de registre enregistre des informations administratives et de routage; il ne prouve pas que les paquets ont traversé une bordure à une minute précise.

Les registres et les annuaires réseau sont des enregistrements de preuves. Ils aident à identifier les détenteurs de ressources, les objets de routage et les voies de contact. Ils ne sont pas des déclarations qui rendent le réseau opérationnel sain. La vérité opérationnelle apparaît dans les routes que les pairs reçoivent réellement et les paquets que le réseau accepte et achemine réellement.

La frontière AS empêche également que la responsabilité ne se dissolve dans le mot « Internet ». L'Internet est une collection de réseaux exploités de manière indépendante. Un fournisseur de contenu distant peut avoir des serveurs fonctionnels. Un fournisseur de transit peut proposer un chemin vers AS5089. Un appareil client peut fonctionner localement. Pourtant, si les routes vers le réseau d'accès disparaissent, les réseaux distants ne peuvent pas acheminer le trafic. Si les routes subsistent mais que la bordure de l'opérateur abandonne les paquets, le chemin visible ne produit toujours pas de service.

Virgin Media ne contrôlait pas chaque pair distant, résolveur, application ou appareil client. Il contrôlait en revanche ses propres annonces de route, son comportement de bordure, son acheminement interne et son processus de récupération. C'est la frontière de contrôle effective sur laquelle une analyse de responsabilité équitable doit commencer.

Le retrait de route a fait disparaître la joignabilité

BGP permet aux systèmes autonomes d'échanger des informations sur les préfixes d'adresses qu'ils peuvent joindre et via quels chemins. La RFC 4271 définit le modèle de protocole. Une route n'est pas une garantie qu'une application fonctionnera, mais sans route utilisable, le trafic n'a généralement nulle part où aller. [12]

ThousandEyes a observé que la majeure partie de la perte de trafic lors des incidents du 4 avril était associée à un manque de routes BGP viables vers le réseau Virgin Media. Lorsque les routes étaient retirées, les autres réseaux ne pouvaient plus sélectionner ces chemins. Les paquets destinés à des adresses dans les préfixes concernés étaient abandonnés en amont ou échouaient après des tentatives de connexion répétées. [2]

Ce n'est pas simplement un symptôme technique accessoire. L'annonce de route est l'un des principaux moyens pour un fournisseur d'accès de rendre son réseau joignable depuis l'Internet global. Le retrait peut être une action de sécurité délibérée, la conséquence d'une perte de session, un résultat de politique, un effet d'automatisation ou la conséquence d'une autre défaillance. Les sources publiques n'établissent pas quel mécanisme a opéré ici.

L'absence de détail sur la cause profonde ne rend pas la responsabilité impossible. Elle change les questions. Quels préfixes ont disparu? Quels pairs ont reçu les retraits en premier? Tous les chemins externes ont-ils disparu ensemble ou par groupes? IPv4 et IPv6 se sont-ils comportés de la même manière? Quels systèmes de surveillance ont détecté le changement? Quel signal de santé interne a autorisé la réannonce? Quel test d'acceptation devait être réussi avant que la reprise côté client soit déclarée?

Ces questions sont des demandes de preuves, pas des accusations. Elles relient le comportement observable aux enregistrements qu'un opérateur devrait posséder. Un serveur de routes, un routeur de bordure, un contrôleur d'automatisation ou un système de surveillance peut enregistrer les changements avec des horodatages. La gestion des changements peut enregistrer si un déploiement était en cours. Les collecteurs de routes externes peuvent montrer une vue extérieure partielle. Aucun enregistrement unique n'est complet, mais ensemble ils peuvent établir une chronologie défendable.

Le risque opérationnel est plus large qu'une seule session de protocole. Les réseaux d'accès peuvent annoncer de nombreux préfixes sur plusieurs bordures. Une défaillance qui retire un large ensemble de routes peut isoler à la fois les services, l'espace d'adressage des clients, l'infrastructure DNS, les systèmes de gestion et les canaux de support. La population touchée subit alors différentes erreurs applicatives, même si la défaillance partagée est la joignabilité.

La responsabilité exige donc à la fois une portée et une chronologie. Un opérateur devrait être capable de dire quelles ressources d'adressage ont été affectées, quelles bordures ont changé d'état, quels services dépendaient de ces ressources et quels chemins sont restés disponibles. Une déclaration générale selon laquelle « le haut débit était en panne » ne suffit pas pour distinguer une panne d'accès régionale d'un isolement à l'échelle du système autonome.

Une route visible ne produisait pas toujours un acheminement fonctionnel

Le détail le plus important dans le compte rendu de ThousandEyes est que le retrait de route n'expliquait pas toutes les défaillances observées. Certains fournisseurs étaient apparemment encore capables de router le trafic vers le réseau Virgin Media. Dans ces cas, le trafic était abandonné à la bordure de Virgin Media. ThousandEyes a décrit ce motif comme suggérant une détresse systémique, impliquant probablement le plan de contrôle. [2]

Le mot « suggérant » est important. Un observateur extérieur peut voir qu'un chemin persiste et que des paquets échouent près d'une bordure. Il ne peut pas inspecter l'état interne du contrôle de l'opérateur. Les abandons en bordure peuvent résulter de plusieurs types de conditions: l'état de transfert peut être absent, les routes internes peuvent être indisponibles, les interfaces peuvent être altérées, la politique peut rejeter le trafic, la capacité peut s'effondrer ou des dépendances peuvent échouer. Choisir un mécanisme sans preuve transformerait l'observation en fiction.

La conclusion limitée est néanmoins solide. La présence de route et la livraison de paquets divergeaient. Pour ces chemins, le système de routage global portait une promesse apparente selon laquelle AS5089 était joignable, tandis que la bordure de l'opérateur ne fournissait pas le service correspondant.

Cette divergence est un risque réseau récurrent. L'état du plan de contrôle peut sembler valide alors que le plan de données échoue. Une session BGP peut rester établie alors qu'un saut suivant est inutilisable. Un préfixe peut rester dans une table de routage alors que les paquets sont rejetés. Un tableau de bord interne peut indiquer une bordure comme disponible parce que le processus est actif même si les sondes de bout en bout échouent.

La réponse en matière de responsabilité consiste à exiger des preuves appariées. La santé du routage demande si les préfixes attendus sont visibles via les pairs attendus. La santé du transfert demande si des paquets représentatifs traversent la bordure et atteignent les destinations. La santé applicative demande si les services réels terminent leurs transactions. Un opérateur ne devrait pas réduire ces couches à un seul indicateur vert.

Les sondes externes sont précieuses car elles testent le service depuis l'extérieur du système modifié. Elles doivent être suffisamment diverses pour éviter de prendre la vue d'un pair pour l'Internet entier. Les mesures doivent inclure les fournisseurs qui ont reçu des retraits et ceux qui ont conservé des routes. Elles doivent couvrir les régions, les familles d'adresses et les classes de service pertinentes.

Le résultat devrait être une matrice, pas un simple chiffre de disponibilité. Une route peut être absente ou présente. Un paquet peut échouer avant la bordure, à la bordure ou après l'entrée. Une application peut échouer malgré un transport réussi. Cette matrice aide les intervenants à décider s'il faut restaurer les annonces de route, réparer le transfert interne, alléger la charge, isoler une bordure défaillante ou communiquer une portée plus étroite.

La récupération doit être prouvée sur trois horloges

La récurrence du 4 avril place le sens de « rétabli » au centre. La récupération n'est pas un seul horodatage. C'est un accord entre au moins trois horloges: le routage, le transfert et le service visible du client.

L'horloge de routage enregistre quand les préfixes ont été retirés, réannoncés et acceptés par les pairs. Elle peut inclure les flux de mises à jour BGP, les observations des collecteurs de routes et les vérifications de looking-glass. La propagation BGP étant distribuée, différents observateurs peuvent voir les changements à des moments différents. La première réapparition d'une route ne prouve pas la convergence globale.

L'horloge de transfert enregistre si le trafic a effectivement traversé la frontière de l'opérateur et atteint des destinations représentatives. Elle inclut la perte de paquets, la latence, les traces de chemin et les sondes actives. Elle peut être en retard par rapport à la réannonce de route si l'état de transfert est incomplet. Elle peut également échouer indépendamment alors que les routes restent visibles.

L'horloge client enregistre quand les utilisateurs ont perdu le service, quand les canaux de support ont reconnu le problème, quand les avis de statut ont changé, quand les clients ont pu accomplir des tâches réelles et quand les processus d'indemnisation ou de réclamation sont devenus disponibles. Elle reflète les conséquences commerciales et sociales, pas seulement l'état du réseau.

Une restauration responsable doit aligner ces horloges. L'opérateur doit spécifier un intervalle de stabilisation pendant lequel la visibilité des routes reste cohérente, les sondes de transfert réussissent depuis divers réseaux et les indicateurs d'impact client reviennent dans les plages attendues. Si la première récupération a été acceptée avant que cet intervalle ne se soit écoulé, l'enregistrement devrait en expliquer la raison.

Les sources publiques ne révèlent pas les critères d'acceptation internes de Virgin Media. Elles montrent en revanche que le service s'est amélioré puis qu'une perturbation majeure similaire est survenue. Cela suffit pour demander si la restauration a été définie comme un retour transitoire du trafic ou comme une joignabilité stable de bout en bout.

La réponse ne doit pas être devinée. Un enregistrement post-incident pourrait la fournir en publiant une chronologie délimitée: ce qui a été changé, quels signaux ont déclenché la récupération, quels signaux se sont ensuite détériorés, si les mêmes composants étaient impliqués et quelle validation supplémentaire a été ajoutée. Si des préoccupations de sécurité ou commerciales empêchent la divulgation de la configuration, des preuves agrégées de route et de santé peuvent toujours être publiées.

Cette approche évite une transparence performative. Un long récit sans horodatages de route et de transfert peut sembler franc tout en laissant l'affirmation principale invérifiable. Un enregistrement plus court qui aligne les trois horloges peut offrir une plus grande responsabilité.

Une deuxième perturbation transforme le retour en arrière en un problème de preuves

Une récurrence après une reprise partielle confronte les intervenants à un choix difficile. Ils peuvent croire avoir supprimé la cause, ou n'avoir restauré que les symptômes. La distinction détermine si le réseau doit revenir à un fonctionnement normal ou rester dans un état surveillé.

Un retour en arrière est souvent traité comme un événement binaire: le nouvel état a été supprimé, donc l'ancien état doit être sûr. Les réseaux distribués ne sont pas si simples. L'ancienne configuration peut revenir pendant que les sessions reconvergent à des vitesses différentes. L'état mis en cache ou généré peut persister. Les dépendances internes peuvent ne pas se rétablir ensemble. Un défaut distinct peut avoir été exposé par l'événement initial.

Pour cette raison, le retour en arrière devrait être lié à des invariants observables. Les préfixes attendus devraient être présents. Les retraits inattendus ou l'instabilité des chemins devraient cesser. Le transfert en bordure devrait fonctionner depuis plusieurs réseaux externes. Les sauts suivants internes devraient être valides. La capacité devrait supporter la charge de retour. Les taux d'erreur visibles par le client devraient rester stables pendant un intervalle défini.

La RFC 7454 traite des pratiques opérationnelles et de sécurité autour de BGP. La RFC 8212 propose une posture explicite de rejet par défaut pour la politique eBGP. MANRS décrit des pratiques de filtrage, de coordination, de validation et de validation globale. Ces sources sont utiles pour définir des familles de contrôle. Elles n'établissent pas qu'un contrôle spécifique de Virgin Media a échoué, ni ne prouvent que l'application d'une recommandation aurait évité cette panne. [13][14][15]

La leçon est plus étroite: la politique de route et la récupération nécessitent des conditions explicites et testables. Un opérateur devrait savoir quelles routes un pair est autorisé à annoncer, ce qu'il exportera, quelle joignabilité interne doit exister avant qu'un agrégat ne soit annoncé et quelles mesures indépendantes peuvent bloquer ou inverser un déploiement.

Pour un fournisseur d'accès national, la conception de « canari » est particulièrement importante. Un changement peut être limité à une bordure, une région, une famille d'adresses ou un groupe de préfixes contrôlé avant un déploiement plus large. Le canari doit être observé depuis l'extérieur du domaine administratif. Si les invariants de route ou de transfert échouent, l'automatisation doit arrêter l'extension et préserver les preuves.

Rien de tout cela n'exige que l'article affirme qu'un changement ait causé l'incident du 4 avril. Il fixe une norme pour toute explication. Si la cause était un déploiement, l'opérateur devrait montrer la frontière et le retour en arrière. S'il s'agissait d'une défaillance de périphérique ou de dépendance, il devrait montrer pourquoi la redondance n'a pas préservé le service de route et de transfert. Si plusieurs conditions se sont combinées, il devrait montrer comment la détection et la récupération ont été modifiées.

L'interconnexion transforme les opérations privées en risque partagé

AS5089 ne fonctionne pas en vase clos. Sa joignabilité dépend des sessions et des politiques avec d'autres réseaux. L'enregistrement actuel de PeeringDB identifie les installations d'interconnexion et la participation aux points d'échange associés à Virgin Media. Ces détails sont un contexte actuel, pas une reconstruction de la topologie de 2023, mais ils démontrent le nombre de frontières opérationnelles impliquées pour atteindre un grand réseau d'accès. [7]

Quand un réseau retire des routes, les pairs doivent traiter les mises à jour et sélectionner des alternatives si elles existent. Quand une bordure accepte du trafic mais ne peut pas l'acheminer, les pairs peuvent continuer à envoyer des paquets dans un chemin défaillant jusqu'à ce que des mesures ou la coordination avec l'opérateur révèlent le problème. L'incident a donc créé des obligations de preuve des deux côtés de l'interconnexion.

Virgin Media contrôlait l'exactitude et l'utilisabilité des routes qu'il annonçait et le comportement de transfert derrière sa bordure. Les pairs contrôlaient ce qu'ils acceptaient, comment ils surveillaient le chemin et s'ils pouvaient contacter l'opérateur. Les fournisseurs de mesures observaient uniquement depuis les points d'observation qui leur étaient accessibles.

Cette division du contrôle devrait apparaître dans la coordination d'incident. Le rapport d'un pair devrait indiquer quelles routes il a reçues, quelles sessions sont restées actives, où les paquets ont échoué et quand le comportement a changé. L'opérateur devrait reconnaître si cette vue correspond à sa propre télémesure. Les observations contradictoires devraient être conservées plutôt que normalisées trop tôt en une chronologie unique.

Les données de contact sont importantes ici. Les enregistrements de registre et PeeringDB peuvent fournir des contacts NOC ou de politique. Leur valeur est pratique: un réseau affecté peut-il joindre une personne autorisée à agir? Une adresse qui existe mais n'est pas surveillée n'est pas un contrôle opérationnel. Un chemin de contact doit être testé et maintenu sans transformer le registre en une revendication de gouvernance sur l'opérateur.

La coordination affecte également la récupération des clients. Les réseaux de contenu et les clients entreprises disposant de plusieurs fournisseurs peuvent détourner le trafic d'un chemin défaillant. Les clients résidentiels ne peuvent généralement pas choisir un système autonome alternatif de dernier kilomètre pendant un incident. Cette asymétrie confère plus de responsabilité de continuité au fournisseur d'accès.

Les clients ne doivent pas être blâmés pour ne pas avoir contourné une perturbation d'accès à l'échelle du système autonome qu'ils ne contrôlent pas. Les grands pairs devraient tout de même tester leurs propres procédures de routage et d'escalade, mais leur préparation n'efface pas la responsabilité de l'opérateur quant à l'exactitude de l'état des routes et du transfert.

La surveillance doit être indépendante du réseau défaillant

Une panne qui affecte le routage peut également isoler les outils utilisés pour diagnostiquer et communiquer à son sujet. Les systèmes de statut, les collecteurs de télémesure, les services d'authentification et les portails de support peuvent partager le même chemin réseau. Si tel est le cas, l'opérateur peut perdre à la fois le service et les preuves en même temps.

Une surveillance indépendante devrait donc se situer en dehors du domaine de défaillance de production. Les collecteurs de routes externes, les sondes actives et les mesures tierces peuvent tester ce que voient les autres réseaux. La télémesure interne reste nécessaire car elle explique l'état des périphériques et des politiques. Aucune de ces deux vues n'est suffisante seule.

Le compte rendu de Cloudflare et l'analyse de ThousandEyes illustrent la valeur de l'observation externe. Ils ont pu détecter l'effondrement du trafic, le retrait de route et la défaillance de bordure sans accès aux systèmes internes de Virgin Media. Leurs données ne pouvaient cependant pas identifier l'événement interne déclencheur. [1][2]

L'opérateur devrait corréler les preuves externes et internes par horodatage, préfixe, bordure et famille d'adresses. Les sources de temps doivent être suffisamment fiables pour que les intervenants puissent comparer les enregistrements. Une erreur d'horloge de cinq minutes peut fausser l'ordre apparent du retrait de route, de la défaillance de transfert et de l'action de l'opérateur.

La surveillance a également besoin de tests négatifs. Il ne suffit pas de confirmer qu'une route existe. Les sondes doivent tester des destinations à l'intérieur de préfixes représentatifs. Il ne suffit pas de confirmer qu'une bordure répond. Les tests doivent vérifier que le trafic client peut la traverser. Il ne suffit pas de confirmer qu'un portail se charge depuis l'intérieur du réseau. Les clients externes doivent pouvoir l'atteindre.

L'objectif de conception n'est pas de produire une vue globale parfaite. C'est irréaliste. Il s'agit de rendre explicites les angles morts et de s'assurer qu'aucun domaine de défaillance unique ne fournisse toutes les preuves utilisées pour déclarer la récupération.

La divulgation publique doit préserver les inconnues

Les post-mortems réseau sont souvent confrontés à des pressions contradictoires. Les clients veulent une explication. Les ingénieurs ont besoin de temps pour vérifier. Les équipes de sécurité peuvent restreindre les détails. Les équipes juridiques peuvent éviter les déclarations qui pourraient créer une responsabilité. Le résultat peut être un langage si général qu'il n'offre aucune preuve opérationnelle.

Une divulgation responsable peut rester délimitée sans être vide. Elle peut énoncer les services et préfixes affectés à un niveau approprié, le mode de défaillance observé, la période de retrait de route, la période de défaillance de transfert en bordure, les étapes de restauration, l'intervalle de validation et les contrôles modifiés par la suite.

Elle doit distinguer l'observation de l'inférence. « Les routes vers ces groupes de préfixes ont été retirées » est une observation. « Une dépendance du plan de contrôle était en détresse » peut être une inférence. « Un processus d'un fournisseur particulier a échoué » nécessite des preuves directes.

Les sources publiques utilisées ici préservent cette distinction. ThousandEyes a déclaré que le comportement de bordure suggérait une contrainte systémique affectant probablement le plan de contrôle. Cet article ne réécrit pas cette déclaration comme une cause profonde confirmée du plan de contrôle. [2]

Les inconnues doivent rester visibles: l'événement déclencheur, le responsable de la décision interne, l'ensemble exact des équipements, la portée complète sur les clients, si les deux perturbations partageaient une même cause et la remédiation durable ne sont pas établis par l'ensemble des sources. Les préserver est une forme d'exactitude, pas une faiblesse.

La question de la responsabilité est alors de savoir si la partie ayant accès aux preuves manquantes a produit un enregistrement adéquat. Les analystes externes ne doivent pas combler une lacune de divulgation par des spéculations confiantes. Les opérateurs ne doivent pas utiliser l'impossibilité de certitude extérieure comme raison de ne rien publier.

Les recours clients font partie de la responsabilité réseau

Les preuves de routage et de transfert peuvent sembler éloignées de la facturation et du support client, mais elles déterminent si les clients peuvent prouver une perte de service admissible. Un fournisseur d'accès contrôle à la fois l'enregistrement technique et une grande partie du processus initial de recours.

Le cadre d'indemnisation automatique de l'Ofcom vise à fournir un remboursement pour les pannes de service haut débit et de téléphonie fixe spécifiées, sans que les clients aient à formuler une réclamation classique. Virgin Media figure en tant que entité. Virgin Media publie également ses propres directives d'indemnisation et des informations sur les travaux planifiés. [16][17][18]

Ces pages sont actuelles. Cet article ne présume pas que chaque montant, règle ou condition d'éligibilité actuelle s'appliquait sans changement en avril 2023. Toute utilisation de la politique devrait préciser la date et ne devrait pas affirmer que chaque client affecté par l'événement de routage était automatiquement éligible.

Le principe de responsabilité est plus large qu'un paiement unique. L'opérateur devrait conserver suffisamment de preuves d'état de service pour déterminer quand une perte totale a commencé et s'est terminée, quels produits ont été affectés et si une exception s'applique. Les clients ne devraient pas avoir à faire de la rétro-ingénierie BGP pour établir que leur service a échoué.

Les canaux de communication doivent également survivre à l'incident. Si une page de statut, un portail de support ou un service téléphonique dépend du même réseau défaillant, les clients peuvent être incapables de signaler la panne ou de voir les mises à jour. La page actuelle des travaux planifiés de Virgin Media oriente les clients vers des services alternatifs en cas de perturbation planifiée. Les incidents non planifiés nécessitent une voie de communication tout aussi indépendante. [17]

Les données de recours peuvent améliorer la responsabilité technique. Le nombre et la durée des enregistrements validés de perte de service montrent l'impact en termes clients. Les motifs de réclamation peuvent révéler des différences régionales ou de produits que les graphiques de trafic agrégés masquent. Ces informations devraient alimenter l'examen post-incident sans remplacer les preuves techniques.

La bonne norme est la traçabilité. Une période de panne orientée client devrait pouvoir être rapprochée des preuves de route et de transfert, tandis que les exceptions devraient avoir une raison documentée. Cela réduit les litiges et dissuade les déclarations de rétablissement qui sont techniquement étroites mais commercialement prématurées.

Les preuves de registre et de sécurité de routage doivent rester dans leur rôle approprié

Un ASN, un enregistrement de préfixe, un objet de route ou une autorisation RPKI permet d'établir qui est autorisé à annoncer un espace d'adressage et comment les autres réseaux peuvent valider les revendications. Ces enregistrements importent pour la surface de responsabilité, mais ils ne garantissent pas la disponibilité.

Les outils actuels montrent l'identité réseau d'AS5089 et les ressources annoncées. PeeringDB identifie l'opérateur et le contexte d'interconnexion. Les services dérivés de RIPE exposent les informations d'enregistrement et de préfixes. Les outils BGP montrent les observations de routage présentes. [6][7][8][9][10][11]

L'article ne doit pas utiliser ces pages actuelles pour affirmer quelles routes étaient présentes à chaque instant en 2023. L'analyse d'incident historique doit s'appuyer sur les observations datées de Cloudflare et ThousandEyes. Les enregistrements actuels sont utilisés pour rattacher l'entité et expliquer la surface de contrôle.

RPKI a également un rôle limité. La validation de l'origine de la route peut aider les réseaux à évaluer si un ASN d'origine est autorisé pour un préfixe. Elle ne prouve pas que l'origine autorisée peut acheminer les paquets, que ses routes internes sont saines ou que sa bordure acceptera le trafic. Une route peut être valide d'après son origine et pourtant aboutir à un trou noir.

Cette distinction s'aligne sur la couche de réalité. Les métadonnées de sécurité améliorent la qualité des décisions de routage. Elles ne remplacent pas les preuves de code en cours d'exécution. La responsabilité exige à la fois des enregistrements précis et un service observé.

La même prudence s'applique à l'approche de rejet par défaut de la RFC 8212 et aux pratiques MANRS. Elles réduisent les classes de propagation accidentelle de routes et améliorent la coordination. Ce ne sont pas des explications universelles pour un effondrement de la joignabilité, et un contrôle général ne peut pas établir un diagnostic rétrospectif.

Une norme de preuve pratique pour la récupération des réseaux d'accès

L'incident Virgin Media suggère un enregistrement de récupération concret que d'autres réseaux d'accès peuvent adopter. Cet enregistrement devrait être conçu avant une panne, car les preuves rassemblées après coup sont facilement incomplètes.

Premièrement, préserver l'état des routes. Pour chaque groupe de préfixes affecté, enregistrer les annonces, les retraits, les sessions de pairs, les versions de politique et les horodatages. Inclure suffisamment d'informations pour montrer quels chemins externes ont disparu et lesquels sont restés. Ne pas publier la configuration sensible pour les clients, mais la conserver pour un examen interne et réglementaire.

Deuxièmement, préserver l'état de transfert. Lancer des sondes depuis divers réseaux externes vers des destinations représentatives. Enregistrer où le trafic s'est arrêté, si la bordure l'a accepté et si les destinations internes ont répondu. Séparer IPv4 et IPv6. Séparer les dépendances résidentielles, professionnelles, DNS et de gestion lorsque leurs chemins diffèrent.

Troisièmement, préserver l'état des changements. Enregistrer les déploiements, la maintenance, les décisions d'automatisation et les actions de retour en arrière autour de la fenêtre d'incident. Si aucun changement n'a causé l'événement, ne le dire qu'après avoir vérifié l'enregistrement. Si la cause reste inconnue, préserver ce statut et la limite de l'enquête.

Quatrièmement, définir des critères de récupération. Exiger une stabilité des routes, un succès de transfert, une santé applicative et une amélioration de l'impact client pendant un intervalle défini. Éviter de déclarer la récupération complète dès la première sonde réussie ou la première réannonce de route.

Cinquièmement, tester le risque de récurrence. Comparer l'état restauré avec l'état avant l'incident. Identifier les dépendances qui sont restées dégradées. Poursuivre une surveillance renforcée pendant au moins un cycle de charge normal. Si une deuxième perturbation se produit, préserver les différences plutôt que d'écraser la première chronologie.

Sixièmement, se coordonner avec les pairs. Fournir un chemin NOC testé et un moyen structuré pour les autres réseaux de signaler les observations de route et de transfert. Reconnaître les preuves contradictoires. Les rapports externes peuvent révéler des défaillances invisibles de l'intérieur de l'opérateur.

Septièmement, communiquer par couches. Donner aux clients une déclaration de service concise et une voie de recours. Donner aux parties prenantes techniques une chronologie délimitée du routage et du transfert. Donner aux régulateurs suffisamment de preuves pour évaluer la durée, la portée et la réponse.

Huitièmement, rapprocher les recours. Relier les périodes validées de perte de service aux systèmes d'indemnisation et de réclamation sans exiger des clients qu'ils comprennent le mécanisme réseau. Indiquer les dates des politiques et les limites d'éligibilité.

Neuvièmement, examiner les concentrations. Identifier les systèmes de support, de statut, d'authentification et de télémesure qui partagent le réseau affecté. Déplacer les preuves et les voies de communication critiques en dehors du domaine de défaillance lorsque cela est possible.

Dixièmement, publier une remédiation durable. Une promesse d'améliorer la surveillance n'est pas suffisante. Indiquer quel signal a été ajouté, quel seuil a changé, quelle limite de déploiement a été introduite, quel test de récupération est devenu obligatoire et comment le contrôle sera audité.

Ce cadre ne présuppose pas que chaque panne puisse être évitée. Il exige que l'opérateur puisse identifier la limite de la défaillance, restaurer le service en toute sécurité et prouver ce qui a changé.

La responsabilité doit suivre les capacités, pas le recul

Une panne d'un grand réseau d'accès affecte des millions de relations entre clients, services et autres réseaux. Cette échelle crée une tentation d'attribuer une responsabilité illimitée à un seul opérateur ou, à l'inverse, de qualifier l'événement de panne Internet inévitable. Aucune de ces approches n'est précise.

Virgin Media devrait être responsable des contrôles qu'il possédait: annonce de route, transfert de bordure, récupération interne, communication opérationnelle et recours client. Il ne devrait pas être tenu pour responsable de faits que les preuves publiques n'établissent pas, comme une défaillance d'un fournisseur nommé ou un acte malveillant.

Les pairs devraient être responsables de leur propre acceptation de route, surveillance et escalade. Les fournisseurs de contenu devraient être responsables d'une conception réaliste des dépendances et de la communication. Les régulateurs devraient être responsables de cadres de recours qui peuvent utiliser des preuves techniques sans imposer aux clients des charges de preuve impossibles.

Les fournisseurs de mesures devraient indiquer les limites de leurs points d'observation. Leurs observations sont précieuses parce qu'elles sont indépendantes, pas parce qu'elles sont omniscientes. Les analystes et journalistes devraient préserver ces limites.

Les clients ont le moins de contrôle sur la frontière du système autonome. Les utilisateurs résidentiels ne peuvent généralement pas contourner leur fournisseur. Leur principale responsabilité est de signaler l'impact et d'utiliser les recours disponibles, pas de concevoir un deuxième réseau d'accès.

Une responsabilité fondée sur les capacités évite le recul. Elle demande ce que chaque partie pouvait observer, décider, changer et prouver au moment donné. Elle expose également les preuves manquantes sans inventer de cause.

Conclusion

Les perturbations de Virgin Media du 4 avril 2023 étaient des événements d'infrastructure réseau, car l'état des routes et du transfert déterminait si AS5089 existait en tant que chemin utilisable depuis l'Internet global. La majeure partie de la perte de trafic observée s'accompagnait d'un manque de routes BGP viables. Certaines routes sont restées, mais le trafic a tout de même échoué à la bordure de l'opérateur. Le service est ensuite revenu puis a de nouveau échoué plus tard dans la journée. [1][2]

Ces faits suffisent à définir une norme de responsabilité même si la cause profonde reste non divulguée. La récupération doit être prouvée à travers la disponibilité des routes, le transfert de paquets et le service visible par le client. Les données de registre doivent identifier le réseau sans être confondues avec la vérité opérationnelle. Les mesures externes doivent tester les affirmations de l'opérateur sans prétendre révéler l'état interne. Les recours clients doivent se connecter à la même chronologie de preuves.

Le meilleur enregistrement post-incident ne revendiquerait pas de certitude que les sources ne peuvent étayer. Il montrerait quelles routes ont changé, ce qu'ont fait les paquets, ce qu'ont vécu les clients, ce que l'opérateur a changé et comment la stabilité de la récupération a été vérifiée. C'est la différence entre un réseau qui revient brièvement et un opérateur qui démontre que le service a été restauré.

Pour les incidents futurs, cette preuve devrait être assemblée au fur et à mesure des opérations plutôt que reconstruite après que l'inquiétude publique ne monte. Les mises à jour de route, les sondes de transfert, les signaux d'impact client, les enregistrements de changement et les avis de statut devraient partager une chronologie rapprochée. L'opérateur devrait publier suffisamment de cet enregistrement pour montrer le mode de défaillance, le test de récupération et le changement de contrôle durable, tout en protégeant les détails sensibles pour les clients et la sécurité.

Un réseau qui peut produire ces preuves est mieux placé pour apprendre des défaillances, se coordonner avec les pairs et offrir des recours équitables. Un réseau qui ne peut pas les produire peut restaurer les paquets, mais il ne peut pas démontrer pourquoi les mêmes conditions ne se reproduiront pas.

Sources

  1. Cloudflare, « Le point de vue de Cloudflare sur la panne de Virgin Media au Royaume-Uni »:https://blog.cloudflare.com/virgin-media-outage-april-4-2023/
  2. ThousandEyes, « Analyse de la panne de Virgin Media UK: 4 avril 2023 »:https://www.thousandeyes.com/blog/virgin-media-uk-outage-analysis-april-4-2023
  3. The Register, « Virgin Media au Royaume-Uni subit une panne massive de haut débit »:https://www.theregister.com/on-prem/2023/04/04/uks-virgin-media-suffers-massive-broadband-outage/1495714
  4. ThousandEyes, « Les principales pannes Internet de 2023 »:https://www.thousandeyes.com/blog/top-internet-outages-2023
  5. Cloudflare, « Résumé des perturbations Internet du T2 2023 »:https://blog.cloudflare.com/q2-2023-internet-disruption-summary/
  6. Cloudflare Radar, trafic AS5089:https://radar.cloudflare.com/traffic/as5089
  7. PeeringDB, AS5089 Virgin Media:https://www.peeringdb.com/net?asn=5089
  8. bgp.tools, AS5089 Virgin Media Limited:https://bgp.tools/as/5089
  9. RIPEstat, informations réseau AS5089:https://stat.ripe.net/data/network-info/data.json?resource=AS5089
  10. RIPEstat, préfixes annoncés AS5089:https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS5089
  11. Base de données RIPE, requête AS5089:https://apps.db.ripe.net/db-web-ui/query?searchtext=AS5089
  12. RFC 4271, « A Border Gateway Protocol 4 (BGP-4) »:https://www.rfc-editor.org/rfc/rfc4271
  13. RFC 7454, « BGP Operations and Security »:https://www.rfc-editor.org/rfc/rfc7454
  14. RFC 8212, « Default External BGP (EBGP) Route Propagation Behavior without Policies »:https://www.rfc-editor.org/rfc/rfc8212
  15. MANRS, programme des opérateurs réseau:https://manrs.org/netops/
  16. Ofcom, « Indemnisation automatique: ce que vous devez savoir »:https://www.ofcom.org.uk/phones-and-broadband/service-quality/automatic-compensation-need-know
  17. Virgin Media, « Nous améliorons le réseau dans votre région »:https://www.virginmedia.com/help/planned-work
  18. Virgin Media, « Indemnisation automatique »:https://www.virginmedia.com/help/billing-and-payments/automatic-compensation