IP : Protocoles de routage IP

Utilisation de la commande traceroute sur les systèmes d'exploitation

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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 hôte du système d'exploitation (par exemple, Linux ou Microsoft (MS) Windows), aussi bien qu'avec le logiciel de ½ du ¿  de Cisco IOSïÂ.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir la connaissance de base d'un de ces systèmes d'exploitation :

  • Logiciel Cisco IOS

  • Linux

  • Microsoft Windows

Composants utilisés

Les informations dans ce document appliquent aux ces le logiciel et les versions de matériel :

  • Routeur de Cisco qui exécute la version du logiciel Cisco IOS 12.2(27)

  • PC qui exécute la version 9 de Red Hat Linux

  • PC qui exécute le MS Windows 2000

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Exécution générale

Si vous exécutez la commande d'IP address de traceroute sur un périphérique de source (tel qu'un hôte, ou un routeur agissant en tant qu'hôte), il envoie des paquets IP vers la destination avec les valeurs du Time to Live (TTL) qui incrémentent jusqu'au compte de saut spécifié par maximum. C'est 30 par défaut. Typiquement, chaque routeur dans le chemin vers la destination décrémente le champ TTL par une unité tandis qu'il en avant ces paquets. Quand un routeur au milieu du chemin trouve un paquet avec TTL = 1, il répond avec message dépassé un « par temps » de Protocole ICMP (Internet Control Message Protocol) à la source. Ce message fait la source savoir que les traversées de paquet ce routeur particulier comme saut

Il y a quelques différences avec la manière que la commande traceroute est mise en application dans les divers systèmes d'exploitation ce document discute.

Cisco IOS et Linux

Le TTL pour la sonde initiale de datagramme de Protocole UDP (User Datagram Protocol) est placé à 1 (ou au minimum TTL, comme spécifié par l'utilisateur dans la commande traceroute étendue. Le port UDP de destination de la sonde initiale de datagramme est placé à 33434 (ou comme spécifié dans la commande traceroute étendue sortie). La commande traceroute étendue est une variation de la commande traceroute ordinaire qui permet les valeurs par défaut des paramètres utilisés par l'exécution de traceroute telle que le TTL et le nombre de destination port à modifier. Pour plus d'informations sur la façon utiliser la commande traceroute étendue, référez-vous utilisant les commandes étendues de ping et de traceroute étendu. Le port UDP de source de la sonde initiale de datagramme est sélectionné de façon aléatoire et a l'opérateur logique OU avec 0x8000 (assure un port minimum de source de 0x8000). Ces étapes illustrent ce qui se produit quand le datagramme UDP est lancé :

Remarque: Les paramètres sont configurables. Débuts de cet exemple avec n = 1 et finitions avec n = 3.

  1. Le datagramme UDP est acheminé avec TTL = 1, port= 33434 d'UDP de destination, et le port de source sélectionné de façon aléatoire.

  2. La destination port d'UDP est incrémentée, le port UDP de source est sélectionné de façon aléatoire, et le deuxième datagramme est acheminé.

  3. Étape 2 est répétée pour jusqu'à trois sondes (ou autant de fois comme en a été faite la demande dans une commande traceroute étendue sortie). Pour chacune des sondes envoyées, vous recevez un message dépassé « par TTL », qui est utilisé pour construire un chemin pas à pas à la destination host.

  4. Le TTL est incrémenté, et des répétitions de ce cycle avec les nombres incrémentaux de destination port, si message dépassé le « par temps » d'ICMP est reçu. Vous pouvez également recevoir un de ces messages :

    • Un type ICMP 3, message du code 3 (« destination inaccessible, » « port inaccessible »), qui indique qu'un hôte a été atteint.

    • « Inaccessible d'hôte, » « net inaccessible, » le « maximum TTL a dépassé, » ou un type de « délai d'attente » de message, ainsi il signifie que la sonde est renvoyée.

Les Routeurs de Cisco envoient des paquets de sonde d'UDP avec un port aléatoire de source et une destination port incrémentale (pour distinguer les différentes sondes). Les Routeurs de Cisco envoient le message ICMP « temps dépassé » de nouveau à la source d'où le paquet UDP/ICMP a été reçu.

La commande traceroute de Linux est semblable à l'implémentation de routeur de Cisco. Cependant, il utilise un port fixe de source. - L'option n dans la commande traceroute est utilisée pour éviter une demande à un Serveur de noms.

Microsoft Windows

La commande tracert de MS Windows utilise des datagrammes de requête d'écho d'ICMP au lieu des datagrammes UDP comme sondes. Des requêtes d'écho d'ICMP sont lancées avec incrémenter le TTL, et la même exécution comme décrit dans le Cisco IOS et le Linux se produit. L'importance d'utiliser des datagrammes de requête d'écho d'ICMP est que le saut final ne se fonde pas sur la réponse message d'un « inaccessible » d'ICMP de la destination host. Il se fonde à la place sur un message de réponse d'écho d'ICMP.

La syntaxe de commande est la suivante :

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

Cette table explique les paramètres de commande :

Paramètre Description
- d Spécifie pour ne pas résoudre des adresses aux noms de l'ordinateur.
- maximum_hops h Spécifie le nombre maximal de sauts pour rechercher une cible.
- ordinateur-liste j Spécifie une artère lâche de source le long d'ordinateur-liste.
- délai d'attente W Attend le nombre de millisecondes spécifiées par le délai d'attente chaque réponse.
target_name Nom de l'ordinateur cible.

Limite de débit d'Unreachables d'ICMP

Des unreachables d'ICMP sont limités à un paquet par 500 ms (comme une protection pour des attaques du Déni de service (DOS)) dans un routeur de Cisco. Du Logiciel Cisco IOS version 12.1 et plus tard, ce teneur en débit est configurable. La commande introduite est :


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 seulement) pour d'autres détails.

Cette limite est pour le débit global de tous les unreachables d'ICMP, car cette sortie affiche. Référez-vous au pour en savoir plus RFCleavingcisco.com 792.

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 n'affecte pas d'autres paquets comme des requêtes d'écho d'ICMP ou des messages dépassés « par temps » d'ICMP.

Exemples

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

/image/gif/paws/22826/traceroute-01.gif

Dans chacun des trois exemples, un différent périphérique A est utilisé. Du périphérique A, la commande de 150.1.4.2 de traceroute est exécutée au périphérique 7C.

Dans chacun des exemples, la commande de détail de debug ip packet fonctionne sur le périphérique 11A.

Routeur de Cisco avec le logiciel de Cisco IOS

Cet exemple étendu de commande traceroute affiche les options que vous pouvez changer quand vous exécutez une commande traceroute d'un routeur de Cisco. Dans cet exemple, tout est par défaut de gauche :

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 cette sortie de débogage, le périphérique 11A envoie les messages dépassés « par temps » d'ICMP à la source des sondes (150.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales qui ont eu un TTL=1. Le périphérique 11A décrémente le TTL à zéro, et répond avec les messages dépassés « par temps ».

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

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

  • Le TTL est décrémenté à zéro, et le paquet n'est jamais conduit. Par conséquent, le débogage n'identifie 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

Cette sortie de débogage affiche la sonde d'UDP de la source 150.1.1.1 destinée à 150.1.4.2.

Remarque:  Dans des ces sondes le TTL=2 (ceci ne peut pas être vu avec mettent au point). Le périphérique 11A décrémente le TTL à 1 et en avant les paquets UDP sur le périphérique 7A. Le périphérique 7A décrémente le TTL à zéro, et répond avec les messages dépassés « par temps » d'ICMP.

*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 d'UDP dans cette sortie de débogage. Le TTL pour ces sondes est 3. que le périphérique 11A décrémente le TTL à 2 et en avant eux en fonction au périphérique 7A. Le périphérique 7A décrémente le TTL à 1 et en avant les paquets en fonction au périphérique 7B, qui décrémente le TTL à zéro et répond avec les messages dépassés « par temps » d'ICMP.

*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 d'UDP dans cette sortie de débogage. L'original TTL de ces sondes était 4. Le TTL a été décrémenté à 3 par le périphérique 11A, puis décrémenté à 2 par le périphérique 7A, puis décrémenté au périphérique 7B de 1par. Le périphérique 7C répond avec l'ICMP messages inaccessibles de « port », puisque c'était la destination des sondes.

Remarque: Le périphérique 7C envoie seulement deux à l'ICMP « port » les messages inaccessibles en raison de la limite de débit.

PC avec le 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 cette sortie de débogage, le périphérique 11A envoie les messages dépassés « par temps » d'ICMP à la source des sondes (150.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales qui ont eu un TTL=1. Le périphérique 11A décrémente le TTL à zéro, et répond avec les messages dépassés « par temps ».

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

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

  • Le TTL est décrémenté à zéro, et le paquet n'est jamais conduit. Par conséquent, le débogage n'identifie 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 d'UDP de la source 150.1.1.1 destinée à 150.1.4.2.

Remarque: Dans des ces sondes le TTL=2 (ceci ne peut pas être vu avec mettent au point). Le périphérique 11A décrémente le TTL à 1 et en avant les paquets UDP sur le périphérique 7A. Le périphérique 7A décrémente le TTL à zéro, et répond avec les messages dépassés « par temps » d'ICMP.

*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 d'UDP sont maintenant vues dans cette sortie de débogage. Le TTL pour ces sondes est 3. que le périphérique 11A décrémente le TTL à 2 et en avant eux en fonction au périphérique 7A. Le périphérique 7A décrémente le TTL à 1 et en avant les paquets en fonction au périphérique 7B, qui décrémente le TTL à zéro et répond avec les messages dépassés « par temps » d'ICMP.

*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 affiche les trois dernières sondes d'UDP. L'original TTL de ces sondes était 4. Le TTL a été décrémenté à 3 par le périphérique 11A, puis décrémenté à 2 par le périphérique 7A, puis décrémenté au périphérique 7B de 1par. Le périphérique 7C répond alors avec l'ICMP messages inaccessibles de « port », puisque c'était la destination des sondes.

Remarque: Le périphérique 7C envoie seulement deux à l'ICMP « port » les messages inaccessibles en raison de la limitation de débit.

PC avec le 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 cette sortie de débogage, le périphérique 11A envoie les messages dépassés « par temps » d'ICMP à la source des sondes (150.1.1.1). Ces messages ICMP sont en réponse aux sondes initiales, qui sont des paquets de demande d'écho d'ICMP avec un TTL=1. Le périphérique 11A décrémente le TTL à zéro et répond avec les messages ICMP.

Remarque: Au dessus vous voyez les demandes de nom NetBIOS. Ces demandes sont vues comme paquets UDP avec la source et les destinations port de 137. Pour des raisons de clarté, les paquets de NETBIOS sont retirés du reste de la sortie de débogage. Vous pouvez utiliser - l'option d dans la commande tracert de désactiver le comportement de NETBIOS.

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

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

  • Le TTL est décrémenté à zéro, et le paquet n'est jamais conduit. Par conséquent, le débogage n'identifie 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 d'ICMP de la source 150.1.1.1 destinée à 150.1.4.2.

Remarque: Dans des ces sondes, le TTL=2 (ceci ne peut pas être vu avec mettent au point). Le périphérique 11A décrémente le TTL à 1 et en avant les paquets UDP en fonction au périphérique 7A. Le périphérique 7A décrémente le TTL à zéro, et répond avec les messages dépassés « par temps » d'ICMP.

*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 d'ICMP dans cette sortie de débogage. Le TTL pour ces sondes est 3. que le périphérique 11A décrémente le TTL à 2 et en avant eux en fonction au périphérique 7A. Le périphérique 7A décrémente le TTL à 1 et en avant les paquets en fonction au périphérique 7B, qui décrémente le TTL à zéro et répond avec les messages dépassés « par temps » d'ICMP.

*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 affiche les trois dernières sondes d'ICMP. L'original TTL de ces sondes était 4. Le TTL a été décrémenté à 3 par le périphérique 11A, puis décrémenté à 2 par le périphérique 7A, puis décrémenté au périphérique 7B de 1par. Le périphérique 7C répond alors avec les messages de réponse d'écho d'ICMP (type=0, code=0), puisque c'était la destination des sondes.

Remarque: Les messages de réponse d'écho d'ICMP ne sont pas débit limité comme ICMP « port » les messages qu'inaccessibles étaient. Dans ce cas, vous voyez chacun des trois messages de réponse d'écho d'ICMP envoyés.

Notes supplémentaires

Dans des Routeurs de Cisco, les codes pour une réponse de commande traceroute sont :

! -- 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 de l'UNIX, notez ces éléments :

  • Vous pouvez recevoir la « traceroute : socket d'ICMP :  » Messages refusés par autorisation.

  • Le programme traceroute se fonde sur la prise d'interface réseau (LENTE) pour piller dans le réseau. Ce périphérique est seulement accessible par la racine. Vous devez l'un ou l'autre exécuté le programme comme racine, ou placer l'user-id pour la racine.

Résumé

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

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

  • Si le port est inaccessible, type=3, code=3, alors le paquet est renvoyé en réponse aux paquets de sonde d'UDP quand ils atteignent la destination (l'application d'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 (voyez les sorties pour le routeur et le Linux de Cisco) a manqué dans même les réponses. Le périphérique 7C ne génère pas le message ICMP, et la sortie de commande traceroute dans des attentes de chaque périphérique plus d'une seconde. Dans le cas de la sortie de commande tracert de MS Windows, le message ICMP est généré parce que le port UDP 137 n'existe pas dans un routeur de Cisco.

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

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


Informations connexes


Document ID: 22826