VXLAN e o uso de redes Overlay

[Pedroxh]

Olá Network Folks !!

Meu nome é Pedro e sou analista SR de redes com foco em Data Centers e Service Providers. Há 2 anos criei o site www.howtonetwork.com.br e posto diversos artigos técnicos sobre diversos temas de routing/switching voltados para esses dois ambientes para ajudar a comunidade técnica que encontra dificuldade de alguns temas especificos em PT/BR e uso referencias de DBZ (Dragon Ball Z) para dar alivio cômico nesses assuntos técnicos rs. Irei deixar esse post sobre VXLAN e o uso de redes Overlay que fiz a algumas semanas e convido a todos para acessarem os demais artigos no site que mencionei a cima. Let's routing!

Overlay e Underlay

Nos dias de hoje,é inadmissível os DC's sofrerem com problemas das arquiteturas tradicionais sendo alguns deles:

• Problemas de convergência do STP (Spanning-Tree Protocol).

• Ausência de ECMP (Equal-cost multi-path routing).

• Escalabilidade da rede.

• Subutilização dos Links.

• Não mobilização das maquinas entre os DC's(se necessario).

A nossa principal necessidade,é que os recursos de multitenancy e virtualização (como mobilidade) fossem escaláveis para suportar o ambiente de alta demanda ao qual nos encontramos hoje.E é ai que as redes Overlay entram.

Mas afinal, o que é Overlay? Bom, uma rede Overlay (rede sobreposta) é uma rede virtual construida "sobre"uma rede inferior (Underlay). De forma clara, são tuneis NVO (Network Virtualization Overlay) como por exemplo VXLAN,NVGRE,MPLSoE que utilizam a rede Underlay (protocolos de roteamento como OSPF, EIGRP, IS-IS, BGP) para construção dessa rede, permitindo caminhos redundantes sem a necessidade de STP,ECMP's para balanceamento de carga e uma topologia flexível.

Ou seja, fazendo uma analogia ao gif abaixo, o Goku é o nosso Underlay, e o Dragão que sai de seu punho é o nosso Overlay!

VXLAN

O VXLAN (Virtual Extensible Lan) é um protocolo overlay de encapsulamento que fornece conectividade usando tunelamento para estender as conexões da camada 2 em uma rede L3. Ele realiza isso fazendo um encapsulamento dos frames (MAC's) em pacotes UDP 4789 e possui dois modos de operação, o Flood & Learn (que será abordado nesse artigo) e o BGP EVPN (que irei abordar em um próximo).

Importante deixar claro alguns benefícios do VXLAN:

• Fornece segmentação,mobilidade IP e escalabilidade

• Não ficamos mais limitados mais aos 4094 VLAN ID e passamos para 16 milhões de endereços possíveis (que será explicado mais a frente como.)

• ECMP

• Integração fisica e virtual

• Utilizada pelo SDN ou Software Defined Network (como por exemplo no Cisco ACI)

Já que vimos os ganhos, vamos entender agora como ele funciona?

VXLAN VTEP

O VTEP (Vlan Tunnel End Point) é um equipamento que origina e/ou termina os tuneis VXLAN.Ele realiza o encapsulamento/desencapsulamento do pacote VXLAN. Essa VTEP possui duas interfaces sendo, uma para fornecer os serviços L2 tradicionais (porta de acesso para uma maquina final ou trunk para um hypervisor), e outra tem uma identificação de IP para encapsulamento/desencapsulamento do VXLAN (ou, interface IP Underlay, que envia e recebe pacotes VXLAN encapsulados,no caso, a interface NVE). Abaixo um desenho que ilustra o que acabei de explicar.

Mas, como conseguimos identificar o trafego VXLAN para saber onde está se originando e para onde encaminha-lo?Com o VNI!

VXLAN VNI

O VNI (Vxlan Network Identifier ou VXLAN ID) é uma ID única de 24 bits conforme imagem abaixo(similar ao TAG de vlan) que é utilizada para identificar um segmento VXLAN (nos valores de 4096 até 16,777,215 VNI's possiveis)

OBS: Importante lembrar que maquinas em VXLAN's diferentes, ou seja, em VNI's diferentes não podem se comunicar por default. Para isso ocorrer, é necessario realizar um roteamento entre as VNI's.

Você deve estar se perguntando, como é feito esse encapsulamento? Bom, de forma resumida, o pacote original enviado pelo host na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquela maquina virtual pertence(mais a frente irei detalhar os passos no nosso lab e tudo isso fará mais sentido!)

OBS: Como o VXLAN Header, o frame ethernet passa a ter um MTU de 1550 bytes por causa do acréscimo de 50 bytes de overhead! É importante garantir que todo o caminho entre os VTEPs suportem mais do que 1500 bytes pois os pacotes VXLAN não podem ser fragmentados!

Bom, após essa teoria extensa, vamos por a mão na massa e entender como configura e funciona um dos métodos do VXLAN, o Flood & Learn?

Flood & Learn VXLAN

Conforme imagem abaixo, iremos realizar um cenário simples de 2 servidores (Winserver46 e 47) em dois N9K simulando um PTP entre eles como se estivessem em locais distintos. Não irei abordar o roteamento entre VNI's pois isso será abordado mais a frente no artigo sobre VXLAN EVPN!

O objetivo é realizar a comunicação entre os servidores que estão na mesma rede (192.168.30.0/24) sem a extensão de vlan entre os N9K e entender como o processo do VXLAN.

No processo de Flood & Learn é utilizado multicast routing (não irei entrar muito em detalhes sobre Multicast Routing, mas deixarei esse link que entra no detalhe os modos de operação). Isso é necessario para podermos realizar o chamado BUM(Broadcast,Unknow Layer 2 Unicast e Multicast) Traffic e assim,conseguirmos encaminhar o pacote para todos os VTEP's que estão como listeners na rede overlay.

Como vimos na imagem do cabeçalho VXLAN, possuímos o campo "OUTER IP" que contem o endereço VTEP de origem e o endereço VTEP de destino.Caso ele não conheça o VTEP de destino,ocorre o processo de FLOOD para se descobrir esse endereço.O VXLAN substitui o endereço de destino pelo ip do MULTICAST GROUP correspondente a VNI(configurável) que está originando a comunicação e envia um flood para esse grupo através da rede IP (underlay).

OBS: Todos os VTEPs membros do mesmo VNI, juntam-se ao mesmo grupo multicast, ou seja, mapeamento 1:1 (VNI:Multicast Group)!

Vejamos as configurações do CORE01 e do CORE02.

CORE01

CORE02

Como podemos ver, possuímos um Underlay (OSPF) entre os core para realizar o roteamento das loopbacks entre os cores. Possuímos 2 loopbacks por 2 motivos:

1. Loopback0 é a loopaback que as nossas NVE's interface irão utilizar para comunicar com o multicast-group 230.1.1.1 para transportar a VNI 6000 que está atrelada a vlan 1000 que é a vlan dos hosts. (vn-segment 6000 na parte "vlan 1000" conforme prints acima)

2. Loopback1 para possuirmos uma redundância de RP ou, Rendzvous Point, que funciona como um "concentrador" do trafego multicast e que fica responsável por receber todos os interessados (join messages) para ele encaminhar o conteúdo aos demais interessados.Esse é o motivo de havermos a mesma rede(3.3.3.3/32) nos dois CORE e de esse endereço ser o nosso RP conforme o comando ip pim rp-address 3.3.3.3 group-list 224.0.0.0/4.

A parte de "ip pim" é toda a configuração multicast que realizamos para o cenario funcionar.Vamos realizar algumas verificações?

CORE01

Como podemos ver, o peer NVE está up através da loopback0 e o nosso peer é o endereço 2.2.2.2 (loopback0 de CORE02). Podemos ver também que o encapsulamento usado nesse túnel é o VXLAN e que possuímos uma VNI atrelada a uma VLAN (vlan 1000 no nosso caso) e que o multicast group dessa VNI é o 230.1.1.1.

OBS: O VXLAN é uma tecnologia de DATA PLANE.Ou seja, essa tecnologia não realiza o aprendizado dos hosts/rede sem que seja necessario um flood (tentativa de envio de trafego) e nem possui inteligencia para podermos realizar um controle do que router pode aprender qual MAC e nem manipulações de roteamento.Para realizarmos isso, é necessario termos um CONTROL PLANE que no caso, é o EVPN.

Vamos verificar se as maquinas possuem comunicação?

WINSERVER46

Perfeito! A maquina final 30.2 consegue comunicação com a maquina final 30.3 através do VXLAN normalmente!

Infelizmente não é possível poder pegar muitas informações via comandos "show" do processo do VXLAN Flood & Learn por ele ser somente Data Plane(somente seria possível utilizando um Wireshark para sniffar esse teste de ICMP mas não consigo realizar isso pois o meu lab fica na nuvem) mas os passos seriam:

1. CORE01 recebe o pacote do WINSERVER46 e grava/aprende o SMAC

2. CORE01 faz o lookup do MAC de destino e do VNI6000 (VNI + DMAC)

3. CORE01 envia para todos os receivers do grupo multicast associado ao VNI6000 (no nosso caso,230.1.1.1)

4. CORE02 recebe o pacote e grava o VNI e SMAC do WINSERVER46

5. CORE02 encaminha o pacote para o VNI6000 no qual é atrelado a vlan 1000 (igual em CORE01)

6. WINSERVER47 envia (unicast) um ARP RESPONSE para o CORE02.

7. CORE02 recebe o pacote do WINSERVER47 e grava/aprende o SMAC

8. CORE02 faz um lookup do VNI e do DMAC do WINSERVER46, encapsula os pacotes com VXLAN e encaminha ao CORE01 em unicast.

9. CORE01 aprende o SMAC do WINSERVER47 na VNI 6000

10. CORE01 faz um lookup do VNI e DMAC do WINSERVER46 e então o encaminha pela ETH1/2(access na vlan 1000)

11. Após isso, todo o trafego entre WINSERVER46 e WINSERVER47 será em unicast.

Realmente as tecnologias Overlay são bastante interessantes e resolvem muitos problemas que arquiteturas grandes e que precisam de mobilidade e escalabilidade demandam. No próximo artigo iremos falar de como o EVPN consegue melhorar ainda mais isso e nos da a chance de otimizar e diminuir o trafego BUM necessario para que o VXLAN Flood&Learn funcione.

Até a próxima!