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 MCR
Le MCR prend en charge les types de peering indiqués dans ce tableau :
| Type de peering | Megaport Attribut de peering | 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, d’Azure Private Peer et de Google Cloud Platform. | ||
| Cloud public | PUB_CLOUD | Routes d’AWS Public, d’Azure MS Peer, de 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, VIF de transit | |
| Azure ExpressRoute | Peering privé | |
| Google Cloud Interconnect | Rattachement d’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 | |
| Azure ExpressRoute | Peering Microsoft | |
| Salesforce | ExpressConnect | |
| Oracle Cloud Infrastructure | Peering public FastConnect |
Scénarios d’annonce de route
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.
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.
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.
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
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.