Direkt zum Inhalt

Wie verwalte ich asymmetrisches Routing mit Direct Connect?

Lesedauer: 8 Minute
0

Ich möchte AWS Direct Connect mit öffentlichen, privaten und virtuellen Transitschnittstellen verwenden, um das asymmetrische Routing zwischen meinem On-Premises-Netzwerk und AWS-Ressourcen zu verwalten.

Lösung

In der folgenden Lösung wird erläutert, wie du den ausgehenden Datenverkehrsfluss von AWS zu deinem On-Premises-Netzwerk verwaltest. Für den eingehenden Datenverkehr vom On-Premises-Netzwerk zu AWS musst du bevorzugte Routing-Optionen verwenden, um die Präferenz für einen bestimmten Pfad festzulegen.

Um asymmetrisches Routing mit Direct Connect zu verwalten, verwende Attribute für die Präfixlänge und das Border Gateway Protocol (BGP), um die Pfadauswahl für verschiedene Typen virtueller Schnittstellen zu bestimmen.

Hinweis: Bei öffentlichen virtuellen Schnittstellen verwendet AWS AS_PATH und die längste Präfixübereinstimmung, um den Routing-Pfad zu bestimmen.

Verwenden bestimmter Präfixe, um Direct Connect dem Internet vorzuziehen

Wenn du dasselbe Präfix sowohl aus dem Internet als auch aus einer öffentlichen virtuellen Schnittstelle ankündigst, verwende spezifischere Routen auf der öffentlichen virtuellen Schnittstelle. Der Datenverkehr bevorzugt dann Direct Connect.

Du kündigst beispielsweise das Präfix 80.80.80./24 sowohl im Internet als auch auf der öffentlichen virtuellen Schnittstelle an. Damit der Datenverkehr die öffentliche virtuelle Schnittstelle bevorzugt, ändere das virtuelle Schnittstellenpräfix in ein spezifischeres, z. B. 80.80.80.0/25 oder 80.80.80.128/25.

Den Datenverkehr aus der Heimat- und Remote-Region mit identischen BGP-Attributen und Präfixlängen weiterleiten

AWS priorisiert die AWS-Heimatregion für ausgehenden Datenverkehr im folgenden Szenario:

Du kündigst dieselben Präfixe auf öffentlichen virtuellen Schnittstellen in der Heimatregion und der Remote-Region mit identischen BGP-Attributen und Präfixlängen an.

Um das Routing zwischen Regionen durchzuführen, kündige das Präfix auf den öffentlichen virtuellen Schnittstellen sowohl in der Heimatregion als auch in der Remote-Region an. Diese Konfiguration ermöglicht es dem Datenverkehr, die virtuelle Schnittstelle zu bevorzugen, die sich in derselben Region wie die VPC befindet.

Den Datenverkehr aus der Heimat- und Remote-Region mit identischen Präfixlängen weiterleiten

AWS priorisiert die Verknüpfung mit dem kürzeren AS_PATH im folgenden Szenario:

Du kündigst dieselben Präfixe auf öffentlichen virtuellen Schnittstellen in der Heimatregion und der Remote-Region mit identischen Präfixlängen an.

Um den Datenverkehr zwischen mehreren Regionen weiterzuleiten, kündige das Präfix auf den virtuellen Schnittstellen sowohl in der Heimatregion als auch in der Remote-Region an. Kündige dann das Präfix auf der virtuellen Schnittstelle in der Heimatregion mit einem längeren AS_PATH an. Diese Konfiguration ermöglicht es, dass der Datenverkehr von der VPC in der Heimatregion die virtuelle Schnittstelle in der Remote-Region bevorzugt.

Den Datenverkehr aus zwei Remote-Regionen mit identischen Präfixlängen weiterleiten

AWS priorisiert die Verknüpfung mit dem kürzeren AS_PATH im folgenden Szenario:

Du kündigst dieselben Präfixe von öffentlichen virtuellen Schnittstellen aus zwei Remote-Regionen mit identischer Präfixlänge an.

Um den Datenverkehr zwischen mehreren Regionen weiterzuleiten, kündige das Präfix auf den öffentlichen virtuellen Schnittstellen in den Remote-Regionen an. Kündige dann das Präfix auf einer der öffentlichen virtuellen Remote-Schnittstellen mit einem längeren AS_PATH an. Diese Konfiguration ermöglicht es, dass der Datenverkehr von der VPC in der Heimatregion die virtuelle Remote-Schnittstelle bevorzugt, die nicht über den längeren AS_PATH verfügt.

Datenverkehr aus mehreren Regionen mit öffentlicher ASN und privater ASN weiterleiten

Hinweis: Das Voranstellen funktioniert mit einer öffentlichen autonomen Systemnummer (ASN), und die vorangestellte ASN ist für andere Netzwerke sichtbar. Wenn du das Präfix mit einer privaten ASN verwendest, ersetzt AWS die private ASN durch die ASN 7224. Wenn du eine private ASN auf einer öffentlichen virtuellen Schnittstelle verwendest, bestimmt das Voranstellen der ASN nicht die Routing-Entscheidungen außerhalb von AWS.

AWS priorisiert die Verknüpfung mit dem kürzeren AS_PATH im folgenden Szenario:

Du kündigst dieselben Präfixe von öffentlichen virtuellen Schnittstellen aus zwei Regionen mit identischer Präfixlänge an.

Um den Datenverkehr zwischen mehreren Regionen weiterzuleiten, wenn du öffentliche und private ASNs verwendest, kündige das Präfix auf den virtuellen Schnittstellen in jeder Remote-Region an. Kündige das Präfix in einer Remote-Region mit einem längeren privaten ASN-AS_PATH an. Kündige in der anderen Remote-Region das Präfix mit einem kürzeren öffentlichen ASN-AS_PATH an. Diese Konfiguration ermöglicht es, dass der Datenverkehr von der VPC in der Heimatregion die virtuelle Schnittstelle mit dem längeren privaten ASN-AS_PATH bevorzugt.

Hinweis: Direct Connect ersetzt die ASNs durch die öffentlichen ASNs des Direct-Connect-Gateways oder die ASN der Region. Im AWS-Netzwerk sieht Direct Connect "[your prefix], as_path [YOUR_PUBLIC_ASN]" von der virtuellen Schnittstelle mit dem längeren privaten ASN-AS_PATH. Auf der virtuellen Schnittstelle mit dem kürzeren öffentlichen ASN-AS_PATH wird "[your prefix], as_path [YOUR_PUBLIC_ASN] 1111 1111" angezeigt.

Lastaufteilung bei mehreren Verbindungen in derselben Region

Um die Lastaufteilung des ausgehenden Datenverkehrs auf mehrere Direct-Connect-Verbindungen zu ändern, kündige Präfixe mit denselben Pfadattributen an.

Hinweis: Du kannst die Last bei virtuellen Schnittstellen nur in derselben Region aufteilen.

Um die Last von mehreren Verbindungen aufzuteilen, kündige das Präfix mit derselben Präfixlänge auf allen öffentlichen virtuellen Schnittstellen an, die sich in derselben Region wie deine VPC befinden.

Lokale Präferenzen verwenden, um einen Netzwerkpfad für private und virtuelle Transitschnittstellen auszuwählen

Verwende BGP-Communitys, um die lokalen Präferenzen zu ändern. Eine höhere lokale Präferenz wird bevorzugt.

Verwende eines der folgenden BGP-Community-Tags, um die lokale Präferenz festzulegen:

  • 7224:7100 (niedrige Präferenz)
  • 7224:7200 (mittlere Präferenz )
  • 7224:7300 (hohe Präferenz)

Die folgenden Beispielszenarien zeigen, wie lokale Präferenzen verwendet werden, um einen Netzwerkpfad für private und virtuelle Transitschnittstellen auszuwählen. In den Szenarien wird davon ausgegangen, dass du die virtuellen Transitschnittstellen an ein einzelnes Direct-Connect-Gateway angefügt hast.

Hinweis: Es hat sich bewährt, das BGP-Attribut für lokale Präferenzen mit Routing-Pfaden für aktive und passive Verbindungen zu verwenden, und wenn du dieselben Präfixlängen ankündigst. Du musst den Wert für die lokale Präferenz für jede Region festlegen, um Direct-Connect-Standorte zu bevorzugen, denen dieselbe Region zugeordnet ist. Stelle den Wert auf 7224:7200 (mittlere Präferenz) ein. Wenn du die lokale Region nicht dem Direct-Connect-Standort zugeordnet hast, setze die lokale Präferenz auf einen niedrigeren Wert. Dies gilt nur, wenn du keine Community-Tags für lokale Präferenzen zuweist.

Zwei virtuelle Schnittstellen in derselben Region

Wenn sich zwei virtuelle Schnittstellen in derselben Region befinden, füge der primären virtuellen Schnittstelle ein Community-Tag hinzu. Füge der sekundären virtuellen Schnittstelle kein Community-Tag hinzu. Kündige dann das Präfix auf beiden virtuellen Schnittstellen an. Diese Konfiguration ermöglicht es, dass der Datenverkehr von der VPC in derselben Region die virtuelle Schnittstelle mit dem Community-Tag bevorzugt.

Hinweis: Der Standardwert der lokalen BGP-Präferenz ist 7224:7200 (mittlere Präferenz).

Eine virtuelle Schnittstelle in einer anderen Region

Du hast eine virtuelle Schnittstelle in derselben Region wie deine VPC und eine in einer Remote-Region. Füge weder der virtuellen Heimat-Schnittstelle noch der virtuellen Remote-Schnittstelle ein Community-Tag hinzu. Kündige dann das Präfix auf beiden virtuellen Schnittstellen an. Diese Konfiguration ermöglicht es dem Datenverkehr, die virtuelle Schnittstelle zu bevorzugen, die sich in derselben Region wie die VPC befindet.

Hinweis: Der Standardwert der lokalen BGP-Präferenz ist 7224:7200 (mittlere Präferenz).

Virtuelle Schnittstellen in einer anderen Region als deine VPC

Beide virtuellen Schnittstellen befinden sich in einer anderen Region als die VPC. Füge keiner der virtuellen Remote-Schnittstellen ein Community-Tag hinzu und kündige dann das Präfix auf beiden virtuellen Schnittstellen an. Diese Konfiguration ermöglicht einen Lastenausgleich des Datenverkehrs von der VPC über beide virtuellen Remote-Schnittstellen.

Das AS_PATH-Attribut verwenden, um einen Netzwerkpfad auszuwählen

Wenn die lokale Einstellungsoption nicht verfügbar ist, verwende das AS_PATH-Attribut, um einen Netzwerkpfad auszuwählen. Du musst Präfixe mit unterschiedlichen AS_PATH-Längen ankündigen, um den Datenverkehr weiterzuleiten, aber nur, wenn die Präfixe dieselbe lokale Präferenz haben. Es hat sich bewährt, einen kürzeren AS_PATH zu verwenden.

Die folgenden Beispielszenarien zeigen, wie AS_PATH-Attribute verwendet werden, um einen Netzwerkpfad für private und virtuelle Transitschnittstellen auszuwählen.

Hinweis: In den folgenden Szenarien wird davon ausgegangen, dass du die virtuellen Transitschnittstellen an ein einzelnes Direct-Connect-Gateway angefügt hast.

Zwei virtuelle Schnittstellen in derselben Region

Du hast zwei virtuelle Schnittstellen in derselben Region. Füge den virtuellen Schnittstellen keine Community-Tags hinzu. Kündige das Präfix auf beiden virtuellen Schnittstellen an und wende dann einen längeren AS_PATH auf eine der virtuellen Schnittstellen an. Diese Konfiguration ermöglicht es, dass der Datenverkehr von der VPC die virtuelle Schnittstelle bevorzugt, die nicht über den längeren AS_PATH verfügt.

Hinweis: Der Standardwert der lokalen BGP-Präferenz ist 7224:7200 (mittlere Präferenz).

Eine virtuelle Schnittstelle in einer anderen Region

Du hast eine virtuelle Schnittstelle in derselben Region wie deine VPC und eine in einer anderen Region. Füge weder der virtuellen Schnittstelle in der Heimatregion noch der virtuellen Remote-Schnittstelle Community-Tags hinzu. Kündige das Präfix auf beiden virtuellen Schnittstellen an und wähle dann eine Kombination von AS_PATH-Präferenzen. Diese Konfiguration ermöglicht es dem Datenverkehr, die virtuelle Schnittstelle zu bevorzugen, die sich in derselben Region wie die VPC befindet.

Hinweis: Der Standardwert der lokalen BGP-Präferenz für die Heimatregion ist 7224:7200 (mittlere Präferenz). Du kannst das AS_PATH-Attribut nicht verwenden, um die Präferenz auf „Heimatregion“: 7224:7200 Mittlere Präferenz zu ändern. Die lokale Präferenz überschreibt alle AS_PATH-Präferenzen.

Virtuelle Schnittstellen in einer anderen Region als deine VPC

Beide virtuellen Schnittstellen befinden sich in einer anderen Region als die VPC. Füge keiner der virtuellen Schnittstellen Community-Tags hinzu. Kündige das Präfix auf beiden virtuellen Schnittstellen mit derselben AS_PATH-Präferenz an. Wende dann einen längeren AS_PATH auf eine der virtuellen Schnittstellen an. Diese Konfiguration ermöglicht es, dass der Datenverkehr von der VPC die virtuelle Schnittstelle bevorzugt, die nicht über den längeren AS_PATH verfügt.

Hinweis: Der Standardwert der lokalen BGP-Präferenz für die Remote-Region ist 7224:7100 (niedrige Präferenz).

Bewährte Methoden zur Verwaltung von asymmetrischem Routing befolgen

Implementiere die folgenden bewährten Methoden:

  • Verwende für öffentliche virtuelle Schnittstellen nach Möglichkeit spezifischere Routen auf Direct Connect, damit der Datenverkehr die dedizierte Verbindung dem Internet vorzieht.
  • Überwache regelmäßig die BGP-Routen und Datenverkehrsmuster, um sicherzustellen, dass die Routing-Konfiguration funktioniert.
  • Wenn du aus Redundanzgründen mehrere virtuelle Schnittstellen verwendest, konfiguriere das On-Premises-Netzwerk, um potenzielle asymmetrische Routing-Szenarien zu bewältigen.
  • Teste deine Routing-Konfigurationen, bevor du sie in Produktionsumgebungen implementierst.

Ähnliche Informationen

Routing-Richtlinien und BGP-Communitys von Direct Connect

AWS OFFICIALAktualisiert vor 5 Monaten