Commande traceroute

La commande traceroute est destinée à être utilisée pour les tests, les mesures et la gestion du réseau.

Bien que la commande ping confirme l'accessibilité du réseau IP, vous ne pouvez pas identifier et améliorer certains problèmes isolés. Tenez compte de la situation suivante :

Lorsqu'il y a de nombreux tronçons (par exemple, des passerelles ou des routes) entre votre système et la destination, et qu'il semble y avoir un problème quelque part sur le chemin. Le système de destination peut avoir un problème, mais vous devez savoir où un paquet est réellement perdu.
La commande ping se bloque et ne vous indique pas les raisons d'un paquet perdu.

La commande traceroute peut vous indiquer l'emplacement du paquet et la raison pour laquelle la route est perdue. Si vos paquets doivent passer par des routeurs et des liens, qui appartiennent et sont gérés par d'autres organisations ou sociétés, il est difficile de vérifier les routeurs connexes via la commande telnet. La commande traceroute fournit un rôle supplémentaire à la commande ping.

Remarque: La commande traceroute doit être utilisée principalement pour l'isolement manuel des erreurs. En raison de la charge qu'elle impose sur le réseau, n'utilisez pas la commande traceroute lors d'opérations standard ou de scripts automatisés.

Exemples de réussite de la commande traceroute

La commande traceroute utilise des paquets UDP et la fonction de génération de rapports d'erreur ICMP. Elle envoie un paquet UDP trois fois à chaque passerelle ou routeur sur le chemin. Elle commence par la passerelle la plus proche et étend la recherche d'un tronçon. Enfin, la recherche atteint le système de destination. Dans la sortie, vous voyez le nom de la passerelle, l'adresse IP de la passerelle et trois temps d'aller-retour pour la passerelle. Prenons cet exemple :

# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  5 ms  3 ms  2 ms
 2  aix1 (10.53.153.120)  5 ms  5 ms  5 ms

Autre exemple :

# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  10 ms  2 ms  3 ms
 2  aix1 (10.53.153.120)  8 ms  7 ms  5 ms

Après l'expiration de l'entrée du protocole de résolution d'adresse (ARP), la même commande a été répétée. Notez que le premier paquet vers chaque passerelle ou destination a pris un temps d'aller-retour plus long. Cela est dû à la surcharge causée par le protocole ARP. Si un réseau public commuté (WAN) est impliqué dans la route, le premier paquet consomme beaucoup de mémoire en raison de l'établissement de la connexion et peut provoquer un dépassement du délai d'attente. Le délai d'attente par défaut pour chaque paquet est de 3 secondes. Vous pouvez le modifier à l'aide de l'option -w.

Les 10 premières ms sont dues au protocole ARP entre le système source (9.53.155.187) et la passerelle 9.111.154.1. La deuxième 8 ms est due au protocole ARP entre la passerelle et la destination finale (vague). Dans ce cas, vous utilisez DNS, et chaque fois que la commande traceroute envoie un paquet, le serveur DNS est recherché.

Exemples d'échec de la commande traceroute

Pour un chemin long vers votre destination ou des routes réseau complexes, vous pouvez rencontrer de nombreux problèmes avec la commande traceroute. Etant donné que de nombreux éléments dépendent de l'implémentation, la recherche du problème ne peut que vous faire perdre du temps. Si tous les routeurs ou systèmes concernés sont sous votre contrôle, vous pouvez peut-être examiner le problème dans son intégralité.

Problème de passerelle (routeur)

Dans l'exemple suivant, les paquets ont été envoyés à partir du système 9.53.155.187. Il y a deux systèmes de routeur sur le chemin du pont. La fonction de routage a été volontairement supprimée du second système de routeur en définissant l'option ipforwarding de la commande no sur 0. Prenons cet exemple :

# traceroute lamar
trying to get source for lamar
source should be 9.53.155.187
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  9.111.154.1 (9.111.154.1)  12 ms  3 ms  2 ms
 2  9.111.154.1 (9.111.154.1)  3 ms !H *  6 ms !H

Si un message d'erreur ICMP, exclusionTime ExceededetPort Unreachable, est reçu, il s'affiche comme suit:

!H: Hôte inaccessible
!N: Réseau inaccessible
!P: Protocole inaccessible
!S: Echec de la route source
!F: Fragmentation nécessaire

Problème du système de destination

Lorsque le système de destination ne répond pas dans un délai de 3 secondes, toutes les requêtes expirent et les résultats sont affichés avec un astérisque (*).

# traceroute chuys
trying to get source for chuys
source should be 9.53.155.187
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  * * *
 2  * * *
 3  * * *
^C#

Si vous pensez que le problème est dû à une liaison de communication, utilisez un délai d'expiration plus long avec l'indicateur -w. Bien que cela soit rare, tous les ports interrogés peuvent avoir été utilisés. Vous pouvez changer les ports et réessayer.

Nombre de "tronçons" vers la destination

Un autre exemple de sortie peut être le suivant :

# traceroute mysystem.university.edu (129.2.130.22)
traceroute to mysystem.university.edu (129.2.130.22), 30 hops max
1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms
6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!