La surveillance de la connectivité réseau est une partie importante de l'administration du serveur. Quelques outils comme ping, tracerroute sont simples à utiliser et fournissent des informations précieuses. Aujourd'hui, je vais vous montrer un autre outil de diagnostic puissant appelé MTR qui combine les fonctionnalités de traceroute et ping programmes. MTR signifie My Traceroute - il vous permet d'étudier la connexion réseau entre l'hôte et le serveur distant. Il fournit également les changements de latence et de performance au fil du temps. Contrairement à traceroute et ping , MTR n'est pas fourni par défaut. vous devez l'installer :
Comment installer MTR :
Sur Ubuntu/Debian :
sudo apt-get install mtr
Sur CentOS/Redhat/Fedora :
Si vous utilisez Redhat et que vous ne recevez pas de mises à jour yum, suivez la procédure Configurer yum pour utiliser le dépôt CentOS sur un système Redhat.
yum install mtr Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile ---> Package mtr.x86_64 2:0.75-5.el6 will be installed --> Finished Dependency Resolution ... ... Installed: mtr.x86_64 2:0.75-5.el6 Complete!
Comment utiliser MTR
Une fois qu'il est installé avec succès, vous pouvez commencer à l'utiliser en tapant :
mtr google.com
Il existe deux modes :un mode d'interface graphique et un mode basé sur le texte (ncurses ). Le mode par défaut est le mode Interface graphique.
Comment lancer MTR en mode texte
Pour spécifier le mode basé sur le texte, vous devez utiliser la commande ci-dessous. La commande ouvre une interface utilisateur textuelle à l'aide de ncurses , qui s'exécute en continu en mode interactif.
mtr --curses google.com
Les paquets (ICMP) traversent une série de "sauts" (routeurs ou nœuds) et atteignent la destination. La sortie peut sembler très similaire à traceroute, mais le gros avantage par rapport à traceroute est que la sortie est constamment mise à jour sur l'heure actuelle de l'aller-retour.
Comment générer un rapport à l'aide de MTR
La commande ci-dessous est émise pour générer le rapport, au lieu de s'exécuter en mode interactif. Par défaut, MTR envoie 10 paquets à l'hôte cible et met un certain temps à imprimer les statistiques du réseau. Vous pouvez changer le non. de paquets en spécifiant l'option –report-cycles=[nombre-de-paquets]. Ce mode fournit suffisamment de données dans un format utile.
mtr --report google.com or mtr --report --report-cycles=12 google.com
Comment éviter le DNS inversé
Lors de la trace du réseau, MTR trouve le nom d'hôte de chaque espoir (routeur/nœud) à l'aide de la recherche DNS inversée. Si vous voulez éviter de faire une recherche DNS inversée, utilisez simplement l'option –no-dns :
mtr --no-dns google.com
Comprendre la sortie MTR
Au-delà du chemin entre l'hôte et le serveur distant, MTR fournit des statistiques précieuses concernant la durabilité de cette connexion dans la 7e colonne, comme indiqué dans le résultat ci-dessous.
% de perte – Affiche le pourcentage de perte de paquets à chaque saut.
Snt – Affiche le nombre de paquets envoyés.
Last – Latence du dernier paquet envoyé.
Avg – Latence moyenne de tous paquets.
Meilleur – Meilleur temps aller-retour (le plus court) pour un paquet vers cet hôte.
Wrst – Pire temps aller-retour (le plus long) pour un paquet vers cet hôte.
StDev – Écart type des latences à chaque hôte.
Last, Avg, Best et Wrst sont tous mesurés en millisecondes. Plus l'écart type était élevé, plus les mesures de latence étaient incohérentes.
Considérons un exemple, pour comprendre la phrase ci-dessus :sur les 10 paquets envoyés à destination, certains paquets peuvent avoir une faible latence de 25 ms, alors que peu d'entre eux auraient un maximum de 350 ms. Après avoir fait la moyenne des latences des 10 paquets envoyés, la moyenne semble normale mais peut en fait ne pas très bien représenter les données. Ainsi, si l'écart type est élevé, examinez les meilleures et les pires colonnes pour les mesures de latence afin de vous assurer que la moyenne est une bonne représentation de la latence réelle et non le résultat d'une trop grande fluctuation.
Analyse des rapports MTR
Hôte de destination inaccessible
Si l'hôte de destination n'est pas configuré correctement ou si des règles de pare-feu ont été configurées pour supprimer les paquets ICMP, vous le voyez comme si les paquets ne pouvaient pas atteindre la destination, comme indiqué ci-dessous. Mais, il atteint la destination.
8. 10.118.225.253 0.0% 10 19.0 19.0 18.9 19.2 0.1 9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Comment vérifier la perte de paquets
Le fournisseur de services suit une pratique courante de limitation du trafic ICMP. Cela pourrait apparaître comme une perte de paquets, alors qu'en réalité il n'y a pas de perte. Vous pouvez vérifier si la perte est réelle ou due à une limitation de débit en vérifiant la colonne % de perte du saut suivant. Par exemple, dans le rapport ci-dessous, le saut suivant de 100 % de perte indique 0,0 %. Il est donc certain que la perte est due à la limitation du débit ICMP et non à la perte réelle.
5. 10.161.18.5 0.0% 5 14.7 14.5 14.4 14.7 0.1 6. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 7. 10.255.222.34 0.0% 5 14.1 14.0 13.9 14.2 0.2
Problème de délai d'attente et de route de retour
Si l'un des sauts montre ??? dans la sortie, cela peut être dû au problème dans le chemin de retour ou alternativement, les routeurs auraient rejeté le paquet ICMP. Ci-dessous, au saut 6, vous pouvez voir ??? . Cela peut être dû à l'une des raisons ci-dessus.
5. 10.161.18.5 0.0% 5 14.7 14.5 14.4 14.7 0.1 6. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 7. 10.255.222.34 0.0% 5 14.1 14.0 13.9 14.2 0.2
Conclusion
MTR est d'une grande aide lors du dépannage d'un réseau interne ou lors de problèmes de réseau. À l'aide des rapports MTR, vous pouvez avoir une idée des routeurs/hôtes sur le chemin de l'hôte distant ou d'un domaine spécifique qui sont à l'origine du problème.