Como posso solucionar problemas de desempenho de rede do Direct Connect?

Resolução

Para isolar e diagnosticar problemas de desempenho da rede e do aplicativo, conclua as seguintes etapas:

**Observação:**É uma prática recomendada configurar uma máquina de teste dedicada on-premises com uma Amazon Virtual Private Cloud (Amazon VPC). Use o tipo de instância do Amazon Elastic Compute Cloud (Amazon EC2) de tamanho C5 ou maior.

Análise de problemas de rede ou de aplicativos

Instale e use a ferramenta iPerf3 para avaliar a largura de banda da rede e verificar os resultados com outros aplicativos ou ferramentas. Para obter mais informações, consulte O que é iPerf/iPerf3?no site da iPerf.

1. Execute o comando a seguir para instalar o iPerf3:

   Linux/REHEL

   $ sudo yum install iperf3 -y

   Ubuntu

   $ sudo apt install iperf3 -y

2. Para medir o throughput bidirecionalmente, execute o iPerf3 no cliente:

   Iinstância do Amazon EC2 (servidor)

   $ iperf3 -s -V

   Localhost on-premises (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.

Exemplos de resultados do teste 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

O exemplo anterior usa os seguintes termos:

• Velocidade de bits: throughput ou velocidade de transmissão medida.
• Transferência: a quantidade total de dados trocados entre cliente e servidor.
• Repetição: o número de pacotes retransmitidos. A retransmissão é observada no lado do remetente.

Exemplos de resultados do teste 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

A perda é de 0% no lado do remetente porque a quantidade máxima de datagramas UDP é enviada. Os datagramas perdidos/totais no lado do destinatário mostram quantos pacotes são perdidos e a taxa de perda. Neste exemplo, 79% do tráfego da rede é perdido.

**Observação:**Se a conexão Direct Connect usar uma Amazon Virtual Private Network (Amazon VPN) em uma interface virtual pública (VIF), execute testes de desempenho sem a VPN.

Verifique as métricas e os contadores de interface

Verifique o Amazon CloudWatch Logs para ver as seguintes métricas:

• **ConnectionErrorCount:**Aplique a ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Statistics-definitions.html)estatística da soma[ . Observe que valores diferentes de zero indicam erros no nível MAC no dispositivo da AWS.
• ConnectionLightLevelTx e ConnectionLightLevelRx: As leituras do sinal óptico devem estar dentro da faixa de -14,4 e 2,50 dBm.
• ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress e VirtualInterfaceBpsIngress: Certifique-se de que a velocidade de bits não tenha atingido a largura de banda máxima.

Para obter mais informações, consulte as métricas e dimensões do AWS Direct Connect.

Se você usa uma VIF hospedada que compartilha a largura de banda total com outros usuários, consulte o proprietário do Direct Connect sobre a utilização da conexão.

Verifique o roteador e o firewall no local do Direct Connect para ver as seguintes métricas:

• CPU, memória, utilização de portas, quedas, descartes
• Use mostrar estatísticas de interfaces ou similares para verificar erros de entrada e saída da interface, como CRC, frame, colisões e portadora
• Limpe ou substitua o cabo de conexão de fibra e o módulo SFP para contadores desgastados

Verifique o AWS Health Dashboard para garantir que a conexão do Direct Connect não esteja em manutenção.

Execute o MTR bidirecionalmente para verificar o caminho da rede

Use o comando Linux MTR para analisar o desempenho da rede. Para o sistema operacional Windows, é uma prática recomendada ativar o WSL 2 para que você possa instalar o MTR em um subsistema Linux. Baixe o WinMTR do site SourceForge.

1. Execute o seguinte comando para instalar o MTR:

   Instalação do Amazon Linux/REHEL

   $ sudo yum install mtr -y

   **Instalação do Ubuntu **

   $ sudo apt install mtr -y

2. Para a direção on-premises para AWS, execute o MTR no host on-premises (baseado em ICMP e 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 a direção AWS para on-premises, execute o MTR na instância EC2 (baseada em ICMP e 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

Exemplo de resultados do teste 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 linha em um salto representa um dispositivo de rede que o pacote de dados passa da origem para o destino. Para obter mais informações sobre como ler os resultados do teste MTR, consulte Lendo a ferramenta de diagnóstico de rede de saída MTR no site da ExaVault.

O exemplo a seguir mostra uma conexão Direct Connect com os pares BGP 10.110.120.1 e 10.110.120.2. A porcentagem de perda é observada no 4º e 5º salto de destino. Isso pode indicar um problema com a conexão Direct Connect ou com o roteador remoto 10.110.120.1. Como o TCP é priorizado em relação ao ICMP com a conexão Direct Connect, o resultado do TCP MTR mostra uma porcentagem menor de perda.

#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

O exemplo a seguir mostra a perda de pacotes do firewall local ou do dispositivo NAT em 5%. A perda de pacotes afeta todos os saltos subsequentes, incluindo o 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

Faça uma captura de pacotes e analise os resultados

Faça uma captura de pacote no localhost e na instância do EC2. Use o utilitáriotcpdump ou Wireshark para obter tráfego de rede para análise. O seguinte exemplo de comando tcpdump obtém o carimbo de data/hora e o endereço IP do host:

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

Use a calculadora de TCP throughput no site do Switch para calcular o limite de rede, o produto com atraso de largura de banda e o tamanho do buffer TCP. Para obter mais informações, consulte Solução de problemas do AWS Direct Connect.

Informações relacionadas

Qual é a diferença entre uma interface virtual hospedada (VIF) e uma conexão hospedada?
O que é iPerf/ iPerf3?