A utilização da L3VPN para comunicação entre sites
Olá Network Folks !!!
Meu nome é Pedro e vou falar um pouco sobre L3VPN para vocês hoje aqui no Tech Rebels. Esse artigo é um da serie de artigos que publico no meu site www.howtonetwork.com.br então você pode ver esse e os demais artigos lá também :) . A ideia do site é explicar um pouco os conceitos sobre as tecnologias que estou estudando/implementando junto com um lab para termos um pequeno "hands on" para não ficar somente na parte teórica.Utilizo referencias de DBZ para dar alivio cômico pois acredito que isso ajuda o entendimento de quem esta aprendendo e todo mundo conhece DBZ não é mesmo? rs
Bom, pega o seu café bem forte e vamos lá!
L3VPN
De forma resumida, a VPN de camada 3 (L3VPN) é uma VPN que utiliza o protocolo BGP para enviar e receber dados relacionados à VPN. Ela funciona permitindo que clientes VPN façam peering com o roteador central (PE) e utiliza técnicas de roteamento e encaminhamento virtual (VRF) para realizar e segregar a comunicação do cliente dentro do backbone da operadora de forma transparente. Essa tecnologia funciona sobre uma rede MPLS na qual utilizamos a alta disponibilidade e resiliência que o protocolo nos fornece para garantir a comunicação do cliente entre diversos pontos da malha MPLS.
Mas, porque a necessidade de uma VPN L3 se já existe a L2VPN?
De fato, a L2VPN (ou qualquer VPN de camada 2) consegue atender muitas necessidades de realizar o transporte entre matriz/filiais ou de interligações de pop’s, porem, a L3VPN consegue realizar essas mesmas funções resolvendo alguns problemas que a L2VPN possui, sendo algum deles:
- A necessidade de realizar configurações L2 na rede metro já que toda a L3VPN é feita via IP+MPLS entre PE’s.
- Broadcast na rede ainda irá existir utilizando L2VPN.
- A possibilidade (mesmo que muito menor se comparada com o método tradicional) de loops de camada 2.
Vamos novamente pensar em um grande ISP. Ele possui um cliente (vamos chama-lo de acme) e esse cliente possui 500 unidades e ele quer que todas as unidades se comuniquem através da sua rede(ISP 666) . Como podemos fazer isso com escalabilidade, sem riscos de loop de camada 2, sem dependência do tamanho da tabela CAM dos equipamentos L2 e o mais importante, com segurança? Com a L3VPN! Utilizando a L3VPN (que consiste na utilização do MP-BGP (MultiProtocol BGP) + MPLS + VRF) conseguimos garantir escalabilidade (já que não ficaremos dependentes do tamanho de tabelas CAM nos SW’s), ambiente livre de loops de camada 2 (já que toda a comunicação será realizada via protocolos de roteamento) e segurança (todo o trafego do cliente ficará em sua VRF e não irá ter comunicação com nenhuma outra VRF no backbone e nem com outros clientes).
Ficou curioso? Vamos ver na pratica como isso funciona.
O cenário
Conforme demonstrado no lab acima, possuímos o backbone MPLS do provedor ISP 666 (R1,R2 e R3) que realizam a troca de labels através do OSPF e possuímos dois CPE’s (CLI-C-USA e CLI-C-SÃO PAULO) conectados nos nossos PE’s (R2 e R3). Entre R2 e R3, existe um IBGP configurado e uma VRF chamada CLI-C que será utilizada para segregar o trafego desse cliente da VRF default(e de qualquer outra VRF que possa existir). Caso você não saiba o que é VRF, vou deixar esse link muito bacana em português que explica o que é uma VRF.
OBS:Estarei utilizando a mesma configuração e estrutura MPLS demonstrada no artigo “L2VPN” que escrevi.Sugiro que leia ele antes de prosseguir com esse.
Vamos por a mão na massa e ativar esse cliente?
Bom, observe que tanto a matriz, quanto a filial, utilizam endereçamentos que conflitam com os endereçamentos que usamos em nosso backbone (redes 172.16.20.0 e 10.10.10.0) e isso é um problema!
Precisamos garantir que esses endereçamentos não vão para a nossa VRF default pois se forem, irá impactar todo o nosso backbone. Como faremos isso? Vamos começar com as configurações de R2 e R3 que se conectam aos CPE’s que ficam no cliente.
R2-MPLS
R3-MPLS
Como podemos ver, possuímos endereços /30 configurados em ambos os roteadores MPLS e possuímos o comando “ip vrf forwarding CLI-C”para adicionar essa interface na VRF CLI-C. O comando “ip vrf forwarding X” é onde estipulamos que aquela interface irá pertencer a VRF que criamos para isolar o cliente da nossa VRF default. Vamos verificar a configuração dessa vrf?
R2-MPLS
R3-MPLS
Você deve estar se perguntando o que são esses “RD e Route-target” certo? Bom, ao criarmos a VRF, precisamos que ela tenha uma identificação (RD, ou Router Distinguisher) pois como iremos possuir vários endereçamentos conflitantes entre vários clientes, precisamos identificar de qual cliente(VRF) é qual anuncio.Podemos dizer que o RD mantém a exclusividade entre rotas iguais em diferentes VRF’s.
Obs: Esse numero é anunciado juntamente com o prefixo via MP-BGP (já irei explica-lo) no processo de troca de rotas VPN’s entre os PE’s.
Já o Route-target é onde esses prefixos são anunciados através do peer VPN. Ele possui o formato de uma comunidade estendida BGP e nela informamos o que iremos “aceitar e enviar” (import e export). No nosso caso, estamos falando que R2 possui um RD de 666:2 e irá anunciar suas rotas com o ID 666:2(export) e irá aceitar (import) rotas do peer remoto que enviar com o RD de 666:1 (no caso, R3) e o inverso acontecerá também.
Eu mencionei que o prefixo é anunciado via MP-BGP e você deve está se perguntando, o que é MP-BGP certo? O MP-BGP (Multiprotocol BGP) é um BGP que permite que o BGP envie informações de roteamento de diferentes tipos de endereçamentos. Diferente da sua versão tradicional que envia somente prefixos IPv4 Unicast, o MP-BGP anuncia prefixos IPV4/IPV6 multicast e também pode ser usado para MPLS VPN para troca de labels VPN que é exatamente o nosso caso.
Obs: Importante salientar que o MP-BGP utiliza outra “address-family” para configuração da VPN.
Vejamos a configuração do MP-BGP de R2 e R3.
R2-MPLS
R3-MPLS
Feita a configuração, vejamos o peer BGP entre R2 e R3
R2-MPLS PEER BGP
Perfeito! O peer BGP está UP. Agora, precisamos anunciar as redes dos CLI-C-USA/CLI-C-SAO PAULO na VPN entre R2 e R3. Para realizarmos isso, R2 e R3 possuem um neighbor OSPF entre cada CLI na VRF que configuramos (VRF CLI-C) que demonstramos anteriormente e realizamos a redistribuição entre OSPF-BGP e BGP-OSPF para anuncio das rotas dos clientes para o a VPNv4 que fechamos. Vejamos a configuração de R2 e R3
R2-MPLS
R3-MPLS
E é isto! Feito os redistributes, vejamos como está a VPN e as rotas que estamos aprendendo do ponto de vista de R2.
R2-MPLS VPN/ROUTES
Como podemos ver, R2 recebeu as rotas de R3 via MP-BGP, sendo elas o endereço LAN do CLI-C-USA (172.16.20.0/24) e o /30 de comunicação entre R3 e o CLI-C-USA (172.16.21.0/30) e podemos ver o RD 666:2 atachado nos anúncios de R3. Com isso, podemos concluir que nossa VPNv4 está UP e que os anúncios já estão sendo trocados através dessa VPN e que mesmo com endereçamentos conflitantes com o nosso backbone, toda a comunicação é feita dentro da nossa VRF CLI-C .
Vamos testar a comunicação entre CLI-C USA e CLI-C São Paulo?
CLI-C-USA
Conseguimos comunicação entre CLI-C-USA com a LAN de CLI-C-SÃO PAULO tranquilamente e o cliente nem imagina que seu trafego está isolado em uma VRF exclusiva e que qualquer alteração de roteamento que o mesmo faça, não irá se espalhar para demais clientes ou nosso backbone.
Observem que existe diferença entre os traceroutes demonstrados acima. Isso ocorreu pois eu desabilitei a interface eth1/2 do R3-MPLS que se conecta ao R2-MPLS somente para testar a alta disponibilidade da nossa nuvem MPLS. Veja que após a eth1/2 ficar down, o trafego migrou para a eth1/0, que é a conexão entre R3-MPLS e R1-MPLS e a comunicação não se perdeu. Isso ocorreu pois na tabela LFIB, o next-hop para a loopback que anuncia o prefixo 10.10.10.0/24 na VRF CLI-C foi alterado e nosso trafego começou a passar via ETH1/0 (agora, possuindo 2 labels) que são o label 18( do next-hop 172.16.20.5,no caso, R1 para alcançar 10.10.10.2) e 21 (O próprio R2 que origina o prefixo). Vejamos a tabela LFIB antes e depois de desabilitar-mos a interface citada assim como a tabela CEF da VRF CLI-C.
LFIB R3-MPLS ETH1/2 UP
show ip cef vrf CLI-C 10.10.10.0/24 detail R3-MPLS
LFIB R3-MPLS ETH1/2 shutdown
show ip cef vrf CLI-C 10.10.10.0/24 detail R3-MPLS
OBS: Somente o roteador no primeiro e ultimo hop precisam verificar a tabela ip (show ip cef “prefixo x”) quando o roteador recebe um pacote L3. Os roteadores MPLS no meio do caminho só precisam checar a LFIB (show mpls forwarding-table) do prefixo que queremos alcançar sem a necessidade de inspecionar o pacote inteiro poupando a control-plane do equipamento.
Realmente a L3VPN nos fornece diversas possibilidades e para um cenário onde empresas precisam se comunicar via L3 como por exemplo, configurar um tunel IPSEC para rodar através da L3VPN, ela se torna uma ótima solução que nos fornece controle, liberdade, segurança e escalabilidade tanto para o cliente quanto para o nosso backbone.
Sobre o autor:
Pedro Ferreira, CCNA , JNCIA
Technical Advisor -Networking
https://www.linkedin.com/in/pedro-hferreira/
