¿Cómo puedo solucionar los problemas de rendimiento de la red de Direct Connect?

Última actualización: 30/11/2021

Tengo problemas de bajo rendimiento y latencia del tráfico con mi conexión de AWS Direct Connect.

Resolución

Siga estas instrucciones para aislar y diagnosticar los problemas de rendimiento de la red y las aplicaciones.

Nota: Se recomienda configurar una máquina de prueba dedicada local y con Amazon Virtual Private Cloud (Amazon VPC). Utilice el tipo de instancia de Elastic Compute Cloud (Amazon EC2) con un tamaño C5 o superior.

Problema de red o aplicación

Puede instalar y utilizar la herramienta iPerf3 para comparar el ancho de banda de la red y verificar los resultados con otras aplicaciones o herramientas.

1.    Instalación de Linux/REHEL:

$ sudo yum install iperf3 -y

Instalación de Ubuntu:

$ sudo apt install iperf3 -y

2.    Ejecute iPerf3 en el cliente y el servidor para medir el rendimiento de forma bidireccional de manera similar a lo siguiente:

Instancia de Amazon EC2 (servidor):

$ iperf3 -s -V

Host local (cliente):

$ iperf3 -c <private IP of EC2> -P 15 -t 15
$ iperf3 -c <private IP of EC2> -P 15 -t 15 -R

$ iperf3 -c <private IP of EC2> -w 256K
$ iperf3 -c <private IP of EC2> -w 256K -R

$ iperf3 -c <private IP of EC2> -u -b 1G -t 15
$ iperf3 -c <private IP of EC2> -u -b 1G -t 15 -R 

----------------
-P, --parallel n
    number of parallel client threads to run; It is critical to run multi-threads to achieve the max throughput.
-R, --reverse
    reverse the direction of a test. So the EC2 server sends data to the on-prem client to measure AWS -> on-prem throughput.
-u, --udp
    use UDP rather than TCP. Since TCP iperf3 does not report loss, UDP tests are helpful to see the packet loss along a path.

Ejemplo de resultados de las pruebas de TCP:

[ ID] Interval          Transfer      Bitrate        Retry
[SUM] 0.00-15.00  sec  7.54 GBytes  4.32 Gbits/sec   18112   sender
[SUM] 0.00-15.00  sec  7.52 GBytes  4.31 Gbits/sec           receiver

Velocidad de bits: el rendimiento o la velocidad de transmisión medidos.

Transferencia: la cantidad total de datos intercambiados entre el cliente y el servidor.

Reintento: el número de paquetes retransmitidos. La retransmisión se observa en el lado del remitente.

Ejemplo de resultados de las pruebas de UDP:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5] 0.00-15.00  sec  8.22 GBytes   4.71 Gbits/sec  0.000 ms   0/986756 (0%)  sender
[  5] 0.00-15.00  sec  1.73 GBytes   989 Mbits/sec   0.106 ms   779454/986689 (79%)  receiver

La pérdida es del 0 % en el lado del remitente porque se envía la cantidad máxima de datagramas UDP.

Los datagramas perdidos/totales en el lado del receptor indican cuántos paquetes se pierden y la tasa de pérdida. En este ejemplo, se pierde el 79 % del tráfico de red.

Nota: Si la conexión Direct Connect utiliza una red privada virtual de Amazon (Amazon VPN) a través de una interfaz virtual pública (VIF), ejecute pruebas de rendimiento sin la VPN.

Comprobar las métricas y los contadores de interfaz

Consulte Amazon CloudWatch Logs para obtener las siguientes métricas:

  • ConnectionErrorCount: aplique la estadística de suma y tenga en cuenta que los valores distintos de cero indican errores de nivel MAC en el dispositivo de AWS.
  • ConnectionLightLevelTx y ConnectionLightLevelRx: asegúrese de que las lecturas de la señal óptica estén dentro del rango de -14,4 y 2,50 dBm.
  • ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress y VirtualInterfaceBpsIngress: asegúrese de que la velocidad de bits no haya alcanzado el ancho de banda máximo.

Para obtener más información, consulte Métricas y dimensiones de Direct Connect.

Si utiliza una interfaz virtual alojada (VIF alojada) que comparte el ancho de banda total con otros usuarios, consulte con el propietario de Direct Connect sobre la utilización de la conexión.

Verifique el enrutador y el firewall en la ubicación de Direct Connect para ver lo siguiente:

  • CPU, memoria, utilización de puertos, caídas, descartes.
  • Utilice “mostrar estadísticas de interfaces” o similar para verificar si hay errores de entrada y salida de la interfaz, como CRC, marco, colisiones y operador.
  • Limpie o reemplace el cable de conexión de fibra y el módulo SFP para contadores gastados.

Consulte AWS Personal Health Dashboard para asegurarse de que la conexión de Direct Connect no esté en mantenimiento.

Ejecutar MTR de forma bidireccional para comprobar la ruta de red

Puede utilizar el comando MTR de Linux para analizar el rendimiento de la red. Para el sistema operativo Windows, se recomienda habilitar WSL 2 a fin de poder instalar MTR en un subsistema Linux. Puede descargar WinMTR desde el sitio web de SourceForge.

1.    Instalación de Amazon Linux/REHEL:

$ sudo yum install mtr -y

Instalación de Ubuntu:

$ sudo apt install mtr -y

2.    Para la dirección local —> AWS, ejecute MTR en el host local (basado en ICMP y TCP):

$ mtr -n -c 100 <private IP of EC2> --report
$ mtr -n -T -P <EC2 instance open TCP port> -c 100 <private IP of EC2> --report

3.    Para la dirección AWS —> local, ejecute MTR en la instancia EC2 (basada en ICMP y TCP):

$ mtr -n -c 100 <private IP of the local host> --report
$ mtr -n -T -P <local host open TCP port> -c 100 <private IP of the local host> --report

Ejemplo de resultados de la prueba de MTR:

#ICMP based MTR results
$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

Cada línea en un salto representa un dispositivo de red que el paquete de datos pasa del origen al destino. Para obtener más información sobre cómo leer los resultados de las pruebas de MTR, consulte el sitio web de ExaVault.

El siguiente ejemplo muestra una conexión de Direct Connect con el par BGP 10.110.120.1 y 10.110.120.2. El porcentaje de pérdida se observa en el cuarto y quinto salto de destino. Esto puede indicar un problema con la conexión de Direct Connect o el enrutador remoto 10.110.120.1. El resultado de MTR de TCP muestra menos porcentaje de pérdida porque se prioriza TCP sobre ICMP con la conexión de Direct Connect.

#ICMP based MTR results
$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

El siguiente ejemplo muestra la pérdida de paquetes del firewall local o del dispositivo NAT al 5 %. La pérdida de paquetes afecta a todos los saltos posteriores, incluido el destino.

$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:11:22 2021
HOST:                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               5.0%   100    0.8   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               6.0%   100  265.7 267.1 265.6 307.8   5.1
  4.|-- 10.110.120.1               6.0%   100  265.1 265.2 265.0 265.4   0.0
  5.|-- 192.168.52.10              6.0%   100  266.7 266.6 266.5 267.2   0.0

Realizar una captura de paquetes y analizar los resultados

Realice una captura de paquetes en el host local y en la instancia EC2. Emplee la utilidad tcpdump o Wireshark para obtener el tráfico de red para su análisis. El siguiente comando de ejemplo tcpdump obtiene la marca de tiempo y la dirección IP del host:

tcpdump -i <network interface> -s0 -w $(date +"%Y%m%d_%H%M%S").$(hostname -s).pcap port <port>

Utilice la Calculadora de rendimiento TCP en el sitio web de Switch para calcular el límite de red, el producto de retardo de ancho de banda y el tamaño del búfer TCP.

Para obtener más información, consulte Solución de problemas de AWS Direct Connect.


¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?