Résumé

  • Dans le code étudié de Sagan, is_success recherche un RTT non nul, interprété comme vrai, sans erreur de paquet au dernier saut fourni. Il n’exige pas que l’adresse répondante soit celle de la destination.
  • La bibliothèque expose déjà destination_ip_responded et last_hop_responded séparément. Le problème serait de substituer un sens à un autre dans un rapport, non de découvrir une information que Sagan cacherait.
  • last_median_rtt peut provenir d’un saut antérieur malgré un dernier saut silencieux. Vingt et un tests existants et cinq cas synthétiques ont été exécutés localement sans réseau, sans aucun échec ; ils ne mesurent ni incident réel ni disponibilité applicative.

Dix millisecondes ne suffisent pas à dire qui a répondu.

Lors d’un contrôle local du parseur Sagan, cette valeur accompagne plusieurs situations. L’adresse cible peut répondre normalement. Un autre routeur peut fournir la dernière réponse. La cible peut renvoyer un paquet marqué comme erreur. Enfin, le dernier saut peut rester silencieux alors qu’un routeur précédent a répondu en dix millisecondes. Le nombre demeure identique ; les conclusions possibles ne le sont pas.

Il s’agit de données inventées, utilisant des adresses réservées à la documentation, et non d’observations faites chez un client. Leur intérêt est de rendre visibles les conditions que la bibliothèque calcule. Avant de demander si un résultat annonce une amélioration ou une panne, il faut savoir à quelle question il répond.

Sagan est la bibliothèque de RIPE NCC destinée à interpréter les résultats de mesure de RIPE Atlas. Elle prend en charge les formats qui évoluent et leurs cas particuliers, pour éviter à chaque utilisateur de reconstruire les mêmes règles. Cette utilité mérite d’être reconnue. Le contrôle porte sur le commit 45d01f754896ad648e5b306c4209153bab774af9, daté du 2026-06-03, pas sur un recensement des versions installées. Présentation du projet.

Le code donne trois réponses, pas une seule

Les trois indicateurs terminaux ne demandent pas la même chose au dernier saut de la liste fournie.

set_destination_ip_responded recherche un paquet dont l’adresse d’origine correspond à l’adresse de destination. set_last_hop_responded recherche un paquet dont le RTT est évalué comme vrai. set_is_success recherche un tel RTT sur un paquet qui n’est pas marqué comme erreur. Cette troisième fonction n’ajoute aucune comparaison avec l’adresse cible. Fonctions du traceroute.

Dans le cas synthétique où le dernier paquet vient d’un routeur différent de la cible, avec un RTT de dix millisecondes et sans erreur, last_hop_responded et is_success valent donc true. destination_ip_responded vaut false. La bibliothèque n’affirme pas que le routeur a changé d’identité. Elle renvoie des réponses à des critères différents.

Une réponse normale provenant de l’adresse cible satisfait les trois critères. Cela explique pourquoi ils peuvent paraître interchangeables dans des exemples simples. Ce sont précisément les exemples moins confortables qui obligent à conserver la distinction.

Le cas d’erreur la montre dans l’autre sens. Un paquet synthétique provenant de la cible, avec dix millisecondes de RTT et le code p, laisse vrais les indicateurs de réponse de la cible et du dernier saut. is_success devient false ; la liste des erreurs contient « Port unreachable ». L’état d’erreur ne supprime ni l’adresse enregistrée ni la durée du paquet. Traitement des erreurs.

Une adresse qui répond et un paquet sans erreur sont donc deux constats. Aucun des deux ne prouve, à lui seul, qu’une application a fourni le service attendu. Ici, le code compare une adresse et classe un paquet ; il n’authentifie pas son émetteur et n’effectue pas une transaction applicative.

La distinction existe déjà dans l’interface

Il serait trompeur de reprocher à Sagan de ne pas offrir de critère pour la destination. destination_ip_responded existe. La documentation des types le présente à côté de last_hop_responded, de is_success et des erreurs du dernier saut. Le lecteur dispose des éléments nécessaires pour préciser son interprétation. Propriétés documentées.

La documentation constitue un contrepoint important au titre de cette analyse. Le succès n’est pas ici une preuve cachée de l’arrivée à destination ; c’est un indicateur dont il faut lire la condition. Une interface peut proposer plusieurs réponses utiles sans que leur nom dispense de choisir la bonne.

Le risque envisagé se situe chez le consommateur du résultat : ne garder que is_success, puis appeler ce champ « destination joignable » ou « service disponible ». Aucun produit nommé n’a été observé faisant cette substitution dans cette recherche. Il faut conserver ce conditionnel. Une possibilité de mauvaise lecture n’est pas une enquête établissant un mauvais usage.

Le dernier délai n’appartient pas forcément au dernier saut

Le calcul de last_median_rtt suit une autre règle. Chaque saut calcule une médiane à partir des RTT retenus. Le parseur parcourt ensuite la liste des sauts en sens inverse et conserve la première médiane évaluée comme vraie. Cette sélection n’exige pas que les paquets viennent de l’adresse cible.

Dans un cas synthétique à trois sauts, le premier routeur répond en cinq millisecondes, le deuxième en dix, tandis que le dernier saut comporte un marqueur d’absence de réponse. Les trois indicateurs terminaux sont false. last_median_rtt reste pourtant égal à dix millisecondes.

Ces valeurs ne se contredisent pas. Les indicateurs portent sur le dernier saut fourni ; la médiane vient du dernier saut répondant trouvé par le parcours inverse. La contradiction naîtrait d’un intitulé ajouté ensuite : « délai jusqu’à la cible ». Cette interprétation introduirait une adresse et une arrivée que le calcul n’a pas exigées.

La liste utilisée dans le contrôle est ordonnée normalement. Le résultat ne permet pas de prétendre que n’importe quelle entrée réordonnée ou malformée désignerait le routeur physiquement le plus éloigné. La règle porte sur la liste transmise au parseur. Elle ne reconstitue pas indépendamment le chemin réellement suivi par tous les paquets.

Une médiane doit ainsi voyager avec les conditions de sa sélection. Moyenne, médiane et minimum ne réparent pas une confusion sur l’objet mesuré. Avant de réunir plusieurs nombres, il faut établir si chacun concerne un routeur intermédiaire, un paquet terminal, une adresse cible ou une opération applicative.

Économiser des objets sans perdre le sens

L’option parse_all_hops=False permet de ne pas construire tous les objets Hop. Pour les utilisateurs qui veulent quelques propriétés finales plutôt qu’un parcours complet, cette économie est légitime. La documentation avertit que la liste hops peut alors ne conserver que le dernier objet Hop.

Appliquée au cas synthétique à trois sauts, l’option conserve seulement le saut d’indice trois, silencieux. La propriété dérivée garde les dix millisecondes trouvées au saut précédent. L’entrée d’origine demeure dans raw_data. Les données sources n’ont pas été détruites ; les objets pratiques et la propriété dérivée n’exposent simplement pas le même sous-ensemble.

Un export limité à hops et au nombre peut donc ne pas montrer l’objet ayant fourni ce nombre. Pour expliquer la sélection ultérieurement, on peut conserver l’entrée d’origine ou joindre le contexte du saut choisi. Cela ne suppose pas de maintenir chaque objet Python pour toujours. Il s’agit de choisir consciemment ce que le destinataire pourra vérifier.

Ce que les essais établissent réellement

Vingt et un tests de traceroute déjà présents dans le projet ont été exécutés localement. Les sources originales des classes de base, de compatibilité et de traceroute ont été chargées en mémoire sans modification. Ils se sont tous achevés sans échec. Cinq cas inventés ont ensuite vérifié la réponse d’un routeur non cible, celle de la cible, le silence terminal avec une durée antérieure, la réponse cible marquée comme erreur et le même silence avec interprétation minimale. Les cinq résultats correspondent aux attentes annoncées. Aucune opération réseau n’a eu lieu. Tests existants.

Ce contrôle vérifie les classes sélectionnées et quelques entrées. Il ne certifie pas l’ensemble d’une installation, l’acceptation par un contrôleur, tous les formats produits ou la conformité de chaque version distribuée. Il ne compte pas la fréquence des situations dans les mesures réelles. Aucun coût client ni incident de production ne peut être déduit de ces exemples.

Les tests existants renforcent aussi le contre-argument : le projet traite déjà plusieurs distinctions de réponse. Le propos n’est pas de faire passer une bibliothèque utile pour négligente. Il est de ne pas transformer une propriété calculée en conclusion qu’elle n’a pas calculée.

Du paquet au service, il reste une enquête

La documentation générale de RIPE Atlas distingue déjà des rôles d’adresse. Le champ supérieur from est ajouté par le système de mesure ; src vient de la sonde. Ils peuvent différer légitimement. Dans le parseur de traceroute, le from du paquet imbriqué sert d’adresse d’origine de ce paquet. L’adresse supérieure, l’émetteur d’une réponse et la destination ne deviennent pas une seule identité parce que des intitulés se ressemblent. Rôles d’adresse dans Atlas.

Les réponses ICMP ne parlent pas toutes d’un service à destination. La RFC 792 décrit Time Exceeded lorsque le TTL expire et les circonstances dans lesquelles un routeur peut prévenir la source. Une telle réponse renseigne utilement sur le traitement d’un paquet sans prouver qu’une application cible a exécuté une opération. Réciproquement, le silence seul n’identifie pas nécessairement un chemin de transmission cassé : le retour de la réponse et son traitement font partie du problème à examiner. Spécification ICMP.

La RFC 2330 sépare une observation élémentaire, un échantillon d’observations et les statistiques qui en sont tirées. La convention Type-P rappelle que la nature du trafic compte. Le RTT d’un saut, la classification d’un traceroute et une estimation de disponibilité dans le temps sont donc des questions différentes. Un tableau commun ne suffit pas à les rendre équivalentes. Cadre des métriques de performance.

La bibliothèque fournit une réponse exploitable. Le compte rendu doit encore nommer cette réponse, garder ses conditions et préciser quelle autre preuve soutient un constat plus large. C’est une exigence d’interprétation, pas une demande faite à Sagan de certifier le fonctionnement de l’Internet.

Sources