Résumé

  • RIPE NCC attribue l’incident du 2 octobre au volume inhabituel de messages BGP provenant d’un pair au RRC12, à la charge sur une partition Kafka et à un nouveau balayage de données qui expirait à chaque redémarrage.
  • Le service indique que les fichiers d’updates d’autres collecteurs ont également pris du retard. Une correction de configuration a permis la reprise, tandis qu’un correctif structurel restait à venir.

Le point important n’est pas seulement que RRC12 ait cessé de produire ses fichiers. Le compte rendu de RIPE NCC décrit un effet qui a dépassé le lieu où les messages sont entrés dans le système : la production des fichiers d’updates d’autres route collectors a elle aussi été retardée. C’est un incident de production d’éléments de preuve sur le routage. La page de statut ne dit pas que le transfert des paquets sur l’Internet a été interrompu.

Dans son avis d’incident, RIPE NCC situe à 01 h 30 UTC le début d’un envoi inhabituellement intense de messages BGP par un pair de DE-CIX vers RRC12. Le processus qui consommait les messages depuis Kafka n’a pas suivi le rythme et a expiré. Au redémarrage, il tentait de parcourir de nouveau un grand volume de données, puis expirait encore avant d’avancer. L’opérateur a ensuite indiqué qu’une mauvaise configuration dans le code rendait ce parcours dix fois plus long qu’il ne devait l’être. La correction de ce paramètre a permis au processus d’avancer. RIPE NCC annonçait encore un correctif structurel pour le défaut de reprise au sprint suivant.

Deux charges se sont donc succédé. La première a créé un arriéré parce qu’un chemin de traitement ne suivait plus le volume entrant. La seconde a rendu la reprise difficile : chaque redémarrage relançait un parcours important, ralenti par une configuration défectueuse. L’avis public ne donne ni l’identité du pair, ni le débit des messages, ni la profondeur de file, ni les délais d’expiration, ni la topologie exacte des partitions. Il faut garder ces inconnues sans affaiblir le constat publié.

Les fichiers concernés servent à observer le routage. La documentation des collecteurs RIPE RIS décrit des machines physiques ou virtuelles qui recueillent les informations BGP de leurs pairs. Elle situe RRC12 à Francfort, sur DE-CIX. La documentation des fichiers MRT précise que les données sont rangées par collecteur : les dumps décrivent un état du routage, tandis que les fichiers d’updates enregistrent les changements observés pendant un intervalle. Le rythme indiqué est de cinq minutes pour les updates et de huit heures pour les dumps. Il s’agit d’une cadence de service, pas d’une preuve que chaque fichier de l’incident était complet et exploitable.

À 09 h 42 CEST le 2 octobre, la page de statut indiquait que le dernier fichier d’updates disponible pour RRC12 portait l’horodatage 01 h 00 UTC et que le dernier bview portait celui de 00 h 00 UTC. Ce relevé renseigne sur la fraîcheur des archives à cet instant. Il ne fixe pas le début exact de l’arrêt de production, la taille maximale de l’arriéré, ni le moment où tous les utilisateurs ont pu exploiter les données rattrapées. Plus tard, RIPE NCC a indiqué qu’après le rétablissement du processus initial, les fichiers bview et update depuis le 2 octobre avaient été publiés.

C’est une déclaration de rattrapage du fournisseur, pas un audit indépendant des octets ou de l’impact chez les utilisateurs.

La distinction entre un chemin réseau et sa trace archivée est essentielle. Le RFC 6396 définit le format MRT d’export des informations de routage. Un fichier MRT absent limite ce que l’archive permet d’observer à un moment donné. À lui seul, il ne prouve pas qu’une session BGP s’est interrompue, qu’une route a disparu du réseau actif ou qu’un client a perdu sa connectivité. Mais l’incident de collecte n’est pas insignifiant : des opérateurs, chercheurs et équipes d’intervention peuvent dépendre de ces archives pour reconstruire une chronologie. RIPE NCC n’a pas publié de mesure d’un tel impact, et cet article n’en suppose aucun.

La portée annoncée invite à examiner le partage des ressources. Une seule entrée à RRC12 a chargé une partition Kafka, tandis que les fichiers d’updates d’autres collecteurs ont aussi pris du retard selon l’avis. Cela laisse entrevoir une dépendance de traitement commune, sans fournir le schéma complet de l’architecture. La conclusion défendable reste limitée : d’après l’opérateur, les effets ne se sont pas arrêtés au collecteur d’entrée. Des indicateurs de fraîcheur couvrant plusieurs collecteurs et des mécanismes d’isolation deviennent donc pertinents pour la gestion du service.

Le plan publié avant l’incident fournit un contexte, mais pas une explication causale. Le plan trimestriel RIS de RIPE NCC, mis à jour le 17 septembre, listait déjà des améliorations de la surveillance du traitement RIS/RIPEstat, prévues au quatrième trimestre. Il annonçait aussi le remplacement des machines Kafka et la mise à niveau vers une nouvelle version ; ce chantier, auparavant repoussé faute de ressources, était indiqué « en cours ». L’examen d’autres architectures de stockage pour réduire la dépendance à HBase figurait également parmi les travaux en cours. Rien dans la page ne relie ces projets à l’incident du 2 octobre ni ne dit que leur achèvement a produit la reprise.

Le même plan propose de revoir l’approche du peering afin de conserver un ensemble de pairs pertinent et diversifié tout en maintenant un volume de données soutenable. Cette ambition rend l’incident instructif : davantage de sources peut enrichir l’archive, mais leur ingestion a un coût de traitement. Rien ne permet de qualifier ce pair d’inutile ou de fautif, ni de lui attribuer la conception du pipeline. La responsabilité opérationnelle consiste à préserver un flux d’observation utile tout en rendant visible son coût et en limitant ses effets sur les sorties d’autres collecteurs.

La suite utile est un reçu de reprise plus précis : quels fichiers ont pris du retard, quel intervalle était attendu, à quel moment la production a repris, si l’arriéré a été rejoué sans lacune ni doublon et comment la vérification a été faite. Un test de capacité devrait indiquer le volume d’entrée exercé, le retard maximal de traitement, le comportement d’un redémarrage avec arriéré et le seuil auquel un autre collecteur est touché. Ces éléments permettraient de faire de « résolu » un constat vérifiable sur les données rétablies et les risques encore présents.

La Note 70 de Heng Lu, consacrée à l’écart entre capacité technique et réalités pratiques, inspire seulement la distinction entre un signal de télémétrie et les conclusions qu’on peut en tirer. Elle n’est pas une source technique sur RIPE. Les faits sur l’incident et les travaux prévus viennent des pages RIPE NCC ; les exigences de fiabilité ci-dessus relèvent de l’analyse.

RIPE NCC a marqué l’incident comme résolu le 6 octobre. La correction de configuration qui a relancé le processus et le correctif structurel annoncé pour le défaut latent sont deux jalons différents. Le premier a restauré la progression à court terme ; le second, accompagné d’un test de charge et de redémarrage, devra montrer si le même cycle est moins probable lors d’un prochain pic. Le dossier public établit cette différence sans fournir encore les résultats du test.

Sources