Comprendre les commandes Ping et Traceroute
Table des matières
Introduction
Ce document décrit l’utilisation des commandes Ping et Traceroute sur les routeurs Cisco.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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
Cette configuration de base est utilisée pour des exemples présentés dans cet article du présent document :
Configuration de base des adresses IP et des routeurs
La commande ping
La commande ping est très courante pour le dépannage en cas de problèmes d’accessibilité des périphériques. Elle emploie une série de messages d'écho d'Internet Control Message Protocol (ICMP) pour déterminer :
-
Si un hôte distant est actif ou inactif.
-
La durée aller-retour pour la communication avec l’hôte.
-
La perte de paquets.
La commande Ping envoie d'abord un paquet de demande d'écho à l'adresse, puis attend une réponse. Le ping est réussi seulement si :
-
la demande d'écho arrive à la destination, et
-
la destination peut renvoyer une réponse d'écho à la source dans un délai prédéterminé intitulé un délai d´attente. La valeur par défaut de ce délai d´attente est de deux secondes sur les routeurs Cisco.
La valeur de TTL d'un paquet ping ne peut pas être changée.
Le prochain exemple de code montre la commande ping après l’activation de la commande debug ip packet detail.
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms Router1# Jan 20 15:54:47.487: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 15:54:47.491: ICMP type=8, code=0 !--- This is the ICMP packet 172.16.12.1 sent to 172.16.0.12.
!--- ICMP type=8 corresponds to the echo message. Jan 20 15:54:47.523: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3 Jan 20 15:54:47.527: ICMP type=0, code=0 !--- This is the answer we get from 172.16.0.12. !--- ICMP type=0 corresponds to the echo reply message.
!--- By default, the repeat count is five times, so there will be five
!--- echo requests, and five echo replies.
Valeurs de type ICMP possibles
| Type ICMP | Littéral |
|---|---|
| 0 | réponse d'écho |
| 3 | code de destination impossible à joindre 0 = réseau inaccessible 1 = hôte inaccessible 2 = protocole inaccessible 3 = port inaccessible 4 = fragmentation requise et bit DF 5 = échec du routage source |
| 4 | source-quench |
| 5 | code de redirection 0 = rediriger les datagrammes pour le réseau 1 = rediriger les datagrammes pour l’hôte 2 = rediriger les datagrammes pour le type de service et le réseau 3 = rediriger les datagrammes pour le type de service et l’hôte |
| 6 | adresse alternative |
| 8 | echo |
| 9 | routeur-annonce |
| 10 | routeur-sollicitation |
| 11 | code de temps dépassé 0 = durée de vie utile dépassée pendant le transit 1 = temps de réassemblage des fragments dépassé |
| 12 | Problème de paramètre |
| 13 | demande d´horodatage |
| 14 | réponse d'horodatage |
| 15 | demande d'informations |
| 16 | réponse à la demande d'informations |
| 17 | demande de masque |
| 18 | réponse à la demande de masque |
| 31 | erreur de conversion |
| 32 | redirection de mobile |
Caractères de sortie possibles à partir de la fonction Ping
| Caractère | Description |
|---|---|
| ! | Chaque point d'exclamation indique la réception d'une réponse. |
| . | Un point (.) indique que le serveur du réseau a expiré lorsqu’il attendait une réponse. |
| U | Une erreur PDU de destination inaccessible a été reçue. |
| Q | Épuisement de la source (destination trop occupée). |
| L | N'a pas pu fragmenter. |
| ? | Type de paquet inconnu. |
| & | Durée de vie du paquet dépassée. |
Impossible d’envoyer un message ping
Si vous ne parvenez pas à envoyer un message ping vers une adresse IP, examinez la liste de causes figurant dans cette section.
Problème de routeur
Voici des exemples de tentatives d’envoi de message ping infructueux qui peuvent déterminer le problème ainsi que la marche à suivre pour le résoudre. Cet exemple est accompagné du diagramme de topologie de réseau suivant :
Problèmes de routeur
Router1# ! interface Serial0 ip address 172.16.12.1 255.255.255.0 no fair-queue clockrate 64000 ! Router2# ! interface Serial0 ip address 10.0.2.23 255.255.255.0 no fair-queue clockrate 64000 ! interface Serial1 ip address 172.16.0.12 255.255.255.0 ! Router3# ! interface Serial0 ip address 172.16.3.34 255.255.255.0 no fair-queue ! interface Serial1 ip address 10.0.3.23 255.255.255.0 ! Router4# ! interface Serial0 ip address 172.16.4.34 255.255.255.0 no fair-queue clockrate 64000 !
Essayez d’envoyer un message ping au routeur 4 à partir du routeur 1 :
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Résultats :
Router1#debug ip packet IP packet debugging is on
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:00:25.603: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:27.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:29.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:31.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Jan 20 16:00:33.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable. Success rate is 0 percent (0/5)
Comme aucun protocole de routage ne fonctionne sur le routeur 1, ce dernier ne sait pas où envoyer son paquet, et un message « unrouteable » s’affiche alors.
Ajoutez une route statique au routeur 1 :
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Résultats :
Router1#debug ip packet detail IP packet debugging is on (detailed) Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:05:30.659: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.663: ICMP type=8, code=0 Jan 20 16:05:30.691: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:30.695: ICMP type=3, code=1 Jan 20 16:05:30.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:30.703: ICMP type=8, code=0 Jan 20 16:05:32.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.703: ICMP type=8, code=0 Jan 20 16:05:32.731: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:05:32.735: ICMP type=3, code=1 Jan 20 16:05:32.739: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:05:32.743: ICMP type=8, code=0
Examinez ce qui ne va pas sur le routeur 2 :
Router2#debug ip packet detail IP packet debugging is on (detailed) Router2# Jan 20 16:10:41.907: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.911: ICMP type=8, code=0 Jan 20 16:10:41.915: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:41.919: ICMP type=3, code=1 Jan 20 16:10:41.947: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:41.951: ICMP type=8, code=0 Jan 20 16:10:43.943: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.947: ICMP type=8, code=0 Jan 20 16:10:43.951: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:43.955: ICMP type=3, code=1 Jan 20 16:10:43.983: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:43.987: ICMP type=8, code=0 Jan 20 16:10:45.979: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable Jan 20 16:10:45.983: ICMP type=8, code=0 Jan 20 16:10:45.987: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending Jan 20 16:10:45.991: ICMP type=3, code=1
Le routeur 1 a correctement envoyé ses paquets au routeur 2, mais ce dernier ne sait pas comment accéder à l’adresse 172.16.4.34. Router2 renvoie un message « ICMP inaccessible » à Router1.
Activez le protocole RIP (Routage Information Protocol) sur les routeurs 2 et 3 :
Router2# router rip network 172.16.0.7 network 10.0.7.23 Router3# router rip network 10.0.7.23 network 172.16.0.34
Résultats :
Router1#debug ip packet IP packet debugging is on Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: Jan 20 16:16:13.367: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:15.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:17.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:19.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Jan 20 16:16:21.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Le routeur 1 envoie des paquets au routeur 4, mais le routeur 4 ne renvoie pas de réponse.
Problème possible sur le routeur 4 :
Router4#debug ip packet IP packet debugging is on Router4# Jan 20 16:18:45.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:45.911: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:47.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:47.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:49.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:49.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:51.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:51.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable Jan 20 16:18:53.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:18:53.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Le routeur 4 reçoit les paquets ICMP et tente de répondre à l’adresse 172.16.12.1, mais comme il ne dispose d’aucune route vers ce réseau, il échoue.
Ajouter une route statique au routeur 4 :
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Les deux côtés peuvent désormais communiquer entre eux :
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Interface inactive
Il s’agit d’une situation où l’interface s’arrête et ne fonctionne plus. Dans l’exemple suivant, une tentative d’envoi d’un message ping vers le routeur 4 s’effectue à partir du routeur 1 :
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
Comme le routage est correct, procédez au dépannage étape par étape du problème. Essayez d’envoyer un message ping au routeur 2 :
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
D’après l’exemple précédent, le problème se situe entre le routeur 2 et le routeur 3. Une possibilité est que l'interface série sur Router3 a été arrêtée :
Router3#show ip interface brief Serial0 172.16.3.34 YES manual up up Serial1 10.0.3.23 YES manual administratively down down
Cette situation est simple à résoudre :
Router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router3(config)#interface serial1 Router3(config-if)#no shutdown Router3(config-if)# Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
Commande Access-list
Dans ce scénario, seul le trafic Telnet est autorisé à entrer dans le routeur 4 par l’interface Serial0.
Router4(config)# access-list 100 permit tcp any any eq telnet Router4(config)#interface serial0 Router4(config-if)#ip access-group 100 in Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#access-list 100 permit ip host 172.16.12.1 host 172.16.4.34 Router1(config)#access-list 100 permit ip host 172.16.4.34 host 172.16.12.1 Router1(config)#end Router1#debug ip packet 100 IP packet debugging is on Router1#debug ip icmp ICMP packet debugging is on
Essayez d’envoyer un message ping au routeur 4 :
Router1#ping 172.16.4.34 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) Jan 20 16:34:49.207: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:49.287: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:49.291: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:49.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending Jan 20 16:34:51.367: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:34:51.371: ICMP: dst (172.16.12.1) administratively prohibited unreachable rcv from 172.16.4.34 Jan 20 16:34:51.379: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, sending
À la fin d’une commande access-list, il y a toujours un rejet total implicite (Implicit Deny All). Cela signifie que les paquets ICMP qui entrent dans l'interface Serial 0 sur le routeur 4 sont refusés, et le routeur 4 envoie un message ICMP « administratively disabled unreachable » à la source du paquet d'origine, comme indiqué dans le message de débogage. La solution est d’ajouter cette ligne dans la commande access-list :
Router4(config)#access-list 100 permit icmp any any
Problème de Protocole de résolution d'adresse (ARP)
Dans ce scénario, la connexion Ethernet suivante est utilisée :
Problème de protocole ARP
Router4#ping 172.16.100.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: Jan 20 17:04:05.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:05.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:07.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:07.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:09.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:09.183: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:11.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:11.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Jan 20 17:04:13.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, sending Jan 20 17:04:13.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, encapsulation failed. Success rate is 0 percent (0/5) Router4#
Dans cet exemple, la commande ping ne fonctionne pas à cause du message « encapsulation failed » (échec de l’encapsulation). Cela signifie que le routeur sait sur quelle interface il doit envoyer le paquet, mais ignore comment le faire. Dans ce cas, vous devez comprendre comment fonctionne le protocole ARP (Address Resolution Protocol).
ARP est un protocole utilisé pour mapper l’adresse de couche 2 (adresse MAC) avec une adresse de couche 3 (adresse IP). Vous pouvez vérifier à l’aide la commande show arp :
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.7 10 0060.5cf4.a955 ARPA Ethernet0
Revenez au problème de l’« échec de l’encapsulation », mais activez cette fois la commande debug arp :
Router4#debug arp
ARP packet debugging is on
Router4#ping 172.16.100.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds:
Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 172.16.100.5
interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
dst 172.16.100.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)
La sortie précédente montre que le routeur 4 diffuse des paquets et les envoie à l’adresse de diffusion Ethernet FFFF.FFFF.FFFF. Ici, 0000.0000.0000 signifie que le routeur 4 cherche l’adresse MAC de la destination 172.16.100.5. Comme il ne connaît pas l’adresse MAC alors que l’ARP est demandé dans cet exemple, il utilise 0000.0000.000 comme espace réservé dans les trames de diffusion envoyées hors de l’interface Ethernet 0 et demande quelle adresse MAC correspond à 172.16.100.5. S’il n’y a aucune réponse, l’adresse MAC qui correspond à l’adresse IP dans la sortie de show aRP est marquée comme incomplète :
Router4#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.100.4 - 0000.0c5d.7a0d ARPA Ethernet0 Internet 172.16.100.5 0 Incomplete ARPA Internet 172.16.100.7 2 0060.5cf4.a955 ARPA Ethernet0
Après une période prédéterminée, cette entrée incomplète est purgée du tableau ARP. Tant que l’adresse MAC ne se trouve pas dans le tableau ARP, le message ping échoue en raison de l’échec de l’encapsulation.
Délai
Par défaut, si vous ne recevez pas de réponse du dispositif distant dans deux secondes, le ping échoue :
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Sur des réseaux avec une liaison lente ou un long délai d'attente, deux secondes ne sont pas suffisantes. Vous pouvez modifier ce paramètre par défaut grâce à la commande extended ping :
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: 30 Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 30 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
Pour plus d’informations sur la commande ping étendu, consultez Understand the Extended Ping and Extended Traceroute Commands (Comprendre les commandes Extended Ping et Extended Traceroute).
Dans l’exemple précédent, lorsque le délai d’expiration a été augmenté, l’envoi du message ping a réussi.
Adresse source correcte
Voici un exemple de scénario courant :
Adresse source correcte
Ajoutez une interface LAN sur le routeur 1 :
Router1(config)#interface ethernet0 Router1(config-if)#ip address 10.0.0.1 255.255.255.0
Depuis une station sur le LAN, vous pouvez envoyez un ping au Router1. Depuis Router1 vous pouvez envoyez un ping au Router2. Mais d'une station sur le LAN, vous ne pouvez pas envoyez un ping au Router2.
Du Router1, vous pouvez envoyez un ping au Router2 parce que, par défaut, vous utilisez l'adresse IP de l´interface sortante comme adresse source dans votre paquet ICMP. Le routeur 2 ne dispose pas d’informations sur ce nouveau réseau local. S’il doit répondre à un paquet provenant de ce réseau, il ne saura pas comment le gérer.
Router1#debug ip packet IP packet debugging is on
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms Router1# Jan 20 16:35:54.227: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:35:54.259: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3
L’exemple de sortie précédent fonctionne, car l’adresse source du paquet envoyé est 172.16.12.1. Pour simuler un paquet du réseau local, vous devez envoyer un message ping étendu :
Router1#ping Protocol [ip]: Target IP address: 172.16.0.12 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 10.0.0.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: Jan 20 16:40:18.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:20.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:22.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Jan 20 16:40:24.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending Jan 20 16:40:26.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100, sending. Success rate is 0 percent (0/5)
Cette fois, l’adresse source est 10.0.0.1, et l’envoi ne fonctionne pas. Des paquets sont envoyés, mais aucune réponse n’est reçue. Pour résoudre ce problème, ajoutez une route à 10.0.0.0 dans le routeur 2. La règle de base, c’est que le périphérique interrogé doit également savoir comment envoyer la réponse à la source du message ping.
Pertes de file d'attente d'entrée élevées
Quand un paquet entre dans le routeur, celui-ci essaye de le transférer au niveau de priorité d'interruption. Si une correspondance ne peut pas être trouvée dans un tableau de cache approprié, le paquet est aligné dans la file d'attente de l'interface entrante à traiter. Certains packets sont toujours traités, mais avec la configuration appropriée et dans des réseaux stables, le débit des paquets traités ne doit jamais congestionner la file d'attente d'entrée. Si la file d'attente d'entrée est pleine, le paquet est perdu.
Bien que l’interface soit opérationnelle, vous ne pouvez pas envoyer un message ping au périphérique en raison du nombre élevé d’abandons dans la file d’attente. Vous pouvez vérifier les suppressions d’entrées grâce à la commande show interface.
Router1#show interface Serial0/0/0
Serial0/0/0 is up, line protocol is up
MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec,
reliability 255/255, txload 69/255, rxload 43/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of "show interface" counters 01:28:49
Input queue: 76/75/5553/0 (size/max/drops/flushes);
Total output drops: 1760
Queueing strategy: Class-based queueing
Output queue: 29/1000/64/1760 (size/max total/threshold/drops)
Conversations 7/129/256 (active/max active/max total)
Reserved Conversations 4/4 (allocated/max allocated)
Available Bandwidth 1289 kilobits/sec
!--- Output supressed
Comme vu pour la sortie, la perte de la file d'attente d'entrée est élevée. Consultez la section Troubleshoot Input Queue Drops and Output Queue Drops (Dépannage des abandons dans la file d’attente des entrées et sorties).
La commande traceroute
La commande traceroute est utilisée pour découvrir les routes que les paquets empruntent réellement pour se rendre à leur destination. Le périphérique (par exemple, un routeur ou un PC) envoie une séquence de datagrammes du Protocole de datagramme utilisateur (UDP) à une adresse de port non valide à l'hôte distant.
Trois datagrammes sont envoyés, chacun avec une valeur du champ Time to Live (TTL) égale à un. La valeur TTL de 1 entraîne l’expiration du délai du datagramme dès qu’il atteint le premier routeur du chemin. Ce routeur répond ensuite par un message de dépassement de délai ICMP qui indique que le datagramme a expiré.
Trois autres messages UDP sont maintenant envoyés, chacun avec la valeur de TTL mise à 2, ce qui cause le deuxième routeur de renvoyer des TEM de l´ICMP. Ce processus se poursuit jusqu’à ce que les paquets atteignent l’autre destination. Comme ces datagrammes tentent d’accéder à un port non valide sur l’hôte de destination, des messages de port inaccessible ICMP sont renvoyés, indiquant que le port est inaccessible. Cet événement signale au programme Traceroute qu’il a terminé.
Le but derrière ceci est d'enregistrer la source de chaque message ICMP de temps dépassé afin de fournir une trace du chemin que le paquet a pris pour atteindre la destination.
Router1#traceroute 172.16.4.34 Type escape sequence to abort. Tracing the route to 172.16.4.34 1 172.16.0.12 4 msec 4 msec 4 msec 2 10.0.3.23 20 msec 16 msec 16 msec 3 172.16.4.34 16 msec * 16 msec Jan 20 16:42:48.611: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.615: UDP src=39911, dst=33434 Jan 20 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.639: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router2. Jan 20 16:42:48.643: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.647: UDP src=34237, dst=33435 Jan 20 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.671: ICMP type=11, code=0 Jan 20 16:42:48.675: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.679: UDP src=33420, dst=33436 Jan 20 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.703: ICMP type=11, code=0
Il s’agit de la première séquence de paquets, envoyée avec une TTL = 1. Le premier routeur, dans ce cas Router2 (172.16.0.12), perd le paquet, et renvoie à la source (172.16.12.1) un message ICMP de type=11. Ceci correspond au message de temps dépassé.
Jan 20 16:42:48.707: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.711: UDP src=35734, dst=33437 Jan 20 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.747: ICMP type=11, code=0 !--- ICMP Time Exceeded Message from Router3. Jan 20 16:42:48.751: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.755: UDP src=36753, dst=33438 Jan 20 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.791: ICMP type=11, code=0 Jan 20 16:42:48.795: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28, sending Jan 20 16:42:48.799: UDP src=36561, dst=33439 Jan 20 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56, rcvd 3 Jan 20 16:42:48.831: ICMP type=11, code=0
Le même processus se produit pour Router3 (10.0.3.23) avec un TTL=2 :
Jan 20 16:42:48.839: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
!--- Port Unreachable message from Router4.
Jan 20 16:42:48.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Avec une TTL = 3, le routeur 4 est enfin atteint. Cette fois, puisque le port est incorrect, Router4 renvoie à Router1 un message ICMP avec type=3, un message d'inaccessibilité de destination, et le code=3 qui signifie port inaccessible.
Le tableau suivant répertorie les caractères qui peuvent figurer dans la sortie de la commande traceroute.
IP traceroute caractères des textes
| Caractère | Description |
|---|---|
| nn millisecondes | Pour chaque noeud, le temps d´aller-retour en millisecondes pour le nombre spécifié de sondes |
| * | Le temps de la sonde est dépassé |
| A | Administrativement interdit (exemple, liste d'accès) |
| Q | Épuisement de la source (destination trop occupée) |
| I | Test interrompu par l´utilisateur |
| U | Port inaccessible |
| H | Hôte inacessible |
| n | Réseau inaccessible |
| P | Protocole inaccessible |
| T | Timeout (Délai d’expiration) |
| ? | Type de paquet inconnu. |
rendement
Vous pouvez obtenir le temps aller-retour (RTT) grâce aux commandes ping et traceroute. Il s’agit du temps nécessaire pour envoyer un paquet écho et obtenir une réponse. Cela peut donner une idée approximative du délai sur la liaison. Cependant, ces chiffres ne sont pas assez précis pour être utilisés pour l'évaluation des performances.
Quand la destination d´un paquet est le routeur lui-même, ce paquet doit être commuté par processus. Le processeur doit gérer les renseignements de ce paquet et renvoyer une réponse. Ce n'est pas l'objectif principal d'un routeur. Par définition, un routeur est construit pour router des paquets. Une réponse au message ping est offerte dans le cadre du service du meilleur effort.
Pour illustrer cette situation, voici un exemple de message ping envoyé du routeur 1 au routeur 2 :
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Le RTT est approximativement quatre millisecondes. Après avoir activé certaines fonctionnalités à processus intensifs sur Router2, essayez d´envoyer un ping de Router1 à Router2.
Router1#ping 172.16.0.12 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
Le RTT a considérablement augmenté ici. Le routeur 2 est très occupé, et la priorité n’est pas de répondre au message ping. Une meilleure façon de tester la performance d’un routeur est d’utiliser le trafic qui circule par ce routeur.
Trafic passant par le routeur
Le trafic est ensuite commuté rapidement et géré par le routeur ayant la plus haute priorité. Le réseau de base l’illustre :
Réseau de base avec 3 routeurs
Envoyez un message ping au routeur 3 à partir du routeur 1 :
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Le trafic passe par le routeur 2 et est maintenant à commutation rapide. Activez la fonctionnalité à processus intensif sur le routeur 2 :
Router1#ping 10.0.3.23 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Il n'y a presque aucune différence. C'est parce que, sur Router2, les packets sont maintenant traités au niveau de priorité d'interruption.
Utilisez la commande Debug
Avant d'utiliser les commandes debug , référez-vous à la section Informations importantes sur les commandes Debug.
Les différentes commandes debug utilisées dans cet article montrent ce qui se passe lorsqu’une commande Ping ou Traceroute est utilisée. Ces commandes peuvent vous aider à résoudre des problèmes. Toutefois, dans un environnement de production, les commandes debug doivent être utilisées avec prudence. Si votre CPU n'est pas puissant, ou si vous avez beaucoup de paquets à commutation par processus, elles peuvent facilement caler votre périphérique. Il y a quelques façons de réduire au minimum l'incidence de la commande Debug sur le routeur. Une façon est d'employer les listes d'accès pour se concentrer sur le trafic spécifique que vous voulez surveiller.
Voici un exemple :
Router4#debug ip packet ?
<1-199> Access list
<1300-2699> Access list (expanded range)
detail Print more debugging detail
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34
Router4(config)#^Z
Router4#debug ip packet 150
IP packet debugging is on for access list 150
Router4#show debug
Generic IP:
IP packet debugging is on for access list 150
Router4#show access-list
Extended IP access list 150
permit ip host 172.16.12.1 host 172.16.4.34 (5 matches)
Avec cette configuration, Router4 imprime seulement le message de débogage qui apparie la liste d'accès 150. Un message ping reçu du routeur 1 fera apparaître le message suivant :
Router4# Jan 20 16:51:16.911: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.003: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.095: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.187: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:51:17.279: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3
La réponse au problème ne vient pas du routeur 4, car ces paquets ne correspondent pas à la liste d’accès. Pour les afficher, ajoutez :
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1
Résultats :
Jan 20 16:53:16.527: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.531: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.627: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.635: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.727: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.731: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.823: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.827: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending Jan 20 16:53:16.919: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, rcvd 3 Jan 20 16:53:16.923: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100, sending
Un autre moyen de réduire l’incidence de la commande debug est de mettre les messages de débogage en mémoire tampon et de les afficher avec la commande show log une fois le débogage désactivé :
Router4#configure terminal
Router4(config)#no logging console
Router4(config)#logging buffered 5000
Router4(config)#^Z
Router4#debug ip packet
IP packet debugging is on
Router4#ping 172.16.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms
Router4#undebug all
All possible debugging has been turned off
Router4#show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 61 messages logged
Trap logging: level informational, 59 message lines logged
Log Buffer (5000 bytes):
Jan 20 16:55:46.587: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:55:46.679: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Les commandes ping et traceroute sont des utilitaires pratiques que vous pouvez utiliser pour régler les problèmes d’accès au réseau. Elles sont également très faciles à utiliser. Ces deux commandes sont les plus utilisées par les ingénieurs réseau.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
04-Oct-2022 |
Recertification |
1.0 |
10-Dec-2001 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)