Résumé

  • RIPE NCC affirme qu’un pair de DE-CIX a commencé à envoyer un nombre inhabituellement élevé de messages BGP au collecteur RRC12 à 01 h 30 UTC le 2 octobre ; le processus qui traite les mises à jour depuis Kafka expirait ensuite à répétition.
  • À 19 h 10 UTC ce jour-là, l’archive publique de RRC12 n’allait toujours pas au-delà de 01 h UTC. Il s’agit d’un retard de publication dans un service de mesure, pas d’une preuve de routes Internet manquantes ou de trafic interrompu.

Analyse

RIPE NCC a ouvert à 09 h 42 CEST, le 2 octobre, un incident intitulé « RRC12 MRT update files are not produced ». Sa première note indiquait que le dernier fichier d’updates de RRC12 datait de 01 h UTC et que son dernier instantané BVIEW remontait à 00 h UTC. À 13 h 26 CEST, l’organisation a expliqué qu’un pair de DE-CIX envoyait depuis 01 h 30 UTC un nombre inhabituellement élevé de messages BGP à RRC12. Le processus qui consommait les mises à jour depuis Kafka ne suivait pas le volume, selon RIPE ; après chaque redémarrage, il expirait de nouveau avant d’avoir suffisamment avancé.

RIPE signalait aussi un retard de production des fichiers d’updates d’autres RRC.

RRC12 est un collecteur de routes situé à Francfort et raccordé à DE-CIX. Les collecteurs reçoivent les données BGP de leurs pairs ; ils ne choisissent pas les routes utilisées par ces réseaux. La documentation de RIPE précise que les données recueillies sont stockées par collecteur : les fichiers « update » enregistrent les changements sur une période, tandis que les fichiers BVIEW représentent un état à un instant donné. RIPE indique que les fichiers d’updates sont normalement produits toutes les cinq minutes. C’est la cadence habituelle d’un flux d’observation, non une garantie que chaque collecteur la respecte en permanence.

Une vérification en lecture seule de l’archive publique de RIPE à 19 h 10 UTC n’a trouvé aucun fichier d’updates RRC12 postérieur à updates.20261002.0100.gz, soit 18 heures et 10 minutes avant la vérification. L’archive de RRC18 allait jusqu’à 19 h 05 UTC. Cette comparaison montre l’écart de fraîcheur visible entre ces deux répertoires à cet instant ; elle ne prouve pas que tous les autres collecteurs étaient épargnés, ne précise pas lesquels avaient été retardés auparavant et n’explique pas pourquoi RRC18 disposait de fichiers plus récents.

Au point de contrôle retenu, l’incident était toujours identifié et en cours d’investigation. Le statut ne nommait pas le pair et ne publiait ni son débit de messages, ni les routes concernées, ni la durée du retard chez les autres collecteurs, ni l’état de reprise de la file, ni le plan de rétablissement. RIPE ne disait pas non plus que des routes avaient disparu ou que le trafic avait été perturbé. Un fichier retardé oblige l’analyste à vérifier son horodatage avant d’interpréter un intervalle vide ; il ne prouve pas qu’aucune modification BGP n’a eu lieu.

La prochaine information utile serait un bref relevé de rétablissement : derniers horodatages des updates et des BVIEW pour les collecteurs touchés, reprise éventuelle des intervalles retardés et heure du retour à la publication normale. Les utilisateurs de RIS pourraient alors distinguer collecte, traitement et publication sans confondre un retard d’archive avec un changement du système de routage.

Sources