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 :
Chemin AS

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.
Même numéro AS

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.
Ajout d’un numéro AS

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 :

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 (Gov Cloud 6142)
Microsoft Azure PRIV_CLOUD ASN privé ou public ASN 12076

Pour en savoir plus, explorez ces ressources.

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.

Plusieurs CSP

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 VPC privé

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.
Peering privé 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.
Double peering Azure

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 VPC GCP

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.

Peering VCN OCI

Pour plus de détails, voir Peering VCN à distance.


Dernière mise à jour: