View a markdown version of this page

Checkliste zur Fehlerbehebung bei Outposts Racks - AWS Outposts
Konnektivität mit Outpost-NetzwerkgerätenDirect Connect öffentliche virtuelle Schnittstelle, Konnektivität zu AWS RegionDirect Connect private virtuelle Schnittstelle, Konnektivität zu AWS RegionÖffentliche Internetverbindung des ISP zu AWS RegionOutposts befindet sich hinter zwei Firewall-Geräten

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Checkliste zur Fehlerbehebung bei Outposts Racks

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

Virtuelle LANs.

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 dem AWS Support mit, indem Sie Ihren Enterprise-Supportplan verwenden.

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.

Direct Connect öffentliche virtuelle Schnittstelle, Konnektivität zu AWS Region

Verwenden Sie die folgende Checkliste, um Probleme mit Edge-Routern zu beheben, mit Direct Connect denen eine Verbindung hergestellt wird, wenn eine öffentliche virtuelle Schnittstelle für die 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 Routing-Tabelle 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 AWS öffentlichen IP-Adressbereiche oder die Standardroute enthalten.

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

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

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

    3. Wenn der BGP-Peering-Status lautetDOWN, pingen Sie die AWS Peer-IP-Adresse an und überprüfen Sie die BGP-Konfiguration im Edge-Router. Weitere Informationen finden Sie im Direct Connect Benutzerhandbuch unter Problembehandlung und Direct Connect in der Konsole unter Mein virtueller Schnittstellen-BGP-Status ist ausgefallen. AWS Was soll ich tun?.

    4. Wenn BGP eingerichtet ist und Sie die Standardroute oder die AWS öffentlichen IP-Adressbereiche im VRF nicht sehen, wenden Sie sich mithilfe Ihres AWS Enterprise-Support-Tarifs an den 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 zustandsbehaftet ist, stellen Sie sicher, dass die Regeln für ausgehenden Datenverkehr zulassen, dass der IP-Adressbereich des Outposts den IP-Adressbereich des Outposts mit den AWS öffentlichen IP-Adressbereichen verbindet. Weitere Informationen finden Sie unter AWS Outposts Konnektivität zu AWS Regionen.

    3. Wenn die Firewall nicht statusbehaftet ist, stellen Sie sicher, dass Sie auch den eingehenden Datenverkehr zulassen (von den AWS öffentlichen IP-Adressbereichen in den Service Link-IP-Adressbereich).

    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 Peer-IP-Adressen durch. Direct Connect Teilen Sie die Testergebnisse dem AWS Support mit, indem Sie Ihren Enterprise-Supportplan verwenden.

Direct Connect private virtuelle Schnittstelle, Konnektivität zu AWS Region

Verwenden Sie die folgende Checkliste, um Probleme mit Edge-Routern zu beheben Direct Connect , mit denen eine private virtuelle Schnittstelle für die Service Link-Konnektivität verwendet wird.

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

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

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

    3. Die Direct Connect private virtuelle Schnittstelle ist eine private Verbindung zu Ihrem Edge-Router an Ihrem ausgewählten 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-Service-Endpunkte (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 der AWS Outposts privaten Konnektivitä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 lokalen Netzwerk haben, können Sie eine Standardroute über die BGP-Sitzung AWS auf Ihrer privaten virtuellen Schnittstelle ankündigen. 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 Peer-IP-Adressen durch. Direct Connect Teilen Sie die Testergebnisse dem AWS Support mit, indem Sie Ihren Enterprise-Supportplan verwenden.

Öffentliche Internetverbindung des ISP zu 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 lokalen Firewalls so konfiguriert sind, dass sie ausgehende Konnektivität (TCP 1025-65535- und UDP 443-Ports) von den Outpost Service Link-IP-Adressbereichen zu den öffentlichen IP-Adressbereichen zulassen. AWS 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, erfassen Sie die Ergebnisse aller Tests (wie MTR, Telnet, Traceroute, Paketerfassung und BGP-Protokolle) und wenden Sie sich mithilfe Ihres Enterprise-Supportplans an den Support. AWS

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 einem asymmetrischen Routing der Service-Verbindung kommen. Das bedeutet, dass eingehender Verkehr Firewall-1 passieren könnte, während ausgehender Verkehr Firewall-2 passiert. Verwenden Sie die folgende Checkliste, um ein potenzielles asymmetrisches Routing der Serviceverbindung zu identifizieren, insbesondere, wenn diese zuvor ordnungsgemäß funktioniert hat.

  • Prüfen Sie, ob kürzlich Änderungen oder laufende Wartungsarbeiten an der Routing-Konfiguration Ihres Unternehmensnetzwerks vorgenommen wurden, die möglicherweise zu einem asymmetrischen Routing der Serviceverbindung durch die Firewalls geführt haben.

    • Suchen Sie anhand von Grafiken zum Firewall-Traffic nach Änderungen an den Verkehrsmustern, die mit dem Beginn des Service-Link-Problems übereinstimmen.

    • Suchen Sie nach einem teilweisen Ausfall der Firewall oder einem Split-Brain-Firewall-Pair-Szenario, das möglicherweise dazu geführt hat, dass Ihre Firewalls ihre Verbindungstabellen nicht mehr untereinander synchronisieren.

    • Prüfen Sie, ob in Ihrem Unternehmensnetzwerk Verbindungen unterbrochen wurden oder ob kürzlich Änderungen am Routing (OSPF/ISIS/EIGRP metrische Änderungen, Änderungen an der BGP-Routenkarte) vorgenommen wurden, die mit dem Beginn des Serviceverbindungsproblems übereinstimmen.

  • Wenn Sie für die Serviceverbindung zur Heimatregion eine öffentliche Internetverbindung verwenden, könnte es aufgrund einer Wartung durch den Dienstanbieter zu einem asymmetrischen Routing der Serviceverbindung durch die Firewalls gekommen sein.

    • Überprüfen Sie die Verkehrsdiagramme auf Verbindungen zu Ihren ISP (s) auf Änderungen an den Verkehrsmustern, die mit dem Beginn des Problems mit der Serviceverbindung übereinstimmen.

  • Wenn Sie Direct Connect Konnektivität für die Serviceverbindung verwenden, ist es möglich, dass eine AWS geplante Wartung das asymmetrische Routing der Serviceverbindung ausgelöst hat.

    • Suchen Sie nach Benachrichtigungen über geplante Wartungsarbeiten an Ihren Direct Connect Diensten.

    • Beachten Sie, dass Sie bei redundanten Direct Connect Diensten das Routing der Outposts-Servicelinks über jeden wahrscheinlichen Netzwerkpfad unter Wartungsbedingungen proaktiv testen können. Auf diese Weise können Sie testen, ob eine Unterbrechung eines Ihrer Direct Connect Dienste zu einem asymmetrischen Routing des Servicelinks führen könnte. Die Stabilität des Direct Connect Teils der durchgängigen Netzwerkkonnektivität kann mit dem Resiliency with Direct Connect Resiliency Toolkit getestet werden. Weitere Informationen finden Sie unter Testen der Resilienz mit dem Direct Connect Resiliency Toolkit — Failover-Tests.

Nachdem Sie die vorangegangene Checkliste durchgegangen und das asymmetrische Routing der Service-Verbindung als mögliche Ursache identifiziert haben, können Sie eine Reihe weiterer Maßnahmen ergreifen:

  • Stellen Sie das symmetrische Routing wieder her, indem Sie alle Änderungen am Unternehmensnetzwerk rückgängig machen oder warten, bis eine vom Anbieter geplante Wartung abgeschlossen ist.

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

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

  • Starten Sie jede Firewall nacheinander neu, um mögliche Beschädigungen bei der Flow-State-Verfolgung des Service Link-Datenverkehrs im Speicher der Firewall zu vermeiden.

  • Bitten Sie Ihren Firewall-Anbieter, das Tracking des UDP-Flow-State für UDP-Verbindungen, die von Port 443 stammen und für Port 443 bestimmt sind, entweder zu überprüfen oder zu lockern.