Em alguns momentos nos deparamos com algumas necessidades de nossos clientes as quais não aparentam possuir viabilidade técnica para solução. Seja por limitação do próprio equipamento ou por conhecimento técnico defasado. Para nos livrarmos de limitações técnicas, podemos afirmar que a Cisco não nos deixa na mão! (Sorry pelo merchandising!) Como também devemos nos manter atualizados das novas tecnologias e possibilidades que surgem no mercado.
Ressalto: Viabilidade técnica é a soma das melhores práticas junto com o conhecimento técnico da aplicabilidade da solução!
Abaixo iremos demonstrar o cenário em que eu e a Sthefanie Costa Marques fomos envolvidos para arquitetar uma solução, apresentar viabilidade técnica para o cliente e implementá-la utilizando os recursos presentes no ambiente tal como realizar a entrega em pouquíssimo tempo.
Necessidade
O cliente contratou o serviço de VIF Pública com a Amazon com o intuito prosseguir com o carveout de empresas realizando a transferências do seu ambiente on-premise para o seu Bucket S3 (serviço de armazenamento da Amazon semelhante a um ‘File System”). Esse Bucket S3 possui um public ip address e para não alcançá-lo através da INTERNET (por diversos fatores que não serão abordados neste artigo), esta modalidade de conectividade é realizada diretamente na rede interna do ambiente on-premise com uma nova sessão eBGP. (Se você não sabe o que é isso, eu já escrevi um artigo sobre BGP e, inclusive, com boas práticas! Basta clicar aqui 😊).
Para estabelecermos a sessão eBGP, a AWS nos forneceu um /31 público onde realizamos o fechamento do peer eBGP com o ANS7224 (Amazon) onde a premissa era de recebermos todos os prefixos oriundos do ASN7224, ou seja, torno de 3k prefixos! O.o
Os Problemas
- O host em questão é uma maquina dentro de um /24 de Produção do cliente que precisa ter também comunicação com outras maquinas da rede do cliente.
- As maquinas desse host tem como Default Gateway o equipamento Core do cliente, que por sua vez, tem um Default gateway apontado para o FW para saída de internet. Se algum host precisasse acessar algum serviço que está na Amazon, em vez de ir via internet indo para o FW do cliente, iria sair via peer BGP na VIF Publica.
Como faremos o anúncio de blocos públicos dentro de uma sessão segregada(guardaremos esta palavra chave para demonstrarmos a solução proposta) de eBGP sem modificarmos o atual tráfego interno que tem como destino default (0.0.0.0/0) a internet além de permitir que any endereços internos façam comunicação direta com vários endereços privados? Como distingui-los? Como traduzí-los? Como não alterar roteamento?
A solução
O objetivo era “somente algumas máquinas podem conversar com os blocos do ASN da AMAZON através dessa VIF Publica”. Focando nesse objetivo, a solução pensada que atenderia de forma mais transparente possível e em curto prazo, foi 1 “combo” de: VRF + BGP com REGEXP+ NAT.
O Raciocínio
VRF (Virtual Routing and Forward) nada mais é que uma “ virtualização da tabela de roteamento”. Ela permite a criação de tabelas de roteamento apartadas da tabela de roteamento “default”(caso você não saiba o que é VRF, vou deixar esse link muito bacana e em português para clarear um pouco o entendimento.)
Por default, UMA VRF NÃO CONVERSA COM A OUTRA (mas é possível realizar a comunicação entre ambas fazendo um VRF-LEAKING, mas não é o escopo desse post). Logo, com a criação de uma VRF apartada, os prefixos que receberemos do peer BGP através dessa VRF não falariam com o restante da rede do cliente, e as demais maquinas que precisarem acessar algum serviço da Amazon (ou hospedado lá) faria o fluxo normal via internet.
Vamos a explicação desse combo que funcionou tão bem quanto a esse do Vegeto rs.
1) Configuração da VRF
ip vrf AWS-VRF
description temporary-communication-with-VIF
rd 65500:10
exit
!
1.1) Criando as Vlans
vlan 500
name AWS-PUBLIC-TST-eBGP
exit
!
vlan 501
name AWS-PUBLIC-CLIENT-VRF
exit
1.2) Configuração das interfaces vlan
interface vlan 500
description AW-VIF-PUBLICA
ip vrf forwarding AWS-VRF
ip address x.x.x.x 255.255.255.254 (ip não será demonstrado por questões de segurança)
no shut
exit
!
interface vlan 501
description HOST-TO-AWS-VIF-PUBLICA
ip vrf forwarding AWS-VRF
ip address 1.1.1.1 255.255.255.248 (apenas para exemplificar)
no shut
exit
Pronto! Criamos a VRF (AWS-VRF) , as interfaces VLAN para cada finalidade (uma para o peer e outra para o Host), endereçamos e agora ambas as interfaces estão na mesma tabela de roteamento (AWS-VRF). Mas, e o host?
2) O host
No host, após o mesmo criar uma nova interface de rede com o endereçamento da VRF que criamos (HOST com o ip 1.1.1.2/29), ele precisa ter comunicação com as demais redes do ambiente produtivo na VRF default. Para isso, solicitamos para que no Host a rota default do mesmo fosse a rede que está na VRF AWS-VRF ( 0.0.0.0/0 via 1.1.1.1) e que criassem rotas estáticas das redes BOGONS para ter comunicação com os demais servidores da rede produtiva, ou seja, todo trafego diferente das redes bogons que criamos irá via rota default para 1.1.1.1(que é o ip que contem a VRF que criamos para a maquina ter comunicação com os prefixos AWS).
Abaixo um desenho para ilustrar essa configuração
3) BGP
No BGP não iremos possuir muitas novidades de um peer tradicional, com a única “diferença” que em vez de criarmos um prefix-list dando match nos prefixos da Amazon (que são mais de 3K) , iremos usar uma “ip as-path” para utilização de EXPRESSÃO REGULAR no BGP para aceitar todos os prefixos que contenham o ASN da AMAZON.
O Motivo: Não seria nada inteligente e escalável uma prefix list tão grande dando match.(para quem não sabe o que é expressão regular (REGEXP) vou deixar esse link que explica com detalhes o que é e como configura-lo.)
3.1) Configurando o REGEXP
ip as-path access-list 1 permit ^7224_ (dando match em tudo que comece com 7224)
3.2)Criando a prefix-list de BOGON e de DIRETAMENTE CONECTADA
ip prefix-list bogon-filtering seq 5 permit 10.0.0.0/8 le 32
ip prefix-list bogon-filtering seq 10 permit 172.16.0.0/12 le 32
ip prefix-list bogon-filtering seq 15 permit 192.168.0.0/16 le 32
ip prefix-list bogon-filtering seq 20 permit 0.0.0.0/0
ip prefix-list connect seq 10 permit x.x.x.x/31 le 32 (IP DO PEER BGP)
3.3) Configurando o Route-map
route-map AS_PATH_FILTER permit 10
match as-path 1 (chamando o REGEXP que criamos)
!
route-map AS_PATH_FILTER deny 20
match ip address prefix-list bogon-filtering
route-map AWS-PUBLIC-FILTER permit 10
match ip address prefix-list TO-VIF-PUBLICA
route-map AWS-PUBLIC-REDISTRIBUTE-CONNECT permit 10
match ip address prefix-list connect
3.4) Configurando o Peer
address-family ipv4 vrf AWS-VRF
redistribute connected route-map AWS-PUBLIC-REDISTRIBUTE-CONNECT
neighbor x.x.x.x remote-as 7224
neighbor x.x.x.x description AWS-PUBLIC
neighbor x.x.x.x password x.x.x.x.x
neighbor x.x.x.x update-source Vlan500
neighbor x.x.x.x activate
neighbor x.x.x.x next-hop-self
neighbor x.x.x.x soft-reconfiguration inbound
neighbor x.x.x.x route-map AS_PATH_FILTER in
4) NAT
Como a maquina precisa sair para esses prefixos públicos através do novo peer, foi necessário a criação de um NAT para que quando o seu ip batesse no equipamento Core, o mesmo "nateasse" a requisição para o ip /31 publico que estava levantado no equipamento core. Para isso, precisamos fazer um NAT overload para o roteador entender que deverá natear somente o ip do host (no caso, o ip 1.1.1.2), e definirmos as interfaces como “inside e outside”.
4.1) Configurando o NAT
ip access-list standard NAT-INSIDE-AWS
10 permit 1.1.1.2
ip nat inside source list NAT-INSIDE-AWS interface Vlan500 vrf AWS-VRF overload
4.2) Adicionando o NAT nas interfaces
interface vlan 501
ip nat inside
!
interface vlan 500
ip nat outside
!
5) CONCLUSÃO
Com isso, o cenário final ficou da seguinte forma
Conseguimos que a sessão BGP fechasse na VRF que criamos, no caso, AWS-VRF
Conseguimos comunicação (ARP) nas vlans/endereçamentos que definimos na vrf AWS-VRF
Obs: final 0 é o ip no equipamento core, ip final 1 ponta remota
E finalizamos a solução com o NAT sendo feito para o HOST ter comunicação com destino a redes da AWS via a VRF AWS-VRF
Cliente satisfeito, solução feita de forma totalmente isolada do ambiente produtivo, e respeitando as melhores praticas de arquitetura. Espero que tenham gostado e que esse case ajude vocês em algum cenário parecido. Até a próxima :) !
