Si abres un reporte MTR y entras en pánico al ver 50% de pérdida en algún salto intermedio, no estás solo. Aprender a interpretar reporte MTR correctamente es la diferencia entre escalar un falso positivo y diagnosticar un problema real de red. La gran mayoría de los «errores» que muestra son falsos positivos generados por routers que limitan o filtran ICMP por seguridad, no caídas reales de tu conexión. En esta guía completa te enseñamos a interpretar reporte MTR sin entrar en pánico, distinguir pérdida real de filtros ICMP y diagnosticar verdaderos problemas de conectividad como lo hace un sysadmin con experiencia.
Esta guía está pensada para administradores de sistemas, equipos de soporte técnico y DevOps en Latinoamérica que necesitan diagnosticar conectividad hacia servidores propios o de terceros — desde Venezuela, Colombia, México, Argentina, Uruguay, Chile, Perú, Ecuador, Bolivia o Paraguay — y quieren dejar de adivinar cuando un cliente dice «está lento».
¿Qué es MTR y por qué necesitas saber interpretar reporte MTR?
MTR significa My Traceroute, y es básicamente traceroute con esteroides. Mientras que un traceroute tradicional envía paquetes una sola vez por cada salto y te muestra el camino hasta el destino, MTR envía múltiples paquetes de forma continua y calcula estadísticas en tiempo real para cada router intermedio. Aprender a usarlo correctamente te permite ver no solo por dónde pasa tu tráfico, sino también cómo se comporta: cuánto se pierde, cuánto tarda, qué tan estable es la latencia y dónde hay jitter.
Por eso es la habilidad favorita de cualquier proveedor serio de hosting, VPS o servidores dedicados cuando hay que diagnosticar problemas de conectividad entre dos puntos de Internet. Para profundizar en la herramienta, puedes consultar el sitio oficial de MTR mantenido por sus desarrolladores.
El comando básico es simple:
mtr -r -c 100 destino.com
Donde -r genera un reporte en formato texto y -c 100 envía 100 paquetes por salto, clave para tener estadísticas confiables como veremos más adelante.
Cómo interpretar reporte MTR — anatomía de cada columna
Antes de interpretar reporte MTR de manera fiable, necesitas entender qué significa cada columna. Aquí está la anatomía completa de un reporte MTR estándar:
Si abres un reporte MTR y entras en pánico al ver 50% de pérdida en algún salto intermedio, no estás solo. Aprender a interpretar reporte MTR correctamente es la diferencia entre escalar un falso positivo y diagnosticar un problema real de red. La gran mayoría de los «errores» que muestra son falsos positivos generados por routers que limitan o filtran ICMP por seguridad, no caídas reales de tu conexión. En esta guía completa te enseñamos a interpretar reporte MTR sin entrar en pánico, distinguir pérdida real de filtros ICMP y diagnosticar verdaderos problemas de conectividad como lo hace un sysadmin con experiencia.
Esta guía está pensada para administradores de sistemas, equipos de soporte técnico y DevOps en Latinoamérica que necesitan diagnosticar conectividad hacia servidores propios o de terceros — desde Venezuela, Colombia, México, Argentina, Uruguay, Chile, Perú, Ecuador, Bolivia o Paraguay — y quieren dejar de adivinar cuando un cliente dice «está lento».
¿Qué es MTR y por qué necesitas saber interpretar reporte MTR?
MTR significa My Traceroute, y es básicamente traceroute con esteroides. Mientras que un traceroute tradicional envía paquetes una sola vez por cada salto y te muestra el camino hasta el destino, MTR envía múltiples paquetes de forma continua y calcula estadísticas en tiempo real para cada router intermedio. Aprender a usarlo correctamente te permite ver no solo por dónde pasa tu tráfico, sino también cómo se comporta: cuánto se pierde, cuánto tarda, qué tan estable es la latencia y dónde hay jitter.
Por eso es la habilidad favorita de cualquier proveedor serio de hosting, VPS o servidores dedicados cuando hay que diagnosticar problemas de conectividad entre dos puntos de Internet. Para profundizar en la herramienta, puedes consultar el sitio oficial de MTR mantenido por sus desarrolladores.
El comando básico es simple:
mtr -r -c 100 destino.com
Donde -r genera un reporte en formato texto y -c 100 envía 100 paquetes por salto, clave para tener estadísticas confiables como veremos más adelante.
Cómo interpretar reporte MTR — anatomía de cada columna
Antes de interpretar reporte MTR de manera fiable, necesitas entender qué significa cada columna. Aquí está la anatomía completa de un reporte MTR estándar:
| Columna | Qué significa | Cómo interpretarla |
|---|---|---|
| HOST | Nombre o IP del router en cada salto | Te dice por qué red pasa tu tráfico (Linode, Arelion, Akamai, etc.) |
| Loss% | Porcentaje de paquetes «perdidos» en ese salto | No siempre indica pérdida real — puede ser ICMP rate limiting |
| Snt | Cantidad de paquetes enviados | Si es menor a 100, las estadísticas son poco confiables |
| Last | Latencia del último paquete (ms) | Útil para ver el comportamiento en tiempo real |
| Avg | Latencia promedio | El número más representativo del estado del salto |
| Best | Mejor latencia registrada | El «piso» físico de la conexión |
| Wrst | Peor latencia registrada | Picos aislados que pueden indicar saturación |
| StDev | Desviación estándar (jitter) | Si es alto, hay inestabilidad — clave para VoIP y videollamadas |
El verdadero arte de leer un MTR no está en mirar una columna aislada, sino en cruzar la información entre todas. Un Loss% del 50% con Avg estable y StDev bajo cuenta una historia muy distinta a un Loss% del 5% con Avg disparado y StDev alto.
El error más común al interpretar reporte MTR — filtrado ICMP vs pérdida real
Este es el malentendido más caro y más común. Si solo te llevas un concepto de esta guía, que sea este: la pérdida que ves en un salto intermedio casi nunca es pérdida real.
Los routers de los grandes operadores (Arelion, Cogent, Lumen, Telia, NTT, Akamai, Hurricane Electric) están configurados con ICMP rate limiting — limitan deliberadamente la cantidad de respuestas ICMP que generan para protegerse de ataques DDoS y para no saturar su CPU. El protocolo ICMP está definido en el RFC 792 del IETF y nunca fue diseñado con prioridad de respuesta. Por eso el tráfico real (HTTP, HTTPS, SSH, SMTP, lo que sea) pasa perfectamente, pero las respuestas a tus pings de diagnóstico se descartan.
La regla de oro al interpretar reporte MTR es simple:
Si el último salto (tu destino) muestra 0% de pérdida, no hay pérdida real en la ruta. Cualquier porcentaje en saltos intermedios que no se propague hasta el final es un falso positivo causado por filtrado o rate limiting de ICMP.
La pérdida real se propaga: si un router intermedio está realmente descartando paquetes de datos, todos los saltos posteriores a él (incluido el destino) mostrarán pérdida igual o mayor. Si el salto 8 muestra 50% de pérdida y los saltos 9 al 20 muestran 0%, el problema está en cómo ese router responde a ICMP, no en cómo enruta los paquetes. Esta regla por sí sola te ahorra el 80% de los errores típicos en cualquier diagnóstico.
Patrones comunes al interpretar reporte MTR y cómo leerlos
Estos son los patrones que verás constantemente en redes hacia Latinoamérica y desde Latinoamérica al mundo:
| Patrón observado | Significado real | ¿Es problema? |
|---|---|---|
| Loss% intermedio + 0% final | ICMP rate limiting del router | No |
| 100% en un salto + saltos posteriores responden | Router con ACL bloqueando ICMP TTL-expired | No |
| Loss% creciente desde un salto X hasta el final | Pérdida real en o después del salto X | Sí |
| Latencia que se duplica entre dos saltos contiguos | Cambio físico de continente, ciudad o backbone | Normal (verificar geografía) |
| Pico de latencia en un salto y vuelve a normal | Router respondiendo ICMP a baja prioridad | No |
| StDev alto solo en el destino final | Servidor saturado o congestión local | Sí — investigar el servidor |
| Asterisco constante en un salto (???) | Router con hardening — no responde a ICMP | No (si el siguiente sí responde) |
| Bucles entre saltos (mismo router aparece dos veces) | Loop de enrutamiento o BGP mal configurado | Sí — reportar al ISP |
Cuándo el problema sí es real al interpretar reporte MTR
No todo en un MTR es falso positivo. Estas son las tres señales inequívocas de que hay un problema genuino que sí debes escalar al interpretar reporte MTR:
1. Pérdida que se propaga hasta el destino
Si ves 5% o más de pérdida desde un salto intermedio en adelante hasta el destino, ahí sí hay un problema real. Significa que ese router (o uno cercano) está descartando paquetes de datos, no solo respuestas ICMP. Anota el ASN del router, identifica el operador (twelve99 = Arelion, gtt.net = GTT, etc.) y abre un ticket si es tu proveedor o repórtalo al peering correspondiente.
2. Latencia incoherente con la geografía
Un salto entre Bogotá y Miami debería estar entre 35 y 60 ms. Uno entre Buenos Aires y Madrid, entre 220 y 260 ms. Si ves latencias muy por encima de lo esperado para una distancia geográfica, alguien está enrutando mal el tráfico — clásico problema de tromboning, donde el tráfico de Argentina a Brasil pasa primero por Estados Unidos en vez de ir directo. Esto es común con proveedores que no tienen buena presencia en Latinoamérica.
3. Jitter (StDev) alto y persistente en múltiples corridas
Si haces mtr -c 200 tres veces seguidas y siempre ves StDev por encima de 30-50 ms en los mismos saltos, hay congestión real. El usuario lo va a notar como audio entrecortado en VoIP, microcortes en SSH, o videollamadas que se trozan. Este es el problema más difícil de demostrar, pero el más impactante para la experiencia del usuario.
¿Necesitas un servidor con red estable y backbone Tier 1 hacia Latinoamérica? En x5 servers tenemos VPS y servidores dedicados con red de alta calidad y datacenters en Estados Unidos optimizados para tráfico LATAM. Conoce nuestros planes de VPS Linux o nuestros servidores dedicados Linux.
Comandos útiles para profundizar tu interpretación
El MTR básico es solo el punto de partida. Estos comandos te permiten ir mucho más a fondo cuando un MTR estándar no es suficiente:
MTR con suficientes muestras estadísticas
mtr -r -c 200 destino.com
Cualquier MTR con menos de 100 paquetes por salto (la columna Snt) es estadísticamente débil. Con 2 paquetes, «50% loss» significa que se perdió 1 de 2 — ruido puro. Para diagnósticos serios, mínimo 100, idealmente 200.
MTR usando TCP en vez de ICMP
mtr -r --tcp --port 443 -c 200 destino.com
Este comando usa paquetes TCP al puerto 443 (HTTPS) en lugar de ICMP. Como simula tráfico real de un servicio web, evita por completo el ICMP rate limiting y te muestra mucho más fiel cómo se comporta la red para una aplicación real. Es el comando que más se acerca a la experiencia del usuario.
MTR usando UDP
mtr -r --udp -c 200 destino.com
Útil cuando sospechas que los routers tratan de manera distinta a ICMP, TCP y UDP. A veces verás patrones de pérdida que aparecen con un protocolo y no con otro — eso te da pistas sobre QoS configurado en algún punto del camino.
MTR inverso (desde el destino hacia ti)
Recuerda que un MTR solo muestra el camino de ida. La ruta de regreso puede ser totalmente distinta y también afecta la latencia y la pérdida real. Si tienes acceso al servidor remoto, ejecuta un MTR desde ahí hacia tu IP pública para tener la imagen completa. Muchos problemas de «lentitud» se resuelven cuando descubres que el tráfico de regreso pasa por un peering congestionado — algo invisible si solo miras el camino de ida.
Por qué interpretar reporte MTR bien también depende del proveedor
Aquí está la verdad incómoda que ningún proveedor barato te va a contar: la calidad de tu red depende mucho más del proveedor de hosting que elegiste que de cualquier comando que ejecutes. Por eso esta habilidad sirve no solo para diagnosticar problemas, sino también para evaluar y comparar proveedores antes de contratarlos.
Un proveedor que use carriers Tier 1 (Arelion, Cogent, Lumen, Telia, NTT) en datacenters bien conectados va a darte rutas limpias hacia Latinoamérica. Un proveedor que solo usa transit barato o peering insuficiente va a darte rutas con tromboning, latencia inflada y jitter constante — y por más MTR que ejecutes, no vas a poder arreglar eso desde tu lado.
Por eso en X5 Servers usamos infraestructura en datacenters Tier III en Estados Unidos con buena conectividad hacia toda Latinoamérica, almacenamiento NVMe, servidor web LiteSpeed y todos nuestros planes incluyen Cloudflare gratuito para acelerar contenido cacheable y absorber picos de tráfico. La diferencia se nota desde el primer ping.
¿Cuándo conviene un VPS o servidor dedicado para tener mejor red?
Si tu actual hosting compartido te da MTR con tromboning, jitter alto y rutas inestables, mejorar la calidad de red puede requerir saltar de plan. Estas son las opciones que ofrecemos en X5 Servers para Latinoamérica:
| Plan | Ideal para | Conoce más |
|---|---|---|
| VPS Linux | Aplicaciones web, APIs, paneles propios con cPanel o sin él | Ver planes de VPS |
| VPS MikroTik (CHR) | VPN, BGP, hotspots, ISPs y operadores de red | Ver VPS MikroTik |
| Servidor Dedicado Linux | Cargas pesadas, recursos garantizados, máxima estabilidad | Ver dedicados Linux |
| Hosting Dedicado Gestionado | Empresas que quieren la potencia de un dedicado sin administrarlo | Ver hosting dedicado |
| Administración de Servidores | Que nuestro equipo se encargue del monitoreo, parches y soporte 24/7 | Ver administración |
Todos los planes anuales incluyen migración gratuita desde tu proveedor actual, hecha por nuestro equipo técnico.
Preguntas frecuentes sobre cómo interpretar reporte MTR
¿Qué significa Loss% al interpretar reporte MTR?
Loss% es el porcentaje de paquetes ICMP que ese salto específico no respondió. No siempre indica pérdida real: muchos routers limitan deliberadamente sus respuestas ICMP por seguridad, generando «pérdida» que no afecta al tráfico real. Solo es relevante si esa pérdida también aparece en el destino final.
¿Por qué un salto muestra 100% de pérdida pero el siguiente responde normal?
Porque ese router tiene una ACL configurada para no responder a ICMP TTL-expired (los paquetes que MTR usa para identificar saltos). El paquete pasa perfectamente por ese router, simplemente no se identifica. Es comportamiento de hardening, muy común en routers de borde de datacenter.
¿Cuál es la diferencia entre traceroute y MTR?
Traceroute envía paquetes una sola vez por salto y te muestra el camino. MTR envía continuamente y calcula estadísticas (pérdida promedio, jitter, latencia mínima/máxima). Para un diagnóstico de calidad, MTR es muy superior porque muestra el comportamiento sostenido de la red, no solo una foto puntual.
¿Qué es el ICMP rate limiting y por qué afecta el resultado?
Es una configuración de seguridad en routers de operadores (Arelion, Lumen, Cogent, etc.) que limita cuántas respuestas ICMP por segundo puede generar el router. Cuando MTR envía muchos paquetes, el router descarta algunas respuestas — no porque haya pérdida, sino porque no quiere generar tantas respuestas ICMP. Esto se ve como Loss% en el MTR pero no afecta el tráfico real. Es la causa #1 de errores al interpretar reporte MTR.
¿Cómo sé si la latencia que veo es normal para Latinoamérica?
Como referencia general: dentro de un mismo país suele estar entre 5 y 40 ms; entre países LATAM, entre 80 y 180 ms; de LATAM a Estados Unidos (Miami), entre 35 y 120 ms según el origen; de LATAM a Europa, entre 180 y 280 ms; de LATAM a Asia, entre 250 y 400 ms. Si ves latencias muy por encima de estos rangos, hay tromboning o enrutamiento subóptimo.
¿Cuántos paquetes debo enviar para interpretar reporte MTR de forma confiable?
Mínimo 100 paquetes por salto (mtr -c 100). Para diagnósticos serios o reportes a ISPs, usa 200 o más. Con menos de 50 paquetes, las estadísticas son demasiado ruidosas para sacar conclusiones — un solo paquete perdido se ve como 2-5% de pérdida y eso confunde más de lo que ayuda.
¿Por qué un MTR contra el mismo destino me da resultados distintos cada vez?
Porque las redes de tránsito hacen load balancing por flujo: paquetes con distinta combinación de IP origen, IP destino, puerto origen y puerto destino pueden tomar rutas físicas diferentes. También influyen la hora (congestión variable), el estado de mantenimientos en routers, y cambios de BGP. Por eso recomendamos correr MTR varias veces en distintos momentos antes de concluir.
¿Sirve interpretar reporte MTR para diagnosticar problemas con mi VPS o servidor dedicado?
Sí, es una de las primeras herramientas que vamos a usar. Si el problema es de red, MTR lo revela inmediatamente. Si MTR sale limpio, el problema está en la aplicación, en la base de datos, en el servidor web o en el DNS. Esto permite descartar la red rápido y enfocar el diagnóstico donde realmente está el fallo. Si tienes contratada nuestra administración de servidores, nuestro equipo lo hace por ti.
Plan de acción para interpretar reporte MTR en tu próximo diagnóstico
La próxima vez que un cliente te diga «está lento» o «se cae la conexión», sigue estos pasos en orden para diagnosticar como un experto:
- Corre un MTR robusto:
mtr -r -c 200 destinoy guarda el output completo. - Mira primero el último salto: si Loss% es 0%, no hay pérdida real en la ruta — pasa al paso 5.
- Si hay pérdida en el destino, busca dónde empieza: identifica el primer salto donde la pérdida se vuelve consistente y se propaga. Ahí está el problema.
- Identifica al operador del salto problemático por el dominio (twelve99 = Arelion, lumen = Lumen, cogent = Cogent, etc.) y abre ticket con tu proveedor con el reporte adjunto.
- Si la red está limpia, salta a la capa de aplicación: revisa logs del servidor web, métricas de CPU/RAM/disco, queries lentas en la base de datos, certificados SSL, resolución DNS.
- Para VoIP o videollamadas, presta atención al StDev: jitter alto rompe la experiencia incluso sin pérdida.
- Documenta el resultado: guardar MTRs antes/después es la mejor evidencia para escalar a un ISP o demostrar mejoras.
Para profundizar más en la herramienta y su historia, puedes consultar el artículo de MyTraceRoute en Wikipedia, donde encontrarás detalles técnicos adicionales y referencias.
¿Estás pensando en migrar a un proveedor con red Tier 1 hacia Latinoamérica?
En X5 Servers tenemos más de 8 años sirviendo al mercado LATAM con datacenters Tier III en Estados Unidos, almacenamiento NVMe, LiteSpeed, Cloudflare gratuito en todos los planes y migración gratuita en planes anuales.
Escríbenos al WhatsApp comercial +1 (786) 744-1279 o por correo a info@x5servers.com. Para soporte técnico de clientes activos, abre un ticket desde el panel de clientes — atendemos 24/7.
Saber leer un MTR es solo una herramienta — la verdadera diferencia la hace tener una infraestructura bien conectada de base. Cuando partes con buena red, el MTR confirma lo bueno. Cuando partes con mala red, el MTR solo confirma lo que ya sospechabas. Elige bien dónde poner tus servidores y la mitad de los problemas de «lentitud» desaparecen antes de que existan.
| Columna | Qué significa | Cómo interpretarla |
|---|---|---|
| HOST | Nombre o IP del router en cada salto | Te dice por qué red pasa tu tráfico (Linode, Arelion, Akamai, etc.) |
| Loss% | Porcentaje de paquetes «perdidos» en ese salto | No siempre indica pérdida real — puede ser ICMP rate limiting |
| Snt | Cantidad de paquetes enviados | Si es menor a 100, las estadísticas son poco confiables |
| Last | Latencia del último paquete (ms) | Útil para ver el comportamiento en tiempo real |
| Avg | Latencia promedio | El número más representativo del estado del salto |
| Best | Mejor latencia registrada | El «piso» físico de la conexión |
| Wrst | Peor latencia registrada | Picos aislados que pueden indicar saturación |
| StDev | Desviación estándar (jitter) | Si es alto, hay inestabilidad — clave para VoIP y videollamadas |
El verdadero arte de leer un MTR no está en mirar una columna aislada, sino en cruzar la información entre todas. Un Loss% del 50% con Avg estable y StDev bajo cuenta una historia muy distinta a un Loss% del 5% con Avg disparado y StDev alto.
El error más común al interpretar reporte MTR — filtrado ICMP vs pérdida real
Este es el malentendido más caro y más común. Si solo te llevas un concepto de esta guía, que sea este: la pérdida que ves en un salto intermedio casi nunca es pérdida real.
Los routers de los grandes operadores (Arelion, Cogent, Lumen, Telia, NTT, Akamai, Hurricane Electric) están configurados con ICMP rate limiting — limitan deliberadamente la cantidad de respuestas ICMP que generan para protegerse de ataques DDoS y para no saturar su CPU. El protocolo ICMP está definido en el RFC 792 del IETF y nunca fue diseñado con prioridad de respuesta. Por eso el tráfico real (HTTP, HTTPS, SSH, SMTP, lo que sea) pasa perfectamente, pero las respuestas a tus pings de diagnóstico se descartan.
La regla de oro al interpretar reporte MTR es simple:
Si el último salto (tu destino) muestra 0% de pérdida, no hay pérdida real en la ruta. Cualquier porcentaje en saltos intermedios que no se propague hasta el final es un falso positivo causado por filtrado o rate limiting de ICMP.
La pérdida real se propaga: si un router intermedio está realmente descartando paquetes de datos, todos los saltos posteriores a él (incluido el destino) mostrarán pérdida igual o mayor. Si el salto 8 muestra 50% de pérdida y los saltos 9 al 20 muestran 0%, el problema está en cómo ese router responde a ICMP, no en cómo enruta los paquetes. Esta regla por sí sola te ahorra el 80% de los errores típicos en cualquier diagnóstico.
Patrones comunes al interpretar reporte MTR y cómo leerlos
Estos son los patrones que verás constantemente en redes hacia Latinoamérica y desde Latinoamérica al mundo:
| Patrón observado | Significado real | ¿Es problema? |
|---|---|---|
| Loss% intermedio + 0% final | ICMP rate limiting del router | No |
| 100% en un salto + saltos posteriores responden | Router con ACL bloqueando ICMP TTL-expired | No |
| Loss% creciente desde un salto X hasta el final | Pérdida real en o después del salto X | Sí |
| Latencia que se duplica entre dos saltos contiguos | Cambio físico de continente, ciudad o backbone | Normal (verificar geografía) |
| Pico de latencia en un salto y vuelve a normal | Router respondiendo ICMP a baja prioridad | No |
| StDev alto solo en el destino final | Servidor saturado o congestión local | Sí — investigar el servidor |
| Asterisco constante en un salto (???) | Router con hardening — no responde a ICMP | No (si el siguiente sí responde) |
| Bucles entre saltos (mismo router aparece dos veces) | Loop de enrutamiento o BGP mal configurado | Sí — reportar al ISP |
Cuándo el problema sí es real al interpretar reporte MTR
No todo en un MTR es falso positivo. Estas son las tres señales inequívocas de que hay un problema genuino que sí debes escalar al interpretar reporte MTR:
1. Pérdida que se propaga hasta el destino
Si ves 5% o más de pérdida desde un salto intermedio en adelante hasta el destino, ahí sí hay un problema real. Significa que ese router (o uno cercano) está descartando paquetes de datos, no solo respuestas ICMP. Anota el ASN del router, identifica el operador (twelve99 = Arelion, gtt.net = GTT, etc.) y abre un ticket si es tu proveedor o repórtalo al peering correspondiente.
2. Latencia incoherente con la geografía
Un salto entre Bogotá y Miami debería estar entre 35 y 60 ms. Uno entre Buenos Aires y Madrid, entre 220 y 260 ms. Si ves latencias muy por encima de lo esperado para una distancia geográfica, alguien está enrutando mal el tráfico — clásico problema de tromboning, donde el tráfico de Argentina a Brasil pasa primero por Estados Unidos en vez de ir directo. Esto es común con proveedores que no tienen buena presencia en Latinoamérica.
3. Jitter (StDev) alto y persistente en múltiples corridas
Si haces mtr -c 200 tres veces seguidas y siempre ves StDev por encima de 30-50 ms en los mismos saltos, hay congestión real. El usuario lo va a notar como audio entrecortado en VoIP, microcortes en SSH, o videollamadas que se trozan. Este es el problema más difícil de demostrar, pero el más impactante para la experiencia del usuario.
¿Necesitas un servidor con red estable y backbone Tier 1 hacia Latinoamérica? En X5 Servers tenemos VPS y servidores dedicados con red de alta calidad y datacenters en Estados Unidos optimizados para tráfico LATAM. Conoce nuestros planes de VPS Linux o nuestros servidores dedicados Linux.
Comandos útiles para profundizar tu interpretación
El MTR básico es solo el punto de partida. Estos comandos te permiten ir mucho más a fondo cuando un MTR estándar no es suficiente:
MTR con suficientes muestras estadísticas
mtr -r -c 200 destino.com
Cualquier MTR con menos de 100 paquetes por salto (la columna Snt) es estadísticamente débil. Con 2 paquetes, «50% loss» significa que se perdió 1 de 2 — ruido puro. Para diagnósticos serios, mínimo 100, idealmente 200.
MTR usando TCP en vez de ICMP
mtr -r --tcp --port 443 -c 200 destino.com
Este comando usa paquetes TCP al puerto 443 (HTTPS) en lugar de ICMP. Como simula tráfico real de un servicio web, evita por completo el ICMP rate limiting y te muestra mucho más fiel cómo se comporta la red para una aplicación real. Es el comando que más se acerca a la experiencia del usuario.
MTR usando UDP
mtr -r --udp -c 200 destino.com
Útil cuando sospechas que los routers tratan de manera distinta a ICMP, TCP y UDP. A veces verás patrones de pérdida que aparecen con un protocolo y no con otro — eso te da pistas sobre QoS configurado en algún punto del camino.
MTR inverso (desde el destino hacia ti)
Recuerda que un MTR solo muestra el camino de ida. La ruta de regreso puede ser totalmente distinta y también afecta la latencia y la pérdida real. Si tienes acceso al servidor remoto, ejecuta un MTR desde ahí hacia tu IP pública para tener la imagen completa. Muchos problemas de «lentitud» se resuelven cuando descubres que el tráfico de regreso pasa por un peering congestionado — algo invisible si solo miras el camino de ida.
Por qué interpretar reporte MTR bien también depende del proveedor
Aquí está la verdad incómoda que ningún proveedor barato te va a contar: la calidad de tu red depende mucho más del proveedor de hosting que elegiste que de cualquier comando que ejecutes. Por eso esta habilidad sirve no solo para diagnosticar problemas, sino también para evaluar y comparar proveedores antes de contratarlos.
Un proveedor que use carriers Tier 1 (Arelion, Cogent, Lumen, Telia, NTT) en datacenters bien conectados va a darte rutas limpias hacia Latinoamérica. Un proveedor que solo usa transit barato o peering insuficiente va a darte rutas con tromboning, latencia inflada y jitter constante — y por más MTR que ejecutes, no vas a poder arreglar eso desde tu lado.
Por eso en X5 Servers usamos infraestructura en datacenters Tier III en Estados Unidos con buena conectividad hacia toda Latinoamérica, almacenamiento NVMe, servidor web LiteSpeed y todos nuestros planes incluyen Cloudflare gratuito para acelerar contenido cacheable y absorber picos de tráfico. La diferencia se nota desde el primer ping.
¿Cuándo conviene un VPS o servidor dedicado para tener mejor red?
Si tu actual hosting compartido te da MTR con tromboning, jitter alto y rutas inestables, mejorar la calidad de red puede requerir saltar de plan. Estas son las opciones que ofrecemos en X5 Servers para Latinoamérica:
| Plan | Ideal para | Conoce más |
|---|---|---|
| VPS Linux | Aplicaciones web, APIs, paneles propios con cPanel o sin él | Ver planes de VPS |
| VPS MikroTik (CHR) | VPN, BGP, hotspots, ISPs y operadores de red | Ver VPS MikroTik |
| Servidor Dedicado Linux | Cargas pesadas, recursos garantizados, máxima estabilidad | Ver dedicados Linux |
| Hosting Dedicado Gestionado | Empresas que quieren la potencia de un dedicado sin administrarlo | Ver hosting dedicado |
| Administración de Servidores | Que nuestro equipo se encargue del monitoreo, parches y soporte 24/7 | Ver administración |
Todos los planes anuales incluyen migración gratuita desde tu proveedor actual, hecha por nuestro equipo técnico.
Preguntas frecuentes sobre cómo interpretar reporte MTR
¿Qué significa Loss% al interpretar reporte MTR?
Loss% es el porcentaje de paquetes ICMP que ese salto específico no respondió. No siempre indica pérdida real: muchos routers limitan deliberadamente sus respuestas ICMP por seguridad, generando «pérdida» que no afecta al tráfico real. Solo es relevante si esa pérdida también aparece en el destino final.
¿Por qué un salto muestra 100% de pérdida pero el siguiente responde normal?
Porque ese router tiene una ACL configurada para no responder a ICMP TTL-expired (los paquetes que MTR usa para identificar saltos). El paquete pasa perfectamente por ese router, simplemente no se identifica. Es comportamiento de hardening, muy común en routers de borde de datacenter.
¿Cuál es la diferencia entre traceroute y MTR?
Traceroute envía paquetes una sola vez por salto y te muestra el camino. MTR envía continuamente y calcula estadísticas (pérdida promedio, jitter, latencia mínima/máxima). Para un diagnóstico de calidad, MTR es muy superior porque muestra el comportamiento sostenido de la red, no solo una foto puntual.
¿Qué es el ICMP rate limiting y por qué afecta el resultado?
Es una configuración de seguridad en routers de operadores (Arelion, Lumen, Cogent, etc.) que limita cuántas respuestas ICMP por segundo puede generar el router. Cuando MTR envía muchos paquetes, el router descarta algunas respuestas — no porque haya pérdida, sino porque no quiere generar tantas respuestas ICMP. Esto se ve como Loss% en el MTR pero no afecta el tráfico real. Es la causa #1 de errores al interpretar reporte MTR.
¿Cómo sé si la latencia que veo es normal para Latinoamérica?
Como referencia general: dentro de un mismo país suele estar entre 5 y 40 ms; entre países LATAM, entre 80 y 180 ms; de LATAM a Estados Unidos (Miami), entre 35 y 120 ms según el origen; de LATAM a Europa, entre 180 y 280 ms; de LATAM a Asia, entre 250 y 400 ms. Si ves latencias muy por encima de estos rangos, hay tromboning o enrutamiento subóptimo.
¿Cuántos paquetes debo enviar para interpretar reporte MTR de forma confiable?
Mínimo 100 paquetes por salto (mtr -c 100). Para diagnósticos serios o reportes a ISPs, usa 200 o más. Con menos de 50 paquetes, las estadísticas son demasiado ruidosas para sacar conclusiones — un solo paquete perdido se ve como 2-5% de pérdida y eso confunde más de lo que ayuda.
¿Por qué un MTR contra el mismo destino me da resultados distintos cada vez?
Porque las redes de tránsito hacen load balancing por flujo: paquetes con distinta combinación de IP origen, IP destino, puerto origen y puerto destino pueden tomar rutas físicas diferentes. También influyen la hora (congestión variable), el estado de mantenimientos en routers, y cambios de BGP. Por eso recomendamos correr MTR varias veces en distintos momentos antes de concluir.
¿Sirve interpretar reporte MTR para diagnosticar problemas con mi VPS o servidor dedicado?
Sí, es una de las primeras herramientas que vamos a usar. Si el problema es de red, MTR lo revela inmediatamente. Si MTR sale limpio, el problema está en la aplicación, en la base de datos, en el servidor web o en el DNS. Esto permite descartar la red rápido y enfocar el diagnóstico donde realmente está el fallo. Si tienes contratada nuestra administración de servidores, nuestro equipo lo hace por ti.
Plan de acción para interpretar reporte MTR en tu próximo diagnóstico
La próxima vez que un cliente te diga «está lento» o «se cae la conexión», sigue estos pasos en orden para diagnosticar como un experto:
- Corre un MTR robusto:
mtr -r -c 200 destinoy guarda el output completo. - Mira primero el último salto: si Loss% es 0%, no hay pérdida real en la ruta — pasa al paso 5.
- Si hay pérdida en el destino, busca dónde empieza: identifica el primer salto donde la pérdida se vuelve consistente y se propaga. Ahí está el problema.
- Identifica al operador del salto problemático por el dominio (twelve99 = Arelion, lumen = Lumen, cogent = Cogent, etc.) y abre ticket con tu proveedor con el reporte adjunto.
- Si la red está limpia, salta a la capa de aplicación: revisa logs del servidor web, métricas de CPU/RAM/disco, queries lentas en la base de datos, certificados SSL, resolución DNS.
- Para VoIP o videollamadas, presta atención al StDev: jitter alto rompe la experiencia incluso sin pérdida.
- Documenta el resultado: guardar MTRs antes/después es la mejor evidencia para escalar a un ISP o demostrar mejoras.
Para profundizar más en la herramienta y su historia, puedes consultar el artículo de MyTraceRoute en Wikipedia, donde encontrarás detalles técnicos adicionales y referencias.
¿Estás pensando en migrar a un proveedor con red Tier 1 hacia Latinoamérica?
En X5 Servers tenemos más de 8 años sirviendo al mercado LATAM con datacenters Tier III en Estados Unidos, almacenamiento NVMe, LiteSpeed, Cloudflare gratuito en todos los planes y migración gratuita en planes anuales.
Escríbenos al WhatsApp comercial +1 (786) 744-1279 o por correo a info@x5servers.com. Para soporte técnico de clientes activos, abre un ticket desde el panel de clientes — atendemos 24/7.
Saber leer un MTR es solo una herramienta — la verdadera diferencia la hace tener una infraestructura bien conectada de base. Cuando partes con buena red, el MTR confirma lo bueno. Cuando partes con mala red, el MTR solo confirma lo que ya sospechabas. Elige bien dónde poner tus servidores y la mitad de los problemas de «lentitud» desaparecen antes de que existan.
