4 conseils pour le travail en réseau

Le précieux utilitaire Ping fournit deux informations utiles : si les paquets provenant
d’une unité peuvent ou non atteindre une autre unité ; et la durée du
trajet aller-retour des paquets entre les unités. Cette simplicité donne toute sa
puissance à  l’humble ping. En effet, Ping offre bien plus qu’un simple test de
connectivité. Il vous permet de surveiller la performance du réseau, de détecter
les goulets d’étranglement, de repérer les unités mal configurées et de
vérifier les SLA (service level agreements) des fournisseurs.
Pour obtenir tout cela du Ping basique, il faut connaître quelques-unes des
options de la commande « ping ». Tout administrateur de réseau doit connaître
plusieurs de ces options :

• packet count (comptage des paquets)
• packet size (taille des paquets)
• Don’t Fragment bit (bit de non-fragmentation)
• maximum wait time (temps d’attente maximum)
• verbose output (sortie détaillée)
• source IP address (adresse IP source)
• flood generation

On spécifie généralement ces options
avec un indicateur-tiret sur la commande
ping. Par exemple :

ping -c 10 -s 1400 coyote.acme.com

Cette commande ordonne d’envoyer
10 paquets (-c 10) d’une taille de 1 400 octets
(-s 1400) à  l’hôte coyote. acme. com.
Les indicateurs d’option eux-mêmes varient
légèrement selon la plate-forme. Ici, j’utilise les indicateurs d’option
standard pour la plupart des implémentations Unix. Windows utilise des indicateurs
différents mais offre la même fonctionnalité.
Ping bénéficie généralement d’une documentation intégrée et vous pouvez
obtenir une liste rapide des indicateurs d’option en tapant ping – ? dans
une fenêtre DOS ou man ping dans Unix. Divers utilitaires ping graphiques
tierce partie donnent un accès pointer/cliquer aux options de ping et sont
généralement assortis d’un bouton d’aide. Voici un aperçu rapide des options
les plus utiles de ping.

Packet count. Cette option définit simplement le nombre
de paquets que ping enverra avant de s’arrêter. Sous Unix, le
défaut est l’infini : les pings se succèdent jusqu’à  ce que vous
les arrêtiez en appuyant sur Ctrl-C. Windows envoie quatre
pings par défaut. Les routeurs Cisco en envoient cinq. Vous
devez connaître la valeur par défaut de chaque unité que
vous utilisez pour le ping. La plupart des pings fournissent
un résumé utile après avoir envoyé le nombre de paquets
spécifiés, vous donnant le pourcentage des paquets qui ont
correctement effectué l’aller-retour, et le temps moyen de
cet aller-retour.

Paquet size. Par défaut, ping envoie des paquets courts
(généralement moins de 100 octets) pour ne pas surcharger
le réseau. Mais, parfois, il faudra solliciter fortement le réseau
pour le tester. Dans ce cas ; on augmentera la taille des paquets.
Quand vous analysez les problèmes de performances,
il est toujours judicieux d’envoyer des paquets de taille maximale
pour vérifier que les grands paquets ne sont pas perdus
pour une raison quelconque. Vous pouvez généralement aller
jusqu’à  10 000 octets environ, mais tout ce qui dépasse le
chemin Maximum Transmission Unit, ou MTU (voir « Le
monstre MTU », ci-dessous) sera fragmenté (nous y reviendrons
plus loin). A noter que la taille des paquets n’inclut pas
l’en-tête IP de 20 octets ou l’en-tête ICMP (Internet Control
Message Protocol) de 8 octets. Le paquet réel a donc 28 octets
de plus que ce que vous spécifiez. Tenez-en compte en
construisant les paquets.

Don’t Fragment bit. Cette option est l’une des plus
puissantes de ping, même si les spécialistes réseau l’oublient
souvent (s’ils l’ont jamais connue). Les paquets qui sont trop
grands pour un médium particulier, comme la taille de paquet
maximale de 1 500 octets d’Ethernet, doivent être fragmentés
avant la transmission puis, parvenus à  destination,
réassemblés pour reconstituer le paquet. Sur Internet, la
fragmentation se passe souvent mal.
L’un des bits à  l’intérieur d’un paquet est le bit Don’t
Fragment: il ordonne aux unités de ne pas scinder un paquet
trop grand mais plutôt de l’ignorer s’il ne peut pas effectuer
le voyage. L’unité qui prend la décision d’ignorer le paquet
renvoie un message ICMP à  la source : « Packet too large and
don’t fragment bit set ». L’indicateur Don’t Fragment du Ping
prescrit à  ce dernier d’activer ce bit dans chaque paquet de
test. En augmentant ou en diminuant progressivement la
taille des paquets dans une série de tests ping, vous pouvez
mettre à  l’épreuve le chemin entre deux unités, afin de
connaître les possibilités des unités intervenantes qui pourraient
être gênées par la taille de paquet utilisée par l’application
objet du dépannage.

Maximum wait time. Cette option indique le temps, généralement
en millisecondes, d’attente du ping avant de
considérer un paquet comme perdu. La valeur par défaut est
généralement de 10 000 millisecondes (10 secondes), mais
Windows a un temps d’attente par défaut beaucoup trop bas
de juste 1 000 millisecondes (une seconde) qui peut
indiquer à  tort qu’une unité est hors de portée (voir
« Le court délai d’attention du Ping Windows », ci-après). Généralement, vous n’aurez pas à  bricoler avec cette option
(sauf si vous faites un ping à  partir de Windows), mais il faut
souligner que ce ping n’attend que pendant cette durée, et
pas au-delà .

Verbose output. Par défaut, les rapports ping ne recevant
que ICMP se font l’écho des paquets, même si d’autres
genres de paquets ICMP peuvent être renvoyés
comme réponse d’une unité à  distance.
Donc, il vous faudra peut-être activer
l’option verbose output pour que ping
signale ces réponses, comme « Packet too
large and don’t fragment bit set », « Time to
live exceeded » (Durée de vie dépassée) et
« Host device unreachable » (Unité hôte
hors de portée). L’effet de cette option varie
selon la plate-forme, donc vous devez
lire la documentation ping de la vôtre.

Source IP address. Quand l’unité à  partir
de laquelle l’on teste a des interfaces réseau multiples,
cette option peut avoir de l’importance. Généralement,
l’adresse source pour faire ping de paquets est l’adresse de
l’interface sur laquelle les paquets quittent l’unité, mais ce
n’est peut-être pas ce que vous voulez. Supposons que vous
ayez un routeur avec une liaison T1 montante qui a une
adresse IP série et un port Ethernet qui a l’adresse IP de votre
LAN. Les pings envoyés à  partir du routeur reviennent toujours,
même s’il y a des problèmes de routage avec votre subnet
IP LAN, parce qu’ils ont l’IP série comme adresse source.
Pour tester vraiment le routage de votre adresse IP, il faut ordonner
à  ping d’utiliser cette adresse comme IP source dans
les paquets de test. Désormais, les échos de ping en retour
seront acheminés d’après les mêmes règles que votre
adresse subnet LAN, vous donnant un vrai test.
A noter que vous ne pouvez spécifier qu’une adresse
source qui existe sur l’unité que vous testez. Cette restriction
empêche quelqu’un d’utiliser ping pour générer une attaque
par déni de service (DoS) en utilisant des adresses source falsifiées.

Flood generation. Utilisez cette option avec précaution !
Elle fait générer à  ping des paquets de test aussi vite qu’il le
peut, sans attendre les réponses. C’est intéressant pour un
test de réseau interne, mais jugé comme comportement abusif
sur le réseau si on l’utilise avec des destinations de réseau
extérieures. L’option flood est une façon bâclée et expéditive
de générer du trafic pour tester un réseau sous la contrainte.
Mais elle est dangereuse. Si vous l’exécutez sur une boîte
Unix, avec son comptage de paquets infini par défaut, et oubliez
de l’annuler, vous avez engendré un monstre incontrôlable.

Ping à  l’ouvrage

Voici un exemple rapide d’utilisation de ping pour évaluer
la latence du réseau. Commencez par obtenir quelques
statistiques ping comme ligne de base :

C:\>ping -c 120 xxx.xxx.xxx.xxx

où « -c 120 » signifie envoyer 120 pings à  l’intervalle par
défaut d’un par seconde, et xxx.xxx.xxx.xxx est l’adresse IP
d’une unité de destination. La sortie du ping se présente
ainsi :

Reply from xxx.xxx.xxx.xxx: bytes=32 time=28ms
Reply from xxx.xxx.xxx.xxx: bytes=32 time=29ms
Reply from xxx.xxx.xxx.xxx: bytes=32 time=27ms
Reply from xxx.xxx.xxx.xxx: bytes=32 time=30ms
Reply from xxx.xxx.xxx.xxx: bytes=32 time=254ms
Reply from xxx.xxx.xxx.xxx: bytes=32 time=329ms
. . .
Reply from xxx.xxx.xxx.xxx: bytes=32 time=27ms

Ping statistics for xxx.xxx.xxx.xxx:
Packets: Sent = 120, Received = 120, Lost = 0 (0%),
Approximate round trip times in milliseconds:
Minimum = 25ms, Maximum = 329ms, Average = 48ms

Rappelons que le temps indiqué par ping est le temps
d’aller-retour (RTT, round-trip time). C’est-à -dire le temps
qu’il faut à  un paquet pour atteindre une adresse IP de destination
et revenir. La latence du paquet est la moitié du RTT.
Ping donne le détail du RTT sur chaque paquet de test puis
donne le RTT minimum, maximum et moyen à  la fin. Il note
également les éventuels paquets perdus. Dans un réseau non
surchargé, vous devriez voir zéro paquet perdu et des RTT
faibles (quelques millisecondes sur des LAN, 10 ms sur une
liaison T1, 30 ms sur un frame relay, 50 ms sur un DSL, et ainsi
de suite). Dans l’exemple ci-dessus, on notera que deux des
RTT sont très hauts : 254 ms et 329 ms. Cela signifie que pendant
deux secondes, la congestion a retardé quelques paquets
10 fois plus longtemps que la normale. Un tel délai
pourrait causer des problèmes d’application (un FTP -File
Transfer Protocol- lent) parce que les applications TCP/IP
peuvent n’attendre que quelques centaines de millisecondes
avant de considérer qu’un paquet est manquant.
Une haute latence peut être due à  des circonstances
étrangères au réseau, comme un routeur Internet ou un réseau
ISP surchargés, ou intérieures au réseau, comme un serveur
occupé ou une liaison Ethernet défaillante. En envoyant
trop de trafic sur une liaison particulière, on accroît la latence
car les unités mettent les paquets en buffer pour les garder
en vue d’une livraison différée.
Tenez compte qu’un paquet ping n’a pas besoin de
prendre le même chemin pour vous revenir, que celui qu’il a
pris vers l’unité de destination. Ce genre de routage asymétrique
est courant sur Internet. Des outils de tracé de route,
comme la commande « traceroute », n’enregistrent que le
chemin qu’un paquet emprunte dans son voyage sortant.
Pour trouver le chemin de retour, vous devez exécuter une
traceroute à  partir de l’unité de destination. Cependant, munis
de traceroutes dans les deux directions, vous pouvez utiliser
des pings progressifs pour trouver la cause d’une latence
excessive.