Résumé

  • RIPE a indiqué que le dernier fichier d’update de RRC07 portait l’horodatage 19:20 UTC le 6 octobre. L’incident a ensuite été déclaré résolu à 21:53 UTC ; les fichiers bview, selon RIPE, ont été créés normalement.
  • L’index actuel de l’archive répertorie 30 fichiers d’update consécutifs, à cinq minutes d’intervalle, de 19:25 à 21:50. Leurs dates de modification vont de 21:53 à 21:55 ; quatre fichiers testés se décompressent entièrement, mais leurs enregistrements MRT n’ont pas été analysés.

Analyse

Deux horloges, deux constats

Une archive de routage porte plusieurs indications temporelles. L’horodatage intégré au nom d’un fichier d’update désigne l’intervalle qu’il couvre. La date de modification du répertoire indique quand le serveur d’archive dit que l’objet a changé. Ces deux repères ne répondent pas à la même question.

Dans son avis initial, RIPE situait le dernier update de RRC07 à 19:20 UTC. Sur l’index public consulté aujourd’hui, le fichier précédent, updates.20261006.1920.gz, affiche une modification à 19:25. Les 30 noms suivants se succèdent ensuite sans trou de cinq minutes, de 19:25 à 21:50. Vingt-cinq portent une date de modification à 21:53, quatre à 21:54 et un à 21:55. Cette concentration est compatible avec la publication tardive d’une série en peu de temps. Elle ne révèle ni le chemin de traitement interne ni l’heure à laquelle chaque utilisateur a pu récupérer un fichier.

La page d’incident indique une résolution à 21:53 UTC le 6 octobre et précise que les bviews ont été créés normalement. RIPE décrit un bview comme un instantané de l’état du routage, tandis qu’un fichier d’update consigne les changements sur un intervalle. Un instantané normal ne permet donc pas de savoir si chaque fichier d’update intermédiaire était complet : ces produits documentent des choses différentes.

Les données RIS servent à examiner l’état du routage, à étudier des événements BGP et à suivre des tendances. Lors d’une analyse rétrospective, une période vide dans un graphique reste ambiguë : aucun changement n’a peut-être été observé, ou le fichier d’observation n’était peut-être pas disponible. Une liste continue publiée plus tard réduit l’incertitude sur les noms présents, mais pas sur le contenu de chaque intervalle.

Quatre fichiers aux limites de la séquence — 19:20, 19:25, 21:45 et 21:50 — ont été récupérés et ont passé une décompression gzip complète. Ce contrôle porte seulement sur le transport. Les enregistrements MRT n’ont pas été analysés et les 26 autres fichiers n’ont pas été échantillonnés. L’index actuel ne montre pas non plus ce que les utilisateurs pouvaient consulter pendant l’incident. L’avis public de RIPE ne donne aucune cause à RRC07, ne signale aucune perte de routes et ne décrit aucun effet sur le trafic. Il ne faut rien déduire de tel à partir du seul retard de publication.

Sources