MTR una herramienta de diagnóstico de red
El artículo detalla el funcionamiento de MTR, proporciona algunos ejemplos de línea de comandos y explica los datos que genera. Al final, dada la salida, realizamos análisis de informes.
¿Cómo funciona MTR??
Herramientas de diagnóstico de red, como ping, traceroute y MTR sondea la conexión entre dos dispositivos con paquetes ICMP para solucionar problemas de conectividad de red. Mientras que la utilidad de ping utiliza ICMP ECHO_REQUEST y ECHO_REPLES, en contraste, Tracerute y MTR usan paquetes ICMP con TTL de tiempo de vida.
Para el análisis de lúpulo para hop, al principio, MTR establece direcciones de los interruptores, puertas de enlace y enrutadores entre los dispositivos locales y remotos. Luego, usa los paquetes ICMP con TTL para hacer ping a cada salto de modo que el TTL controla los nodos que alcanzará el paquete antes de morir. Por lo tanto, envía una serie de icmp echo_request con el TTL establecido a uno, dos, tres, y así sucesivamente hasta que MTR ensambla toda la ruta.
El proceso anterior emite estadísticas que contienen información adicional, como estado de lop, conexión de red, capacidad de respuesta de nodo, latencia de red y jitter. Lo más interesante, es similar al comando superior, ya que se mantiene refrescante con la conectividad de red en tiempo real.
Instalación de MTR
Por defecto, la herramienta vive en el /usuario/sbin directorio tal como viene preinstalado con la mayoría de las distribuciones. Si no está disponible, instale MTR con el administrador de paquetes predeterminado de la distribución.
Para Ubuntu:
ubuntu@ubuntu: ~ $ sudo apt -get -y install mtr
Para Rhel:
ubuntu@ubuntu: ~ $ sudo yum -y install mtr
Para el arco:
ubuntu@ubuntu: ~ $ sudo Pacman -y Install MTR
Generar y leer informes MTR en vivo
Como se muestra en las capturas de pantalla anteriores, aparte de listar lúpulos de red, MTR también realiza un seguimiento de la latencia. En otras palabras, también estima el tiempo de ida y vuelta desde la máquina local hasta cada dispositivo en la ruta.
Para una mejor idea, use el indicador de informes para generar un informe que constituye estadísticas sobre la calidad de la red. Los usuarios también pueden utilizar esto con la opción -c, ya que solo se ejecutará para el número de ciclos especificados por él y salir después de imprimir estadísticas.
ubuntu@ubuntu: ~ $ sudo mtr -r -c 5 google.comunicarse
La captura de pantalla anterior emite varios campos/columnas para acceder al tráfico de red. Estas columnas informan las siguientes estadísticas:
- %Pérdida: Porcentaje de pérdida de paquetes en cada máquina
- SNT: Número de paquetes enviados
- Último: El tiempo de ida y vuelta para el último paquete Traceroute
- AVG: El tiempo promedio de ida y vuelta para todas las sondas
- Mejor: El tiempo de ida y vuelta más corto de un paquete a un anfitrión en particular
- WRST: Tiempo de ida y vuelta más largo de un paquete a un anfitrión
- Stdev: Desviación estándar de latencias
El SNT a Fusil Las columnas miden las latencias en milisegundos, pero solo el Aviso La columna es más importante. El único inconveniente para generar informes para la calidad de la red es que utiliza un montón de tráfico de red que degrada el rendimiento de la red.
Opciones útiles
La siguiente sección contiene algunos de los ejemplos de comando de banderas MTR más útiles. Explicaremos los detalles de salida en la sección de lectura del informe MTR más adelante.
IPv6: MTR usa IPv6 como la opción predeterminada, que requiere incluida la dirección IP o el nombre de dominio del host de destino como argumento. Mostrará una salida en tiempo real Presione Ctrl+C o Q para salir:
ubuntu@ubuntu: ~ $ sudo mtr google.comunicarse
o
ubuntu@ubuntu: ~ $ sudo mtr 8.8.8.8
Solo ipv4: El conmutador IPv4 (-4) muestra solo direcciones IPv4 e incluye nombres de dominio totalmente calificados:
ubuntu@ubuntu: ~ $ sudo mtr -4 google.comunicarse
b: Para mostrar tanto los nombres de dominio como las direcciones IPv4, use el indicador -B de la siguiente manera:
ubuntu@ubuntu: ~ $ sudo mtr -b Google.comunicarse
C: Como se discutió anteriormente, la bandera limita el número de pings enviados a cada máquina. Después de completar el número de pings, detiene la actualización en vivo y sale MTR poco después:
ubuntu@ubuntu: ~ $ sudo mtr -c7 google.comunicarse
T/u: Reemplace los paquetes de eco ICMP con TCP SYN -T/-TCP o datagramas UDP -u/-udp:
ubuntu@ubuntu: ~ $ sudo mtr - -tcp google.comunicarse
o
ubuntu@ubuntu: ~ $ sudo mtr --udp google.comunicarse
o: Organice el campo de salida según sus requisitos. Por ejemplo, el comando dado muestra la salida de la siguiente manera:
ubuntu@ubuntu: ~ $ mtr -o "lsdr nbaw jmxi" 8.8.8.8
metro: Especifique el lúpulo entre el host local y la máquina remota. Los siguientes ejemplos establecen los lúpulos en 5, mientras que el valor predeterminado es 30:
ubuntu@ubuntu: ~ $ mtr -m 5 8.8.8.8
s: Probe la red especificando el tamaño del paquete ICMP, incluidos los encabezados IP/ICMP en bytes:
ubuntu@ubuntu: ~ $ mtr -s paquetsize -c 5 google.comunicarse
Análisis de informes
El análisis del informe de salida de MTR constituye principalmente o se centra en la pérdida de paquetes y la latencia de la red. Discutamos cada uno de estos en detalle:
Paquete perdido
El informe MTR genera un porcentaje del campo de pérdida de paquetes en cada salto para indicar un problema. Sin embargo, los proveedores de servicios tienen una práctica común de los paquetes MTR ICMP de límite de tasa que dan una ilusión de pérdida de paquetes, lo que no es cierto. Para identificar si la pérdida de paquete se debe realmente a la limitación de la tasa o no, tenga en cuenta la pérdida de paquete del salto posterior. Como en la captura de pantalla anterior, para -O Ejemplo de bandera, observamos una pérdida de paquetes de dieciséis.7% en el lúpulo 5 y 6. Si no hay pérdida de paquetes en el siguiente dispositivo, entonces resulta debido a la limitación de la velocidad.
En otro escenario, si los informes representan diferentes cantidades de pérdida en el lúpulo posterior inicial y los últimos dispositivos muestran el mismo porcentaje de pérdida de paquete, entonces la pérdida en las máquinas iniciales se debe a ambos factores: limitación de tasa y pérdida real. Por lo tanto, cuando MTR informa una pérdida de paquetes diferente en varios lúpulos, confíe en la pérdida en el salto posterior.
Latencia de conexion
La latencia de una red aumenta con el número de saltos entre dos puntos finales. Sin embargo, la latencia también depende de la calidad de la conexión de red entre las máquinas locales y remotas. Por ejemplo, las conexiones de acceso telefónico muestran una latencia más alta que los módems.
También es importante tener en cuenta que la latencia de la red no implica una ruta ineficiente. Independientemente de la alta latencia de la red en varios nodos, los paquetes pueden llegar al destino y volver a la fuente con pérdida cero.
En el ejemplo anterior, observamos un salto en la latencia desde el octavo salto en adelante, pero no se perdió ningún paquete excepto en el anfitrión de destino.
Conclusión
Comprender los conceptos básicos de MTR es necesario para obtener y descubrir los problemas de conectividad de red más comunes, como la configuración inadecuada de la red ISP/Residencial Router y Destination Host, TimeOuts y ICMP Tase Limiting. El artículo construye un terreno para que un usuario principiante comprenda el uso y el funcionamiento de MTR. También muestra cómo generar informes de MTR y realizar un análisis para identificar los problemas de pérdida de paquetes relacionados con la limitación de la velocidad y analizar la latencia de la red.