mtr vs traceroute

Traceroute et mtr sont tous deux des outils de ligne de commande permettant de diagnostiquer les problèmes de réseau. Traceroute vous donne un instantané de la route empruntée par vos paquets. mtr fait la même chose mais continue à sonder, en établissant des statistiques sur la perte de paquets, la latence et la gigue au fil du temps. Cet article explique le fonctionnement de chaque outil, comment lire les résultats et quand les utiliser.

Comment fonctionne traceroute

Traceroute utilise le champ TTL (Time-to-Live) dans les en-têtes des paquets IP. Il envoie un paquet dont le TTL est fixé à 1. Le premier routeur décrémente le TTL à zéro, laisse tomber le paquet et renvoie un message ICMP "Time Exceeded". Traceroute enregistre l'adresse IP du routeur et le temps d'aller-retour, puis envoie un autre paquet dont le TTL est fixé à 2, et ainsi de suite jusqu'à ce que le paquet atteigne la destination ou la limite maximale de sauts (30 par défaut, réglable avec -m).

Par défaut, traceroute envoie trois sondes par saut, ce qui permet d'obtenir trois mesures de latence. Les protocoles diffèrent selon le système d'exploitation :

• Windows : La commande tracert envoie des demandes d'écho ICMP.
• Linux/macOS : la commande traceroute envoie des datagrammes UDP (ports 33434-33534). Utilisez -I pour ICMP ou -T pour TCP si UDP est bloqué.

L'ajout de l'option -n permet d'ignorer les recherches DNS inversées, ce qui accélère sensiblement les choses sur les chemins comportant de nombreux sauts.

Comment fonctionne le mtr

mtr (My Traceroute) utilise la même découverte de chemin basée sur le TTL que traceroute, mais il continue d'envoyer des sondes, généralement une par seconde. Au lieu de trois points de données par saut, vous obtenez des statistiques courantes : pourcentage de perte de paquets, latence moyenne, meilleurs et pires temps de réponse, et écart type (gigue).

mtr prend en charge les sondes ICMP (par défaut), UDP et TCP SYN. Le mode TCP est utile lorsque les pare-feu bloquent l'ICMP ou lorsque vous souhaitez tester un port d'application spécifique :

mtr --tcp --port 443 example.com

Pour un rapport non interactif que vous pouvez partager avec une équipe de support, utilisez le mode rapport :

mtr --report --report-cycles 100 example.com

Ce mode exécute 100 sondes et imprime un résumé. Vous pouvez également définir des tailles de paquets personnalisées avec --psize pour tester les problèmes de MTU ou de fragmentation.

mtr fonctionne nativement sous Linux et macOS. Les utilisateurs de Windows peuvent utiliser WinMTR pour une interface graphique équivalente.

Principales différences

La différence pratique se résume à des problèmes intermittents. Un simple traceroute peut facilement passer à côté d'un routeur qui laisse tomber 2 % des paquets ou d'un saut avec 15 ms de gigue. mtr les détecte parce qu'il continue à mesurer.

Lecture de la sortie

L'erreur la plus fréquente lors de la lecture des résultats de traceroute ou de mtr est de croire qu'un saut intermédiaire problématique signifie qu'il y a un vrai problème. Ce n'est généralement pas le cas.

Les astérisques (*) dans traceroute signifient que le routeur n'a pas répondu à la sonde. De nombreux routeurs sont configurés pour ignorer ou limiter le taux d'ICMP. Si les sauts suivants répondent normalement, le chemin est bon.

Laperte de paquets à un seul saut en mtr suit la même logique. Si le saut 5 montre une perte de 20 % mais que la destination finale montre une perte de 0 %, ce routeur ne fait que déprioriser les réponses des sondes. Une véritable perte de paquets se manifeste par un schéma : la perte apparaît à un saut et persiste à chaque saut suivant jusqu'à la destination.

Lessauts de latence entre les sauts sont normaux et attendus. Un saut de 10 ms à 80 ms signifie généralement que le paquet a traversé un océan ou une longue route terrestre. Ne vous préoccupez de la latence que si elle est anormalement élevée pour la distance (moins de 5 ms dans une zone métropolitaine, quelques dizaines de millisecondes d'un pays à l'autre, 80 à 150 ms en transocéanique) ou si la latence de la destination finale est inacceptable.

Il convient de prêter attention auStDev (gigue) en mtr. Des valeurs supérieures à 10 ms à n'importe quel saut peuvent poser des problèmes pour la VoIP, les appels vidéo et les jeux. Si vous constatez une gigue élevée, effectuez au moins 100 cycles pour confirmer qu'il s'agit d'une tendance durable et non d'un bref pic.

Quand utiliser chaque outil

Utilisez traceroute lorsque vous avez besoin d'une réponse rapide : la destination est-elle accessible et, dans la négative, où le chemin s'interrompt-il ? C'est le bon point de départ pour les pannes et pour vérifier le routage de base.

Utilisez mtr lorsque le problème est intermittent ou lié aux performances. Les utilisateurs qui signalent des déconnexions occasionnelles, des problèmes de qualité de la VoIP ou des pics de latence ont besoin des données continues du RTM. Exécutez au moins 50 à 100 cycles pour obtenir des statistiques fiables.

Pour un diagnostic approfondi, exécutez mtr dans les deux sens : de votre machine vers le serveur, et du serveur vers votre IP. Le routage Internet étant asymétrique, le chemin de retour peut avoir des caractéristiques complètement différentes. Si vous ne testez qu'une direction, vous risquez de ne pas voir où se situe le problème.

Si vous rencontrez des problèmes avec votre serveur dédié ou votre VPS, les équipes de support de FDC Servers acceptent les rapports mtr comme preuve de diagnostic standard pour les escalades de réseau.