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 zur 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:
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.
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.
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:
- AWS – FAQs zu AWS Direct Connect
- Google Cloud – Herstellen von 99,99 % Verfügbarkeit für Partner Interconnect
- Oracle Cloud – Anforderungen für FastConnect
- Microsoft Azure – ASNs (Autonomous System Numbers)
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 Anbindungsstellen (On-ramps) bereitstellen, solange Sie den Datenverkehr nicht über eBGP-Peering mit der gleichen ASN leiten.
In diesem Abschnitt werden zahlreiche, aber nicht alle der unterstützten Private Peering-Konnektivitätsarchitekturen mit MCRs beschrieben. Da Netzwerke nicht identisch sind, bieten die Beispiele einen Ausgangspunkt für Ihre Peering-Architektur.
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.
Azure Private Peering 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.
Hinweis
Azure Private Peering 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.
Azure Private Peering 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.
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.
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.
Weitere Informationen dazu finden Sie unter Remote-VCN-Peering.