Encuentra la pérdida de paquetes con MTR y léela correctamente

Instalarlo

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

Ejecutarlo correctamente

mtr -rwbc 200 <destination>

• -r modo informe, para que salga con algo que puedas pegar
• -w salida ancha, para que los nombres de host largos sobrevivan
• -b mostrar el nombre y la dirección de cada salto
• -c 200 doscientos ciclos, unos tres minutos y medio, y la diferencia entre evidencia y anécdota

Diez paquetes no prueban nada en absoluto. Si una ejecución de diez ciclos muestra pérdida, ejecuta doscientos antes de concluir nada.

Leer primero el último salto

Los enrutadores despriorizan los paquetes dirigidos a sí mismos. Un enrutador de tránsito que transporta cientos de gigabits responderá a tus sondas TTL caducadas cuando tenga un ciclo libre y las descartará cuando no, lo que pinta pérdida en medio de tu informe mientras que cada paquete que realmente te importa llega intacto.

Dos reglas cubren la mayoría de los informes:

1. Pérdida en el salto siete que está ausente en el salto ocho y más allá es un límite de tasa. Ignóralo.
2. La pérdida que comienza en el salto siete y continúa hasta el destino es real, y el salto donde comienza es dónde mirar.

La latencia se comporta de la misma manera. Un salto que añade ochenta milisegundos y luego entrega el tráfico al siguiente salto con la cifra anterior está respondiendo lentamente, no reenviando lentamente.

ICMP no es tu tráfico

Si el servicio corre sobre TCP, prueba sobre TCP:

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

Las redes que limitan ICMP duramente a menudo pasan TCP sin tocarlo. El caso inverso merece ser descubierto antes de culpar la red de nadie: un cortafuegos que responde al ping felizmente y descarta el puerto al que tus usuarios realmente llegan.

Ambas direcciones, cada vez

El enrutamiento es asimétrico más a menudo que no. El camino de ti a nosotros no es el camino de nosotros a ti, y un informe de un extremo describe exactamente uno de ellos. Ejecuta MTR desde la instancia hacia el cliente y desde el cliente hacia la instancia, y adjunta ambos. Nuestra mitad del camino también puede sondearse sin necesidad de shell, desde el looking glass.

Corroborarlo en los contadores TCP

MTR describe el camino. Las estadísticas de sockets describen la consecuencia:

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Una tasa de retransmisión por encima de un porcentaje más o menos, en una conexión que debería estar limpia, respalda el informe. Cero retransmisiones junto a un MTR lleno de pérdida significa que estás viendo un límite de tasa y nada más.

Qué enviarnos

• Ambos informes MTR, doscientos ciclos, como texto en lugar de captura de pantalla
• Destino, transporte y puerto
• Marcas de tiempo con zona horaria, y si la pérdida es constante o en ráfagas
• El ID de la instancia

Aproximadamente la mitad de estos se resuelven a un salto intermedio con límite de tasa, y lo decimos en la primera respuesta. El resto normalmente podemos redirigirlo en menos de una hora: la pérdida dentro de nuestra propia red es nuestro problema, y la pérdida en una ruta de tránsito es cuestión de mover tu tráfico a otra diferente.