mtr y traceroute: diagnóstico de red paso a paso en Linux 2026

Cuando algo “anda lento” en la red, lo primero que tirás es un ping. Lo segundo debería ser mtr. Te explico por qué y cómo leer cada columna.

---

Por qué necesitas más que un ping

El ping te dice si hay conectividad y cuánto tarda. Pero cuando algo está lento, no te dice dónde se rompe. traceroute te muestra cada salto, y mtr lo combina con ping para darte estadísticas en tiempo real de cada router intermedio.

En la práctica, cuando un usuario me dice “la página tarda 8 segundos en cargar”, lo primero es ver si el problema está en mi servidor, en el ISP, en un peering internacional, o en el destino. mtr te lo muestra en una pantalla.

La diferencia clave:

• traceroute: un snapshot estático de la ruta
• mtr: estadísticas continuas hasta que lo mates (Ctrl+C), puedes ver pérdida de paquetes que aparece solo bajo carga

---

Índice

1. Instalar mtr y traceroute
2. traceroute básico y opciones útiles
3. mtr: el traceroute con esteroides
4. Interpretar la salida: dónde está realmente el problema
5. Troubleshooting común

---

1. Instalar mtr y traceroute

Antes de empezar, verifica qué tienes instalado. traceroute suele venir en casi todas las distros, pero mtr a veces hay que instalarlo aparte. Conviene hacer las dos cosas en este orden: primero ver qué hay, después instalar lo que falte, y finalmente confirmar que las versiones son razonables.

# Verificar qué hay instalado
which traceroute mtr
# Instalar si falta (Debian/Ubuntu)
sudo apt update
sudo apt install -y traceroute mtr
# Instalar si falta (Fedora/RHEL)
sudo dnf install -y traceroute mtr

Si mtr te da error de permisos o aparece mtr requires root privileges: la versión clásica necesita CAP_NET_RAW para enviar paquetes ICMP. O corres con sudo mtr, o instalas mtr-tiny (versión solo CLI sin GUI GTK, ideal para servidores headless — sigue necesitando CAP_NET_RAW o root), o cambiás los permisos con sudo setcap cap_net_raw+ep $(which mtr). La tercera opción es la más limpia para uso frecuente.

---

2. traceroute básico y opciones útiles

Trazado simple a un destino

El caso más básico: quieres ver por dónde viajan los paquetes hasta Google DNS. traceroute va incrementando el TTL (Time To Live) desde 1, y cada router intermedio responde con un mensaje “TTL excedido”. Eso te permite mapear la ruta hop por hop.

traceroute 8.8.8.8

La salida muestra tres columnas de tiempo por hop (tres intentos), el nombre del router si lo resuelve por DNS inverso, y la IP. Si ves tres asteriscos *, ese hop no respondió (puede ser un firewall que filtra ICMP, no necesariamente un problema).

Si el primer hop ya muestra pérdida del 100%: no es problema del destino, es tu propia máquina o router. revisa ip route show y ip addr show antes de seguir. Si el primer hop aparece pero el segundo se pierde, el problema está entre tú y ese segundo router.

Forzar protocolo y desactivar resolución DNS

La resolución DNS inversa (esos nombres largos tipo ae0-401.bbr01.lax01.network.net) puede hacer que traceroute parezca colgado cuando en realidad solo está esperando DNS. Si quieres velocidad pura, desactivalo con -n.

# Sin resolver DNS inverso (más rápido)
traceroute -n 8.8.8.8
# Forzar ICMP en vez de UDP (algunos routers filtran mejor UDP)
traceroute -I 8.8.8.8
# Limitar cantidad de saltos (default 30)
traceroute -m 15 8.8.8.8

Si traceroute se queda colgado en un hop mostrando solo *: ese router probablemente está configurado para no responder ICMP TTL Exceeded (común en Cisco y Juniper bien configurados). No significa que esté caído. Para confirmar, espera al hop siguiente: si el siguiente responde normalmente, la ruta está bien y ese router solo está “mudo”.

---

3. mtr: el traceroute con esteroides

mtr básico en modo reporte

mtr arranca y se queda actualizando la pantalla hasta que lo mates con Ctrl+C. Pero si quieres un snapshot limpio para mandar por mail o pegar en un ticket, usa -r (report) con -c para definir cuántos ciclos quieres.

# Reporte de 10 ciclos a Google DNS
mtr -r -c 10 8.8.8.8

La salida combina lo mejor de traceroute y ping: por cada hop te muestra % Loss, Snt (paquetes enviados), Last, Avg, Best, Wrst y StDev. Eso te permite detectar pérdida intermitente que un traceroute solo jamás vería.

Si ves pérdida alta en los primeros hops pero luego desaparece: es clásico que los routers de tu ISP tengan ICMP rate-limit configurado. Priorizan tráfico real sobre mensajes de error, así que pierden algunos pero los siguientes hops muestran 0%. Eso no es problema real; es solo que el router está ocupado.

mtr en formato CSV para análisis

Cuando necesitas comparar dos corridas o meter los datos en una planilla, el formato CSV es ideal. Con --csv lo exportás directo. Después puedes abrirlo en LibreOffice o graficar con gnuplot.

# Generar CSV de 100 ciclos
mtr -r -c 100 --csv 8.8.8.8 > mtr-google.csv
# Misma idea pero JSON, útil para scripts
mtr -r -c 50 --json 1.1.1.1 > mtr-cloudflare.json

Si el CSV sale vacío o con solo la cabecera: probablemente el destino filtró todos los probes o algún firewall intermedio dropeó el tráfico. verifica primero con un ping -c 5 que la conectividad básica existe antes de gastar 100 ciclos en un mtr.

---

4. Interpretar la salida: dónde está realmente el problema

Esta es la parte donde muchos se traban. tienes una salida de mtr con pérdida del 30% en el hop 8 y quieres saber si ese hop es el culpable. La regla de oro es la siguiente:

Si la pérdida crece en un hop y se mantiene (o crece) en los siguientes, el problema está en ese hop o antes. Si la pérdida desaparece en los hops siguientes, fue el router el que perdió los probes, no la ruta real.

Caso real: diagnosticar lentitud hacia un servidor

Supongamos que tu servidor en Argentina tarda 800 ms en responder a uno en Chile y quieres ver dónde se va el tiempo. El comando te da el dato en una sola corrida.

mtr -r -c 30 -n servidor.cl

La salida típica te muestra algo así (resumido):

Host                  Loss%  Snt   Last   Avg  Best  Wrst StDev
1. 192.168.1.1         0.0%   30    0.5   0.4   0.3   0.8   0.1
2. 10.50.0.1           0.0%   30    3.2   3.5   2.8   5.1   0.6
3. 200.123.45.67       0.0%   30    8.1   8.0   7.5  10.2   0.8
4. ???                 100.0   30    0.0   0.0   0.0   0.0   0.0
5. 198.51.100.20       0.0%   30   45.2  44.8  42.1  48.5   1.5

Aquí el hop 4 es mudo (no responde), pero el 5 sigue con latencia razonable. El salto grande (de 8 ms a 45 ms) está entre el hop 3 y el 5. Para confirmar, mira el StDev del hop 5: si es bajo y consistente, esa latencia es real (fibra larga, distancia, peering transcontinental). Si el StDev es alto (más de 50% del Avg), hay congestión intermitente en ese enlace.

Si te aparece un hop con 100% de pérdida pero el siguiente responde bien: casi siempre es un router que no responde ICMP por configuración. Para verificar, fíjate si los tiempos del siguiente hop son consistentes. Si sí, ignorá esa pérdida.

Detectar congestión vs. ruteo subóptimo

Dos patrones distintos que te dicen cosas diferentes. La congestión se manifiesta como varianza alta (StDev grande); un ruteo subóptimo (paquete dando vuelta por otro continente) se ve como latencia base alta pero estable.

# Comparar dos corridas separadas en el tiempo
mtr -r -c 20 -n destino > corrida1.txt
sleep 60
mtr -r -c 20 -n destino > corrida2.txt
diff corrida1.txt corrida2.txt

Si entre corrida 1 y 2 cambió la ruta entera (saltos diferentes): es BGP reconvergiendo. Puede ser un mantenimiento programado, una falla en un peer, o una decisión de ingeniería de tráfico. Si pasa en horario laboral de un ISP grande, suele ser mantenimiento; si pasa de madrugada, mira el status page del proveedor.

---

5. Troubleshooting común

“mtr muestra 100% de pérdida al destino pero el sitio responde”

El destino puede estar configurado para no responder a pings/ICMP, pero igual responder HTTP/S. El ICMP es best-effort; muchos sysadmins lo deshabilitan en servidores públicos por seguridad (reduce superficie de ataque y ruido en logs).

# Verificar que el puerto responde aunque ICMP no
mtr -r -c 10 -n destino -P 443

El -P le dice a mtr el puerto destino, pero las sondas siguen siendo UDP por defecto. Para que mtr use TCP real necesitas agregar -T (--tcp). Si con -P 443 llegas sin pérdida pero con ICMP normal ves asteriscos, el destino está filtrando ICMP a propósito. No es problema tuyo.

“traceroute muestra rutas distintas cada vez”

Esto pasa cuando hay load balancing por flujo. Los paquetes se distribuyen entre varios enlaces según un hash (src IP, dst IP, puertos, etc.). Para verificarlo, usa -S en mtr para forzar el puerto source.

# Forzar puerto source fijo
mtr -r -c 20 -n -S 5000 destino

Si con puerto fijo la ruta se estabiliza, era ECMP (Equal-Cost Multi-Path). Si sigue variando, hay ruteo dinámico cambiando permanentemente (BGP o IGP inestable).

“mtr funciona pero traceroute no”

mtr usa UDP en alta port por defecto y puede usar TCP con -T. traceroute usa UDP por defecto; pasale -I para forzar ICMP o UDP sin flag. Si un firewall filtra específicamente uno de los protocolos, solo uno funciona.

# traceroute con TCP SYN (como si fuera un paquete real)
sudo traceroute -T -p 443 destino
# traceroute con ICMP explícito
sudo traceroute -I destino

Si solo -T (TCP) funciona y ni ICMP ni UDP responden: hay un firewall estatal que filtra UDP e ICMP outgoing. Común en WiFi de hoteles, aeropuertos, redes corporativas con inspección profunda.

“Los tiempos de mtr son inconsistentes con los de curl”

mtr mide RTT (ida + vuelta) por hop. Si ves en mtr 100 ms pero curl tarda 250 ms, la diferencia puede deberse a ICMP deprioritizado vs TCP optimizado, routing asimétrico, o tiempo de procesamiento del servidor pasando por otra ruta (routing asimétrico, muy común).

# Mtr desde el servidor de vuelta hacia tu cliente
mtr -r -c 20 -n tu-ip-publica

El routing asimétrico es la norma en internet. Si el camino de vuelta pasa por otro ISP, vas a ver tiempos distintos en cada dirección.

---

Resumen

traceroute y mtr son las dos herramientas base para diagnóstico de red en Linux. traceroute para un snapshot rápido y mtr cuando necesitas estadísticas y quieres ver pérdida intermitente. La clave está en saber leer la salida: dónde la pérdida empieza, dónde termina, y cómo interpretar el StDev para distinguir congestión de latencia física.

Para el próximo paso te recomiendo leer la guía de [tcpdump para capturar tráfico](/coming-soon/) o cómo configurar [nftables como firewall en Linux](/configurar-firewall-linux-nftables-reemplazo-iptables/) si después de diagnosticar quieres filtrar tráfico problemático.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux