Annonces de routes MCR

Le Megaport Cloud Router (MCR) fonctionne dans des architectures multicloud qui sont connectées en utilisant différentes combinaisons de types de peering. En plus de la connectivité de peering privé, le MCR peut se connecter à des types de peering public tels qu’AWS, Azure, Oracle et d’autres fournisseurs de services cloud (CSP).

Cette rubrique décrit les types de peering du MCR et les routes annoncées par chaque type de peering.

Le MCR utilise une connexion transversale virtuelle (VXC) pour se connecter aux autres points de terminaison du réseau Megaport. Les VXC prennent en charge différents types de pairs. Le MCR utilise des politiques de routage alignées sur le type de peering VXC.

Le type de peering défini pour la VXC détermine quelles routes sont annoncées.

Types de peering du MCR

Le MCR prend en charge les types de peering indiqués dans ce tableau :

Type de peering Attribut de peering Megaport Routes annoncées
Non cloud NON_CLOUD Routes du pair Border Gateway Protocol (BGP) derrière un port.
Cloud privé PRIV_CLOUD Routes d’AWS Private, Azure Private Peer, et Google Cloud Platform.
Public cloud PUB_CLOUD Routes d’AWS Public, Azure MS Peer, Salesforce, et d’autres fournisseurs de cloud.

Remarque

Bien que vous puissiez configurer simultanément des types de peering cloud privé et public, le MCR n’échange pas de routes entre les deux.

VXC non cloud

Les VXC non cloud (NON_CLOUD) se connectent à un port physique dans le centre de données. Ces connexions font référence à l’infrastructure de réseau privé au sein d’un centre de données et peuvent inclure des fournisseurs de services dans la Megaport Marketplace. Il s’agit de connexions dans lesquelles vous administrez entièrement les deux côtés ou dans lesquelles vous avez réglé les détails du routage avec l’entreprise pair.

Point de terminaison Megaport Type de peering
Ports physiques VXC privée
Megaport Marketplace VXC privée
VXC B2B Clé de service

VXC cloud privé

Les VXC de cloud privé (PRIV_CLOUD) se connectent à des options de peering privé avec des fournisseurs de services de cloud public. Le peering privé implique généralement l’échange de routes RFC 1918 avec le fournisseur de services.

Fournisseur de services cloud Type de peering
AWS Direct Connect VIF privée
Azure ExpressRoute Peering privé
Google Cloud Interconnect Rattachement interconnexion partenaire
Oracle Cloud Infrastructure Peering privé FastConnect

Une connectivité similaire est disponible auprès d’IBM Cloud, d’Alibaba, de SAP HANA Enterprise Cloud et de nombreux autres CSP. Pour obtenir la liste complète des CSP, consultez Aperçu de la connectivité cloud MCR.

VXC cloud public

Les VXC de cloud public (PUB_CLOUD) fournissent une connectivité directe aux options de peering public des CSP publics. Les options de peering public impliquent généralement l’échange d’un espace d’adressage public avec un fournisseur de services.

Fournisseur de services cloud Type de peering
AWS Direct Connect VIF publique, VIF de transit
Azure ExpressRoute Peering Microsoft
Salesforce ExpressConnect
Infrastructure cloud d’Oracle Peering public FastConnect

Scénarios d’annonces de routes

Non cloud et cloud privé

Une combinaison de connectivité cloud privé et non cloud est assez simple en matière d’annonce de routes. L’utilisation de mécanismes de virtualisation et de segmentation des réseaux permet aux réseaux multi-tenant d’échanger des espaces d’adressage RFC 1918 privés entre chaque environnement. Le cloud privé est introduit comme un nœud privé sur votre réseau interne.

Cette illustration montre une entreprise qui utilise un pare-feu pour segmenter sa connectivité cloud. Le réseau cloud se connecte de son pare-feu dans le centre de données à son MCR via une VXC NON_CLOUD privée. Le MCR se connecte à son tour à AWS via une VXC PRIV_CLOUD.
Non cloud avec cloud privé

Cloud public

L’option de connectivité cloud public nécessite l’échange d’un espace d’adressage public, comme pour le peering avec un fournisseur de services Internet (ISP). Les grandes entreprises qui ont besoin d’une connectivité avec plusieurs ISP emploient des ingénieurs et des architectes de réseau qui connaissent toutes les exigences nuancées nécessaires pour participer à l’échange de routes publiques sur Internet.

Le MCR atténue certaines de ces nuances en fournissant des politiques par défaut qui garantissent que vous n’annoncez pas par inadvertance des routes publiques appartenant à un fournisseur de services cloud à un autre. Prenons par exemple l’annonce de routes dans une topologie de réseau avec un peering Microsoft ExpressRoute vers Azure et une interface virtuelle publique (VIF) vers AWS.

Cloud privé

Si une connectivité any-to-any était autorisée entre les deux peerings de cloud public, tout le trafic entre AWS et Azure passerait par le MCR. Cela entraînerait une perturbation globale des services pour les deux CSP. Pour éviter toute perturbation de service, les CSP protègent leurs clients grâce à des politiques qui empêchent ce type de mauvaise configuration. Cependant, comme des erreurs peuvent se produire, le MCR a également mis en place des mécanismes de routage pour empêcher les types de peering de cloud public d’échanger des espaces d’adressage publics.

Cloud public vers cloud public

Configurations des annonces de routes MCR

Les types de configuration des annonces de routes MCR pris en charge sont les suivants :

  • Cloud public => Non cloud
  • Cloud privé => Non cloud, cloud privé
  • Non cloud => Non cloud, cloud privé, cloud public

Configurations des annonces de routes

La prise en charge de ces configurations de type de peering se traduit par une plateforme disponible dans le monde entier qui permet le déploiement rapide de services de routage à la demande, de manière sûre, avec les meilleures pratiques en matière de politiques de routage déjà appliquées.


Dernière mise à jour: