Padrões de design para interconectar o data center de uma empresa de telecomunicações a um Amazon VPC

Figura 1 Interconexão VRF para cada VPC (RFC4364 Opção-A)

Essa proposta é eficaz e simples, mas só se aplica quando os aplicativos de rede podem ser segregados em cada VPC de forma independente. No entanto, na maioria dos casos de aplicativos de telecomunicações, como uma função de rede virtual (VNF) ou uma função de rede baseada em contêiner (CNF), vários contextos de roteamento separados são necessários, mas confinados a uma única VPC (por exemplo, OAM VRF, rede de sinalização VRF, VRF de plano de usuário, interface de roaming VRF) para cargas de trabalho específicas (como EPC [Evolved Packet Core] e 5GG C [núcleo 5G]). Em geral, essa situação agrega mais complexidade e custos quando se trata de implementar uma extensão entre a rede de telecomunicações (CSP) e a AWS, mantendo a exigência de separar os contextos de roteamento e plano de dados. Portanto, é aconselhável também avaliar outras opções práticas ao usar uma arquitetura com uma única VPC para aplicativos de telecomunicações na AWS.

Figura 2 Interconexão de VRFs com uma VPC comum

Esta publicação apresenta quatro padrões de design viáveis para criar uma rede híbrida entre a AWS e a rede CSP separada por vários VRFs, por exemplo, 1) configurando a filtragem de rotas no Gateway do cliente (CGW), 2) usando tabelas de rotas separadas no AWS Transit Gateway (Transit Gateway), 3) usando tabelas de rotas separadas na funcionalidade AWS Transit Gateway e Transit Gateway Connect e 4) usando um virtual dispositivo roteador dentro do VPC. Os padrões 1, 2 e 3 usariam uma estrutura de rede nativa da AWS com uma configuração ajustada no lado do roteador Provider Edge (PE) no provedor de serviços de telecomunicações ou no Transit Gateway. Por outro lado, o padrão 4 exigirá um dispositivo de roteador virtual dentro da VPC para implementar a configuração RFC4363 Inter-AS Option-B. Além desses 4 padrões, há outras opções, mas as incluídas aqui são apresentadas com uma abordagem geral e como melhores práticas que minimizam o impacto na arquitetura da VPC da AWS e nos VRFs existentes na rede CSP.

Padrão de projeto 1: conectar VRFs a uma única VPC usando um filtro de mapa de rotas de entrada no CGW (roteador Provider Edge (PE))

O primeiro padrão de design apresentado seria o método mais simples de configuração de rede da AWS, usando uma rede privada virtual (VPN) individual de site a site (S2S) ou uma interface virtual (VIF) (VIF) (VIF) individual para cada VRF, além de ter uma configuração específica no lado do Provider Edge (PE). Conforme mencionado na seção anterior, uma única VPC representaria um domínio de roteamento na rede da AWS. Portanto, ao conectar um Amazon VPC à rede do provedor de telecomunicações, onde já existe uma separação em VRFs por meio de uma VPN S2S ou DX VIF, todas as faixas CIDR da VPC são anunciadas a todos os “pares” do BGPS em cada VRF. Nesse caso, um mapa de política de rotas poderia ser implementado em cada VRF no PE (ele também pode ser visto como cada CGW para cada conexão S2S com a VPC), para que não haja interferência de outras sub-redes do Amazon VPC em cada VRF. Essa política de rota deve ser aplicada na sessão BGP do PE na direção de entrada em cada VRF para filtrar as sub-redes anunciadas pelo VGW na Amazon VPC. Essa política implementaria o descarte de todas as rotas que não têm nada a ver com cada VRF correspondente. Esta opção requer pré-configuração na sessão de BGP dentro do VRF do PE e, ao mesmo tempo, é necessário ter informações predefinidas sobre as sub-redes do Amazon VPC que são atribuídas a cada correspondência VRF para configurar a política de filtragem. Além dessa configuração no lado da rede privada, o perímetro correto de segurança e isolamento também deve ser estabelecido usando o (s) grupo (s) de segurança e as listas de controle de acesso (ACL) nas interfaces de instância e sub-rede. Isso permite que o isolamento de rede seja implementado dentro da VPC.

Figura 3: padrão de projeto 1; uso de filtragem de rotas no PE VRF

A seguir está um exemplo de configuração de um filtro de mapa de rota no caso do VRF1 do roteador PE no diagrama da Figura 3, quando a sub-rede VRF1 é pré-configurada como 10.0.10.0/24 na VPC, enquanto a VPC anuncia todo o intervalo CIDR 10.0.0.0/16 da VPC. Para receber e filtrar vários intervalos VPC CIDR anunciados por meio de uma conexão S2S VPN ou DX, um novo VPC CIDR secundário deve ser configurado para cada prefixo adicional que você deseja anunciar e suas sub-redes VPC devem ser criadas a partir desse intervalo CIDR. O S2S VPN e o DX publicarão um prefixo VPC CIDR para cada VPC CIDR secundário e, claro, outro para o principal, o que permitirá que você filtre conforme o CIDR na extremidade VRF do PE.

Figura 4: Padrão de projeto 2; usando tabelas de roteamento separadas no TGW

Padrão 3: Usando o Transit Gateway Connect por meio de um único DX Transit-VIF

A funcionalidade Transit Gateway Connect fornece um modelo de conectividade semelhante ao padrão anterior, mas mais eficaz quando há apenas uma conexão DX. O Transit Gateway Connect fornece uma maneira de interconectar vários sistemas autônomos (AS) e vários VRFs PE por meio de uma única interface virtual de trânsito (Transit-VIF) de conexão direta (DX). Isso simplifica a conectividade de rede física entre o roteador PE da rede de telecomunicações e o domínio da AWS com uma única conexão física e várias conexões lógicas (ou associações) usando encapsulamento de roteamento genérico (GRE) e diferentes sessões de BGP em cada uma delas.

Figura 5: Padrão de projeto 3; usando tabelas de roteamento separadas no TGW e no TGW Connect

O diagrama acima mostra uma implementação de várias associações do Transit Gateway “Connect” com vários VRFs. O Direct Connect Gateway (DX-GW) é configurado com um único Transit-VIF e anuncia a linha CIDR do AWS Transit Gateway. O DX-GW está associado a um AWS Transit Gateway. Essa parceria entre o DX-GW e o AWS Transit Gateway se torna o transporte de outras associações do Transit Gateway, como “Connect”, que estão estabelecidas acima da anterior. Após criar as associações do Transit Gateway “Connect”, o GRE + BGP é configurado em um VRF local no PE e associado às associações do tipo “Connect”, respectivamente. O par de endereços IP externos do túnel GRE até o Transit Gateway será configurado com qualquer endereço IPv4 do Transit Gateway CIDR em uma extremidade e um endereço anunciado pelo roteador PE na outra extremidade. O bloco de endereços para sessões de BGP deve ser um intervalo CIDR /29 dentro de 169.254.0.0/16. O primeiro endereço nesse intervalo IPv4/29 será o endereço IP da sessão BGP no PE VRF e dois outros endereços dentro do mesmo intervalo serão selecionados para os “pares” do BGP no lado do Transit Gateway. Ao poder configurar duas sessões de BGP por conexão GRE, um nível de redundância é fornecido integrado em cada túnel GRE. Cada associação “Connect” Transit Gateway tem sua própria tabela de roteamento no AWS Transit Gateway, que adiciona outra camada de separação de tráfego. O intervalo VPC CIDR será propagado dinamicamente para o VRF assim que a propagação da conexão VPC for ativada na tabela de roteamento. O VRF no PE anunciará sua rede em sua tabela de roteamento correspondente assim que sua associação correspondente “Connect” Transit Gateway for anexada à propagação da tabela de roteamento. Como nos padrões anteriores, nesse caso, a NACL e o Grupo de Segurança também devem ser usados para garantir que a rede seja separada dentro da VPC.

Padrão de projeto 4: Separação de VRFs usando um dispositivo de roteamento virtual (RFC4364-opção-b)

Como no último padrão, você pode considerar o uso de uma rede sobreposta criada por meio de um dispositivo de roteador virtual instanciado na VPC. Entre o roteador PE da rede do provedor de telecomunicações e um dispositivo de roteador virtual na região da AWS, você pode criar uma conexão de rede a rede (NNI) da opção B estabelecida por meio de uma conexão MPLS via GRE, sobreposta a uma conexão VPN S2S ou conexão direta VIF, conforme mostrado no diagrama a seguir.

Figura 6: Padrão de projeto 4; usando uma rede de sobreposição usando um dispositivo de roteador virtual

Como exemplo, essa arquitetura pode ser testada usando uma configuração como a do diagrama a seguir, por exemplo, usando o Juniper Networks Virtual SRX (vSRX) do AWS Marketplace. No lado esquerdo, o roteador virtual na VPC1 imitaria o roteador PE na rede do provedor de telecomunicações, enquanto no lado direito, o roteador virtual em outra VPC2 representa o equipamento dentro da VPC que estabelece uma rede sobreposta. Isso faz com que as duas VPCs se conectem por meio de uma VPN S2S pela Internet.

Figura 7 Exemplo de ambiente de verificação de padrões de projeto 4

Nesse ambiente de demonstração, o tráfego de e para diferentes VPNs L3 MPLS é multiplexado por meio de uma única conexão MPLS de opção B sobreposta que termina em um dispositivo de roteamento virtual dentro da AWS VPC. Esse dispositivo de roteamento virtual pode eliminar a ambiguidade dos fluxos de vários VRFs configurados localmente, de acordo com suas tags MPLS, e esses VRFs podem ser vinculados a uma ou mais sub-redes da VPC, simplesmente importando e exportando os “destinos de rota” correspondentes com o MP-eBGP. A seguir está um exemplo de configuração do vSRx que funciona como um roteador autônomo de borda de sistema (ASBR) nesse ambiente MP-eBGP.