Comprendre les commandes ping et traceroute

Options de téléchargement

  • PDF     (376.8 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (126.4 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (266.0 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:4 octobre 2022
ID du document:12778

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit l'utilisation des commandes ping et traceroute sur les routeurs Cisco.

    Conditions préalables

    Exigences

    There are no specific requirements for this 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

    Note: Toute commande debug utilisée sur un routeur de production peut causer de sérieux problèmes. Lisez la section Utiliser la commande de débogage avant d'émettre des commandes de débogage.

    Dans ce document, cette configuration de base est utilisée pour des exemples dans cet article :

    Basic Configuration of IPs and RoutersConfiguration de base des adresses IP et des routeurs

    La commande ping

    La commande ping est une méthode très courante utilisée pour dépanner l'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.

    • Délai aller-retour utilisé pour communiquer 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.

    Cet exemple de code suivant montre la commande ping après l'activation de la commande debug ip packet detail.

    Avertissement : Lorsque la commande debug ip packet detail est utilisée sur un routeur de production, elle peut entraîner une utilisation élevée du CPU. Cela peut entraîner une grave dégradation des performances ou une panne du réseau.

    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 inaccessible 0 = réseau inaccessible 1 = hôte inaccessible 2 = protocole inaccessible 3 = port inaccessible 4 = fragmentation nécessaire et ensemble DF 5 = échec de la route source
    4 extinction de la source
    5 code de redirection 0 = datagrammes de redirection pour le réseau 1 = datagrammes de redirection pour l’hôte 2 = datagrammes de redirection pour le type de service et réseau 3 = datagrammes de redirection pour le type de service et l’hôte
    6 adresse alternative
    8 rappeler
    9 routeur-annonce
    10 routeur-sollicitation
    11 temps dépassé code 0 = temps de vie dépassé en transit 1 = temps de réassemblage de 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 de la fonction Ping

    Caractère Description
    ! Chaque point d'exclamation indique la réception d'une réponse.
    . Chaque point indique que le serveur réseau a dépassé le délai imparti en attendant une réponse.
    U Une erreur PDU de destination inaccessible a été reçue.
    Q  Épuisement de la source (destination trop occupée).
    M N'a pas pu fragmenter.
    ? Type de paquet inconnu.
    & Durée de vie du paquet dépassée.

    Impossible d'envoyer une requête ping

    Si vous ne parvenez pas à envoyer une requête ping à une adresse IP, tenez compte des causes répertoriées dans cette section.

    Problème de routeur

    Voici des exemples de tentatives ping infructueuses qui peuvent déterminer le problème et ce qu'il faut faire pour le résoudre. Cet exemple est illustré avec le schéma de topologie réseau suivant :

    Router IssuesProblè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 une requête ping à Router4 depuis Router1 :

    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

    Avertissement : Lorsque la commande debug ip packet est utilisée sur un routeur de production, elle peut entraîner une utilisation élevée du CPU. Cela peut entraîner une grave dégradation des performances ou une panne du réseau. 

    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)

    Étant donné qu’aucun protocole de routage n’est exécuté sur le routeur 1, celui-ci ne sait pas où envoyer son paquet et génère un message « unrouteable ».

    Ajoutez une route statique à Router1 :

    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 Router2 :

    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 envoyé correctement ses paquets au routeur 2, mais le routeur 2 ne sait pas comment accéder à l’adresse 172.16.4.34. Le routeur 2 renvoie un message « inaccessible ICMP » au routeur 1.

    Activez le protocole RIP (Routing 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 ce dernier ne répond pas.

    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 à 172.16.12.1, mais comme il n’a pas de route vers ce réseau, il échoue.

    Ajoutez une route statique au routeur 4 :

    Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0

    Les deux parties peuvent désormais accéder l'une à l'autre :

    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 dans laquelle l’interface ne fonctionne plus. Dans l'exemple suivant, vous tentez d'envoyer une requête ping à Router4 à partir de Router1 :

    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, effectuez un dépannage étape par étape du problème. Essayez d’envoyer une requête ping à 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 = 4/4/4 ms

    Dans l’exemple précédent, le problème se situe entre Router2 et Router3. Il est possible que l’interface série sur Router3 ait é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

    C'est simple à corriger :

    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 Router4 via 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 une requête ping à Router4 :

    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 deny all implicite. 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 « administrativement interdit inaccessible » à 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, il s'agit de la connexion Ethernet :

    Address Resolution Protocol IssueProblème de protocole de résolution d'adresse

    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 requête ping ne fonctionne pas en raison du message « encapsulation failed ». Cela signifie que le routeur sait sur quelle interface il doit envoyer le paquet mais ne sait pas comment le faire. Dans ce cas, vous devez comprendre le fonctionnement du protocole ARP (Address Resolution Protocol).

    Le protocole ARP est utilisé pour mapper l’adresse de couche 2 (adresse MAC) à une adresse de couche 3 (adresse IP). Vous pouvez vérifier ceci avec 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 « encapsulation failed », mais cette fois, activez 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)

    Le résultat précédent 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 recherche l’adresse MAC de destination 172.16.100.5. Comme il ne connaît pas l’adresse MAC alors que le protocole ARP est demandé dans cet exemple, il utilise 0000.000.000 comme espace réservé dans les trames de diffusion envoyées à partir de l’interface Ethernet 0 et demande quelle adresse MAC correspond à 172.16.100.5. S’il n’y a pas de réponse, l’adresse MAC correspond à l'adresse IP dans le résultat de la commande show arp est marqué comme incomplet :

    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 figure pas dans la table ARP, la requête ping échoue en raison de l’échec de l’encapsulation.

    Retard

    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 cette valeur par défaut avec une requête ping étendue :

    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 étendue, consultez Comprendre les commandes ping étendue et traceroute étendue .

    Dans l'exemple précédent, lorsque le délai d'attente a été augmenté, la requête ping a réussi.

    Note: Le temps moyen de l´aller-retour est plus que deux secondes.

    Adresse source correcte

    Cet exemple est un scénario courant :

    Correct Source AddressAdresse source correcte

    Ajoutez une interface LAN sur Router1 :

    Router1(config)#interface ethernet0
Router1(config-if)#ip address 10.0.0.1 255.255.255.0

    À partir d’une station du réseau local, vous pouvez envoyer une requête ping à Router1. À partir de Router1, vous pouvez envoyer une requête ping à Router2. Cependant, à partir d’une station du réseau local, vous ne pouvez pas envoyer de requête ping à 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 sait pas comment le traiter.

    Router1#debug ip packet
IP packet debugging is on

    Avertissement : Lorsque la commande debug ip packet est utilisée sur un routeur de production, elle peut entraîner une utilisation élevée du CPU. Cela peut entraîner une grave dégradation des performances ou une panne du réseau.

    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 à partir du réseau local, vous devez utiliser une requête ping étendue :

    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 elle ne fonctionne pas. Les paquets sont envoyés mais aucune réponse n'est reçue. Pour résoudre ce problème, ajoutez une route vers 10.0.0.0 dans Router2. La règle de base est que le périphérique ayant reçu une requête ping doit également savoir comment envoyer la réponse à la source de la requête 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 active et que vous ne puissiez pas envoyer de requête ping au périphérique en raison de pertes importantes de la file d'attente. Vous pouvez vérifier les abandons d'entrée avec 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. Référez-vous à Dépanner les pertes de file d'attente d'entrée et de sortie pour dépanner les pertes de file d'attente d'entrée/sortie.

    La commande traceroute

    La commande traceroute est utilisée pour découvrir les routes que les paquets empruntent réellement lorsqu'ils se rendent à 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 de 1 du TTL provoque un « délai expiré » du datagramme dès qu'il atteint le premier routeur dans le chemin ; ce routeur répond alors par un message ICMP de dépassement de délai (TEM) 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 réellement l’autre destination. Puisque ces datagrammes tentent d'accéder à un port non valide sur l'hôte de destination, les messages d'inaccessibilité de port ICMP sont retournés, et indiquent un port inaccessible ; cet événement signale au programme Traceroute qu'il est 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 un TTL=1. Le premier routeur, dans ce cas Router2 (172.16.0.12), abandonne 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 un TTL=3, le routeur 4 est finalement 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 apparaître dans le résultat 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 inaccessible
    n Réseau inaccessible
    P Protocole inaccessible
    T Délai
    ? Type de paquet inconnu.

    Performances

    Vous pouvez obtenir le temps de parcours aller-retour (RTT) avec les commandes ping et traceroute. Il s’agit du temps nécessaire pour envoyer un paquet d’écho et obtenir une réponse. Cela peut fournir 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 traiter les informations 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 requête ping avec réponse est proposée dans le cadre du service au mieux.

    Pour illustrer ceci, voici un exemple de requête ping du routeur 1 vers le 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é est de ne pas répondre à la requête ping. Un meilleur moyen de tester les performances d’un routeur est d’utiliser le trafic qui passe par le routeur.

    Traffic Through the RouterTrafic via le routeur

    Le trafic est alors commuté rapidement et géré par le routeur ayant la priorité la plus élevée. Le réseau de base illustre ceci :

    Basic Network with 3 RoutersRouteurs réseau 3 de base

    Envoyez une requête ping à Router3 depuis Router1 :

    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 désormais à commutation rapide. Activez la fonction de traitement intensif sur Router2 :

    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 quand une commande ping ou traceroute est utilisée. Ces commandes peuvent vous aider à résoudre des problèmes. Cependant, dans un environnement de production, les débogages doivent être utilisés 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 uniquement le message de débogage qui correspond à la liste de contrôle d’accès 150. Une requête ping envoyée par Router1 entraîne l’affichage de ce message :

    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 provient pas du routeur 4, car ces paquets ne correspondent pas à la liste de contrôle 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

    Une autre façon de réduire l'impact de la commande debug est de mettre en mémoire tampon les messages de débogage et de les afficher avec la commande show log une fois que le débogage a été 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 utiles que vous pouvez utiliser pour résoudre des problèmes d'accès au réseau. Elles sont également très faciles à utiliser. Ces deux commandes sont largement 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
    TAC Authored

    Contribution d’experts de Cisco

    • Julio Jimenez
      Ingénieur TAC Cisco

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits