Peering cloud privé du MCR
Le Megaport Cloud Router (MCR) prend en charge les architectures multicloud qui comprennent des combinaisons de types de peering cloud privé et public, ainsi qu’une connectivité non cloud à votre centre de données. Cette rubrique décrit :
- Comment les numéros de systèmes autonomes (ASN) fonctionnent avec le routage Border Gateway Protocol (BGP) pour annoncer les routes de trafic.
- Les options de connectivité privée MCR prises en charge par les fournisseurs de services cloud (CSP).
Comprendre les numéros de systèmes autonomes
Un système autonome (SA) 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 seule entité administrative, telle qu’une division commerciale. Un AS se voit attribuer un numéro unique au monde qui identifie le réseau pour le monde entier.
Le MCR utilise le BGP pour échanger des routes de trafic entre les types de peering privé et de peering non cloud. Pour réduire la complexité de la prise en charge du 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 le BGP ait une prévention de boucles intégrée, il est utile de comprendre la liste de chemins de système autonome pour l’attribution des ASN aux pairs.
Comprendre la liste de chemins AS
Lorsque des routes sont annoncées à un voisin BGP externe (eBGP), l’ASN du routeur local est ajouté à la liste de chemins AS (AS_PATH). Pour le système autonome (AS) récepteur, cela crée un fil d’Ariane vers l’AS d’origine. Cette illustration montre deux routeurs, R2 et R3, avec le même ASN :
Lorsqu’un pair eBGP reçoit une route eBGP qui inclut son propre numéro AS comme attribut de chemin AS, il refusera la route et l’abandonnera pour empêcher une boucle de route BGP. C’est le comportement attendu avec le BGP. Dans ce scénario, comme R2 et R3 ont le même ASN, R3 abandonnera les routes de R2 à l’arrivée.
Supposons maintenant que R4, ayant un ASN de 65101, soit ajouté au réseau. Dans ce scénario, les routes seront annoncées de R3 à R4, et de R2 à R4 via R1. Toutefois, R3 abandonnera toujours les routes de R2 à l’arrivée parce que R2 et R3 ont le même ASN.
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.
Prise en charge d’ASN privés
Avec la passerelle AWS Direct Connect, vous pouvez apporter votre propre ASN privé du côté Amazon de la connexion. D’autres fournisseurs de services cloud vous demandent d’utiliser leur ASN public pour le peering.
Ce tableau résume les ASN pris en charge par chaque CSP :
| Cloud Provider (Fournisseur de cloud) | Peering Type (Type de peering) | Customer Side AS (AS côté client) | Cloud Provider Side AS (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 (Gov Cloud 6142) |
| Microsoft Azure | PRIV_CLOUD | ASN privé ou public | ASN 12076 |
Pour en savoir plus, explorez ces ressources.
- AWS – FAQ sur AWS Direct Connect
- Google Cloud – Établissement d’une disponibilité de 99,99 % pour l’interconnexion partenaire
- Oracle Cloud – Exigences relatives à FastConnect
- Microsoft Azure – Numéros système autonomes
Options de connectivité prises en charge avec le MCR
Le MCR vous permet de construire une architecture robuste qui prend en charge le peering privé vers plusieurs fournisseurs de cloud. Veillez simplement à utiliser des ASN uniques entre les pairs MCR, à moins que vous ne créiez un pair iBGP (internal Border Gateway Protocol) pour un autre MCR ou un routeur physique dans le centre de données. Vous pouvez fournir une connectivité au même fournisseur cloud, dans différentes régions, avec différents on-ramps, tant que vous ne routez pas le trafic sur un peering eBGP avec le même ASN.
Cette section décrit un grand nombre, mais pas la totalité, des architectures de connectivité de peering privé prises en charge par le MCR. Les réseaux n’étant pas identiques, les exemples constituent un point de départ pour votre architecture de peering.
Peering privé AWS entre les VPC
AWS offre la possibilité de router entre plusieurs Virtual Private Clouds (VPC) AWS lorsque vous utilisez votre propre ASN privé et le MCR.
Peering privé Azure avec une seule ExpressRoute et plusieurs VNets
Avec Azure, vous pouvez relier plusieurs réseaux virtuels (VNets) à la même ExpressRoute et router le trafic entre les VNets sans quitter le réseau Azure.
Remarque
Le peering privé Azure avec double ExpressRoute n’est pas pris en charge. Dans ce scénario, la prévention des boucles BGP empêchera que les routes soient annoncées, car Azure détectera son propre ASN dans le chemin AS.
Peering privé Azure avec double routage inter-VNet ExpressRoute
Le MCR prend en charge une architecture avec doubles circuits ExpressRoute reliant chaque VNet aux deux circuits ExpressRoute. Comme le routage inter-VNet se fait sans quitter Azure, le chemin AS n’est pas évalué. Ce déploiement assure une haute disponibilité tout en permettant le routage inter-VNet.
Peering VPC Google Cloud Platform
Les VPC dans Google Cloud Platform (GCP) sont mondiaux et comprennent des sous-réseaux pour chaque région. GCP permet d’effectuer un peering VPC pour router le trafic entre deux VPC.
Peering VCN Oracle Cloud Infrastructure
Oracle fournit un peering de réseau cloud virtuel (VCN) à distance pour le routage entre les régions. La prise en charge comprend le routage entre Oracle Cloud Infrastructure (OCI) et OCI Classic, ou entre OCI et Oracle Government Cloud.
Remarque
Le routage externe entre les régions commerciales OCI n’est pas pris en charge.
Pour plus de détails, voir Peering VCN à distance.