Checkliste zur Fehlerbehebung bei Outposts-Rack-Netzwerken - AWS Outposts
Konnektivität mit Outpost-NetzwerkgerätenAWS Direct Connect Konnektivität über öffentliche virtuelle Schnittstellen zur Region AWSAWS Direct Connect private virtuelle Schnittstelle, Konnektivität zur AWS RegionISPöffentliche Internetverbindung zur 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-Rack-Netzwerken

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

VirtuellLANs.

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 lautetDOWN, gehen Sie wie folgt vor:

  1. Pingen Sie die Remote-Peer-IP-Adresse auf den Outpost-Netzwerkgeräten von den Kundengeräten aus. Die Peer-IP-Adresse finden Sie 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 Nummer des autonomen Systems (KundeASN) korrekt konfiguriert ist.

    2. Vergewissern Sie sich, dass die Nummer des autonomen Fernsystems (OutpostASN) 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 Aktiv- und Verbindungsstatus hin- und herschwankt, stellen Sie sicher, dass 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. BGPund Debug-Protokolle TCP

    2. BGPLogs

    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 AWS Ihres Enterprise-Supportplans mit dem Support.

Wenn der BGP Peering-Status UP zwischen den lokalen Netzwerkgeräten des Kunden und den Outpost-Netzwerkgeräten besteht, der Service-Link jedoch weiterhin bestehtDOWN, 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.

AWS Direct Connect Konnektivität über öffentliche virtuelle Schnittstellen zur Region AWS

Verwenden Sie die folgende Checkliste, um Probleme mit Edge-Routern zu beheben, mit AWS Direct Connect denen eine Verbindung hergestellt wird, 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 für den Service Link über empfangen. BGP

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

    2. Überprüfen Sie die Routing-Tabelle der Service-Link-Instanz für virtuelles Routing and Forwarding (VRF). Die Anzeige sollte zeigen, dass der IP-Adressbereich verwendet wird.

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

  3. Wenn Sie die AWS öffentlichen IP-Adressbereiche nicht über den Service-Link erhaltenVRF, überprüfen Sie die folgenden Punkte.

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

    2. Wenn die physische Verbindung aktiviert istUP, ü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 unter Problembehandlung AWS Direct Connect im AWS Direct Connect Benutzerhandbuch und Mein virtueller BGP Schnittstellenstatus ist ausgefallen in der AWS Konsole. Was soll ich tun?.

    4. Wenn BGP es eingerichtet ist und Sie die Standardroute oder die AWS öffentlichen IP-Adressbereiche im nicht sehenVRF, wenden Sie sich mit Ihrem AWS Enterprise-Support-Plan 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.

      • TCPProtokoll — Quellport: TCP 1025-65535, Zielport: 443.

      • UDPProtokoll — 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 IP-Adressbereichen zuordnen. AWS 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 AWS öffentlichen 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 lokalen Netzwerk so konfiguriert haben, dass die Service-Link-IP-Adressbereiche von 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 Anschlüsse 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 AWS Ihres Enterprise-Supportplans mit dem Support.

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

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

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

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

    2. Stellen Sie sicher, dass das BGP Peering über die AWS 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 AWS Direct Connect im AWS Direct Connect Benutzerhandbuch, Mein virtueller BGP Schnittstellenstatus ist ausgefallen in der AWS Konsole. Was sollte ich tun? , und Wie kann ich BGP Verbindungsprobleme über Direct Connect beheben? .

    3. Die AWS Direct Connect private virtuelle Schnittstelle ist eine private Verbindung zu Ihrem Edge-Router an Ihrem ausgewählten AWS Direct Connect Standort und dient BGP zum Austausch von Routen. Ihr privater virtueller privater CIDR Cloud-Bereich (VPC) wird während dieser BGP Sitzung Ihrem Edge-Router mitgeteilt. In ähnlicher Weise wird der IP-Adressbereich für den Outpost-Servicelink der Region BGP von Ihrem Edge-Router aus bekannt gegeben.

    4. Vergewissern Sie sich, dass das Netzwerk, das mit dem privaten Service-Link-Endpunkt in Ihrem System ACLs verknüpft ist, den entsprechenden Datenverkehr VPC zulässt. Weitere Informationen finden Sie unter Checkliste zur Netzwerkbereitschaft.

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

    6. Wenn die Firewall nicht statusbehaftet ist, stellen Sie sicher, dass die Firewall über Regeln und Richtlinien verfügt, die eingehenden Datenverkehr von den Outpost-Dienstendpunkten in der zulassen. VPC

  2. Wenn Sie mehr als 100 Netzwerke in Ihrem lokalen Netzwerk haben, können Sie eine Standardroute über die BGP Sitzung an Ihre private virtuelle Schnittstelle AWS 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 AWS Direct Connect Peer-IP-Adressen durch. Teilen Sie die Testergebnisse mithilfe AWS Ihres Enterprise-Supportplans mit dem Support.

ISPöffentliche Internetverbindung zur AWS Region

Verwenden Sie die folgende Checkliste, um Fehler bei Edge-Routern zu beheben, die über und ISP bei Verwendung des öffentlichen Internets für Service Link-Konnektivität verbunden sind.

  • Vergewissern Sie sich, dass die Internetverbindung aktiv ist.

  • Vergewissern Sie sich, dass auf die öffentlichen Server von Ihren Edge-Geräten aus zugegriffen werden kann, die über eine verbunden sind. ISP

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 hergestellt ist.

    1. Vergewissern Sie sich, dass der nicht BGP flattert.

    2. Vergewissern Sie BGP sich, dass der die erforderlichen Routen von empfängt und ankündigt. ISP

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

  3. Bestätigen Sie, ob Sie über eine andere ISP Verbindung auf das Internet zugreifen können.

  4. Wenn das Problem weiterhin besteht, führen Sie MTR /traceroute/-Paketerfassungen auf Ihrem Edge-Router durch. Teilen Sie die Ergebnisse Ihrem technischen Support-Team mitISP, um weitere Probleme zu beheben.

Wenn über die ISP Links auf das Internet und öffentliche 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 den Datenverkehr in Ihrem Netzwerk trennen, vergewissern Sie sich, dass der Service-Link VRF über Routen oder Richtlinien verfügt, die den Datenverkehr zum und vom ISP (Internet) und weiterleiten. VRF Sehen Sie sich die folgenden Checkpoints an.

    1. Edge-Router, die eine Verbindung mit dem 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 von VRFs und stellen Sie sicher, dass das Routing und die Richtlinien, die für die Konnektivität zwischen dem Service Link VRF und dem erforderlich ISP VRF sind, ordnungsgemäß konfiguriert sind. Normalerweise wird für den Datenverkehr VRF zum Internet eine Standardroute vom ISP VRF in den Service-Link 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 (Ports TCP 1025-65535 und UDP 443) von den IP-Adressbereichen des Outpost Service Links 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 dies im lokalen Netzwerk so konfiguriert NAT ist, dass die Service-Link-IP-Adressbereiche von 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, die für neue Sitzungen reserviert werden können.

    2. Das NAT Gerät ist für die Adressübersetzung 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 Netzwerks verloren gehen oder blockiert werden, wenden Sie sich an den technischen Support ISP des Netzwerks. ISP

  • Wenn die Ergebnisse keine Probleme zeigen, sammeln Sie die Ergebnisse aller Tests (z. B. TelnetMTR, Traceroute, Paketerfassung und BGP Protokolle) und wenden Sie sich über Ihren AWS Enterprise-Supportplan an den 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 einem asymmetrischen Routing der Service-Verbindung kommen. Das bedeutet, dass eingehender Datenverkehr Firewall-1 passieren könnte, während ausgehender Datenverkehr Firewall-2 passieren könnte. Verwenden Sie die folgende Checkliste, um ein potenzielles asymmetrisches Routing des Service Links zu identifizieren, insbesondere wenn er zuvor ordnungsgemäß funktioniert hat.

  • Überprüfen Sie, ob in letzter Zeit Änderungen oder laufende Wartungsarbeiten am Routing-Setup Ihres Unternehmensnetzwerks vorgenommen wurden, die möglicherweise zu einem asymmetrischen Routing des Service Links durch die Firewalls geführt haben.

    • Verwenden Sie Firewall-Verkehrsdiagramme, um nach Änderungen der Verkehrsmuster zu suchen, die mit dem Beginn des Service-Link-Problems übereinstimmen.

    • Suchen Sie nach einem teilweisen Firewallausfall oder einem Szenario mit geteilten Firewall-Paaren, das möglicherweise dazu geführt hat, dass Ihre Firewalls ihre Verbindungstabellen nicht mehr miteinander synchronisieren.

    • Suchen Sie in Ihrem Unternehmensnetzwerk nach nicht funktionierenden Links oder nach kürzlichen Änderungen am BGP Routing (OSPFISIS//EIGRPMetrikänderungen, Änderungen der Routenzuweisung), die mit dem Beginn des Service-Link-Problems übereinstimmen.

  • Wenn Sie eine öffentliche Internetverbindung für die Verbindung zur Heimatregion verwenden, könnte eine Wartung durch den Dienstanbieter zu einem asymmetrischen Routing der Serviceverbindung durch die Firewalls geführt haben.

    • Suchen Sie in den Verkehrsdiagrammen nach Links zu Ihren ISP (n), ob sich die Verkehrsmuster geändert haben, die mit dem Beginn des Dienstverbindungsproblems ü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 Links ausgelöst hat.

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

    • Beachten Sie, dass Sie bei redundanten AWS Direct Connect Diensten das Routing des Outposts-Servicelinks ü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 Dienste zu einem asymmetrischen Routing der Service-Verbindung führen könnte. Die Widerstandsfähigkeit des AWS Direct Connect Teils der end-to-end Netzwerkkonnektivität kann mit dem Resiliency with AWS Direct Connect Resiliency Toolkit getestet werden. Weitere Informationen finden Sie unter Resilienz mit dem AWS Direct Connect Resiliency Toolkit testen — Failover-Tests.

Nachdem Sie die vorherige Checkliste durchgesehen 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 die vom Anbieter geplante Wartung abgeschlossen ist.

  • Melden Sie sich bei einer oder beiden Firewalls an und löschen Sie alle Flussstatusinformationen für alle Datenflüsse ü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 an 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-Verkehrs im Speicher der Firewall zu vermeiden.

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