Patrones de diseño para interconectar un centro de datos de una empresa de telecomunicaciones a una Amazon VPC

Esta propuesta es efectiva y sencilla, pero solamente aplica cuando se pueden segregar aplicaciones de red en cada VPC de forma independiente. Sin embargo, en la mayoría de los casos de aplicaciones de telecomunicaciones, tales como una Función de Red Virtual (VNF) o una Función de Red basada en Contenedores (CNF), se requieren varios contextos de encaminamiento separados, pero confinados dentro de una única VPC (por ejemplo, VRF de OAM, VRF red de señalización, VRF plano de usuario, VRF interfaz de roaming) para cargas de trabajo específicas (como EPC [Evolved Packet Core] y 5GC [5G core]). Por lo general, esta situación añade más complejidad y costes a la hora de implementar una extensión entre la red de telecomunicaciones (CSP) y AWS, a la vez que se mantiene el requisito de separación de contextos de encaminamiento y plano de datos. Por lo tanto, es conveniente evaluar también otras opciones prácticas cuando se utiliza una arquitectura con una única VPC para aplicaciones Telco en AWS.

En esta publicación, se presentan cuatro patrones de diseño viables para crear una red híbrida entre AWS y la red CSP que esté separada por múltiples VRFs, por ejemplo, 1) mediante configuración de filtrado de rutas en el Gateway del cliente (CGW), 2) mediante tablas de rutas separadas en el AWS Transit Gateway (Transit Gateway), 3) usando tablas de rutas separadas en el AWS Transit Gateway y la funcionalidad Transit Gateway Connect, y 4) usando un dispositivo enrutador virtual dentro de la VPC. Los patrones 1, 2 y 3 utilizarían una estructura de red nativa de AWS con una configuración ajustada en el lado del router Provider Edge (PE) en el proveedor de servicios de telecomunicaciones o en el Transit Gateway. Por otro lado, el patrón 4 requerirá un dispositivo de enrutador virtual dentro de la VPC para implementar la configuración de inter-AS opción-B del RFC4363. Más allá de estos 4 patrones, existen otras opciones, pero los incluidos aquí se presentan con un enfoque general y como mejores prácticas que minimizan el impacto tanto en la arquitectura de la VPC de AWS como en las VRFs existentes en la red CSP.

Patrón de diseño 1: conectar las VRFs a una única VPC mediante un filtro route-map de entrada en el CGW (Provider Edge (PE) Router)

El primer patrón de diseño presentado sería el método de configuración de redes de AWS más simple, utiliza una red privada virtual (VPN) individual de sitio-a-sitio (S2S) o una interfaz virtual (VIF) de Direct Connect (DX) para cada VRF, además de tener una configuración específica en el lado del Provider Edge (PE). Como se mencionó en la sección anterior, una única VPC representaría un dominio de enrutamiento en la red de AWS. Por lo tanto, al conectar una Amazon VPC a la red del proveedor de telecomunicaciones, en la que ya existe una separación en VRFs mediante una VPN S2S o DX VIF, todos los rangos de CIDR de la VPC se anuncian a todos los “peers” de BGPs en cada VRF. En este caso, se podría implementar un mapa de políticas de rutas en cada VRF en el PE (también puede verse como cada CGW para cada conexión S2S a la VPC), para que no hubiera interferencias de otras subredes de Amazon VPC en cada VRF. Esta política de rutas debe aplicarse en la sesión BGP del PE en dirección de entrada en cada VRF para filtrar las subredes anunciadas desde la VGW en la Amazon VPC. Esta política implementaría un descarte de todas aquellas rutas que no tienen nada que ver con cada VRF correspondiente. Esta opción requiere una pre-configuración en la sesión BGP dentro de la VRF del PE y, al mismo tiempo, es necesario disponer de información predefinida sobre las subredes de Amazon VPC que se asignan a cada correspondencia de VRF para poder configurar la política de filtrado. Además de esta configuración del lado de la red privada, también se debe establecer el perímetro correcto de seguridad y aislamiento mediante los Security Group(s) y las Access Control Lists (ACL) en las interfaces de instancia y subred. Esto permite implementar el aislamiento de red dentro de la VPC.

A continuación se incluye un ejemplo de configuración de un filtro route-map en el caso de la VRF1 del router PE del diagrama de la figura 3, cuando la subred VRF1 está pre-configurada como 10.0.10.0/24 en la VPC, mientras que la VPC anuncia todo el rango CIDR 10.0.0.0/16 de la VPC. Para recibir y filtrar varios rangos CIDR de VPC anunciados a través de una conexión S2S VPN o DX, se tendrá que configurar un nuevo CIDR de VPC secundario para cada prefijo adicional que se desee anunciar y se deben crear sus subredes de VPC a partir de ese rango CIDR. La S2S VPN y DX publicarán un prefijo CIDR de VPC por cada CIDR de VPC secundaria y por supuesto otro para la principal, lo que le permitirá filtrar según el CIDR en consecuencia en el extremo de la VRF del PE.

router bgp 65001
network 169.254.205.58
neighbor 169.254.205.57 remote-as 64512
neighbor 169.254.205.57 route-map SET-LOCAL-PREF in
!
route-map SET-LOCAL-PREF permit 10
match ip address 2
set local-preference 120
!
route-map SET-LOCAL-PREF permit 20
!
access-list 2 permit 10.0.10.0 0.0.0.255
access-list 2 deny any

Patrón de diseño 2: Uso de tablas de rutas separadas en el Transit Gateway

Si tiene S2S VPN individuales o DX VIFs para múltiples VRFs (es decir, una S2S VPN o VIF para cada VRF de forma individual), se puede conectar cada VRF a una única VPC separadamente. En este contexto, se puede usar AWS Transit Gateway y tablas de rutas del Transit Gateway para separar la propagación de rutas del rango CIDR de cada VPC a cada VRF. Un factor a tener en cuenta en este enfoque (así como para el siguiente patrón de diseño 3) es que AWS Transit Gateway puede no ser la mejor opción para transportar el tráfico de usuarios en los casos de uso de redes 4G/5G de telecomunicaciones, que deben gestionar una enorme cantidad de tráfico, debido a los costes asociados al tráfico de datos a través de dicho servicio. Como se ilustra en la siguiente figura 4, la idea clave de este diseño es que se puede deshabilitar la propagación automática de todas las rutas de una Amazon VPC en el Transit Gateway y, en su lugar, definir una ruta estática en cada tabla de rutas de dicho Transit Gateway para incluir solo las subredes adecuadas dentro del rango CIDR de la VPC. En el siguiente diagrama de ejemplo, como resultado, la VRF1 del enrutador PE solo recibirá el rango de subredes VRF1 privadas del anuncio de BGP desde el Transit Gateway, la VRF2 solo verá el rango de subredes VRF2 privadas, y así sucesivamente. Al igual que en el patrón anterior, la separación y el aislamiento de la red dentro de la VPC deben implementarse mediante NACL y Security Group a nivel de subred de la Amazon VPC y a nivel de instancia EC2.

Patrón 3: Uso de Transit Gateway Connect a través de un único DX Transit-VIF

La funcionalidad Transit Gateway Connect aporta un modelo de conectividad similar al patrón anterior, pero más eficaz cuando existe una sola conexión DX. Transit Gateway Connect proporciona una forma de interconectar múltiples Sistemas Autónomos (AS) y múltiples VRFs del PE a través de un único Transit Virtual Interface (Transit-VIF) de Direct Connect (DX). Esto simplifica la conectividad de red física entre el enrutador PE de la red de telecomunicaciones y el dominio de AWS con una única conexión física, y varias conexiones lógicas (o asociaciones) usando encapsulación de enrutamiento genérica (GRE) y distintas sesiones BGP sobre cada una de ellas.

El diagrama anterior muestra una implementación de múltiples asociaciones del Transit Gateway tipo “Connect“ con múltiples VRFs. El Direct Connect Gateway (DX-GW) está configurado con un único Transit-VIF y anuncia el rango CIDR del AWS Transit Gateway. El DX-GW está asociado a un AWS Transit Gateway. Esta asociación entre DX-GW y AWS Transit Gateway se convierte en el transporte de otras asociaciones Transit Gateway tipo “Connect“, que se establecen por encima de la anterior. Tras crear las asociaciones de Transit Gateway tipo “Connect“, se configura GRE + BGP en una VRF local en el PE y se asocian con asociaciones tipo “Connect“ respectivamente. La pareja de direcciones IP externas del túnel GRE hacia el Transit Gateway se configurará con cualquier dirección IPv4 del CIDR de Transit Gateway en un extremo y una dirección anunciada desde el enrutador PE en el otro extremo. El bloque de direcciones para las sesiones BGP debe ser un rango CIDR /29 dentro de 169.254.0.0/16. La primera dirección de este rango IPv4 /29 será la dirección IP de la sesión BGP en la VRF del PE y se seleccionarán otras dos direcciones dentro del mismo rango para los “peers” de BGP en el lado del Transit Gateway. Al poder configurar dos sesiones BGP por cada conexión GRE, se proporciona un nivel de redundancia integrada dentro de cada túnel GRE. Cada asociación de Transit Gateway tipo “Connect“ tiene su propia tabla de enrutamiento en el AWS Transit Gateway, lo que añade otra capa de separación de tráfico. El rango CIDR de la VPC se propagará dinámicamente a la VRF una vez que se haya activado la propagación de la conexión de la VPC en la tabla de enrutamiento. La VRF en el PE anunciará su red en su tabla de enrutamiento correspondiente una vez que se adjunte su correspondiente asociación de Transit Gateway tipo “Connect“ a la propagación de la tabla de enrutamiento. Al igual que en los patrones anteriores, en este caso también se deben usar NACL y el Security Group para asegurarse de que la red esté separada dentro de la VPC.

Patrón de diseño 4: separación de VRFs mediante un dispositivo de enrutamiento virtual (RFC4364-option-B)

Del mismo modo que en el último patrón, se puede tener en cuenta el uso de una red superpuesta creada a través de un dispositivo enrutador virtual instanciado dentro de la VPC. Entre el enrutador PE de la red del proveedor de telecomunicaciones y un dispositivo enrutador virtual dentro de la Región de AWS, se puede crear una conexión de red a red (NNI) de opción-B establecida a través de una conexión MPLS sobre GRE, superpuesta sobre una conexión S2S VPN o VIF de Direct Connect, como se muestra en el siguiente diagrama.

A modo de ejemplo, esta arquitectura se puede probar usando una configuración como la del siguiente diagrama, por ejemplo utilizando Juniper Networks Virtual SRX (vSRX) del AWS Marketplace. En el lado izquierdo, el enrutador virtual en la VPC1 imitaría al enrutador PE en la red del proveedor de telecomunicaciones, mientras que en el lado derecho, el enrutador virtual en otra VPC2 representa el equipo dentro de la VPC que establece una red superpuesta. Esto hace que ambas VPCs se conecten mediante una S2S VPN a través de Internet.

En este entorno de demostración, el tráfico hacia y desde diferentes L3 VPNs de MPLS se multiplexa a través de una única conexión MPLS superpuesta de opción-B que termina en un dispositivo de enrutamiento virtual dentro de la VPC de AWS. Este dispositivo de enrutamiento virtual puede desambiguar los flujos de varias VRFs configuradas localmente, de acuerdo a sus etiquetas MPLS, y dichas VRFs se pueden vincular a una o varias subredes de la VPC, simplemente importando y exportando las “route targets” correspondientes con MP-eBGP. El siguiente es un ejemplo de configuración del vSRX que funciona como un enrutador de borde del sistema autónomo (ASBR) en este entorno MP-eBGP.

[edit configuration]
routing-instances {
    vSRXForWorkload-LAN1 {
        interface ge-0/0/1.0;
        instance-type vrf;
        route-distinguisher 65002:1;
        vrf-import import-vSRXOnPrem1;
        vrf-export export-vSRXForWorkload1;
        vrf-table-label;
    }
    vSRXForWorkload-LAN2 {
        interface ge-0/0/2.0;
        instance-type vrf;
        route-distinguisher 65002:2;
        vrf-import import-vSRXOnPrem1; 
        vrf-export export-vSRXForWorkload2;
        vrf-table-label;
    }
}

También se puede implementar cualquier combinación arbitraria de políticas de importación y exportación en cada VRF, basadas en “route targets” comunes o diferentes. En el lado de AWS, cada una de estas subredes se puede asociar a tablas de rutas comunes o separadas que pertenezcan a la misma VPC. Con ello, se puede implementar un contexto de enrutamiento diferente con cada tabla de rutas de una VPC. Además, es posible lograr una separación entre los contextos de enrutamiento y también utilizar NACL y Security Groups de forma similar a los patrones anteriores.

Conclusión

De una forma genérica, dado que Amazon VPC es por defecto una red plana única que proporciona un único dominio de enrutamiento, el diseño más sencillo sería implementar y asociar una VPC separada para cada VRF. Sin embargo, una aplicación tipo 4G/5G (como UPF y PGW) puede requerir que un equipo de la red del proveedor de telecomunicaciones se tenga que conectar a varias VRFs simultáneamente, sin poder segmentarse en varias VPCs. Por lo tanto, este desafío surge a menudo en el contexto de la implementación de redes móviles en AWS. En esta publicación, analizamos cuatro enfoques diferentes para conectar una Amazon VPC a redes privadas locales en el proveedor de comunicaciones, separadas por VRFs. Esto suele ser necesario, por ejemplo, con una red pública 5G y con redes privadas 4G/5G en AWS. Cada enfoque tiene ventajas y desventajas en relación a la complejidad de la implementación, el coste de operación y las restricciones a los requisitos de escalabilidad y rendimiento. Por lo tanto, se recomienda encarecidamente que se decida una implementación cuidadosamente teniendo en cuenta los factores para caso de uso.