AWS Builder Center: Learn, Build and Connect with builders in the AWS community

AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.

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

Lesedauer: 8 Minute

Meine AWS-Direct-Connect-Verbindung weist Leistungsprobleme auf, darunter niedrigen Durchsatz, Verkehrslatenz und Paketverlust.

Lösung

Hinweis: Es hat sich bewährt, einen dedizierten On-Premises-Testcomputer mit einer Amazon Virtual Private Cloud (Amazon VPC) einzurichten. Verwende einen Amazon Elastic Compute Cloud (Amazon EC2)-Instance-Typ der Größe C5 oder größer.

Überprüfung auf Netzwerk- oder Anwendungsprobleme

Verwende das iPerf3-Tool, um die Netzwerkbandbreite zu messen und die Ergebnisse mit anderen Anwendungen oder Tools zu vergleichen. Weitere Informationen findest du unter What is iPerf / iPerf3? (Was ist iPerf/iPerf3?) auf der iPerf-Website.

Gehe wie folgt vor:

Um IPerf3 zu installieren, führe einen der folgenden Befehle für das Betriebssystem aus, das du verwendest.

Linux und Red Hat Enterprise Linux (RHEL):
```
sudo yum install iperf3 -y
```
Ubuntu:
```
sudo apt install iperf3 -y
```

Um den Durchsatz bidirektional zu messen, führe die folgenden iPerf3-Befehle für den Server und 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

Hinweis: -P setzt parallele Threads für maximalen Durchsatz. -R kehrt die Testrichtung um und -u verwendet das User Datagram Protocol (UDP) anstelle von TCP, um den Paketverlust zu messen.

In den folgenden Beispiel-TCP-Testergebnissen ist Bitrate der gemessene Durchsatz oder die Übertragungsgeschwindigkeit. Transfer ist die Gesamtmenge an Daten, die zwischen Client und Server ausgetauscht wird. Retry (Wiederholungsversuch) ist die Anzahl der erneut übertragenen Pakete. Die erneute Übertragung erfolgt auf der Absenderseite:

[ 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

In den folgenden Beispiel-UDP-Testergebnissen liegt Lost (Verloren) auf der Absenderseite bei 0 %. Dies liegt daran, dass das Paar Sender (ID) und Empfänger (5) die maximale Anzahl von UDP-Datagrammen gesendet hat. Lost/Total datagrams (Datagramme „Verloren/Gesamtzahl“) zeigt, wie viele Pakete der Empfänger verloren hat und wie hoch die Verlustrate ist. In diesem Beispiel hat der Empfänger 79 % des Netzwerkdatenverkehrs verloren:

[ 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

Hinweis: Wenn die Direct-Connect-Verbindung AWS Site-to-Site VPN über eine öffentliche virtuelle Schnittstelle verwendet, führe Leistungstests ohne VPN durch.

Metriken und Schnittstellenzähler anzeigen

Verwende Amazon CloudWatch Logs, um Metriken anzuzeigen, die dir bei der Problembehandlung helfen können. Sieh dir beispielsweise ConnectionErrorCount an und suche nach Werten ungleich Null, die einen Media Access Control (MAC)-Fehler auf einem AWS-Gerät anzeigen. Du kannst die Summenstatistik für die ConnectionErrorCount-Metrik verwenden.

Zeige ConnectionLightLevelTx and ConnectionLightLevelRx an, um zu überprüfen, ob die optischen Signalwerte im Bereich von –14,4 und 2,50 dBm liegen.

Zeige ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress und VirtualInterfaceBpsIngress an, um sicherzustellen, dass die Bitrate nicht die maximale Bandbreite erreicht hat.

Weitere Informationen findest du unter Direct-Connect-Metriken und -Dimensionen.

Wenn du eine gehostete virtuelle Schnittstelle verwendest, die die gesamte Bandbreite mit anderen Benutzern teilt, frage den/die Direct-Connect-Eigentümer:in nach der Verbindungsnutzung. Weitere Informationen findest du unter Hybrid-Netzwerkverbindungen.

Überprüfe den Router und die Firewall am Direct-Connect-Standort auf die folgenden Probleme:

Achte auf Unregelmäßigkeiten bei CPU, Arbeitsspeicher, Portauslastung, Ausfällen und verworfenen Daten.
Führe den Befehl show interfaces statistics aus, um Ein- und Ausgangsfehler der Schnittstelle zu identifizieren, z. B. Cyclic Redundancy Check (CRC), Frame-, Konflikt- und Netzwerkbetreiberfehler.
Reinige oder ersetze bei vermehrten Schnittstellenfehlern das Glasfaser-Patchkabel und das Small Form-factor Pluggable (SFP)-Modul.

Prüfe außerdem, ob für Direct Connect eine Wartung geplant ist.

MTR bidirektional ausführen, um den Netzwerkpfad zu überprüfen

Führe den My Traceroute (MTR)-Befehl für Linux aus, um die Netzwerkleistung zu analysieren. Für Windows hat es sich bewährt, WSL 2 zu aktivieren, um MTR auf einem Linux-Subsystem installieren zu können. Weitere Informationen findest du unter Neuerungen in WSL 2 auf der Microsoft-Website. Du kannst WinMTR von der SourceForge-Website herunterladen.

Gehe wie folgt vor, um MTR bidirektional auszuführen:

Um MTR zu installieren, führe einen der folgenden Befehle für dein Betriebssystem aus:

Amazon Linux/RHEL:

sudo yum install mtr -y

Ubuntu:

sudo apt install mtr -y

Führe für die Richtung von On-Premises zu AWS 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

Führe für die Richtung von AWS zu On-Premises 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

Der folgende Beispielbefehl und die folgende Ausgabe zeigen ICMP-basierte MTR-Ergebnisse:

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

Der folgende Beispielbefehl und die folgende Ausgabe zeigen TCP-basierte MTR-Ergebnisse:

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

In den vorherigen Ergebnissen steht jede Zeile in einem Hop für ein Netzwerkgerät für ein Datenpaket, das von der Quelle zum Ziel übertragen wird. Weitere Informationen zum Lesen der MTR-Testergebnisse findest du unter Reading MTR output network diagnostic tool (Lesen des MTR-Ausgangsnetzwerk-Diagnosetools) auf der ExaVault-Website.

Der folgende Beispielbefehl und die folgende Ausgabe zeigen ICMP-basierte MTR-Ergebnisse:

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

Der folgende Beispielbefehl und die folgende Ausgabe zeigen TCP-basierte MTR-Ergebnisse:

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

Die vorherigen Beispiele zeigen eine Direct-Connect-Verbindung mit den Border Gateway Protocol (BGP)-Peers 10.110.120.1 und 10.110.120.2. Beim vierten und fünften Ziel-Hop gibt es einen Verlustprozentsatz, der auf ein Problem mit der Direct-Connect-Verbindung oder dem Remote-Router 10.110.120.1 hinweist. Da eine Direct-Connect-Verbindung TCP gegenüber ICMP priorisiert, weist ein TCP-MTR-Ergebnis einen geringeren Verlustprozentsatz auf.

Der folgende Beispielbefehl und die folgende Ausgabe zeigen den Paketverlust der lokalen Firewall oder des NAT-Geräts 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ührung einer Paketerfassung und Analyse der Ergebnisse

Nimm eine Paketerfassung auf dem lokalen Host und der EC2-Instance vor. Verwende das tcpdump- oder Wireshark-Hilfsprogramm, um den Netzwerkdatenverkehr für eine Analyse abzurufen. Weitere Informationen zu tcpdump findest du unter tcpdump auf der tcpdump-Website. Um Wireshark herunterzuladen, besuche die Wireshark-Download-Seite auf der Wireshark-Website.

Führe beispielsweise den folgenden tcpdump-Befehl aus, um den Zeitstempel und die Host-IP-Adresse abzurufen:

tcpdump -i YOUR_NETWORK_INTERFACE  -s0 -w $(date +"%Y%m%d_%H%M%S").$(YOUR_HOSTNAME -s).pcap port YOUR_PORT

Hinweis: Ersetze YOUR_NETWORK_INTERFACE durch deine Netzwerkschnittstelle, YOUR_HOSTNAME durch deinen Hostnamen und YOUR_PORT durch deinen Port.

Verwende den TCP-Durchsatzrechner auf der Switch-Website, um das Netzwerklimit, das Produkt für die Bandbreitenverzögerung und die TCP-Puffergröße zu berechnen. Weitere Informationen findest du unter Problembehandlung bei Direct Connect.

Relevanter Inhalt

Wie richte ich eine dedizierte Verbindung in Direct Connect ein?
AWS OFFICIALAktualisiert vor 9 Monaten
Wie erhöhe ich die Bandbreite meiner dedizierten Verbindung in Direct Connect?
AWS OFFICIALAktualisiert vor 9 Monaten
Wie kann ich Probleme mit asymmetrischem Routing lösen, wenn ich ein VPN als Backup für Direct Connect in einem Transit-Gateway erstelle?
AWS OFFICIALAktualisiert vor 3 Jahren
Wie behebe ich Probleme mit der Direct Connect-Verbindung, bei denen das optische Tx/Rx-Signal keine oder nur geringe Lichtwerte empfängt?
AWS OFFICIALAktualisiert vor 10 Monaten