Aller au contenu principal

ICMP, ping et traceroute

CCNA — IP Services

ICMP, ping et traceroute

Définition

ICMP (Internet Control Message Protocol) est le protocole de signalisation du réseau IP : il ne transporte pas de données utilisateur mais des messages d'erreur et de diagnostic. ICMPv4 porte les echo request/reply du ping et les time-exceeded de traceroute ; ICMPv6 hérite en plus de la Neighbor Discovery, le mécanisme qui remplace ARP.

Contexte

Le blueprint 200-301 (section connectivité de base, tools) demande d'interpréter les sorties de ping et traceroute et d'utiliser les outils de test. Points durs : le rôle de TTL/hop limit, le mécanisme qui fait exploser traceroute (Time Exceeded), les messages ICMPv6 clés (type 1 NS, 2 NA, 134 RA, 128/129 echo), et la lecture des diagnostics Cisco (!!!!! contre .....).

Détails techniques

Les messages ICMPv4 fréquents

Type Code Nom Émis quand
0 0 Echo Reply Réponse à un ping
8 0 Echo Request Ping sortant
3 0-4 Destination Unreachable Pas de route, hôte mort, port fermé (code 3), frag needed (code 4)
11 0 Time Exceeded TTL tombé à 0 (traceroute, boucle)
5 0-1 Redirect Le routeur connaît un meilleur next-hop sur le même LAN

Un ping Cisco affiche un ! par réponse reçue, un . par timeout, U si un routeur renvoie un Destination Unreachable explicite, ? pour un type inconnu. !!!!! = 5/5, parfait. ..... = cinq timeouts : silencieux, souvent un drop par ACL (pas de return ICMP), pas une preuve de panne.

La mécanique de traceroute

Traceroute envoie une série de paquets (UDP ports hauts sur Unix/Cisco, ICMP sur Windows tracert) avec TTL 1, puis 2, etc. Chaque routeur qui fait décroître le TTL à 0 répond par un ICMP Time Exceeded ; la destination finale répond par un ICMP Port Unreachable (ou Echo Reply côté tracert). La liste des répondeurs reconstitue le chemin.

R1# traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to 8.8.8.8
  1 10.0.0.2 4 msec 4 msec 4 msec
  2 192.0.2.97 12 msec 12 msec *
  3 203.0.113.6 28 msec 28 msec 28 msec
  4 * * *
  5 8.8.8.8 32 msec 30 msec 32 msec

Le saut 4 sans réponse n'est pas une panne : beaucoup d'équipements core filtrent l'envoi d'ICMP (politique, CPU protect). Un * isolé au saut 2 est un timeout sur une des trois sondes. Un chemin qui s'arrête avant la destination avec des * répétés = paquet mort quelque part, à confirmer par un ping étendu.

Le ping étendu Cisco

L'outil de diagnostic le plus demandé :

R1# ping
Protocol [ip]:
Target IP address: 192.168.20.10
Repeat count [5]: 50
Datagram size [100]: 1500
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]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep size increment from 100 to 1500 [100]:

Le sweep de tailles détecte les problèmes de PMTU/fragmentation : les paquets passent en-dessous d'une taille critique et meurent au-dessus, souvent parce qu'un DF est posé et qu'un lien intermédiaire a un MTU réduit. Set DF + taille croissante est la méthode pratique de découverte du PMTU.

ICMPv6 et Neighbor Discovery

ICMPv6 (RFC 4443) fusionne ICMPv4 et ARP. Messages à connaître :

Type Nom Rôle
1 Destination Unreachable Pas de route, rejet de trafic (code 1)
2 Packet Too Big Paquet plus grand que le MTU du lien, PMTU
3 Time Exceeded Hop limit tombé à 0 (traceroute IPv6)
128/129 Echo Request/Reply ping IPv6
133/134 Router Solicitation/Advertisement découverte des préfixes, SLAAC
135/136 Neighbor Solicitation/Advertisement résolution (remplace ARP) et DAD

Un NS cible l'adresse solicitée multicast FF02::1:FFxx:xxxx (les 24 bits de poids faible de la cible), ce qui limite la tempête à une portion du lien. Pas d'ARP en v6, pas de broadcast : la ND roule sur le multicast link-local, ce qui explique pourquoi un firewall qui bloque les ICMPv6 types 133 à 136 (RA/NS/NA) et 1 à 3 (erreurs) casse IPv6 sans toucher aux pings.

Exemple concret

Un poste Windows ne va pas sur un serveur interne mais pingue sa passerelle. tracert 10.20.30.40 depuis le poste : ligne 1 = passerelle, ligne 2 = * * *, destination jamais atteinte. Le ping étendu depuis le routeur noyau avec source 10.20.30.1 et DF posé, sweep de 100 à 1500 octets : tout passe jusqu'à 1472, puis timeouts. Diagnostic : un tunnel GRE intermédiaire avec MTU 1476 coupe les paquets au-dessus de la taille utile, et la réponse Packet Too Big est bloquée par une ACL ICMP sur le pare-feu - la PMTUD est cassée. Correction : réduire le MSS sur l'interface WAN (ou autoriser les ICMP nécessaires), pas changer le ping du poste.

Pièges fréquents

  1. Interpréter un traceroute avec trous comme une panne : les * au milieu sont normaux sur les backbone.
  2. Oublier que ..... (timeout) et UUUUU (unreachable) sont deux diagnostics différents : le premier est un drop silencieux, le second un routeur qui dit non.
  3. En IPv6, bloquer ICMP = bloquer la ND = interfaces up mais réseau mort.
  4. Un ping depuis un routeur avec mauvaise source : le paquet part, la réponse revient à une autre interface, symptôme fantôme.