Résumé

  • Le RIPE NCC indique que les bviews RIS de 16 h UTC ont été générées mais non publiées à cause d’une mauvaise configuration consécutive à un basculement ; il reconnaît aussi une lacune de supervision.
  • Les éléments disponibles établissent une panne de la couche de publication, pas une panne du BGP, de tous les collecteurs, de RIS Live ou de l’ensemble des données de routage.
  • Le contrôle manquant se situe au bord visible par l’utilisateur : liste des fichiers attendus, confirmation du rattrapage et heure à laquelle l’ensemble public redevient complet.

À 16 h UTC, les fichiers existaient d’un côté du système du RIPE NCC et manquaient du côté utilisable par les chercheurs. L’avis d’incident affirme que les bviews avaient été générées. Une mauvaise configuration de l’infrastructure après un basculement a empêché leur publication. Le RIPE NCC dit avoir corrigé la configuration et commencé à publier les fichiers manquants ; au gel de nos sources, l’incident restait au statut monitoring.

La phrase décisive n’est pas celle sur la reprise. C’est l’aveu d’une « lacune » de supervision. Le RIPE NCC dit avoir été informé de l’absence des fichiers, sans préciser par qui ni si une alerte automatique avait déjà réagi. La question de responsabilité est donc étroite mais importante : le succès était-il mesuré à la génération alors que l’utilisateur dépendait de la publication ?

Un instantané n’est livré que lorsqu’il est récupérable

RIS collecte les données BGP collecteur par collecteur. Sa documentation distingue les dumps bview, photographie de l’état du routage, des fichiers d’updates qui enregistrent les changements. Le rythme annoncé est d’un dump toutes les huit heures et d’un fichier d’updates toutes les cinq minutes. La RFC 6396 définit les structures MRT qui transportent ces enregistrements.

La génération ne suffit pourtant pas à rendre un fichier public. Entre le collecteur et l’analyste se trouvent le traitement, la création de l’objet, l’indexation, le stockage et la récupération. L’avis du 25 août situe l’échec dans cette chaîne aval. C’est moins large qu’une panne de RIS, mais ce n’est pas anodin : une analyse fondée sur un lot complet de collecteurs peut changer silencieusement si une partie arrive tard ou manque.

Le dossier public ne nomme pas les collecteurs touchés, le nombre d’objets absents, le délai de publication ni l’heure d’achèvement du rattrapage. Il ne fait état ni de corruption ni de perte de données de routage. RIS Live est documenté comme un flux quasi temps réel distinct ; l’incident bview ne prouve donc pas la défaillance de toutes les surfaces de livraison. Aucun impact utilisateur chiffré n’est établi.

L’épisode de mai rend la provenance pertinente, sans prouver une cause commune

En mai 2026, une autre modification d’infrastructure avait conduit le pipeline de publication à recopier des bviews historiques. Les dates de modification avaient changé et certaines copies couvrant la période du 1er mars au 21 mai pouvaient être incomplètes lorsqu’elles avaient été téléchargées après le 26 mai. Le RIPE NCC a ensuite annoncé leur restauration.

Il serait abusif de fusionner ces événements. Celui de mai concernait des copies historiques après une modification d’infrastructure ; celui d’août, un lot programmé non publié après un basculement. Leur lien démontrable est architectural : la couche de publication peut changer la disponibilité, la fraîcheur apparente et la complétude des données alors même que la collecte ou la génération a réussi.

Tester ce que reçoit réellement l’utilisateur

Le contrôle minimal est fini et vérifiable. Pour chaque dump planifié, le RIPE NCC peut établir la matrice des collecteurs actifs et des objets bview attendus. Un contrôle placé hors du chemin de publication doit vérifier que chacun est listé, récupérable, non vide, lisible comme MRT et disponible dans un délai déclaré. Après un basculement, cette vérification doit viser le point d’accès public, pas seulement la file interne.

Le rattrapage mérite un état propre. « Les fichiers manquants sont en cours de publication » marque le début de la reprise, pas le moment où le lot redevient complet ni la nécessité éventuelle de remplacer un téléchargement antérieur. Un inventaire bref peut donner le lot, les collecteurs concernés, la première heure manquante, l’heure de complétude publique et toute réserve d’intégrité. Les utilisateurs pourraient alors décider sans exiger la divulgation de détails sensibles.

Cet incident est assez limité pour être réparé proprement et assez précis pour améliorer le service. La conclusion n’est pas que les données publiques de routage sont indignes de confiance. Elle est que la confiance doit porter sur l’objet visible du consommateur, non sur une étape interne qu’il ne peut observer.

Sources