AWS Outposts-Checkliste zur Fehlersuche in Racknetzwerken

Verwenden Sie diese Checkliste, um Probleme mit einem Service-Link zu beheben, der den Status DOWN hat.

Konnektivität mit Outpost-Netzwerkgeräten

Überprüfen Sie den BGP-Peering-Status auf den lokalen Netzwerkgeräten des Kunden, die mit den Outpost-Netzwerkgeräten verbunden sind. Wenn der BGP-Peering-Status DOWN lautet, gehen Sie wie folgt vor:

1. Pingen Sie die Remote-Peer-IP-Adresse auf den Outpost-Netzwerkgeräten von den Kundengeräten aus. Sie finden die Peer-IP-Adresse in der BGP-Konfiguration Ihres Geräts. Sie können sich auch auf die Checkliste zur Netzwerkbereitschaft beziehen, die Ihnen zum Zeitpunkt der Installation zur Verfügung gestellt wurden.

2. Wenn das Pingen nicht erfolgreich ist, überprüfen Sie die physische Verbindung und stellen Sie sicher, dass der Verbindungsstatus UP lautet.

   1. Bestätigen Sie den LACP-Status der lokalen Netzwerkgeräte des Kunden.

   2. Überprüfen Sie den Schnittstellenstatus auf dem Gerät. Wenn der Status UP lautet, fahren Sie mit Schritt 3 fort.

   3. Überprüfen Sie die lokalen Netzwerkgeräte des Kunden und vergewissern Sie sich, dass das optische Modul funktioniert.

   4. Tauschen Sie defekte Glasfasern aus und stellen Sie sicher, dass sich die Lichter (Tx/Rx) innerhalb eines akzeptablen Bereichs befinden.

3. Wenn das Pingen erfolgreich ist, überprüfen Sie die lokalen Netzwerkgeräte des Kunden und stellen Sie sicher, dass die folgenden BGP-Konfigurationen korrekt sind.

   1. Vergewissern Sie sich, dass die lokale Autonome Systemnummer (Kunden-ASN) korrekt konfiguriert ist.

   2. Vergewissern Sie sich, dass die entfernte Autonome Systemnummer (Outpost ASN) korrekt konfiguriert ist.

   3. Vergewissern Sie sich, dass die Schnittstellen-IP und die Remote-Peer-IP-Adressen korrekt konfiguriert sind.

   4. Vergewissern Sie sich, dass die beworbenen und empfangenen Routen korrekt sind.

4. Wenn Ihre BGP-Sitzung zwischen dem Status Aktiv und dem Status Connect hin- und herschwankt, stellen Sie sicher, dass der TCP-Port 179 und andere relevante kurzlebige Ports auf den lokalen Netzwerkgeräten des Kunden nicht blockiert sind.

5. Wenn Sie weitere Probleme beheben müssen, überprüfen Sie Folgendes auf den lokalen Netzwerkgeräten des Kunden:

   1. BGP- und TCP-Debug-Protokolle

   2. BGP-Logs

   3. Paketerfassung

6. Wenn das Problem weiterhin besteht, führen Sie MTR/traceroute/-Paketerfassungen von Ihrem mit Outpost verbundenen Router zu den Peer-IP-Adressen der Outpost-Netzwerkgeräte durch. Teilen Sie die Testergebnisse mithilfe Ihres Enterprise-Supportplans mit dem AWS-Support.

Wenn zwischen den lokalen Netzwerkgeräten des Kunden und den Outpost-Netzwerkgeräten der BGP-Peering-Status UP besteht, der Service-Link jedoch weiterhin DOWN ist, können Sie weitere Probleme beheben, indem Sie die folgenden Geräte auf den lokalen Netzwerkgeräten Ihres Kunden überprüfen. Verwenden Sie je nach Bereitstellungsart Ihrer Service Link-Konnektivität eine der folgenden Checklisten.

• Edge-Router, verbunden mit AWS Direct Connect – Öffentliche virtuelle Schnittstelle, die für Service Link-Konnektivität verwendet wird. Weitere Informationen finden Sie unter AWS Direct Connect öffentliche virtuelle Schnittstellenverbindung zur AWS-Region.

• Edge-Router, verbunden mit AWS Direct Connect – Private virtuelle Schnittstelle, die für die Service Link-Konnektivität verwendet wird. Weitere Informationen finden Sie unter AWS Direct Connect private virtuelle Schnittstellenverbindung zur AWS-Region.

• Edge-Router, die mit Internetdienstanbietern (ISPs) verbunden sind – Öffentliches Internet, das für die Service Link-Konnektivität verwendet wird. Weitere Informationen finden Sie unter ISP öffentliche virtuelle Schnittstellenverbindung zur AWS-Region.

AWS Direct Connect öffentliche virtuelle Schnittstellenverbindung zur AWS-Region

Verwenden Sie die folgende Checkliste für die Fehlersuche bei Edge-Routern, die mit AWS Direct Connect verbunden sind, wenn eine öffentliche virtuelle Schnittstelle für Service-Link-Konnektivität verwendet wird.

1. Vergewissern Sie sich, dass die Geräte, die eine direkte Verbindung zu den Outpost-Netzwerkgeräten herstellen, die IP-Adressbereiche von Service Link über BGP empfangen.

   1. Bestätigen Sie die Routen, die über BGP von Ihrem Gerät empfangen werden.

   2. Überprüfen Sie die Routentabelle der Service Link Virtual Routing and Forwarding Instance (VRF). Die Anzeige sollte zeigen, dass der IP-Adressbereich verwendet wird.

2. Um die Konnektivität der Region sicherzustellen, überprüfen Sie die Routing-Tabelle für den Service Link VRF. Sie sollte die öffentlichen AWS-IP-Adressbereiche oder die Standardroute enthalten.

3. Wenn Sie die öffentlichen AWS-IP-Adressbereiche nicht im Service Link VRF erhalten, überprüfen Sie die folgenden Punkte.

   1. Überprüfen Sie den AWS Direct Connect-Verbindungsstatus vom Edge-Router oder der AWS Management Console.

   2. Wenn die physische Verbindung UP ist, überprüfen Sie den BGP-Peering-Status vom Edge-Router aus.

   3. Wenn der BGP-Peering-Status DOWN lautet, pingen Sie die AWS-Peer-IP-Adresse an und überprüfen Sie die BGP-Konfiguration im Edge-Router. Weitere Informationen finden Sie unter AWS Direct Connect-Fehlerbehebung im AWS Direct Connect-Benutzerhandbuch und Meine virtuelle Schnittstelle BGP-Status ist down in der AWS-Konsole. Was soll ich tun?.

   4. Wenn BGP eingerichtet ist und Sie die Standardroute oder die öffentlichen AWS-IP-Adressbereiche nicht in der VRF sehen, wenden Sie sich mithilfe Ihres Enterprise-Supportplans an den AWS-Support.

4. Wenn Sie eine On-Premises-Firewall haben, überprüfen Sie die folgenden Elemente.

   1. Vergewissern Sie sich, dass die für die Service Link-Konnektivität erforderlichen Ports in den Netzwerk-Firewalls zulässig sind. Verwenden Sie Traceroute auf Port 443 oder ein anderes Tool zur Netzwerkfehlerbehebung, um die Konnektivität zwischen den Firewalls und Ihren Netzwerkgeräten zu überprüfen. Die folgenden Ports müssen in den Firewall-Richtlinien für die Service Link-Konnektivität konfiguriert werden.

      • TCP-Protokoll – Quellport: TCP 1025-65535, Zielport: 443.

      • UDP-Protokoll – Quellport: TCP 1025-65535, Zielport: 443.

   2. Wenn die Firewall statusbehaftet ist, stellen Sie sicher, dass die Regeln für ausgehende Nachrichten den Service-Link-IP-Adressbereich des Outpost den öffentlichen AWS-IP-Adressbereichen zuordnen. Weitere Informationen finden Sie unter AWS Outposts-Konnektivität zu AWS-Regionen.

   3. Wenn die Firewall nicht statusbehaftet ist, stellen Sie sicher, dass auch der eingehende Datenfluss zugelassen ist (von den öffentlichen AWS-IP-Adressbereichen bis zum IP-Adressbereich des Service Links).

   4. Wenn Sie in den Firewalls einen virtuellen Router konfiguriert haben, stellen Sie sicher, dass das entsprechende Routing für den Datenverkehr zwischen dem Outpost und der AWS-Region konfiguriert ist.

5. Wenn Sie NAT im On-Premises-Netzwerk so konfiguriert haben, dass die Service Link-IP-Adressbereiche des Outpost in Ihre eigenen öffentlichen IP-Adressen übersetzt werden, überprüfen Sie die folgenden Punkte.

   1. Vergewissern Sie sich, dass das NAT-Gerät nicht überlastet ist und über freie Ports für neue Sitzungen verfügt.

   2. Vergewissern Sie sich, dass das NAT-Gerät für die Adressübersetzung korrekt konfiguriert ist.

6. Wenn das Problem weiterhin besteht, führen Sie MTR/traceroute/-Paketerfassungen von Ihrem Edge-Router zu den AWS Direct Connect-Peer-IP-Adressen durch. Teilen Sie die Testergebnisse mithilfe Ihres Enterprise-Supportplans mit dem AWS-Support.

AWS Direct Connect private virtuelle Schnittstellenverbindung zur AWS-Region

Verwenden Sie die folgende Checkliste, um Fehler bei Edge-Routern zu beheben, die mit AWS Direct Connect verbunden sind, wenn eine private virtuelle Schnittstelle für Service Link-Konnektivität verwendet wird.

1. Wenn für die Konnektivität zwischen dem Outpost-Rack und der AWS-Region die private Konnektivitätsfunktion AWS Outposts verwendet wird, überprüfen Sie die folgenden Punkte.

   1. Pingen Sie die Remote-Peering-IP-Adresse von AWS vom Edge-Router aus an und bestätigen Sie den BGP-Peering-Status.

   2. Stellen Sie sicher, dass BGP-Peering über die private virtuelle AWS Direct Connect-Schnittstelle zwischen Ihrem Service-Link-Endpunkt VPC und dem in Ihren Räumlichkeiten installierten Outpost UP ist. Weitere Informationen finden Sie unter AWS Direct Connect-Fehlerbehebung im AWS Direct Connect-Benutzerhandbuch und Meine virtuelle Schnittstelle BGP-Status ist down in der AWS-Konsole. Was sollte ich tun?, und Wie kann ich BGP-Verbindungsprobleme über Direct Connect beheben? .

   3. Die private virtuelle AWS Direct Connect-Schnittstelle ist eine private Verbindung zu Ihrem Edge-Router an Ihrem ausgewählten AWS Direct Connect-Standort und verwendet BGP, um Routen auszutauschen. Ihr CIDR-Bereich für Ihre private Virtual Private Cloud (VPC) wird über diese BGP-Sitzung auf Ihrem Edge-Router angekündigt. In ähnlicher Weise wird der IP-Adressbereich für den Outpost-Service Link der Region über BGP von Ihrem Edge-Router aus bekannt gegeben.

   4. Vergewissern Sie sich, dass die Netzwerk-ACLs, die dem privaten Service Link-Endpunkt in Ihrer VPC zugeordnet sind, den entsprechenden Datenverkehr zulassen. Weitere Informationen finden Sie unter Checkliste zur Netzwerkbereitschaft.

   5. Wenn Sie über eine On-Premises-Firewall verfügen, stellen Sie sicher, dass die Firewall über ausgehende Regeln verfügt, die die IP-Adressbereiche für Service Links und die Outpost-Servicendpunkte (die IP-Adressen der Netzwerkschnittstelle) zulassen, die sich in der VPC oder der VPC CIDR befinden. Stellen Sie sicher, dass die Ports TCP 1025-65535 und UDP 443 nicht blockiert sind. Weitere Informationen finden Sie unter Einführung von AWS Outposts-Privatkonnektivität.

   6. Wenn es sich nicht um eine Stateful-Firewall handelt, stellen Sie sicher, dass die Firewall über Regeln und Richtlinien verfügt, die den von den Outpost-Service-Endpunkten in der VPC eingehenden Datenverkehr zum Outpost zulassen.

2. Wenn Sie mehr als 100 Netzwerke in Ihrem On-Premises-Netzwerk haben, können Sie eine Standardroute über die BGP-Sitzung zu AWS auf Ihrer privaten virtuellen Schnittstelle bewerben. Wenn Sie keine Standardroute bewerben möchten, fassen Sie die Routen so zusammen, dass die Anzahl der beworbenen Routen weniger als 100 beträgt.

3. Wenn das Problem weiterhin besteht, führen Sie MTR/traceroute/-Paketerfassungen von Ihrem Edge-Router zu den AWS Direct Connect-Peer-IP-Adressen durch. Teilen Sie die Testergebnisse mithilfe Ihres Enterprise-Supportplans mit dem AWS-Support.

ISP öffentliche virtuelle Schnittstellenverbindung zur AWS-Region

Verwenden Sie die folgende Checkliste für die Fehlersuche bei Edge-Routern, die über einen ISP verbunden sind, wenn Sie das öffentliche Internet für Service Link-Konnektivität nutzen.

• Vergewissern Sie sich, dass die Internetverbindung aktiv ist.

• Vergewissern Sie sich, dass die öffentlichen Server von Ihren Edge-Geräten aus zugänglich sind, die über einen ISP verbunden sind.

Wenn über die ISP-Links nicht auf das Internet oder die öffentlichen Server zugegriffen werden kann, führen Sie die folgenden Schritte aus.

1. Überprüfen Sie, ob der BGP-Peering-Status mit den ISP-Routern eingerichtet ist.

   1. Vergewissern Sie sich, dass das BGP nicht schwankt.

   2. Vergewissern Sie sich, dass das BGP die erforderlichen Routen vom ISP empfängt und bewirbt.

2. Überprüfen Sie bei einer statischen Routenkonfiguration, ob die Standardroute auf dem Edge-Gerät ordnungsgemäß konfiguriert ist.

3. Prüfen Sie, ob Sie das Internet über eine andere ISP-Verbindung erreichen können.

4. Wenn das Problem weiterhin besteht, führen Sie MTR/traceroute/-Paketerfassungen von Ihrem Edge-Router zu den -Peer-IP-Adressen durch. Teilen Sie die Ergebnisse dem technischen Support Ihres Internetdienstanbieters mit, um weitere Probleme zu beheben.

Wenn über die ISP-Links auf das Internet und die öffentlichen Server zugegriffen werden kann, führen Sie die folgenden Schritte aus.

1. Vergewissern Sie sich, ob auf Ihre öffentlich zugänglichen EC2-Instances oder Load Balancer in der Outpost-Heimatregion von Ihrem Edge-Gerät aus zugegriffen werden kann. Sie können Ping oder Telnet verwenden, um die Konnektivität zu bestätigen, und dann Traceroute verwenden, um den Netzwerkpfad zu bestätigen.

2. Wenn Sie VRFs verwenden, um den Datenverkehr in Ihrem Netzwerk zu trennen, stellen Sie sicher, dass das Service Link-VRF über Routen oder Richtlinien verfügt, die den Datenverkehr zum und vom ISP (Internet) und VRF weiterleiten. Sehen Sie sich die folgenden Checkpoints an.

   1. Edge-Router, die eine Verbindung zum ISP herstellen. Überprüfen Sie in der ISP-VRF-Routing-Tabelle des Edge-Routers, ob der IP-Adressbereich für den Service Link vorhanden ist.

   2. Lokale Netzwerkgeräte des Kunden, die eine Verbindung zum Outpost herstellen. Überprüfen Sie die Konfigurationen der VRFs und stellen Sie sicher, dass das Routing und die Richtlinien, die für die Konnektivität zwischen dem Service Link-VRF und dem ISP-VRF erforderlich sind, ordnungsgemäß konfiguriert sind. Normalerweise wird eine Standardroute vom ISP-VRF an das Service Link-VRF für den Datenverkehr zum Internet gesendet.

   3. Wenn Sie in den Routern, die mit Ihrem Outpost verbunden sind, quellenbasiertes Routing konfiguriert haben, vergewissern Sie sich, dass die Konfiguration korrekt ist.

3. Stellen Sie sicher, dass die On-Premises-Firewalls so konfiguriert sind, dass sie ausgehende Verbindungen (Ports TCP 1025-65535 und UDP 443) von den IP-Adressbereichen des Outpost-Service Links zu den öffentlichen IP-Adressbereichen von AWS erlauben. Wenn die Firewalls nicht zustandsorientiert sind, stellen Sie sicher, dass die eingehende Verbindung zum Outpost ebenfalls konfiguriert ist.

4. Stellen Sie sicher, dass NAT im On-Premises-Netzwerk so konfiguriert ist, dass die Service-Link-IP-Adressbereiche des Outpost in öffentliche IP-Adressen übersetzt werden. Prüfen Sie außerdem die folgenden Elemente.

   1. Das NAT-Gerät ist nicht überlastet und verfügt über freie Ports für neue Sitzungen.

   2. Das NAT-Gerät für die Adressübersetzung ist korrekt konfiguriert.

Wenn das Problem weiterhin besteht, führen Sie MTR/traceroute/-Paketerfassungen durch.

• Wenn die Ergebnisse zeigen, dass Pakete im On-Premises-Netzwerk verloren gehen oder blockiert werden, wenden Sie sich an Ihr Netzwerk- oder Technikteam, um weitere Informationen zu erhalten.

• Wenn die Ergebnisse zeigen, dass die Pakete im Netzwerk des Internetdienstanbieters verloren gehen oder blockiert werden, wenden Sie sich an den technischen Support des ISP.

• Wenn die Ergebnisse keine Probleme zeigen, sammeln Sie die Ergebnisse aller Tests (z. B. MTR, Telnet, Traceroute, Paketerfassung und BGP-Protokolle) und wenden Sie sich über Ihren Enterprise-Supportplan an den AWS-Support.

Outposts befindet sich hinter zwei Firewall-Geräten

Wenn Sie Ihren Outpost hinter einem Paar synchronisierter Firewalls mit hoher Verfügbarkeit oder zwei eigenständigen Firewalls platziert haben, kann es zu asymmetrischem Routing des Service-Links kommen. Das bedeutet, dass eingehender Datenverkehr durch Firewall-1 und ausgehender Datenverkehr durch Firewall-2 geleitet werden kann. Verwenden Sie die folgende Checkliste, um potenzielles asymmetrisches Routing des Service-Links zu identifizieren, insbesondere wenn er zuvor ordnungsgemäß funktioniert hat.

• Überprüfen Sie, ob es in letzter Zeit Änderungen oder laufende Wartungsarbeiten an der Routing-Einrichtung Ihres Unternehmensnetzwerks gegeben hat, die möglicherweise zu einem asymmetrischen Routing der Serviceverbindung über die Firewalls geführt haben.

  • Verwenden Sie Firewall-Datenverkehrsdiagramme, um nach Änderungen an Datenverkehrsmustern zu suchen, die mit dem Anfang des Service Link-Problems übereinstimmen.

  • Überprüfen Sie, ob eine teilweise Firewall ausfällt oder ob Ihre Firewalls ihre Verbindungstabellen nicht mehr miteinander synchronisieren.

  • Suchen Sie in Ihrem Unternehmensnetzwerk nach Links zu den letzten Änderungen am Routing (OSPF/ISIS/EIGRP-Metrikänderungen, BGP-Routing-Map-Änderungen), die mit dem Start des Service Link-Problems übereinstimmen.

• Wenn Sie öffentliche Internetverbindung für den Service Link zur Heimatregion verwenden, könnte eine Serviceanbieterwartung zu asymmetrischem Routing des Service Links über die Firewalls geführt haben.

  • Überprüfen Sie Datenverkehrsdiagramme auf Links zu Ihren ISP(s) auf Änderungen an Datenverkehrsmustern, die mit dem Anfang des Service Link-Problems übereinstimmen.

• Wenn Sie AWS Direct Connect Konnektivität für den Service Link verwenden, ist es möglich, dass eine AWS geplante Wartung ein asymmetrisches Routing des Service Link ausgelöst hat.

  • Überprüfen Sie, ob Sie Benachrichtigungen über geplante Wartungsarbeiten an Ihrem/Ihren AWS Direct Connect Service(s) erhalten.

  • Beachten Sie, dass Sie bei redundanten AWS Direct Connect Services das Routing des Outposts-Service-Links über jeden wahrscheinlichen Netzwerkpfad unter Wartungsbedingungen proaktiv testen können. Auf diese Weise können Sie testen, ob eine Unterbrechung eines Ihrer AWS Direct Connect Services zu asymmetrischem Routing des Service-Links führen könnte. Die Ausfallsicherheit des -AWS Direct ConnectTeils der end-to-end Netzwerkkonnektivität kann vom AWS Direct Connect Resiliency with Resiliency Toolkit getestet werden. Weitere Informationen finden Sie unter Testen AWS Direct Connect der Ausfallsicherheit mit dem Resiliency Toolkit – Failover-Tests.

Nachdem Sie die vorangehende Checkliste durchlaufen und das asymmetrische Routing des Service-Links als mögliche Ursache festgelegt haben, können Sie eine Reihe weiterer Maßnahmen ergreifen:

• Stellen Sie symmetrisches Routing wieder her, indem Sie Änderungen am Unternehmensnetzwerk rückgängig machen oder darauf warten, dass die geplante Wartung eines Anbieters abgeschlossen ist.

• Melden Sie sich bei einer oder beiden Firewalls an und löschen Sie alle Flow-Statusinformationen für alle Flows aus der Befehlszeile (sofern vom Firewall-Anbieter unterstützt).

• Filtern Sie BGP-Ankündigungen vorübergehend durch eine der Firewalls oder schließen Sie die Schnittstellen auf einer Firewall, um ein symmetrisches Routing über die andere Firewall zu erzwingen.

• Starten Sie jede Firewall neu, um potenzielle Beschädigungen bei der Flow-Zustandsverfolgung des Service Link-Datenverkehrs im Arbeitsspeicher der Firewall zu vermeiden.

• Bitten Sie Ihren Firewall-Anbieter, die Nachverfolgung des UDP-Flow-Zustands für UDP-Verbindungen, die auf Port 443 stammen und für Port 443 bestimmt sind, entweder zu überprüfen oder zu vereinfachen.