Man page - ping6(8)

Packages contains this manual

Package:  iputils-ping
apt-get install iputils-ping

Manuals in package:
• ping6(8)
• ping(8)
• ping4(8)
Documentations in package:
• iputils-ping

Available languages:

en fr es it pl nl uk ro

Manual

PING

NOM
SYNOPSIS
DESCRIPTION
OPTIONS
ENVIRONNEMENT
DESTINATIONS IPV6 LINK-LOCAL
DÉTAILS D’UN PAQUET ICMP
PAQUETS DUPLIQUÉS ET ENDOMMAGÉS
COLLISIONS D’IDENTIFIANT
TESTER DES MOTIFS DE DONNÉES DIFFÉRENTS
DÉTAILS SUR LE TTL
BOGUES
VOIR AUSSI
HISTORIQUE
SECURITÉ
DISPONIBILITÉ
TRADUCTION

---

NOM

ping – Envoyer un ECHO_REQUEST ICMP aux hôtes du réseau

SYNOPSIS

ping [ -aAbBdCDfhHLnOqrRUvV346 ] [ -c nombre ] [ -e identifiant ] [ -F flowlabel ] [ -i intervalle ] [ -I interface ] [ -l préchargement ] [ -m marque ] [ -M pmtudisc_option ] [ -N nodeinfo_option ] [ -w échéance ] [ -W délai ] [ -p motif ] [ -Q tos ] [ -s taille_paquet ] [ -S tampon_émission ] [ -t ttl ] [ -T horodatage option ] [saut...] {destination}

DESCRIPTION

ping utilise le datagramme ECHO_REQUEST obligatoire du protocole ICMP pour obtenir une réponse ECHO_RESPONSE ICMP d’un hôte ou d’une passerelle. Les datagrammes ECHO_REQUEST (« pings ») comportent des en-têtes IP et ICMP, suivis d’une struct timeval et d’un nombre arbitraire d’octets de bourrage utilisés pour remplir le paquet.

ping fonctionne avec IPv4 et IPv6. L’utilisation explicite de l’un des deux peut être forcée en spécifiant -4 ou -6 .

ping peut également envoyer des requêtes d’information sur les nœuds IPv6 (RFC4620). Les saut s intermédiaires peuvent ne pas être autorisés, car le routage de la source IPv6 est déconseillé (RFC5095).

OPTIONS

-3

précision RTT (sans arrondir le temps du résultat).

-4

Utiliser seulement IPv4.

-6

Utiliser seulement IPv6.

-a

Ping sonore.

-A

Ping adaptatif. L’intervalle entre les paquets s’adapte au délai aller-retour ( round-trip time , RTT), afin qu’il n’y ait pas plus d’un essai sans réponse (ou plus, si le préchargement est utilisé) sur le réseau. L’intervalle par défaut est de 2 ms, pour plus d’informations voir -i . Sur les réseaux de faible RTT, ce mode est quasiment équivalent au mode inondation.

-b

Autoriser à envoyer un ping à une adresse de diffusion (broadcast).

-B

Ne pas autoriser ping à changer l’adresse source des essais. L’adresse est liée à celle sélectionnée au démarrage de ping .

-c nombre

Arrêter après avoir envoyé nombre paquets ECHO_REQUEST. Avec l’option échéance , ping attend pour nombre paquets ECHO_REPLY, jusqu’à ce que le délai expire.

-C

Appeler l’appel système connect() lors de la création de socket.

-d

Définir l’option SO_DEBUG sur le socket utilisé. Généralement, cette option de socket n’est pas utilisée par le noyau Linux.

-D

Afficher l’horodatage (temps Unix + les microsecondes comme dans gettimeofday) avant chaque ligne.

-e identifiant

Définir le champ d’identification de ECHO_REQUEST. La valeur 0 implique l’usage de socket raw (non géré par le socket de datagrammes ICMP ). La valeur du champ peut être affichée avec l’option -v .

-f

Mode inondation (flood ping). Pour chaque ECHO_REQUEST envoyé, un point (« . ») est affiché, alors que pour chaque ECHO_REPLY reçu un effacement arrière (backspace) est affiché. Cela fournit un affichage rapide de combien de paquets ont été abandonnés. S’il n’y a pas d’intervalle donné, l’intervalle est défini à zéro et ping renvoie les paquets aussi vite qu’ils reviennent ou cent fois par seconde, selon le plus rapide. Seul le superutilisateur peut utiliser cette option avec un intervalle de zéro.

-F flow label

Seulement pour IPv6. Allouer et inscrire une étiquette de flux de 20 bits (en hexadécimal) sur les paquets ECHO_REQUEST. Si la valeur est zéro, le noyau alloue une étiquette de flux aléatoire.

-h

Afficher l’aide.

-H

Forcer une résolution de nom DNS pour la sortie. Utile pour une destination numérique ou pour l’option -f qui par défaut ne fait pas de résolution de nom ; peut aider à la recherche de résolution de problèmes DNS et écrase une option -n précédemment définie. Voir aussi la variable d’environnement IPUTILS_PING_PTR_LOOKUP .

-i intervalle

Attendre intervalle secondes entre l’envoi de chaque paquet. Les nombres réels sont autorisés avec un point comme séparateur de décimales (indépendamment du réglage des paramètres régionaux). L’attente par défaut est d’une seconde entre chaque paquet ou aucune attente en mode inondation. Seul le superutilisateur peut définir l’intervalle à une valeur inférieure à 2 ms. Les ping à une adresse de diffusion et multidestinataires (multicast) ont des limites encore plus élevées pour un utilisateur ordinaire : le minimum est 1 seconde.

-I interface

L’ interface est soit une adresse, un nom d’interface ou un nom VRF. Si l’ interface est une adresse, son adresse source est définie par l’adresse de l’interface spécifiée. Si l’ interface est un nom d’interface, son interface source est définie à l’interface spécifiée. Si l’ interface est un nom VRF, chaque paquet est routé en utilisant la table de routage correspondante ; dans ce cas, l’option -I peut être répétée pour spécifier une adresse source. NOTE : Pour IPv6, lors d’un ping à une adresse de portée liaison locale, la spécification de la liaison (par la notation « % » dans destination ou par cette option) peut être utilisée, mais n’est plus nécessaire.

-l préchargement

Si préchargement est spécifié, ping envoie plusieurs paquets sans attendre de réponse. Seul le superutilisateur peut sélectionner un préchargement supérieur à trois.

-L

Enlever la boucle locale (loopback) des paquets multidestinataires (multicast). Cette option ne s’applique que si la destination du ping est une adresse multidestinataire.

-m marque

Utiliser marque pour étiqueter les paquets sortants. Cela est utile pour diverses raisons dans le noyau comme l’utilisation du routage selon la politique pour sélectionner un traitement spécifique des sorties. L’attribut CAP_NET_ADMIN ou CAP_NET_RAW (depuis Linux 5.17) est nécessaire (voir socket (7)).

-M pmtudisc_opt

Sélectionner la stratégie de découverte du chemin MTU (Path MTU Discovery). L’option pmtudisc_option peut être soit do (positionner un drapeau DF mais sujet à des vérifications de chemin MTU par le noyau, les paquets trop grands seront rejetés), soit want (faire la découverte du chemin MTU, fragmenter localement quand le paquet est grand), probe (positionner un drapeau DF et contourner les vérifications de chemin MTU, utile pour la détection) ou dont (ne pas positionner de drapeau DF).

-N nodeinfo_option

Seulement pour IPv6. Envoyer des demandes d’information de nœud IPv6 (RFC 4620), au lieu de ECHO_REQUEST. La capacité CAP_NET_RAW est requise.

help

Afficher l’aide pour la prise en charge des informations de nœud.

nom

Demander les noms de nœuds.

ipv6

Demander les adresses IPv6. Il y a plusieurs drapeaux spécifiques à IPv6.

ipv6-global

Demander les adresses global-scope IPv6.

ipv6-sitelocal

Demander les adresses site-local IPv6.

ipv6-linklocal

Demander les adresses link-local IPv6.

ipv6-all

Demander les adresses IPv6 sur les autres interfaces.

ipv4

Demander les adresses IPv4. Il y a un drapeau spécifique à IPv4.

ipv4-all

Demander les adresses IPv4 sur les autres interfaces.

subject-ipv6= ipv6addr

Adresse de sujet IPv6.

subject-ipv4= ipv4addr

Adresse de sujet IPv4.

subject-name= nom_du_nœud

Nom du sujet. S’il contient plus qu’un point (« . »), un nom de domaine pleinement qualifié est supposé.

subject-fqdn= nom_du_nœud

Nom du sujet. Un nom de domaine pleinement qualifié est toujours supposé.

-n

Sortie numérique uniquement. Aucune tentative de recherche de noms symboliques pour les adresses d’hôte ne sera faite (pas de résolution inverse de DNS). C’est le comportement par défaut pour une destination numérique ou pour l’option -f . Écrase une option -H précédemment définie. Voir aussi la variable d’environnement IPUTILS_PING_PTR_LOOKUP .

-O

Rapporter la réponse ICMP ECHO en suspens avant d’envoyer le paquet suivant. Cela est utile avec l’horodatage -D pour enregistrer la sortie dans un fichier de diagnostic et rechercher les réponses manquantes.

-p motif

Vous pouvez spécifier jusqu’à 16 octets de « pad » pour remplir le paquet que vous envoyez. Cela est utile pour diagnostiquer les problèmes dépendant des données dans un réseau. Par exemple, -p ff fera en sorte que le paquet envoyé soit rempli avec des 1.

-q

Sortie silencieuse. Rien n’est affiché à part les lignes de résumé au démarrage et à la fin de l’exécution.

-Q tos

Définir la qualité de service, relative aux bits dans les datagrammes ICMP. tos peut être un nombre décimal ( ping seulement) ou hexadécimal.

Dans la RFC2474, ces champs sont interprétés comme un champ de 8 bits destiné aux services différenciés (Differentiated Services, DS), constitué des bits 0-1 (les deux bits les plus faibles) de données indépendantes, et des bits 2-7 (les six bits les plus forts) du Differentiated Services Codepoint (DSCP). Dans les RFC2481 et RFC3168, les bits 0-1 sont utilisés pour l’ECN (NdT : Explicit Congestion Notification, notification explicite de congestion).

Historiquement (la RFC1349, rendue obsolète par la RFC2474), l’interprétation était la suivante : le bit 0 (bit le plus faible) est réservé (actuellement en cours de redéfinition pour le contrôle de congestion), 1-4 pour le type de service (Type of Service, ToS), et les bits 5-7 (bits les plus forts) pour la Priorité.

-r

Ne pas utiliser les tables de routage normales et envoyer les paquets directement à un hôte présent sur une interface directement connectée. Si l’hôte n’est pas situé dans un réseau directement connecté, une erreur est renvoyée. Cette option peut être utilisée pour envoyer un ping à un hôte local au travers d’une interface ne faisant partie d’aucune route à condition que l’option -I soit également utilisée.

-R

ping seulement. Enregistrer la route. Inclut l’option RECORD_ROUTE dans le paquet ECHO_REQUEST et affiche le tampon de la route dans les paquets renvoyés. Notez que l’en-tête IP ne peut contenir au plus que neuf de ces routes. Beaucoup d’hôtes ignorent ou désactivent cette option.

-s taille_paquet

Spécifier le nombre d’octets de données à envoyer. Le nombre par défaut est 56 , ce qui se traduit en 64 octets de données ICMP quand ils sont combinés avec les 8 octets de données de l’en-tête ICMP. La valeur maximale autorisée pour IPv4 est 65507 ( 65467 avec -R ou -T ou des saut s intermédiaires) ou 65527 pour IPv6, mais la plupart des systèmes limitent cette taille à une valeur plus basse en fonction du système.

-S tampon_émission

Définir le tampon d’émission du socket. S’il n’est pas spécifié, il n’est pas mis en mémoire tampon plus d’un paquet.

-t ttl

ping seulement. Spécifier le champ IP Time to Live.

-T horodatage option

Définir les options d’horodatage d’IP spéciales. horodatage option peut être soit tsonly (seulement les horodatages), tsandaddr (horodatages et adresses) ou tsprespec hôte1 [hôte2 [hôte3 [hôte4]]] (sauts prédéterminés d’horodatage).

-U

Afficher le temps de latence total utilisateur-à-utilisateur (l’ancien comportement). Normalement ping affiche le RTT (round trip time) du réseau, qui peut être différent par exemple à cause d’échecs du DNS.

-v

Sortie loquace. Ne pas supprimer les réponses DUP (paquets dupliqués) lors de l’envoi d’un ping sur une adresse multidestinataire.

-V

Afficher la version et quitter.

-w échéance

Spécifier un délai, en secondes, avant que ping ne quitte indépendamment de combien de paquets ont été envoyés ou reçus. Dans ce cas ping ne stoppe pas après que nombre paquets ont été envoyés, il attend soit que l’ échéance expire ou que nombre essais aient reçu une réponse, ou encore qu’une notification d’erreur provienne du réseau.

-W délai

Temps d’attente d’une réponse, en secondes. L’option ne concerne que le délai en l’absence d’une quelconque réponse, sinon ping attend deux RTT. Les nombres réels sont autorisés avec un point comme séparateur de décimales (indépendamment du réglage des paramètres régionaux). 0 signifie un délai infini.

Quand vous utilisez ping pour la localisation de pannes, il devrait d’abord être exécuté sur l’hôte local, pour vérifier que l’interface réseau locale est activée et fonctionne correctement. Ensuite, un ping devrait être envoyé aux hôtes et aux passerelles de plus en plus éloignés. Les délais aller-retour et les statistiques de perte de paquets sont calculés. Si des paquets dupliqués sont reçus, ils ne sont pas inclus dans le calcul des paquets perdus, bien que le temps d’aller-retour de ces paquets soit utilisé pour calculer les temps d’aller-retour minimal/moyen/maximal/écart type.

L’écart type de la population (mdev), essentiellement une moyenne de l’écart entre le RTT de chaque ping et le RTT moyen. Plus l’écart type est élevé, plus le RTT est variable (dans le temps). Avec une variabilité élevée du RTT, vous aurez des problèmes de vitesse avec les transferts de masse (ils prendront plus de temps que nécessaire à proprement parler, car la variabilité fera que l’expéditeur finira par attendre les acquittements) et vous aurez une qualité de VoIP moyenne à médiocre.

Lorsque le nombre de paquets indiqués ont été envoyés (et reçus) ou si le programme se termine avec un SIGINT, un bref résumé est affiché. Des statistiques actuelles plus courtes peuvent être obtenues sans terminer le processus en utilisant le signal SIGQUIT.

Ce programme est fait pour être utilisé dans les tests, la mesure et l’administration du réseau. À cause de la charge qu’il peut infliger au réseau, il est imprudent d’utiliser ping pendant les opérations normales ou à partir de scripts automatisés.

ENVIRONNEMENT

Par défaut, la variable d’environnement IPUTILS_PING_PTR_LOOKUP définie à 0 désactive la résolution DNS inverse (résolution PTR). Cela peut être écrasé par l’option -H ou -n .

Si ping ne reçoit aucun paquet en retour, il quittera avec le code 1 . Si un paquet est spécifié avec à la fois nombre et échéance , et que moins de paquets que nombre sont reçus au moment où l’ échéance est atteinte, ping quittera aussi avec le code 1 . Pour une autre erreur, il quittera avec le code 2 . Sinon, il quittera avec le code 0 . Cela rend possible l’utilisation du code de sortie pour savoir si un hôte est actif ou non.

DESTINATIONS IPV6 LINK-LOCAL

Pour IPv6, lorsque l’adresse de destination a une portée locale (link-local scope) et que ping utilise des sockets de datagrammes ICMP , l’interface de sortie doit être spécifiée. Lorsque ping utilise des n’est pas strictement nécessaire de spécifier l’interface de sortie, mai sockets raw , il s cela est préférable pour lever l’ambigüité lorsqu’il y a plusieurs interfaces de sortie possibles.

Il y a deux manières de spécifier l’interface de sortie :

• en utilisant la notation %

L’adresse de destination est suffixée avec % puis le nom de l’interface de sortie ou l’indice d’interface (ifIndex), par exemple :

ping fe80::5054:ff:fe70:67bc%eth0

ping fe80::5054:ff:fe70:67bc%2

• en utilisant l’option -l

Lors de l’utilisation de sockets de datagrammes ICMP , cette méthode est prise en charge depuis les versions du noyau suivantes : 5.17, 5.15.19, 5.10.96, 5.4.176, 4.19.228, 4.14.265. En outre, ce n’est pas pris en charge par la libc musl.

DÉTAILS D’UN PAQUET ICMP

Un en-tête IP sans option comporte 20 octets. Un paquet ICMP ECHO_REQUEST contient 8 octets supplémentaires d’en-tête ICMP suivis d’une quantité arbitraire de données. Quand une taille_paquet est fournie, elle indique la taille de cette partie de données supplémentaires (56 octets par défaut). Par conséquent, la quantité de données reçues à l’intérieur d’un paquet IP de type ICMP ECHO_REPLY sera toujours de 8 octets supérieure à l’espace requis par les données (l’en-tête ICMP).

Si l’espace occupé par les données est d’au moins la taille d’une struct timeval , ping utilise les huit premiers octets de cet espace pour inclure un horodatage qu’il utilise dans le calcul des délais aller-retour. Si l’espace des données est plus faible, aucun délai aller-retour n’est donné.

PAQUETS DUPLIQUÉS ET ENDOMMAGÉS

ping signalera les paquets dupliqués ou endommagés. Une duplication de paquets ne devrait jamais se produire, et semble être causée par des retransmissions inadéquates au niveau liaison. Les duplications peuvent se produire dans de nombreuses situations, et sont rarement (pour ne pas dire jamais) un bon signe, bien que la présence d’une faible proportion de paquets dupliqués ne doive pas toujours vous inquiéter.

Les paquets endommagés constituent évidemment une cause sérieuse d’alerte et indiquent souvent une panne matérielle quelque part sur le chemin du paquet ping (dans le réseau ou dans les hôtes).

COLLISIONS D’IDENTIFIANT

À la différence de TCP et d’UDP qui utilisent le port pour identifier de façon unique le destinataire pour fournir des données, ICMP utilise le champ identifiant (ID) pour l’identification. Par conséquent, si sur la même machine, au même instant, deux processus de ping utilisent le même ID, la réponse ECHO peut être adressée au mauvais destinataire. C’est un problème connu dû à la taille limitée du champ ID de 16 bits. C’est une limite ancienne du protocole qui pour le moment ne peut pas être corrigé à moins d’encoder un ID dans la charge utiles d’un paquet ping. ping affiche une erreur DIFFERENT ADDRESS et la perte de paquet est négative.

ping utilise le PID pour obtenir un numéro unique. La valeur par défaut de /proc/sys/kernel/pid_max est 32768. Sur les systèmes qui utilisent ping intensément et avec pid_max supérieur à 65535, des collisions sont inévitables.

TESTER DES MOTIFS DE DONNÉES DIFFÉRENTS

La couche (inter)réseau ne devrait jamais traiter des paquets différemment en fonction des données contenues dans la partie de données. Malheureusement, on a signalé des problèmes dépendant des données qui s’immiscent dans les réseaux et restent non détectés pendant une longue période de temps. Dans beaucoup de cas, le motif particulier qui aura des problèmes est un motif ne comportant pas suffisamment de « transitions », comme que des « un » ou que des « zéro », ou bien un motif proche de la limite (comme presque uniquement des « zéro »). Il ne suffit pas nécessairement de spécifier un motif de données ne comportant que des zéros (par exemple) sur la ligne de commandes étant donné que le motif qui entre en jeu est celui qui se trouve au niveau liaison de données, et que la relation entre ce que vous tapez et ce qui sera réellement envoyé sur le réseau par les contrôleurs peut être complexe.

Cela signifie que si vous avez un problème dépendant des données, alors vous devrez probablement effectuer beaucoup de tests pour le trouver. Si vous avez de la chance, vous pouvez trouver un fichier qui ne peut être envoyé sur votre réseau, ou qui prend beaucoup plus de temps à être transféré que d’autres fichiers de longueur similaire. Vous pouvez ensuite examiner ce fichier pour trouver des motifs répétés que vous pouvez tester en utilisant l’option -p de ping .

DÉTAILS SUR LE TTL

La valeur TTL (Time To Live, temps de vie) d’un paquet IP représente le nombre maximal de routeurs IP que ce paquet est autorisé à traverser avant d’être rejeté. Dans la pratique actuelle, vous pouvez vous attendre à ce que chaque routeur sur Internet décrémente le champ TTL d’exactement une unité.

Le champ TTL des paquets TCP peut prendre différentes valeurs. La valeur maximale de ce champ est 255 ; la valeur initiale recommandée est 64. Pour davantage d’informations, consulter la section « TCP/Lower-Level Interface » de la RFC9293.

Normalement, ping affiche la valeur TTL du paquet qu’il reçoit. Quand un système distant reçoit un paquet ping, il peut faire une de ces trois choses avec le champ TTL dans sa réponse :

• Ne pas le modifier ; c’est ce que les systèmes Unix de Berkeley faisaient avant la version Tahoe 4.3BSD. Dans ce cas, la valeur TTL du paquet reçu sera 255 moins le nombre de routeurs dans le chemin de l’aller-retour.

• Le définir à 255 ; c’est la manière actuelle de faire des systèmes Unix de Berkeley. Dans ce cas la valeur TTL dans le paquet reçu sera 255 moins le nombre de routeurs sur le chemin du système distant à l’hôte ping uant.

• Le définir à une autre valeur. Quelques machines utilisent la même valeur pour les paquets ICMP qu’elles utilisent pour les paquets TCP, par exemple 30 ou 60 . D’autres peuvent utiliser des valeurs totalement étranges.

BOGUES

• Plusieurs hôtes et passerelles ignorent l’option RECORD_ROUTE.

• La taille maximale de l’en-tête IP est trop courte pour que des options comme RECORD_ROUTE soient vraiment utiles. Cependant, il n’y a pas grand chose qui peut être fait pour cela.

• Inonder de pings n’est en général pas recommandé et inonder de pings l’adresse de diffusion générale (broadcast) ne devrait être fait que dans des circonstances très particulières.

VOIR AUSSI

ip (8), ss (8)

HISTORIQUE

La commande ping apparaît dans 4.3BSD.

La version décrite ici est sa descendance spécifique à Linux.

Avec la version s20150815, le binaire ping6 disparait. Il a été fusionné à ping . La création d’un lien symbolique nommé ping6 pointant sur ping résultera en la même fonctionnalité qu’auparavant.

SECURITÉ

ping nécessite la capacité CAP_NET_RAW pour être exécuté : 1) si le programme est utilisé pour des requêtes sans écho (voir l’option -N ) ou lorsque le champ d’identification est défini à 0 pour l’ECHO_REQUEST (voir -e ), ou 2) si le noyau ne prend pas en charge les sockets de datagrammes ICMP, ou 3) si l’utilisateur n’est pas autorisé à créer un socket d’écho ICMP. Le programme peut nécessiter d’être utilisé dans le mode set-uid superutilisateur.

DISPONIBILITÉ

ping fait partie du paquet iputils .

TRADUCTION

La traduction française de cette page de manuel a été créée par Frédéric Delanoy <delanoy_f@yahoo.com> et bubu <bubub@no-log.org>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org .

---