Supervisar la conectividad de la red es una parte importante de la administración del servidor. Pocas herramientas como ping, trazar ruta son fáciles de usar y proporcionan información valiosa. Hoy les mostraré otra poderosa herramienta de diagnóstico llamada MTR que combina las funcionalidades de traceroute y ping programas MTR significa My Traceroute - le permite investigar la conexión de red entre el host y el servidor remoto. También proporciona los cambios de latencia y rendimiento a lo largo del tiempo. A diferencia de traceroute y ping , MTR no viene de forma predeterminada. necesitas instalarlo:
Cómo instalar MTR:
En Ubuntu/Debian:
sudo apt-get install mtr
En CentOS/Redhat/Fedora:
Si está utilizando Redhat y no recibe actualizaciones de yum, siga cómo configurar yum para usar el repositorio de CentOS en un sistema Redhat.
yum install mtr Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile ---> Package mtr.x86_64 2:0.75-5.el6 will be installed --> Finished Dependency Resolution ... ... Installed: mtr.x86_64 2:0.75-5.el6 Complete!
Cómo usar el MTR
Una vez que se haya instalado correctamente, puede comenzar a usarlo escribiendo:
mtr google.com
Hay dos modos, un modo de interfaz gráfica y un modo basado en texto (ncurses ). El modo predeterminado es el modo de interfaz gráfica.
Cómo iniciar MTR en modo texto
Para especificar el modo basado en texto, debe usar el siguiente comando. El comando abre una interfaz de usuario basada en texto usando ncurses , que se ejecuta continuamente en modo interactivo.
mtr --curses google.com
Los paquetes (ICMP) viajan a través de una serie de “saltos” (Routers o Nodos) y llegan al destino. La salida puede parecer muy similar a traceroute, pero la gran ventaja sobre traceroute es que la salida se actualiza constantemente en el tiempo de ida y vuelta actual.
Cómo generar un informe usando MTR
El siguiente comando se emite para generar el informe, en lugar de ejecutarlo en modo interactivo. De forma predeterminada, MTR envía 10 paquetes al host de destino y tarda un tiempo en imprimir las estadísticas de la red. Puede cambiar el nro. de paquetes especificando la opción –report-cycles=[número-de-paquetes]. Este modo proporciona suficientes datos en un formato útil.
mtr --report google.com or mtr --report --report-cycles=12 google.com
Cómo evitar el DNS inverso
Durante el seguimiento de la red, MTR busca el nombre de host de cada esperanza (enrutador/nodo) mediante la búsqueda inversa de DNS. Si desea evitar realizar una búsqueda inversa de DNS, simplemente use la opción –no-dns:
mtr --no-dns google.com
Comprender el resultado del MTR
Más allá de la ruta entre el host y el servidor remoto, MTR proporciona estadísticas valiosas sobre la durabilidad de esa conexión en la séptima columna, como se ve en el siguiente resultado.
Loss %:muestra el porcentaje de pérdida de paquetes en cada salto.
Snt:muestra la cantidad de paquetes que se envían.
Last:latencia del último paquete enviado.
Avg:latencia promedio de todos paquetes.
Mejor:el mejor tiempo de ida y vuelta (más corto) de un paquete a este host.
Wrst:el peor tiempo de ida y vuelta (más largo) de un paquete a este host.
StDev:desviación estándar de las latencias a cada host.
Last, Prom, Best y Wrst se miden en milisegundos. Cuanto mayor era la desviación estándar, las mediciones de latencia eran inconsistentes.
Considere, por ejemplo, para comprender la oración anterior:de los 10 paquetes enviados a destino, algunos paquetes pueden tener una latencia baja de 25 ms, mientras que pocos tendrían una latencia alta de 350 ms. Después de promediar las latencias de los 10 paquetes enviados, el promedio parece normal pero, de hecho, es posible que no represente muy bien los datos. Por lo tanto, si la desviación estándar es alta, observe las mejores y peores columnas para las mediciones de latencia para asegurarse de que el promedio sea una buena representación de la latencia real y no el resultado de demasiadas fluctuaciones.
Análisis de informes MTR
Host de destino inalcanzable
Si el host de destino no está configurado correctamente o las reglas del firewall se configuraron para descartar los paquetes ICMP, verá que los paquetes no pudieron llegar al destino como se muestra a continuación. Pero, llega a su destino.
8. 10.118.225.253 0.0% 10 19.0 19.0 18.9 19.2 0.1 9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Cómo verificar la pérdida de paquetes
El proveedor de servicios sigue una práctica común de limitar el tráfico ICMP. Esto podría mostrarse como una pérdida de paquetes, cuando en realidad no hay pérdida. Puede verificar si la pérdida es real o se debe a una limitación de velocidad al verificar la columna % de pérdida del siguiente salto. Por ejemplo, en el siguiente informe, el siguiente salto de 100 % de pérdida muestra 0,0 %. Por lo tanto, es seguro que la pérdida se deba a la limitación de la tasa ICMP y no a la pérdida real.
5. 10.161.18.5 0.0% 5 14.7 14.5 14.4 14.7 0.1 6. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 7. 10.255.222.34 0.0% 5 14.1 14.0 13.9 14.2 0.2
Problema de tiempo de espera y ruta de retorno
Si alguno de los saltos muestra ??? en la salida, puede deberse a un problema en la ruta de retorno o, alternativamente, los enrutadores habrían descartado el paquete ICMP. A continuación, en el salto 6, puede ver ??? . Esto podría deberse a cualquiera de las razones anteriores.
5. 10.161.18.5 0.0% 5 14.7 14.5 14.4 14.7 0.1 6. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 7. 10.255.222.34 0.0% 5 14.1 14.0 13.9 14.2 0.2
Conclusión
MTR es de gran ayuda durante la resolución de problemas de una red interna o cuando se experimentan problemas de red. Con los informes de MTR, puede tener una idea de qué enrutadores/host en el camino hacia el host remoto o un dominio específico están causando el problema.