MTR : comprendre et diagnostiquer le réseau
Auteur : Rédaction Domeny.ForSale Publié le
En bref : MTR, ou My Traceroute, est un outil de diagnostic réseau qui combine l’analyse du trajet des paquets avec des mesures répétées de la latence et des réponses manquantes. Sous Linux, il aide à déterminer si un problème de connexion apparaît dès le réseau local ou plus loin sur le trajet vers le serveur. La règle essentielle pour interpréter les résultats : l’absence de réponse d’un routeur ne signifie pas nécessairement qu’il perd les paquets destinés à la cible.
Comment fonctionne MTR et en quoi diffère-t-il de ping ?
ping vérifie si l’hôte indiqué répond et mesure le temps nécessaire pour recevoir sa réponse. traceroute affiche les nœuds successifs sur le trajet vers la cible. MTR combine ces fonctions : il repère le trajet et envoie des sondes à plusieurs reprises, en actualisant les résultats pour chaque nœud.
Un nœud, également appelé saut ou hop, est généralement un routeur qui transmet les paquets au suivant. MTR détecte ces équipements en augmentant progressivement le TTL, c’est-à-dire la limite du nombre de sauts d’un paquet. Lorsque cette limite est atteinte, le routeur peut renvoyer un message permettant d’identifier son adresse.
La mesure indique le temps d’aller-retour de la sonde et de sa réponse, et non la seule latence entre deux routeurs voisins. Le trajet de retour peut différer du trajet aller : le rapport ne permet donc pas toujours de localiser précisément la panne.
Installation et premier test sous Linux
Sur Debian et Ubuntu, la version en mode texte de l’outil peut généralement être installée avec les commandes suivantes :
sudo apt update
sudo apt install mtr-tiny
Dans d’autres distributions, le nom du paquet peut être différent ; il s’agit souvent de mtr. Vérifiez ce nom dans la documentation de la distribution ou avec la fonction de recherche du gestionnaire de paquets utilisé.
Pour lancer un test interactif, indiquez une adresse IP ou un nom d’hôte :
mtr 1.1.1.1
Les résultats sont actualisés jusqu’à l’arrêt du test, par exemple à l’aide de la touche q. L’adresse 1.1.1.1 sert ici à vérifier la connectivité vers une cible publique ; pour diagnostiquer un service précis, testez en priorité son hôte.
Pour enregistrer et transmettre les résultats, un rapport portant sur un nombre défini de cycles est plus pratique :
mtr -r -w -c 100 -n 1.1.1.1
L’option -r active le rapport, -w élargit son format, -c 100 définit 100 cycles de mesure et -n désactive la conversion des adresses IP en noms d’hôtes. Si le programme signale que vous n’avez pas les droits nécessaires pour envoyer des sondes, vérifiez la configuration du paquet ; selon l’installation, il peut être nécessaire de le lancer avec sudo.
Comment lire les colonnes du rapport
Chaque ligne décrit un nœud détecté. Les colonnes les plus utiles sont les suivantes :
| Colonne | Signification |
|---|---|
Loss% | Pourcentage de sondes restées sans réponse |
Snt | Nombre de sondes envoyées |
Last | Temps de réponse de la dernière sonde ayant reçu une réponse |
Avg | Temps de réponse moyen |
Best / Wrst | Temps de réponse le plus court et le plus long |
StDev | Mesure de la variabilité des temps de réponse |
Les temps sont généralement exprimés en millisecondes. Une valeur élevée de Wrst associée à une moyenne basse peut correspondre à un pic de latence isolé. Une valeur élevée de StDev indique une instabilité des mesures, mais n’en précise pas à elle seule la cause.
Ne jugez pas la connexion sur quelques sondes seulement. Recueillez, par exemple, 100 cycles pendant que le problème se manifeste, puis comparez ces résultats à une mesure effectuée lorsque le service fonctionne correctement.
Quand les réponses manquantes signalent-elles un problème ?
Les routeurs peuvent limiter les réponses de diagnostic ou leur accorder une priorité inférieure à celle de la transmission du trafic. La valeur Loss% d’un nœud intermédiaire ne mesure donc pas automatiquement les pertes de paquets de l’utilisateur.
Exemple : le quatrième nœud affiche 70% de réponses manquantes, mais tous les suivants, y compris la cible, affichent 0%. Ce résultat indique généralement que le quatrième routeur limite ses réponses, et non qu’il perd le trafic qu’il transmet. Les paquets parviennent bien aux équipements situés plus loin.
Il est plus préoccupant de constater des réponses manquantes à partir d’un certain point, puis sur les nœuds suivants et sur la cible. C’est un indice justifiant un diagnostic plus poussé, pas une preuve qu’un routeur précis est en cause : des trajets différents, le filtrage et le traitement des sondes peuvent fausser le résultat.
Interprétez les latences de la même manière. Si un routeur répond lentement et que les suivants répondent rapidement, sa valeur élevée ne prouve pas que toute la connexion est ralentie. L’absence de réponse, indiquée par les caractères ???, ne signifie pas non plus nécessairement que le trajet est interrompu.
Que vérifier lorsque le problème concerne un site web ?
Les sondes MTR utilisent par défaut ICMP, un protocole servant notamment aux messages de diagnostic. Le réseau peut les traiter différemment du trafic d’un site web. En cas de problème avec HTTPS, un test TCP sur le port 443 peut être utile :
mtr -r -w -c 100 -n --tcp -P 443 example.com
Remplacez example.com par l’hôte du service à tester. Ce test ne mesure toutefois ni le chargement de la page, ni la négociation TLS, ni le fonctionnement de l’application. Un rapport MTR sans anomalie n’exclut donc pas un problème lié au DNS, au serveur web ou à la base de données.
Si l’hôte possède des adresses IPv4 et IPv6, vous pouvez comparer les tests avec les options -4 et -6. Lorsque vous signalez le problème à l’administrateur, joignez le rapport, l’heure de la mesure avec son fuseau horaire, la cible testée et une description du symptôme. Avant toute publication, supprimez les adresses ou les noms qui révèlent une infrastructure privée.
Voir aussi : Qu’est-ce que ping ?
À lire aussi
