Dépannage avec les procédures MTR (Windows)

Niveau d’expertise : Moyen

Le soutien technique iWeb peut vous demander de remplir un rapport MyTraceRoute (MTR) étant donné que les coupe-feu peuvent compromettre les résultats. La procédure est simple. Effectuez les étapes suivantes : 

Générer un rapport MTR avec Windows 

  1. Téléchargez un programme winMTR comme celui-ci : http://sourceforge.net/projects/winmtr/
  2. Une fois que l’installation est terminée, lancez l’application. Il n’est pas nécessaire de l’installer : lancer le fichier exécutable est suffisant. 
  3. Dans la section « Host », entrez l’information relative au serveur distant (nom de domaine ou adresse IP).
  4. Cliquez sur « Start ».
  5. Attendez que le programme vérifie tous les tronçons. Rien n’indiquera que le programme a terminé, mais il fonctionnera en continu pour rendre les données plus précises. Il a vérifié tous les « tronçons » s’il n’y en a pas d’autres qui sont générés.
  6. Cliquez sur « Export Text ».
  7. Enregistrez les résultats sous forme de fichier texte.

Fournir votre adresse IP à iWeb

Pour interpréter les résultats, iWeb a besoin de votre adresse IP publique. Souvent, les clients utilisent leur IP locale à leurs postes de travail. Si c’est votre cas, vous avez besoin d’un outil pour déterminer votre adresse IP publique. L’outil suivant est fiable et facile à utiliser : http://www.whatismyip.com/

Interpréter les résultats du MTR 

Les résultats du rapport MTR permettent de diagnostiquer les problèmes. Selon ce qu’a révélé l’analyse, ils peuvent comprendre les éléments suivants :

  • Essai de tronçon de réseau 
  • Nombre de tronçons et longueur des tronçons
  • Pourcentage de paquets perdus (moyenne de paquets en pourcentage)
  • Nombre de paquets envoyés (total envoyé)
  • Nombre de paquets reçus
  • Temps de réponse de tronçon le plus rapide 
  • Temps moyen de réponse de tronçon
  • Temps de réponse de tronçon le plus lent
  • Temps de réponse du tronçon final

L’information la plus importante utilisée pour diagnostiquer et résoudre les problèmes de connectivité est le pourcentage de paquets perdus

À titre d’exemple, voici deux illustrations de rapport MTR : la première présente un cas extrême de perte de paquets (en gras).

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                              70.38.99.3 -    4 |  771 |  747 |    0 |    0 |  122 |    3 |
|                  te8-3.cr2.mtl.iweb.com -    4 |  762 |  736 |    0 |    2 |  198 |    3 |
|                   po21.cr1.mtl.iweb.com -    5 |  740 |  709 |    0 |    1 |  170 |    0 |
|               xe-0-0-0.er1.tor.iweb.com -    5 |  721 |  687 |    0 |    8 |   81 |    7 |
|    gw-google.torontointernetxchange.net -    3 |  802 |  785 |    0 |    9 |   83 |    7 |
|                          216.239.47.114 -    2 |  811 |  796 |    8 |    8 |   38 |    9 |
|                          216.239.46.160 -   20 |  464 |  373 |    0 |   23 |   43 |   27 |
|                          209.85.248.214 -   63 |  229 |   85 |    0 |   35 |   50 |   36 |
|                          216.239.43.219 -   17 |  506 |  423 |    0 |   35 |   80 |   36 |
|                   No response from host -  100 |  159 |    0 |    0 |    0 |    0 |    0 |
|          google-public-dns-a.google.com -   91 |  173 |   17 |    0 |   34 |   36 |   34 |
|________________________________________________|______|______|______|______|______|______|
 
---------------------------------------------------------------------------------------------------------------------------------------------------------
Hop    Hostname (IP)                     Loss    Sent    Rcvd     Min (ms)    Avg (ms)    Max (ms)
1    69.42.85.82                    0 %    5    5    0.341        4.312        17.362
2    csd180.gsc.webair.net(173.239.0.53)        0 %    5    5    0.506        0.705        1.206
3    csc180.gsc.webair.net(173.239.32.1)        0 %    5    5    0.415        0.728        1.047
4    es0.nyc2.webair.net(173.239.0.25)        0 %    5    5    0.887        1.123        1.468
5    208.178.245.149                    0 %    5    5    0.881        16.704        22.378
6    ae7-70G.scr4.NYC1.gblx.net(67.16.142.53)    0 %    5    5    0.855        4.814        19.778
7    po4-40G.ar5.NYC1.gblx.net(67.17.105.238)    0 %    5    5    1.003        1.487        2.956
8    64.215.195.214                    0 %    5    5    0.835        1.184        1.641
9    vlan60.csw1.NewYork1.Level3.net(4.69.155.62)    0 %    5    5    8.233        8.324        8.504
10    ae-62-62.ebr2.NewYork1.Level3.net(4.69.148.33)    0 %    5    5    8.356        8.618        8.927
11    ae-5-5.car1.Montreal2.Level3.net(4.69.141.5)    0 %    5    5    8.355        10.300        13.459
12    te6-2.cl-core05.level3.mtl.iweb.com(4.59.176.10)20 %    4    5    8.894        13.456        22.702
13    te8-3.dr10.mtl.iweb.com(67.205.127.238)        0 %    5    5    9.152        14.627        25.000
---------------------------------------------------------------------------------------------------------------------------------------------------------
La seconde illustration ne montre aucun paquet perdu entre le deuxième et le dernier tronçon (en gras). Si vous obtenez de tels résultats, il est important de noter le fait suivant : afin d’isoler et de réduire au minimum les vérifications ping, les analyses de route empruntée et le nombre de tronçons dans le MTR, iWeb contrôle l’afflux de protocoles ICMP sur ses propres routeurs. Cela nous aide à établir des diagnostics en concentrant les résultats du rapport MTR sur le dernier tronçon. De tels cas et de tels résultats prouvent qu’il n’y a pas de problème de connectivité. 
Vous avez d’autres questions ? Envoyer une demande

0 Commentaires

Cet article n'accepte pas de commentaires.
Réalisé par Zendesk