MCR Peering Entre Clouds Privés
Megaport Cloud Router (MCR) prend en charge les architectures multicloudL’utilisation de multiples services de cloud computing dans une architecture hétérogène unique. Par exemple, une entreprise pourrait utiliser plusieurs fournisseurs de cloud pour les services d’infrastructure (IaaS) et de logiciel (SaaS). L’une des propositions de valeur fondamentales de Megaport est de permettre la connectivité multicloud.
qui incluent des combinaisons de types de peering cloud privés et publics, ainsi que la connectivité hors cloud vers votre centre de données. Ce sujet décrit:
- Les options de connectivité MCR prises en charge par les fournisseurs de services cloud (CSP) pour le peering entre clouds privés.
- Comment les numéros de systèmes autonomes (ASN) fonctionnent avec le routage Border Gateway Protocol (BGP) pour annoncer les routes.
Options de connectivité prises en charge avec MCR
MCR vous permet de construire une architecture robuste qui prend en charge le peering privé vers plusieurs fournisseurs de cloud. Vous pouvez offrir une connectivité au même fournisseur de cloud, dans différentes régions, avec différentes rampes d’accès, à condition que chaque pair BGP ait un ASN différent.
Cette section décrit de nombreuses, mais pas toutes, les architectures de connectivité de peering privé prises en charge avec le MCR. Comme les réseaux ne sont pas identiques, les exemples fournissent un point de départ pour votre architecture de peering.
Peering privé AWS entre VPC
AWS offre la possibilité de router entre différents Virtual Private Clouds (VPC) AWS lorsque vous utilisez votre propre ASN privé et le MCR.
Peering privé Azure avec un seul ExpressRoute et plusieurs VNets
Avec Azure, vous pouvez attacher plusieurs réseaux virtuels (VNets) au même ExpressRoute et router le trafic entre les VNets sans quitter le réseau Azure.
Remarque
Le peering privé Azure avec deux ExpressRoute n’est pas pris en charge. Dans ce scénario, la prévention des boucles BGP empêchera l’annonce des routes, car Azure détectera son propre ASN dans le chemin AS.
Peering privé Azure avec routage inter-VNet à double ExpressRoute
MCR prend en charge une architecture avec des circuits ExpressRoute doubles connectant chaque VNet aux deux circuits ExpressRoute. Comme le routage inter-VNet se produit sans quitter Azure, le chemin AS n’est pas évalué. Ce déploiement offre une haute disponibilité tout en permettant le routage inter-VNet.
Peering VPC sur Google Cloud Platform
Les VPC sur Google Cloud Platform (GCP) sont globaux et incluent des sous-réseaux pour chaque région. GCP offre la possibilité d’effectuer le peering VPC pour router le trafic entre deux VPC.
Peering VCN sur Oracle Cloud Infrastructure
Oracle propose le peering à distance de Virtual Cloud Network (VCN) pour router entre les régions. Le support inclut le routage entre Oracle Cloud Infrastructure (OCI) et OCI Classic, ou entre OCI et Oracle Government Cloud.
Remarque
Routage externe entre les régions commerciales OCI n’est pas pris en charge.
Pour plus d’informations, voir Peering de VCN à distance.
Comprendre les numéros de systèmes autonomes
Un système autonome (AS) est un réseau unique ou un ensemble de réseaux et de routeurs qui sont gérés et supervisés au nom d’une entité administrative unique, telle qu’une division d’entreprise. Un AS se voit attribuer un numéro unique mondialement qui identifie le réseau au monde.
Le MCR utilise BGP pour échanger des routes entre le peering privé et les types de peering hors cloud. Pour réduire la complexité du support BGP pour les CSP, le MCR fournit une configuration automatisée et suit les politiques de routage BGP standard et les meilleures pratiques de routage inter-AS. Bien que le MCR suive les meilleures pratiques de routage et que BGP dispose d’une prévention de boucle intégrée, une compréhension de la liste de chemins du système autonome est utile lors de l’attribution des ASN aux pairs.
Comprendre la prévention des boucles de chemin AS
Lorsque des routes sont annoncées à un voisin BGP externe (eBGP), l’ASN du routeur local est ajouté à la liste des chemins AS (AS_PATH). Pour le système autonome recevant (AS), cela crée une trace de miettes vers l’AS d’origine. Cette image montre deux routeurs, R2 et R3, avec le même ASN:
Lorsqu’un pair eBGP reçoit une route eBGP incluant son propre numéro AS dans le chemin AS, il supprimera la route pour prévenir une boucle de route BGP. C’est le comportement attendu avec BGP. Dans ce scénario, puisque R2 et R3 ont le même ASN, R3 supprimera les routes de R2 à leur arrivée.
Après avoir mis à jour la configuration de R2 avec un numéro AS unique, 64515, R3 accepte maintenant les routes annoncées par R2. Il est important de garder cela à l’esprit lors de la configuration du peering entre deux clouds privés.
Support ASN privé
Avec la passerelle Direct Connect AWS, vous pouvez apporter votre propre ASN privé du côté Amazon de la connexion. D’autres fournisseurs de services cloud exigent que vous peeriez en utilisant leur ASN public.
Ce tableau résume les ASN pris en charge par chaque CSP:
| Fournisseur de Cloud | Type de Peering | AS Côté Client | AS Côté Fournisseur de Cloud |
|---|---|---|---|
| AWS | PRIV_CLOUD | ASN Privé ou Public | ASN Privé ou ASN 7224 |
| Google Cloud | PRIV_CLOUD | ASN Privé ou Public | ASN 16550 |
| Oracle Cloud | PRIV_CLOUD | ASN Privé ou Public | ASN 31898 (Cloud du Gouvernement 6142) |
| Microsoft Azure | PRIV_CLOUD | ASN Privé ou Public | ASN 12076 |
Pour en savoir plus, explorez ces ressources.
- AWS – FAQs AWS Direct Connect
- Google Cloud – Établir 99,99% de Disponibilité pour Partner Interconnect
- Oracle Cloud – Exigences FastConnect
- Microsoft Azure – Numéros de Systèmes Autonomes (ASN)