¿Cómo diagnosticar problemas de red usando MTR?
Actualizado el 11 de octubre, 2016. Por BlueHosting.
MTR es una poderosa herramienta de red que permite que los administradores diagnostiquen y aíslen los errores de red. Además provee reportes útiles de estatus de red a los proveedores de upstream. MTR representa la evolución del comando traceroute al proveer una mayor muestra de datos, como si se ampliara traceroute con la salida del comando ping. Este documento presenta un análisis profundo sobre MTR, los datos que genera, y cómo interpretar correctamente los resultados y sacar conclusiones con base en los datos provistos por esta herramienta.
Por favor verifique y complete nuestros tutoriales de configuración inicial (explore nuestra documentación en busca del tutorial adecuado a su SO) y nuestros consejos de seguridad en Linux antes de continuar con la revisión de esta guía.
Conocimientos básicos del diagnóstico de red
Las herramientas para el diagnóstico de red, incluyendo ping, traceroute y mtr utilizan los paquetes "ICMP" para probar la conexión y el tráfico entre dos puntos en Internet. Cuando un usuario hace ping a un host en la Internet, una serie de paquetes ICMP se envían a dicho host, el cual responde con otros paquetes de vuelta. El cliente del usuario es entonces capaz de calcular el tiempo de ida y vuelta entre dos puntos en la Internet.
En contraste, las herramientas como MTR y traceroute envían paquetes ICMP que van incrementando gradualmente los tiempos de vida o TTLs con el fin de ver la ruta de las series de saltos que da un paquete entre el origen y su destino. El TTL (time to live, por sus siglas en inglés), controla cuántos "saltos" dará un paquete antes de "morir" y regresar al host. Al enviar una serie de paquetes y causarles la muerte después de uno, dos, y luego tres saltos, la máquina cliente es capaz de ensamblar la ruta que toma el tráfico para comunicar a dos hosts en Internet.
Más que proveer un esquema simple de la ruta que el tráfico sigue a través de la Internet, MTR reúne información adicional relacionada con el estado, la conexión y la respuesta de los hosts intermedios. Debido a esta información adicional, se recomienda que utilice MTR siempre que sea posible, para proporcionar un resumen más completo de la conexión entre dos hosts de Internet. Las siguientes secciones explican cómo instalar el software de MTR y cómo interpretar los resultados que proporciona esta herramienta.
Instalar la herramienta MTR
En los sistemas Debian y Ubuntu, ejecute los siguientes comandos para asegurarse de que el repositorio de paquetes de su sistema esté actualizado, de que todos los paquetes instalados estén actualizados y para instalar el propio MTR finalmente:
apt-get update
apt-get upgrade
apt-get install mtr-tiny
En los sistemas CentOS y Fedora debe ejecutar los siguientes comandos para actualizar los repositorios, actualizar los paquetes del sistema e instalar el programa MTR:
yum update
yum install mtr
En los sistemas Arch Linux ejecute los siguientes comandos para actualizar la base de datos de paquetes e instalar MTR:
pacman -Sy
pacman -S mtr
También querrá usar MTR para diagnosticar los problemas de red desde su estación de trabajo local. Si está trabajando con un sistema Linux, puede instalar MTR usando los comandos especificados arriba.
Si está en una estación de trabajo con Mac OS X, puede instalar MTR ya sea con Homebrew o con MacPorts. Para instalar MTR con Homebrew ejecute:
brew install mtr
Para instalar MTR con MacPorts ejecute:
port install mtr
Si su computador usa Windows, puede usar el puerto de Windows para MTR llamado “WinMTR”. Puede descargar esta aplicación en el siguiente enlace: WinMTR.
Generar un reporte MTR
Debido a que MTR provee una imagen de la ruta que toma el tráfico de un host a otro, puede pensar en MTR como una herramienta direccional. Por otra parte, la ruta tomada entre dos puntos en la Internet puede variar en gran medida con base en la ubicación y los enrutadores que estén ubicados por encima de usted. Por esta razón, se recomienda que reúna reportes MTR en ambas direcciones para todos los hosts que estén experimentando problemas de conectividad —o para todos los hosts que sea posible—.
El soporte de BlueHosting a menudo le pedirá los reportes MTR desde y hacia su servidor en caso de que experimente problemas de red. Esto se debe a que, en algunas ocasiones, los reportes MTR no apuntarán los errores desde una dirección cuando aún hay paquetes perdidos en la dirección opuesta. Tener ambos reportes es útil y puede ayudarle en la identificación de problemas; y será necesario al reportar un problema.
Para ubicarnos y estar claros en los términos utilizados en este artículo, cuando nos refiramos a los reportes MTR, el host que ejecuta el programa mtr se llamará host fuente y el host cuyo blanco es la solicitud de mtr lo llamaremos host destino.
Usar MTR en sistemas basados en Unix
Una vez que instale MTR en un sistema con Linux o Mac OS X, puede generar reportes MTR usando la siguiente sintaxis:
mtr -rw [host_destino]
Puede especificar el host_destino usando un nombre de dominio o directamente la dirección IP. Por ejemplo, para probar la ruta y la calidad de la conexión del tráfico al host destino ejemplo.com, ejecute el siguiente comando desde el host fuente:
mtr -rw example.com
Al contactar a nuestro servicio de soporte con un problema relacionado con la red, el técnico le puede solicitar los reportes MTR desde y hacia su BlueHosting. Un reporte a su BlueHosting se haría desde su computador local (u otra PC en su ubicación). El comando se parecería al siguiente:
mtr -rw 123.45.67.89
Asegúrese de remplazar 123.45.67.89 con la dirección IP de su servidor, que podrá encontrar en la sección Accesos de su panel de BlueHosting. Al mismo tiempo, también puede recorger el reporte MTR desde su servidor hacia su red doméstica. El comando sería similar al siguiente:
mtr -rw 111.222.33.44
Asegúrese de remplazar el valor 111.222.33.44 con la dirección IP de su red local. Si no está seguro de cuál es la dirección IP de su computador puede utilizar el primer o segundo host en la salida del reporte MTR que generamos anteriormente. Otra alternativa, es usar el servicio de un tercero, como el que ofrece WhatIsMyIP.com. Al ingresar a su sitio web, podrá ver cuál es su dirección IP pública de inmediato.
Nota:
Las banderas que estamos usando arriba (
rwc) son útiles para ayudar a los técnicos a leer un reporte más completo y específico.La opción
r(forma corta de--report) genera el reporte.La opción
w(forma corta de--report-wide) usa la versión larga del hostname de manera que nuestros técnicos y usted puedan ver el hostname completo en cada salto.
Usar MTR en sistemas con Windows
La herramienta MTR en Windows provee una interfaz de usuario. Abra el programa WinMTR, escriba el host destino en el cuadro de texto cuando se le solicite y luego seleccione la opción iniciar para comenzar con la generación del reporte de datos. Necesitará usar la versión Linux de MTR para generar el reporte MTR para su BlueHosting. Consulte la información expuesta arriba para más información.
Leer los reportes MTR
Debido a que los reportes MTR contienen una gran cantidad de información, puede ser un poco difícil interpretarlos al principio. Considere el siguiente ejemplo de una conexión local a google.com:
mtr --report google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. interno-interno 0.0% 10 2.8 2.1 1.9 2.8 0.3
2. externo-interno 0.0% 10 3.2 2.6 2.4 3.2 0.3
3. 68.85.118.13 0.0% 10 9.8 12.2 8.7 18.2 3.0
4. po-20-ar01.absecon.nj.panjde 0.0% 10 10.2 10.4 8.9 14.2 1.6
5. be-30-crs01.audubon.nj.panjd 0.0% 10 10.8 12.2 10.1 16.6 1.7
6. pos-0-12-0-0-ar01.plainfield 0.0% 10 13.4 14.6 12.6 21.6 2.6
7. pos-0-6-0-0-cr01.newyork.ny. 0.0% 10 15.2 15.3 13.9 18.2 1.3
8. pos-0-4-0-0-pe01.111eighthav 0.0% 10 16.5 16.2 14.5 19.3 1.3
9. as15169-3.111eighthave.ny.ib 0.0% 10 16.0 17.1 14.2 27.7 3.9
10. 72.14.238.232 0.0% 10 19.1 22.0 13.9 43.3 11.1
11. 209.85.241.148 0.0% 10 15.1 16.2 14.8 20.2 1.6
12. lga15s02-in-f104.1e100.net 0.0% 10 15.6 16.9 15.2 20.6 1.7
El comando ejecutado para generar este reporte es: mtr --report google.com. Este utiliza la opción --report la cual envía 10 paquetes al host google.com y genera la salida observada. Sin la opción --report, mtr se ejecutaría continuamente en un entorno interactivo. El modo interactivo refleja el viaje de ida y vuelta repetidamente en tiempo real. En la mayoría de los casos, el modo --report proporciona datos suficientes en un formato útil.
Siguiendo el comando, MTR genera su salida. Generalmente, los reportes MTR toman varios segundos para generarse. No se alarme si toman cierto tiempo para completarse. Un reporte está compuesto de una serie de saltos (12 en este caso). Los "Saltos" son los nodos, enrutadores (o routers) que tiene que atravesar el paquete a través de Internet para poder llegar a su destino. En el ejemplo anterior, los paquetes viajan desde los dispositivos internos "interno-interno" y "externo-interno" hasta llegar a la dirección 68.85.118.13. Los nombres de los hosts se determinan usando búsquedas DNS inversas. Si usted quiere omitir las búsquedas de rDNS puede usar la opción --no-dns, la cual producirá una salida similar a la siguiente:
mtr --no-dns --report google.com
HOST: deleuze Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2
2. 68.85.118.13 0.0% 10 8.6 11.0 8.4 17.8 3.0
3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2
4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4
5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3
6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9
7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9
8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6
9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9
10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2
11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5
En cuanto a las mejores prácticas que deben seguirse al discutir los reportes MTR, lo más recomendado es referirse a cualquier problema en términos de su número de salto. Más allá de ver simplemente la ruta entre los servidores que llevan el paquete al host destino, MTR provee estadísticas valiosas con respecto a la durabilidad de la conexión en 7 columnas. La columna Loss% muestra el porcentaje de pérdida de paquetes en cada salto. La columna Snt cuenta el número de paquetes enviados. La opción --report enviará 10 paquetes a menos que se especifique lo contrario usando la opción --report-cycles=[número-de-paquetes], donde [número-de-paquetes] representa el númera total de paquetes que quiere enviar al host remoto.
Las siguientes cuatro columnas Last, Avg, Best y Wrst son todas medidas de la latencia en milisegundos (ms). Last es la latencia del último paquete enviado, Avg es la latencia promedio de todos los paquetes, mientras que Best y Wrst muestran el mejor (o más corta) y el peor (más largo) viaje de ida y vuelta transcurrido por el paquete para llegar al host. En la mayoría de las casos, la columna Avg debería ser el centro de nuestra atención.
La última columna StDev provee la desviación estándar de las latencias en cada host. A mayor desviación estándar, mayor será la diferencia entre las medidas de latencia. La desviación estándar le permite evaluar si la media (promedio) representa el verdadero valor central del conjunto de datos, o si ha sido sesgado por algún valor no común o por un error de medición. Por ejemplo, si la desviación estándar es muy alta, las medidas de latencias fueron inconsistentes. Aunque algunas pueden ser bajas (por ejemplo: 25ms), otras pueden ser muy altas (por ejemplo: 350 ms). Después de sacar el promedio de latencias de los 10 paquetes enviados, el promedio luce normal pero —en realidad— puede que no represente muy bien a los datos. Si la desviación estándar es alta, por favor verifique los valores de medida de latencia más baja y más alta para asegurarse de que el promedio es una buena representación de la latencia real y que no es resultado de algún valor que produjo un exceso de fluctuación.
En la mayoría de las circunstancias, puede pensar en la salida MTR en tres secciones principales. Dependiendo de las configuraciones, los primeros 2 o 3 saltos a menudo representan el ISP del host fuente, mientras que los últimos 2 o 3 hosts, representan al ISP del host destino. Los saltos intermedios son los routers que los paquetes tienen que atravesar para llegar a su destino.
Por ejemplo, si MTR es ejecutado desde su computador local hacia su BlueHosting, los primeros 2 o 3 saltos pertenecen a su ISP. Los últimos 3 saltos pertenecen al datacenter donde reside su servidor BlueHosting. Cualquier salto en el medio es un salto intermedio. Al ejecutar MTR localmente, si usted observa alguna anormalidad en los primeros saltos cercanos a su fuente, contacte a su proveedor de servicios local o investigue su configuración de red local. Por el contrario, si ve anomalías cerca del destino al que quiere llegar, contacte al operador del servidor destino o revise la configuración de red de dicho servidor. Desafortunadamente, en los casos en los cuales los problemas están en los saltos intermedios, ambos proveedores de servicio tendrán una capacidad muy limitada de solucionar estos problemas técnicos.
Analizar los reportes MTR
Comprobar la pérdida de paquetes
Cuando se analiza una salida MTR, se buscan dos cosas: pérdida y latencia. Primero, hablemos sobre la pérdida. Si usted observa un porcentaje de pérdidas en algún salto particular, esto puede ser un indicador de que hay un problema con un router específico. Sin embargo, una práctica común entre algunos proveedores de servicios, es limitar la tasa de tráfico ICMP usado por MTR. Esto puede dar la ilusión de pérdida de paquetes cuando en realidad, no hay pérdidas. Para determinar si la pérdida que está observando es real o se debe a la limitación de tasas de tráfico, eche un vistazo al próximo salto. Si ese salto muestra una pérdida de 0.0%, entonces puede estar casi seguro de que es una limitación de tasa de tráfico ICMP y no una pérdida real. A continuación un ejemplo:
mtr --report www.google.com
HOST: example Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 50.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
En este caso, la pérdida reportada entre los saltos 1 y 2 se debe probablemente a limitación de tasa de tráfico en el segundo salto. Aunque todo el tráfico restante en los otros ocho saltos pasa por el segundo salto, no hay pérdida de paquetes. Si la pérdida continúa por más de un salto, entonces sí es posible que haya alguna pérdida de paquetes o algún problema de enrutamiento. Recuerde que la limitación de tráfico y las pérdidas pueden ocurrir concurrentemente. En este caso, tome el porcentaje más bajo de pérdidas en una secuencia como la pérdida real. Por ejemplo, considere la siguiente salida:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2
En este caso, se puede ver una pérdida del 60% entre los saltos 2 y 3 así como también entre los saltos 3 y 4. Puede asumir que —probablemente— el tercer y cuarto salto están perdiendo cierta cantidad de tráfico debido a que no hay ningún host subsecuente que reporte una pérdida de cero. Sin embargo, parte de la pérdida se debe a limitación de tráfico, ¿por qué? Porque varios de los saltos finales solo experimentan una pérdida del 40%. Cuando se reporten distintas pérdidas, siempre confíe en los reportes de los últimos saltos.
Algunas pérdidas también pueden estar dadas por problemas en la ruta de retorno. Los paquetes alcanzarán su destino sin errores, pero a veces tienen problemas para hacer el viaje de regreso. Esto será evidente en el reporte, pero puede ser difícil de deducir a través de una salida MTR. Por esta razón, lo mejor es obtener reportes MTR en ambas direcciones cuando esté experimentando algún problema.
Adicionalmente, resista la tentación de investigar o reportar todas las incidencias de pérdidas de paquetes en sus conexiones. Los protocolos de Internet están designados para ser resistentes a algunas degradaciones de red, y las rutas que toman los datos a través del Internet pueden fluctuar según la respuesta de carga, eventos breves de mantenimiento y otros problemas de enrutamiento. Si su reporte MTR muestra pequeñas cantidades de pérdidas cercanas al 10%, en realidad esto no es causa para una preocupación seria debido a que la capa de aplicación compensará las pérdidas que son posiblemente transitorias.
Comprender la latencia de red
Además de ayudar a evaluar la pérdida de paquetes, MTR también le ayuda a evaluar la latencia de una conexión entre su host y el host destino. En virtud de las limitaciones físicas, la latencia siempre aumenta con el número de saltos en una ruta. Sin embargo, el aumento debería ser consistente y lineal. Lamentablemente, la latencia suele ser relativa y es muy dependiente de la calidad de las conexiones del host y de su distancia física. Al evaluar los reportes MTR en busca de conexiones potencialmente problemáticas, considere otros reportes anteriores cuyo funcionamiento haya sido adecuado. También considere las velocidades de conexión conocidas entre otros hosts en un área dada.
La calidad de la conexión también puede afectar la cantidad de latencia que puede experimentar en una ruta particular. Como es de esperar, las conexiones dial-up o de acceso telefónico tendrán una latencia mucho más grande que las conexiones de cable modem al mismo destino. Considere el siguiente reporte MTR el cual muestra una alta latencia:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 388.0 360.4 342.1 396.7 0.2
5. 72.14.233.56 0.0% 10 390.6 360.4 342.1 396.7 0.2
6. 209.85.254.247 0.0% 10 391.6 360.4 342.1 396.7 0.4
7. 64.233.174.46 0.0% 10 391.8 360.4 342.1 396.7 2.1
8. gw-in-f147.1e100.net 0.0% 10 392.0 360.4 342.1 396.7 1.2
La latencia salta significativamente entre los saltos 3 y 4 y permanece alta. Esto puede apuntar un problema de latencia de red porque los tiempos de viaje de ida y vuelta permanecen altos después del cuatro salto. De este reporte, es imposible determinar la causa, aunque entre las posibilidades se incluyen: una sesión de peering (intercambio de tráfico) saturada, un router mal configurado o un enlace congestionado.
Desafortunadamente, la latencia alta no siempre significa un problema con la ruta actual. Un reporte como el de arriba significa que a pesar de algún tipo de problema con el cuatro salto, el tráfico sigue alcanzando el host destino y retornando al host fuente. La latencia también puede ser causada por un problema con la ruta de retorno. La ruta de retorno no será vista en su reporte MTR y los paquetes pueden tomar rutas completamente diferentes desde y hacia un destino particular.
En el ejemplo anterior, aunque hay un gran salto en la latencia entre los hosts 3 y 4, la latencia no aumenta inusualmente en los siguientes saltos. A partir de esto, es lógico asumir que hay algún problema con el cuarto router.
La limitación de tasa de tráfico ICMP también puede crear la apariencia de latencia, similar a la pérdida de paquetes que a veces genera. Considere el siguiente ejemplo:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 254.2 250.3 230.1 263.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
A primera vista, la latencia entre los saltos 4 y 5 llama la atención. Sin embargo, después del quinto salto, la latencia cae drásticamente. La latencia real medida aquí es de aproximadamente 40ms. En casos como estos, MTR llama la atención sobre un problema que no afecta el servicio. Considere la latencia en el último salto al evaluar un reporte MTR.
Reportes MTR comunes
Algunos problemas de red son inusuales y requieren escalarse a los operadores de upstream de la red. Sin embargo, hay una selección de reportes MTR comunes que describe problemas de red frecuentes. Si usted está experimentando algún tipo de problema de red y quiere diagnosticar su problema, considere los siguientes ejemplos:
Configuración de red inapropiada en el host destino
En el siguiente ejemplo, parece que hay un 100% de pérdidas en el host destino debido a que el router está mal configurado. A primera vista parece que los paquetes no están alcanzando el host, pero este no es el caso:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 100.0 10 0.0 0.0 0.0 0.0 0.0
El tráfico llega al host destino; sin embargo, el reporte MTR muestra menos pérdidas porque el host de destino no está enviando una respuesta. Esto puede ser resultado de una configuración inadecuada en la red o en las reglas de firewall (iptables) que causan que el host descarte los paquetes ICMP.
La forma en puede decir que la pérdida se debe a un host mal configurado es mirando el salto que muestra una pérdida del 100%. En el reporte, puede observar que este es el salto final y que MTR no intenta hacer otros saltos adicionales. Aunque es difícil aislar el problema sin una medición inicial, este tipo de errores es bastante común.
Router empresarial o residencial
Muchas veces las puertas de enlace o gateways residenciales causan que los reportes MTR parezcan un poco erróneos.
mtr --no-dns --report google.com
HOST: deleuze Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 2.2 2.2 2.0 2.7 0.2
2. ??? 100.0 10 8.6 11.0 8.4 17.8 3.0
3. 68.86.210.126 0.0% 10 9.1 12.1 8.5 24.3 5.2
4. 68.86.208.22 0.0% 10 12.2 15.1 11.7 23.4 4.4
5. 68.85.192.86 0.0% 10 17.2 14.8 13.2 17.2 1.3
6. 68.86.90.25 0.0% 10 14.2 16.4 14.2 20.3 1.9
7. 68.86.86.194 0.0% 10 17.6 16.8 15.5 18.1 0.9
8. 75.149.230.194 0.0% 10 15.0 20.1 15.0 33.8 5.6
9. 72.14.238.232 0.0% 10 15.6 18.7 14.1 32.8 5.9
10. 209.85.241.148 0.0% 10 16.3 16.9 14.7 21.2 2.2
11. 66.249.91.104 0.0% 10 22.2 18.6 14.2 36.0 6.5
No se alarme por la pérdida reportada del 100%. Esto no indica que haya un problema. Puede ver que no hay pérdidas en los próximos paquetes.
Un router ISP no está configurado de forma adecuada
En ocasiones, un router en la ruta que toma su paquete está configurado incorrectamente y sus paquetes podrían no llegar nunca a su destino. Considere el siguiente ejemplo:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
Los signos de interrogación aparecen cuando no hay información adicional de la ruta. El siguiente reporte muestra el mismo problema:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 172.16.29.45 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
A veces un router mal configurado enviará paquetes en un bucle. Puede ver ese caso en el siguiente ejemplo:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
6. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
7. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
8. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
9. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
10. 12.34.56.78 0.0% 10 0.0 0.0 0.0 0.0 0.0
11. 12.34.56.79 0.0% 10 0.0 0.0 0.0 0.0 0.0
12. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
13. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
14. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0
Todos estos reportes muestran que un router en el salto 4 no está configurado de forma apropiada. Cuando ocurre esto, la única forma de solucionar el problema es contactar al equipo de operadores y administradores de red en el host fuente.
Limitación de la tasa ICMP
Limitar la tasa ICMP puede causar una aparente pérdida de paquetes como se describe a continuación. Cuando hay pérdida de paquetes en un salto —la cual no persiste en los próximos saltos— la pérdida es causada por limitación ICMP. Vea el siguiente ejemplo:
mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9
6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
En situaciones como esta no hay causas para preocuparse. La limitación de la tasa de tráfico es una práctica común y reduce la congestión para priorizar otro tráfico más importante.
Timeouts
Los tiempos de espera agotados o timeouts pueden ocurrir por varias razones. Algunos routers descartarán completamente los paquetes ICMP y no se mostrarán respuestas en la salida como timeouts (???). De forma alternativa, puede haber un problema con la ruta de retorno:
root@localhost:~# mtr --report www.google.com
HOST: localhost Loss% Snt Last Avg Best Wrst StDev
1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3
2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8
3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7
4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1
5. ??? 0.0% 10 7.2 8.3 7.1 16.4 2.9
6. ??? 0.0% 10 39.1 39.4 39.1 39.7 0.2
7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3
8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2
Las timeouts no son necesariamente un indicador de pérdida de paquetes. Los paquetes siguen alcanzando su destino sin pérdidas o latencias significativas. Los timeouts se pueden atribuir a routers que descartan paquetes por propósitos a calidad de servicio QoS (Quality of Service). También puede haber algún problema con las rutas de retorno que causa los timeouts. Este otro falso positivo.
Resolver los problemas de red y de enrutamiento identificados en su reporte MTR
La mayoría de los problemas de enrutamientos mostrados por los reportes MTR son temporales. Gran parte de estos problemas se solucionarán por sí solos en menos de 24 horas. En muchos casos, para el momento en que usted logra notar un problema con una ruta, los supervisores del proveedor de servicios de Internet ya han reportado el problema y los administradores probablemente estén trabajando en la solución del mismo. En los casos en los cuales experimente una degradación del servicio por un período de tiempo prolongado, puede reportar el problema al proveedor de servicios. Al contactarlos, envíe los reportes MTR y cualquier otro dato relevante que pueda tener. Sin datos útiles, los proveedores no tienen un medio para verificar los problemas que usted está experimentando.
Si bien los errores y problemas de enrutamiento cuentan en el porcentaje de lentitud de la red, bajo ningún concepto son la única causa de un rendimiento degradado. La congestión de red puede aumentar significativamente, particularmente en largas distancias durante las horas pico. El tráfico transatlántico y transpacífico puede ser variable y está sujeto a la congestión general de la red. En estos casos, se recomienda que ubique los hosts y los recursos lo más cerca posible —geográficamente— de la audiencia objetiva.
Si está experimentando problemas de conectividad y no puede interpretar su reporte MTR, puede abrir un ticket de soporte incluyendo la salida de dicho reporte, o contactar a nuestro servicio de soporte.
Recursos adicionales
Puede consultar los siguientes recursos en busca de información adicional con respecto a este tema. Aunque este material es provisto esperando que sea útil, tome en cuenta que no podemos dar fe de la actualidad o precisión de los contenidos externos.
- Sitio web oficial de MTR.
- Artículo de Cisco sobre el comando traceroute.