Wie kann ich Probleme mit der Direct-Connect-Netzwerkleistung beheben?

Behebung

Gehen Sie wie folgt vor, um Netzwerk- und Anwendungsleistungsprobleme zu isolieren und zu diagnostizieren:

Hinweis: Es hat sich bewährt, eine dedizierte Testmaschine on-premises mit einer Amazon Virtual Private Cloud (Amazon VPC) einzurichten. Verwenden Sie eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance vom Typ C5 oder größer.

Überprüfung auf Netzwerk- oder Anwendungsprobleme

Installieren und verwenden Sie das Tool iPerf3, um die Netzwerkbandbreite zu prüfen und die Ergebnisse mit anderen Anwendungen oder Tools zu vergleichen. Weitere Informationen finden Sie unter What is iPerf / iPerf3? auf der iPerf-Website.

1. Führen Sie den folgenden Befehl aus, um iPerf3 zu installieren:

   Linux/REHEL

   $ sudo yum install iperf3 -y

   Ubuntu

   $ sudo apt install iperf3 -y

2. Um den Durchsatz bidirektional zu messen, führen Sie iPerf3 auf dem Client aus:

   Amazon-EC2-Instance (Server)

   $ iperf3 -s -V

   On-Premises-Localhost (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.

Beispiel für TCP-Testergebnisse:

[ 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

Im obigen Beispiel werden die folgenden Begriffe verwendet:

• Bitrate: Der gemessene Durchsatz oder die Übertragungsgeschwindigkeit.
• Transfer: Die Gesamtmenge der zwischen Client und Server ausgetauschten Daten.
• Retry: Die Anzahl der wiederholt übertragenen Pakete. Erneute Übertragungen werden auf der Absenderseite beobachtet.

Beispiel für UDP-Testergebnisse:

[ 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 ist auf der Absenderseite 0 %, da die maximale Menge an UDP-Datagrammen gesendet wird. Lost/Total Datagrams auf der Empfängerseite gibt an, wie viele Pakete verloren gegangen sind und wie hoch die Verlustrate ist. In diesem Beispiel gehen 79 % des Datenverkehrs im Netzwerk verloren.

Hinweis: Wenn die Direct-Connect-Verbindung ein Amazon Virtual Private Network (Amazon VPN) über eine öffentliche virtuelle Schnittstelle (VIF) verwendet, führen Sie Leistungstests ohne VPN durch.

Überprüfen der Metriken und Schnittstellenzähler

Überprüfen Sie die folgenden Metriken In Amazon CloudWatch Logs:

• ConnectionErrorCount: Wenden Sie die Summenstatistik an. Beachten Sie, dass Werte, die nicht Null sind, auf MAC-Level-Fehler im AWS-Gerät hinweisen.
• ConnectionLightLevelTx und ConnectionLightLevelRx: Die optischen Signalwerte müssen im Bereich von -14,4 und 2,50 dBm liegen.
• ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress und VirtualInterfaceBpsIngress: Vergewissern Sie sich, dass die Bitrate nicht die maximale Bandbreite erreicht hat.

Weitere Informationen finden Sie unter AWS Direct Connect metrics and dimensions.

Wenn Sie eine gehostete VIF verwenden, die die gesamte Bandbreite mit anderen Benutzern teilt, erkundigen Sie sich beim Direct-Connect-Besitzer nach der Verbindungsauslastung.

Überprüfen Sie den Router und die Firewall am Direct-Connect-Standort auf die folgenden Metriken:

• CPU, Arbeitsspeicher, Portauslastung, Drops, Discards
• Verwenden Sie show interfaces statistics oder Ähnliches, um nach Schnittstelleneingabe- und -ausgabefehlern wie CRC, Frame, Collisions und Carrier zu suchen.
• Falls die Zähler abgenutzt sind, reinigen oder ersetzen Sie das Glasfaserkabel und das SFP-Modul.

Überprüfen Sie das AWS-Servicestatus-Dashboard, um sicherzustellen, dass die Direct-Connect-Verbindung aktuell nicht gewartet wird.

Bidirektionales Ausführen von MTR, um den Netzwerkpfad zu überprüfen

Verwenden Sie den MTR-Befehl von Linux, um die Netzwerkleistung zu analysieren. Für Windows-Betriebssysteme hat es sich bewährt, WSL 2 zu aktivieren, um MTR auf einem Linux-Subsystem installieren zu können. Laden Sie WinMTR von der SourceForge-Website herunter.

1. Führen Sie den folgenden Befehl aus, um MTR zu installieren:

   Installation auf Amazon Linux/REHEL

   $ sudo yum install mtr -y

   Installation auf Ubuntu

   $ sudo apt install mtr -y

2. Für die Richtung von On-Premises zu AWS führen Sie MTR auf dem lokalen Host aus (ICMP- und TCP-basiert):

   $ 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. Für die Richtung von AWS zu On-Premises führen Sie MTR auf der EC2-Instance aus (ICMP- und TCP-basiert):

   $ 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

Beispiel für MTR-Testergebnisse:

#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

Jede Zeile in einem Hop steht für ein Netzwerkgerät, das ein Datenpaket von der Quelle zum Ziel durchläuft. Weitere Informationen zum Lesen der MTR-Testergebnisse finden Sie unter Reading MTR Output Network Diagnostic Tool auf der ExaVault-Website.

Das folgende Beispiel zeigt eine Direct-Connect-Verbindung mit den BGP-Peers 10.110.120.1 und 10.110.120.2. Der prozentuale Verlust wird beim 4. und 5. Zielhop beobachtet. Dies kann auf ein Problem mit der Direct-Connect-Verbindung oder dem Remote-Router 10.110.120.1 hinweisen. Da TCP bei der Direct-Connect-Verbindung Vorrang vor ICMP hat, zeigt das TCP-MTR-Ergebnis einen geringeren prozentualen Verlust.

#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

Das folgende Beispiel zeigt den Paketverlust bei der lokalen Firewall oder dem NAT-Gerät bei 5 %. Der Paketverlust wirkt sich auf alle nachfolgenden Hops aus, einschließlich des Ziels.

$ 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

Durchführen einer Paketerfassung und Analysieren der Ergebnisse

Nehmen Sie eine Paketerfassung auf dem lokalen Host und der EC2-Instance vor. Verwenden Sie eines der Hilfsprogramme tcpdump oder Wireshark, um den Netzwerkdatenverkehr zur Analyse abzurufen. Der folgende tcpdump-Beispielbefehl ruft den Zeitstempel und die Host-IP-Adresse ab:

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

Verwenden Sie den TCP-Durchsatzrechner auf der Switch-Website, um das Netzwerklimit, das Verzögerungs-Bandbreiten-Produkt und die TCP-Puffergröße zu berechnen. Weitere Informationen finden Sie unter Troubleshooting AWS Direct Connect.

Ähnliche Informationen

Was ist der Unterschied zwischen einer gehosteten virtuellen Schnittstelle (VIF) und einer gehosteten Verbindung?
Was ist iPerf/iPerf3?