MCR-Peering für private Clouds

Megaport Cloud Router (MCR) unterstützen Multi-Cloud-Architekturen, die Kombinationen aus privaten und öffentlichen Cloud-Peering-Typen sowie die Nicht-Cloud-Konnektivität zu Ihrem Rechenzentrum anbieten. Folgende Aspekte werden betrachtet:

  • Zusammenwirken der Nummern des autonomen Systems (ASNs) mit dem Border Gateway Protocol (BGP)-Routing, um Datenverkehrsrouten anzukündigen.
  • Die von den Cloud Service Providern (CSPs) unterstützten privaten MCR-Konnektivitätsoptionen

Erläuterungen zu ASNs

Ein autonomes System (AS) ist ein einzelnes Netzwerk oder eine Gruppe von Netzwerken und Routern, die im Auftrag einer einzelnen Verwaltungseinheit, z. B. eines Geschäftsbereichs, verwaltet und überwacht werden. Einem AS wird eine weltweit eindeutige Nummer zugewiesen, die das Netzwerk nach außen hin identifiziert.

Der MCR verwendet BGP, um Datenverkehrsrouten zwischen Peering-Typen für privates Peering und Nicht-Cloud-Peering auszutauschen. Um die Komplexität der BGP-Unterstützung für die CSPs zu reduzieren, bietet der MCR eine automatisierte Konfiguration und folgt zudem Standardrichtlinien für das BGP-Routing und Best Practices für das Inter-AS-Routing. Obwohl der MCR den Best Practices für das Routing folgt und BGP über ein integrierte Funktion zur Verhinderung von Schleifen verfügt, ist ein Verständnis der Pfadliste des autonomen Systems bei der Zuweisung von ASNs zu Peers hilfreich.

Erläuterungen zu AS-Pfadliste

Wenn Routen einem externen BGP-Nachbarn (eBGP) angekündigt werden, wird die ASN des lokalen Routers zur AS-Pfadliste (AS_PATH) hinzugefügt. Für das empfangende autonome System (AS) wird dabei ein Breadcrumb-Trail (Brotkrümelspur) zum Ursprungs-AS erstellt. In der folgenden Abbildung werden zwei Router, R2 und R3, mit der gleichen ASN gezeigt:
AS-Pfad

Wenn ein eBGP-Peer eine eBGP-Route empfängt, die seine eigene AS-Nummer als AS-Pfad-Attribut enthält, wird er die Route ablehnen und verwerfen, um eine BGP-Routenschleife zu verhindern. Dies ist das erwartete Verhalten bei BGP. Da in diesem Szenario R2 und R3 die gleiche ASN haben, wird R3 die Routen von R2 bei Ankunft verwerfen.
Gleiche AS-Nummer

Nehmen wir nun an, dass R4 mit einer ASN von 65101 zum Netzwerk hinzugefügt wird. In diesem Szenario werden die Routen von R3 nach R4 und von R2 nach R4 über R1 angekündigt. Dennoch wird R3 die Routen von R2 bei der Ankunft verwerfen, da R2 und R3 die gleiche ASN haben.
Hinzufügen einer AS-Nummer

Nach dem Aktualisieren der Konfiguration von R2 mit der eindeutigen AS-Nummer 64515 akzeptiert R3 nun die von R2 angekündigten Routen.

Unterstützung von privaten ASNs

Mit dem AWS Direct Connect-Gateway können Sie Ihre eigene private ASN auf die Amazon-Seite der Verbindung bringen. Bei anderen Clouddienstanbietern müssen Sie das Peering über deren öffentliche ASN durchführen.

In der folgenden Tabelle sind die unterstützten ASNs jedes CSP zusammengefasst:

Cloudanbieter Peering-Typ AS Kundenseite AS Cloudanbieter-Seite
AWS PRIV_CLOUD Private oder öffentliche ASN Private ASN oder ASN 7224
Google Cloud PRIV_CLOUD Private oder öffentliche ASN ASN 16550
Oracle Cloud PRIV_CLOUD Private oder öffentliche ASN ASN 31898 (Gov Cloud 6142)
Microsoft Azure PRIV_CLOUD Private oder öffentliche ASN ASN 12076

Weitere Information der einzelnen Anbieter finden Sie unter folgenden Links:

Unterstützte Konnektivitätsoptionen mit MCRs

Mit MCRs können Sie eine robuste Architektur aufbauen, die privates Peering zu mehreren Cloudanbietern unterstützt. Stellen Sie nur sicher, dass Sie eindeutige ASNs zwischen den MCR-Peers verwenden, es sei denn, Sie erstellen einen internen Border Gateway Protocol (iBGP)-Peer zu einem anderen MCR oder zu einem physischen Router im Rechenzentrum. Sie können Konnektivität zum gleichen Cloudanbieter in verschiedenen Regionen mit unterschiedlichen On-Ramps bereitstellen, solange Sie den Datenverkehr nicht über ein eBGP-Peering mit der gleichen ASN leiten.

In diesem Abschnitt werden zahlreiche, aber nicht alle der unterstützten privaten Peering-Konnektivitätsarchitekturen mit MCRs beschrieben. Da Netzwerke nicht identisch sind, bieten die Beispiele einen Ausgangspunkt für Ihre Peering-Architektur.

Mehrere CSPs

AWS Private Peering zwischen VPCs

AWS bietet die Möglichkeit zum Routing zwischen verschiedenen AWS Virtual Private Clouds (VPCs), wenn Sie Ihre eigene private ASN und einen MCR verwenden.
Privates VPC-Peering

Privates Peering auf Azure mit einer ExpressRoute und mehreren VNets

Mit Azure können Sie mehrere virtuelle Netzwerke (VNets) an dieselbe ExpressRoute anhängen und das Routing des Datenverkehrs zwischen den VNets vornehmen, ohne das Azure-Netzwerk verlassen zu müssen.
Privates Peering auf Azure

Hinweis

Privates Peering auf Azure mit dualem ExpressRoute wird nicht unterstützt. In diesem Szenario verhindert die BGP-Schleifenprävention, dass Routen angekündigt werden, da Azure seine eigene ASN im AS-Pfad erkennt.

Privates Peering auf Azure mit dualem ExpressRoute Inter-VNet-Routing

MCR unterstützt eine Architektur mit zwei ExpressRoute-Verbindungen, die jedes VNet mit beiden ExpressRoute-Verbindung verbinden. Da das Inter-VNet-Routing erfolgt, ohne Azure zu verlassen, wird der AS-Pfad nicht ausgewertet. Diese Bereitstellung bietet eine hohe Verfügbarkeit und ermöglicht gleichzeitig ein VNet-übergreifendes Routing.
Duales Peering auf Azure

VPC-Peering auf Google Cloud Platform

VPCs auf Google Cloud Platform (GCP) sind global und umfassen Subnetze für jede Region. GCP bietet die Möglichkeit, VPC-Peering durchzuführen, um Datenverkehr zwischen zwei VPCs zu routen.
GCP-VPC-Peering

VCN-Peering auf Oracle Cloud Infrastructure

Oracle bietet Remote Virtual Cloud Network (VCN)-Peering für das Routing zwischen den Regionen. Die Unterstützung umfasst das Routing zwischen Oracle Cloud Infrastructure (OCI) und OCI Classic oder zwischen OCI und Oracle Government Cloud.

Hinweis

Externes Routing zwischen kommerziellen OCI-Regionen wird nicht unterstützt.

OCI-VCN-Peering

Weitere Informationen dazu finden Sie unter Remote-VCN-Peering.


Letztes Update: