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