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 Service Provider Peering-Typ
AWS Direct Connect Private 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 Service Provider Peering-Typ
AWS Direct Connect Öffentliches VIF, Transit-VIF
Azure ExpressRoute Microsoft Peering
Salesforce Express Connect
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.
Nicht-Cloud mit privater Cloud

Ö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.

Private Cloud

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.

Öffentliche Cloud zu öffentlicher Cloud

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

Konfigurationen für Routenankündigungen

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.


Letztes Update: