Résumé

  • Un utilisateur du forum de RIPE NCC a rapporté des réponses vides pour une adresse IP, alors que son préfixe routé renvoyait des données.
  • Le 3 septembre, nos quatre requêtes portant sur les deux exemples ont toutes obtenu des résultats. Le symptôme n’a pas été reproduit ; sa résolution définitive n’est pas établie.
  • La conversion de l’adresse en préfixe fait partie de la recherche. Il faut la distinguer de l’état des routes et, plus encore, du fonctionnement du réseau.

Le résultat le plus important de cette vérification est négatif : nous n’avons pas reproduit le problème. Le 3 septembre, vers 04:13 UTC, RIPEstat a fourni des données pour les quatre entrées testées. Les recherches par adresse ont indiqué leur conversion en préfixe, et les recherches portant directement sur ces préfixes ont également abouti.

Cela ne rend pas inutile le signalement publié la veille. Il porte sur une différence précise : 14.137.164.1 ne donnait pas de résultat, contrairement à 14.137.164.0/24. Le premier identifie une adresse ; le second, un bloc. Les traiter comme deux formulations strictement équivalentes revient à oublier le travail que le service doit accomplir entre la saisie et l’affichage.

Le service choisit d’abord l’objet de la recherche

La documentation de Looking Glass prévoit deux comportements. Un préfixe fourni explicitement doit correspondre exactement à un préfixe routé. Une adresse déclenche une recherche du préfixe routé qui l’englobe. Les entrées trop anciennes sont exclues selon une limite de retour en arrière, fixée par défaut à 86 400 secondes.

Cette souplesse facilite le diagnostic : l’utilisateur n’a pas besoin de connaître à l’avance la plage annoncée. Mais elle introduit une dépendance supplémentaire. Avant de demander ce que les collecteurs voient, le service doit déterminer quel bloc interroger. Une difficulté à cette étape pourrait modifier la réponse sans qu’un opérateur ait changé ses annonces. Il s’agit d’une possibilité architecturale, pas d’une cause démontrée dans le cas présent.

Ajouter systématiquement /24 n’est donc pas une solution. Un préfixe de cette taille n’est pas nécessairement annoncé pour l’adresse considérée. Une comparaison utile exige un préfixe dont l’existence dans le routage est déjà étayée. Sinon, on remplace une question incertaine par une autre.

Le dossier public reste circonscrit

Le fil du forum commence le 24 août, avec un exemple concernant 159.138.184.0 et son /24. Le lendemain, ties, compte publiquement identifié comme appartenant au personnel de RIPE NCC, évoque un phénomène apparemment transitoire, explique la recherche du préfixe le plus spécifique et propose de vérifier le traitement d’un échec de recherche.

Le 2 septembre, le même utilisateur, moonteach, indique que le premier exemple fonctionne désormais, mais rapporte la différence pour 14.137.164.1. Les horaires reproduits pour cette nouvelle paire sont séparés de 27 secondes. Ce ne sont ni des mesures simultanées ni plusieurs témoignages indépendants. Aucun diagnostic définitif ou achèvement d’une correction n’est annoncé dans cet échange.

Nos propres requêtes, exécutées successivement entre 04:13:08.929 et 04:13:10.945 UTC le 3 septembre, donnent un tableau différent.

Entrée interrogée Entrées de collecteurs Lignes de pairs
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

Les quatre réponses portent HTTP 200 et l’état ok. Pour les deux adresses, le message de conversion et le paramètre effectif désignent le /24 correspondant. Les nombres du tableau comptent les éléments des réponses sauvegardées, non les opérateurs distincts ou l’ensemble du parc RIS. Les liens exécutent des requêtes actuelles : ils ne constituent pas des archives fixes.

Même les totaux égaux demandent de la prudence. Pour la seconde paire, les champs latest_time diffèrent de 20 secondes. Nous n’avons donc pas établi l’identité des instantanés. Quatre succès bornent une tentative de reproduction ; ils ne mesurent pas la disponibilité du service et ne reconstituent pas son état antérieur.

Le réseau n’est pas le dernier champ d’une réponse

Le format de la Data API distingue état, messages, version et cache. Recevoir correctement une réponse ne prouve pas qu’une adresse est joignable. Recevoir un ensemble vide ne prouve pas davantage qu’une route a été retirée.

RIS rassemble des observations BGP fournies par des sessions de pairs volontaires. Ce dispositif n’est pas un test de transmission de bout en bout. Il faut encore comprendre le point de vue, l’âge de l’observation et l’objet réellement interrogé avant de transformer le résultat en constat opérationnel.

Aucune panne client, perte de trafic ou attaque n’est établie ici. L’intérêt du cas tient plutôt à une discipline : conserver la différence entre une question restée sans réponse et une réponse qui démontre une absence. Le test actuel est rassurant dans son périmètre. Lui demander d’expliquer le passé serait déjà dépasser ce périmètre.