Présentation
MTR (à l'origine, Matt's TraceRoute, maintenant juste My TraceRoute) est un outil pratique et léger dans l'arsenal d'un administrateur UNIX/Linux qui peut aider à identifier et à diagnostiquer les problèmes de réseau courants tels que la latence, la perte de paquets et les erreurs de routage. C'est un puissant outil 2 en 1 qui combine et affiche les résultats d'un traceroute et d'un ping avec une seule commande. Passons en revue les bases de l'utilisation de MTR et comment interpréter les données qu'il fournit.
Prérequis
- Vous aurez besoin d'un serveur Linux, et si vous n'en avez pas déjà, vous pouvez visiter notre page d'hébergement VPS et créer un nouveau serveur en moins de 30 secondes
Installer MTR
Les packages MTR sont disponibles pour la plupart des systèmes d'exploitation Linux (ou UNIX) populaires d'aujourd'hui.
Installez MTR sur Ubuntu/Debian :
sudo apt-get install mtr-tiny
Le
mtr-tinypackage est la version en ligne de commande uniquement dumtrforfait. Lemtrinclut la prise en charge de l'interface graphique X-11.
Installez MTR sur CentOS/Fedora :
yum install mtr
Installez MTR sur Arch Linux :
pacman -S mtr
Installez MTR sur FreeBSD :
pkg install mtr
.
Fonctionnement de la MTR
Pour comprendre la sortie générée par MTR, vous trouverez peut-être utile de savoir comment cela fonctionne. Si vous savez déjà comment le traceroute commande fonctionne, alors cette explication vous semblera familière.
MTR génère un paquet de requête d'écho ICMP destiné à l'adresse IP cible/nom d'hôte de votre mtr commande. Le premier paquet aura une valeur de durée de vie (TTL) de 1. Lorsque ce paquet arrive au routeur qui est sa passerelle sur son chemin vers sa destination éventuelle, le routeur récepteur décrémentera le TTL de 1, le rendant 0 Lorsqu'un TTL atteint 0, le routeur supprime le paquet et envoie à l'expéditeur d'origine un paquet ICMP Time Exceeded. Ce paquet de retour contient l'adresse IP de l'expéditeur et MTR affiche cette adresse IP (ou nom d'hôte, s'il peut le résoudre) comme premier saut. Ensuite, il envoie un paquet ICMP Echo Request séparé avec un TTL de 2, et lorsqu'il reçoit le paquet ICMP Time Exceeded de l'expiration TTL, il répertorie ce périphérique comme deuxième saut, et ainsi de suite jusqu'à ce que la destination renvoie un paquet ICMP Echo Reply .
.
Lire les rapports MTR
En plus de répertorier chaque saut de réseau entre l'expéditeur et la destination, MTR garde également une trace des statistiques liées au temps d'aller-retour des paquets de l'hôte d'origine à chaque saut en cours de route. Ce temps d'aller-retour est souvent appelé latence .
Pour avoir une meilleure idée ou une meilleure idée de ce que MTR nous dit, regardons un exemple qui trace la route vers le DNS public de Google.
sudo mtr -r 8.8.8.8
[sample results below]
HOST: endor Loss% Snt Last Avg Best Wrst StDev
1. 69.28.84.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
2. 38.104.37.141 0.0% 10 1.2 1.4 1.0 3.2 0.7
3. te0-3-1-1.rcr21.dfw02.atlas. 0.0% 10 0.8 0.9 0.8 1.0 0.1
4. be2285.ccr21.dfw01.atlas.cog 0.0% 10 1.1 1.1 0.9 1.4 0.1
5. be2432.ccr21.mci01.atlas.cog 0.0% 10 10.8 11.1 10.8 11.5 0.2
6. be2156.ccr41.ord01.atlas.cog 0.0% 10 22.9 23.1 22.9 23.3 0.1
7. be2765.ccr41.ord03.atlas.cog 0.0% 10 22.8 22.9 22.8 23.1 0.1
8. 38.88.204.78 0.0% 10 22.9 23.0 22.8 23.9 0.4
9. 209.85.143.186 0.0% 10 22.7 23.7 22.7 31.7 2.8
10. 72.14.238.89 0.0% 10 23.0 23.9 22.9 32.0 2.9
11. 216.239.47.103 0.0% 10 50.4 61.9 50.4 92.0 11.9
12. 216.239.46.191 0.0% 10 32.7 32.7 32.7 32.8 0.1
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. google-public-dns-a.google.c 0.0% 10 32.7 32.7 32.7 32.8 0.0
Les rapports MTR, par défaut, affichent les colonnes suivantes :
– Perte % =Le pourcentage de paquets pour lesquels aucune réponse ICMP n'a été reçue.
– Snt =Le nombre de paquets envoyés à chaque saut.
– Dernier =Le temps d'aller-retour de la dernière sonde traceroute, en millisecondes.
– Avg =Le temps moyen aller-retour de toutes les sondes traceroute, en millisecondes.
– Meilleur =Le temps d'aller-retour le plus court de toutes les sondes traceroute, en millisecondes.
– Wrst =Le temps d'aller-retour le plus long de toutes les sondes traceroute, en millisecondes.
– StDev =Les résultats de la sonde d'écart type à chaque saut.
.
Obtenir un rapport en direct de MTR
Si vous exécutez MTR avec juste une adresse IP cible (ou un nom d'hôte), vous obtiendrez un rapport en direct qui continuera jusqu'à ce que vous terminiez votre session ou que vous exécutiez la commande break (Ctrl+C ).
sudo mtr 8.8.8.8
Certains systèmes d'exploitation nécessitent
sudoavant d'exécuter lemtrcommande; d'autres non.
.
Si vous souhaitez mettre en pause MTR, appuyez sur p . MTR conservera tous les décomptes collectés pendant la pause, vous permettant de prendre une capture d'écran ou de copier les données dans votre presse-papiers. Réactivez MTR avec la barre d'espace.
.
Génération d'un rapport MTR à nombre fixe
Vous pouvez également générer un rapport MTR après un nombre spécifique de sondes de trace avec le -r option (la forme longue est --report ). Le nombre de comptes par défaut est 10, mais si vous souhaitez exécuter MTR pour un nombre différent de comptes, utilisez le -c (--report-cycles ) également. Par exemple, si vous souhaitez générer un rapport sur 200 comptes :
sudo mtr -rc 200 8.8.8.8 [long form] sudo mtr --report --report-cycles 200 8.8.8.8
Tout MTR exécuté avec le -r L'option ne produira aucune sortie (contrairement au rapport en direct ci-dessus) tant qu'elle n'aura pas terminé le nombre total de comptages. MTR envoie une série de sondes de trace une fois par seconde par défaut, donc un rapport devrait se terminer en un peu plus d'un nombre de secondes égal à votre nombre de comptage (200 secondes dans l'exemple ci-dessus).
.
Autres options utiles
Il existe plusieurs autres options que vous pourriez trouver utiles lors de l'utilisation de MTR. Ceux qui ne nécessitent pas d'arguments (comme -r ) peuvent être chaînés dans la même chaîne d'options (par exemple, -rn ). Une option nécessitant un argument ne peut être incluse dans l'une de ces chaînes que si elle est la dernière option et qu'elle est suivie de son argument (par exemple, -rnc 200 ).
-n:(forme longue--no-dns) Désactivez les recherches de nom d'hôte DNS. LenLa clé peut également être utilisée lors d'un rapport en direct pour basculer entre la désactivation et l'activation des recherches DNS.-u:Envoie des datagrammes UDP au lieu de paquets de requête d'écho ICMP. Leupeut également basculer entre UDP et ICMP lors d'un rapport en direct.-w:(forme longue--report-wide) Remplace-rmais produit un rapport qui ne tronque pas les noms d'hôtes plus longs.-i* :(forme longue--interval) Spécifiez l'intervalle, en secondes, entre les sondes de test. L'intervalle par défaut est de 1 seconde.-4:Restreindre le test à IPv4.-6:Restreindre le test à IPv6.
.
Analyse des données MTR pour la latence
La sortie des données MTR peut vous aider à identifier les problèmes que vous ou l'un des opérateurs Internet pouvez rencontrer avec le routage. Cela peut également aider à définir une référence pour la latence attendue entre les points de terminaison.
Répétons ici que les temps générés par MTR sont les temps d'aller-retour pour qu'un paquet ICMP atteigne le saut auquel son TTL expire, pour que l'appareil traite cette expiration pour générer un paquet ICMP Time Exceeded, et pour que ce paquet revienne à l'appareil d'origine. Pour de nombreux routeurs, l'exécution de la réponse ICMP pour les paquets abandonnés est une faible priorité et sur certains appareils, elle est entièrement désactivée.
Pour l'une de ces raisons, vous verrez probablement des cas où un saut intermédiaire affiche un pic occasionnel dans la colonne "Dernier" ou "Pire". Tant que le saut de latence ne se propage pas également à chaque saut suivant, alors ce que vous voyez est le retard du mécanisme de réponse sur cet appareil, par opposition à la véritable latence de débit. Prenons, par exemple, la sortie MTR suivante :
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. vl223-ar-01.nyc-ny.atlantic.net 0.0% 66 0.5 6.1 0.5 140.2 25.5 2. te0-0-1-1.rcr11.ewr04.atlas.cogentco.com 0.0% 66 1.0 1.0 0.8 2.8 0.2 3. te0-3-0-4.rcr21.ewr02.atlas.cogentco.com 0.0% 66 1.1 1.1 0.9 2.5 0.2 4. be2601.rcr24.jfk01.atlas.cogentco.com 0.0% 66 1.6 1.7 1.5 2.0 0.0 5. be2632.ccr42.jfk02.atlas.cogentco.com 0.0% 66 1.7 1.8 1.6 3.0 0.1 6. be2807.ccr42.dca01.atlas.cogentco.com 0.0% 66 8.3 8.1 7.7 12.1 0.6 7. be2113.ccr42.atl01.atlas.cogentco.com 9.1% 66 27.5 21.7 18.6 34.7 3.9 8. be2123.ccr22.mia01.atlas.cogentco.com 0.0% 66 33.0 33.4 33.0 41.5 1.1 9. be2055.ccr21.mia03.atlas.cogentco.com 0.0% 66 33.3 33.6 33.1 36.3 0.4 10. 38.104.95.170 0.0% 65 40.8 40.9 40.7 42.0 0.1 11. 209.208.7.42 0.0% 65 41.6 43.3 40.9 187.9 18.2 12. [target host] 0.0% 65 41.1 41.1 40.9 41.3 0.0
Voyez comment le premier saut et le onzième saut ont chacun un pire temps bien supérieur à leurs moyennes ? Beaucoup regardent un indicateur comme celui-ci et supposent qu'il représente une preuve de latence de débit. Mais remarquez comment les deuxième et douzième sauts ne montrent pas également un pire moment similaire ? Si la colonne du pire temps pour chaque saut suivant affichait le même temps ou un temps supérieur, nous pourrions alors prendre ce résultat d'un incident indiquant des problèmes de latence potentiels. Notez, en revanche, la colonne de temps moyen, en particulier entre les sauts 6 et 7. La moyenne saute de 8,3 millisecondes à 21,7 millisecondes, et chaque saut suivant a un nombre plus élevé. Cette colonne montre un exemple de véritable latence, dans ce cas entre des routeurs à Washington, D.C, et à Atlanta, GA (ce résultat est assez normal selon les normes de 2015).
Vous pouvez également voir des sauts intermédiaires de manière sporadique ou même systématiquement supprimer des paquets. Encore une fois, tant que ces baisses sont isolées sur un seul appareil et ne sont pas cohérentes sur tous les sauts suivants, il s'agit très probablement d'un symptôme de la perte de priorité des messages de réponse ICMP Time Exceeded pour un trafic de transit plus important (vous pouvez voir un exemple de cette baisse dans le saut 7 ci-dessus). Dans certains cas, les administrateurs réseau configurent les routeurs pour qu'ils ne répondent pas du tout avec des réponses ICMP Time Exceeded. Vous pouvez voir ces sauts apparaître comme une chute de 100 % du trafic alors que les sauts au-delà sont toujours réactifs (dans le premier exemple de cet article, vous pouvez voir un exemple de ce comportement dans le saut 13 montrant une perte de 100 % et ne montrant pas l'IP de ses hôtes ou nom d'hôte).
.
Et ensuite ?
Cet article n'est qu'une introduction à la façon dont vous pouvez utiliser l'outil MTR pour examiner votre connectivité réseau à divers points de terminaison sur Internet. Bien qu'il reste encore beaucoup à apprendre, les informations présentées ici devraient vous donner un bon départ pour pouvoir diagnostiquer les problèmes de réseau que vous pourriez rencontrer. Merci d'avoir lu, et revenez nous voir pour d'autres mises à jour et des didacticiels et articles d'hébergement VPS plus avancés comme Qu'est-ce que :les bases de la mise en réseau – Commutateurs, routeurs et pare-feu.
En savoir plus sur nos services d'hébergement VPS et nos serveurs privés virtuels.
.
.