Quelques corrections
This commit is contained in:
parent
1986d04357
commit
96c87ced38
|
@ -56,12 +56,11 @@ Modifier l'interval d'envoi (défaut 1s) :
|
||||||
On peut également lancer MTR en mode TCP :
|
On peut également lancer MTR en mode TCP :
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
mtr -P 80 linuxfr.org
|
# mtr -P 80 linuxfr.org
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
Autres options utiles :
|
Autres options utiles :
|
||||||
|
|
||||||
* -n: ( --no-dns) Désactive la résolution DNS
|
|
||||||
* -u: Passer en UDP
|
* -u: Passer en UDP
|
||||||
* -w: (--report-wide) remplace -r en fournissant les hostnames complets
|
* -w: (--report-wide) remplace -r en fournissant les hostnames complets
|
||||||
* -4: IPv4
|
* -4: IPv4
|
||||||
|
@ -105,7 +104,7 @@ Dans cette section nous allons voir comment interpréter et tirer des conclusion
|
||||||
|
|
||||||
### La perte de paquets
|
### 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 :
|
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.
|
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
|
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
|
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.
|
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.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue