Comment lire la perte de paquets avant d’accuser le câble

Deux pour cent de perte sur une longue série de ping ressemble à un chiffre sur lequel on peut agir, et c’est rarement le cas. Il ne dit pas où les réponses ont disparu, si elles ont disparu ensemble, ni comment une application donnée a vécu cet intervalle. Une perte répartie uniformément sur une minute et une perte concentrée dans un seul échange produisent des résultats très différents pour le même pourcentage.

Comparez trois mesures au lieu d’en croire une seule : ce que la sonde a vu, ce que les compteurs d’interface ont fait et ce que l’application a réellement attendu.

Ce que mesure vraiment un pourcentage de ping

Une sonde d’écho teste une direction d’un protocole avec une taille de paquet, au rythme que vous avez choisi. Un tunnel qui transporte un gros envoi fait quelque chose de complètement différent, et un lien qui perd de petites sondes n’est pas forcément le lien qui pénalise le transfert. Le pourcentage écrase aussi l’information temporelle qui importe le plus, car dix réponses perdues en rafale ne sont pas la même chose que dix réponses perdues à une heure d’intervalle. Il ne peut pas non plus vous dire quel côté du tunnel a perdu quelque chose.

Gardez le résultat de la sonde comme un indice sur le chemin. Cherchez ensuite le moment et la frontière qui l’ont produit.

Comparez les écarts des compteurs, pas les totaux de vie

Prenez des relevés horodatés avant et après la fenêtre où le symptôme est apparu, aux deux extrémités et sur tout port de commutateur que vous contrôlez. Notez le volume de trafic avec les erreurs, les rejets et les changements d’état du lien, car un total non nul accumulé sur des mois décrit l’histoire et non cet incident. Un compteur qui a bougé de trois pendant l’attente est une observation différente d’un compteur qui affiche trois mille et n’a jamais changé.

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

Les paquets rejetés à cause d’erreurs de réception et les paquets rejetés pour d’autres raisons vivent dans des compteurs séparés, et cette distinction change la suite. Les compteurs d’erreurs pointent vers la couche physique ou la couche pilote, tandis que la pression des files et les rejets de politique pointent quelque part au-dessus. Conservez aussi la direction et le nom de l’interface, car une hausse des erreurs de réception sur un lien montant et un compteur de paquets de tunnel ne sont pas interchangeables.

Si un pilote expose des compteurs physiques détaillés, lisez-les dans la documentation de cet adaptateur. Attribuer un seul sens à chaque champ nommé « drop » chez deux fabricants, c’est ainsi qu’une bizarrerie comptable normale devient un diagnostic matériel.

Comment un segment perdu devient une longue attente

Une application peut attendre bien plus qu’un aller-retour après avoir perdu un segment. TCP estime le temps d’aller-retour, calcule un temporisateur de retransmission à partir de cette estimation et recule lorsqu’une retransmission échoue aussi, si bien qu’un seul segment perdu au mauvais moment peut bloquer une requête pendant un intervalle notable. Ce mécanisme est spécifié dans RFC 6298, et il explique pourquoi un taux de perte qui paraît anodin peut malgré tout se ressentir.

Toute pause n’est cependant pas un délai de retransmission. La même attente peut venir de la résolution de noms, d’un serveur lent ou d’une application qui réessaie sa propre requête après un échec. Séparez ces cas en alignant l’opération échouée avec les observations de transport et avec les événements de session du tunnel lui-même. Une interruption sur le chemin des données sans reconnexion est un événement différent d’une nouvelle poignée de main et d’un échange d’identifiants.

Là où la capture est autorisée, gardez-la étroite. Ce qu’il vous faut, c’est savoir si les paquets ou accusés attendus s’arrêtent à une frontière précise, pas le fait qu’il existe une retransmission quelque part dans une trace chargée.

Changez une frontière sans bouger les autres

Si les preuves pointent vers un lien local, remplacez un câble ou un port approuvé comme comparaison contrôlée et laissez tout le reste tranquille. Gardez l’extrémité, l’application et la charge de travail comparables, et changez exactement une frontière par essai. Comparer un portable filaire à un portable sans fil tout en changeant aussi les sorties et les protocoles ne vous dit rien que vous puissiez attribuer.

Des compteurs locaux propres ne certifient pas le reste du chemin. Ils bornent la partie que vous voyez, et le rapport honnête dit quelles frontières ont été observées et lesquelles ne l’ont pas été. Ce que vous voulez à la fin, c’est une affirmation selon laquelle une observation a changé quand une intervention a eu lieu, pas une anecdote sur un mauvais câble promue au rang de règle universelle.