Emparejamiento privado de MCR en la nube
Megaport Cloud Router (MCR) admite arquitecturas de nubes múltiples que incluyen combinaciones de tipos de emparejamiento de nubes privadas y públicas, así como conectividad sin nube al centro de datos. Este tema describe:
- Cómo funcionan los números de sistema autónomo (ASN) con el enrutamiento del protocolo de puerta de enlace de borde (BGP) para anunciar las rutas de tráfico.
- Las opciones de conectividad privada de MCR admitidas por los proveedores de servicios en la nube (CSP).
Explicación de los números de sistema autónomo
Un sistema autónomo (AS) es una red única o un conjunto de redes y enrutadores que se administran y supervisan en nombre de una entidad administrativa (por ejemplo, una división empresarial). A un AS se le asigna un número único global que identifica la red para el resto del mundo.
El MCR utiliza BGP para intercambiar rutas de tráfico entre los tipos de emparejamiento privados y sin nube. Para reducir la complejidad del soporte de BGP para los CSP, el MCR proporciona una configuración automatizada y sigue las políticas de enrutamiento de BGP estándar, así como las prácticas recomendadas de enrutamiento entre AS. Aunque el MCR sigue las prácticas recomendadas de enrutamiento y BGP integra la prevención de bucles, la explicación de la lista de rutas del sistema autónomo es útil a la hora de asignar ASN a los pares.
Explicación de la lista de rutas de AS
Cuando las rutas se anuncian a un vecino BGP externo (eBGP), el ASN del enrutador local se añade a la lista de rutas del AS (AS_PATH). En el sistema autónomo (AS) receptor, esto crea un rastro hasta el AS de origen. Esta figura muestra dos enrutadores (R2 y R3) con el mismo ASN:
Si un par eBGP recibe una ruta de eBGP que incluye su propio número de AS como atributo de ruta de AS, denegará la ruta y la abandonará para evitar un bucle de ruta de BGP. Este es el comportamiento previsto con BGP. En este caso, dado que R2 y R3 tienen el mismo ASN, R3 descartará las rutas de R2 al llegar.
Ahora, supongamos que se añade a la red un R4 con un ASN de 65101. En este caso, las rutas se anunciarán de R3 a R4 y de R2 a R4 a través de R1. Sin embargo, R3 seguirá descartando las rutas de R2 cuando lleguen porque R2 y R3 tienen el mismo ASN.
Tras actualizar la configuración de R2 con un solo número de AS (64515) R3 aceptará las rutas anunciadas por R2.
Soporte de ASN privado
Con la puerta de enlace de AWS Direct Connect, puede llevar su propio ASN privado al lado de Amazon de la conexión. Otros proveedores de servicios en la nube le exigen que utilice su ASN público.
Esta tabla resume los ASN admitidos de cada CSP:
| Proveedor de la nube | Tipo de emparejamiento | AS del lado del cliente | AS del lado del proveedor de nube |
|---|---|---|---|
| AWS | PRIV_CLOUD | ASN Private (Privado) o Public (Público) | ASN Private (Privado) o ASN 7224 |
| Google Cloud | PRIV_CLOUD | ASN Private (Privado) o Public (Público) | ASN 16550 |
| Oracle Cloud | PRIV_CLOUD | ASN Private (Privado) o Public (Público) | ASN 31898 (Gov Cloud 6142) |
| Microsoft Azure | PRIV_CLOUD | ASN Private (Privado) o Public (Público) | ASN 12076 |
Para saber más, consulte estos recursos.
- AWS – Preguntas frecuentes sobre AWS Direct Connect
- Google Cloud – Establecimiento del 99,99 % de disponibilidad para Partner Interconnect
- Oracle Cloud – Requisitos de FastConnect
- Microsoft Azure – Números de sistema autónomo
Opciones de conectividad admitidas en MCR
MCR permite construir una arquitectura robusta que admite el emparejamiento privado a varios proveedores de nube. Asegúrese de utilizar ASN únicos entre los pares de MCR, a menos que quiera crear un par interno de protocolo de puerta de enlace de borde (iBGP) a otro MCR o enrutador físico en el centro de datos. Puede proporcionar conectividad al mismo proveedor de nube en regiones con varias vías de acceso, siempre que no redirija el tráfico en un emparejamiento de eBGP con el mismo ASN.
Esta sección describe la mayoría de arquitecturas de conectividad privada de emparejamiento que admite el MCR. Dado que las redes no son idénticas, los ejemplos proporcionan un punto de partida para su arquitectura de emparejamiento.
Emparejamiento privado de AWS entre VPC
AWS permite redirigir varias nubes privadas virtuales (VPC) de AWS cuando se utiliza su propio ASN privado y el MCR.
Emparejamiento privado de Azure con un solo ExpressRoute y varias VNets
Con Azure, puede adjuntar varias redes virtuales (VNets) al mismo ExpressRoute y redirigir el tráfico entre las VNets sin salir de la red Azure.
Nota
No se admite el emparejamiento privado de Azure con un ExpressRoute doble. En ese caso, la prevención de bucles de BGP evitará que se anuncien rutas, ya que Azure detectará su propio ASN en la ruta del AS.
Emparejamiento privado de Azure con enrutamiento de ExpressRoute doble entre VNet
MCR admite una arquitectura con circuitos de ExpressRoute dobles, que conectan cada VNet a ambos circuitos ExpressRoute. Como el enrutamiento entre redes se produce sin salir de Azure, no se evalúa la ruta del AS. Esta implementación proporciona una alta disponibilidad al tiempo que permite el enrutamiento entre redes.
Emparejamiento de VPC de Google Cloud Platform
Las VPC en Google Cloud Platform (GCP) son globales e incluyen subredes para cada región. GCP ofrece la posibilidad de realizar el emparejamiento de VPC para redirigir el tráfico entre dos VPC.
Intercambio de VCN en Oracle Cloud Infrastructure
Oracle proporciona un emparejamiento remoto de red de nube virtual (VCN) para realizar el enrutamiento entre regiones. El soporte incluye el enrutamiento entre Oracle Cloud Infrastructure (OCI) y OCI Classic, así como entre OCI y Oracle Government Cloud.
Nota
No se admite el enrutamiento externo entre regiones comerciales de OCI.
Para obtener más detalles, vaya a Emparejamiento con VCN remoto.