Panne 2021 de Comcast: la limite de table de routage comme test

Résumé

ThousandEyes a signalé deux pannes distinctes de Comcast en novembre 2021. La première a commencé vers 21 h 44, heure du Pacifique, le 8 novembre, et s'est terminée vers 22 h 48. La seconde a commencé vers 5 h 05, le 9 novembre, et s'est terminée vers 6 h 15.[1]
Lors du premier événement, des tests externes ont montré des pertes de paquets sur des chemins traversant le cœur de Comcast de Sunnyvale. Une partie du trafic qui utilisait initialement d'autres chemins est restée fonctionnelle, puis a échoué après avoir été reroutée via Sunnyvale. Cette séquence constitue une preuve relative aux chemins de forwarding observés, et non un inventaire interne complet de la topologie ou de la configuration de Comcast.[1]
Le second événement a eu une empreinte observée plus large. ThousandEyes a indiqué qu'une partie du trafic de la zone centrale et orientale des États-Unis était temporairement dirigée vers Sunnyvale même lorsque les points de terminaison étaient éloignés de la Californie. Certains chemins ont alterné entre perte totale et joignabilité réussie, comportement que l'analyse a décrit comme pouvant être lié à des variations du plan de contrôle.[1][3]
Une revue ultérieure de ThousandEyes a attribué l'incident au dépassement involontaire d'une limite de table de routage.[2] Le paquet public ne précise ni le périphérique exact, ni la table, ni le seuil configuré, ni le comportement logiciel, ni la commande, ni le propriétaire du changement, ni la séquence d'approbation. L'explication par la limite de table doit donc rester une attribution, plutôt qu'un postmortem complet interne de Comcast.
Une limite de table de routage est un contrôle de responsabilité, car les opérateurs peuvent mesurer l'occupation d'une table, le taux de croissance, la marge réservée, les seuils d'alarme, le comportement de panne et la récupération. Il n'est pas divulgué si de telles mesures ont existé ou étaient efficaces en interne chez Comcast dans les sources figées.
Le reroutage n'a pas toujours produit un chemin indépendant. Le trafic redirigé vers le cœur de Sunnyvale altéré a également échoué. La continuité dépend donc de la séparation des domaines de défaillance, pas seulement de l'existence d'un autre calcul de route.
L'enregistrement RDAP d'ARIN pour l'AS7922 fournit un contexte d'attribution des ressources réseau.[9] Il ne révèle pas les routes actives dans un routeur Comcast, l'état du route-reflector interne, la topologie, l'utilisation de la table ou le résultat de forwarding d'un paquet particulier.
Les documents de l'IETF expliquent le fonctionnement de BGP, la convergence, la réflexion de routes, la transition gracieuse et la détection de panne.[10]-[20] Ils fournissent du vocabulaire de contrôle et un contexte de conception ultérieur et plus général. Ils ne prouvent pas quels mécanismes Comcast a déployés en novembre 2021 et ne sont pas des conclusions de faute rétroactives.
Les règles de déclaration des pannes de la FCC établissent un registre de responsabilité pour les pannes de communications qualifiantes.[7][8] Les sources publiques utilisées ici ne dévoilent pas le dépôt confidentiel de Comcast pour cet événement. Une obligation de reporting ne peut être traitée comme un postmortem technique public.
La preuve soutient une conclusion opérationnelle mesurable, pas une accusation. Comcast contrôlait sa capacité de routage interne, sa topologie, ses alarmes, son processus de changement, sa communication client et sa récupération. Les observateurs externes contrôlaient leurs méthodes de mesure. Les régulateurs contrôlaient les exigences de reporting. Le corpus public disponible n'établit ni intention, ni négligence, ni responsabilité légale ni responsabilité individuelle.

La question de la responsabilité

Les incidents de novembre 2021 sont importants car Internet ne s'est pas arrêté comme un « cloud » abstrait. Des chemins de trafic spécifiques ont cessé de faire du forwarding, certains calculs alternatifs ont dirigé le trafic vers le même cœur perturbé, et le service est revenu quand l'état du réseau a changé. Il s'agit d'une séquence opérationnelle observable. Elle crée une question de responsabilité plus ciblée que celle de savoir si un grand fournisseur doit jamais subir une panne.

La question est de savoir si les contrôles qui régissaient la capacité des tables de routage et le comportement du domaine de défaillance étaient testables avant l'événement. Un opérateur peut connaître le nombre de routes que supporte un appareil ou un processus. Il peut connaître l'occupation actuelle, la vitesse de croissance de l'état, la capacité réservée à la convergence, le comportement aux seuils d'avertissement et de limite stricte, et si des éléments de contrôle redondants partagent le même plafond. Il peut tester si un nœud ou une région défaillant(e) entraîne le trafic vers un chemin indépendamment opérationnel.

Il peut conserver des preuves indiquant quand les alarmes ont déclenché, qui a agi, ce qui a changé et comment le forwarding a récupéré.

Les preuves publiques ne révèlent pas les réponses de Comcast à ces questions. ThousandEyes a fourni des observations externes depuis ses propres points de vue et a ensuite attribué l'incident à une limite de table de routage dépassée.[1][2] Il n'a pas publié l'archive de configuration de Comcast, la télémétrie interne, les enregistrements d'approbation ou la revue complète de l'incident.

Les pages d'architecture de Comcast décrivent un réseau large et distribué, mais elles n'ont pas été écrites comme le postmortem de ces deux événements.[5][6] L'analyse de responsabilité doit donc séparer ce qui est observable de ce qui reste dans la frontière probatoire de l'opérateur.

Cette séparation n'est pas un argument pour abandonner l'analyse. Elle définit l'unité de responsabilité correcte. Comcast contrôlait le système interne dans lequel la limite a été atteinte et où la récupération a été exécutée. ThousandEyes contrôlait ses mesures et son interprétation, pas les routeurs de Comcast. ARIN contrôlait l'exactitude et la disponibilité de l'enregistrement de ressource AS7922, pas les routes installées dans le cœur de Sunnyvale.[9] La FCC contrôlait les exigences et l'accès au reporting, pas les décisions de forwarding en temps réel.[7][8]

La conclusion qui en découle est pratique: une revendication de continuité n'est crédible que lorsque capacité, topologie et récupération peuvent être démontrées dans des systèmes en fonctionnement. Un schéma d'architecture peut montrer plusieurs nœuds. Un protocole de routage peut calculer plusieurs chemins. Un registre peut identifier correctement un système autonome. Aucun de ces faits, pris isolément, ne prouve que le trafic évitera un domaine impairé commun quand une limite de table est atteinte.

Chronologie médico-légale à deux événements

La chronologie provient de mesures externes et doit rester qualifiée comme telle. Une plate-forme de supervision de chemins voit des tests sélectionnés depuis des points de vue sélectionnés. Elle peut révéler des pertes de paquets, des changements de chemin et des motifs récurrents. Elle ne peut pas voir chaque commande interne, chaque route dans chaque table ou chaque session client.

La chronologie suivante enregistre des observations sans les convertir en journal interne imaginé.

Heure	Événement étayé
Avant 21 h 44, heure du Pacifique, le 8 novembre	Le paquet public ne précise pas de changement déclencheur, d’événement de croissance de table, d’alarme d’appareil ou d’action de maintenance interne. Les chemins externes utilisés par l'analyse ultérieure fonctionnaient avant la perte observée.
Environ 21 h 44	ThousandEyes a placé le début de la première panne à peu près à ce moment. Les tests dont le trafic traversait le cœur de Sunnyvale ont commencé à montrer des pertes.[1]
De 21 h 44 à 21 h 46 environ	Certains chemins voisins hors de Sunnyvale ont continué de fonctionner. L'observation est importante car elle montre que la panne n'était pas uniformément présente sur chaque chemin mesuré.[1]
À partir d'environ 21 h 46	Une partie du trafic a été reroutée via Sunnyvale puis a subi la même perte totale. Le registre public montre un changement de chemin suivi d'une panne, mais pas la décision interne ni la route qui a provoqué chaque changement.[1]
Environ 22 h 48	La première panne observée a pris fin. Les chemins précédemment reroutés sont revenus vers leurs routes d'origine, tandis qu'une partie du trafic traversant Sunnyvale utilisait un autre ensemble de nœuds de Sunnyvale. Le registre public ne précise pas la commande corrective ou la séquence exacte de convergence.[1]
Entre les événements	Le paquet ne révèle pas si une condition partagée a persisté, si un changement a été tenté, ou si le second événement avait le même déclencheur immédiat. Les deux incidents ont présenté un comportement similaire, mais une similarité ne prouve pas une cause interne ininterrompue.
Vers 5 h 05, le 9 novembre	Le second événement a commencé. ThousandEyes a observé une perte totale sur certains chemins traversant Sunnyvale.[1]
Pendant le second événement	Une partie du trafic d'autres régions américaines a été redirigée vers Sunnyvale et a échoué. Le trafic Chicago vers Chicago figurait parmi les exemples utilisés pour illustrer le chemin géographique inattendu.[1]
Pendant le second événement	Certains chemins mesurés ont alterné entre perte et joignabilité réussie. ThousandEyes a évoqué un churn du plan de contrôle comme explication possible de cette évolution variable.[1]
Environ 6 h 15	La seconde panne observée a pris fin et les chemins impactés ont de nouveau atteint leurs destinations. Le paquet public ne précise pas si la récupération provenait d'un rollback, d'un changement de capacité, d'un redémarrage de processus, d'un retrait de route ou d'une autre action.[1]
Revue ultérieure	La revue annuelle de ThousandEyes a attribué l'incident à un dépassement involontaire d'une limite de table de routage.[2] Cette explication tardive fournit le mécanisme gelé, mais non un arbre complet de causes internes.

Cette chronologie soutient trois conclusions. Premièrement, les deux événements étaient séparés dans le temps et ne doivent pas être fusionnés en une panne continue sans preuve interne. Deuxièmement, le cœur de Sunnyvale a été central dans les pannes observées. Troisièmement, le reroutage pouvait élargir le périmètre impacté lorsque le calcul alternatif envoyait le trafic vers le même cœur perturbé.

Elle ne soutient pas une affirmation selon laquelle tous les abonnés Comcast étaient hors ligne, ni que tous les chemins ont traversé Sunnyvale, ni que la limite a affecté tous les routeurs de la même manière. Elle ne révèle pas si une limite stricte a entraîné le rejet, le retrait, le vidage ou le recalcul répété des routes. Elle n'établit pas si la table était une base d'informations de routage BGP, une table de forwarding, une structure propre à une plateforme, ou une autre ressource du plan de contrôle. Ces distinctions restent des inconnues essentielles.

Ce que peut établir la preuve de chemin externe

Les mesures externes sont plus robustes quand elles décrivent les résultats de forwarding. Un test envoie du trafic depuis un point de vue connu vers une destination connue, enregistre les sauts et les pertes, puis compare le chemin avant, pendant et après un incident. Quand de nombreux tests partagent une interface ou un lieu impacté, la preuve peut identifier un point de panne observable commun.

Pour le premier événement de Comcast, la comparaison entre des chemins réussis hors de Sunnyvale et des chemins défaillants via Sunnyvale crée une frontière significative. Elle indique que la panne observée a suivi le placement du trafic. Quand du trafic voisin a ensuite été redirigé via Sunnyvale puis a échoué, la séquence montrait que la route alternative ne sortait pas du domaine affecté.[1]

Le second événement a ajouté une anomalie géographique. Une partie du trafic ayant des points de terminaison au centre ou à l'est des États-Unis a été observée traversant Sunnyvale. Un chemin peut être techniquement valide tout en étant opérationnellement indésirable pendant une panne. BGP et les systèmes de routage internes choisissent des chemins selon des politiques configurées et l'état disponible; ils ne comprennent pas l'intuition d'un client selon laquelle le trafic local devrait rester localement local.[10] Le contrôle de responsabilité n'est donc pas une intuition. C'est une exigence de politique et de topologie testable.

Les preuves de chemin externe ont des limites. Un saut visible peut ne pas répondre à toutes les questions sur l'encapsulation, les labels internes, la reflection de routes ou l'ECMP à coût égal. Des interfaces non répondantes peuvent compliquer l'interprétation. Un chemin vu depuis un point de vue n'est pas une route universelle. Une perte de paquets à un saut nommé ou après ne prouve pas toujours que l'interface qui répondait a causé la perte. Les conclusions de ThousandEyes doivent être lues comme des observations de fournisseur de mesure, pas comme un accès privilégié à chaque routeur.

Ces limites rendent la corrélation et la rétention importantes. Les opérateurs peuvent conserver leur propre état de routes, compteurs d'interfaces, occupation de tables et dossiers de changement en parallèle des données externes de chemin. Une revue ultérieure peut ensuite tester si un déplacement externe de chemin correspond à un événement interne connu. Sans preuve jointe, les acteurs extérieurs peuvent identifier le domaine de panne mais pas reconstituer la séquence complète de contrôle.

La capacité de table de routage est un contrôle de continuité

Les systèmes de routage stockent plusieurs types d'état. Les speakers BGP reçoivent des mises à jour, appliquent des politiques, sélectionnent des chemins et annoncent des résultats autorisés.[10] Les implémentations peuvent maintenir des routes reçues, acceptées, sélectionnées et installées dans des structures séparées. Un route-reflector peut réduire le besoin d'un maillage complet de sessions BGP internes, tout en faisant partie du chemin de distribution des informations de routage.[12] Le matériel et le logiciel imposent des limites de mémoire, d'entrées de forwarding, de ressources de processus et de routes supportées.

L'expression « limite de table de routage » doit donc être précise. Un maximum configuré peut être une garde-fou volontaire. Une capacité de plateforme peut être une contrainte d'ingénierie stricte. Un processus peut saturer la mémoire avant d'atteindre le nombre de routes nominal. Un mécanisme de session maximum-prefix peut fermer une session ou avertir un opérateur. Une table de forwarding peut avoir une capacité différente d'une table de plan de contrôle. Les preuves publiques figées ne précisent pas quelle condition est survenue dans le réseau de Comcast.

Cette incertitude ne rend pas la capacité non auditable. Un opérateur peut consigner l'identité de chaque table pertinente, ses limites prises en charge et configurées, l'occupation normale, l'occupation de pointe, la marge de convergence réservée et la croissance attendue. Il peut définir des seuils d'alerte sous le point de panne et tester la chaîne de livraison d'alerte. Il peut simuler une augmentation contrôlée de l'état de route et vérifier si l'appareil n'admet que l'excédent, protège le forwarding établi, redémarre un processus, retire des routes ou produit un churn.

La marge doit être définie par rapport à un scénario de panne, pas à une journée moyenne. Lors d'une convergence, un routeur peut temporairement conserver les anciens et les nouveaux chemins. Une maintenance peut faire apparaître des routes alternatives. Une erreur de politique peut augmenter l'état accepté. Un changement de route-reflector peut modifier les chemins visibles. La marge correcte inclut donc l'état transitoire et le temps nécessaire à un opérateur pour agir.

Un enregistrement de capacité utile contiendrait au moins six mesures:

l'occupation actuelle de chaque structure de routage et de forwarding;
la limite stricte de la plateforme et tout seuil configuré inférieur;
l'occupation transitoire la plus élevée observée pendant une convergence testée;
le seuil d'avertissement et le délai de livraison de l'alerte vérifié;
le comportement documenté aux seuils d'avertissement et de limite stricte; et
la procédure de récupération, y compris la preuve requise avant que le trafic ne soit rétabli.

L'incident de novembre rend cet enregistrement important car la panne observée n'est pas restée locale au trafic déjà dans Sunnyvale. Une partie du trafic a été redirigée vers le cœur et a échoué là-bas.[1] Si une limite de table sur un nœud ou un cluster peut attirer des chemins additionnels pendant la convergence, la limite devient un contrôle de rayon d'impact. Les tests de capacité doivent donc vérifier non seulement si un appareil résiste, mais aussi comment le reste du réseau réagit à sa défaillance partielle.

Aucune source du paquet n'établit que Comcast ne possédait pas ces mesures. La preuve montre qu'une limite a été dépassée plus tard, et que les chemins observés extérieurement ont échoué. La conclusion de responsabilité est que les mesures pertinentes doivent pouvoir être révisées. Ce n'est pas la preuve que leur absence a été établie.

Pourquoi le reroutage n'était pas une résilience indépendante

On décrit souvent les réseaux comme résilients parce qu'un trafic peut emprunter un autre chemin. Cette affirmation omet la question essentielle: indépendant de quoi? Deux chemins peuvent utiliser des interfaces différentes tout en partageant un route-reflector, une version logicielle, un plafond de table, un domaine d'alimentation, un cœur métropolitain, un processus de maintenance ou une source de configuration commune. Un nouveau calcul de chemin peut donc préserver la même panne sous-jacente.

Le premier événement Comcast fournit un exemple concret. Une partie du trafic hors de Sunnyvale est restée d'abord réussie. Après avoir été redirigée via Sunnyvale, elle a également échoué.[1] Le protocole a trouvé une route, mais la route est entrée dans un domaine perturbé. Du point de vue de l'utilisateur, l'existence d'un second calcul n'a pas créé la continuité.

L'analyse de domaine de défaillance doit être réalisée à plusieurs couches. La diversité physique vérifie si liens, sites et alimentations sont séparés. La diversité du plan de contrôle vérifie si la distribution et la décision peuvent échouer de manière indépendante. La diversité de capacité vérifie si les nœuds alternatifs ont une capacité de table indépendante et suffisante. La diversité opérationnelle vérifie si une même modification, un même système d'automatisation ou une même approbation peuvent affecter toutes les alternatives supposées.

La diversité d'observabilité vérifie si la supervision reste disponible quand le plan de contrôle de production est compromis.

Un cœur de type Clos peut fournir plusieurs chemins et une échelle horizontale. ThousandEyes a évoqué l'utilisation par Comcast d'une architecture spine-leaf en interprétant l'événement.[1] Ce contexte architectural explique pourquoi le comportement au niveau des nœuds et du tissu est pertinent. Il ne dévoile pas la topologie de production exacte du cœur affecté ni ne prouve que chaque chemin partageait la même dépendance de contrôle.

La vérification correcte est adversariale mais bornée. Les opérateurs peuvent retirer un nœud, isoler un route-reflector, contraindre une table, retarder une mise à jour et observer où se déplace le trafic. Le test doit confirmer que le chemin alternatif évite le domaine de panne physique et logique initial, qu'il dispose d'une capacité suffisante et qu'il ne crée pas de détour géographique inattendu. Les résultats doivent être saisis dans des mesures de forwarding tant depuis l'intérieur que depuis l'extérieur du réseau.

La résilience se démontre quand le chemin alternatif supporte du trafic dans la défaillance testée. Elle ne se démontre pas parce qu'un schéma de topologie contient plusieurs lignes.

Convergence, reflection de routes et chemins changeants

BGP ne met pas à jour instantanément Internet ou un grand réseau interne. Les routeurs reçoivent des changements à des moments différents, appliquent des politiques locales et annoncent de nouveaux résultats. La RFC 4277 analyse la convergence et les délais ou états transitoires pouvant survenir après des changements de routage.[11] Les route-reflectors modifient la structure de propagation dans un système autonome en permettant aux clients d'échanger des routes sans maillage interne complet.[12]

ThousandEyes a observé que certains chemins Comcast alternaient entre perte totale et joignabilité normale pendant le second événement et a identifié un churn du plan de contrôle comme explication possible.[1] Les preuves publiques ne montrent pas les mises à jour précises responsables. Elles établissent néanmoins pourquoi le comportement de convergence doit être dans une revue de capacité. Un système proche d'une limite peut réagir différemment quand d'anciens et de nouveaux chemins coexistent ou quand des sessions se réinitialisent et repopulent l'état.

Les mécanismes restart et shutdown gracieuses traitent des problèmes particuliers de transition. La RFC 4724 décrit la préservation de l'état de forwarding pendant certains redémarrages BGP.[13] La RFC 6198 fixe des exigences de réduction de perte quand une session BGP est fermée volontairement, et la RFC 8326 précise un mécanisme de graceful-shutdown.[15][19] Ces documents ne prouvent pas que ces mécanismes étaient pertinents, disponibles ou déployés dans l'incident de Comcast.

Ils montrent que dire que « le protocole a convergé » n'est pas un standard opérationnel complet. Un événement de convergence peut impliquer des pertes de paquets, des boucles transitoires, un état obsolète ou des changements de chemin qui violent la localisation attendue. Un réseau testé devrait définir un temps de convergence acceptable et une perte autorisée pour chaque classe de défaillance. Il devrait aussi définir ce qui se passe quand une ressource du plan de contrôle, plutôt qu'un lien, atteint une limite.

La réflexion de routes requiert une preuve spécifique car la redondance logique peut encore partager l'état de distribution. Un opérateur doit connaître quels clients dépendent de chaque reflector, si les reflecteurs alternatifs ont une capacité indépendante, comment les chemins sont sélectionnés quand un reflector perd de l'état, et comment une alarme de limite modifie la propagation. L'article n'affirme pas qu'un route-reflector a causé l'incident de Comcast. Il identifie le type de dépendance qu'un postmortem sur limite de table de routage doit examiner.

La détection doit survivre à la panne qu'elle signale

Une détection rapide n'est utile que si l'alerte atteint un opérateur et identifie la surface de contrôle affectée. Le Bidirectional Forwarding Detection peut fournir une détection rapide de certains échecs de chemin de forwarding.[14] Il ne diagnostique pas à lui seul une limite de table de routage. La télémétrie d'appareil peut signaler occupation de table et santé des processus. Les collecteurs de routes et les tests externes de chemin peuvent révéler des changements de joignabilité. Les rapports clients peuvent montrer des symptômes de service. Chaque source voit une partie différente de l'événement.

Une conception d'observabilité responsable relie ces couches. Une alarme de table doit identifier l'appareil, la structure, la valeur actuelle, le seuil configuré et la tendance. Une alarme de routage doit montrer quel état a changé. Une alarme de chemin doit montrer quelles destinations et régions ont perdu leur joignabilité. Un système d'impact client doit relier l'événement réseau aux services touchés sans affirmer plus d'utilisateurs que le permet la preuve.

La supervision doit aussi disposer d'une chaîne de livraison indépendante. Si alertes, tableaux de bord, authentification ou canal d'incident dépendent du même réseau altéré, l'opérateur peut perdre les outils nécessaires à la récupération. Le paquet public Comcast ne dit pas si cela s'est produit. C'est une exigence de continuité mesurable issue de la classe de panne, pas une allégation sur l'événement.

Les mesures externes apportent une vérification distincte de la réalité. ThousandEyes a pu comparer des chemins réussis et défaillants avant la publication détaillée de Comcast.[1][4] Un opérateur peut utiliser une preuve externe similaire pour tester si un statut « vert » interne correspond à un forwarding réussi. La barrière finale de récupération devrait exiger une stabilité interne et une joignabilité externe depuis plusieurs régions.

Cette barrière évite une erreur fréquente: déclarer une reprise lorsque le processus de contrôle a redémarré mais que le forwarding reste instable. Dans la chronologie Comcast, l'état observable final était que les chemins impactés rejoignaient à nouveau leurs destinations.[1] Le registre public ne révèle pas les critères internes de déclaration de récupération, donc aucune comparaison n'est possible. L'incident illustre néanmoins pourquoi la preuve de forwarding doit être incluse dans les critères.

Preuve de registre et réalité opérationnelle

Le service ARIN RDAP enregistre AS7922 comme ressource AS enregistrée.[9] De tels enregistrements comptent. Ils aident les opérateurs et les enquêteurs à identifier l'organisation associée à un numéro de ressource, à maintenir les contacts et à distinguer un réseau d'un autre. Précision, unicité et actualité des registres soutiennent la coordination.

L'enregistrement ne pilote pas BGP. Il ne stocke pas la table de routes complète d'un routeur Comcast, ne sélectionne pas un chemin, n'applique pas un seuil de table et ne redirige pas le trafic de Chicago hors de la Californie. Ces résultats proviennent de logiciels en fonctionnement, d'état installé, de la topologie et de la politique opérateur.

Cette distinction évite deux erreurs. La première consiste à traiter l'attribution de registre comme preuve de toute action interne. Voir AS7922 dans un chemin peut identifier un contexte réseau, mais ne peut pas identifier l'employé, la configuration ou la responsabilité légale derrière une panne. La seconde consiste à rejeter la preuve de registre parce qu'elle ne peut pas imposer le forwarding. Un enregistrement actuel reste utile pour l'attribution et la coordination des incidents, même s'il n'est pas un système de contrôle de chemin.

La responsabilité réseau dépend de la jonction entre la couche registre et la couche réalité. L'identifiant de ressource, l'inventaire d'appareils, la politique de routage, la télémétrie de table, le dossier de changement, l'alarme et l'observation externe de chemin doivent renvoyer au même événement opérationnel. Quand ces liens sont conservés, une revue peut identifier qui a contrôlé chaque décision sans supposer qu'une base de données gouverne l'ensemble du réseau.

Responsabilité du reporting et preuve confidentielle

Les règles de la FCC de la partie 4 et les guides associés créent des obligations de reporting et de tenue de registres pour les pannes de communications qualifiantes.[7][8] Ces règles reconnaissent que la portée géographique, la durée, le nombre d'utilisateurs et les effets de sécurité publique peuvent compter pour la supervision. Elles protègent aussi les informations de panne qui ne sont pas généralement publiques.

Cet article ne dispose pas du dépôt NORS confidentiel de Comcast pour les événements de novembre 2021. Il ne peut donc pas indiquer ce que Comcast a rapporté comme cause racine, comment le nombre d'utilisateurs a été comptabilisé selon les définitions réglementaires, si un seuil a été franchi, ni quelle remédiation a été fournie à la FCC.

Cette frontière est importante car un dépôt réglementaire et un postmortem public servent des audiences différentes. Un régulateur peut recevoir des détails d'infrastructure sensibles qui ne devraient pas être exposés publiquement. Les clients et opérateurs dépendants ont néanmoins besoin d'informations publiques suffisantes pour comprendre la nature d'une panne et évaluer la continuité.

La responsabilité ne requiert pas la publication d'une topologie exploitante, mais exige une explication publique crédible de la classe de panne, de la portée, de la récupération et des mesures préventives vérifiables.

Un registre public utile pourrait indiquer qu'une limite d'état de routage a été dépassée, décrire le domaine de contrôle affecté au niveau approprié, donner les fenêtres d'observation et de récupération, expliquer pourquoi le trafic rerouté est entré dans le même domaine, et lister les contrôles modifiés ensuite. Cela peut être fait sans nommer d'ingénieurs individuels ni publier des configurations de routeur sensibles.

L'absence de ces détails dans le paquet public figé limite les conclusions. Cela ne prouve pas que Comcast n'a pas rapporté confidentiellement ou n'a pas remédié. Cela montre que les acteurs extérieurs doivent s'appuyer principalement sur des mesures externes pour la reconstruction technique.

Responsables de contrôle et obligations de preuve

La responsabilité doit suivre le contrôle opérationnel plutôt que la proximité d'un titre.

Comcast contrôlait la capacité de routage interne.L'opérateur pouvait inventorier ses plateformes, fixer ou accepter des limites, surveiller l'occupation, réserver une marge et tester le comportement de panne. Les preuves incluraient des inventaires d'appareils et de logiciels, de la télémétrie de table, des configurations de limites, des alarmes et des résultats de tests de capacité.

Comcast contrôlait la topologie et la distribution des routes.Il pouvait définir les domaines de panne du cœur, les relations de route-reflector, les préférences de chemin et les contraintes géographiques. Les preuves incluraient topologies approuvées, politiques de routage, cartes de dépendances et résultats de tests d'injection de faute. Le paquet public ne divulgue pas ces éléments.

Comcast contrôlait le changement et la récupération.Il pouvait autoriser les changements, les déployer, conserver l'état avant/après, exécuter rollback et vérifier le forwarding. Les preuves incluraient tickets, approbations, diff, journaux de commandes, décisions d'incident et tests de récupération externes.

Les fournisseurs contrôlaient le comportement produit de leurs produits.Un routeur ou un logiciel peut définir capacité, alarmes et modes de panne. Les sources figées n'identifient pas de fournisseur ni de produit, donc l'article ne peut imposer une obligation spécifique à un fournisseur ni conclure à un défaut.

Les observateurs externes contrôlaient la qualité de mesure.ThousandEyes contrôlait ses points de vues, ses tests, son interprétation de chemins et son analyse publiée.[1]-[4] Son évidence peut montrer des motifs, mais doit expliciter ses limites et rester ouverte à la comparaison avec des données internes.

Les clients contrôlaient seulement leurs choix de continuité.Une entreprise pouvait utiliser plusieurs fournisseurs d'accès, plusieurs chemins ou plusieurs régions applicatives. Ces options peuvent réduire la dépendance, mais ne transfèrent pas la responsabilité de l'état interne de routage de Comcast vers le client. Certains utilisateurs résidentiels ou de service public n'ont pas d'alternative pratique.

ARIN contrôlait la précision et la disponibilité des enregistrements de registre.Il ne contrôlait pas les routes internes de Comcast.[9]

La FCC contrôlait les règles de déclaration et les dossiers de supervision protégés.Elle ne contrôlait pas la décision de routage qui a envoyé un chemin via Sunnyvale.[7][8]

Cette répartition n'est pas une affirmation que chaque acteur a échoué. C'est une carte de qui peut produire les éléments de preuve nécessaires pour évaluer un contrôle donné.

Remédiation mesurable

Le programme de remédiation le plus solide transforme les inconnues de l'incident en tests récurrents.

1. Définir chaque limite pertinente.Pour chaque structure de routage et de forwarding, consigner le maximum de plateforme, le maximum configuré, l'occupation actuelle, la croissance attendue et la réserve d'urgence. Séparer les états reçus, acceptés, sélectionnés et installés lorsque la plate-forme les expose. Un unique nombre total de routes est insuffisant si une structure interne plus petite peut échouer en premier.

2. Déployer des alarmes multi-niveaux.Les seuils d'avertissement doivent laisser assez de temps pour l'investigation avant la limite stricte. Les alertes doivent inclure la structure affectée, la valeur courante, le taux de variation, le voisin ou processus pertinent et une réponse sûre. La livraison de l'alarme doit être testée via une chaîne de gestion indépendante.

3. Tester la marge transitoire.Les modèles de capacité doivent inclure la croissance normale plus l'état supplémentaire créé pendant la maintenance, la reconvergence de route, la restauration de session et le rollback de politique. Le test doit mesurer le pic, pas seulement la table stable finale.

4. Vérifier le comportement en panne.En environnement contrôlé, approcher ou dépasser la limite configurée et enregistrer le comportement du système. Rejette-t-il de nouvelles routes, redémarre-t-il un processus, retire-t-il des routes existantes, préserve-t-il le forwarding, ou produit-il du churn? Une limite documentée sans mode de panne vérifié est incomplète.

5. Cartographier les dépendances de contrôle partagées.Les nœuds redondants doivent être vérifiés pour les mêmes route-reflectors, les mêmes systèmes de configuration, versions logicielles, plafonds de table et chemins de gestion communs. Une cible de basculement qui partage la même ressource limitante n'est pas indépendante.

6. Tester la localité géographique.Définir quelles classes de trafic devraient rester dans une région pendant des pannes données. Utiliser des mesures internes et externes pour vérifier qu'un chemin local n'est pas redirigé vers un cœur éloigné dégradé sans motif explicite et testé.

7. Coupler preuves du plan de contrôle et du forwarding.Une route peut exister dans une table de contrôle alors que les paquets échouent encore. La récupération devrait exiger des tests de forwarding réussis, une perte acceptable et des chemins stables depuis plusieurs points de vue. L'état interne de route et l'observation externe de chemin doivent être alignés temporellement.

8. Préserver les temps de déclenchement, détection, réponse et récupération séparément.L'événement déclencheur peut précéder la première alarme. Un observateur externe peut détecter des symptômes avant que l'opérateur n'identifie la cause. Le rollback peut survenir avant la stabilisation globale des chemins. Un postmortem devrait enregistrer chaque horodatage et source de preuve au lieu d'écraser le tout dans une seule durée de panne.

9. Revoir le comportement route-reflector et convergence.Lorsque la reflection de routes est utilisée, tester le comportement des clients, la capacité d'un reflector alternatif, la visibilité des chemins et la repopulation de l'état.[12] Définir une convergence et une perte acceptables pour chaque panne planifiée.[11] Les mécanismes gracieusement conçus peuvent être évalués quand pertinent sans supposer qu'ils résolvent l'épuisement de table.[13][15][19]

10. Garder une terminologie de politique interdomaines précise.La RFC 7908 définit les fuites de routes, tandis que la RFC 8212 et la RFC 9234 traitent de contrôles explicites et de mécanismes conscients des relations.[17][18][20] Les preuves Comcast de ce paquet concernent des changements internes de chemin et une limite de table. Les opérateurs ne devraient pas étiqueter chaque reroutage inattendu comme une fuite de route, car une mauvaise étiquette oriente la remédiation vers le mauvais contrôle.

11. Exercer la chaîne de dépendance de gestion d'incidents.Le système de supervision, l'authentification, la page de statut, l'assistance client, la communication ingénierie et le chemin de changement devraient rester disponibles quand le cœur de production est perturbé. L'exercice doit inclure la perte de connectivité réseau primaire.

12. Publier un compte technique borné.Un rapport public devrait identifier la classe de panne, la fenêtre temporelle, le domaine de contrôle affecté, la méthode de récupération et les remédiations vérifiées sans dévoiler une topologie sensible. Il devrait distinguer faits mesurés, constats internes et questions non résolues.

Chaque mesure doit avoir une condition de réussite. « Surveiller la taille de table » n'est pas une condition de réussite. « Alerter à une marge définie, livrer l'alerte sur un chemin indépendant dans un intervalle testé, et démontrer que les opérateurs peuvent rétablir une marge adéquate avant la limite stricte » est testable. « Mettre en place de la redondance » n'est pas une condition de réussite. « Lors d'une panne isolée du cœur de Sunnyvale, un trafic spécifié reste joignable sans traverser le domaine isolé et avec une perte sous un seuil défini » est testable.

Les contrôles doivent aussi avoir des propriétaires et des dates d'examen. La capacité peut évoluer avec les clients, peers, préfixes, services et politiques d'ingénierie de trafic. Un résultat positif sur une année ne peut pas établir une sécurité indéfinie. La preuve doit montrer quand le test a été exécuté, avec quel logiciel et quelle topologie, et quelles exceptions demeurent.

Ces propositions ne sont pas la preuve que Comcast ne les a pas mises en place. Elles sont les contrôles mesurables logiquement liés à l'échec observé de manière externe et au mécanisme de limite attribué.

Les normes ultérieures sont un contexte, pas des verdicts

Plusieurs documents IETF de l'ensemble source sont postérieurs ou généralisent au-delà de l'incident. La RFC 8212 décrit le comportement par défaut de rejet lorsque la politique BGP externe n'est pas explicitement configurée.[18] La RFC 9234 décrit les rôles BGP et l'attribut Only-to-Customer pour réduire certaines fuites de route.[20] Aucun de ces documents n'établit la cause d'une limite interne de table de routage ni ne prouve la configuration 2021 de Comcast.

La RFC 7454 regroupe les pratiques opérationnelles et de sécurité BGP.[16] La RFC 6198 et la RFC 8326 traitent des exigences et signalisations de shutdown gracieux.[15][19] La RFC 5880 définit BFD.[14] Elles aident à cadrer les questions de politique, changement planifié et détection. Elles ne doivent pas être présentées comme une checklist que les preuves publiques démontreraient violée par Comcast.

Cette distinction protège l'analyse d'un biais rétrospectif. Les normes peuvent montrer qu'un contrôle était connu ou techniquement possible. Elles ne peuvent établir qu'il était contractuellement exigé, pris en charge sur une plateforme donnée, configuré dans le réseau affecté ou capable de prévenir l'échec exact. Ces conclusions demandent des preuves supplémentaires.

L'article utilise les normes pour définir des alternatives mesurables. Il ne s'en sert pas pour fabriquer une conclusion de faute.

Ce que cet article ne confond pas

Les événements de novembre 2021 ne sont pas la panne 2017 de Comcast associée à une fuite externe de route de Level 3. Cet événement impliquait des routes externes propagées et un mécanisme observé différent. Il ne s'agit pas non plus de la panne de fibre de 2018, où des dommages physiques et des annonces plus spécifiques ont formé un autre historique de récupération. Il ne s'agit pas de l'incident de fuite de données lié à CitrixBleed en 2023, qui concernait un appareil en bordure exposé et des enregistrements d'identité.

L'article ne confond pas non plus tous les reroutages avec une fuite de route. Une fuite de route a un sens politique inter-domaine précis.[17] Le paquet 2021 montre des chemins internes ou contrôlés par fournisseur qui changent et du trafic entrant dans un cœur impairé. Sans annonces de routes pertinentes et preuve relationnelle, qualifier ce comportement de fuite de route serait injustifié.

La panne n'est pas non plus une preuve d'échec de registre. L'enregistrement AS7922 d'ARIN aide à identifier la ressource réseau.[9] Un registre correct ne peut pas empêcher une table de route d'atteindre une limite, et une limite de table n'invalide pas l'enregistrement de registre.

Enfin, l'incident n'est pas une preuve d'attaque. Les sources figées ne posent pas d'action malveillante, d'accès non autorisé, de perturbation délibérée ou d'intention criminelle.

Incertitudes essentielles

La table exacte et le seuil restent inconnus. L'état déclencheur, l'appareil, le logiciel, la commande et le rôle responsable restent inconnus. La topologie et l'occupation de table de chaque nœud de Sunnyvale restent inconnues. L'impact client et de service complet demeure inconnu.

La chronologie interne d'alarmes, les décisions de réponse, la méthode de récupération et les mesures de remédiation post-incident ne figurent pas dans le paquet public figé. Le contenu de tout dépôt de panne confidentiel est indisponible. Aucune source utilisée ici ne démontre un défaut fournisseur, une défaillance individuelle, une négligence, une responsabilité légale ni une perte chiffrée.

Ces lacunes limitent les accusations de faute, pas les questions opérationnelles. Les chemins observés et la limite attribuée identifient encore quelles preuves seraient nécessaires à une revue complète.

Conclusion

La panne de novembre 2021 de Comcast a transformé une borne de capacité en test de responsabilité réseau. ThousandEyes a observé deux incidents centrés sur le cœur de Sunnyvale. Le trafic déjà dans le cœur a échoué, et une partie du trafic auparavant réussie a échoué après redirection vers Sunnyvale. Pendant le second événement, des chemins de régions éloignées ont été dirigés vers la même zone et parfois alterné entre perte et joignabilité.[1][3]

Une revue ultérieure de ThousandEyes a attribué l'incident à une limite de table de routage dépassée involontairement.[2] Cette explication ne précise pas le déclencheur interne exact, mais elle définit une surface de contrôle concrète. L'occupation des tables de routage, les seuils, la marge transitoire, le comportement de panne, les dépendances de topologie, les alarmes, le rollback et la récupération en forwarding peuvent tous être mesurés.

L'événement montre également pourquoi les registres et diagrammes ne suffisent pas. ARIN peut enregistrer correctement AS7922.[9] BGP peut calculer un nouveau chemin.[10] Une topologie peut contenir plusieurs nœuds. La continuité échoue encore si l'état en fonctionnement atteint une limite ou si un chemin alternatif entre dans le même domaine impairé.

La responsabilité repose donc sur la preuve de contrôle opérationnel. Comcast contrôlait le système de routage et sa récupération. Les observateurs externes contrôlaient leurs mesures. Les régulateurs contrôlaient les règles de reporting. Les fournisseurs ont pu contrôler le comportement produit, mais le paquet public ne désigne pas l'un d'eux. Les clients contrôlaient uniquement les alternatives pratiquement disponibles.

La conclusion défendable n'est ni qu'une norme aurait empêché la panne ni qu'un opérateur ne peut jamais échouer. Elle est que la revendication de continuité doit être appuyée par une marge testée, des domaines de défaillance indépendants, une supervision durable, une explication publique bornée et une reprise vérifiée extérieurement. Dans un grand réseau, la résilience n'est pas la présence d'un autre chemin. C'est la preuve que ce chemin fonctionne quand le domaine de contrôle primaire ne le fait pas.

Panne 2021 de Comcast: la limite de table de routage comme test de responsabilité

Pourquoi c'est important