mtr vs Traceroute: Cuándo usar cada herramienta

8 min de lectura - 13 de mayo de 2026

hero section cover
Tabla de contenidos
  • mtr vs traceroute
  • Cómo funciona traceroute
  • Cómo funciona mtr
  • Principales diferencias
  • Lectura de los resultados
  • Cuándo utilizar cada herramienta
Compartir

Cómo funcionan traceroute y mtr, cómo leer sus resultados correctamente y cuándo utilizar cada uno de ellos para el diagnóstico de redes

mtr vs traceroute

Traceroute y mtr son herramientas de línea de comandos para diagnosticar problemas en las rutas de red. Traceroute te da una instantánea de la ruta que siguen tus paquetes. mtr hace lo mismo pero sigue sondeando, acumulando estadísticas sobre pérdida de paquetes, latencia y fluctuación de fase a lo largo del tiempo. Este artículo explica cómo funciona cada herramienta, cómo leer los resultados y cuándo utilizar cada una.

Cómo funciona traceroute

Traceroute utiliza el campo Time-to-Live (TTL) de las cabeceras de los paquetes IP. Envía un paquete con TTL establecido en 1. El primer router disminuye el TTL a cero, descarta el paquete y devuelve un mensaje ICMP "Time Exceeded". Traceroute registra la IP del enrutador y el tiempo de ida y vuelta, luego envía otro paquete con TTL establecido en 2, y así sucesivamente hasta que el paquete llega al destino o alcanza el límite máximo de saltos (30 por defecto, ajustable con -m).

Por defecto, traceroute envía tres sondas por salto, dándole tres lecturas de latencia. Los protocolos difieren según el sistema operativo:

  • Windows: El comando tracert envía ICMP Echo Requests.
  • Linux/macOS: El comando traceroute envía datagramas UDP (puertos 33434-33534). Utilice -I para ICMP o -T para TCP si UDP está bloqueado.

Si se añade el indicador -n, se omiten las búsquedas DNS inversas, lo que acelera notablemente las cosas en rutas con muchos saltos.

Cómo funciona mtr

mtr (My Traceroute) utiliza el mismo descubrimiento de rutas basado en TTL que traceroute, pero sigue enviando sondas, normalmente una por segundo. En lugar de tres puntos de datos por salto, se obtienen estadísticas de ejecución: porcentaje de pérdida de paquetes, latencia media, mejores y peores tiempos de respuesta y desviación estándar (fluctuación).

mtr admite sondas ICMP (por defecto), UDP y TCP SYN. El modo TCP es útil cuando los cortafuegos bloquean ICMP, o cuando se quiere probar un puerto de aplicación específico:

mtr --tcp --port 443 example.com

Para un informe no interactivo que pueda compartir con un equipo de soporte, utilice el modo informe:

mtr --report --report-cycles 100 example.com

Este modo ejecuta 100 sondas e imprime un resumen. También puede configurar tamaños de paquetes personalizados con --psize para comprobar problemas de MTU o fragmentación.

mtr funciona de forma nativa en Linux y macOS. Los usuarios de Windows pueden utilizar WinMTR para una GUI equivalente.

Principales diferencias

FunciónTraceroutemtr
Recogida de datosUna sola vez, 3 sondas por saltoCiclos continuos configurables
Pérdida de paquetesNo se rastrea por saltoMedida por salto
Métricas de latenciaTres valores RTT por saltoÚltima, media, mejor, peor, desviación estándar
Fluctuación (StDev)No se mideMedido por salto
ProtocolosICMP, UDPICMP, UDP, TCP SYN
SalidaTexto estáticoModo de actualización en directo o de informe

La diferencia práctica se reduce a los problemas intermitentes. Un simple traceroute puede fácilmente pasar por alto un router que pierde el 2% de los paquetes o un salto con 15ms de jitter. mtr los detecta porque sigue midiendo.

Lectura de los resultados

El error más común al leer la salida de traceroute o mtr es asumir que un salto intermedio de aspecto problemático significa que hay un problema real. Normalmente no es así.

Los asteriscos (*) en traceroute significan que el router no respondió a la sonda. Muchos routers están configurados para ignorar o limitar la tasa de ICMP. Si los siguientes saltos responden normalmente, la ruta está bien.

Lapérdida de paquetes en un solo salto en mtr sigue la misma lógica. Si el salto 5 muestra un 20% de pérdida pero el destino final muestra un 0%, ese router está simplemente despriorizando las respuestas de la sonda. La pérdida real de paquetes se muestra como un patrón: la pérdida aparece en un salto y persiste en todos los saltos siguientes hasta el destino.

Los saltos de latencia entre saltos son normales y esperados. Un salto de 10 ms a 80 ms suele significar que el paquete cruzó un océano o una larga ruta terrestre. Preocúpate de la latencia sólo si es inusualmente alta para la distancia (menos de 5 ms dentro de un área metropolitana, decenas de milisegundos campo a través, 80-150 ms transoceánica) o si la latencia del destino final es inaceptable.

Merece la pena prestar atenciónal StDev (jitter) en mtr. Valores superiores a 10 ms en cualquier salto pueden causar problemas en VoIP, videollamadas y juegos. Si observas un jitter elevado, ejecuta al menos 100 ciclos para confirmar que se trata de un patrón sostenido y no de un breve pico.

Cuándo utilizar cada herramienta

Utiliza traceroute cuando necesites una respuesta rápida: ¿se puede llegar al destino y, si no, dónde se interrumpe la ruta? Es el punto de partida adecuado para las interrupciones y para verificar el enrutamiento básico.

Utilice mtr cuando el problema sea intermitente o esté relacionado con el rendimiento. Los usuarios que informan de desconexiones ocasionales, problemas de calidad de VoIP o picos de latencia necesitan los datos continuos de mtr. Ejecute al menos 50-100 ciclos para obtener estadísticas fiables.

Para un diagnóstico completo, ejecute mtr en ambas direcciones: desde su máquina al servidor, y desde el servidor de vuelta a su IP. El enrutamiento en Internet es asimétrico, por lo que la ruta de retorno puede tener características completamente diferentes. Si sólo pruebas una dirección, puede que no veas dónde está realmente el problema.

Si tiene problemas con su servidor dedicado o VPS, los equipos de soporte de FDC Servers aceptan informes mtr como prueba de diagnóstico estándar para escaladas de red.

background image
¿Su servidor está frenando su crecimiento?

¿Cansado de despliegues lentos o límites de ancho de banda? FDC Servers ofrece potencia dedicada instantánea, alcance global y planes flexibles diseñados para cualquier escala. ¿Listo para actualizar?

Libere el rendimiento ahora

Blog

Destacados de la semana

Más artículos
Lista de comprobación para el refuerzo de servidores Linux

Lista de comprobación para el refuerzo de servidores Linux

Lista de comprobación paso a paso para reforzar un servidor Linux. Cubre SSH, cortafuegos, parches, permisos de archivos, SELinux/AppArmor y registro de auditorías

15 min de lectura - 8 de mayo de 2026

tutorial de iperf3: Prueba de velocidad de red en Linux y Windows

10 min de lectura - 7 de mayo de 2026

Más artículos