MTR significa Mi Traceroute.
Es una poderosa herramienta de diagnóstico de red que combina el poder de los comandos Ping y Traceroute.
Permite que el administrador diagnostique y aísle los errores de la red y proporcione informes útiles sobre el estado de la red.
En este artículo, explicaremos cómo instalar, usar y analizar el informe proporcionado por el comando MTR.
MTR funciona enviando paquetes ICMP aumentando gradualmente el valor TTL para encontrar la ruta entre el origen y el destino dado.
1. Instalación
En los sistemas Debian o Ubuntu, use el siguiente comando:
$ sudo apt-get install mtr
En los sistemas centos y fedora, ejecute el siguiente comando:
$ yum install mtr
2. Ejecutar mtr para un Dominio
MTR funciona en dos modos, un modo gráfico (X11) y un modo basado en texto (ncurses). De forma predeterminada, el comando mtr se ejecuta en modo X11.
$ mtr google.com
El comando anterior abrirá una ventana GUI y mostrará los resultados.
3. Inicie el modo de texto usando –curses
Use la opción –curses para ejecutar mtr en modo terminal.
$ mtr --curses google.com
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. mblaze.hilink 0.0% 20 3.2 2.7 2.1 3.8 0.5
2. 10.228.129.9 0.0% 20 187.7 61.8 41.6 187.7 31.3
3. 10.228.149.14 0.0% 20 112.1 60.2 33.2 112.1 17.8
4. 116.202.226.145 0.0% 20 57.9 63.2 35.2 147.6 24.4
5. 116.202.226.21 0.0% 20 35.4 70.4 35.4 211.8 48.6
6. 72.14.219.94 0.0% 20 58.9 74.6 43.4 231.2 44.2
7. 72.14.233.204 0.0% 20 46.9 69.8 40.3 222.5 41.9
8. 72.14.239.20 0.0% 20 94.1 259.2 68.8 3436. 748.2
9. 209.85.244.111 0.0% 20 86.4 97.5 72.1 232.2 34.3
10. google.com 0.0% 19 387.9 132.5 71.8 387.9 84.9 Lo anterior se ejecutará continuamente en modo interactivo.
En el modo interactivo, el resultado reflejará el tiempo de ida y vuelta actual para cada host. Del ejemplo anterior, el paquete viajó a través de "mblaze.hilink" (mi enrutador local), luego a través de una serie de "saltos" y llega al destino.
Los saltos son enrutadores o nodos en Internet a través de los cuales viaja el paquete para llegar al destino.
4. Omita el DNS inverso usando –no-dns
MTR encuentra el nombre de host de cada enrutador/nodo mediante la búsqueda inversa de DNS. Si desea evitar realizar una búsqueda inversa de DNS, utilice la opción –no-dns.
$ mtr --curses --no-dns google.com
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 2 3.0 2.9 2.9 3.0 0.1
2. 10.228.129.9 0.0% 2 58.6 49.6 40.7 58.6 12.7
3. 10.228.149.14 0.0% 2 46.1 46.8 46.1 47.6 1.0
4. 116.202.226.145 0.0% 2 61.8 61.6 61.3 61.8 0.3
5. 116.202.226.17 0.0% 2 42.7 39.9 37.0 42.7 4.0
6. 72.14.215.234 0.0% 2 47.1 43.9 40.7 47.1 4.5
7. 72.14.232.110 0.0% 2 56.9 60.7 56.9 64.4 5.3
8. 72.14.239.22 0.0% 2 111.5 95.0 78.5 111.5 23.3
9. 209.85.244.23 0.0% 2 126.0 102.4 78.8 126.0 33.4
10. 209.85.223.113 0.0% 10 76.4 92.7 75.4 157.3 29.5
11. 74.125.200.102 0.0% 1 78.4 78.4 78.4 78.4 0.0 5. Ejecute mtr en Modo Informe usando –report
En lugar de ejecutar MTR en modo interactivo, puede ejecutarlo en modo de informe utilizando –report. En el modo de informe, mtr se ejecutará durante el número de ciclos (predeterminado 10), y luego imprimirá las estadísticas y saldrá. Este modo será útil para generar estadísticas sobre la calidad de la red.
$ mtr --no-dns --report google.com HOST: lakshmanan Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.1.1 0.0% 10 2.5 3.0 2.4 4.2 0.6 2.|-- 10.228.129.9 0.0% 10 235.0 74.4 34.0 235.0 67.9 3.|-- 10.228.149.14 0.0% 10 154.8 65.5 38.7 154.8 34.8 4.|-- 116.202.226.145 0.0% 10 60.9 66.9 48.2 102.4 15.4 5.|-- 116.202.226.17 0.0% 10 54.1 65.1 36.0 194.5 46.8 6.|-- 72.14.215.234 0.0% 10 44.5 78.8 39.2 252.7 64.5 7.|-- 72.14.232.110 0.0% 10 55.7 66.4 39.1 179.8 41.8 8.|-- 66.249.94.72 0.0% 10 68.9 90.3 68.9 133.6 18.6 9.|-- 72.14.233.105 0.0% 10 68.8 76.3 68.8 92.2 7.3 10.|-- 173.194.38.162 0.0% 10 88.7 107.3 72.2 293.1 65.8
En el ejemplo anterior, mtr se ejecutó durante 10 ciclos y recopiló las estadísticas. Los usuarios pueden cambiar el número de ciclos usando la opción -c.
Comprender el informe MTR
Más allá de proporcionar información sobre la ruta entre el origen y el destino, MTR brinda valiosas estadísticas sobre la durabilidad de la conexión.
- Lost%:muestra el porcentaje de pérdida de paquetes en cada salto.
- Snt:muestra el número de paquetes que se envían.
- Último:latencia del último paquete enviado.
- Avg:latencia promedio de todos los paquetes.
- Mejor:muestra el mejor tiempo de ida y vuelta para un paquete a este host (RTT más corto).
- Wrst:muestra el peor tiempo de ida y vuelta de un paquete a este host (RTT más largo).
- StDev:proporciona la desviación estándar de las latencias para cada host.
Incluso si el "promedio" se ve bien, observe la desviación estándar. Si la desviación estándar es alta, entonces puede indicar que "Promedio" está sesgado por algún error de medición o demasiada fluctuación. En tal caso, observe la mejor y la peor latencia para asegurarse de que el promedio sea bueno.
Analizar informes MTR
1. Verificar pérdida de paquetes
Existe una práctica común entre los proveedores de servicios para "Limitar la velocidad" del tráfico ICMP. Esto puede proporcionar una ilusión de pérdida de paquetes, cuando en realidad no hay pérdida. Para verificar si la pérdida es real o se debe a una limitación de velocidad, verifique el "% de pérdida" del siguiente salto. Si muestra 0,0 %, entonces puede estar seguro de que el "% de pérdida" informado se debe a la limitación de la tasa ICMP y no a una pérdida real.
10.|-- 209.85.250.237 0.0% 10 85.6 97.5 76.0 172.0 27.2 11.|-- 209.85.250.203 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- 74.125.135.138 0.0% 10 77.2 107.3 77.2 219.5 43.5
En el resultado anterior, aunque muestra una pérdida del 100,0 % entre los saltos 10 y 11, el siguiente salto 12 informa una pérdida de paquetes del 0,0 %, lo que significa que la pérdida informada en el salto 11 solo se debe a la limitación de velocidad de ICMP.
Si la pérdida continúa durante más de 1 salto, es posible que haya alguna pérdida de paquetes. También tenga en cuenta que la limitación de velocidad y la pérdida de paquetes pueden ocurrir al mismo tiempo. En ese caso, tome el % de pérdida más bajo en una secuencia como pérdida real.
2. Redes de host de destino incorrectas
13.|-- 4.69.168.254 0.0% 10 293.3 304.7 276.0 441.0 48.5 14.|-- 4.69.161.105 10.0% 10 287.5 291.7 261.2 393.6 40.0 15.|-- 4.69.137.50 0.0% 10 412.2 299.2 266.9 412.2 48.6 16.|-- 4.69.134.146 10.0% 10 260.5 281.8 260.3 320.1 22.0 17.|-- 4.69.134.129 10.0% 10 294.7 303.5 268.0 397.8 41.8 18.|-- 4.69.132.177 10.0% 10 287.8 341.6 262.7 470.4 77.4 19.|-- 4.71.162.50 10.0% 10 280.8 276.0 257.8 323.2 21.3 20.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Del ejemplo anterior, puede parecer que los paquetes no llegaron a su destino. Pero llega a destino. Esto puede ser el resultado de reglas de host o firewall configuradas incorrectamente para descartar paquetes ICMP.
3. Problema de tiempo de espera y ruta de retorno
A veces, los enrutadores descartarán el ICMP y se mostrará como ??? en la salida. Alternativamente, también puede haber un problema con la ruta de retorno.
9.|-- 209.85.244.25 0.0% 10 260.6 147.0 78.1 260.6 75.3 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 11.|-- 74.125.200.100 0.0% 10 84.8 112.4 75.6 234.4 63.9
En el ejemplo anterior, el enrutador en el salto 10 no responde a ICMP o hay un problema en la ruta de retorno del paquete.