Olá Network Folks !!

Estamos com mais um post no Howtonetwork com um tema muito bacana e interessante(e um pouco complexo rs) que já existe em nossas vidas a muito tempo e que facilita muito nosso trabalho em ativação de clientes e em escalabilidade da rede. Estou falando da “VPN de camada 2”, a L2VPN.

É um tema bem interessante e que requer um pouco de atenção, então pega um café bem forte e vem comigo.

L2VPN

O L2VPN nada mais é do que uma “simulação” de conexão L2 (layer 2) entre dispositivos que estão em pontos geográficos distintos da rede, porem diferente do modelo tradicional de extensão de vlan em todo o backbone, nos utilizamos o backbone MPLS para realizar esse transporte. Segundo o IETF(Internet Engineering Task Force) os L2VPN’s são construídos com tecnologia de PSEUDOWIRE(PW) que utiliza uma rede (L3) para transportar serviços L2. É isso mesmo que você leu, transportaremos vlans em nosso backbone IP e para o cliente será como o teletransporte do Goku, totalmente transparente e independente da localização!

Mas, você deve está se perguntando “Pedro, porque usar isso em vez eu estender uma vlan em todo o ambiente e realizar o acesso para o cliente onde ele precisa e não gerar essa complexidade utilizando o MPLS?”

De fato, em uma primeira olhada parece que ao utilizarmos o tão famoso MPLS iremos deixar o ambiente muito complexo, mas, é mais simples do que parece!

Imagine por um momento um grande ISP que possui 500 switches em sua rede. Imagine o trabalho moroso em ter que passar 1 vlan nova para cada cliente novo que entra? Fora isso, imagine os possíveis problemas de uma rede tão grande com um domínio L2 tão extenso.

Listo alguns sendo eles:

• Complexidade da topologia STP do ambiente além da correção de possíveis loops que ocasionariam um downtime muito grande.

• Falta de escalabilidade já que ficaríamos limitados a um valor máximo de 4094 vlans.

• O grande numero de MACS que o ambiente possuiria o que lotaria a tabela CAM dos switches causando grandes impactos ao ambiente.

• Possibilidade de erro humano (o temível switchport trunk allowed vlan sem o “add” rs).

OBS: Caso você não saiba o que é VLAN, convido você a ler esse artigo que escrevi sobre esse tema

Podemos ver que esses pontos já provam por si só que se podemos evitar um domínio L2 extenso e diminuir a intervenção humana para ativações de cliente, o L2VPN se torna uma das solução que vale a pena ser implementada.

Importante sinalizar que irei somente mencionar o VPWS nesse artigo, mas que existem outras tecnologias possíveis de utilizar esses benefícios, cada uma com sua particularidade sendo elas:

-ATOM (Any transport over MPLS)

-L2TPv3 (Layer2 Tunneling Protocol version 3)

-VPLS (Virtual Private LAN Service)

-EVPN (Ethernet VPN)

Então, vamos entender como essa mágica funciona?

Topologia

Conforme demonstrado no lab acima, possuímos o backbone do ISP 666 no qual há 2 switches metro que são responsáveis por receber os CPE’s (equipamentos do ISP 666 que ficam na estrutura do cliente) dos clientes, respectivamente os CPE’s CLI-A,CLI-B e CLI-B-FILIAL, e possuímos na nuvem MPLS do provedor os equipamentos que realizam a troca de labels através do protocolo IGP OSPF e possuímos o CORE com o nome CORE-INTERNET que possui um link com o “google” somente para simularmos um acesso a internet.

Obs: Para quem não possui familiaridade com o tema “MPLS”, sugiro que leia o link que explica de forma bem superficial e simples o que é somente para que norteie o entendimento do que irei explicar.

Possuímos as seguintes demandas:

1. CLI A ASN 667 contratou o link de internet do ISP 666 e possui uma sessão BGP com o CORE-INTERNET no qual divulga o seu prefixo 192.168.0.0/24 (somente para exemplificação) e recebe o prefixo do google (8.8.8.8).
   

2. CLI-B/CLI-B-FILIAL possui contratado um L2L entre matriz e filial com o ASN666 e ele deseja configurar um protocolo de roteamento dinâmico dentro desse L2L para evitar que seja configurado rotas estáticas para cada nova filial ativada.

Cenário 1) CLI-A INTERNET

Conforme mencionado, o CLI-A contratou o link de internet do ISP666 e com isso irá precisar fechar uma sessão BGP (peering) com ele através do endereço 200.200.200.0/30 que foi fornecido para realizar esse peering.

Obs: se você não sabe o que é BGP, sugiro que leia o artigo que escrevi sobre isso e como se configura nesse link .

Primeiramente, vamos ver como está a configuração no SW-METRO1 que é responsável por receber o CPE e de interconectar com a rede MPLS.

SW-METRO1

Como podemos ver, a vlan 200 é a vlan desginada pelo ISP 666 para o CLI-A e na ETH1/1 realizamos o acesso para o cliente. Já no uplink que é a ETH1/3, passamos a vlan para o backbone MPLS para que seja transportada (o comando “switchport mode trunk” está passando TODAS as vlans, mas é somente para agilidade do lab, nunca façam isso em ambiente produtivo!).

Vamos ver como está nossa nuvem MPLS.

R1-MPLS

Conforme pode ser visto, o R1-MPLS na sua interface com o SW-METRO1 possui sub-interfaces (já que essa é uma interface TRUNK) contendo o dot1q de cada vlan que irá passar por essa porta (vlan 300 será mencionada posteriormente) e realiza o encapsulation das mesmas. Para que os PW’s anunciem as vlans via LDP’s (Label distribution Protocol do MPLS), o comando XCONNECT é utilizado. Esse comando é o responsável por realizar a configuração dos PW entre os PE (Providers Edge’s ou Roteadores PE da nuvem MPLS) envolvidos no encapsulamento e desencapsulamento desse transporte. Eu sei, parece confuso, mas ficará mais claro.

No comando “xconnect 10.10.10.2 200 encapsulation mpls” na interface eth 1/1.200, estamos falando que iremos encapsular a vlan 200 e transportaremos ela para o peer 10.10.10.2, que é o endereço loopback de R2. Porque R2? Pois ele é o PE mais próximo do CORE-INTERNET, que é o equipamento onde existe a vlan 200 levantada para comunicação com o cliente. Podemos verificar esse peer VPN fechado com o comando "show xconnect all" conforme abaixo

Vamos verificar os neighbors MPLS de R1 e quais os labels que são atrelados ao prefixo 10.10.10.2, que é onde estamos fechando o túnel XCONECT?

Você deve estar se perguntando “Então eu preciso ter comunicação IP com o IP que eu irei fechar essa VPN L2?” e a resposta é sim, é preciso. Perceba que possuímos um OSPF rodando na rede MPLS entre os 3 PE MPLS (R1,R2 e R3) no qual cada um divulga seu endereço loopback, e que utilizamos o ip “10.10.10.2” como ip de destino para fechar o peer PW já que em caso de falha entre R1 e R2 (a fibra romper, por exemplo), eu alcance o endereço loopback de R2 através de R3, e o meu peer PW com o 10.10.10.2 não ficará indisponível, fazendo com que o label responsável pelo transporte vá para outro caminho de forma transparente! Isso tudo pode ser verificado abaixo com um show do ponto de vista de R1.

Essa é uma das diversas vantagens de utilizar a rede MPLS para transporte de serviços.

Obs: Os comandos “mpls ldy sync” e “mpls ldp autoconfig” são para sincronização dos ldp’s e para autoconfiguração ldp na interface que está rodando OSPF.

Abaixo estão as configurações de R2 e R3.

R2-MPLS

Como podemos observar no R2-MPLS, a segunda parte da VPN é configurada e consiste em configurar o “xconnect” apontando o IP loopback de R1-MPLS conforme o comando “xconnect 10.10.10.1 200 encapsulation mpls” finalizando assim a configuração da L2VPN. As demais configurações MPLS/OSPF são a mesma das mencionadas no R1-MPLS.

R3-MPLS

R3 somente possui as configurações OSPF/MPLS já mencionadas na configuração de R1 pois ele servirá de trânsito de labels no nosso cenário provendo a alta disponibilidade da nossa nuvem MPLS. Abaixo as configurações realizadas em R3

Perfeito! Entendemos como o transporte dos labels é feito através do IGP(OSPF) que está rodando na nuvem MPLS, agora podemos verificar as configurações do CORE-INTERNET.

CORE-INTERNET

Somente isso! Do ponto de vista do CPE, somente foi necessário configurar o ip de comunicação com o ISP 666 através do /30 disponibilizado pelo mesmo (configurações BGP realizadas não serão mostradas por não serem o escopo do artigo). Vejamos as configurações do CLI-A e os testes de comunicação.

CLI-A

Do ponto de vista do CPE, somente foi necessário configurar o ip de comunicação com o ISP 666 através do /30 disponibilizado pelo mesmo (configurações BGP realizadas não serão mostradas por não serem o escopo do artigo)e o mesmo já esta com a sua sessão BGP up e liberado para testes.

Vamos validar a comunicação do CLI-A para com o ISP666 e para o google?

Sucesso! Conseguimos comunicação com o CORE-INTERNET de forma transparente como se possuímos um grande fio (por isso o nome pseudowire) entre o CLI-A/CORE-INTERNET, porem passando por uma grande malha L3 totalmente escalável e resiliente que mesmo desabilitando a ETH1/2 de R1 (conforme demonstrado anteriormente), a sessão BGP do cliente se manteve UP.

Testes feitos, podemos considerar o CLI-A ativado e liberado para a produção.

CENÁRIO 2) CLI-B/CLI-B-FILIAL

Conforme mencionado anteriormente, CLI-B contratou o serviço de L2L com o ISP666 para interligar sua matriz e filiais. Na primeira ativação, o mesmo solicitou que por “dentro” desse L2L, ele consiga rodar o seu próprio protocolo IGP para não ter que realizar apontamento estático de cada LAN de uma unidade nova. Essa configuração ficará como responsabilidade do cliente então não irei abordar as configurações do OSPF configurado e somente da interligação e da validação da comunicação.

Para começar, vamos verificar nossos SW’s Metro.

SW-METRO1

SW-METRO2

Bem similar a ativação do CLI-A não é mesmo? Vejamos agora a configuração da nuvem MPLS!

R1-MPLS

R2-MPLS

A mesma logica do “xconnect” explicada anteriormente foi utilizada e os mesmos comportamentos de Labels e de encapsulation se mantiveram. Já conseguem ver a agilidade da ativação de 1 novo cliente após toda a infra estar funcionando? Vejamos os CLI-B/CLI-B-FILIAL!

CLI-B

CLI-B/FILIAL

E está feito! Do ponto de vista do cliente, subimos o IP diretamente na interface que conecta com os seus respectivos SW-METRO e está funcionando como mágica.

Vamos validar?

Comunicação funcionando e cliente ativado!

Importante observar que,caso alguma interface que possua o comando “xconnect x encapsulation mpls” fique indisponível, o túnel irá ficar como DOWN pois como a interface está fora, ele entende que o frame da vlan não está chegando mais e com isso o peer ficará indisponível. Abaixo esta os logs PW da vlan 200 de R1-MPLS após eu derrubar a interface eth1/3 do R2-MPLS.

Conclusão

Esse método é somente uma das diversas tecnologias L2VPN que aproveitam da inteligência de labels do MPLS para transportar o frame ethernet por dentro da rede IP. Existem outras tecnologias mais fáceis e flexíveis como EVPN mas acredito que o PW já consegue dar uma demonstração mais didática do seu beneficio para o backbone.

Espero que esse artigo tenha clareado um pouco sobre esse assunto e espero escrever em breve sobre mais tecnologias L2VPN.