Olá Network Folks !
Após um período parado, voltamos com outro artigo para os amantes de EVPN e de labels. Irei falar sobre como utilizar o EVPN como Control Plane para serviços de VPWS (P2) em seu backbone e como se configura esse cenário.
Pegue um café bem forte, e let's routing (MACs hahaha) !
EVPN na perspectiva do ISP
Com a evolução das demandas de interconexão, os IPSs se depararam com questões de como ofertar serviços de alta disponibilidade e resiliência, sem aumentar a complexidade e impactar diretamente a operação? Com cada vez mais soluções de abstração, a automação se tornando uma realidade e com os equipamentos se tornando mais robustos e acessíveis, alguns service providers começaram a utilizar dos benefícios do EVPN para incrementar suas ofertas de serviço e com isso, tirando a complexidade técnica de se sustentar esse ambiente (se você não sabe o que e EVPN, sugiro que leia esse artigo aqui para não ficar perdido).
A Cisco escreveu um artigo com uma rica quantidade de detalhes sobre os motivadores e cenários possíveis na utilização de EVPN para os service providers.
Vendo isso, e se pudéssemos trazer uma melhor administração sobre nossos VPLS/VPWS (P2MP/P2P) utilizando o BGP e conseguir utilizar a resiliência que o MPLS possui? Pois será isso que veremos agora!
Cenário
No cenário acima emulei o backbone de um ISP (65666) e simulei 2 clientes (CPE1 e CPE2) que possuem dois servidores em unidades distintas e ambos precisam se comunicar. Para deixar mais interessante, fiz com que cada PE fechasse um OSPF entre eles para divulgar os prefixos dos servidores utilizando a malha backbone do meu ISP para estabelecerem o peering. Veja que os PEs estão dentro da mesma subnet 192.168.100.0/30 logo, os PEs precisam conseguir gerar ARP para se pingarem e estabelecerem a vizinhança entre eles e os prefixos sejam trocados sem que o backbone tenha qualquer conhecimento desses prefixos. No nosso backbone MPLS, estamos utilizando IS-IS como IGP e o LDP para troca de labels.
OBS: Poderíamos utilizar Segment routing, ou ate mesmo fazer engenharia de trafego MPLS com o MPLS TE + RSVP, mas foquei em deixar o lab mais simples possível para focarmos em como o BGP EVPN fornece o serviço de L2VPN para o cliente.
As versões dos devices usados foram:
P1 e P6= IOS XR 6.1.3
SW-Metro1 e SW-Metro2 = NX-OS 9.2
PE1-XE,PE2-XE,P2-CSR,P3-CSR,P4-CSR,P5-CSR = CSR1000V IOS XE 16.09.07
CPE1-CPE2 = Cisco IOL i86bi-linux-l3-adventerprisek9-15.4.2T
Para começar, vamos verificar as configurações dos PE1 e PE2 referente ao core side
PE1-XE
PE2-XE
Podemos ver que ambos os PE's possuem a configuração na sub-interface x.100 de "xconnect" apontando para as loopbacks de ambos os PEs. Essa configuração é para criar o destino do tunel L2 entre os devices e que o encapsulation desse tag de vlan (no nosso caso, vlan 100) será feito pelo MPLS. Abaixo uma imagem que ilustra esse processo
Podemos ver abaixo que possuímos nossas adjacências IS-IS e que possuímos o LDP configurado.
PE1-XE IS-IS neighbors and MPLS forwarding-table
P1-XR
Vamos verificar a tabela de rotas de P1 e ver como aprendemos a loopback de PE2-XE?
P1-XR routing table e traceroute para lo de PE2-XE
Perfeito! Possuímos na nossa tabela de roteamento todos os prefixos do nosso backbone. Se realizarmos um ping entre os PEs utilizando as lo0 como source, provavelmente teremos comunicação.
Teste de ping entre os PEs
Feito a parte do IGP, agora precisamos criar a instância do serviço L2 nos nossos PEs na interface que vai para o cliente.
Você deve estar se perguntando, o que são os comandos"service instance x " e toda a configuração de bridge-domain?
Bom, nos switches tradicionais, sempre que possuimos uma interface trunk, utilizamos o tag de vlan para classificar esse tráfego. Acontece que alguns devices não possuem a capacidade de utilizar os conceitos de "Switchport mode trunk" e com isso devemos utilizar o Ethernet Virtual Circuit ou EVC para aproveitar as tags 802.1q existentes. Não apenas isso, o EVC permite que tenhamos diversos servicos L2 dentro da mesma interface física, podendo assim utilizar a mesma vlan para diferentes clientes em cada switchport e encaminhar o tráfego de cada cliente atraves de diferentes PWs MPLS pois a vlan (no nosso caso, vlan 100) não existe GLOBALMENTE. Vou deixar abaixo um desenho da Cisco mostrando esse conceito e recomendo fortemente a leitura desse artigo deles.
Quando um frame com tag de vlan entra (ingress) em uma interface que foi configurada com um EVC , determinaremos qual EVC ele sera classificado com base nos tags do quadro e dentro dele, definiremos qual ação desejamos realizar.
Dito isso, dissecando nossa configuração de PE1-XE só para entendimento do processo:
Criamos a service instance 100 ethernet que define a instância de servico "ethernet" (coloquei o mesmo ID da vlan para ficar mais intuitivo. Por isso possuimos uma service instance para o servico de L2VPN da vlan 100, e um para a gerencia do SW-METRO!)
encapsulamos esse tag no comando "encapsulation dot1q 100" (o mesmo para a instancia do SW-METRO, porem no vlan ID 110)
REMOVEMOS esse tag com o comando "rewrite ingress tag pop 1 symetric", que quer dizer que ao receber 1 tag de vlan, nos removeremos esse tag e encaminharemos para a nossa nuvem MPLS.
Informamos no comando "xconnect x.x.x.x encapsulation mpls" mostrado anteriormente que enviaremos esse frame pela nuvem MPLS (no nosso caso, um VPWS por ser apenas um P2P)
Quando esse frame chega no PE2-XE, o inverso ocorre, ele irá identifical a qual service instance está associado esse frame, adicionará o tag da vlan no nosso caso, a vlan 100, e encaminhará para a porta que contem o encapsulation 802.1Q que no nosso caso, é o SW-METRO2.
O comando "member GigabitEthernet1 Service-instance 100" e "member evpn-instance 100" é necessário para que o EVPN faça o control plane dos frames que possuírem esse tag de vlan.
Feito essa configuração, agora precisamos configurar os SW-METRO1 e SW-METRO2 com as vlans que definimos nos nossos EVCs, e realizar a configuração do EVPN.
SW-METRO1 L2 Config
SW-METRO2 L2 Config
Agora vamos realizar a configuração do EVPN!
OBS: Lembrando que o EVPN utiliza uma outra AFI/SAFI logo, utilizaremos toda uma address family diferente para realização desse peer BGP.
No nosso cenário, possuímos um Route Reflector, que é o P3-CSR-RR, logo- PE1-XE e PE2-XE irão configurar seus peers BGP para o RR.
EVPN config e BGP config do PE1-XE
EVPN config e BGP config do PE2-XE
BGP config RR P3-CSR-RR
Vamos verificar se o peer BGP na AFI/SAFI do BGP EVPN está estabelecida?
BGP L2VPN EVPN PEERING
Perfeito! Podemos ver que o peering foi estabelecido, e que se olharmos os neighboors dentro da address-family ipv4 tradicional, não existe qualquer peer configurado.
Vamos verificar se aprendemos os MACs no nosso bridge-domain e se nossa EVPN EVI está estabelecida?
PE-XE1
PE2-XE
Agora, iremos verificar se nosso xconnect esta UP e se recebemos os MACs via BGP!
PE-XE1 EVPN routes and xconnect state
PE2-XE1 EVPN routes and xconnect state
Ambos os PEs recebem o MAC dos CPEs de ambas as portas. O mac final 0.100 é o MAC do PE1 , enquanto o MAC final 0.f100 é o MAC do PE2. Podemos ver que os prefixos (MAC address) dos CPEs são recebidos através do meu peering com o Route Reflector, e que essa rota foi exportada e importada (import/export) baseado no meu RT/RD configurado.
Com isso, CPE1 e CPE2 agora possuem comunicação entre eles dentro do mesmo domínio de broadcast, e ambos conseguem gerar ARP e estabelecer a sessão OSPF entre eles!
CPE-1 Tests
CPE 2 Tests
E por fim, basta testarmos a comunicação entre os servidores para validar se ambos os servers se pingam.
Servers communication
SUCESSO! Ambos os servidores se pingam utilizando o backbone MPLS do provedor AS65666.
Com isso finalizamos a demonstração da utilização do EVPN para serviços L2VPN .Pode parecer muito extenso, mas uma vez aplicada essa lógica, a escala se torna muito mais interessante e possuímos o control plane do EVPN para saber exatamente quais MACs estão sendo anunciados para o nosso cliente.
Abaixo os scripts de configuração e espero que o artigo tenha ajudado a entender melhor como o EVPN funciona em uma operadora, e nos vemos na próxima!
