Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Opération générale

Cisco IOS et Linux

Microsoft Windows

Limitation du débit d'inaccessibilité ICMP

Exemples

Routeur Cisco avec logiciel Cisco IOS

PC avec Linux

PC avec MS Windows

Remarques supplémentaires

Résumé

Informations connexes

Introduction

La commande « traceroute » vous permet de déterminer le chemin qu'un paquet prend pour obtenir une destination d'une source donnée en retournant l'ordre des sauts traversés par le paquet. Cet utilitaire est livré avec votre système d'exploitation hôte (par exemple Linux ou Microsoft (MS) Windows), aussi bien qu'avec le logiciel Cisco IOS®.

Conditions préalables

Conditions requises

Les lecteurs de ce document doivent avoir une connaissance de base de l'un des systèmes d'exploitation suivants :

- Logiciel Cisco IOS

- Linux

- Microsoft Windows

Components Used

Les informations de ce document s'appliquent aux versions logicielles et matérielles suivantes :

- Routeur Cisco qui exécute le logiciel Cisco IOS Version 12.2(27)

- PC exécutant Red Hat Linux version 9

- PC exécutant MS Windows 2000

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. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Opération générale

Si vous exécutez la commande traceroute ip-address sur un périphérique source (tel qu'un hôte, ou un routeur agissant en tant qu'hôte), elle envoie des paquets IP vers la destination avec des valeurs de durée de vie (TTL) qui augmentent jusqu'au nombre maximal de sauts spécifié. Il s'agit de 30 par défaut. Généralement, chaque routeur sur le chemin vers la destination décrémente le champ TTL par une unité pendant qu’il transfère ces paquets. Lorsqu’un routeur situé au milieu du chemin trouve un paquet avec TTL = 1, il répond par un message ICMP (Internet Control Message Protocol) indiquant que le temps est dépassé à la source. Ce message indique à la source que le paquet traverse ce routeur en tant que saut

Il y a quelques différences dans la façon dont la commande traceroute est implémentée dans les différents systèmes d'exploitation que ce document traite.

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 commande traceroute étendue. Le port UDP de destination de la sonde de datagramme initiale est défini sur 33434 (ou comme spécifié dans la sortie de commande traceroute étendue). La commande traceroute étendue est une variante de la commande traceroute ordinaire qui permet de modifier les valeurs par défaut des paramètres utilisés par l'opération traceroute telles que TTL et le numéro de port de destination. Pour plus d'informations sur l'utilisation de la commande traceroute étendue, reportez-vous à Utilisation des commandes ping et traceroute étendues. Le port UDP source de la sonde de datagramme initiale est aléatoire et possède l'opérateur logique OR avec 0x8000 (garantit un port source minimal de 0x8000). Ces étapes illustrent ce qui se produit lors du lancement du datagramme UDP :

Remarque : Les paramètres sont configurables. Cet exemple commence par n = 1 et se termine par n = 3.

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

2. Le port de destination UDP est incrémenté, le port UDP source est aléatoire et le deuxième datagramme est distribué.

3. L'étape 2 est répétée pour un maximum de trois sondes (ou autant de fois que demandé dans une sortie de commande traceroute étendue). Pour chaque sonde envoyée, vous recevez un message « TTL dépassé », qui est utilisé pour construire un chemin pas à pas vers l'hôte de destination.

4. La durée de vie est incrémentée, et ce cycle se répète avec des numéros de port de destination incrémentiels, si le message ICMP « dépassement de délai » est reçu. Vous pouvez également obtenir l'un de ces messages :

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

- Un message « host unreachable », « net unreachable », « maximum TTL dépassée » ou un type de message « timeout », ce 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 incrémentielle (pour distinguer les différentes sondes). Les routeurs Cisco envoient le message ICMP « time dépassée » à la source à partir de laquelle le paquet UDP/ICMP a été reçu.

La commande traceroute Linux est similaire à la mise en oeuvre du routeur Cisco. Cependant, il utilise un port source fixe. L'option -n de la commande traceroute permet d'éviter une requête à un serveur de noms.

Microsoft Windows

La commande tracert 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 l'incrémentation de TTL, et la même opération décrite dans Cisco IOS et Linux se produit. L’utilisation des datagrammes de requête d’écho ICMP signifie que le saut final ne dépend pas de la réponse d’un message ICMP « inaccessible » de l’hôte de destination. Il s’appuie 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 la commande :

Paramètre

Description

-d

Spécifie de ne pas résoudre les adresses en noms d'ordinateurs.

-h sauts_maximum

Spécifie le nombre maximal de sauts à rechercher pour une cible.

-j liste-ordinateur

Spécifie une route source libre le long de la liste des ordinateurs.

-w timeout

Attend le nombre de millisecondes spécifié par le délai d'attente pour chaque réponse.

nom_cible

Nom de l'ordinateur cible.

Limitation du débit d'inaccessibilité ICMP

Les inaccessibles ICMP sont limitées à un paquet par 500 ms (en tant que protection contre les attaques par déni de service (DoS)) dans un routeur Cisco. À partir du logiciel Cisco IOS version 12.1 et ultérieure, cette valeur de débit est configurable. La commande présentée est la suivante :

ip icmp rate-limit unreachable

[DF] <1-4294967295 millisecond>

no ip icmp rate-limit unreachable [DF] (DF limits rate for code=4)

Référez-vous à l'ID de bogue Cisco CSCdp28161 (clients enregistrés uniquement) pour plus de détails.

Cette limitation concerne le taux global de toutes les inaccessibles ICMP, comme le montre ce résultat. 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 limitation n'affecte pas les autres paquets tels que les requêtes d'écho ICMP ou les messages ICMP « dépassement de temps ».

Exemples

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

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

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

Routeur Cisco avec logiciel Cisco IOS

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

rp-10c-2611#traceroute

Protocol [ip]:

Target IP address: 150.1.4.2

Source address: 150.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 150.1.4.2

1 150.1.1.2 4 msec 0 msec 4 msec

2 150.1.2.2 4 msec 4 msec 0 msec

3 150.1.3.2 0 msec 0 msec 4 msec

4 150.1.4.2 4 msec * 0 msec

rp-11a-7204#

*Dec 29 13:13:57.060: IP: s=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),

len 56, sending

*Dec 29 13:13:57.068: ICMP type=11, code=0

Dans ce résultat de débogage, le périphérique 11A envoie des messages ICMP « dépassement de délai » à la source des sondes (150.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales qui avaient une TTL=1. Le périphérique 11A décrémente la durée de vie à zéro et répond avec les messages de dépassement de temps.

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

- Le périphérique 11A n'est pas la destination des sondes UDP.

- La durée de vie est décrémentée à zéro et le paquet n’est jamais routé. Par conséquent, le débogage ne reconnaît jamais le paquet.

*Dec 29 13:13:57.068: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.1.1.1, len 56, forward

*Dec 29 13:13:57.076: ICMP type=11, code=0

Ce résultat de débogage montre la sonde UDP de la source 150.1.1.1 destinée à 150.1.4.2.

Note : Dans ces sondes, le TTL=2 (ceci ne peut pas être vu avec debug). Le périphérique 11A décrémente la durée de vie à 1 et transfère les paquets UDP sur le périphérique 7A. Le périphérique 7A décrémente la durée de vie à zéro et répond par des messages ICMP « dépassement de temps ».

*Dec 29 13:13:57.080: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.1.1.1, len 56, forward

*Dec 29 13:13:57.088: ICMP type=11, code=0

Vous voyez les trois prochaines sondes UDP dans cette sortie de débogage. La durée de vie de ces sondes est de 3. Le périphérique 11A décrémente la durée de vie à 2 et la transmet au périphérique 7A. Le périphérique 7A décrémente la durée de vie à 1 et transfère les paquets au périphérique 7B, qui décrémente la durée de vie à zéro et répond par des messages ICMP « dépassement de temps ».

*Dec 29 13:13:57.088: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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. La durée de vie initiale de ces sondes était de 4. La durée de vie a été décrémentée à 3 par le périphérique 11A, puis décrémentée à 2 par le périphérique 7A, puis décrémentée à 1 par le périphérique 7B. Le périphérique 7C répond par des messages ICMP « port inaccessible », car il était la destination des sondes.

Remarque : le périphérique 7C n'envoie que deux messages ICMP « port inaccessible » en raison de la limitation de débit.

PC avec Linux

[root#linux-pc]#traceroute -n 150.1.4.2

traceroute to 150.1.4.2 (150.1.4.2), 30 hops max, 40 byte packets

1. 150.1.1.2 1.140 ms 0.793 ms 0.778 ms

2. 150.1.2.2 2.213 ms 2.105 ms 3.491 ms

1. 150.1.3.2 3.146 ms 2.314 ms 2.347 ms

1. 150.1.4.2 3.579 ms * 2.954 ms

rp-11a-7204#

*Jan 2 07:17:27.894: IP: s=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),

len 56, sending

*Jan 2 07:17:27.894: ICMP type=11, code=0

Dans ce résultat de débogage, le périphérique 11A envoie des messages ICMP « dépassement de délai » à la source des sondes (150.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales qui avaient une TTL=1. Le périphérique 11A décrémente la durée de vie à zéro et répond avec les messages de dépassement de temps.

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

- Le périphérique 11A n'est pas la destination des sondes UDP.

- La durée de vie est décrémentée à zéro et le paquet n’est jamais routé. Par conséquent, le débogage ne reconnaît jamais le paquet.

*Jan 2 07:17:27.894: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.1.1.1, len 56, forward

*Jan 2 07:17:27.902: ICMP type=11, code=0

Remarque : dans cette sortie de débogage, vous voyez maintenant la sonde UDP de la source 150.1.1.1 destinée à 150.1.4.2.

Note : Dans ces sondes, le TTL=2 (ceci ne peut pas être vu avec debug). Le périphérique 11A décrémente la durée de vie à 1 et transfère les paquets UDP sur le périphérique 7A. Le périphérique 7A décrémente la durée de vie à zéro et répond par des messages ICMP « dépassement de temps ».

*Jan 2 07:17:27.902: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.1.1.1, len 56, forward

*Jan 2 07:17:27.910: ICMP type=11, code=0

Les trois prochaines sondes UDP sont maintenant visibles dans cette sortie de débogage. La durée de vie de ces sondes est de 3. Le périphérique 11A décrémente la durée de vie à 2 et la transmet au périphérique 7A. Le périphérique 7A décrémente la durée de vie à 1 et transfère les paquets au périphérique 7B, qui décrémente la durée de vie à zéro et répond par des messages ICMP « dépassement de temps ».

*Jan 2 07:17:27.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),

g=150.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. La durée de vie initiale de ces sondes était de 4. La durée de vie a été décrémentée à 3 par le périphérique 11A, puis décrémentée à 2 par le périphérique 7A, puis décrémentée à 1 par le périphérique 7B. Le périphérique 7C répond ensuite avec des messages ICMP « port inaccessible », car il était la destination des sondes.

Remarque : le périphérique 7C n'envoie que deux messages ICMP « port inaccessible » en raison de la limitation de débit.

PC avec MS Windows

C:\>tracert 150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),

len 56, sending

*Dec 29 14:02:26.752: ICMP type=11, code=0

Dans ce résultat de débogage, le périphérique 11A envoie des messages ICMP « dépassement de délai » à la source des sondes (150.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales, qui sont des paquets de requête d'écho ICMP avec une TTL=1. Le périphérique 11A décrémente la durée de vie à zéro et répond avec les messages ICMP.

Note : En haut, vous voyez les demandes de noms NETBIOS. Ces requêtes sont considérées comme des paquets UDP avec des ports source et de destination de 137. Pour des raisons de clarté, les paquets NETBIOS sont supprimés du reste de la sortie de débogage. Vous pouvez utiliser l'option -d de la commande tracert pour désactiver le comportement NETBIOS.

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

- Le périphérique 11A n'est pas la destination des sondes ICMP.

- La durée de vie est décrémentée à zéro et le paquet n’est jamais routé. Par conséquent, le débogage ne reconnaît jamais le paquet.

*Dec 29 14:02:32.256: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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 150.1.1.1 destinée à 150.1.4.2.

Note : Dans ces sondes, le TTL=2 (ceci ne peut pas être vu avec debug). Le périphérique 11A décrémente la durée de vie à 1 et transfère les paquets UDP au périphérique 7A. Le périphérique 7A décrémente la durée de vie à zéro et répond par des messages ICMP « dépassement de temps ».

*Dec 29 14:02:37.776: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.1.1.1, len 56, forward

*Dec 29 14:02:37.784: ICMP type=11, code=0

Vous voyez les trois prochaines sondes ICMP dans cette sortie de débogage. La durée de vie de ces sondes est de 3. Le périphérique 11A décrémente la durée de vie à 2 et la transmet au périphérique 7A. Le périphérique 7A décrémente la durée de vie à 1 et transfère les paquets au périphérique 7B, qui décrémente la durée de vie à zéro et répond par des messages ICMP « dépassement de temps ».

*Dec 29 14:02:43.292: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),

g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),

g=150.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. La durée de vie initiale de ces sondes était de 4. La durée de vie a été décrémentée à 3 par le périphérique 11A, puis décrémentée à 2 par le périphérique 7A, puis décrémentée à 1 par le périphérique 7B. Le périphérique 7C répond ensuite avec des messages de réponse d'écho ICMP (type=0, code=0), car il était la destination des sondes.

Remarque : Les messages de réponse d'écho ICMP ne sont pas limités car les messages ICMP « port inaccessible » l'étaient. Dans ce cas, les trois messages de réponse d’écho ICMP sont envoyés.

Remarques supplémentaires

Dans les routeurs Cisco, les codes d'une réponse de commande traceroute 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 les éléments suivants :

- Vous pouvez recevoir « traceroute : socket icmp : Messages d'autorisation refusés.

- Le programme traceroute s'appuie sur le NIT (Network Interface Tap) pour naviguer dans le réseau. Ce périphérique est uniquement accessible par racine. Vous devez soit exécuter le programme en tant que racine, soit définir l'ID utilisateur de la racine.

Résumé

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

- Si la durée de vie est dépassée en transit, type=11, code=0, alors le paquet est renvoyé par le routeur de transit dans tous les cas où la durée de vie 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 par 500 ms. Ceci explique pourquoi la réponse de la destination (voir les sorties pour le 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 traceroute dans chaque périphérique attend plus d'une seconde. Dans le cas de la sortie de la commande tracert MS Windows, le message ICMP est généré car le port UDP 137 n'existe pas dans un routeur Cisco.

- S'il existe un écho, type=8, code=0, le paquet de sonde d'écho est envoyé par le PC MS Windows.

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

Informations connexes

- Support et documentation techniques - Cisco Systems