Mi Traceroute, o MTR, combina el traceroute y el ping para medir el estado de una ruta de red.
Después de leer este artículo podrás:
Contenido relacionado
Suscríbete a theNET, el resumen mensual de Cloudflare sobre las ideas más populares de Internet.
Copiar el enlace del artículo
Traceroute es una herramienta utilizada para diagnosticar problemas en una ruta de red. Traceroute se utiliza para entender la ruta que siguen los paquetes IP desde un ordenador (dirección IP de origen) a otro (dirección IP de destino). El comando traceroute (en Linux o macOS) o tracert (en Windows) permite entender:
*El Tiempo de ida y vuelta (RTT) es el tiempo que tardan los datos en llegar y salir de un punto determinado de la red.
Aquí tienes un ejemplo de traceroute a 1.1.1.1. Las líneas con asteriscos (* * *) representan saltos de los que no se devolvieron paquetes; esto puede ocurrir cuando los enrutadores están configurados para ignorar los paquetes traceroute. Los tiempos en milisegundos de cada línea son los tiempos de ida y vuelta desde el origen hasta ese salto para cada paquete (traceroute envía tres paquetes a la vez para verificar los resultados).
Ejemplo de Traceroute |
---|
traceroute a 1.1.1.1 (1.1.1.1), 64 saltos como máximo, paquetes de 52 bytes |
1 myrouter (192.168.47.1) 2,755 ms 1,452 ms 1,325 ms |
2 * * * |
3 69.168.32.65 (69.168.32.65) 18,159 ms 18,658 ms 15,091 ms |
4 * * * |
5 206.126.237.30 (206.126.237.30) 30,453 ms 50,242 ms 24,342 ms |
6 one.one.one.one (1.1.1.1) 29,000 ms 26,784 ms 26,017 ms |
Una ruta de red hace referencia a la secuencia de redes que atraviesa un paquete para llegar a su destino.
Internet es un conjunto enorme de redes que se conectan entre sí a mediante enrutamiento. La mayoría de los puntos de conexión de Internet, por ejemplo, un navegador web que intenta acceder a un sitio web y el servidor que lo aloja, no forma parte de la misma red. Esto quiere decir que si dicho navegador envía una solicitud a los servidores del sitio web, la solicitud probablemente tendrá que saltar entre varias redes intermediarias a lo largo del camino.
Una herramienta de traceroute envía paquetes a una IP de destino y con un tiempo de vida (TTL) ajustado a 1, para que el primer enrutador al que lleguen los paquetes devuelva un error ("tiempo excedido"). Cuando el error vuelve, la herramienta de traceroute registra la identidad del primer enrutador, y el tiempo de ida y vuelta, incrementa el TTL y envía nuevos paquetes, repitiendo este proceso hasta que 1) el último paquete llegue a la IP de destino o 2) se descarten dos conjuntos de paquetes.
Al hacer esto, la herramienta te permite comprender la ruta que siguen tus paquetes, y el tiempo de ida y vuelta de cada salto, para que puedas solucionar la pérdida de paquetes y la latencia.
Traceroute se basa en el protocolo ICMP (Protocolo de control de mensajes de Internet). El ICMP es un protocolo de la capa de red utilizado para comprobar errores. No tiene un protocolo de transporte asociado, ya que funciona directamente sobre el Protocolo de Internet (IP). Cuando se supera el TTL de un paquete enviado por la herramienta traceroute, el enrutador devuelve un paquete ICMP de tipo 11 (error de tiempo excedido).
Los paquetes salientes (enviados desde el enrutador de salida) pueden utilizar ICMP (por defecto en los sistemas operativos MacOS y Linux) o UDP (por defecto en Windows). Elegir un protocolo diferente para los paquetes de traceroute salientes es una forma de obtener resultados más completos si los enrutadores a lo largo de la ruta de la red están configurados para filtrar los paquetes de un determinado protocolo.
Mi Traceroute (MTR) es una herramienta que combina traceroute y ping, que es otro método habitual para comprobar la conectividad y la velocidad de la red. Además de los saltos a lo largo de la ruta de la red, MTR muestra información constantemente actualizada sobre la latencia y la pérdida de paquetes a lo largo de la ruta hasta el destino. Esto ayuda a solucionar los problemas de la red, ya que te permite ver lo que ocurre a lo largo de la ruta en tiempo real.
MTR funciona al descubrir la ruta de red de forma similar al traceroute, y al enviar después paquetes con regularidad, para seguir recopilando información que ofrezca una visión actualizada del estado y la velocidad de la red.
Al igual que traceroute, MTR puede utilizar ICMP o UDP para los paquetes de salida, pero confía en ICMP para los paquetes de retorno (Tipo 11: Tiempo excedido).
A continuación, hay tres ejemplos de cómo leer y sacar conclusiones de los resultados de las pruebas de rendimiento.
MTR limpio | |||||||
---|---|---|---|---|---|---|---|
Empieza: 2020-04-08T13:28:52+0100 | |||||||
HOST: myrouter | % de pérdida | Snt | Último | Media | Mejor | Peor | StDev |
1.|-- 10.10.1.1 | 0,0 % | 10 | 0,3 | 0.4 | 0,3 | 0.4 | 0.0 |
2.|-- 141.0.147.177.bcube.co.uk | 0,0 % | 10 | 2,7 | 2,7 | 2,5 | 3.1 | 0.2 |
3.|-- 172.16.28.38 | 0,0 % | 10 | 2,8 | 6,4 | 2,8 | 22,2 | 6.1 |
4.|-- 172.17.13.76 | 0,0 % | 10 | 1,1 | 2,8 | 1,1 | 14,6 | 4.2 |
5.|-- 172.17.13.49 | 0,0 % | 10 | 1.4 | 4,0 | 1,3 | 25,0 | 7,4 |
6.|-- 172.17.13.24 | 0,0 % | 10 | 2,5 | 2,7 | 2.0 | 5.1 | 1,1 |
7.|-- one.one.one.one | 0,0 % | 10 | 1,3 | 1.2 | 1.2 | 1,3 | 0.0 |
Este ejemplo sigue la ruta de la red entre el enrutador de partida y el servidor 1.1.1.1 DNS de Cloudflare. La salida del MTR no indica ningún problema: se necesitan 7 saltos para llegar a 1.1.1.1, y ninguno de ellos indica ninguna pérdida de paquetes.
Pérdida de paquetes en ruta | |||||||
---|---|---|---|---|---|---|---|
Empieza: 2020-04-08T12:48:28+0000 | |||||||
HOST: myrouter | % de pérdida | Snt | Último | Media | Mejor | Peor | StDev |
1.|-- 2400:cb00:207:1000::1 | 0,0 % | 10 | 1,1 | 6,0 | 0.6 | 15,7 | 5,9 |
2.|-- 2404:d400:4000:27::1 | 0,0 % | 10 | 0.4 | 0.6 | 0.2 | 2,9 | 0.8 |
3.|-- 2404:d400:0:8:: | 0,0 % | 10 | 125,7 | 125,7 | 125,7 | 126,2 | 0.2 |
4.|-- 2001:978:2:42::e:1 | 50,0 % | 10 | 129,2 | 129,6 | 129,2 | 130,5 | 0.6 |
5.|-- be2846.ccr42.fra03.atlas.cogentco.com | 80,0 % | 10 | 151,9 | 139,5 | 127,1 | 151,9 | 17,6 |
6.|-- be2814.ccr42.ams03.atlas.cogentco.com | 80,0 % | 10 | 136,2 | 137,0 | 136,2 | 137,8 | 1,1 |
7.|-- be2183.ccr22.lpl01.atlas.cogentco.com | 50,0 % | 10 | 146,3 | 146,2 | 145,9 | 146,3 | 0,10 |
8.|-- be3043.ccr22.ymq01.atlas.cogentco.com | 30,0 % | 10 | 215,3 | 215,2 | 215,0 | 215,4 | 0.2 |
9.|-- be3260.ccr32.yyz02.atlas.cogentco.com | 90,0 % | 10 | 227,8 | 227,8 | 227,8 | 227,8 | 0.0 |
10.|-- be2994.ccr22.cle04.atlas.cogentco.com | 30,0 % | 10 | 234,9 | 234,9 | 234,5 | 235,1 | 0.2 |
11.|-- be2718.ccr42.ord01.atlas.cogentco.com | 70,0 % | 10 | 233,7 | 233,8 | 233,7 | 233,9 | 0,10 |
12.|-- be2832.ccr22.mci01.atlas.cogentco.com | 50,0 % | 10 | 244,8 | 245,1 | 244,8 | 245,5 | 0,3 |
13.|-- be3036.ccr22.den01.atlas.cogentco.com | 30,0 % | 10 | 259,6 | 259,6 | 259,3 | 259,8 | 0.2 |
14.|-- be3038.ccr32.slc01.atlas.cogentco.com | 90,0 % | 10 | 267,2 | 267,2 | 267,2 | 267,2 | 0.0 |
15.|-- be3110.ccr22.sfo01.atlas.cogentco.com | 10,0 % | 10 | 291,0 | 291,1 | 291,0 | 291,4 | 0,10 |
16.|-- be3670.ccr41.sjc03.atlas.cogentco.com | 30,0 % | 10 | 292,6 | 292,7 | 292,6 | 292,8 | 0,10 |
17.|-- 2001:550:2:1f::29:2 | 0,0 % | 10 | 312,3 | 291,5 | 287,0 | 312,3 | 8,6 |
8,6 | 0,0 % | 10 | 298,7 | 299,5 | 298,7 | 306,1 | 2.3 |
19.|-- ??? | 100.0 | 10 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
20.|-- ??? | 100.0 | 9 | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
21.|-- 2400:cb00:36:1008::a29e:40e2 | 0,0 % | 9 | 302,9 | 302,9 | 302,8 | 303,2 | 0,10 |
Este ejemplo muestra la ruta de red entre el enrutador inicial y 2400:cb00:36:1008::a29e:40e2, que es una dirección IPv6. El resultado muestra una pérdida de paquetes significativa en todos los saltos de Cogent. Sin embargo, no hay pérdida de paquetes en el último salto (21). Esto indica que la ruta de red no es realmente problemática. Lo que ocurre es algo que suele denominarse "Política del plano de control".
Como ya se ha comentado anteriormente, el MTR funciona al enviar (por defecto) paquetes ICMP Echo, con un TTL (Tiempo de vida) creciente por paquete. Cuando el TTL caduca, un enrutador envía de vuelta un ICMP de tipo 11 (tiempo excedido), indicando cuántos saltos hay desde el punto A al punto B.
Muchos operadores de red (incluido Cloudflare) establecen límites arbitrarios a la cantidad de paquetes ICMP que pueden llegar al plano de control de un enrutador. (El plano de control es el cerebro del enrutador.) Un paquete que supera el TTL del enrutador lo tiene que procesar el plano de control. Para evitar que el plano de control se vea desbordado por demasiados paquetes de este tipo, se establece un límite de velocidad (o policer), por lo que vemos toda esa pérdida en los saltos intermedios, pero no en el salto final: se superaron los límites de velocidad del plano de control de los enrutadores en los saltos intermedios, por lo que no se devolvieron los paquetes de tipo 11 para los paquetes de traceroute que superaron esos límites, pero los paquetes pudieron llegar al destino sin problemas.
Pérdida de paquetes en la ruta de retorno | |||||||
---|---|---|---|---|---|---|---|
Comienza: 2020-04-08T13:32:30+0000 | |||||||
HOST: myrouter | % de pérdida | Snt | Último | Media | Mejor | Peor | StDev |
1.|-- 162.158.216.129 | 0,0 % | 10 | 0,7 | 6.9 | 0,7 | 62,6 | 19,6 |
2.|-- 118.69.221.209 | 0,0 % | 10 | 0.2 | 0,3 | 0.2 | 1,3 | 0,3 |
3.|-- 118.69.252.172 | 0,0 % | 10 | 0,7 | 1.0 | 0.6 | 2,9 | 0,7 |
4.|-- 118.69.132.169 | 0,0 % | 10 | 11,4 | 11.3 | 11.2 | 11,5 | 0,10 |
5.|-- 118.69.247.64 | 0,0 % | 10 | 34,2 | 34,4 | 33,9 | 37,2 | 1.0 |
6.|-- 13335.sgw.equinix.com | 50,0 % | 10 | 27,5 | 27,9 | 27,1 | 29,1 | 0.8 |
7.|-- 162.158.161.251 | 30,0 % | 10 | 26,8 | 26,8 | 26,8 | 26,8 | 0.0 |
Este ejemplo muestra la ruta de la red entre el enrutador inicial y 162.158.161.251. La salida muestra la pérdida de paquetes en los 2 últimos saltos.
MTR tiene muchas opciones. Puedes encontrar más en la página de ayuda de MTR: mtr --help
Algunas de las opciones más utilizadas son: