Qué es MTR: cómo ejecutar y leer un informe de mtr

MTR (My Traceroute, originalmente Matt's traceroute) combina traceroute y ping. Descubre todos los routers que hay entre tú y un destino, y después sigue enviando sondas a cada uno de ellos y acumula estadísticas. Un traceroute es una sola instantánea de la ruta; un informe de mtr equivale a cien, resumidas por salto. Esta guía explica cómo instalarlo y qué opciones importan, y analiza columna por columna un informe real obtenido desde nuestros servidores.

Instalar mtr

Sistema	Instalar	Ejecutar
Debian, Ubuntu	sudo apt install mtr-tiny (solo texto) o mtr	mtr example.com
Fedora, RHEL, Rocky	sudo dnf install mtr	mtr example.com
macOS	brew install mtr	sudo mtr example.com
Windows	WinMTR, un programa aparte con columnas similares, o mtr dentro de WSL 2	Abre WinMTR e introduce el host

En macOS, Homebrew instala mtr en su carpeta sbin, que no siempre está en el PATH, y el programa necesita sudo para enviar sus sondas. Sin opciones, mtr abre una pantalla en vivo que se actualiza cada segundo (pulsa q para salir). Para todo lo que quieras conservar o enviar, usa el modo informe, que ejecuta un número fijo de ciclos e imprime el resultado una sola vez:

mtr -rwz -c 100 example.com

Las opciones que conviene conocer

Opción	Qué hace
-r	Modo informe: ejecuta y luego imprime una tabla que puedes pegar en cualquier sitio
-w	Informe ancho: nombres de host completos en lugar de truncados
-c 100	Número de sondas por salto. Con 10 echas un vistazo rápido; 100 es lo que envías a un proveedor
-z	Muestra el número de AS de cada salto, para ver dónde una red entrega el tráfico a la siguiente
-n	Sin DNS inverso: más rápido, pero pierdes los nombres de los routers, que a menudo contienen un código de ciudad
-b	Muestra a la vez el nombre y la dirección IP de cada salto
-T -P 443	Sondas TCP al puerto 443, para redes que descartan ICMP
-u	Sondas UDP en lugar de ICMP
-4, -6	Fuerza IPv4 o IPv6
-i 0.5	Segundos entre sondas (1 por defecto; solo root puede bajar de 1)
--json	Salida legible por máquina

Un informe real, leído columna por columna

Lo ejecutamos el 7 de octubre de 2026 a las 12:26 UTC desde nuestro servidor de Falkenstein, Alemania (Hetzner), hacia un host de prueba de Vultr en Nueva Jersey, con 100 sondas por salto. Solo hemos acortado el nombre de host de nuestra máquina:

$ mtr -rwz -c 100 nj-us-ping.vultr.com
HOST: falkenstein                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.0.1                           73.0%   100    0.2   0.1   0.0   0.2   0.0
  2. AS24940  ex9k1.dc11.fsn1.hetzner.com           0.0%   100    4.7   1.0   0.3  15.1   1.7
  3. AS24940  core22.fsn1.hetzner.com               0.0%   100    0.8   0.7   0.3   1.7   0.2
  4. AS24940  juniper5.dc2.nbg1.hetzner.com         0.0%   100    3.0   5.2   2.8  65.6   9.2
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
  7. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  8. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  9. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
 10. AS20473  66.55.138.149.vultrusercontent.com    2.0%   100   85.7  85.9  85.6  87.3   0.2
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

• Loss%: el porcentaje de sondas a ese salto que no obtuvieron respuesta. Aquí marca un 73 % en el salto 1 y un 2 % en el salto 10, pero un 0 % en el destino. Nada de eso es pérdida real (lo vemos más abajo).
• Snt: sondas enviadas a cada salto, aquí 100.
• Last, Avg, Best, Wrst: tiempos de ida y vuelta en milisegundos de la última sonda, la media, la más rápida y la más lenta. Best es lo más cercano a lo que la ruta permite físicamente: 85,9 ms hasta Nueva Jersey.
• StDev: cuánto varían los tiempos, es decir, el jitter. De 0,1 a 0,2 ms en la mayoría de los saltos: una ruta tranquila.
• AS (con -z): la red a la que pertenece cada dirección. Los saltos 2 a 4 son de Hetzner (AS24940), los 5 y 6 de Core-Backbone (AS201011) y los 10 y 11 de Vultr (AS20473). Es en los traspasos entre ellas donde suele aparecer la congestión, cuando la hay.
• Nombres: los nombres de los routers suelen incluir una ciudad. El salto 5 es nbg40 (Núremberg), a 3 ms, y el salto 6 es nyk10 (Nueva York), a 86,7 ms: el cruce del Atlántico, en una sola línea.

Tres cosas de ese informe que parecen un problema y no lo son

1. Pérdida en un salto, pero no en los siguientes. El salto 1 (la puerta de enlace del contenedor en el que se ejecuta la prueba) deja sin responder el 73 % de las sondas, el salto 10 el 2 %, y todos los saltos que vienen después responden a todas. Los routers responden a las sondas por software, con baja prioridad, y muchos limitan cuántas respuestas envían por segundo. El tráfico que pasa a través de ellos no se ve afectado.
2. Un salto lento seguido de otros rápidos. El salto 4 tiene una media de 5,2 ms y un peor caso de 65,6 ms, mientras que el salto 5, justo después, nunca supera los 3,3 ms. El router se tomó su tiempo para responder a algunas sondas; no retrasó los paquetes que reenviaba.
3. Saltos silenciosos. Los saltos 7 a 9 nunca responden (???, 100 %). Son routers configurados para no contestar. Como los saltos 10 y 11 sí responden, está claro que los paquetes pasan por ellos.

La regla que se deduce: una pérdida o una latencia solo cuenta si empieza en un salto y continúa hasta el destino. Si el salto 6 mostrara un 15 % de pérdida y los saltos 7 a 11 lo mismo, el problema empezaría en el salto 6 o en el enlace justo anterior. Un pico que desaparece en el salto siguiente es cosa del router, no de la ruta.

El mismo informe, lanzado en el mismo minuto hacia Singapur, muestra estos efectos con más claridad todavía: un router de Arelion en Hamburgo solo respondió al 47 % de las sondas, otro en Singapur al 18 %, con un peor tiempo de 381,6 ms, y el destino respondió al 100 % con una media de 165,5 ms.

Cuántas sondas, desde dónde y cuándo

• Con 10 sondas basta para ver la ruta. Para medir la pérdida hacen falta 100: con 10 sondas, una pérdida del 1 % aparece como 0 % la mayoría de las veces.
• Ejecútalo mientras ocurre el problema. Un mtr lanzado una hora después muestra una ruta sana y no demuestra nada.
• Ejecútalo desde más de un lugar. El mismo host de Nueva Jersey, medido en el mismo minuto desde nuestro servidor de Gravelines, Francia (OVHcloud), respondió en 71,7 ms en lugar de 86,4 ms: OVH lleva el tráfico por su propia red hasta Nueva York y se lo entrega a Vultr en el punto de intercambio NYIIX, mientras que desde Falkenstein pasa por Core-Backbone. Mismo destino, dos rutas, 15 ms de diferencia.
• No olvides la ruta de vuelta. Cada tiempo del informe es una ida y vuelta, y la vuelta puede seguir otra ruta que mtr no puede ver. Si puedes, ejecuta mtr también desde el otro extremo.

Enviar un informe de mtr a tu proveedor

• Usa mtr -rwzb -c 100: el informe, los nombres completos, los números de AS y las direcciones IP.
• Anota la fecha, la hora con su zona horaria, tu IP pública y el destino.
• Si ICMP está filtrado en algún punto de la ruta, añade -T -P 443 e indícalo.
• Señala el primer salto en el que la pérdida o la latencia empieza y se mantiene hasta el final, no el salto con la cifra más alta.

mtr, traceroute y ping

Herramienta	Qué mide	Sonda por defecto	Ideal para
ping	Tiempo de ida y vuelta y pérdida, solo hasta el destino	ICMP echo	Saber si está activo, lo rápido y lo estable que es
traceroute	La ruta, con tres sondas por salto, una sola vez	UDP en Linux y macOS, ICMP en Windows (tracert)	Ver la ruta
mtr	La ruta, con estadísticas de pérdida y latencia de cada salto	ICMP (UDP o TCP si se indica)	Problemas intermitentes, pruebas para un proveedor

En Windows sin WinMTR, el pathping integrado en el sistema hace algo parecido en dos pasadas: una traza y luego unos 25 segundos de sondas por salto. Para las diferencias entre las dos primeras herramientas, consulta traceroute vs ping; para el comando traceroute de cada sistema, el comando traceroute en Windows, Mac y Linux.

Cuando no puedes ejecutarlo tú mismo

Las redes de empresa suelen bloquear las sondas, en un teléfono no se puede ejecutar mtr y una prueba desde tu propia conexión no dice nada de la ruta desde otros lugares. TraceMapper hace la misma medición desde nuestros servidores y desde más de 30 ubicaciones, sitúa cada salto en un mapa con su latencia, su pérdida y su red, y guarda el resultado como un enlace que puedes enviar. Para encontrar dónde se degrada realmente una ruta, consulta cómo identificar cuellos de botella en la red.