Come posso risolvere i problemi relativi alle prestazioni della rete Direct Connect?

Soluzione

Segui queste istruzioni per isolare e diagnosticare i problemi relativi alle prestazioni della rete e delle applicazioni:

Nota: è consigliabile configurare una macchina di test dedicata on-premises con un Amazon Virtual Private Cloud (Amazon VPC). Usa il tipo di istanza Amazon Elastic Compute Cloud (Amazon EC2) di dimensione C5 o superiore.

Identificazione di problemi di rete o applicativi

Installa e utilizza lo strumento iPerf3 per confrontare la larghezza di banda della rete e verificare i risultati con altre applicazioni o strumenti. Per ulteriori informazioni, consulta What is iPerf / iPerf3? sul sito Web iPerf.

1. Esegui il comando seguente per installare iPerf3:

   Linux/REHEL

   $ sudo yum install iperf3 -y

   Ubuntu

   $ sudo apt install iperf3 -y

2. Per misurare il throughput in modo bidirezionale, esegui iPerf3 sul client:

   Istanze di Amazon EC2 (server)

   $ iperf3 -s -V

   **Host locale on-premises (client) **

   $ 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.

Esempi di risultati del test 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

L'esempio precedente utilizza i seguenti termini:

• **Bitrate: **il throughput o la velocità di trasmissione misurata.
• Transfer: la quantità totale di dati scambiati tra client e server.
• Retry: il numero di pacchetti ritrasmessi. La ritrasmissione viene osservata dal lato del mittente.

Esempi di risultati del test 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

Lost è pari allo 0% dal lato del mittente perché viene inviata la quantità massima di datagrammi UDP. Lost/Total datagrams sul lato del ricevitore indica il numero di pacchetti persi e il tasso di perdita. In questo esempio, il 79% del traffico di rete viene perso.

Nota: se la connessione Direct Connect utilizza una rete privata virtuale Amazon (Amazon VPN) su un'interfaccia virtuale pubblica (VIF), esegui i test delle prestazioni senza la VPN.

Controllo delle metriche e dei contatori dell'interfaccia

Controlla le seguenti metriche in Amazon CloudWatch Logs:

• ConnectionErrorCount: applica la statistica di somma. Nota che valori diversi da zero indicano errori di livello MAC sul dispositivo AWS.
• ConnectionLightLevelTx e ConnectionLightLevelRx: le letture del segnale ottico devono essere comprese tra -14,4 e 2,50 dBm.
• ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress e VirtualInterfaceBpsIngress: Assicurati che il bitrate non abbia raggiunto la larghezza di banda massima.

Per ulteriori informazioni, consulta le metriche e le dimensioni di AWS Direct Connect.

Se utilizzi un VIF host che condivide la larghezza di banda totale con altri utenti, verifica con il proprietario di Direct Connect l'utilizzo della connessione.

Controlla le seguenti metriche di router e firewall nella posizione Direct Connect:

• CPU, memoria, utilizzo delle porte, cadute, scarti
• Usa mostra statistiche interfacce o simili per verificare la presenza di errori di input e output dell'interfaccia come CRC, frame, collisioni e carrier
• Pulisci o sostituisci il cavo patch in fibra e il modulo SFP per i contatori usurati

Controlla il Dashboard AWS Health per assicurarti che la connessione Direct Connect non sia in manutenzione.

Esegui MTR in modo bidirezionale per verificare il percorso di rete

Usa il comando Linux MTR per analizzare le prestazioni della rete. Per il sistema operativo Windows, è consigliabile attivare WSL 2, in modo da poter installare MTR su un sottosistema Linux. Scarica WinMTR dal sito Web di SourceForge.

1. Esegui il comando seguente per installare MTR:

   Installazione di Amazon Linux/REHEL

   $ sudo yum install mtr -y

   Installazione di Ubuntu

   $ sudo apt install mtr -y

2. Per la direzione on-premises ad AWS, esegui MTR sull'host locale (basato su 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. Per la direzione da AWS a on-premises, esegui MTR sull'istanza EC2 (basata su 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

Esempi di risultati del test 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

Ogni riga in un hop rappresenta un dispositivo di rete che il pacchetto di dati passa dall'origine alla destinazione. Per ulteriori informazioni su come leggere i risultati dei test MTR, consulta Reading MTR output network tool sul sito Web ExaVault.

L'esempio seguente mostra una connessione Direct Connect con i peer BGP 10.110.120.1 e 10.110.120.2. La percentuale di perdita viene osservata sul 4° e 5° hop di destinazione. Ciò può indicare un problema con la connessione Direct Connect o il router remoto 10.110.120.1. Poiché TCP ha la priorità rispetto a ICMP con la connessione Direct Connect, il risultato TCP MTR mostra una percentuale di perdita inferiore.

#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

L'esempio seguente mostra che la perdita di pacchetti del dispositivo NAT o del firewall locale è pari al 5%. La perdita di pacchetti influisce su tutti gli hop successivi, inclusa la destinazione.

$ 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

Acquisizione di un pacchetto e analisi dei risultati

Acquisisci un pacchetto sull’host locale e sull'istanza EC2. Usa l'utilità tcpdump o Wireshark per ottenere il traffico di rete per l'analisi. Il seguente comando di esempio tcpdump ottiene il timestamp e l'indirizzo IP dell'host:

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

Utilizza il calcolatore di throughput TCP sul sito Web di Switch per calcolare il limite di rete, il prodotto con ritardo di larghezza di banda e la dimensione del buffer TCP. Per ulteriori informazioni, consulta la sezione Troubleshooting AWS Direct Connect.

Informazioni correlate

Qual è la differenza tra un'interfaccia virtuale in hosting (VIF) e una connessione in hosting?
Che cos'è iPerf/IPerf3?