MCR Peering entre nubes privadas
Megaport Cloud Router (MCR) es compatible con arquitecturas multicloudEl uso de múltiples servicios de cloud computing en una única arquitectura heterogénea. Por ejemplo, una empresa podría usar múltiples proveedores cloud para servicios de infraestructura (IaaS) y de software (SaaS). Una de las propuestas de valor clave de Megaport es habilitar la conectividad multicloud.
que incluyen combinaciones de tipos de peering de nube privada y pública, así como conectividad que no es de nube hacia su centro de datos. Este tema describe:
- Las opciones de conectividad de MCR compatibles por los proveedores de servicios en la nube (CSP) para peering entre nubes privadas.
- Cómo funcionan los números de sistema autónomo (ASN) con el enrutamiento de Border Gateway Protocol (BGP) para anunciar rutas.
Opciones de conectividad compatibles con MCR
MCR le permite construir una arquitectura sólida que admite peering privado con múltiples proveedores de nube. Puede proporcionar conectividad al mismo proveedor de nube, en diferentes regiones, con distintos on-ramps, siempre que cada par BGP tenga un ASN diferente.
Esta sección describe muchas, pero no todas, las arquitecturas de conectividad de peering privado compatibles con MCR. Dado que las redes no son idénticas, los ejemplos proporcionan un punto de partida para su arquitectura de peering.
Peering privado de AWS entre VPCs
AWS proporciona la capacidad de enrutar entre diferentes AWS Virtual Private Clouds (VPCs) cuando usa su propio ASN privado y MCR.
Peering privado de Azure con un solo ExpressRoute y múltiples VNets
Con Azure, puede adjuntar múltiples redes virtuales (VNets) al mismo ExpressRoute y enrutar el tráfico entre las VNets sin salir de la red de Azure.
Nota
El peering privado de Azure con ExpressRoute dual no es compatible. En este escenario, la prevención de bucles de BGP impedirá que se anuncien las rutas, porque Azure detectará su propio ASN en el AS path.
Peering privado de Azure con ExpressRoute dual y enrutamiento inter-VNet
MCR admite una arquitectura con circuitos ExpressRoute duales que conectan cada VNet a ambos circuitos de ExpressRoute. Debido a que el enrutamiento inter-VNet ocurre sin salir de Azure, no se evalúa el AS path. Este despliegue proporciona alta disponibilidad y también permite el enrutamiento inter-VNet.
Peering de VPC en Google Cloud Platform
Las VPC en Google Cloud Platform (GCP) son globales e incluyen subredes para cada región. GCP proporciona la capacidad de realizar peering de VPC para enrutar el tráfico entre dos VPC.
Peering de VCN de Oracle Cloud Infrastructure
Oracle proporciona peering remoto de Virtual Cloud Network (VCN) para enrutar entre regiones. La compatibilidad incluye el enrutamiento entre Oracle Cloud Infrastructure (OCI) y OCI Classic, o entre OCI y Oracle Government Cloud.
Nota
El enrutamiento externo entre regiones comerciales de OCI no es compatible.
Para obtener más información, consulte Remote VCN Peering.
Comprender los números de sistema autónomo
Un sistema autónomo (AS) es una red única o un conjunto de redes y routers que se gestionan y supervisan en nombre de una única entidad administrativa, como una división empresarial. A un AS se le asigna un número único a nivel global que identifica la red ante el mundo.
MCR usa BGP para intercambiar rutas entre peering privado y tipos de peering no basados en la nube. Para reducir la complejidad del soporte de BGP para los CSP, MCR proporciona configuración automatizada y sigue las políticas estándar de enrutamiento BGP y las mejores prácticas de enrutamiento entre AS. Aunque MCR sigue las mejores prácticas de enrutamiento y BGP tiene prevención de bucles incorporada, comprender la lista de ruta AS (AS_PATH) es útil al asignar ASN a los pares.
Comprender la prevención de bucles en el AS path
Cuando se anuncian rutas a un vecino de BGP externo (eBGP), el ASN del router local se agrega a la lista de AS path (AS_PATH). Para el sistema autónomo (AS) receptor, esto crea un rastro hacia el AS de origen. Esta imagen muestra dos routers, R2 y R3, con el mismo ASN:
Cuando un par eBGP recibe una ruta eBGP que incluye su propio número de AS en el AS path, descartará la ruta para evitar un bucle de enrutamiento BGP. Este es el comportamiento esperado con BGP. En este escenario, dado que R2 y R3 tienen el mismo ASN, R3 descartará las rutas de R2 al recibirlas.
Después de actualizar la configuración de R2 con un número de AS único, 64515, R3 ahora acepta las rutas que anuncia R2. Es importante tener esto en cuenta al configurar peering entre dos nubes privadas.
Compatibilidad con ASN privados
Con AWS Direct Connect gateway, puede llevar su propio ASN privado al lado de Amazon de la conexión. Otros proveedores de servicios en la nube requieren establecer peering utilizando su ASN público.
Esta tabla resume los ASN compatibles de cada CSP:
| Proveedor de nube | Tipo de Peering | AS del lado del cliente | AS del lado del proveedor de nube |
|---|---|---|---|
| AWS | PRIV_CLOUD | ASN privado o público | ASN privado o ASN 7224 |
| Google Cloud | PRIV_CLOUD | ASN privado o público | ASN 16550 |
| Oracle Cloud | PRIV_CLOUD | ASN privado o público | ASN 31898 (Gov Cloud 6142) |
| Microsoft Azure | PRIV_CLOUD | ASN privado o público | ASN 12076 |
Para obtener más información, explore estos recursos.
- AWS – AWS Direct Connect FAQs
- Google Cloud – Establishing 99.99% Availability for Partner Interconnect
- Oracle Cloud – FastConnect Requirements
- Microsoft Azure – Autonomous System numbers (ASN)