mirroir readonly du Gitit wiki.evolix.org (attention, ne rien commiter/merger sur ce dépôt) https://wiki.evolix.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

HowtoMTR.md 9.8 KiB

3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194
  1. ---
  2. title: Howto MTR
  3. categories: tips network
  4. ...
  5. * Manpage <https://manpages.debian.org/stable/mtr-tiny/mtr.8.en.html>
  6. * Code source : <https://github.com/traviscross/mtr>
  7. [MTR (My traceroute)](http://www.bitwizard.nl/mtr/) est un outil de diagnostic réseau combinant les fonctionnalités des programmes _traceroute_ et _ping_.
  8. ## Principe
  9. Pour décrire l'itinéraire emprunté, MTR utilise les paquets ICMP _Time Exceeded_ renvoyés par les routeurs intermédiaires et les paquets ICMP _Echo Reply_ renvoyés par l'hôte de destination. Les paquets ICMP envoyés ont des TTLs augmentant progressivement jusqu'à la destination. Le TTL (Time To Live) contrôle le nombre de sauts qu'un paquet fera avant d'expirer. De cette façon après un saut (TTL=1), le premier routeur décrémentera le TTL de 1, le passant à 0. Ainsi le paquet expirera et un paquet ICMP _Time Exceeded_ sera transmis à l'émetteur contenant l'IP du routeur. S'en suivra un paquet avec un TTL à deux, puis trois, et ainsi de suite jusqu'à ce que l'hôte de destination renvoie un paquet ICMP _Echo Reply_. Parallèlement, MTR collecte des informations supplémentaires tel que le temps d'aller-retour et la perte de paquets éventuelle pour chacun des équipements traversés jusqu'à la destination. Cela en fait un outil idéal pour diagnostiquer des problèmes réseau.
  10. ## Installation
  11. Sous Debian
  12. ~~~
  13. # apt install mtr
  14. ~~~
  15. > *Note* : pour installer la version sans couche graphique, utiliser le paquet **mtr-tiny**
  16. Sous OpenBSD :
  17. ~~~
  18. # pkg_add mtr
  19. ~~~
  20. ## Utilisation de base
  21. Utiliser l'interface "ncurses" (`-t` ou `--ncurses`) :
  22. ~~~
  23. $ mtr example.com --curses
  24. ~~~
  25. Sans résolution DNS (`-n` ou `--no-dns`) :
  26. ~~~
  27. $ mtr example.com --curses -n
  28. ~~~
  29. > *Note* : on peut désactiver/activer la résolution DNS en live en appuyant sur la touche `n`
  30. Lancer en mode rapport (`-r` ou `--report`) :
  31. ~~~
  32. $ mtr example.com -r
  33. ~~~
  34. Modifier l'intervalle d'envoi (défaut 1 seconde) :
  35. ~~~
  36. # mtr example.com --curses -i 0.1
  37. ~~~
  38. On peut également lancer MTR en mode TCP sur un port donné :
  39. ~~~
  40. # mtr example.com --curses --tcp -P 80
  41. ~~~
  42. Autres options utiles :
  43. * `-u` passe en UDP
  44. * `-w` (--report-wide) remplace `-r` en fournissant les hostnames complets
  45. * `-4` force en IPv4
  46. * `-6` force en IPv6
  47. ~~~
  48. Start: Fri Mar 31 14:04:36 2017
  49. HOST: foo.example.net Loss% Snt Last Avg Best Wrst StDev
  50. 1.|-- routeur1.example.net 0.0% 10 0.9 0.8 0.5 1.0 0.0
  51. 2.|-- routeur2.example.net 0.0% 10 1.0 1.1 0.8 1.4 0.0
  52. 3.|-- routeur3.example.net 0.0% 10 2.4 9.4 1.8 21.2 7.3
  53. 4.|-- routeur4.example.net 0.0% 10 11.6 25.9 11.1 139.2 40.2
  54. 5.|-- routeur5.example.net 0.0% 10 5.4 7.3 5.3 21.5 5.0
  55. 6.|-- routeur6.example.net 0.0% 10 12.0 11.8 11.4 12.1 0.0
  56. 7.|-- routeur7.example.net 0.0% 10 11.5 11.7 11.4 12.1 0.0
  57. 8.|-- routeur8.example.net 0.0% 10 15.4 15.8 11.7 19.7 2.6
  58. 9.|-- routeur9.example.net 0.0% 10 12.2 12.4 11.9 12.9 0.0
  59. 10.|-- routeur10.example.net 0.0% 10 12.0 12.2 11.8 13.6 0.3
  60. 11.|-- example.com 0.0% 10 11.7 13.0 11.7 23.1 3.5
  61. ↑ ↑ ↑ ↑ ↑ ↑ ↑
  62. | | | | | | |
  63. | | | | | | −− Écart type des latences : différence entre les mesures de la
  64. | | | | | | latence.
  65. | | | | | |
  66. | | | | | −− Moins bonne latence
  67. | | | | |
  68. | | | | −− Meilleur latence
  69. | | | |
  70. | | | −− Latence moyenne de tous les paquets envoyés
  71. | | |
  72. | | −− Latence du dernier paquet envoyé
  73. | |
  74. | −− Nombre de paquets envoyés
  75. |
  76. −− Pourcentage de perte de paquets à chaque saut
  77. ~~~
  78. ## Diagnostics réseau
  79. Dans cette section nous allons voir comment interpréter et tirer des conclusions en fonction des données fournies par MTR.
  80. ### La perte de paquets
  81. 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.
  82. Voici un exemple :
  83. ~~~
  84. Start: Sat Apr 1 19:52:13 2017
  85. HOST: foo.example.com Loss% Snt Last Avg Best Wrst StDev
  86. 1.|-- routeur1.example.net 0.0% 10 0.8 0.8 0.7 1.0 0.0
  87. 2.|-- routeur2.example.net 0.0% 10 25.2 26.2 24.7 28.2 1.1
  88. 3.|-- routeur3.example.net 0.0% 10 25.6 26.5 25.6 27.4 0.0
  89. 4.|-- routeur4.example.net 70.0% 10 38.2 39.3 36.8 42.6 2.0
  90. 5.|-- routeur5.example.net 0.0% 10 36.3 36.4 35.9 37.3 0.0
  91. 6.|-- routeur6.example.net 0.0% 10 38.8 42.0 37.4 77.9 12.6
  92. 7.|-- routeur7.example.net 0.0% 10 36.7 36.8 36.2 38.7 0.7
  93. 8.|-- routeur8.example.net 0.0% 10 36.1 36.6 35.4 38.1 1.2
  94. 9.|-- routeur9.example.net 0.0% 10 36.1 36.1 36.0 36.1 0.0
  95. 10.|-- routeur10.example.net 0.0% 10 37.2 35.9 35.2 37.2 0.5
  96. ~~~
  97. On peut voir ici que la perte ne concerne que le quatrième saut et nous avons bien 0% de perte à la destination. On est bien ici dans un cas de rate limiting ICMP.
  98. Voici un exemple de perte à considérer :
  99. ~~~
  100. Start: Sat Apr 1 19:52:13 2017
  101. HOST: foo.example.com Loss% Snt Last Avg Best Wrst StDev
  102. 1.|-- routeur1.example.net 0.0% 10 0.8 0.8 0.7 1.0 0.0
  103. 2.|-- routeur2.example.net 0.0% 10 25.2 26.2 24.7 28.2 1.1
  104. 3.|-- routeur3.example.net 0.0% 10 25.6 26.5 25.6 27.4 0.0
  105. 4.|-- routeur4.example.net 0.0% 10 38.2 39.3 36.8 42.6 2.0
  106. 5.|-- routeur5.example.net 0.0% 10 36.3 36.4 35.9 37.3 0.0
  107. 6.|-- routeur6.example.net 40.0% 10 38.8 42.0 37.4 77.9 12.6
  108. 7.|-- routeur7.example.net 40.0% 10 36.7 36.8 36.2 38.7 0.7
  109. 8.|-- routeur8.example.net 40.0% 10 36.1 36.6 35.4 38.1 1.2
  110. 9.|-- routeur9.example.net 40.0% 10 36.1 36.1 36.0 36.1 0.0
  111. 10.|-- routeur10.example.net 40.0% 10 37.2 35.9 35.2 37.2 0.5
  112. ~~~
  113. Si la perte rapportée se poursuit jusqu'à la destination alors la perte est probablement réelle.
  114. On peut aussi observer des cas où rate limiting et perte réelle sont présents :
  115. ~~~
  116. Start: Sat Apr 1 19:52:13 2017
  117. HOST: foo.example.com Loss% Snt Last Avg Best Wrst StDev
  118. 1.|-- routeur1.example.net 0.0% 10 0.8 0.8 0.7 1.0 0.0
  119. 2.|-- routeur2.example.net 0.0% 10 25.2 26.2 24.7 28.2 1.1
  120. 3.|-- routeur3.example.net 0.0% 10 25.6 26.5 25.6 27.4 0.0
  121. 4.|-- routeur4.example.net 0.0% 10 38.2 39.3 36.8 42.6 2.0
  122. 5.|-- routeur5.example.net 70.0% 10 36.3 36.4 35.9 37.3 0.0
  123. 6.|-- routeur6.example.net 40.0% 10 38.8 42.0 37.4 77.9 12.6
  124. 7.|-- routeur7.example.net 40.0% 10 36.7 36.8 36.2 38.7 0.7
  125. 8.|-- routeur8.example.net 40.0% 10 36.1 36.6 35.4 38.1 1.2
  126. 9.|-- routeur9.example.net 40.0% 10 36.1 36.1 36.0 36.1 0.0
  127. 10.|-- routeur10.example.net 40.0% 10 37.2 35.9 35.2 37.2 0.5
  128. ~~~
  129. 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.
  130. 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 conseillé de lancer un MTR dans les deux sens.
  131. ### La latence réseau
  132. Outre la perte de paquets, MTR permet la mise en évidence de la latence. Elle est bien sûr liée avant tout à des contraintes physiques et augmente avec le nombre de sauts. Cette augmentation doit idéalement être constante. La nature de la connexion affectera la latence que vous observez, les connexions ADSL auront une latence beaucoup plus élevée que les connexions par fibre par exemple.
  133. ## FAQ
  134. **J'ai 100% de perte sur un saut mais 0% à la destination.**
  135. Tout va bien, cela signifie simplement qu'un équipement sur le trajet refuse l'ICMP.
  136. **J'ai plus au moins de perte sur un saut mais 0% à la destination.**
  137. Un équipement sur le chemin doit certainement faire du rate limiting ICMP, ce qui explique ces pertes. Ici encore pas d'inquietude.
  138. **J'observe des ??? sur un saut.**
  139. Il s'agit de time out. Cela ne signifie pas qu'il y a perte de paquet mais que l'équipement drop le trafic ICMP. Tout va bien.
  140. **J'ai 100% de perte à la destination.**
  141. Soit l'hôte de destination est injoignable, soit celui-ci reçoit les paquets mais n'est pas en mesure d'y répondre ce qui probablement alarmant (défaut de configuration).
  142. ## Liens
  143. * [A Practical Guide to (Correctly) Troubleshooting with Traceroute Troubleshooting with Traceroute](https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf)