cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
cancel
2809
Apresentações
10
Útil
0
Comentários
Pedroxh
Spotlight
Spotlight

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:

  1. A necessidade de realizar configurações L2 na rede metro já que toda a L3VPN é feita via IP+MPLS entre PE’s.
  2. Broadcast na rede ainda irá existir utilizando L2VPN.
  3. 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


 

Pedroxh_2-1637335907253.jpeg

 

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


 

Pedroxh_4-1637335907198.jpeg

 

R3-MPLS

Pedroxh_6-1637335907255.jpeg

 

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


 

Pedroxh_8-1637335907206.jpeg

 

R3-MPLS


 

Pedroxh_10-1637335907310.jpeg

 

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


 

Pedroxh_12-1637335907406.jpeg

 

R3-MPLS


 

Pedroxh_14-1637335907313.jpeg

 

Feita a configuração, vejamos o peer BGP entre R2 e R3

R2-MPLS PEER BGP


 

Pedroxh_16-1637335907334.jpeg

 

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


 

Pedroxh_18-1637335907340.jpeg

 


 

Pedroxh_20-1637335907489.jpeg

 

R3-MPLS


 

Pedroxh_22-1637335907447.jpeg

 


 

Pedroxh_24-1637335907392.jpeg

 

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


 

Pedroxh_26-1637335907393.jpeg

 


 

Pedroxh_28-1637335907366.jpeg

 

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


 

Pedroxh_30-1637335907415.jpeg

 


 

Pedroxh_32-1637335907443.jpeg

 

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


 

Pedroxh_34-1637335907418.jpeg

 

show ip cef vrf CLI-C 10.10.10.0/24 detail R3-MPLS


 

Pedroxh_36-1637335907378.jpeg

 

LFIB R3-MPLS ETH1/2 shutdown


 

Pedroxh_38-1637335907469.jpeg

 

show ip cef vrf CLI-C 10.10.10.0/24 detail R3-MPLS


 

Pedroxh_40-1637335907446.jpeg

 

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.

Primeiros Passos

Encontre respostas, faça perguntas e conecte-se com nossa comunidade de especialistas da Cisco de todo o mundo.

Estamos felizes por você estar aqui! Participe de conversas e conecte-se com sua comunidade.