Leer un traceroute: por qué la pérdida en el salto 5 casi nunca significa nada
Una web va lenta, alguien lanza un traceroute y ahí está: 40 por ciento de pérdida en el salto 5. Parece la respuesta. Casi nunca lo es, y actuar en consecuencia manda a la gente a perseguir un router que funciona perfectamente.
El traceroute es una herramienta muy útil construida sobre un truco, y ese truco es lo que hace tan fácil malinterpretar su salida.
Lo que hace realmente un traceroute
Envía paquetes con un TTL deliberadamente pequeño. El primer router lo baja a cero, se rinde y devuelve un mensaje ICMP Time Exceeded. Esa respuesta es la que te dice que el router existe. Con TTL 2 aparece el segundo, y así hasta que los paquetes llegan al destino.
Así que todas las líneas menos la última no miden tu tráfico. Miden la rapidez con la que un router decidió generar un mensaje de error sobre tu tráfico. Son cosas distintas, y los routers las tratan de forma distinta.
Por qué mienten los saltos intermedios
Generar respuestas ICMP no es el trabajo de un router. Reenviar paquetes se hace en hardware; responder a un TTL agotado lo hace el plano de control, una CPU mucho más pequeña con tareas más importantes. La mayoría de los routers limita la tasa de esas respuestas y algunos las descartan directamente.
El resultado es un salto que muestra 40 por ciento de pérdida mientras deja pasar el 100 por ciento del tráfico. De ahí salen dos reglas que resuelven en el acto la mayoría de estos tickets:
- La pérdida que no continúa hasta el final no es pérdida. Si el salto 5 marca 40 por ciento y los saltos del 6 al 12 marcan cero, no se perdió nada. El salto 5 simplemente no quiso contestar.
- Solo cuenta la última línea. La pérdida en el destino, sostenida, es real. Ese es el número que merece escalarse.
Un salto con latencia alta se comporta igual. Un router que responde despacio a su propio ICMP no reenvía necesariamente despacio.
La mitad que no ves
Un traceroute muestra el camino de ida. Del camino de vuelta no dice nada, y a menudo son distintos: tus paquetes pueden salir por un proveedor de tránsito y las respuestas volver por otro. En internet eso es normal y no es una avería.
Importa porque el problema que buscas puede estar entero en el camino de vuelta, que tu traceroute no ve en absoluto. Por eso una traza en un solo sentido suele terminar con el soporte pidiendo más datos en lugar de arreglar algo: falta la mitad de las pruebas.
Por lo mismo, la solución a veces vive en una red que no es tuya ni nuestra. Cuando uno tiene su propio AS y sus sesiones BGP, cambiar por dónde vuelve el tráfico es algo que se puede ajustar aguas arriba, no solo explicar.
Usa mtr
mtr es traceroute y ping a la vez. Sigue enviando, así que ves la pérdida como porcentaje a lo largo del tiempo en vez de adivinar con tres sondas:
mtr -rwzbc 200 dcxv.com
-rmodo informe, imprime una vez y sale-wsalida ancha, para que los nombres largos no se corten-zmuestra el número de AS de cada salto, es decir de quién es esa red-bmuestra nombre e IP a la vez-c 200envía 200 sondas, porque con 10 no sabes nada de una pérdida intermitente
En Windows, WinMTR hace el mismo trabajo. Déjalo correr un par de minutos antes de sacar conclusiones.
Qué enviar al soporte
Lo más útil que puedes adjuntar es mtr en los dos sentidos: uno desde tu máquina al servidor y otro desde el servidor a tu dirección, tomados a la vez. Ese par convierte una suposición unilateral en algo que se puede atribuir a una red concreta.
Añade la IP de destino, tu propia dirección pública, la hora con su zona horaria y si es constante o va y viene. Si va y viene, di cuándo. Una pérdida intermitente con patrón diario suele ser congestión en algún punto, y saber la hora acota rápido.
Lo que no ayuda: una captura de un traceroute con un círculo rojo alrededor de un salto intermedio. Es el adjunto más habitual y el menos accionable.
En resumen
Lee la última línea, no las intermedias. La pérdida que no llega hasta el destino es un router que se niega a contestar, no una red que tira tu tráfico. Cuando algo va mal de verdad, mtr en los dos sentidos es lo que convierte una queja en un informe que se puede arreglar.
Servidores cloud y dedicados en Chequia y Portugal, en nuestra propia red AS204057: dcxv.com/data-center#cloud
