Détecter la perte de paquets avec MTR et la lire correctement

Installer

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

Exécuter correctement

mtr -rwbc 200 <destination>

• -r mode rapport, pour qu'il se termine avec quelque chose à coller
• -w sortie large, pour que les noms d'hôtes longs survivent
• -b afficher le nom et l'adresse de chaque saut
• -c 200 deux cents cycles, environ trois minutes et demie, et la différence entre une preuve et une anecdote

Dix paquets ne prouvent rien du tout. Si une exécution de dix cycles montre de la perte, exécutez deux cents cycles avant de conclure quoi que ce soit.

Lire le dernier saut en premier

Les routeurs dépriorisent les paquets qui leur sont adressés. Un routeur de transit transportant des centaines de gigabits répondra à vos sondes TTL expirées quand il a un cycle de libre et les ignorera quand il n'en a pas, ce qui peint de la perte au milieu de votre rapport alors que chaque paquet qui vous intéresse vraiment arrive intact.

Deux règles couvrent la plupart des rapports :

1. Une perte au saut sept qui est absente au saut huit et au-delà est une limitation de débit. Ignorez-la.
2. Une perte qui commence au saut sept et continue jusqu'à la destination est réelle, et le saut où elle commence est l'endroit où regarder.

La latence se comporte de la même manière. Un saut qui ajoute quatre-vingts millisecondes puis transmet le trafic au saut suivant au chiffre précédent répond lentement, ne fait pas suivre lentement.

ICMP n'est pas votre trafic

Si le service fonctionne sur TCP, testez sur TCP :

mtr -rwbc 200 --tcp --port 443 <destination>

Les réseaux qui limitent fortement ICMP laissent souvent passer TCP sans le toucher. Le cas inverse vaut la peine d'être découvert avant de blâmer le réseau de qui que ce soit : un pare-feu qui répond au ping gentiment et qui bloque le port que vos utilisateurs atteignent réellement.

Les deux directions, à chaque fois

Le routage est asymétrique plus souvent qu'autrement. Le chemin de vous vers nous n'est pas le chemin de nous vers vous, et un rapport d'une extrémité décrit exactement un seul d'entre eux. Exécutez MTR depuis l'instance vers le client et depuis le client vers l'instance, puis joignez les deux. Notre moitié du chemin peut aussi être sondée sans shell nulle part, depuis le looking glass.

Corroborer avec les compteurs TCP

MTR décrit le chemin. Les statistiques de sockets décrivent la conséquence :

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Un taux de retransmission supérieur à environ un pourcent, sur une connexion qui devrait être propre, soutient le rapport. Zéro retransmission avec un MTR plein de perte signifie que vous regardez une limitation de débit et rien d'autre.

Ce qu'il faut nous envoyer

• Les deux rapports MTR, deux cents cycles, sous forme de texte plutôt que de capture d'écran
• Destination, transport et port
• Horodatages avec fuseau horaire, et si la perte est constante ou par rafales
• L'ID de l'instance

Environ la moitié de ces cas se résolvent à un saut intermédiaire limité en débit, et nous le disons dans la première réponse. Le reste, nous pouvons généralement le contourner dans l'heure : la perte dans notre propre réseau est notre problème, et la perte dans un chemin de transit est une question de déplacer votre trafic vers un autre.