Traceroute est de loin l’outil le plus connu pour découvrir le chemin réseau entre une source et une destination.
Dans cet article, nous expliquons les principaux concepts qui régissent traceroute. Nous abordons également ses principales limites. Celles-ci expliquent pourquoi vous ne pouvez pas vous fier à traceroute dans le cadre de mesures de grande précision.
A quoi sert traceroute ?
Traceroute est un outil très utile pour la surveillance du réseau et le diagnostic de problèmes. Avec traceroute vous pouvez :
- découvrir le chemin de routage réseau entre une source et une destination
- mesurer la latence du réseau pour atteindre chaque noeud dans le chemin
- mesurer la perte de paquets à chaque noeud
Il est extrêmement utile pour mesurer la qualité du réseau (congestions, …). Il peut également détecter toute variation de chemin réseau pouvant survenir lors de modifications de configuration de peering/routage BGP.
Comment fonctionne traceroute ?
Le principe de base de traceroute est présenté ci-dessous :
Traceroute repose en grande partie sur le champ TTL (Time To Live) de l’en-tête du paquet IP. Ce champ est principalement utilisé pour éviter les boucles dans les réseaux, où les paquets pourraient être routés indéfiniment dans certaines circonstances, sans jamais atteindre la destination. Lorsqu’un hôte envoie un paquet sur un réseau, sa valeur TTL initiale est généralement comprise entre 32 et 255, selon le système d’exploitation utilisé. A chaque fois que le paquet atteint un routeur et doit être routé, la valeur TTL diminue de 1. Lorsqu’un paquet avec une valeur TTL de 1 atteint un routeur, ce dernier ne peut plus router le paquet (cela signifierait un TTL=0). Il supprime donc le paquet (pour éviter un problème de bouclage potentiel). Il en informe également la source en renvoyant un message d’erreur ICMP spécifique à la source (message d’erreur ICMP « TTL Exceeded In Transit »).
Traceroute repose donc sur le fait que les routeurs renverront ce message d’erreur ICMP à la source dans le cas où une valeur TTL atteint 1. Lors de l’exécution d’un traceroute, voici ce qui se passe :
- La source envoie un premier paquet IP avec une valeur de champ d’en-tête TTL de 1.
- Le paquet atteint le premier routeur du chemin réseau. Le routeur supprime le paquet en raison de cette valeur TTL et renvoie un message d’erreur ICMP à la source.
- La source a découvert le premier routeur ! Passons donc au suivant. Pour cela, il envoie un paquet avec une valeur TTL de 2.
- Le paquet atteint le premier routeur, est routé normalement et la valeur TTL est diminuée de 1 (nouvelle valeur TTL = 1).
- Le paquet atteint le deuxième routeur du chemin. Le routeur le supprime en raison de la valeur TTL de 1. Encore une fois, un message d’erreur ICMP est renvoyé à la source, qui découvre le deuxième routeur dans le chemin.
- … et ainsi de suite jusqu’à ce que le paquet atteigne la destination finale.
- Le type de message que cette destination finale enverra à la source dépend de l’implémentation spécifique de traceroute utilisée (voir le point suivant).
Différentes implémentations de traceroute
Avec traceroute, les paquets IP ne sont pas envoyés tels quels. Ils sont généralement transportés dans un protocole de couche de transport supérieur comme UDP, ou directement dans des paquets ICMP.
Traceroute dans Windows
L’implémentation Windows standard de traceroute utilise ICMP comme protocole pour envoyer des paquets IP.
Voyons comment cela fonctionne en pratique :
Ces images montrent une commande traceroute Windows vers google.com.
Une ligne correspond à un routeur découvert. Par défaut, un traceroute Windows envoie trois paquets par saut. Vous pouvez le voir par les 3 valeurs de latence du réseau fournies par ligne.
Dans cet exemple, le paquet a atteint la destination après 7 sauts consécutifs. La dernière ligne (8) correspond à la destination finale elle-même.
Voyons maintenant en détail ce qui s’est passé en utilisant Wireshark. Nous analysons le cinquième routeur découvert.
La capture d’écran de gauche montre que la source (192.168.1.31) envoie un paquet ICMP « Echo (ping) request » à la destination (216.58.208.110) avec une valeur de champ TTL d’en-tête IP de 5.
La capture d’écran de droite montre la réponse du routeur intermédiaire découvert (91.183.245.122). Ce dernier renvoie à la source un message d’erreur ICMP « Time to live exceeded ». En tant que données supplémentaires, il renvoie également le paquet à l’origine de ce message d’erreur.
Lorsque le paquet atteint enfin la destination, le paquet n’a plus besoin d’être routé. Ainsi, la destination ne renvoie aucun message d’erreur ICMP à la source. Ceci est montré ci-dessous.
Sur le côté gauche, vous pouvez voir que la source envoie toujours des paquets ICMP avec une valeur TTL de champ IP incrémentielle (8 dans ce cas). Néanmoins, comme la destination n’a plus à router le paquet, elle ne se soucie pas de la valeur TTL. Au lieu de cela, il répond à la sollicitation de demande ICMP (Echo request) en renvoyant une réponse ICMP (Echo reply) à la source.
Traceroute sous Linux
Traceroute sous Linux utilise UDP comme protocole de transport pour envoyer des paquets IP.
Voyons comment cela fonctionne en pratique :
Sans regarder plus de détails, le processus semble identique à un traceroute sous Windows : 3 tests par valeur TTL fournissant la latence du réseau à chaque saut de routage, jusqu’à la destination.
Voyons ce qui s’est exactement passé cette fois :
Sur le côté gauche, vous voyez les détails de la cinquième ligne du traceroute, c’est-à-dire un paquet UDP envoyé avec un champ TTL d’en-tête IP de 5. Sur le côté droit, vous voyez qu’un routeur intermédiaire renvoie un message d’erreur ICMP ( « TTL exceeded in transit ») à la source. Vous pouvez vérifier la raison de ce message d’erreur ICMP dans ce paquet ICMP pour être sûr qu’il a bien été déclenché par le paquet UDP initial.
Lorsque le paquet atteint enfin la destination, il ne doit plus être routé. Ainsi, la destination ne renvoie aucun message d’erreur ICMP à la source. Néanmoins, comme Linux utilise UDP par défaut et non ICMP comme Windows, la destination ne répondra pas avec un message « ICMP Echo reply » à la source. Au lieu de cela, il répond en informant la source qu’il n’écoute pas sur le port UDP de destination.
Comme vous pouvez le voir sur la capture d’écran ci-dessus, la destination finale (172.217.168.206) renvoie un message d’erreur ICMP « Destination unreachable – Port unreachable » à la source. Il informe la source qu’il n’écoute pas sur le port UDP de destination (33.468 dans notre cas).
En règle générale, traceroute basé sur le protocole de transport UDP utilise des ports de destination supérieurs à 33.435.
Principales limitations de traceroute
Si vous souhaitez découvrir rapidement un itinéraire vers une destination et avoir une première idée des performances du réseau, traceroute est certainement l’un de vos meilleurs amis. Néanmoins, vous devez être conscient de certaines limitations majeures que nous pouvons classer comme suit :
- découverte de nœuds
- découverte du chemin
- indicateurs de performance
Découverte de nœuds de réseau
Afin d’identifier tous les nœuds intermédiaires jusqu’à la destination, ils doivent renvoyer les messages d’erreur ICMP à la source. Si l’un d’eux ne répond pas, il ne sera pas identifié. Vous pouvez toujours savoir qu’il y a un routeur dans le chemin, mais ne pouvez pas l’identifier clairement.
Sur la capture d’écran ci-dessus, le quatrième routeur dans le chemin n’est pas identifié. Ceci est symbolisé par le * .
Beaucoup de nœuds du réseau ne répondront pas à la sollicitation ICMP pour des raisons de sécurité. Un pare-feu peut simplement filtrer une partie du trafic sans renvoyer le paquet ICMP pour masquer sa présence.
Découverte du chemin du réseau
Comme vous le savez maintenant, traceroute est basé sur une succession de paquets avec une valeur de champ TTL d’en-tête IP incrémentielle. Ainsi, le scénario suivant peut parfaitement se produire :
Il montre pourquoi le traceroute traditionnel ne gère pas correctement la répartition de charge du trafic. Au lieu de détecter l’équilibrage de charge entre le nœud B et C, le résultat peut être une connexion directe entre C et E (suivants les tests TTL=2 et TTL=3), et une boucle sur le nœud E (suivant les tests TTL=3 et TTL=4). Vous ne découvrez pas du tout les nœuds B et D !
Indicateurs de performance du réseau
Mesures des nœuds intermédiaires
Comme expliqué précédemment, traceroute fournit la mesure de latence du réseau de la source jusque chaque routeur intermédiaire. Il s’agit du temps entre l’envoi du paquet par la source et le moment où elle reçoit le message d’erreur ICMP en retour du routeur intermédiaire. Malheureusement, la vitesse à laquelle tout se passe dépend de la vitesse de routage ainsi que de la capacité du routeur à générer et à envoyer le message d’erreur ICMP. Habituellement, ce type de trafic n’est pas considéré comme hautement prioritaire. Les routeurs gèrent généralement ce type de trafic avec une faible priorité par rapport aux flux d’applications métier critiques. Ainsi, la mesure de la latence du réseau peut ne pas refléter les performances réelles du trafic de production.
Du nombre de paquets manquants renvoyés au client, vous pouvez également déduire la valeur de perte de paquets. Mais cela a deux limites :
- Le fait qu’un routeur intermédiaire ne renvoie aucun message d’erreur ICMP peut être dû à une perte de paquets, mais peut être dû au fait qu’il ne répond tout simplement pas !
- L’envoi de trois paquets par saut ne peut pas fournir une mesure de perte de paquets très précise (perdre 1 paquet signifierait 33% de perte de paquets ! Ouch…)
Mesures de bout en bout
La mesure de la latence du réseau de la source à la cible nécessite que cette dernière réponde à la sollicitation de la source.
Dans une implémentation de traceroute Windows standard, la destination ne doit pas ignorer/filtrer les paquets « ICMP Echo request » et doit renvoyer la réponse « ICMP Echo reply » à la source.
Dans une implémentation de traceroute Linux standard, vous devez vous assurer qu’aucun service n’est en cours d’exécution sur les ports UDP 33.435 et supérieurs, et également que cette machine renverra le message d’erreur « ICMP Destination Unreachable » à la source.
Si, pour une raison quelconque, la destination ne répond à aucune sollicitation de la source, vous ne pourrez jamais mesurer la latence du réseau de bout en bout avec traceroute.
Utilisation de traceroute dans un environnement de production
Traceroute est un outil fantastique pour découvrir rapidement les chemins de réseau et avoir une idée des performances du réseau. Néanmoins, vu les principales limitations expliquées ci-dessus, si vous souhaitez utiliser cet outil dans un environnement de production, vous feriez mieux d’opter pour des solutions spécialisées qui répondent aux défis majeurs que vous rencontrerez.
Plusieurs protocoles de transport
Comme indiqué précédemment, Windows utilise ICMP et Linux utilise UDP pour envoyer des paquets IP. Le niveau de précision de la découverte des nœuds dépend de la réponse ou non des routeurs intermédiaires. De plus, les métriques de performance du réseau dépendront beaucoup de la façon dont les différents nœuds gèrent le trafic correspondant. Enfin, les mesures de bout en bout nécessitent que la cible réponde à la sollicitation de la source, qui là encore dépend du protocole utilisé.
Jusqu’à présent, nous n’avons mentionné que ICMP et UDP comme protocoles utilisés pour cela. Mais vous pouvez même utiliser TCP ou d’autres techniques (comme l’envoi de paquets TCP ACK présents dans le processus de négociation TCP). C’est une bonne alternative pour les réseaux qui filtrent le trafic UDP.
Vous devriez donc envisager d’utiliser plusieurs techniques et de les combiner pour :
- assurer une visibilité complète du chemin jusqu’à la destination
- estimer avec précision les mesures de performance du réseau
Algorithmes spécialisés
Les versions standards de traceroute peuvent vous fournir des informations totalement erronées car elles ne peuvent pas gérer correctement les routes à répartition de charge. Pour résoudre ce problème, vous devez utiliser des techniques plus sophistiquées, comme le « Paris traceroute ». Mais ce n’est pas suffisant. Vous aurez besoin d’algorithmes et d’heuristiques spécifiques supplémentaires pour calculer efficacement d’autres métriques comme le taux de perte de paquets.
Visualisation du chemin réseau
Avoir une liste de nœuds et d’adresses IP correspondantes est un point de départ.
Mais ce dont vous avez vraiment besoin, c’est d’un aperçu clair des différents AS BGP qui sont traversés afin que vous puissiez identifier les propriétaires d’AS (FAI, CSP, …) qui ne fournissent pas des performances adéquates, et prendre des mesures correctives, comme changer votre peering BGP.
Détection des changements de chemin réseau
Découvrir le chemin du réseau aujourd’hui ne suffit pas. Il peut changer demain en raison de modifications de routage BGP ou de conditions de réseau spécifiques. Vous avez donc besoin d’une solution qui vous permette de surveiller en permanence les chemins réseau, stocker les données à grande échelle et offrir un moyen de visualiser rapidement tout écart par rapport aux baselines.
Un exemple concret
La capture d’écran suivante montre un chemin réseau entre une station Kadiska à Singapour et un service numérique. Sur le graphique « Round Trip over Time », vous constatez une diminution de la latence du réseau. Comment l’expliquer ?
Examinons d’abord le chemin du réseau tel qu’il était avant cette diminution de latence :
Vous pouvez voir que le premier fournisseur de réseau traversé était NTT.
Examinons maintenant le chemin du réseau pour la période de diminution de la latence du réseau :
Cette fois, le premier fournisseur de réseau traversé était NewMedia. Et vous pouvez également voir que le nombre de sauts a également considérablement diminué.
Donc dans ce cas précis, configurer un peering en priorité avec NewMedia peut certainement être une bonne idée.
Si vous souhaitez poursuivre votre lecture et découvrir comment le chemin BGP impacte la performance de vos services numériques, continuez ici.
