MTR signifie My Traceroute.
Il s'agit d'un puissant outil de diagnostic réseau qui combine la puissance des commandes Ping et Traceroute.
Il permet à l'administrateur de diagnostiquer et d'isoler les erreurs de réseau et de fournir des rapports utiles sur l'état du réseau.
Dans cet article, nous expliquerons comment installer, utiliser et analyser le rapport fourni par la commande MTR.
MTR fonctionne en envoyant des paquets ICMP en augmentant progressivement la valeur TTL pour trouver la route entre la source et la destination donnée.
1. Mise en place
Sur les systèmes Debian ou Ubuntu, utilisez la commande suivante :
$ sudo apt-get install mtr
Sur les systèmes Centos et Fedora, exécutez la commande suivante :
$ yum install mtr
2. Exécuter mtr pour un domaine
MTR fonctionne en deux modes, un mode graphique (X11) et un mode texte (ncurses). Par défaut, la commande mtr s'exécute en mode X11.
$ mtr google.com
La commande ci-dessus ouvrira une fenêtre graphique et affichera les résultats.
3. Lancer le mode texte en utilisant –curses
Utilisez l'option –curses pour exécuter mtr en mode terminal.
$ mtr --curses google.com
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. mblaze.hilink 0.0% 20 3.2 2.7 2.1 3.8 0.5
2. 10.228.129.9 0.0% 20 187.7 61.8 41.6 187.7 31.3
3. 10.228.149.14 0.0% 20 112.1 60.2 33.2 112.1 17.8
4. 116.202.226.145 0.0% 20 57.9 63.2 35.2 147.6 24.4
5. 116.202.226.21 0.0% 20 35.4 70.4 35.4 211.8 48.6
6. 72.14.219.94 0.0% 20 58.9 74.6 43.4 231.2 44.2
7. 72.14.233.204 0.0% 20 46.9 69.8 40.3 222.5 41.9
8. 72.14.239.20 0.0% 20 94.1 259.2 68.8 3436. 748.2
9. 209.85.244.111 0.0% 20 86.4 97.5 72.1 232.2 34.3
10. google.com 0.0% 19 387.9 132.5 71.8 387.9 84.9 Ce qui précède fonctionnera en continu en mode interactif.
En mode interactif, le résultat reflétera le temps d'aller-retour actuel, pour chaque hôte. Dans l'exemple ci-dessus, le paquet a voyagé à travers "mblaze.hilink", (mon routeur local), puis à travers une série de "sauts", et atteint la destination.
Les sauts sont des routeurs ou des nœuds sur Internet par lesquels le paquet voyage pour atteindre la destination.
4. Omettre le DNS inverse en utilisant –no-dns
MTR trouve le nom d'hôte de chaque routeur/nœud à l'aide de la recherche DNS inversée. Si vous voulez éviter de faire une recherche DNS inversée, utilisez l'option –no-dns.
$ mtr --curses --no-dns google.com
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 2 3.0 2.9 2.9 3.0 0.1
2. 10.228.129.9 0.0% 2 58.6 49.6 40.7 58.6 12.7
3. 10.228.149.14 0.0% 2 46.1 46.8 46.1 47.6 1.0
4. 116.202.226.145 0.0% 2 61.8 61.6 61.3 61.8 0.3
5. 116.202.226.17 0.0% 2 42.7 39.9 37.0 42.7 4.0
6. 72.14.215.234 0.0% 2 47.1 43.9 40.7 47.1 4.5
7. 72.14.232.110 0.0% 2 56.9 60.7 56.9 64.4 5.3
8. 72.14.239.22 0.0% 2 111.5 95.0 78.5 111.5 23.3
9. 209.85.244.23 0.0% 2 126.0 102.4 78.8 126.0 33.4
10. 209.85.223.113 0.0% 10 76.4 92.7 75.4 157.3 29.5
11. 74.125.200.102 0.0% 1 78.4 78.4 78.4 78.4 0.0 5. Exécutez mtr en mode rapport en utilisant –report
Au lieu d'exécuter MTR en mode interactif, vous pouvez l'exécuter en mode rapport en utilisant –report. En mode rapport, mtr s'exécute pendant le nombre de cycles (par défaut 10), puis imprime les statistiques et quitte. Ce mode sera utile pour générer des statistiques sur la qualité du réseau.
$ mtr --no-dns --report google.com HOST: lakshmanan Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.1.1 0.0% 10 2.5 3.0 2.4 4.2 0.6 2.|-- 10.228.129.9 0.0% 10 235.0 74.4 34.0 235.0 67.9 3.|-- 10.228.149.14 0.0% 10 154.8 65.5 38.7 154.8 34.8 4.|-- 116.202.226.145 0.0% 10 60.9 66.9 48.2 102.4 15.4 5.|-- 116.202.226.17 0.0% 10 54.1 65.1 36.0 194.5 46.8 6.|-- 72.14.215.234 0.0% 10 44.5 78.8 39.2 252.7 64.5 7.|-- 72.14.232.110 0.0% 10 55.7 66.4 39.1 179.8 41.8 8.|-- 66.249.94.72 0.0% 10 68.9 90.3 68.9 133.6 18.6 9.|-- 72.14.233.105 0.0% 10 68.8 76.3 68.8 92.2 7.3 10.|-- 173.194.38.162 0.0% 10 88.7 107.3 72.2 293.1 65.8
Dans l'exemple ci-dessus, mtr a fonctionné pendant 10 cycles et a collecté les statistiques. Les utilisateurs peuvent modifier le nombre de cycles à l'aide de l'option -c.
Comprendre le rapport MTR
En plus de fournir des informations sur le chemin entre la source et la destination, MTR fournit des statistiques précieuses sur la durabilité de la connexion.
- Lost% – Affiche le % de perte de paquets à chaque saut.
- Snt – Affiche le nombre de paquets envoyés.
- Dernier :latence du dernier paquet envoyé.
- Avg :latence moyenne de tous les paquets.
- Meilleur – Affiche le meilleur temps aller-retour pour un paquet vers cet hôte (RTT le plus court).
- Wrst – Affiche le pire temps d'aller-retour pour un paquet vers cet hôte (RTT le plus long).
- StDev :fournit l'écart type des latences pour chaque hôte.
Même si le "Avg" semble bon, jetez un œil à l'écart type. Si l'écart type est élevé, cela peut indiquer que "Avg" est biaisé par une erreur de mesure ou trop de fluctuation. Dans ce cas, jetez un coup d'œil à la meilleure et à la première latence pour vous assurer que la moyenne est bonne.
Analyser les rapports MTR
1. Vérifier la perte de paquets
Il existe une pratique courante parmi les services fournis pour « limiter le débit » du trafic ICMP. Cela peut donner l'illusion d'une perte de paquets, alors qu'en fait il n'y a pas de perte. Pour vérifier si la perte est réelle ou due à une limitation de débit, vérifiez le «% de perte» du prochain saut. S'il affiche 0,0 %, vous pouvez être sûr que le "% de perte" signalé est dû à la limitation du taux ICMP et non à la perte réelle.
10.|-- 209.85.250.237 0.0% 10 85.6 97.5 76.0 172.0 27.2 11.|-- 209.85.250.203 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- 74.125.135.138 0.0% 10 77.2 107.3 77.2 219.5 43.5
Dans la sortie ci-dessus, bien qu'elle affiche une perte de 100,0 % entre les sauts 10 et 11, le prochain saut 12 signale une perte de paquets de 0,0 %, ce qui signifie que la perte signalée sur le saut 11 est uniquement due à la limitation du débit ICMP.
Si la perte continue pendant plus d'un saut, il est possible qu'il y ait une perte de paquets. Notez également que la limitation de débit et la perte de paquets peuvent se produire simultanément. Dans ce cas, prenez le pourcentage de perte le plus bas dans une séquence comme perte réelle.
2. Mauvaise mise en réseau de l'hôte de destination
13.|-- 4.69.168.254 0.0% 10 293.3 304.7 276.0 441.0 48.5 14.|-- 4.69.161.105 10.0% 10 287.5 291.7 261.2 393.6 40.0 15.|-- 4.69.137.50 0.0% 10 412.2 299.2 266.9 412.2 48.6 16.|-- 4.69.134.146 10.0% 10 260.5 281.8 260.3 320.1 22.0 17.|-- 4.69.134.129 10.0% 10 294.7 303.5 268.0 397.8 41.8 18.|-- 4.69.132.177 10.0% 10 287.8 341.6 262.7 470.4 77.4 19.|-- 4.71.162.50 10.0% 10 280.8 276.0 257.8 323.2 21.3 20.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Dans l'exemple ci-dessus, il peut sembler que les paquets n'ont pas atteint la destination. Mais il arrive à destination. Cela peut être le résultat de règles d'hôte ou de pare-feu mal configurées pour supprimer les paquets ICMP.
3. Problème de délai d'attente et de route de retour
Parfois, les routeurs rejetteront l'ICMP et il sera affiché comme ??? sur la sortie. Sinon, il peut également y avoir un problème avec l'itinéraire de retour.
9.|-- 209.85.244.25 0.0% 10 260.6 147.0 78.1 260.6 75.3 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 11.|-- 74.125.200.100 0.0% 10 84.8 112.4 75.6 234.4 63.9
Dans l'exemple ci-dessus, soit le routeur du saut 10 ne répond pas à ICMP, soit il y a un problème dans la route de retour du paquet.