evolix/wiki
22
0
Fork 0
Code Releases Activity

Quelques corrections

Browse source
This commit is contained in:
tpilat 2017-04-03 14:00:21 +02:00
parent 1986d04357
commit 96c87ced38
1 changed files with 4 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
HowtoMTR.md
View file

@ -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.