Wie kann ich den Paketverlust für meine Direct Connect-Verbindung beheben?

Auflösung

Paketverlust tritt auf, wenn übertragene Datenpakete ihr Ziel nicht erreichen, was zu Problemen mit der Netzwerkleistung führt. Paketverlust wird durch eine geringe Signalstärke am Ziel, übermäßige Systemauslastung, Netzwerküberlastung oder Fehlkonfigurationen der Netzwerkroute verursacht.

Führen Sie die folgenden Prüfungen für Ihre Netzwerkgeräte und die Direct Connect-Verbindung durch.

Informieren Sie sich im AWS Personal Health Dashboard über geplante Wartungsarbeiten oder Ereignisse

Das AWS Personal Health Dashboard zeigt relevante Informationen zu den Ressourcen, die derzeit gewartet werden, und enthält auch Benachrichtigungen für Aktivitäten. Weitere Informationen finden Sie unter Wie kann ich Benachrichtigungen über geplante Direct Connect-Wartungsarbeiten oder -Ereignisse erhalten?

Überprüfen Sie die Metriken für den Direct Connect-Endpunkt, das Kunden-Gateway und das Zwischengerät (Layer 1)

Bei einem Kunden-Gateway und Zwischengeräten kann das Problem lokal im lokalen Netzwerk oder auf dem Transitpfad zu AWS liegen. Überprüfen Sie auf dem lokalen Knoten und den Zwischengeräten Folgendes:

• Das Kunden-Gateway protokolliert Schnittstellenklappen
• CPU-Auslastung für das Kunden-Gateway, als das Problem auftrat
• Das auf dem Gerät angezeigte Lichtsignal, das die Direct Connect-Verbindung beendet
• Das Gerät, das die Direct Connect-Verbindung aufgrund von Eingabefehlern, inkrementellen Framing-Fehlern, CRC-Fehlern (zyklischer Redundanz), Runts, Giants oder Drosselungen beendet

Überprüfen Sie die Direct Connect-Verbindungsmetriken (Ebene 1)

Prüfen Sie, ob die folgenden Direct Connect-Metriken vorliegen:

• Anzahl der Verbindungsfehler: Wenden Sie die Summenstatistik für diese Metrik an. Beachten Sie, dass Werte, die nicht Null sind, auf MAC-Level-Fehler im AWS-Gerät hinweisen.
• Verbindung LightLeveltX und ConnectionLightLevelRX: Überprüfen Sie das Lichtsignal, das auf der Direct Connect-Verbindung aufgezeichnet wurde, als das Problem auftrat. Der akzeptable Bereich liegt zwischen -14,4 und 2,50 dBm.
• ConnectionBPSegress und ConnectionBPSInGress: Überprüfen Sie den Datenverkehr auf der Direct Connect-Verbindung, als der Paketverlust auftrat, um eine Überlastung der Verbindung festzustellen. Wenn Sie die Kapazität der Schnittstelle zu 100 % nutzen, kann es zu Paketverlusten und übermäßigem Datenverkehr kommen.

Weitere Informationen finden Sie unter Direct Connect-Verbindungsmetriken.

Prüfen Sie, ob asymmetrisches, suboptimales Routing vorhanden ist (Layer 3)

Asymmetrisches Routing tritt auf, wenn Netzwerkverkehr über eine Verbindung eingeht und über eine andere Verbindung wieder austritt. Dieses Routing kann zu Paketverlusten führen, wenn die lokale Firewall eine Unicast-Reverse-Path-Weiterleitung durchführt, wodurch der Netzwerkverkehr sinkt.

• Wenn Sie über eine redundante Backup-Direct Connect-Verbindung oder eine Backup-Verbindung mit AWS Site-to-Site VPN verfügen, überprüfen Sie, ob möglicherweise asymmetrisches Routing auftritt.
• Angenommen, Sie haben eine Backup-VPN-Verbindung von Standort zu Standort und haben ähnliche Präfixe sowohl für die Direct Connect- als auch für die VPN-Verbindungen angekündigt. In diesem Fall wird der Datenverkehr von AWS zu den lokalen Standorten über Direct Connect geleitet. Um asymmetrisches Routing zu vermeiden, stellen Sie sicher, dass Sie den Datenverkehr nur über Direct Connect von lokal an AWS senden.
• Wenn Sie eine Backup-Direct Connect-Verbindung haben, kann es zu asymmetrischem Routing kommen, je nachdem, wie Sie Ihre Präfixe über beide Direct Connect-Verbindungen bewerben.
• Ein suboptimales Routing mit dem lokalen Netzwerk kann zu Paketverlusten führen.

Weitere Informationen finden Sie unter Wie kann ich Probleme mit asymmetrischem Routing lösen, wenn ich ein VPN als Backup für Direct Connect in einem Transit-Gateway erstelle?

Durchgängige bidirektionale Trace-Route zwischen dem lokalen Host und dem AWS-Host (Layer 3)

Die Ausführung der Trace-Route zwischen den Hosts bestimmt den Netzwerkpfad, der in beide Richtungen zurückgelegt wird. Die Trace-Ergebnisse bestimmen auch, ob das Routing asymmetrisch, lastausgeglichen usw. ist.

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

Linux:

sudo yum install traceroute

Ubuntu:

sudo apt-get install traceroute

2.Führen Sie einen Befehl ähnlich dem folgenden für die TCP-Traceroute aus:

sudo traceroute -T -p <destination Port> <IP of destination host>

Windows-Betriebssystem:

1. Laden Sie WinPcap und tracetcp herunter.
2. Extrahieren Sie die Tracetcp ZIP-Datei.
3. Kopieren Sie tracetcp.exe auf Ihr Laufwerk C.
4. Installieren Sie WinPcap.
5. Öffnen Sie die Befehlszeile und rooten Sie WinPcap auf Ihrem Laufwerk C mit dem Befehl C:\ Users\ username>cd\.
6. Führen Sie tracetcp mit den folgenden Befehlen aus: tracetcp.exe hostname:port oder tracetcp.exe ip:port.

Durchgängiger bidirektionaler MTR-Test zwischen dem lokalen Host und dem AWS-Host (Layer 3)

MTR-Tests ähneln Traceroute, da sie die Erkennung jedes Routers im Netzwerkverbindungspfad zwischen den Hosts ermöglichen. MTR-Tests liefern auch Informationen zu jedem Knoten im Pfad, z. B. zum Paketverlust.

Überprüfen Sie die MTR-Ergebnisse auf Paketverlust und Netzwerklatenz. Ein prozentualer Netzwerkverlust bei einem Hop kann auf ein Problem mit dem Router hinweisen. Einige Dienstanbieter begrenzen den ICMP-Verkehr, den MTR verwendet. Um festzustellen, ob der Paketverlust auf Ratenbegrenzungen zurückzuführen ist, überprüfen Sie die nachfolgenden Hops. Weist der darauffolgende Hop einen Verlust von 0,0 % auf, kann dies auf eine Begrenzung der ICMP-Rate hindeuten.

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

Amazon Linux/REHEL:

$ sudo yum install mtr -y

Ubuntu:

sudo apt install mtr -y

Windows-Betriebssystem:

Herunterladen und installieren Sie WinMTR.

**Hinweis:**Für Windows-Betriebssysteme unterstützt WinMTR kein TCP-basiertes MTR.

2.Führen Sie MTR auf dem lokalen Host aus (ICMP- und TCP-basiert), um von der lokalen Verbindung zu AWS zu wechseln:

$ 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ühren Sie MTR auf der EC2-Instance aus (ICMP- und TCP-basiert), um von AWS auf die lokale Version umgeleitet zu werden:

$ 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

Überprüfen Sie den MTU-Pfad zwischen dem lokalen Host und dem AWS-Host (Layer 3)

Die maximale Übertragungseinheit (MTU) ist die Größe des größten zulässigen Pakets, das über die Netzwerkverbindung übertragen wurde. Jedes Paket, das größer als die MTU-Größe ist, wird auf der Schnittstelle gelöscht. Daher kann es zu Paketverlusten kommen, wenn das Paket zu groß ist.

Path MTU Discovery (PMTUD) bestimmt den MTU-Pfad. Weitere Informationen finden Sie unter Path MTU Discovery.

Sie können die Pfad-MTU zwischen zwei Hosts mithilfe von Tracepath überprüfen.

1.Führen Sie Tracepath auf Port 80 vom lokalen Host aus für die Weiterleitung von lokal zu AWS aus:

$ tracepath -n -p 80 <EC2 private instance IP>

2.Führen Sie Tracepath auf Port 80 von der EC2-Instance aus, um von AWS nach On-Premise weiterzuleiten:

$ tracepath -n -p 80 <private IP of local host>

Suchen Sie nach möglichen Routing-Problemen mit BGP

Die Direct Connect-Verbindung verwendet das dynamische Routing-Protokoll Border Gateway Protocol (BGP) für das Routing und die Kommunikation zwischen AWS und lokalen Systemen.

Suchen Sie nach regelmäßigen Flaps in BGP, die zu zeitweiligem Paketverlust führen könnten.

Prüfen Sie auf dem Kunden-Gateway-Gerät, wie alt die erlernten Routen von AWS zum Kundennetzwerk sind. Wenn die Routen auf dem Kunden-Gateway-Gerät aktualisiert werden, wird das Routenalter in der BGP-Routentabelle aktualisiert. Sie können diese Informationen überprüfen, um zu überprüfen, ob bei der Aktualisierung der Route kurzzeitig ein Paketverlust aufgetreten ist.

Führen Sie den folgenden Befehl aus, um das Routealter auf einem Cisco-Router zu überprüfen:

Router#sh ip bgp 1.1.1.1       
BGP routing table entry for 1.1.1.1/32, version 3
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  64512, (received & used)
    169.254.92.181 from 169.254.92.181 (169.254.92.181)
      Origin IGP, metric 100, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Mar 31 2023 08:08:00 UTC    >> Last time that the route was updated

-or-

Router#sh ip route | in 1.1.1.1
B    1.1.1.1 [20/100] via 169.254.92.181, 01:37:46   >> You can see the route age or when the route was last refreshed

Wenn Sie eine gehostete Verbindung verwenden, erkundigen Sie sich bei Ihrem Partner oder Dienstanbieter, ob Wartungsarbeiten auf deren Seite den Paketverlust verursacht haben.

Verwandte Informationen

Bewährte Methoden für die Konfiguration von Netzwerkschnittstellen

Wie kann ich Paketverlust und Latenz von AWS zu einem lokalen Netzwerk über ein Internet-Gateway oder NAT-Gateway überwachen?

Problembehandlung bei AWS Direct Connect

Wie kann ich Direct Connect-Netzwerkleistungsprobleme beheben? Laden Sie WinPcap und tracetcp herunter.