Qu'est-ce que MTR ? Lancer et lire un rapport mtr

MTR (My Traceroute, à l'origine Matt's traceroute) combine traceroute et ping. Il repère chaque routeur entre vous et une destination, puis continue d'envoyer des sondes à chacun d'eux et tient des statistiques. Un traceroute donne un seul instantané du chemin ; un rapport mtr en compile une centaine, résumés saut par saut. Au programme : l'installation, les options qui comptent, et un vrai rapport issu de nos serveurs, lu colonne par colonne.

Installer mtr

Système	Installation	Lancement
Debian, Ubuntu	sudo apt install mtr-tiny (texte seul) ou mtr	mtr example.com
Fedora, RHEL, Rocky	sudo dnf install mtr	mtr example.com
macOS	brew install mtr	sudo mtr example.com
Windows	WinMTR, un programme distinct aux colonnes similaires, ou mtr dans WSL 2	Lancer WinMTR, saisir l'hôte

Sous macOS, Homebrew installe mtr dans son dossier sbin, qui n'est pas toujours dans le PATH, et mtr a besoin de sudo pour envoyer ses sondes. Sans option, mtr ouvre un écran en direct, rafraîchi chaque seconde (appuyez sur q pour quitter). Pour tout ce que vous voulez conserver ou envoyer, utilisez le mode rapport, qui exécute un nombre fixe de cycles et affiche le résultat une seule fois :

mtr -rwz -c 100 example.com

Les options à connaître

Option	Effet
-r	Mode rapport : mesure, puis affiche un tableau à coller n'importe où
-w	Rapport large : noms d'hôte complets au lieu de noms tronqués
-c 100	Nombre de sondes par saut. 10 pour un coup d'œil rapide ; 100 pour un rapport à envoyer à un opérateur
-z	Affiche le numéro d'AS de chaque saut, pour voir où un réseau passe la main au suivant
-n	Pas de résolution DNS inverse : plus rapide, mais vous perdez les noms des routeurs, qui contiennent souvent un code de ville
-b	Affiche à la fois le nom et l'adresse IP de chaque saut
-T -P 443	Sondes TCP vers le port 443, pour les réseaux qui bloquent l'ICMP
-u	Sondes UDP au lieu d'ICMP
-4, -6	Force IPv4 ou IPv6
-i 0.5	Secondes entre deux sondes (1 par défaut ; seul root peut descendre sous 1)
--json	Sortie exploitable par un programme

Un vrai rapport, lu colonne par colonne

Nous l'avons lancé le 7 octobre 2026 à 12:26 UTC depuis notre serveur de Falkenstein, en Allemagne (Hetzner), vers un hôte de test Vultr dans le New Jersey, avec 100 sondes par saut. Seul le nom d'hôte de notre machine a été raccourci :

$ mtr -rwz -c 100 nj-us-ping.vultr.com
HOST: falkenstein                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.0.1                           73.0%   100    0.2   0.1   0.0   0.2   0.0
  2. AS24940  ex9k1.dc11.fsn1.hetzner.com           0.0%   100    4.7   1.0   0.3  15.1   1.7
  3. AS24940  core22.fsn1.hetzner.com               0.0%   100    0.8   0.7   0.3   1.7   0.2
  4. AS24940  juniper5.dc2.nbg1.hetzner.com         0.0%   100    3.0   5.2   2.8  65.6   9.2
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
  7. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  8. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  9. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
 10. AS20473  66.55.138.149.vultrusercontent.com    2.0%   100   85.7  85.9  85.6  87.3   0.2
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

• Loss% : la proportion de sondes restées sans réponse à ce saut. Elle vaut ici 73 % au saut 1 et 2 % au saut 10, mais 0 % à la destination. Rien de tout cela n'est une vraie perte (voir plus bas).
• Snt : le nombre de sondes envoyées à chaque saut, 100 ici.
• Last, Avg, Best, Wrst : les temps d'aller-retour en millisecondes pour la dernière sonde, en moyenne, pour la plus rapide et pour la plus lente. Best est la valeur la plus proche de ce que le chemin permet physiquement : 85,9 ms jusqu'au New Jersey.
• StDev : la dispersion des temps, autrement dit la gigue. De 0,1 à 0,2 ms sur la plupart des sauts : un chemin calme.
• AS (avec -z) : le réseau auquel appartient chaque adresse. Les sauts 2 à 4 sont chez Hetzner (AS24940), les sauts 5 et 6 chez Core-Backbone (AS201011), les sauts 10 et 11 chez Vultr (AS20473). C'est aux interconnexions entre ces réseaux que la congestion se voit d'habitude, quand il y en a.
• Noms : les noms des routeurs indiquent souvent une ville. Le saut 5 est nbg40 (Nuremberg) à 3 ms et le saut 6 nyk10 (New York) à 86,7 ms : la traversée de l'Atlantique, en une seule ligne.

Trois anomalies apparentes de ce rapport, qui n'en sont pas

1. Une perte à un saut, qui ne se prolonge pas. Au saut 1 (la passerelle du conteneur dans lequel tourne le test), 73 % des réponses manquent, 2 % au saut 10, et tous les sauts suivants répondent à tout. Les routeurs répondent aux sondes en logiciel, avec une faible priorité, et beaucoup limitent le nombre de réponses qu'ils envoient par seconde. Le trafic qui les traverse n'est pas affecté.
2. Un saut lent suivi de sauts rapides. Le saut 4 affiche 5,2 ms en moyenne et 65,6 ms au pire, alors que le saut 5, juste après, ne dépasse jamais 3,3 ms. Le routeur a pris son temps pour répondre à certaines sondes ; il n'a pas retardé les paquets qu'il a relayés.
3. Des sauts muets. Les sauts 7 à 9 ne répondent jamais (???, 100 %). Ce sont des routeurs configurés pour ne pas répondre. Puisque les sauts 10 et 11 répondent, les paquets les traversent bel et bien.

La règle qui en découle : une perte ou une latence ne compte que si elle commence à un saut et se maintient jusqu'à la destination. Si le saut 6 montrait 15 % de perte et les sauts 7 à 11 la même chose, le problème commencerait au saut 6 ou sur le lien juste avant. Un pic qui disparaît au saut suivant vient du routeur, pas du chemin.

Le même rapport, lancé à la même minute vers Singapour, montre ces effets encore plus nettement : un routeur d'Arelion à Hambourg n'a répondu qu'à 47 % des sondes, un autre à Singapour qu'à 18 %, avec un pire temps de 381,6 ms, et la destination a répondu à 100 % d'entre elles en 165,5 ms en moyenne.

Combien de sondes, depuis où, et quand

• 10 sondes suffisent pour voir le chemin. Il en faut 100 pour mesurer la perte : avec 10 sondes, une perte de 1 % apparaît le plus souvent comme 0 %.
• Lancez-le pendant que le problème se produit. Un mtr lancé une heure plus tard montre un chemin sain et ne prouve rien.
• Lancez-le depuis plusieurs endroits. Le même hôte du New Jersey, mesuré à la même minute depuis notre serveur de Gravelines, en France (OVHcloud), a répondu en 71,7 ms au lieu de 86,4 ms : OVH achemine le trafic sur son propre réseau jusqu'à New York et le remet à Vultr au point d'échange NYIIX, alors que depuis Falkenstein il passe par Core-Backbone. Même destination, deux routes, 15 ms d'écart.
• Pensez au chemin retour. Chaque temps du rapport est un aller-retour, et le retour peut suivre une autre route, que mtr ne voit pas. Si vous le pouvez, lancez aussi mtr depuis l'autre extrémité.

Envoyer un rapport mtr à votre opérateur

• Utilisez mtr -rwzb -c 100 : le rapport, les noms complets, les numéros d'AS et les adresses IP.
• Notez la date, l'heure avec son fuseau horaire, votre IP publique et la destination.
• Si l'ICMP est filtré quelque part sur le chemin, ajoutez -T -P 443 et précisez-le.
• Désignez le premier saut où la perte ou la latence apparaît et se maintient jusqu'au bout, pas le saut qui affiche le plus gros chiffre.

mtr, traceroute et ping

Outil	Ce qu'il mesure	Sonde par défaut	Idéal pour
ping	L'aller-retour et la perte, jusqu'à la destination seulement	ICMP echo	Savoir si l'hôte répond, en combien de temps, avec quelle stabilité
traceroute	Le chemin, trois sondes par saut, une seule fois	UDP sous Linux et macOS, ICMP sous Windows (tracert)	Voir la route
mtr	Le chemin, avec des statistiques de perte et de latence pour chaque saut	ICMP (UDP ou TCP sur demande)	Problèmes intermittents, preuves pour un opérateur

Sous Windows, sans WinMTR, la commande intégrée pathping fait à peu près la même chose en deux passes : un tracé, puis environ 25 secondes de sondes par saut. Pour les différences entre les deux premiers outils, voir traceroute ou ping ; pour la commande traceroute de chaque système, voir la commande traceroute sous Windows, Mac et Linux.

Quand vous ne pouvez pas le lancer vous-même

Les réseaux d'entreprise bloquent souvent les sondes, un téléphone ne peut pas exécuter mtr, et un test depuis votre propre connexion ne dit rien du chemin depuis ailleurs. TraceMapper lance le même test depuis nos serveurs et depuis plus de 30 points de mesure, place chaque saut sur une carte avec sa latence, sa perte et son réseau, et conserve le résultat sous la forme d'un lien que vous pouvez envoyer. Pour trouver où un chemin se dégrade vraiment, voir comment repérer les goulots d'étranglement réseau.