Introducción
MTR (originalmente, Matt's TraceRoute, ahora solo My TraceRoute) es una herramienta práctica y liviana en el arsenal de un administrador de UNIX/Linux que puede ayudar a identificar y diagnosticar problemas comunes de la red, como latencia, pérdida de paquetes y errores de enrutamiento. Es una poderosa herramienta 2 en 1 que combina y muestra los resultados de un trazado de ruta y un ping con un solo comando. Repasemos los conceptos básicos del uso de MTR y cómo interpretar los datos que proporciona.
Requisitos
- Necesitará un servidor Linux y, si aún no tiene un servidor, puede visitar nuestra página de alojamiento de VPS y crear un nuevo servidor en menos de 30 segundos
Instalando MTR
Los paquetes MTR están disponibles para la mayoría de los sistemas operativos Linux (o basados en UNIX) populares de la actualidad.
Instalar MTR en Ubuntu/Debian:
sudo apt-get install mtr-tiny
El mtr-tiny el paquete es la versión solo de línea de comandos del mtr paquete. El mtr el paquete incluye soporte para la interfaz gráfica X-11.
Instalar MTR en CentOS/Fedora:
yum install mtr
Instalar MTR en Arch Linux:
pacman -S mtr
Instalar MTR en FreeBSD:
pkg install mtr
.
Cómo funciona el MTR
Para comprender la salida que genera MTR, puede que le resulte útil saber cómo funciona. Si ya está familiarizado con la forma en que traceroute funciona, esta explicación le resultará familiar.
MTR genera un paquete de solicitud de eco ICMP destinado a la IP/nombre de host objetivo de su mtr dominio. El primer paquete tendrá un valor de tiempo de vida (TTL) de 1. Cuando ese paquete llegue al enrutador que es su puerta de enlace en su ruta hacia su destino final, el enrutador receptor disminuirá el TTL en 1, convirtiéndolo en 0 Cuando un TTL llega a 0, el enrutador descarta el paquete y envía al remitente original un paquete ICMP Time Exceeded. Este paquete de retorno contiene la dirección IP del remitente y MTR muestra esta IP (o nombre de host, si puede resolverlo) como el primer salto. Luego, envía un paquete de solicitud de eco ICMP por separado con un TTL de 2, y cuando recibe el paquete de tiempo excedido de ICMP del vencimiento del TTL, enumera este dispositivo como el segundo salto, y así sucesivamente hasta que el destino devuelve un paquete de respuesta de eco ICMP. .
.
Lectura de informes MTR
Además de enumerar cada salto de red entre el origen y el destino, MTR también realiza un seguimiento de las estadísticas relacionadas con el tiempo de ida y vuelta de los paquetes desde el host de origen hasta cada salto en el camino. Este tiempo de ida y vuelta a menudo se denomina latencia .
Para tener una mejor idea de lo que nos dice MTR, echemos un vistazo a un ejemplo que rastrea la ruta al DNS público de Google.
sudo mtr -r 8.8.8.8
[sample results below]
HOST: endor Loss% Snt Last Avg Best Wrst StDev
1. 69.28.84.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
2. 38.104.37.141 0.0% 10 1.2 1.4 1.0 3.2 0.7
3. te0-3-1-1.rcr21.dfw02.atlas. 0.0% 10 0.8 0.9 0.8 1.0 0.1
4. be2285.ccr21.dfw01.atlas.cog 0.0% 10 1.1 1.1 0.9 1.4 0.1
5. be2432.ccr21.mci01.atlas.cog 0.0% 10 10.8 11.1 10.8 11.5 0.2
6. be2156.ccr41.ord01.atlas.cog 0.0% 10 22.9 23.1 22.9 23.3 0.1
7. be2765.ccr41.ord03.atlas.cog 0.0% 10 22.8 22.9 22.8 23.1 0.1
8. 38.88.204.78 0.0% 10 22.9 23.0 22.8 23.9 0.4
9. 209.85.143.186 0.0% 10 22.7 23.7 22.7 31.7 2.8
10. 72.14.238.89 0.0% 10 23.0 23.9 22.9 32.0 2.9
11. 216.239.47.103 0.0% 10 50.4 61.9 50.4 92.0 11.9
12. 216.239.46.191 0.0% 10 32.7 32.7 32.7 32.8 0.1
13. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
14. google-public-dns-a.google.c 0.0% 10 32.7 32.7 32.7 32.8 0.0
Los informes MTR, de forma predeterminada, muestran las siguientes columnas:
– % de pérdida =El porcentaje de paquetes para los que no se recibió una respuesta ICMP.
– Snt =El número de paquetes enviados a cada salto.
– Último =El tiempo de ida y vuelta de la última sonda traceroute, en milisegundos.
– Avg =El tiempo promedio de ida y vuelta de todas las sondas de traceroute, en milisegundos.
– Mejor =El tiempo de ida y vuelta más corto de todas las sondas de traceroute, en milisegundos.
– Wrst =El tiempo de ida y vuelta más largo de todas las sondas traceroute, en milisegundos.
– StDev =Los resultados de la sonda de desviación estándar para cada salto.
.
Obtener un informe en vivo de MTR
Si ejecuta MTR con solo una IP de destino (o nombre de host), obtendrá un informe en vivo que continuará hasta que finalice su sesión o ejecute el comando de interrupción (Ctrl+C ).
sudo mtr 8.8.8.8
Algunos sistemas operativos requieren sudo antes de ejecutar el mtr dominio; otros no.
.
Si desea pausar el MTR, presione p . MTR conservará todos los recuentos recopilados mientras está en pausa, lo que le permitirá tomar una captura de pantalla o copiar los datos en su portapapeles. Reanude el MTR con la barra espaciadora.
.
Generación de un informe MTR de recuento fijo
También puede generar un informe MTR después de un número específico de sondeos de seguimiento con -r opción (la forma larga es --report ). El número predeterminado de conteos es 10, pero si desea ejecutar MTR para un número diferente de conteos, use -c (--report-cycles ) opción también. Por ejemplo, si desea generar un informe de más de 200 recuentos:
sudo mtr -rc 200 8.8.8.8 [long form] sudo mtr --report --report-cycles 200 8.8.8.8
Cualquier MTR ejecutado con -r La opción no producirá ningún resultado (a diferencia del informe en vivo anterior) hasta que complete el número total de conteos. MTR envía una serie de sondeos de rastreo una vez por segundo de manera predeterminada, por lo que un informe debería completarse en poco más de una cantidad de segundos igual a su número de conteo (200 segundos en el ejemplo anterior).
.
Otras opciones útiles
Hay varias otras opciones que pueden resultarle útiles al usar MTR. Aquellos que no requieren argumentos (como -r ) se pueden encadenar en la misma cadena de opción (por ejemplo, -rn ). Una opción que requiere un argumento se puede incluir en una de estas cadenas solo si es la última opción y va seguida de su argumento (p. ej., -rnc 200 ).
-n:(forma larga--no-dns) Deshabilite las búsquedas de nombres de host DNS. ElnLa clave también se puede usar durante un informe en vivo para alternar entre deshabilitar y habilitar las búsquedas de DNS.-u:envía datagramas UDP en lugar de paquetes de solicitud de eco ICMP. EluLa tecla también puede alternar entre UDP e ICMP durante un informe en vivo.-w:(formulario largo--report-wide) Sustituye a-rpero genera un informe que no trunca los nombres de host más largos.-i*:(forma larga--interval) Especifique el intervalo, en segundos, entre sondas de prueba. El intervalo predeterminado es 1 segundo.-4:Restrinja la prueba a IPv4.-6:Restrinja la prueba a IPv6.
.
Análisis de datos MTR para latencia
La salida de datos de MTR puede ayudarlo a identificar problemas que usted o uno de los operadores de Internet pueden tener con el enrutamiento. También puede ayudar a establecer una línea de base para la latencia esperada entre puntos finales.
Reiteremos aquí que los tiempos generados por MTR son los tiempos de ida y vuelta para que un paquete ICMP alcance el salto en el que expira su TTL, para que el dispositivo procese ese vencimiento para generar un paquete ICMP Time Exceeded, y para que ese paquete vuelva a el dispositivo de origen. Para muchos enrutadores, realizar la respuesta ICMP para paquetes perdidos es una prioridad baja y, en algunos dispositivos, está deshabilitada por completo.
Por una de estas razones, es probable que vea casos en los que un salto intermedio muestra un pico ocasional en la columna de tiempo "Último" o "Peor". Siempre que el salto en la latencia no se propague también a cada salto subsiguiente, lo que está viendo es el retraso del mecanismo de respuesta en ese dispositivo, a diferencia de la latencia de rendimiento real. Tome, por ejemplo, la siguiente salida de MTR:
Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. vl223-ar-01.nyc-ny.atlantic.net 0.0% 66 0.5 6.1 0.5 140.2 25.5 2. te0-0-1-1.rcr11.ewr04.atlas.cogentco.com 0.0% 66 1.0 1.0 0.8 2.8 0.2 3. te0-3-0-4.rcr21.ewr02.atlas.cogentco.com 0.0% 66 1.1 1.1 0.9 2.5 0.2 4. be2601.rcr24.jfk01.atlas.cogentco.com 0.0% 66 1.6 1.7 1.5 2.0 0.0 5. be2632.ccr42.jfk02.atlas.cogentco.com 0.0% 66 1.7 1.8 1.6 3.0 0.1 6. be2807.ccr42.dca01.atlas.cogentco.com 0.0% 66 8.3 8.1 7.7 12.1 0.6 7. be2113.ccr42.atl01.atlas.cogentco.com 9.1% 66 27.5 21.7 18.6 34.7 3.9 8. be2123.ccr22.mia01.atlas.cogentco.com 0.0% 66 33.0 33.4 33.0 41.5 1.1 9. be2055.ccr21.mia03.atlas.cogentco.com 0.0% 66 33.3 33.6 33.1 36.3 0.4 10. 38.104.95.170 0.0% 65 40.8 40.9 40.7 42.0 0.1 11. 209.208.7.42 0.0% 65 41.6 43.3 40.9 187.9 18.2 12. [target host] 0.0% 65 41.1 41.1 40.9 41.3 0.0
¿Ves cómo el primer salto y el undécimo salto tienen cada uno un peor tiempo mucho más alto que sus promedios? Muchos miran un indicador como este y asumen que representa evidencia de latencia de rendimiento. Pero, ¿observa cómo el segundo y el duodécimo salto no muestran un peor tiempo similar? Si la columna de peor tiempo para cada salto subsiguiente mostró el mismo tiempo o más, entonces podríamos tomar ese resultado como un incidente que apunta a posibles problemas de latencia. Tenga en cuenta, por el contrario, la columna de tiempo promedio, particularmente entre los saltos 6 y 7. El promedio salta de 8,3 milisegundos a 21,7 milisegundos, y cada salto subsiguiente tiene un número más alto. Esta columna muestra un ejemplo de latencia real, en este caso entre enrutadores en Washington, D.C. y Atlanta, GA (este resultado es bastante normal según los estándares de 2015).
También puede ver saltos intermedios esporádicamente o incluso dejar caer paquetes de forma constante. Nuevamente, siempre que estas caídas estén aisladas en un dispositivo y no sean consistentes en todos los saltos posteriores, entonces es muy probable que sea un síntoma de que los mensajes de respuesta de ICMP Time Exceeded no tienen prioridad para el tráfico de tránsito más importante (puede ver un ejemplo de esta caída en el salto 7 arriba). En algunos casos, los administradores de red configuran los enrutadores para que no respondan con ninguna respuesta de tiempo excedido de ICMP. Es posible que vea que estos saltos muestran una caída del 100 % del tráfico, mientras que los saltos más allá todavía responden (en el primer ejemplo de este artículo, puede ver un ejemplo de este comportamiento en el salto 13 que muestra una pérdida del 100 % y no muestra la IP de sus hosts). o nombre de host).
.
¿Qué sigue?
Este artículo es solo una introducción a cómo puede usar la herramienta MTR para examinar la conectividad de su red a varios puntos finales a través de Internet. Si bien hay mucho más que aprender, la información que se presenta aquí debería brindarle un buen comienzo para poder diagnosticar los problemas de red que pueda estar experimentando. Gracias por leer y vuelva a consultarnos para obtener más actualizaciones y tutoriales y artículos de alojamiento de VPS más avanzados como Qué es:conceptos básicos de redes:conmutadores, enrutadores y cortafuegos.
Obtenga más información sobre nuestros servicios de alojamiento VPS y servidores privados virtuales.
.
.