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

Auflösung

Befolgen Sie diese Anweisungen, um Probleme mit der Netzwerk- und Anwendungsleistung zu isolieren und zu diagnostizieren.

Hinweis: Es ist eine bewährte Methode, ein dediziertes On-Premises-Testgerät und in einer Amazon Virtual Private Cloud (Amazon VPC) einzurichten. Verwenden Sie Elastic Compute Cloud (Amazon EC2) Instance-Typ der Größe C5 oder größer.

Netzwerk- oder Anwendungsproblem

Sie können das iPerf3-Tool installieren und verwenden, um die Netzwerkbandbreite zu messen und die Ergebnisse mit anderen Anwendungen oder Tools abzugleichen.

1.    Linux/REHEL-Installation:

$ sudo yum install iperf3 -y

Ubuntu-Installation:

$ sudo apt install iperf3 -y

2.    Führen Sie iPerf3 auf dem Client und dem Server aus, um den Durchsatz bidirektional zu messen, ähnlich wie im Folgenden beschrieben:

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

Bitrate - der gemessene Durchsatz oder die Übertragungsgeschwindigkeit.

Übertragung - die Gesamtmenge der zwischen Client und Server ausgetauschten Daten.

Wiederholung - die Anzahl der erneut gesendeten Pakete. Die Wiederholung der Übertragung wird auf der Senderseite 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

Der Verlust beträgt 0 % auf der Senderseite, da die maximale Anzahl von UDP-Datagrammen gesendet wird.

Verlorene/Gesamt-Datagramme auf der Seite des Receivers zeigen an, wie viele Pakete verloren gegangen sind und wie hoch die Verlustrate ist. In diesem Beispiel gehen 79 % des Netzverkehrs 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 das VPN durch.

Prüfen Sie die Metriken und Schnittstellenzähler

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

• ConnectionErrorCount: Wenden Sie die Summenstatistik an und beachten Sie, dass Werte ungleich Null auf MAC-Level-Fehler auf dem AWS-Gerät hinweisen.
• ConnectionLightLevelTx und ConnectionLightLevelRx: Vergewissern Sie sich, dass die Messwerte des optischen Signals innerhalb des Bereichs von -14,4 und 2,50 dBm liegen.
• ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress und VirtualInterfaceBpsIngress: Stellen Sie sicher, dass die Bitrate nicht die maximale Bandbreite erreicht hat.

Weitere Informationen finden Sie unter Direct Connect Metriken und Dimensionen.

Wenn Sie eine gehostete virtuelle Schnittstelle (Hosted VIF) verwenden, bei der die Gesamtbandbreite mit anderen Benutzern geteilt wird, erkundigen Sie sich beim Eigentümer von Direct Connect nach der Auslastung der Verbindung.

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

• CPU, Speicher, Portauslastung, Ausfälle, Verwerfungen.
• Verwenden Sie "Schnittstellenstatistiken anzeigen" oder eine ähnliche Funktion, um Schnittstellen-Eingangs- und -Ausgangsfehler wie CRC, Rahmen, Kollisionen und Träger zu überprüfen.
• Reinigen oder ersetzen Sie das Glasfaser-Patchkabel und das SFP-Modul bei abgenutzten Zählern.

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

Führen Sie die MTR bidirektional aus, um den Netzwerkpfad zu überprüfen

Sie können den Linux-Befehl MTR verwenden, um die Netzwerkleistung zu analysieren. Für Windows-Betriebssysteme empfiehlt es sich, WSL 2 zu aktivieren, damit Sie MTR auf einem Linux-Subsystem installieren können. Sie können WinMTR von der SourceForge-Website downloaden.

1.    Amazon Linux/REHEL-Installation:

$ sudo yum install mtr -y

Ubuntu-Installation:

$ sudo apt install mtr -y

2.    Für die On-Premises --> AWS-Richtung, 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 AWS --> On-Premises Richtung, 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 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 stellt ein Netzwerkgerät dar, das das Datenpaket von der Quelle zum Ziel weiterleitet. Weitere Informationen zum Lesen der MTR-Testergebnisse finden Sie auf der ExaVault-Website.

Das folgende Beispiel zeigt eine Direct Connect-Verbindung mit dem BGP-Peer 10.110.120.1 und 10.110.120.2. Der prozentuale Verlust wird beim 4. und 5. Ziel-Hop beobachtet. Dies kann auf ein Problem mit der Direct Connect-Verbindung oder dem entfernten Router 10.110.120.1 hinweisen. Das TCP-MTR-Ergebnis zeigt einen geringeren Verlustprozentsatz, da TCP mit der Direct Connect-Verbindung vor ICMP priorisiert wird.

#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 der lokalen Firewall oder des NAT-Geräts bei 5 %. Der Paketverlust wirkt sich auf alle nachfolgenden Hops einschließlich des Ziels aus.

$ 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

Nehmen Sie eine Paketerfassung vor und analysieren Sie die Ergebnisse

Nehmen Sie eine Paketerfassung auf dem localhost und der EC2-Instance vor. Verwenden Sie das Dienstprogramm tcpdump oder Wireshark, um den Netzwerkverkehr für die Analyse abzurufen. Mit dem folgenden tcpdump-Beispielbefehl werden der Zeitstempel und die Host-IP-Adresse abgerufen:

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 Netzwerklimit, Bandbreitenverzögerungsprodukt und TCP-Puffergröße zu berechnen.

Weitere Informationen finden Sie unter Problembehandlung bei AWS Direct Connect.

---

Relevante Informationen

Wodurch unterscheidet sich eine gehostete virtuelle Schnittstelle (VIF) von einer gehosteten Verbindung?