Trucs & Astuces iSeries : DNS, TCP/IP

Q : Nous utilisons plusieurs serveurs
Sun sur un site en colocation, et
ils communiquent entre eux par
l’intermédiaire d’un commutateur
100 Mbps Ethernet unique.
Dernièrement, les communications
entre les serveurs (mais pas
avec Internet) sont devenues très
lentes. Parfois, les sessions de
sauvegarde ne parviennent pas à 
s’initier, les sessions d’administration
à  distance mettent du
temps à  démarrer et nous ne parvenons
pas à  échanger des pings
entre les serveurs dans de bonnes
conditions. En fait, la performance
ping vers Internet est complètement
normale, alors que le
ping d’un serveur à  un autre,
produit le résultat bizarre suivant
:

ping -s xxx.xxx.xxx.33
PING xxx.xxx.xxx.33: 56 data bytes
…icmp_seq=0. time=1. ms

…icmp_seq=0. time=40000. ms
…icmp_seq=1. time=39000. ms
…icmp_seq=2. time=38000. ms
[36 lignes similaires]:
…icmp_seq=40. time=1000. ms

…icmp_seq=41. time=0. ms
…icmp_seq=42. time=0. ms

Nous constatons le même comportement
en faisant des pings
entre deux serveurs quelconques
sur le site en colocation. Le premier
ping retourne toujours immédiatement,
mais après il y a
un délai de 40 secondes pour les
réponses suivantes, jusqu’à  ce
que le temps descende parfois à 
zéro. En recommençant le ping,
on obtient exactement le même
résultat ! Au secours !

Votre problème est certes déroutant
mais, heureusement, sa cause est
simple. Avant que je ne la dévoile,
réfléchissez d’abord à  la manière dont
le ping fonctionne en mode par défaut.
L’utilitaire envoie un paquet à  l’appareil
distant et attend une réponse.
Quand il la reçoit, le ping imprime une
ligne montrant le temps d’aller-retour
mesuré. Mais certains utilitaires ping
en font davantage. Le ping Sun Solaris
(Unix), en particulier, fait du zèle et recherche
le nom correspondant à 
l’adresse IP de l’hôte répondant au
ping. Ensuite, il imprime ce nom sur
les lignes suivantes, jugeant que c’est
un renseignement supplémentaire
intéressant.
Et c’est précisément ce processus
de recherche du nom qui cause votre
problème. Quelque chose s’est détraqué
dans la base de données DNS
inversée de votre fournisseur, provoquant
le timeout des requêtes DNS
pour vos adresses. Le processus
de sortie de l’utilitaire ping attend patiemment, avec l’horloge du temps
d’aller-retour fonctionnant pendant 30
secondes environ, que la consultation
DNS inversé, aille à  son terme. Entre
temps, un processus ping séparé continue
à  envoyer et à  recevoir des requêtes
et des réponses ping. Quand la
consultation DNS échoue, ping calcule
et émet tous les résultats de ping accumulés,
mais il utilise l’heure courante
dans ses calculs, ce qui explique les
longs temps de ping que vous constatez.
La défaillance de DNS inversé n’affecte
pas simplement le ping, c’est
aussi la cause de tous les autres problèmes
de performances. Quand un
serveur reçoit une requête de connexion
TCP/IP, il essaie d’examiner le
nom associé à  l’adresse du demandeur.
Si cette consultation dure trop longtemps,
la connexion peut se voir interdire
de continuer pour des raisons de
sécurité. Les services Mail, FTP et de
partage de fichiers se comportent
souvent ainsi.
Un test facile consiste à  exécuter le
programme nslookup sur un serveur, à 
lui transmettre l’adresse IP d’un serveur
partenaire comme seul argument.
Si le nslookup se bloque, le problème
est confirmé. Le remède est simple et
direct : contactez votre fournisseur de
service en colocation, qui fournit probablement
le service DNS inversé pour
vos adresses IP et demandez-lui
de configurer correctement le DNS
inversé pour vos adresses IP.