Résumé

  • RIPE NCC attribue l’incident à un flux élevé de messages BGP qui a chargé une partition Kafka ; au redémarrage, un défaut latent relançait une analyse volumineuse, suivie de nouveaux délais d’expiration.
  • Une correction de configuration a permis le rétablissement du processus. RIPE NCC dit que les fichiers BVIEW et les fichiers d’updates depuis le 2 octobre ont ensuite été produits ; une correction structurelle du défaut restait prévue pour un prochain sprint.
  • Le retour des fichiers et la suppression du chemin de panne ne sont pas la même affirmation. L’incident concerne la production des données RIS, et ne prouve pas une perte de routes ou une interruption du trafic.

Les archives sont revenues avant la correction complète

Le 6 octobre, RIPE NCC a clôturé l’incident touchant les fichiers MRT et BVIEW de RRC12 en formulant deux constats distincts. D’une part, après le rétablissement du processus, les fichiers depuis le 2 octobre avaient été produits avec succès. D’autre part, la correction immédiate reposait sur un changement de configuration, tandis qu’une correction structurelle du défaut latent devait être travaillée lors du sprint suivant.

Il s’agit de deux états opérationnels. Le registre public a été alimenté à nouveau ; le mécanisme qui faisait échouer le redémarrage n’était pas encore présenté comme corrigé structurellement. Un service peut reprendre alors qu’une tâche d’ingénierie reste ouverte. Confondre les deux reviendrait à faire dire à l’avis de statut plus qu’il ne dit.

Selon RIPE NCC, l’incident a commencé à 01:30 UTC le 2 octobre, lorsqu’un pair de DE-CIX a commencé à envoyer un nombre inhabituellement élevé de messages BGP à RRC12. Le pipeline consommant les données depuis Kafka n’a pas suivi le volume. Un processus a expiré, puis a de nouveau expiré après son redémarrage, avant d’avoir suffisamment progressé. RIPE NCC a ensuite signalé des retards dans la production des fichiers d’updates d’autres RRC.

La mise à jour ultérieure précise le facteur d’amplification : le volume a chargé une seule partition Kafka. Au redémarrage, un défaut latent déclenchait une nouvelle analyse d’un grand volume de données. Cette analyse expirait à répétition. Une erreur de configuration la rendait un ordre de grandeur plus longue qu’elle n’aurait dû l’être. La correction de cette configuration a permis le rétablissement ; la modification structurelle restait à faire.

Ce que contiennent les fichiers

RRC12 est le collecteur de routes RIPE situé à Francfort, chez DE-CIX. La documentation de RIPE distingue deux artefacts : le fichier BVIEW est un instantané de l’état du routage à un moment donné ; le fichier d’updates consigne les changements sur un intervalle. La cadence habituelle documentée est de huit heures pour les dumps et de cinq minutes pour les updates. RIPE indique que les fichiers MRT peuvent servir aux analyses BGP, aux post-mortems et aux tendances de long terme.

Un retard de publication complique donc la reconstitution d’une période à partir de preuves publiques. Il ne transforme pas pour autant l’incident en panne de routage. Les sources établissent un retard de production de fichiers, pas des routes manquantes, un trafic interrompu, une intention malveillante ou un dommage chez les clients. Elles ne nomment pas le pair et ne quantifient ni son débit de messages, ni la file d’attente, ni la durée des retards des autres collecteurs.

L’index d’octobre contient désormais des noms de fichiers BVIEW et d’updates jusqu’au 7 octobre. Ce contrôle indique que le répertoire public comporte des artefacts plus récents. Il ne prouve pas que chaque fichier est complet, qu’un contrôle d’intégrité indépendant a été réalisé ou que toute analyse en aval aurait obtenu le même résultat qu’avec un flux sans interruption.

Le rétablissement n’a pas qu’une seule ligne d’arrivée

Il ne faut pas réduire les étapes de l’incident à un unique état vert. Le volume entrant a cessé de bloquer le traitement. Le processus redémarré a pu avancer. Les fichiers manquants ont été générés. Séparément, le chemin de démarrage défectueux restait inscrit au programme de travail structurel. Ce sont des affirmations différentes.

Dans un système de mesure, rétablir les archives répond à la question « les fichiers sont-ils de nouveau produits ? ». Cela ne répond pas entièrement à « la condition qui rendait le rattrapage fragile a-t-elle disparu ? », ni à « la série restaurée a-t-elle été vérifiée comme complète ? ». La mise à jour publique répond à la première question et annonce un travail futur pour la deuxième. Elle ne publie pas de reçu indépendant de complétude pour la troisième.

Ce constat ne prouve pas que le rétablissement était insuffisant. L’avis public est simplement plus étroit qu’un rapport complet : il donne le déclencheur, la charge sur une partition, le nouveau scan au redémarrage, la correction de configuration et le travail structurel à venir. Il ne fournit ni identité du pair, ni taux, ni mesures de file, ni fenêtre détaillée des retards, ni méthode de validation, ni identifiant de version.

Pour les utilisateurs d’archives de mesure publiques, une clôture utile relierait ces éléments sans dévoiler de détails sensibles : collecteurs et périodes concernés, fichiers régénérés, validations effectuées, contournement immédiat, correction structurelle restante et preuve de sa vérification. Un historique daté permettrait de distinguer disponibilité retrouvée et réparation de fiabilité achevée.

La conclusion doit rester mesurée. Les fichiers de RRC12 ont été rétablis après qu’une forte charge a révélé une faiblesse au redémarrage, aggravée par la configuration. RIPE NCC indiquait qu’une correction structurelle restait à venir. L’archive ne représente pas à elle seule tout le routage d’Internet ; l’incident ne prouve pas de panne de routes. Mais la différence entre « les fichiers sont de retour » et « le mécanisme de reprise est corrigé » mérite d’être visible.

Sources