VXLAN EVPN como cérebro do seu Data Center
Olá Network Folks!!!
Meu nome é Pedro e vou falar um pouco sobre VXLAN EVPN para vocês hoje aqui no Tech Rebels. Esse artigo é um da série 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
VXLAN EVPN
O EVPN (Ethernet VPN) é uma solução de control plane para distribuir (anunciar) informações de L2 (MAC) e Layer 3 (IP) entre os VTEP’s em uma rede overlay(para você ter maior entendimento dos termos e do que é uma rede overlay, recomendo que leia o meu último artigo sobre VXLAN nesse link). Para que essa distribuição seja feita, é usado o protocolo BGP para suportar as extensões de EVPN para o VXLAN. Porem, não utilizaremos o BGP tradicional (que suporta somente prefixos unicast v4/v6) e sim o MP-BGP(expliquei sobre isso no artigo sobre L3VPN que você pode ver aqui).
Mas o que o EVPN traz de benefício para o VXLAN? Bom, com o EVPN agindo como o control plane do VXLAN, toda a decisão de encaminhamento agora é baseada no Control Plane o que diminui o flooding que antes era gerado no Flood &Learn e que nos fornece a liberdade de manipular que host(mac) podem ser anunciados para qual VTEP e etc (já que estamos utilizando BGP para fazer esses anúncios agora e não mais dependendo de Multicast). Algumas das funcoes da EVPN para o VXLAN são:
- Anuncio de informações de acessibilidade de hosts/redes por meio do MP-BGP (Control Plane)
- Autenticação da VTEP aumentando a segurança, pois essa autenticação é feita através dos peers BGP
- Possibilidade de ter um gateway distribuido (anycast gateway) em todo o fabric fornecendo mobilidade para VM’s de forma muito mais eficaz.
- Possibilidade de realizar um “ARP Suppression” (será explicado mais a frente) e com isso minimizar o flooding na rede.
Resumindo, agora conseguimos ter muito mais controle do nosso VXLAN e criar um ambiente muito mais inteligente e seguro. Graças a essa tecnologia, hoje já possuímos soluces SDN muito robustas (como o Cisco ACI, por exemplo)que possui VXLAN EVPN rodando em suas entranhas.
ARP Suppression
O ARP Suppression é utilizado para minimizar o flood & learn no aprendizado dos hosts. Agora, quando um host envia uma solicitação ARP, o VTEP em que está conectado esse host recebe a solicitação, intercepta e se o VTEP possuir o MAC do host de destino, o VTEP que esse host está conectado encaminhará uma resposta ARP como se fosse o host de destino para o host de origem. Porem, caso o VTEP que interceptou essa comunicação não possua uma entrada em sua tabela que corresponda o host de destino, ele encaminhará a solicitação ARP para o VTEP remoto de uma das duas formas:
- Multicast (através do BUM Traffic)
- Head-end-replication (ou Ingress Replication) através do BGP.
A imagem abaixo ilustra o que acabei de explicar
VXLAN Routing IRB
O VXLAN trabalha com dois modelos de IRB (Integrated Route/Bridge) dependendo da arquitetura que utilizemos (centralizada ou distribuída). Possuímos a forma centralizada em que todo o roteamento VXLAN é feito em roteadores centralizados (1 ou 2) o que pode gerar um trafego east-west adicional para o data center. E possuímos a arquitetura distribuída, que provê o VXLAN mais próximo dos hosts (nos Leaf Switches, por exemplo) e isso simplifica o trafego do ambiente. Usando a arquitetura distribuída, é possível trabalhar usando dois modelos de IRB, sendo eles:
- Asymmetric IRB : Permite que o routing/bridging seja realizada no VTEP de entrada(ingress VTEP), mas apenas o bridging(L2) sai nos VTEP’s de saida (egress VTEP)
- Symmetric IRB : Realiza o routing/bridging nos VTEP’s de entrada(ingress VTEP) e nos de saída(egress VTEP), resultando em um tráfego bidirecional sendo capaz de viajar no mesmo VNI, no entanto, um novo VNI de trânsito (L3VNI) é usado para todo o trafego VXLAN roteado. Com isso, todo trafego que precisar ser roteado, será roteado para o L3VNI, encapsulado pela infraestrutura da camada 3, roteado para fora do L3VNI para a VLAN apropriada, e no final será entregue ao host. (nesse cenário não iremos realizar uma comunicação entre L3VNI’s, mas, irei abordar-lo em um próximo).
Abaixo uma tabela comparativa para ajudar a entender um pouco as diferenças entre eles.
OBS: O meu intuito nesse artigo é nortear um pouco o entendimento teórico e a configuração básica do EVPN para ajudar fixar alguns conceitos. Não irei abordar tópicos de como rotas externas se integram ao meu VXLAN e nem os múltiplos designs que podem ser realizados. Para maiores detalhes de todas as possibilidades e comandos, irei deixar esse Cisco Live no qual me ajudou a conseguir criar a base para esse artigo.
Vamos por a mão na massa?
Cenário
No cenário acima, possuímos dois hosts em localidades diferentes na vlan 100 e ambos precisam se comunicar. Para essa comunicação acontecer, utilizaremos o VXLAN igual o nosso laboratorio anterior, porem agora em vez de utilizarmos o BUM Traffic para descoberta do host remoto utilizaremos o EVPN como nosso control plane. O nosso SPINE-01 será utilizado somente como Route Reflector para as atualizações BGP entre os LEAF’s já que estamos utilizando o mesmo ASN (65535) nas caixas e para não realizarmos conexões full mesh entre todos, utilizaremos o route reflector para minimizar a quantidade de peerings(podem desconsiderar a informação de L3VNI no print, pois ela será utilizada em outro artigo). Vamos começar configurando o nosso underlay(OSPF) entre as caixas.
SPINE01
LEAF-01
LEAF-02
Feito isso, vamos habilitar as features que utilizaremos para realizar a configuração do VXLAN EVPN (essas features são habilitadas no LEAF-01,02 e SPINE-01)
Vamos realizar a configuração do nosso Control-Plane? SPINE-01
SPINE01
OBS: O comando “update-source loopback0” é usado para ativar o L2VPN EVPN em cada peer BGP. O comando “address-family l2vpn evpn” é a address-family que o EVPN utiliza para enviar communitys BGP estendidas para distribuir os atributos das rotas EVPN.
LEAF-01
LEAF-02
Vamos verificar se nosso peer BGP entre LEAF-01 e SPINE-01 fechou?
Boa! Observem que eu dei o comando “show ip bgp summ” para mostrar a diferença entre um peer convencional e o peer de L2VPN. Com o meu Control plane criado, vamos realizar a extensão entre a vlan dos hosts para com a VXLAN (o mesmo print serve para os LEAF’s01 e 02) LEAF-01/LEAF-02
Perfeito! Criamos a vlan 100 e atrelamos ela ao nosso L2VNI (vn-segment 7000) e habilitamos o EVPN Control plane para serviços L2 dessa VNI (toda a parte de config a partir de “evpn”). Após isso, criamos a nossa interface VTEP (nve1) e habilitamos a VNI 7000 nessa VTEP. Configuramos o suppress-arp (conforme expliquei anteriormente) e utilizamos o ingresss-replication protocol BGP para não utilizarmos mais multicast para comunicação entre os VTEPS, e sim, unicast BGP. Vamos verificar como está a configuração da interface vlan dos hosts e realizar alguns testes?
LEAF-01
LEAF-02
Como podemos ver, a interface vlan dos hosts está em uma VRF dedicada para o cliente (CLI-A) e tanto LEAF-01 quanto LEAF-02 possuem o mesmo ip (192.168.30.1/24) e o porquê disso? Uma das vantagens em um ambiente com EVPN é a possibilidade de conseguir implementar o anycast gateway. Com essa configuração, eu não preciso mais da utilização de protocolos de FHRP (HSRP,GLBP,VRRP) que possuem downtime e trabalham com a ideia de ativo/passivo e passo a ter um core distribuido onde todo o caminho fica como ativo/ativo. Do ponto de vista da máquina, o gateway que estiver mais proximo “fisicamente” dela, será o seu GW de comunicação. Obs: Para realizar esse teste, é preciso que cada host tenha uma conexão com o outro leaf no qual está configurado o GW, porem nos emuladores ainda não é possivel realizar configurações de LACP ou VPC. Vamos testar a comunicação entre os hosts.
HOST-A
E pingou! Vamos entender no detalhe como que o HOST-A conseguiu comunicação com o HOST-B que está em outro DC.
LEAF-01
Como pode ser visto, LEAF-01 recebe através do BGP o MAC 5036.002f.0000 via BGP e seu next hop para alcança-lo é 3.3.3.3 (loopback de LEAF-02). No “show bgp l2vpn evpn” conseguimos detalhes de quem é o originador desse MAC, qual é sua community e qual é o IP do MAC final 0000 (que é 192.168.30.3).
Espero que esse artigo tenha ajudado a clarear um pouco do que é EVPN e como ele fornece uma gama de possibilidades ao VXLAN. É um assunto complexo então é normal ficar perdido durante a execução e leitura, mas, recomendo que tentem subir o laboratorio junto com esse artigo e com os links que deixei marcado durante o artigo para ajudar a fixar o conteudo. Uma outra dica, é o livro da Cisco “Building Data Centers with VXLAN BGP EVPN: A Cisco NX-OS Perspective”
Sobre o autor:
Pedro Ferreira, CCNA , JNCIA
Technical Advisor -Networking
https://www.linkedin.com/in/pedro-hferreira/
