¿Qué es Traceroute y MTR?

Cada paquete que viaja por Internet atraviesa múltiples routers. Traceroute y MTR revelan esa cadena invisible. Ambas son utilidades de diagnóstico que trazan la ruta desde un dispositivo local hasta un host remoto y miden el tiempo en cada paso. Los ingenieros de red las emplean para detectar cuellos de botella, bucles de enrutamiento y pérdida de paquetes.

¿Qué es Traceroute y MTR?

Traceroute (o tracert en sistemas Windows) es una herramienta que envía paquetes de prueba a un destino y registra cada router intermedio, conocido como salto (hop), junto con el tiempo de ida y vuelta (round-trip time, RTT). El resultado es una instantánea estática de la ruta en un momento determinado.

MTR, abreviatura de My Traceroute, combina el descubrimiento de rutas de Traceroute con un monitoreo continuo similar al ping, tal como describe Cloudflare. Una vez que descubre el camino, sigue enviando sondas a cada salto de forma simultánea. Esto genera un panel en tiempo real con estadísticas de latencia, pérdida de paquetes y variabilidad. MTR se mantiene como proyecto de código abierto y su comportamiento está documentado en las páginas de manual del sistema.

Ambas herramientas comparten conceptos fundamentales. Un salto es cualquier dispositivo que reenvía tráfico. El campo TTL (Time to Live) es un contador en la cabecera IP que se decrementa en cada router. Cuando llega a cero, el router descarta el paquete y, por lo general, responde con un mensaje ICMP de "Tiempo excedido". Esa respuesta revela la dirección IP del router.

¿Cómo funcionan?

El mecanismo es sencillo. Traceroute establece el TTL inicial en 1. El primer router lo reduce a 0 y devuelve un error. Traceroute anota esa dirección y el tiempo transcurrido. Luego envía sondas con TTL 2, exponiendo el segundo salto. El proceso se repite, incrementando de uno en uno, hasta que los paquetes alcanzan el destino o se llega a un límite máximo de saltos.

MTR utiliza el mismo método basado en TTL para descubrir la ruta. Después, cambia a un modo paralelo. Envía sondas a todos los saltos al mismo tiempo y actualiza las estadísticas en tiempo real. La mayoría de las implementaciones usan ICMP por defecto, aunque ambas herramientas pueden configurarse para emplear UDP o TCP. Esto es relevante porque muchos cortafuegos bloquean ICMP pero permiten TCP en puertos comunes.

La elección del protocolo afecta los resultados. Traceroute en modo UDP envía paquetes a puertos altos para provocar una respuesta ICMP de puerto inalcanzable desde el destino. En modo TCP, la sonda imita tráfico web real, útil cuando los cortafuegos descartan ICMP pero permiten TCP por el puerto 80 o 443.

No todas las sondas reciben respuesta. Si un salto no responde dentro del tiempo de espera, la salida muestra un asterisco. Esto puede significar que el router está caído, que filtra mensajes ICMP o que está saturado. Interpretar estos huecos correctamente forma parte del análisis.

Diferencias clave entre Traceroute y MTR

Según FDC Servers, Traceroute se ejecuta una vez y termina. Captura un solo instante. MTR permanece abierto acumulando decenas o cientos de muestras. Esa persistencia permite detectar problemas intermitentes que un Traceroute aislado pasaría por alto.

Mientras Traceroute muestra tiempos puntuales de sondas individuales, MTR agrega datos de múltiples pruebas. Calcula el porcentaje de pérdida, la latencia promedio, los mejores y peores casos, y la desviación estándar. Esta profundidad facilita identificar un enlace inestable o un router de interconexión sobrecargado.

Traceroute es más ligero y rápido para una primera exploración. MTR consume más recursos pero es superior para diagnósticos profundos de calidad de ruta. En MTR se puede configurar el intervalo de sondas y el número de ciclos, mientras que Traceroute suele ser de ejecución directa. En redes que usan multipath de igual costo, Traceroute con puertos UDP variables puede exponer múltiples rutas paralelas. MTR, al usar sondas ICMP consistentes, tiende a mantenerse en un solo camino.

Cómo ejecutar Traceroute y MTR

Desde un terminal en Linux o macOS, una invocación básica de Traceroute solo requiere el destino:

traceroute -n ejemplo.com

La opción -n omite las búsquedas DNS, lo que acelera la prueba y limpia la salida. Un resultado típico se ve así:

traceroute to ejemplo.com (93.184.216.34), 30 hops max, 60 byte packets
 1  192.168.1.1  1.2 ms  1.1 ms  1.3 ms
 2  10.10.0.1  5.4 ms  5.2 ms  5.5 ms
 3  * * *
 4  93.184.216.34  15.1 ms  14.9 ms  15.2 ms

Cuando se necesita una vista continua, MTR en modo reporte genera un resumen analizable tras un número definido de ciclos:

mtr --report -n --cycles 100 ejemplo.com

Esto produce una tabla con las columnas clave:

Host                                                                 Loss% Drop Rcv  Avg  StDev  Javg 
 1. AS12345 _gateway (192.168.1.1)                                    0.0%    0 100  1.7    0.8   0.6
 2. AS12345 10.10.0.1                                                  0.0%    0 100  5.3    1.2   0.8
 3. AS3356 no-ptr (4.69.x.x)                                          0.2%    0 100 15.2    3.1   2.4
 4. AS15169 dns.google (8.8.8.8)                                       0.0%    0 100 24.8    2.5   1.9

Loss% es la pérdida, Avg la latencia media y StDev la desviación estándar. El prefijo AS identifica el operador de red del salto.

En Windows, Traceroute está disponible nativamente como tracert. MTR no viene preinstalado, pero existe WinMTR o se pueden usar herramientas en línea como Dig Trace MTR y Dig Trace Traceroute para ejecutar diagnósticos desde distintas ubicaciones globales sin instalar nada localmente. Esto resulta especialmente útil para comparar rutas desde diferentes puntos de vista geográficos.

Cuándo usar cada herramienta

Usa Traceroute para un diagnóstico rápido inicial de la ruta. Es la primera herramienta que se emplea cuando un usuario reporta lentitud para acceder a un servicio. Si la salida muestra tiempos normales, el problema probablemente no esté en el camino de red.

Los administradores de red deben solicitar siempre una captura de MTR cuando un cliente reporta problemas intermitentes. Un único Traceroute rara vez es suficiente para descartar fallos en la ruta.

Pasa a MTR si sospechas pérdida de paquetes o latencia variable. Los equipos de soporte técnico deben pedir MTR, y no solo Traceroute, a clientes que reportan cortes esporádicos. Un ISP o un punto de interconexión (peering) puede mostrarse estable en un único Traceroute pero revelar microcortes en un análisis prolongado con MTR.

En entornos empresariales o de hosting, MTR ayuda a diferenciar si un problema es local, del proveedor de tránsito o del destino final. Combinar estas herramientas con ping básico y los looking glass de proveedores ofrece una visión completa para resolver incidencias de conectividad.

Contexto en el diagnóstico de red

Traceroute y MTR no operan en un vacío. Son parte de un conjunto mayor de utilidades que incluyen ping, análisis DNS y registros BGP. Por ejemplo, si un servidor DNS no responde, Traceroute puede confirmar si el host es alcanzable o si la interrupción ocurre en un salto intermedio.

Las implementaciones modernas permiten exportar resultados de MTR en formatos como JSON o generar gráficos para automatización. Algunos paneles de hosting integran estas utilidades directamente en sus plataformas de soporte. Cuando un usuario en Madrid nota latencia anómala hacia un servidor en Barcelona, pero el centro de datos no reproduce el problema, MTR desde ambos extremos aclara si el cuello de botella está en el ISP del cliente o en un punto de interconexión.

Para la mayoría de los profesionales, la regla es simple: Traceroute para una foto fija, MTR para una película.

Entender cuándo aplicar cada una marca la diferencia entre un diagnóstico correcto y una suposición errónea.