MCR-Routenankündigung
Der Megaport Cloud Router (MCR) wird in Multi-Cloud-Architekturen eingesetzt, die über verschiedene Kombinationen von Peering-Typen verbunden sind. Zusätzlich zur privaten Peering-Konnektivität kann sich der MCR mit öffentlichen Peering-Typen wie AWS, Azure, Oracle und anderen Cloud Service Providern (CSPs) verbinden.
Unter diesem Thema werden die MCR-Peering-Typen und die Routen beschrieben, die von jedem Peering-Typ angekündigt werden.
MCR verwendet eine virtuelle Cross-Connect-Verbindung (VXC), um eine Verbindung zu anderen Endpunkten im Megaport-Netzwerk herzustellen. Die VXCs unterstützen verschiedene Typen von Peers. MCR wendet Routing-Richtlinien an, die auf den VXC-Peering-Typ abgestimmt sind.
Der für die VXC definierte Peering-Typ bestimmt, welche Routen angekündigt werden.
MCR-Peering-Typen
MCR unterstützt die in der folgenden Tabelle aufgeführten Peering-Typen:
Peering-Typ | Megaport Peering-Attribut | Angekündigte Routen | ||
---|---|---|---|---|
Non-cloud | NON_CLOUD | Routen vom Border Gateway Protocol (BGP)-Peer hinter einem Port. | ||
Private Cloud | PRIV_CLOUD | Routen von AWS Private, Azure Private Peer und Google Cloud Platform. | ||
Public Cloud | PUB_CLOUD | Routen von AWS Public, Azure MS Peer, Salesforce und anderen Cloudanbietern. |
Hinweis
Auch wenn Sie Private Cloud- und Public Cloud-Peering-Typen gleichzeitig konfigurieren können, tauscht MCR keine Routen zwischen den beiden aus.
Nicht-Cloud-VXCs
Nicht-Cloud-VXCs (NON_CLOUD) verbinden sich mit einem physischen Port im Rechenzentrum. Diese Verbindungen beziehen sich auf die private Netzwerkinfrastruktur innerhalb eines Rechenzentrums und können Dienstanbieter im Megaport Marketplace einschließen. Dies sind Verbindungen, bei denen Sie beide Seiten vollständig administrieren oder bei denen Sie die Routing-Details gemeinsam mit der Peer-Organisation festgelegt haben.
Megaport Endpunkt | Peering-Typ | |
---|---|---|
Physische Ports | Private VXC | |
Megaport Marketplace | Private VXC | |
B2B VXCs | Dienstschlüssel |
VXCs für private Clouds
VXCs für private Clouds (PRIV_CLOUD) stellen eine Verbindung zu Optionen für privates Peering bei öffentlichen Clouddienstanbietern her. Beim privaten Peering werden typischerweise RFC 1918-Routen mit dem Dienstanbieter ausgetauscht.
Cloud-Dienstanbieter | Peering-Typ | |
---|---|---|
AWS Direct Connect | Privates VIF, Transit-VIF | |
Azure ExpressRoute | Private Peering | |
Google Cloud Interconnect | Partner Interconnect Attachment | |
Oracle Cloud Infrastructure | FastConnect Private Peering |
Ähnliche Konnektivität ist bei IBM Cloud, Alibaba, SAP HANA Enterprise Cloud und vielen anderen CSPs verfügbar. Eine vollständige Liste der CSPs finden Sie unter Übersicht zur MCR-Cloud-Konnektivität.
VXCs für öffentliche Clouds
VXCs für öffentliche Clouds (PUB_CLOUD) bieten direkte Konnektivität zu Optionen für öffentliches Peering bei öffentlichen CSPs an. Optionen zum öffentlichen Peering beinhalten in der Regel den Austausch von öffentlichem Adressbereichen mit einem Dienstanbieter.
Cloud-Dienstanbieter | Peering-Typ | |
---|---|---|
AWS Direct Connect | Public VIF | |
Azure ExpressRoute | Microsoft Peering | |
Salesforce | ExpressConnect | |
Oracle Cloud Infrastructure | FastConnect Public Peering |
Szenarien für die Routenankündigung
Nicht-Cloud und private Cloud
Eine Kombination aus Nicht-Cloud- und Private-Cloud-Konnektivität ist ziemlich unkompliziert, wenn es um die Routenankündigung geht. Die Verwendung von Netzwerkvirtualisierungs- und Segmentierungsmechanismen ermöglicht es mandantenfähigen Netzwerken, private RFC 1918-Adressbereiche zwischen den einzelnen Umgebungen auszutauschen. Die private Cloud wird als ein privater Knoten in Ihrem internen Netzwerk eingeführt.
Diese Abbildung zeigt eine Firma, die eine Firewall verwendet, um seine Cloudkonnektivität zu segmentieren. Das Cloudnetzwerk verbindet sich von ihrer Firewall im Rechenzentrum über eine private NON_CLOUD-VXC mit ihrem MCR. Der MCR wiederum verbindet sich über eine PRIV_CLOUD-VXC mit AWS.
Öffentliche Cloud
Die Public-Cloud-Konnektivitätsoption erfordert den Austausch von öffentlichem Adressraum, ähnlich wie beim Peering mit einem Internetdienstanbieter (ISP). Große Unternehmen, die eine Verbindung zu mehreren ISPs benötigen, beschäftigen Netzwerkingenieure und -architekten, die mit den differenziertesten Anforderungen vertraut sind, die für die Teilnahme am Austausch von öffentlichen Routen im Internet erforderlich sind.
Der MCR mildert einige dieser komplexen Anforderungen ab, indem er Standardrichtlinien bereitstellt, die sicherstellen, dass nicht versehentlich öffentliche Routen, die zu einem Clouddienstanbieter gehören, einem anderen Clouddienstanbieter angekündigt werden. Betrachten Sie zum Beispiel die Routenankündigung in einer Netzwerktopologie mit einem ExpressRoute-Microsoft-Peering zu Azure und einer öffentlichen virtuellen Schnittstelle (VIF) zu AWS.
Wenn eine n:n-Konnektivität zwischen den beiden Public-Cloud-Peerings erlaubt wäre, würde der gesamte Datenverkehr zwischen AWS und Azure über MCR geführt. Dies würde eine globale Dienstunterbrechung für beide CSPs verursachen. Um Dienstunterbrechungen zu vermeiden, schützen die CSPs ihre Kunden mit Richtlinien, die diese Art von Fehlkonfiguration verhindern. Da jedoch Fehler passieren können, verfügt MCR auch über Routing-Mechanismen, die den Austausch von öffentlichen Adressbereichen zwischen den Peering-Typen der öffentlichen Cloud einschränken.
Konfigurationen für MCR-Routenankündigungen
Folgende Konfigurationstypen werden für MCR-Routenankündigungen unterstützt:
- Öffentliche Cloud => Nicht-Cloud
- Private Cloud => Nicht-Cloud, Private Cloud
- Nicht-Cloud => Nicht-Cloud, Private Cloud, Öffentliche Cloud
Die Unterstützung von Konfigurationen der Peering-Typen führt zu einer global verfügbaren Plattform, die eine schnelle Bereitstellung von Routing-Diensten bei Bedarf ermöglicht, und zwar auf sichere Art und Weise und mit bereits angewandten Best-Practice-Richtlinien für das Routing.