Wie beeinflusse ich den Netzwerkverkehr meiner Direct-Connect-Verbindung zu On-Premises über mehrere Leitungen?

Kurzbeschreibung

Sie können mehrere Direct-Connect-Leitungen in verschiedenen AWS-Regionen verwenden, um die Bandbreite und die hohe Verfügbarkeit zu erhöhen. Abhängig von der Verteilung der Leitungen über die Regionen können Sie den Direct-Connect-Verkehr beeinflussen, indem Sie Community-Tags des Border Gateway Protocol (BGP) mit lokalen Präfixen anmelden.

Übliche Setups für mehrere Direct-Connect-Verbindungen sind:

• Private virtuelle Schnittstellen, die auf den Direct-Connect-Verbindungen erstellt wurden, die an dieselben Virtual Private Gateways (VGW) in derselben Region angeschlossen sind.
• Private virtuelle Schnittstellen, die auf den Direct-Connect-Verbindungen erstellt wurden, die an dasselbe Direct Connect Gateway (DXGW) angeschlossen und mehreren VGWs in beliebigen Regionen zugeordnet sind.
• Virtuelle Transitschnittstellen, die auf den Direct-Connect-Verbindungen erstellt wurden, die an dasselbe DXGW angeschlossen und mehreren Transit-Gateways in beliebigen Regionen zugeordnet sind.

Auflösung

Befolgen Sie diese Anweisungen, um den Netzwerkverkehrspfad Ihrer Direct-Connect-Verbindung passend zu Ihrem Anwendungsfall zu beeinflussen.

Standardverhalten für private virtuelle Schnittstellen und virtuelle Transitschnittstellen und wie man sie beeinflusst

Eine bewährte Methode zur Beeinflussung des Standardverhaltens ist die Verwendung eines vorangestellten Pfads im Autonomen System (AS) und der folgenden lokalen BGP-Community-Tags:

• 7224:7100 – Niedrige Präferenz
• 7224:7200 – Mittlere Präferenz
• 7224:7300 – Hohe Präferenz

BGP-Community-Tags mit lokaler Präferenz werden in der Reihenfolge von der niedrigsten zur höchsten Präferenz bewertet (wobei die höchste Präferenz Vorrang hat). Für jedes über eine BGP-Sitzung angemeldete Präfix können Sie ein Community-Tag anwenden, um die Priorität des zugeordneten Pfads für den Rückverkehr anzugeben.

Weitere Infos unter Wie kann ich BGP-Communities verwenden, um den bevorzugten Routingpfad von Direct-Connect-Links von AWS zu meinem Netzwerk zu beeinflussen?

Szenario 1

Sie haben eine Direct-Connect-Verbindung (DX1) in der Region USA Ost 1 und eine zweite Verbindung (DX2) in der Region EU West 1. Eine private virtuelle Schnittstelle (VIF) wird auf DX1 und DX2 mit denselben Präfixen erstellt, die von lokalen Geräten angemeldet werden. DX1- und DX2-VIFs sind mit einem DXGW verbunden, das drei VGWs in den Regionen USA Ost 1, EU West 1 und AP Südost 1 zugeordnet ist.

Für die Anmeldung von BGP-Tag 7224:7300 über die VIF auf DX1 bleibt der Verkehr aus der Region USA Ost 1 Amazon Virtual Private Cloud (Amazon VPC) unverändert. Der Verkehr aus den Regionen EU West 1 und AP Südost 1 bevorzugt DX1, da die Präferenz der gleichen Region von der BGP-Community überschrieben wird.

Für die Anmeldung von BGP Tag 7224:7300 über VIFs auf DX1 und DX2 wird für den Verkehr von allen Amazon VPCs in verschiedenen Regionen zwischen DX1 und DX2 eine Lastenverteilung vorgenommen. Dies liegt daran, dass die Präferenz der gleichen Region von der BGP-Community überschrieben wird.

Für die Anmeldung von BGP Tag 7224:7300 über beide VIFs mit vorangestelltem AS auf DX1, bevorzugt der Verkehr von allen Amazon VPCs in allen Regionen DX2. Dies liegt daran, dass die Regionspräferenzen als gleich überschrieben werden. Anschließend führt AWS eine Validierung der AS-Pfadlänge durch und stellt fest, dass das Pfadpräfix für DX2 kürzer als DX1 ist.

Wenn Sie nur einen vorangestellten AS über VIF auf DX1 ohne BGP-Community-Tags anmelden, bleibt der Verkehr von Amazon-VPCs in den Regionen USA Ost 1 und EU West 1 unverändert. Der Verkehr aus der Region AP Südost 1 bevorzugt DX2. Dies liegt daran, dass die Regionspräferenz eine höhere Priorität als die AS-Pfadlänge hat.

Szenario 2

Sie haben Direct-Connect-Verbindungen DX1 und DX2 in der Region US Ost 1 mit privaten virtuellen Schnittstellen, die dasselbe Präfix verwenden, das von lokalen Geräten angemeldet wird. Die privaten virtuellen Schnittstellen sind mit dem DXGW verbunden, das drei VGWs in den Regionen USA Ost 1 und EU West 1 zugeordnet ist.

Für die Anmeldung von BGP-Tag 7224:7300 über den VIF auf DX1, wird der Verkehr aus den Regionen USA Ost 1 und EU West 1 DX1 bevorzugen, da die BGP-Community die gleiche Regionspräferenz überschreibt.

Für die Anmeldung von BGP-Tag 7224:7300 über die beiden VIFs auf DX1 und DX2 bleibt der Datenverkehr von VPCs in verschiedenen Regionen unverändert. Dies liegt daran, dass die Regionspräferenz durch das BGP-Community-Tag für die Lastenverteilung überschrieben wird.

Für die Anmeldung von BGP-Tag 7224:7300 über die beiden VIFs mit vorangestelltem AS auf DX1 bevorzugt der Verkehr von Amazon VPCs in allen Regionen DX2. Dies liegt daran, dass die Regionspräferenz als gleich überschrieben wird. Anschließend führt AWS eine Validierung der AS-Pfadlänge durch und stellt fest, dass das Pfadpräfix für DX2 kürzer als DX1 ist.

Wenn Sie einen AS über die VIF auf DX1 ohne BGP-Community-Tags anmelden, bevorzugt der Verkehr von Amazon VPCs in den Regionen USA Ost 1 und EU West 1 DX2. Das liegt daran, dass die Regionen USA Ost 1 und EU West 1 die gleiche Regionspräferenz und einen kürzeren AS-Pfad für DX2 haben.

Szenario 1 und Szenario 2

Wenn Sie lokale Präfixe ohne Einflussfaktoren anmelden, ist weist der ausgehende Datenverkehr folgendes Standardverhalten auf:

• Der Datenverkehr aus der Amazon-VPC in der Region USA Ost 1 nutzt bevorzugt DX1, da er sich in derselben Region befindet. Der Datenverkehr aus der Amazon-VPC in der Region EU West 1 nutzt bevorzugt DX2, da er sich in derselben Region befindet. Da AP Südost 1 eine entfernte Region ist, wird für den von der Amazon VPC stammenden Datenverkehr eine Lastenverteilung über DX1 und DX2 vorgenommen.
• Für den Datenverkehr aus der Amazon-VPC in der Region US Ost 1 wird eine Lastenverteilung über DX1 und DX2 vorgenommen, da sie sich in derselben Region befinden. Für den Datenverkehr aus der Amazon-VPC in der Region EU West 1 wird eine Lastenverteilung über DX1 und DX2 vorgenommen.

Standardverhalten für öffentliche virtuelle Schnittstellen und wie man sie beeinflusst

Im folgenden Szenario haben Sie zwei Direct-Connect-Verbindungen in derselben Region, die dieselbe öffentliche virtuelle Schnittstelle und dasselbe Präfix verwenden, das von lokalen Geräten angemeldet wurde.

Für den ausgehenden Datenverkehr aus AWS-Richtung wird eine Lastenverteilung über öffentliche VIFs ohne Einflussfaktoren vorgenommen. Eine bewährte Methode zur Beeinflussung des Standardverhaltens ist die Verwendung eines vorangestellten Autonomen Systems (AS) mit öffentlicher ASN. Wenn Sie nur eine private ASN verwenden können, empfiehlt es sich, spezifischere Präfixe aus dem bevorzugten öffentlichen VIF anzumelden, sodass die längste Präfixübereinstimmung den Routingpfad bestimmt.

Gängige asymmetrische Routing-Szenarien für öffentliche virtuelle Schnittstellen

Folgende BGP-Präfixe können mit Direct Connect verwendet werden:

• 7224:9100 — Lokale AWS-Region
• 7224:9200 — Alle AWS-Regionen für einen Kontinent
• 7224:9300 — Global (alle öffentlichen AWS-Regionen)

Weitere Informationen finden Sie im Bereich BGP-Communitys.

Im folgenden Szenario haben Sie eine Direct-Connect-Verbindung in der Region USA Ost 1 mit einer öffentlichen virtuellen Schnittstelle. Sie melden dasselbe öffentliche On-Premises Präfix mit dem Community-Tag 7224:9100 über die Direct Connect-Verbindung und den lokalen Internetdienstanbieter an.

Wenn Sie auf einen Amazon Simple Storage Service (Amazon S3) -Bucket in der Region USA Ost 1 zugreifen, erfolgt der ein- und ausgehende Datenverkehr über die Direct-Connect-Verbindung.

Wenn Sie auf einen Amazon S3-Bucket in der Region EU West 1 zugreifen, erfolgt der eingehende Datenverkehr über die Direct Connect-Verbindung und der ausgehende Datenverkehr über den lokalen Internetdienstanbieter. Dies liegt daran, dass das Präfix nicht an die Region EU West 1 weitergegeben wird, was zu einem asymmetrischen Routing führt.

Wenn Sie auf einen Amazon S3-Bucket in der Region USA Ost 1 zugreifen und der eingehende Datenverkehr von On-Premises über den lokalen Internetdienstanbieter läuft, kommt es zu asymmetrischem Routing. Das liegt daran, dass AWS den ausgehenden Datenverkehr lieber über die Direct Connect-Verbindung als über den lokalen Internetdienstanbieter sendet, wenn die gleichen Präfixe empfangen werden.

Zugehörige Informationen

Konfigurieren redundanter Verbindungen mit AWS Direct Connect

Wie richte ich eine Active/Active- oder Active/Passive-Direct-Connect-Verbindung mit AWS über eine öffentliche virtuelle Schnittstelle ein? 

Virtuelle Schnittstellentypen für AWS Direct Connect

---