Article

Effectuer un test My Trace Route (MTR)

4–6 minutes

🎯Ce guide a pour objectif de vous accompagner dans la rĂ©alisation d’un test MTR (My Trace Route). Celui-ci peut vous ĂȘtre demandĂ© par les Ă©quipes support CEC‑XPR lors de l’ouverture d’une demande d’assistance, notamment en cas de comportements inhabituels ou inattendus affectant vos services rĂ©seau.

 Quelques notions de rĂ©seau đŸŒ  #

  • Un nƓud : Ă©quipement qui traite et achemine des paquets (Routeur, switch, firewall, Ă©quipement opĂ©rateur…). 
  • Un tronçon : liaison entre deux nƓuds (fibre, cuivre, radio…). 

Pour joindre une ressource cible depuis une machine source, les requĂȘtes peuvent ĂȘtre adressĂ©es en direct au serveur si ce dernier se trouve dans le mĂȘme rĂ©seau que la machine (site gĂ©ographique, directement connectĂ©).

Figure 1 – AccĂšs Ă  un serveur

Pour accĂ©der Ă  une ressource distante, les requĂȘtes traversent plusieurs pĂ©rimĂštres avant d’arriver sur le serveur cible : le rĂ©seau Free Pro, puis Internet si la ressource est hĂ©bergĂ©e en dehors de notre infrastructure. 

Figure 2 – DiffĂ©rents acteurs dans la chaĂźne

Physiquement, les requĂȘtes empruntent des artĂšres rĂ©seaux entre diffĂ©rents nƓuds de communication.  

Figure 3 – Une multitude d’Ă©quipements traversĂ©s

Ainsi, utilisez ce guide si vous observez l’un des comportements suivants : 

  • lenteurs inhabituelles lors de l’accĂšs Ă  vos services 
  • coupures ou interruptions ponctuelles 
  • pertes de paquets lors de vos Ă©changes rĂ©seau 
  • variations anormales de stabilitĂ© ou de rĂ©activitĂ© 
  • difficultĂ©s d’accĂšs Ă  un service habituellement disponible 

My trace route – MTR #

L’outil MTR combine les outils traceroute et ping. Ce fonctionnement lui permet de cartographier le cheminement rĂ©seau, et de mesurer la latence, depuis une machine source, au travers chaque maillon de la chaine, jusqu’à sa destination.  

Ce test constitue un Ă©lĂ©ment essentiel pour nos Ă©quipes, car il fournit une vision prĂ©cise et objective du chemin empruntĂ© par vos donnĂ©es sur Internet. GrĂące Ă  lui, nous pouvons : 

  • Localiser avec exactitude l’endroit oĂč le comportement anormal apparaĂźt, que ce soit sur votre rĂ©seau local, sur un Ă©quipement intermĂ©diaire ou sur un segment opĂ©rateur ; 
  • Distinguer un problĂšme local d’un problĂšme externe, ce qui Ă©vite des investigations inutiles et accĂ©lĂšre la prise en charge ; 
  • Identifier la nature du dysfonctionnement (latence, pertes, instabilitĂ©) en observant son Ă©volution Ă  chaque Ă©tape du parcours rĂ©seau ; 
  • Fournir aux Ă©quipes d’ingĂ©nierie ou aux opĂ©rateurs tiers des preuves techniques fiables, indispensables pour engager des actions correctives ; 
  • RĂ©duire considĂ©rablement le temps de rĂ©solution, en orientant immĂ©diatement l’analyse vers le bon maillon de la chaĂźne. 

En rĂ©sumĂ©, le MTR nous permet d’obtenir une photographie complĂšte et dĂ©taillĂ©e du trajet rĂ©seau entre votre poste et notre infrastructure. Sans ces informations, l’analyse serait partielle, et l’ouverture d’une demande d’assistance manquera

Installer l’outil MTR đŸ’œ  #

Sous Windows 

L’outil avec une interface graphique est disponible sur https://sourceforge.net/projects/winmtr/ 

Sous Linux/macOS 

L’outil est disponible dans les dĂ©pĂŽts classiques « homebrew » (macOS), « apt Â» (Linux) (peut nĂ©cessiter les droits sudo) 

Lire et interprĂ©ter les rĂ©sultats đŸ”Ž  #

Nous y sommes. Vous disposez dĂ©sormais d’un poste Ă©quipĂ© de l’outil : vous pouvez Ă  prĂ©sent lancer votre test.  

Windows : WinMTR 

Dans le champ â€œHost”, tapez l’Url de votre cible ou son IP. Les rĂ©sultats se prĂ©senteront sous la forme suivante : 

Environement Unix / Linux 

Depuis votre console, ligne de commande (droits sudo peuvent ĂȘtre nĂ©cessaire)  : 

mtr [ip] ou [url]

Devrait apparaitre alors : 

*St-dev : Ă©cart type de la distribution.

💡Plus un Ă©chantillon est important, plus il est significatif. Dans le cadre d’un test MTR, un Ă©chantillon de 1000 paquets est pertinant. 

Reprenons notre exemple : 

Sur les 2 077 paquets envoyĂ©s, aucune perte n’est Ă  dĂ©plorer Ă  destination. Visible au 0 % de perte rĂ©elle (Ligne 8, colonne “Loss%”) sur le trajet complet qui s’effectue en huit sauts, avec une latence moyenne de 4,4 ms.  

Les valeurs surlignĂ©es correspondent Ă  des comportements qui peuvent sembler anormaux au premier regard. Par exemple, la colonne “Loss%” indique ici 2,8 % de pertes au saut n°2. Factuellement, cela signifie que ce routeur ne rĂ©pond pas Ă  environ 3 requĂȘtes ICMP (ping, traceroute, MTR) sur 100. 

Pour autant, comme dit prĂ©cĂ©demment, la destination finale ne prĂ©sente aucune perte, ce qui montre que le trafic transite correctement.

L’explication est simple : les Ă©quipements rĂ©seau ne sont pas tenus de rĂ©pondre aux tests ICMP. Leur prioritĂ© est d’acheminer le trafic rĂ©el. RĂ©pondre Ă  chaque sollicitation de diagnostic consomme des ressources processeur ; pour prĂ©server leur capacitĂ© de traitement, ils peuvent limiter, dĂ©prioriser ou ignorer ces requĂȘtes. 

Ainsi, une perte affichĂ©e sur un saut intermĂ©diaire n’indique pas forcĂ©ment un dĂ©faut : elle peut simplement reflĂ©ter la maniĂšre dont l’équipement gĂšre les requĂȘtes ICMP, sans impact sur le trafic utilisateur. 

Prenons une nouvelle trace, nouvelle destination, dans un exemple qui se veut volontairement problĂ©matique. 

Ici, on constate, Ă  la lecture de la derniĂšre ligne, que 30 % des paquets sont perdus vers la destination (saut #7). 

Pour identifier l’origine du dĂ©faut, on remonte la chaĂźne du bas vers le haut, en observant Ă  quel moment la perte apparaĂźt pour la premiĂšre fois.

Dans cet exemple, la perte est visible : 

au saut #7 (30 %) 

au saut #6 (50 %) 

au saut #5 (23 %) 

La perte est donc prĂ©sente sur plusieurs nƓuds consĂ©cutifs : on parle alors de perte propagĂ©e. Cela signifie qu’un dĂ©faut situĂ© Ă  un point donnĂ© du parcours impacte nĂ©cessairement tous les sauts suivants. 

La premiĂšre apparition de la perte se situe au saut #5. C’est donc Ă  partir de ce point que l’analyse doit se concentrer. 

ConcrĂštement, il convient d’examiner : 

le nƓud #5 (l’équipement lui‑mĂȘme) 

le nƓud #6, qui est le suivant dans la chaĂźne 

le tronçon 5 ↔ 6, c’est‑à‑dire la liaison entre ces deux Ă©quipements 

le tronçon 6 ↔ 7, puisque la perte continue jusqu’à la destination 

Ceci conclut notre guide. Le centre d’expertise client, solutions XPR reste Ă  votre disposition.

Qu'avez vous pensé de cet article ?
Free Pro est la filiale entreprise du Groupe iliad et met l’expertise technologique du Groupe iliad au service des entreprises et des marchĂ©s publics

GrĂące Ă  des infrastructures souveraines et certifiĂ©es, Free Pro propose des solutions Cloud, IT, tĂ©lĂ©com et cybersĂ©curitĂ© – appelĂ©es Solutions XPR – pour rĂ©pondre de façon simple aux enjeux des environnements les plus exigeants.

FidĂšle Ă  l’ADN du Groupe iliad, Free Pro place l’humain au cƓur de sa dĂ©marche, en garantissant un service de proximitĂ© partout en France et un partenariat de confiance avec chacun de ses clients. Une expertise reposant sur plus de 20 ans d’expĂ©rience, qui lui permet d’accompagner de grandes rĂ©fĂ©rences telles que le Groupe Printemps, Lidl, Monin, le ministĂšre de l’IntĂ©rieur ou encore Gaumont.

Table des matiĂšres