|
Le protocole Internet Control Message Protocol ou ICMP est décrit dans le document RFC792 Internet Control Message Protocol. C'est un protocole de la couche réseau. Comme le protocole IPv4 ne fournit aucun service de contrôle lors de la transmission des paquets sur le réseau, le rôle du protocole ICMP est d'informer l'émetteur sur les conditions de cette transmission. Avec l'arrivée du protocole IPv6, 5 messages supplémentaires ont été ajoutés pour constituer le protocole ICMPv6. Ces 5 messages sont nécessaires à la reconnaissance du voisinage réseau IPv6 à l'aide du Neighbor Discovery Protocol. |
 |
La commande ping utilise principalement deux types de messages du protocole ICMP et fournit les informations suivantes.
-
Le nombre de routeurs traversés pour joindre la destination
-
Le temps de propagation aller retour (round-trip delay) lors de la communication avec l'hôte distant
-
Le taux de pertes de paquets pendant la communication
Il existe 18 types de messages ICMP pour IPv4. Les deux types de messages employés par la commande ping sont les suivants.
-
Le type 8 (
echo request) est émis vers l'hôte distant. -
Le type 0 (
echo reply) est émis par l'hôte distant en réponse.
Quelques autres types sont abordés dans la Section 10, « Lire et configurer les fonctions réseau du noyau Linux ».
Pour valider le bon fonctionnement des communications entre les adresses IP source et destination, on suit une séquence classique de tests :
-
adresse IP de l'interface de boucle locale :
lo -
adresse IP de la passerelle par défaut
-
adresse IP d'un hôte extérieur au réseau local
Comment savoir si un hôte distant est joignable ?
- État de la pile TCP/IP
-
Le test suivant permet de valider les communications réseau IPv4 et IPv6 pour les processus appartenant au même système.
$ping -c2 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.320 ms 64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.320 ms --- 127.0.0.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.320/0.320/0.320/0.000 ms$ping -c2 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.028 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.034 ms --- ::1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1013ms rtt min/avg/max/mdev = 0.028/0.031/0.034/0.003 ms - Test de la passerelle par défaut
-
On reprend le même test avec les adresses IPv4 et IPv6 de la passerelle par défaut.
$ping -c2 192.0.2.1 PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data. 64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.759 ms 64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.218 ms --- 192.0.2.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1030ms rtt min/avg/max/mdev = 0.218/0.488/0.759/0.271 ms$ping -c2 fe80::b8f1:b6ff:fee4:a0bd%eth0 PING fe80::b8f1:b6ff:fee4:a0bd%eth0(fe80::b8f1:b6ff:fee4:a0bd%eth0) 56 data bytes 64 bytes from fe80::b8f1:b6ff:fee4:a0bd%eth0: icmp_seq=1 ttl=64 time=0.171 ms 64 bytes from fe80::b8f1:b6ff:fee4:a0bd%eth0: icmp_seq=2 ttl=64 time=0.239 ms --- fe80::b8f1:b6ff:fee4:a0bd%eth0 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1029ms rtt min/avg/max/mdev = 0.171/0.205/0.239/0.034 ms - Tests vers des adresses extérieures au réseau local
-
$ping -c2 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8:
icmp_seq=1
ttl=39
time=23.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=39 time=22.8 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 22.801/22.921/23.041/0.120 ms
$ping -c2 2001:4860:4860::8888 PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes 64 bytes from 2001:4860:4860::8888:
icmp_seq=1
ttl=60
time=40.0 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=60 time=39.7 ms
--- 2001:4860:4860::8888 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 39.756/39.909/40.062/0.153 ms Adresse de réponse du message ICMP : destinataire du test
Numéro de séquence du message
La valeur du champ TTL d'un paquet IP correspond au nombre de routeurs traversés pour arriver à destination
Comment savoir si un hôte du réseau local est joignable avec IPv4 ?
La commande ping permet de qualifier les correspondances entre les adresses de la couche liaison de données (MAC) et les adresses de la couche réseau (IPv4 ou IPv6).
Prenons l'exemple d'une table du voisinage réseau avant et après l'émission de messages ICMP vers deux adresses IPv4.
-
Voisinage réseau avant émission des messages ICMP
$ip neigh ls 192.0.2.1 dev eth0 lladdr ba:f1:b6:e4:a0:bd STALE fe80::b8f1:b6ff:fee4:a0bd dev eth0 lladdr ba:f1:b6:e4:a0:bd router DELAY -
Lancement des questions ICMP
$ping -c2 192.0.2.30 PING 192.0.2.30 (192.0.2.30) 56(84) bytes of data. 64 bytes from 192.0.2.30: icmp_seq=1 ttl=64 time=0.868 ms 64 bytes from 192.0.2.30: icmp_seq=2 ttl=64 time=0.296 ms --- 192.0.2.30 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.296/0.582/0.868/0.286 ms$ping -c2 192.0.2.20 PING 192.0.2.20 (192.0.2.20) 56(84) bytes of data. From 192.0.2.29 icmp_seq=1 Destination Host Unreachable From 192.0.2.29 icmp_seq=2 Destination Host Unreachable --- 192.0.2.20 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1012ms -
Voisinage réseau après émission des messages ICMP
$ip neigh ls 192.0.2.1 dev eth0 lladdr ba:f1:b6:e4:a0:bd STALE 192.0.2.30 dev eth0 lladdr ba:ad:ca:fe:00:1e STALE 192.0.2.20 dev eth0 FAILED fe80::b8f1:b6ff:fee4:a0bd dev eth0 lladdr ba:f1:b6:e4:a0:bd router DELAY
L'expérience caractérise indirectement l'utilisation du
protocole ARP. Dans le cas de
l'adresse destination 192.0.2.30,
la première réponse à la requête ICMP prend un temps beaucoup plus important que
la seconde : 0.868 ms contre
0.296 ms. La différence de temps
s'explique par le recours au protocole ARP pour établir la correspondance entre
l'adresse IPv4 192.0.2.30 et son adresse MAC ba:ad:ca:fe:00:1e.
Avec l'adresse destination 192.0.2.20, le protocole ARP n'est pas parvenu à établir une
correspondance entre adresse IPv4 et adresse MAC. Les requêtes ICMP n'ont donc pas pu aboutir.
Comment obtenir la liste des voisins dans un réseau local IPv6 ?
On sait que dans un réseau IPv6, la notion de trafic de diffusion n'existe pas et que c'est le protocole Neighbor Discovery Protocol qui se charge des correspondances d'adresses. Il est possible d'émettre des messages ICMPv6 de multidiffusion pour solliciter les hôtes voisins dans un réseau local. Reprenons l'exemple de la table des voisins de la section précédente avant et après les messages de sollicitation ICMPv6.
-
Voisinage réseau avant émission des messages ICMPv6
$ip neigh ls 192.0.2.1 dev eth0 lladdr ba:f1:b6:e4:a0:bd STALE 192.0.2.30 dev eth0 lladdr ba:ad:ca:fe:00:1e STALE 192.0.2.20 dev eth0 FAILED fe80::b8f1:b6ff:fee4:a0bd dev eth0 lladdr ba:f1:b6:e4:a0:bd router DELAY -
Lancement des sollicitations de noeuds ICMPv6
$ping -c2 ff02::1%eth0 PING ff02::1%eth0(ff02::1%eth0) 56 data bytes 64 bytes from fe80::21e:c9ff:fef6:a2cd%eth0: icmp_seq=1 ttl=64 time=0.049 ms 64 bytes from fe80::b8f1:b6ff:fee4:a0bd%eth0: icmp_seq=1 ttl=64 time=0.394 ms (DUP!) 64 bytes from fe80::b8ad:caff:fefe:1e%eth0: icmp_seq=1 ttl=64 time=0.521 ms (DUP!) 64 bytes from fe80::21e:c9ff:fef6:a2cd%eth0: icmp_seq=2 ttl=64 time=0.031 ms --- ff02::1%eth0 ping statistics --- 2 packets transmitted, 2 received, +2 duplicates, 0% packet loss, time 1027ms rtt min/avg/max/mdev = 0.031/0.248/0.521/0.214 ms -
Voisinage après réception des réponses ICMPv6
$ip neigh ls 192.0.2.1 dev eth0 lladdr ba:f1:b6:e4:a0:bd STALE 192.0.2.30 dev eth0 lladdr ba:ad:ca:fe:00:1e STALE 192.0.2.20 dev eth0 FAILED fe80::b8ad:caff:fefe:1e dev eth0 lladdr ba:ad:ca:fe:00:1e STALE fe80::b8f1:b6ff:fee4:a0bd dev eth0 lladdr ba:f1:b6:e4:a0:bd router REACHABLE
La commande $ ping -c2 ff02::1%eth0
Comment savoir si un hôte est joignable en utilisant la résolution des noms de domaines ?
La commande ping est aussi utile pour savoir si la résolution des noms d'hôtes fonctionne correctement. Dans ce cas, on fait appel à un service Internet appelé Domain Name Service (DNS). Cet appel au service DNS suppose que la fonction resolver soit correctement configurée.
$ping -c2 www.nic.fr
$ping -4 -c2 www.nic.fr
|
|
Utilisation de la commande ping avec un nom d'hôte au lieu d'une adresse IPv4 ou IPv6. Par défaut, dès qu'une solution IPv6 est disponible, c'est ce protocole qui est utilisé. |
|
|
Affichage de la correspondance entre le nom de l'hôte et
l'adresse IPv6 ou
IPv4 suivant le contexte.
L'utilisation de l'option |
En cas d'échec sur la résolution des noms, il faut contrôler la configuration de la partie cliente du service des noms de domaines. Cette partie est abordée dans la section suivante.