action.skip

AWS Häufig gestellte Fragen (FAQs)

Klicken Sie in der rechten Navigation auf eine der FAQs für Vorschläge und Lösungen.

Wie kann ich VPN als Backup für meine Direct Connect-Verbindung konfigurieren?

Ich möchte eine Backup-VPN-Verbindung für Failover mit meiner AWS Direct Connect-Verbindung konfigurieren. Gibt es Empfehlungen und Best Practices?

Lösung

So konfigurieren Sie das Hardware-VPN als Backup für Ihre Direct Connect-Verbindung:

  • Stellen Sie sicher, dass Sie dasselbe virtuelle private Gateway sowohl für Direct Connect als auch für die VPN-Verbindung zur VPC verwenden.
  • Wenn Sie ein Border Gateway Protocol (BGP)-VPN konfigurieren, annoncieren Sie dasselbe Präfix für Direct Connect und das VPN.
  • Wenn Sie ein statisches VPN konfigurieren, fügen Sie der VPN-Verbindung dieselben statischen Präfixe hinzu, die Sie mit der Direct Connect Virtual Interface announcen.
  • Wenn Sie dieselben Routen in Richtung der AWS VPC annoncieren, wird der Direct Connect-Pfad immer bevorzugt, unabhängig von AS-Path-Prepending.

Wichtig

Stellen Sie sicher, dass Direct Connect von Ihrer Seite aus die bevorzugte Route ist und nicht über VPN, wenn die Direct Connect Virtual Interface aktiv ist, um asymmetrisches Routing zu vermeiden; dies kann dazu führen, dass Traffic verworfen wird. Wir bevorzugen immer eine Direct Connect-Verbindung gegenüber VPN-Routen. Informationen zu Routenpriorität und Routingoptionen finden Sie im AWS-Artikel Route Priority.

Hinweis

Wenn Sie eine kurzfristige oder kostengünstigere Lösung wünschen, sollten Sie ein Hardware-VPN als Failover-Option für eine Direct Connect-Verbindung konfigurieren. VPN-Verbindungen sind nicht dafür ausgelegt, dieselbe Bandbreite bereitzustellen, die den meisten Direct Connect-Verbindungen zur Verfügung steht. Stellen Sie sicher, dass Ihr Anwendungsfall oder Ihre Anwendung eine geringere Bandbreite tolerieren kann, wenn Sie ein VPN als Backup für eine Direct Connect-Verbindung konfigurieren.

Wie aktiviere ich BFD für die Verwendung mit Direct Connect?

Bidirectional Forwarding Detection (BFD) ist ein Protokoll zur Erkennung von Netzwerkfehlern, das Pfadausfälle zwischen direkt verbundenen BGP-Nachbarn erkennt. Es bietet kurze Fehlererkennungszeiten und ermöglicht dadurch kürzere Rekonvergenzzeiten für dynamische BGP-Routingprotokolle. Es ist unabhängig von Medien, Routingprotokollen und Daten.

Wir empfehlen, BFD zu aktivieren, wenn Sie mehrere AWS Direct Connect-Verbindungen konfigurieren oder wenn Sie eine einzelne AWS Direct Connect-Verbindung zusammen mit einer VPN-Verbindung als Backup konfigurieren, um eine schnelle Erkennung und ein schnelles Failover sicherzustellen. BFD erkennt Link- oder Pfadausfälle und aktualisiert das dynamische Routing, indem Direct Connect das BGP Peering schnell beendet, sodass Backup-Routen greifen können. Dies stellt sicher, dass die BGP-Nachbarschaft schnell abgebaut wird, anstatt darauf zu warten, dass 3 Keepalives bei einer Hold-Down-Zeit von 90 Sekunden fehlschlagen.

Lösung

Das BFD-Intervall gibt an, wie häufig BFD-Pakete gesendet werden, min_rx legt fest, wie häufig ein Router den Empfang der Pakete erwartet, und der Multiplikator gibt an, wie viele ausbleiben dürfen, bevor die BGP-Nachbarschaft als down betrachtet wird.

Asynchrones BFD ist auf der AWS-Seite für jede Direct Connect Virtual Interface automatisch aktiviert, tritt jedoch erst in Kraft, wenn es auf Ihrem Router konfiguriert ist. Der Direct Connect-Standard setzt das minimale Intervall der BFD-Liveness-Detection auf 300 Millisekunden und den BFD-Liveness-Detection-Multiplikator auf 3.

Bevor Sie den BFD-Echo-Modus mit Ihrem Netzwerkgerät verwenden, müssen Sie das Senden von Internet Control Message Protocol (ICMP)- und Redirect-Nachrichten mit dem Befehl no ip redirect deaktivieren, um eine hohe CPU-Auslastung zu vermeiden.

Wie richte ich eine Active/Passive-Direct Connect-Verbindung ein?

Bei der Verwendung von AWS Direct Connect zum Transport von produktiven Workloads von und zu AWS wird empfohlen, zwei Direct Connect Virtual Circuits zu verwenden – entweder über einen einzelnen Port, ein Paar physischer Port-Verbindungen (entweder diskret oder LAG/LACP) in einem einzelnen DC oder verteilt über mehrere DC-Standorte.

Sie können Folgendes konfigurieren:

  • Zwei Router, die die primäre und sekundäre DX-Verbindung terminieren, um einen Single Point of Failure auf Geräteebene zu vermeiden.
  • Eine private virtuelle Schnittstelle auf jedem der DX-Router, die zur gleichen VPC terminiert. HA-Routingprotokolle (wie HSRP, VRRF, GLBP usw.) auf zwei Routern, sodass lokale Server mehrere Router verwenden können, die als ein einzelner virtueller Router agieren und die Konnektivität aufrechterhalten, selbst wenn der primäre Router ausfällt, da der sekundäre Router übernimmt und aktiv wird, oder ein internes Routingprotokoll wie iBGP betreiben, das Routen von Direct Connect EBGP lernt und Präfixe an interne iBGP-Gateways verteilt.
  • Active/Passive (Failover). Eine Verbindung verarbeitet den Traffic, die andere befindet sich im Standby. Wenn die aktive Verbindung nicht verfügbar ist, wird der gesamte Traffic über die passive Verbindung geroutet. Sie müssen auf einem Ihrer Links AS-Path-Prepending für die Routen vornehmen, damit es der passive Link ist. Weitere Informationen finden Sie unter Configure Redundant Connections with AWS Direct Connect.

Das Local-Preference-Attribut identifiziert einen bevorzugten Exit-Punkt aus dem lokalen Autonomous System (AS). Wenn es mehrere Exit-Punkte aus dem AS gibt, wählt das Local-Preference-Attribut den Exit-Punkt für eine bestimmte Route aus.

Beeinflussung von ausgehendem AWS-Traffic mithilfe von AS-Path-Prepending

Der BGP-Best-Path-Algorithmus entscheidet, wie der beste Pfad zu einem Autonomous System ausgewählt wird. Ein üblicher Wert zur Bestimmung des besten Pfads ist die AS-Path-Länge. Wenn zwei oder mehr Routen existieren, um ein Präfix zu erreichen, bevorzugt BGP standardmäßig die Route mit dem kürzesten AS-Path.

Der sekundäre Router annonciert einen längeren AS-Path, sodass Traffic von der VPC zu Ihrem Netzwerk immer über den primären Router läuft.

Meine öffentliche Virtual Interface steckt im Status “verifying” fest. Was kann ich tun?

Wenn Sie eine öffentliche Virtual Interface erstellen und die öffentlichen Peer-IP-Adressen angeben, erfordert dies die Genehmigung durch das AWS Direct Connect-Team (private VIFs/VXCs erfordern diese Autorisierung nicht und sind innerhalb von Minuten verfügbar). Bevor öffentliche IP-Präfixe oder öffentliche ASNs genehmigt werden, muss das AWS Direct Connect-Team den Besitz der öffentlichen IP-Präfixe und des BGP ASN verifizieren. Das AWS Direct Connect-Team bestätigt den Besitz, indem es überprüft, dass das regionale Register zur in Ihrem AWS-Konto angegebenen Organisationsbezeichnung gehört.

Lösung

Wenn sich der Status der öffentlichen Virtual Interface länger als 72 Stunden im Status verifying befindet, überprüfen Sie die für Ihr AWS-Konto registrierte E-Mail-Adresse. Möglicherweise haben Sie eine E-Mail vom AWS Direct Connect-Team erhalten, wenn der Inhaber des BGP ASN oder eine Ihrer annoncierten Routen nicht mit Ihren Kontodaten übereinstimmt.

Wenn der BGP ASN oder eine annoncierten Route nicht mit Ihrem Konto übereinstimmt, können Sie:

  • Den Inhaber der IP-Adresse bitten, eine E-Mail an directconnect-requests@amazon.com zu senden und zu bestätigen, dass die öffentlichen IP-Präfixe für die öffentliche Virtual Interface dxvif-xxx genehmigt werden dürfen.

    oder

  • Den Inhaber der IP-Adresse bitten, ein Autorisierungsschreiben auf Firmenbriefkopf einzureichen oder ihn bitten, eine E-Mail zu senden, die die Nutzung des öffentlichen IP-Präfixes für die öffentliche Virtual Interface dxvif-xxx mit Ihrem AWS-Konto autorisiert. Melden Sie sich dann bei dem Konto an, dem die öffentliche Direct Connect Virtual Interface gehört, eröffnen Sie einen Supportfall und fügen Sie Ihrem Fall das Autorisierungsschreiben bei.

Der BGP-Status der Virtual Interface ist in der AWS-Konsole down. Was soll ich tun?

Der Status Ihrer Virtual Interface kann aufgrund von Konfigurationsproblemen mit der OSIOpen Systems Interconnection (OSI) ist ein Modell, das die Kommunikationsfunktionen eines Telekommunikations- oder Computersystems charakterisiert und standardisiert. Die meisten Megaport Produkte sind Layer 2 (oder L2), wobei einige der OSI-Konzepte bis in Layer 3 (L3) hineinreichen, wo IP-Adressinformationen ausgetauscht werden, was als L2/L3-Dienst bezeichnet wird.
-Schicht 2 oder dem Border Gateway Protocol (BGP)Border Gateway Protocol (BGP) ist ein standardisiertes Routing-Protokoll, das Routen- und Erreichbarkeitsinformationen zwischen Autonomen Systemen (AS) im Internet austauscht.
down sein.

Konfiguration der OSI-Schicht 2

Überprüfen Sie zunächst, ob Ihr OSI-Layer 2 korrekt konfiguriert ist. Prüfen Sie Folgendes:

  • Sie haben auf Ihrem Gerät (z. B. Router oder Switch) die korrekte VLAN-ID mit dot1Q-Kapselung konfiguriert. Die VLAN-ID erscheint auf der Registerkarte Portalinformationen als A-End-Service für Ihr VXC.

  • Die Konfiguration der Peer-IP-Adresse ist auf Ihrem Gerät, über das Portal und in der AWS Direct Connect-Konsole identisch.

  • Alle zwischengeschalteten Geräte sind für VLAN-Tagging mit der entsprechenden VLAN-ID konfiguriert, und VLAN-getaggter Traffic bleibt am AWS Direct Connect-Endpunkt erhalten.

  • Ihr Gerät lernt die Media Access Control (MAC)-Adresse des AWS Direct Connect-Endpunkts für die konfigurierte VLAN-ID aus der Address Resolution Protocol (ARP)-Tabelle.

  • Ihr Gerät kann die Amazon-Peer-IP mit Ihrer Peer-IP als Quelle anping(en).

BGP-Konfiguration

Wenn die Tests der OSI-Schicht 2 positiv sind, bestätigen Sie die BGP-Konfiguration auf Ihrem Gerät. Prüfen Sie Folgendes:

  • Der lokale ASN und der Remote-ASN wie in der Registerkarte Portalinformationen als A-End-Service für Ihr VXC angegeben.
  • Die Nachbar-IP-Adresse und das BGP-MD5-Passwort wie in der Registerkarte Portalinformationen als A-End-Service für Ihr VXC angegeben.
  • Ihr Gerät blockiert keinen Ingress oder Egress von TCP-Port 179 (BGP) und anderen geeigneten dynamischen Ports.
  • Ihr Gerät annonciert nicht mehr als 100 Präfixe per BGP an AWS. Standardmäßig akzeptiert AWS über eine BGP-Session auf AWS Direct Connect nur bis zu 100 Präfixe.

Nach der Bestätigung dieser Konfigurationen sollte der BGP-Status Ihrer Virtual Interface up sein.