From 96c87ced384eeae3df9ff185923afc6c58170b9a Mon Sep 17 00:00:00 2001 From: tpilat Date: Mon, 3 Apr 2017 14:00:21 +0200 Subject: [PATCH] Quelques corrections --- HowtoMTR.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/HowtoMTR.md b/HowtoMTR.md index 9cad35af..cc2e2783 100644 --- a/HowtoMTR.md +++ b/HowtoMTR.md @@ -56,12 +56,11 @@ Modifier l'interval d'envoi (défaut 1s) : On peut également lancer MTR en mode TCP : ~~~ -mtr -P 80 linuxfr.org +# mtr -P 80 linuxfr.org ~~~ Autres options utiles : -* -n: ( --no-dns) Désactive la résolution DNS * -u: Passer en UDP * -w: (--report-wide) remplace -r en fournissant les hostnames complets * -4: IPv4 @@ -105,7 +104,7 @@ Dans cette section nous allons voir comment interpréter et tirer des conclusion ### La perte de paquets -Lorsque l'on souhaite faire une analyse avec MTR, on observe deux paramètres importortants, la perte de paquets et la latence. Le première chose à regarder concerne la perte de paquets. Une perte observée sur le chemin n'est pas toujours pertinente. Une pratique commune consiste à faire du rate limiting sur l'ICMP. Vous pouvez alors observer une perte à un saut particulier. Il est facile de déterminer si la perte est à considerer ou non. Si les sauts suivants rapportent 0.0% de perte alors il s'agit de rate limiting ICMP, pas d'inquétude à avoir. +Lorsque l'on souhaite faire une analyse avec MTR, on observe deux paramètres importants, la perte de paquets et la latence. Le première chose à regarder concerne la perte de paquets. Une perte observée sur le chemin n'est pas toujours pertinente. Une pratique commune consiste à faire du rate limiting sur l'ICMP. Vous pouvez alors observer une perte à un saut particulier. Il est facile de déterminer si la perte est à considérer ou non. Si les sauts suivants rapportent 0.0% de perte alors il s'agit de rate limiting ICMP, pas d'inquétude à avoir. Voici un exemple : @@ -145,7 +144,7 @@ HOST: bofh.evolix.net Loss% Snt Last Avg Best Wrst StDev Si la perte rapportée se poursuit jusqu'à la destination alors la perte est réelle. -On peut aussi observer des cas où rate limiting et perte réel sont présents : +On peut aussi observer des cas où rate limiting et perte réelle sont présents : ~~~ Start: Sat Apr 1 19:52:13 2017 @@ -162,7 +161,7 @@ HOST: bofh.evolix.net Loss% Snt Last Avg Best Wrst StDev 10.|-- viaxoft-mrs2-backup.evoli 40.0% 10 37.2 35.9 35.2 37.2 0.5 ~~~ -Ici le cinquième saut est concerné par une perte liée à du rate limiting ICMP car les sauts suivants ne sont concernés que par une perte de 40%. La perte réel à considérer est toujours celle observée sur les sauts suivants. +Ici le cinquième saut est concerné par une perte liée à du rate limiting ICMP car les sauts suivants ne sont concernés que par une perte de 40%. La perte réelle à considérer est toujours celle observée sur les sauts suivants. Il est important d'avoir en tête que parfois la perte est due à un problème sur le chemin du retour. Les paquets peuvent arriver correctement à destination mais se perdre sur le retour ce pourquoi il est toujours utile lorsque c'est possible de lancer un MTR dans les deux sens.