Qué es MTR y cómo diagnosticar conexiones
Autor: Redacción Domeny.ForSale Publicado
En resumen: MTR, o My Traceroute, es una herramienta de diagnóstico de red que combina el análisis de la ruta de los paquetes con mediciones repetidas de la latencia y de las respuestas no recibidas. En Linux ayuda a determinar si un problema de conexión se produce en la red local o más adelante, en el camino hacia el servidor. La regla más importante al interpretar los resultados es esta: que un router no responda no significa necesariamente que esté perdiendo el tráfico dirigido al destino.
Cómo funciona MTR y en qué se diferencia de ping
ping comprueba si el host indicado responde y mide cuánto tarda en llegar la respuesta. traceroute muestra los sucesivos nodos de la ruta hacia el destino. MTR combina ambas funciones: detecta la ruta y envía sondas repetidamente, actualizando los resultados de cada nodo.
Un nodo, también llamado salto o hop, suele ser un router que reenvía los paquetes. MTR detecta estos dispositivos aumentando progresivamente el TTL, es decir, el límite de saltos del paquete. Cuando se agota ese límite, el router puede devolver un mensaje que permite identificar su dirección.
La medición muestra el tiempo de ida de la sonda y de vuelta de la respuesta, no solo la latencia entre dos routers vecinos. La ruta de regreso puede ser distinta de la ruta hacia el destino, por lo que el informe no siempre permite localizar el fallo con certeza.
Instalación y primera prueba en Linux
En Debian y Ubuntu, la versión de texto de la herramienta suele poder instalarse con estos comandos:
sudo apt update
sudo apt install mtr-tiny
En otras distribuciones, el paquete puede tener otro nombre; a menudo es mtr. Confírmalo en la documentación de la distribución o en el buscador de paquetes del gestor que utilices.
Para iniciar una prueba interactiva, indica una dirección IP o un nombre de host:
mtr 1.1.1.1
Los resultados se actualizarán hasta que termines la prueba, por ejemplo, pulsando q. Aquí se utiliza la dirección 1.1.1.1 para comprobar la conectividad con un destino público; si estás diagnosticando un servicio concreto, prueba ante todo su host.
Para guardar y compartir los resultados, resulta más práctico generar un informe con un número determinado de ciclos:
mtr -r -w -c 100 -n 1.1.1.1
La opción -r activa el informe, -w amplía su formato, -c 100 establece 100 ciclos de medición y -n desactiva la conversión de direcciones IP en nombres de host. Si el programa indica que no tiene permisos para enviar sondas, revisa la configuración del paquete; según la instalación, puede ser necesario ejecutarlo con sudo.
Cómo leer las columnas del informe
Cada fila describe un nodo detectado. Las columnas más útiles son:
| Columna | Significado |
|---|---|
Loss% | Porcentaje de sondas para las que no se recibió respuesta |
Snt | Número de sondas enviadas |
Last | Tiempo de la última respuesta recibida |
Avg | Tiempo medio de respuesta |
Best / Wrst | Tiempo de respuesta más corto y más largo |
StDev | Medida de la variabilidad de los tiempos de respuesta |
Los tiempos suelen expresarse en milisegundos. Un valor alto de Wrst con una media baja puede indicar un pico aislado de latencia. Un valor elevado de StDev indica que las mediciones son inestables, pero no permite determinar por sí solo la causa.
No evalúes la conexión con solo unas pocas sondas. Recoge, por ejemplo, 100 ciclos mientras se produce el problema y compáralos con una medición realizada cuando el servicio funcione correctamente.
Cuándo la falta de respuestas indica un problema
Los routers pueden limitar las respuestas de diagnóstico o darles menos prioridad que al reenvío del tráfico. Por eso, el valor de Loss% de un nodo intermedio no mide automáticamente la pérdida de paquetes del usuario.
Por ejemplo: el cuarto nodo muestra un 70% de respuestas no recibidas, pero todos los siguientes, incluido el destino, muestran un 0%. Este resultado suele indicar que el cuarto router limita sus respuestas, no que pierda el tráfico que reenvía. Al fin y al cabo, los paquetes llegan a los dispositivos posteriores.
Resulta más preocupante que, a partir de cierto punto, la falta de respuestas también aparezca en los nodos siguientes y en el destino. Es un indicio que justifica seguir investigando, no una prueba de que un router concreto sea el responsable: las diferencias de ruta, el filtrado y la forma de gestionar las sondas pueden alterar los resultados.
Interpreta las latencias del mismo modo. Si un router responde despacio y los siguientes lo hacen con rapidez, su tiempo elevado no demuestra que toda la conexión se haya ralentizado. La ausencia de respuesta, indicada con ???, tampoco implica necesariamente que la ruta esté interrumpida.
Qué comprobar si el problema afecta a una página web
Las sondas predeterminadas de MTR utilizan ICMP, un protocolo empleado, entre otras cosas, para mensajes de diagnóstico. La red puede gestionarlas de forma distinta al tráfico de una página web. Para los problemas con HTTPS, puede ser útil una prueba TCP en el puerto 443:
mtr -r -w -c 100 -n --tcp -P 443 example.com
Sustituye example.com por el host del servicio que quieras analizar. Esta prueba tampoco mide la carga de la página, la negociación TLS ni el funcionamiento de la aplicación. Por tanto, un informe MTR sin anomalías no descarta problemas con DNS, el servidor web o la base de datos.
Si el host tiene direcciones IPv4 e IPv6, puedes comparar las pruebas con las opciones -4 y -6. Al comunicar el problema al administrador, adjunta el informe, la hora de la medición con su zona horaria, el destino analizado y una descripción del síntoma. Antes de publicar los resultados, elimina las direcciones o los nombres que revelen infraestructura privada.
Consulta también: ¿Qué es ping?
Lee también
