Résumé

  • Le RIPE NCC a séparé, dans son avis du 20 octobre, la fraîcheur des différents points d’accès de RIPEstat et indiqué que les métadonnées du Looking Glass signalent le retard maximal des données présentes.
  • Une requête horodatée à 18 h 04 min 43 s UTC a renvoyé des données dont l’horodatage le plus récent était 12 h 13 min 37 s UTC. Cet échantillon ne décrit ni tous les pairs ni toutes les ressources.

Une observation de route vieille de cinq heures peut aider à lire une tendance et rester trop ancienne pour déclencher une action automatisée. Une réponse réussie ne garantit donc pas une donnée actuelle : la requête peut être récente alors que les observations ne le sont pas. Le 20 octobre, le RIPE NCC a indiqué que les retards de RIPEstat variaient selon le point d’accès ; une réponse du Looking Glass montre l’écart entre ces deux horloges.

Une requête peut être récente alors que les observations qu’elle renvoie sont plus anciennes. Les tableaux de suivi brouillent facilement cette différence lorsqu’ils affichent un code de réponse positif, une heure de requête récente ou un seul état général du service. Le 20 octobre, le RIPE NCC a formulé une distinction plus précise : certaines données de RIPEstat étaient retardées à cause d’un problème dans le Routing Information Service (RIS), et l’ampleur variait selon le point d’accès de l’API.

L’avis ne décrit pas une horloge unique pour RIPEstat. Il indique que le Looking Glass devrait être à jour pour une majorité — plus de 90 % — des pairs, tandis que ses métadonnées donnent le retard maximal parmi les données disponibles. Ces deux indications ne se contredisent pas. Une majorité peut être récente alors qu’une partie plus réduite du résultat est plus ancienne ; un indicateur du retard maximal avertit sur cette queue sans attribuer le même âge à chaque ligne. Le RIPE NCC n’a publié ni garantie universelle de fraîcheur ni seuil unique qui définirait, pour chaque pair, ce que signifie « à jour ».

Cette distinction compte parce que RIPEstat est à la fois une interface publique de données et la source de ses propres widgets et de son interface utilisateur. L’API ne constitue pas un jeu de données unique doté d’un calendrier de mise à jour unique. Chaque point d’accès répond à une question différente, et la documentation énumère plusieurs facteurs de fraîcheur : fréquence de collecte, rythme normal de mise à jour du stockage, délai de traitement, fonctionnement normal de la collecte et du traitement, et cache. Une réponse réussie confirme qu’une requête a abouti. À elle seule, elle ne donne pas l’âge de chaque observation sous-jacente.

La documentation du Looking Glass décrit son flux RIS comme proche du temps réel dans des conditions ordinaires, avec un léger délai, mais distingue aussi plusieurs horodatages. La date de dernière modification d’une route signifie quand celle-ci a changé ; la dernière confirmation indique quand elle a été observée pour la dernière fois. L’une ne remplace pas l’autre. Le point d’accès accepte également une limite de recul, réglée par défaut à 24 heures, qui exclut les entrées plus anciennes. Avant de lire l’absence d’une ligne comme la preuve qu’une route n’existait pas, il faut donc connaître le filtre et la fenêtre d’observation.

L’incident en amont confirme qu’il s’agit d’une question de cycle de vie des données, et non d’un compte rendu de panne de routage. Dans un avis distinct, le RIPE NCC a mentionné un problème de copie des fichiers BVIEW depuis son stockage et un retard de consommation de messages recueillis par RRC25. Au moment de la mise à jour, les derniers fichiers BVIEW étaient publiés à l’exception de RRC25 ; les fichiers RIS d’actualisation étaient eux aussi retardés. L’incident RIPEstat renvoie à ce problème et prévient que les points d’accès ne sont pas affectés de façon identique.

Aucun des deux avis ne dit que des routes ont disparu d’Internet ou que des clients ont perdu leur connectivité.

La leçon opérationnelle est limitée mais utile : conserver l’horloge des données à côté de celle de la requête. Pour toute décision qui s’appuie sur RIPEstat, garder le point d’accès, la ressource, l’heure de requête, l’heure des données les plus récentes, l’état du cache et la couverture représentée par la réponse. Il faut ensuite comparer l’âge des données à la tolérance réelle de la décision. Une observation vieille de cinq heures peut convenir à une tendance historique et ne pas convenir à une action automatisée ; le seuil pertinent dépend de l’usage, pas d’une couleur générique sur un tableau de bord.

L’avis du RIPE NCC est utile justement parce qu’il ne réduit pas l’incident à un chiffre unique. La mention « plus de 90 % » oriente sur le service, tandis que les métadonnées signalent le retard maximal. La question pour l’utilisateur n’est pas de décider si l’avis est vrai ou faux. Il doit savoir si ce point d’accès précis et cette fenêtre de données suffisent à la décision en cours. Séparer ces vérifications permet de conserver la valeur du flux sans lui faire prouver davantage qu’il ne peut. Sources primaires : incident RIPEstat du RIPE NCC, incident RIS du RIPE NCC, documentation de l’API RIPEstat, documentation du point d’accès Looking Glass, Présentation de RIPEstat, réponse horodatée de l’API Looking Glass et documentation des collecteurs RIS.