Utiliser la commande Traceroute sur les systèmes d’exploitation

Introduction

Ce document décrit comment la commande traceroute fonctionne sur différents systèmes.

Conditions préalables

Exigences

Les lecteurs de ce document doivent avoir des connaissances de base de l’un de ces systèmes d’exploitation :

• Logiciel Cisco IOSMD

• Linux

• Microsoft Windows

Composants utilisés

L’information contenue dans le présent document repose sur les versions logicielles et matérielles suivantes :

• Routeur Cisco utilisant le logiciel Cisco IOS, version 12

• Ordinateur qui exécute Red Hat Linux

• Ordinateur exécutant MS Windows 

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

La traceroute commande vous permet de déterminer le chemin emprunté par un paquet pour atteindre une destination à partir d'une source donnée en retournant la séquence de sauts que le paquet a traversé. Cet utilitaire est fourni avec votre système d’exploitation hôte (par exemple, Linux ou Microsoft [MSWindows]), ainsi qu’avec Cisco IOS

Fonctionnement général

Si vous exécutez la traceroute ip-address commande sur un périphérique source (tel qu'un hôte ou un routeur agissant en tant qu'hôte), il envoie des paquets IP vers la destination avec des valeurs de durée de vie (TTL) qui s'incrémentent jusqu'au nombre maximal de sauts spécifié. La valeur par défaut est 30. En règle générale, chaque routeur sur le chemin vers la destination réduit le champ TTL d’une unité pendant qu’il transfère ces paquets. Lorsqu’un routeur au milieu du chemin trouve un paquet avec TTL = 1, il répond par un message ICMP (Internet Control Message Protocol) de « délai dépassé » à la source. Ce message informe la source que le paquet traverse ce routeur particulier en tant que saut

Il y a quelques différences avec la façon dont la commande est mise en oeuvre dans les différents systèmes d'exploitation que ce document aborde traceroute .

Cisco IOS et Linux

La durée de vie de la sonde de datagramme UDP (User Datagram Protocol) initiale est définie sur 1 (ou la durée de vie minimale, comme spécifié par l'utilisateur dans la traceroute commande étendue). Le port UDP de destination de la sonde de datagramme initiale est défini sur 33434 (ou comme spécifié dans le résultat de la traceroute commande étendue). La commande étendue traceroute est une variante de la commande ordinaire traceroute qui permet de modifier les valeurs par défaut des paramètres utilisés par l' traceroute opération, tels que la durée de vie et le numéro de port de destination. Pour plus d'informations sur l'utilisation de la traceroute commande étendue, reportez-vous à Comprendre les commandes ping étendue et traceroute étendue. Le port UDP source de la sonde de datagramme initiale est aléatoire et comporte un opérateur logique OU avec 0x8000 (assure un port source minimal de 0x8000). Ces étapes illustrent ce qui se passe lorsque le datagramme UDP est lancé :

1. Le datagramme UDP est distribué avec TTL = 1, port UDP de destination = 33434 et le port source est aléatoire.

2. Le port de destination UDP est augmenté, le port UDP source est réparti de manière aléatoire et le deuxième datagramme est envoyé.

3. L’étape 2 est répétée pour un maximum de trois sondes (ou autant de fois que nécessaire dans une sortie de traceroute commande étendue). Pour chacune des sondes envoyées, le message « TTL exceeded » (TTL dépassé) s’affiche, il est utilisé pour créer un chemin par étape vers l’hôte de destination.

4. La TTL est augmentée et ce cycle se répète avec les numéros de port de destination supplémentaires, si le message de dépassement de temps ICMP est reçu. L’un de ces messages peut également s’afficher :

   • Message ICMP de type 3, code 3 (destination, port inaccessible), qui indique qu’un hôte a été atteint.

   • Un hôte inaccessible, net inaccessible, une TTL maximale dépassée ou un message de type délai d’expiration qui signifie que la sonde est renvoyée.

Les routeurs Cisco envoient des paquets de sonde UDP avec un port source aléatoire et un port de destination supplémentaire (pour distinguer les différentes sondes). Les routeurs Cisco renvoient le dépassement de l’heure du message ICMP à la source à partir de laquelle le paquet UDP/ICMP a été reçu.

La commande Linux traceroute est similaire à l'implémentation du routeur Cisco. Cependant, il utilise un port source fixe. L'option -n de la traceroute commande est utilisée pour éviter une requête à un serveur de noms.

Microsoft Windows

Latracertcommande MS Windows utilise des datagrammes de requête d’écho ICMP au lieu de datagrammes UDP comme sondes. Les requêtes d’écho ICMP sont lancées avec une TTL supplémentaire et la même opération que celle décrite dans Cisco IOS et Linux se produit. L’importance de l’utilisation de datagrammes de demande d’écho ICMP est que le saut final ne dépend pas de la réponse d’un message MICMAC d’inaccessibilité de l’hôte de destination. Il repose plutôt sur un message de réponse d’écho ICMP.

La syntaxe de commande est la suivante :

tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name

Ce tableau explique les paramètres de commande :

Paramètre	Description
-d	Indique qu’il ne faut pas résoudre les adresses en noms d’ordinateurs.
-h maximum_hops	Indique le nombre maximal de sauts à effectuer pour rechercher une cible.
-j computer-list	Indique une route source libre le long de la liste des ordinateurs.
-w timeout	Attend la durée en millisecondes précisée par le délai d’expiration pour chaque réponse.
target_name	Nom de l’ordinateur cible.

Limite du taux d’inaccessibilités ICMP

Les éléments ICMP inaccessibles sont limités à un paquet toutes les 500 ms (comme protection contre les attaques par déni de service [DoS]) dans un routeur Cisco. À partir du logiciel Cisco IOS versions 12.1 et ultérieures, cette valeur de débit est configurable. La commande introduite est la suivante :

Router(config)#ip icmp rate-limit unreachable ?
  <1-4294967295>  Once per milliseconds
  DF              code 4, fragmentation needed and DF set

Cette limite concerne le taux agrégé de tous les ICMP inaccessibles, comme le montre cette sortie. Référez-vous à RFC 792 pour plus d'informations.

type = 3, code 
0 = net unreachable; 
1 = host unreachable; 
2 = protocol unreachable; 
3 = port unreachable; 
4 = fragmentation needed and DF set; 
5 = source route failed.

Cette limite ne touche pas les autres paquets comme les demandes d’écho ICMP ou les messages de dépassement de temps ICMP.

Exemples

Cette topologie de réseau est utilisée pour les exemples :

Topologie du réseau

Dans chacun des trois exemples, un appareil A différent est utilisé. À partir du périphérique A, la commande est exécutée sur traceroute 10.1.4.2 le périphérique 7C.

Dans chacun des exemples, la commande s'exécute debug ip packet detail sur le périphérique 11A.

Routeur Cisco avec le logiciel Cisco IOS

Cet exemple de traceroute commande étendue montre les options que vous pouvez modifier lorsque vous exécutez une traceroute commande à partir d'un routeur Cisco. Dans cet exemple, tout est conservé par défaut :

rp-10c-2611#traceroute
Protocol [ip]: 
Target IP address: 10.1.4.2 
Source address: 10.1.1.1 
Numeric display [n]: 
Timeout in seconds [3]: 
Probe count [3]: 
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 10.1.4.2

1 10.1.1.2 4 msec 0 msec 4 msec
2 10.1.2.2 4 msec 4 msec 0 msec
3 10.1.3.2 0 msec 0 msec 4 msec
4 10.1.4.2 4 msec * 0 msec 


rp-11a-7204#
*Dec 29 13:13:57.060: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.060: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.064: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.068: ICMP type=11, code=0

Dans cette sortie de débogage, l’appareil 11A envoie des messages de dépassement d’heure ICMP à la source des sondes (10.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales qui avaient un TTL=1. Le périphérique 11A décrémente le TTL à zéro et répond avec les messages de dépassement de délai.

• L’appareil 11A n’est pas la destination des sondes UDP.

• La TTL est réduite à zéro et le paquet n’est jamais acheminé. Par conséquent, le débogage ne reconnaît jamais le paquet.

  *Dec 29 13:13:57.068: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
   g=10.1.2.2, len 28, forward
  *Dec 29 13:13:57.068: UDP src=40309, dst=33437
  *Dec 29 13:13:57.068: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
   g=10.1.1.1, len 56, forward
  *Dec 29 13:13:57.068: ICMP type=11, code=0
  *Dec 29 13:13:57.072: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
   g=10.1.2.2, len 28, forward
  *Dec 29 13:13:57.072: UDP src=37277, dst=33438
  *Dec 29 13:13:57.072: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
   g=10.1.1.1, len 56, forward
  *Dec 29 13:13:57.072: ICMP type=11, code=0
  *Dec 29 13:13:57.076: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
   g=10.1.2.2, len 28, forward
  *Dec 29 13:13:57.076: UDP src=36884, dst=33439
  *Dec 29 13:13:57.076: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
   g=10.1.1.1, len 56, forward
  *Dec 29 13:13:57.076: ICMP type=11, code=0

Cette sortie de débogage montre la sonde UDP de la source 10.1.1.1 destinée à 10.1.4.2.

*Dec 29 13:13:57.080: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.080: UDP src=37479, dst=33440
*Dec 29 13:13:57.080: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.080: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.084: UDP src=40631, dst=33441
*Dec 29 13:13:57.084: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.084: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39881, dst=33442
*Dec 29 13:13:57.088: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.088: ICMP type=11, code=0

Vous voyez les trois sondes UDP suivantes dans cette sortie de débogage. La durée de vie de ces sondes est de 3. Le dispositif 11A décrémente la durée de vie à 2 et les transmet au dispositif 7A. L’appareil 7A réduit la TTL à 1 et transfère les paquets à l’appareil 7B, qui réduit la TTL à zéro et répond par des messages de dépassement de temps ICMP.

*Dec 29 13:13:57.088: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39217, dst=33443
*Dec 29 13:13:57.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.092: ICMP type=3, code=3
*Dec 29 13:13:57.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.096: UDP src=34357, dst=33444
*Dec 29 13:14:00.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:14:00.092: UDP src=39587, dst=33445
*Dec 29 13:14:00.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:14:00.092: ICMP type=3, code=3

Vous pouvez voir les trois dernières sondes UDP dans cette sortie de débogage. Le TTL original de ces sondes était de 4. Le TTL a été décrémenté à 3 par le dispositif 11A, puis décrémenté à 2 par le dispositif 7A, puis décrémenté à 1 par le dispositif 7B. L’appareil 7C répond par des messages de port ICMP inaccessible, car il s’agit de la destination des sondes.

Ordinateur exécutant Linux

[root#linux-pc]#traceroute -n 10.1.4.2
traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets
1. 10.1.1.2 1.140 ms 0.793 ms 0.778 ms
2. 10.1.2.2 2.213 ms 2.105 ms 3.491 ms
1. 10.1.3.2 3.146 ms 2.314 ms 2.347 ms
1. 10.1.4.2 3.579 ms * 2.954 ms 


rp-11a-7204#
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0

Dans cette sortie de débogage, l’appareil 11A envoie des messages de dépassement d’heure ICMP à la source des sondes (10.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales qui avaient un TTL=1. Le périphérique 11A décrémente le TTL à zéro et répond avec les messages de dépassement de délai.

Vous ne voyez pas les sondes UDP dans cette sortie de débogage pour deux raisons :

1. L’appareil 11A n’est pas la destination des sondes UDP.

2. La TTL est réduite à zéro et le paquet n’est jamais acheminé. Par conséquent, le débogage ne reconnaît jamais le paquet.

*Jan 2 07:17:27.894: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.894: UDP src=33302, dst=33438
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33439
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33440
*Jan 2 07:17:27.902: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.902: ICMP type=11, code=0

*Jan 2 07:17:27.902: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.902: UDP src=33302, dst=33441
*Jan 2 07:17:27.906: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.906: ICMP type=11, code=0
*Jan 2 07:17:27.906: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.906: UDP src=33302, dst=33442
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33443
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0

Les trois sondes UDP suivantes sont maintenant vues dans cette sortie de débogage. La durée de vie de ces sondes est de 3. Le dispositif 11A décrémente la durée de vie à 2 et les transmet au dispositif 7A. L’appareil 7A réduit la TTL à 1 et transfère les paquets à l’appareil 7B, qui réduit la TTL à zéro et répond par des messages de dépassement de temps ICMP.

*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33444
*Jan 2 07:17:27.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.914: ICMP type=3, code=3
*Jan 2 07:17:27.914: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.914: UDP src=33302, dst=33445
*Jan 2 07:17:32.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:32.910: UDP src=33302, dst=33446
*Jan 2 07:17:32.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:32.914: ICMP type=3, code=3

Cette sortie de débogage montre les trois dernières sondes UDP. Le TTL original de ces sondes était de 4. Le TTL a été décrémenté à 3 par le dispositif 11A, puis décrémenté à 2 par le dispositif 7A, puis décrémenté à 1 par le dispositif 7B.

L’appareil 7C répond ensuite par des messages de port ICMP inaccessible, car il s’agit de la destination des sondes.

Ordinateur exécutant MS Windows

C:\>tracert 10.1.4.2 

1 <10 ms <10 ms <10 ms 10.1.1.2
1 <10 ms <10 ms <10 ms 10.1.2.2
1 <10 ms <10 ms <10 ms 10.1.3.2
1 <10 ms 10 ms 10 ms 10.1.4.2

Trace complete

rp-11a-7204#
*Dec 29 14:02:22.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:22.236: UDP src=137, dst=137
*Dec 29 14:02:22.240: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:22.240: ICMP type=3, code=3
*Dec 29 14:02:23.732: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:23.732: UDP src=137, dst=137
*Dec 29 14:02:23.736: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:23.736: ICMP type=3, code=3
*Dec 29 14:02:25.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:25.236: UDP src=137, dst=137
*Dec 29 14:02:25.236: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:25.240: ICMP type=3, code=3
*Dec 29 14:02:26.748: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.748: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0

Dans cette sortie de débogage, l’appareil 11A envoie des messages de dépassement d’heure ICMP à la source des sondes (10.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales, qui sont des paquets de requête d'écho ICMP avec un TTL=1. Le dispositif 11A décrémente le TTL à zéro et répond avec les messages ICMP.

Vous ne voyez pas les sondes ICMP dans cette sortie de débogage pour deux raisons :

1. L’appareil 11A n’est pas la destination des sondes ICMP.

2. La TTL est réduite à zéro et le paquet n’est jamais acheminé. Par conséquent, le débogage ne reconnaît jamais le paquet.

*Dec 29 14:02:32.256: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.256: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.260: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.260: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.264: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.264: ICMP type=8, code=0
*Dec 29 14:02:32.264: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.264: ICMP type=11, code=0

Dans cette sortie de débogage, vous voyez maintenant la sonde ICMP de la source 10.1.1.1 destinée à 10.1.4.2.

*Dec 29 14:02:37.776: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.776: ICMP type=8, code=0
*Dec 29 14:02:37.776: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.776: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.780: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.780: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.784: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.784: ICMP type=11, code=0

Vous voyez les trois sondes ICMP suivantes dans cette sortie de débogage. La durée de vie de ces sondes est de 3. Le dispositif 11A décrémente la durée de vie à 2 et les transmet au dispositif 7A. L’appareil 7A réduit la TTL à 1 et transfère les paquets à l’appareil 7B, qui réduit la TTL à zéro et répond par des messages de dépassement de temps ICMP.

*Dec 29 14:02:43.292: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.292: ICMP type=8, code=0
*Dec 29 14:02:43.296: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.296: ICMP type=0, code=0
*Dec 29 14:02:43.296: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.296: ICMP type=8, code=0
*Dec 29 14:02:43.300: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.300: ICMP type=0, code=0
*Dec 29 14:02:43.300: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.300: ICMP type=8, code=0
*Dec 29 14:02:43.304: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.304: ICMP type=0, code=0

Cette sortie de débogage montre les trois dernières sondes ICMP. Le TTL original de ces sondes était de 4. Le TTL a été décrémenté à 3 par le dispositif 11A, puis décrémenté à 2 par le dispositif 7A, puis décrémenté à 1 par le dispositif 7B. L’appareil 7C répond ensuite par des messages de réponse d’écho ICMP (type=0, code=0), puisqu’il s’agit de la destination des sondes.

Notes supplémentaires

Dans les routeurs Cisco, les codes de réponse à une traceroute commande sont les suivants :

! -- success
* -- time out
N -- network unreachable
H -- host unreachable
P -- protocol unreachable
A -- admin denied
Q -- source quench received (congestion)
? -- unknown (any other ICMP message)

Si vous exécutez la commande traceroute à partir d'UNIX, notez ces éléments :

• Vous pouvez recevoir des traceroute: icmp socket: Permission denied messages.

• Le programme s'appuie traceroute sur le NIT (Network Interface Tap) pour surveiller le réseau. Ce appareil n’est accessible que par la racine. Vous devez soit exécuter le programme en tant qu’utilisateur racine, soit définir l’identifiant d’utilisateur pour la racine.

Résumé

Ce document a démontré comment la commande détermine le chemin qu'un paquet prend d'une source donnée à une destination donnée avec l'utilisation de paquets UDP et ICMP traceroute . Les types de messages ICMP possibles dans les sorties sont les suivants :

• Si la TTL est dépassée pendant le transit, type=11, code=0, le paquet est renvoyé par le routeur de transit dans tous les cas où la TTL des paquets de sonde expire avant que les paquets n’atteignent la destination.

• Si le port est inaccessible, type=3, code=3, le paquet est renvoyé en réponse aux paquets de sonde UDP lorsqu’ils atteignent la destination (l’application UDP n’est pas définie). Ces paquets sont limités à un paquet toutes les 500 ms. Cela explique pourquoi la réponse de la destination (voir les sorties du routeur Cisco et Linux) a échoué dans les réponses paires. Le périphérique 7C ne génère pas le message ICMP et la sortie de la commande de chaque périphérique attend le message pendant plus traceroute d’une seconde. Dans le cas de la sortie de commande MS Windows tracert , le message ICMP est généré car le port UDP 137 n'existe pas dans un routeur Cisco.

• S’il y a un écho, type=8, code=0, le paquet de sonde d’écho est envoyé par l’ordinateur MS Windows.

• S’il y a une réponse écho, type=0, code=0, une réponse au paquet précédent est envoyée lorsque la destination est atteinte. Ceci s'applique uniquement à la commande MS Windows tracert .

Informations connexes

• Assistance technique de Cisco et téléchargements