Lire un traceroute : pourquoi la perte au saut 5 ne veut presque jamais rien dire

Un site paraît lent, quelqu'un lance un traceroute, et voilà : 40 pour cent de perte au saut 5. Cela ressemble à la réponse. Ce n'en est presque jamais une, et agir là-dessus envoie chercher la panne sur un routeur qui fonctionne parfaitement.

Le traceroute est un outil réellement utile bâti sur une astuce, et c'est cette astuce qui rend sa sortie si facile à mal lire.

Ce que fait vraiment un traceroute

Il envoie des paquets avec un TTL volontairement petit. Le premier routeur le décrémente à zéro, abandonne et renvoie un message ICMP Time Exceeded. C'est par cette réponse que vous apprenez que le routeur existe. Un TTL de 2 donne le deuxième, et ainsi de suite jusqu'à la destination.

Chaque ligne sauf la dernière ne mesure donc pas votre trafic. Elle mesure la vitesse à laquelle un routeur a bien voulu produire un message d'erreur à propos de votre trafic. Ce sont deux choses distinctes, et les routeurs les traitent différemment.

Pourquoi les sauts du milieu mentent

Produire des réponses ICMP n'est pas le métier d'un routeur. L'acheminement se fait en matériel ; répondre à un TTL expiré revient au plan de contrôle, un processeur bien plus modeste avec des tâches plus urgentes. La plupart des routeurs limitent le débit de ces réponses, certains les jettent purement et simplement.

D'où un saut affichant 40 pour cent de perte tout en laissant passer 100 pour cent du trafic. Deux règles en découlent, et elles règlent sur-le-champ la plupart de ces tickets :

Une perte qui ne se prolonge pas jusqu'au bout n'est pas une perte. Si le saut 5 affiche quarante pour cent et que les sauts 6 à 12 affichent zéro, rien n'a été perdu. Le saut 5 n'a simplement pas voulu répondre.
Seule la dernière ligne compte. Une perte à la destination, durable, est réelle. C'est ce chiffre qui mérite une escalade.

Un saut à forte latence se comporte pareil. Un routeur qui répond lentement à son propre ICMP n'achemine pas forcément lentement.

La moitié que vous ne voyez pas

Un traceroute montre l'aller. Il ne dit rien du retour, et les deux diffèrent souvent : vos paquets sortent peut-être par un opérateur de transit et les réponses reviennent par un autre. Sur internet c'est normal, ce n'est pas une panne.

Cela compte parce que le problème recherché peut se trouver entièrement sur le chemin de retour, que votre traceroute ne voit pas du tout. C'est pourquoi une trace unidirectionnelle amène souvent le support à demander davantage plutôt qu'à réparer : la moitié des preuves manque.

Pour la même raison, la correction se trouve parfois dans un réseau qui n'est ni le vôtre ni le nôtre. Quand on exploite son propre AS et ses sessions BGP, le chemin de retour du trafic peut être ajusté en amont, et pas seulement expliqué.

Utilisez plutôt mtr

mtr, c'est traceroute et ping réunis. Il émet en continu, vous voyez donc la perte en pourcentage dans la durée au lieu de deviner sur trois sondes :

mtr -rwzbc 200 dcxv.com

-r mode rapport, affiche une fois puis se termine
-w sortie large, pour que les noms longs ne soient pas tronqués
-z affiche le numéro d'AS de chaque saut, donc à qui appartient le réseau
-b affiche nom et IP en même temps
-c 200 envoie 200 sondes, car 10 ne disent rien d'une perte intermittente

Sous Windows, WinMTR fait le même travail. Laissez-le tourner deux ou trois minutes avant d'y lire quoi que ce soit.

Quoi envoyer au support

La chose la plus utile à joindre, c'est mtr dans les deux sens : un depuis votre machine vers le serveur et un depuis le serveur vers votre adresse, pris au même moment. Cette paire transforme une supposition à sens unique en un élément attribuable à un réseau précis.

Joignez l'IP de destination, votre propre adresse publique, l'heure avec le fuseau, et si c'est permanent ou intermittent. Si c'est intermittent, dites quand. Une perte intermittente au rythme journalier signale en général une congestion quelque part, et connaître l'heure restreint vite le champ.

Ce qui n'aide pas : une capture d'un seul traceroute avec un rond rouge autour d'un saut intermédiaire. C'est la pièce jointe la plus fréquente et la moins exploitable.

En résumé

Lisez la dernière ligne, pas celles du milieu. Une perte qui ne tient pas jusqu'à la destination, c'est un routeur qui refuse de répondre, pas un réseau qui jette votre trafic. Quand quelque chose ne va vraiment pas, mtr dans les deux sens transforme une plainte en un rapport exploitable.

Serveurs cloud et dédiés en Tchéquie et au Portugal, sur notre propre réseau AS204057 : dcxv.com/data-center#cloud