em 03-07-2023 06:21 AM
Olá Network Folks!!!
Meu nome é Pedro e vou falar um pouco sobre VXLAN EVPN para vocês hoje. 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
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:
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.
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:
A imagem abaixo ilustra o que acabei de explicar
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:
Abaixo uma tabela comparativa para 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?
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 laboratório com esse artigo e com os links que deixei marcado durante o artigo para ajudar a fixar o conteúdo. Outra dica, é o livro da Cisco “Building Data Centers with VXLAN BGP EVPN: A Cisco NX-OS Perspective”
Excelente conteúdo meu amigo. Grande abraço.
Conteúdo muito agregador!!
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.
Navegue pelos links rápidos da Comunidade e usufrua de um conteúdo personalizado e em seu idioma nativo: