cancelar
Mostrar resultados para 
Pesquisar em vez de 
Queria dizer: 
cancel
1008
Apresentações
5
Útil
1
Comentários
Pedroxh
Spotlight
Spotlight

 

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 . A ideia do site é explicar um pouco os conceitos sobre as tecnologias que estou estudando/implementando com um lab para termos um pequeno “hands on” e não ficar somente na parte teórica. 

 

VXLAN EVPN

Pedroxh_19-1678198049011.jpeg

 

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

Pedroxh_20-1678198048934.jpeg

 

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 entender um pouco as diferenças entre eles.

Pedroxh_21-1678198048898.jpeg

 

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

Pedroxh_22-1678198049122.jpeg

 

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

Pedroxh_23-1678198048880.jpeg

 

LEAF-01

Pedroxh_24-1678198048902.jpeg

 

LEAF-02

Pedroxh_25-1678198048905.jpeg

 

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)

Pedroxh_26-1678198048821.jpeg

 

Vamos realizar a configuração do nosso Control-Plane? SPINE-01

SPINE01

Pedroxh_27-1678198048834.jpeg

 

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

Pedroxh_28-1678198048892.jpeg

 

LEAF-02

Pedroxh_29-1678198048884.jpeg

 

Vamos verificar se nosso peer BGP entre LEAF-01 e SPINE-01 fechou?

Pedroxh_30-1678198048928.jpeg

 

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

Pedroxh_31-1678198048888.jpeg

 

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

Pedroxh_32-1678198048872.jpeg

 

LEAF-02

Pedroxh_33-1678198048918.jpeg

 

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

Pedroxh_34-1678198048923.jpeg

 

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

Pedroxh_35-1678198048932.jpeg

 

Pedroxh_36-1678198048914.jpeg

 

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”

Comentários
tomy.tim
VIP
VIP

Excelente conteúdo meu amigo. Grande abraço.

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.