VXLAN – Underlay – OSPF

Nesse post vamos analisar como funciona a implementação do Underlay da malha VXLAN utilizando o protocolo OSPF. A indústria recomenda o uso do OSPF, então antes de iniciar o post, vamos falar rapidinho um pouco sobre esse protocolo.

Por que usar OSPF no Underlay

A indústria recomenda o uso do OSPF por alguns motivos, entre eles o seguinte:

  • Permite uso de ECMP(Equal Cost Multi-Path).
  • Convergência Rápida
  • Interoperabilidade comprovada entre diferentes plataformas, permitindo o uso de diferentes vendors na mesma malha.

OSPF no Underlay da Malha VXLAN

Ao fazer o uso do OSPF na camada Underlay, é ideal levar algumas considerações de design para otimizar seu desempenho, garantindo que o tempo de convergência seja reduzido:

  • Somente Area 0
    • O ideal é utilizarmos o OSPF somente em área zero, simplificando a topologia e a LSDB, já que com uma área só, trabalhamos somente com LSA-1 e LSA-2 na DB.
  • OSPF Network Type Point-to-Point
    • Com isso, removemos os cargos de DR e BDR, logo, não se faz mais o processo de eleição ao formar uma adjacência e também eliminamos o uso de LSA-2, simplificando a LSDB.
  • BFD habilitado nos links entre Leaf e Spine
    • É mais indicado fazer o uso de BFD do que alterar os timers de OSPF para um tempo mais agressivo, já que o BFD usa menos recursos e também consegue garantir a detecção de falhas em milissegundos.
    • Se usado juntamente com IP Unnumbered, é necessário que seja utilizado sem o modo BFD Echo habilitado.
  • IP Unnumbered nos links
    • Obrigatoriamente precisamos configurar o OSPF link como point-to-point para usar essa função.
    • LSDB ainda menor, já que não usaríamos nenhuma rede de trânsito para fechar as adjacências entre leafs e spines.
    • Configuração simplificada, já que não é necessária a configuração e alocação de prefixos para as adjacências.
    • É mais fácil de automatizar o processo de deploy de uma malha ou escalar alguma malha já existente, já que a definição de rede das comunicações entre Leaf e Spine não necessita de alocação de rede.
    • Entendo que não existe uma recomendação formal sobre usar IP Unnumbered ou não, realmente, vai de avaliar se é o melhor caso para o seu ambiente.

Lembrando que o Underlay da nossa malha VXLAN tem o propósito de garantir conectividade entre os VTEPs, então é uma camada de rede reduzida em prefixos se comparada com redes de produção, tendo somente os prefixos dos links entre Leafs e Spines e os endereços dos VTEPs(/32).

Configuração do Underlay OSPF

Obs: As configurações aqui do post são baseadas na sintaxe do NX-OS.

Certo, para a configuração do nosso Underlay vou separar em blocos para trazer mais clareza sobre o que cada bloco representa para a nossa configuração:

Comando Função
feature ospf
router ospf {nome do processo ospf}
router-id {router-id}
Habilita e configura o OSPF no equipamento
interface loopback{id}
ip address {ip}/32
ip router ospf {nome do processo ospf} area 0
Configura a interface que será utilizada pelo VTEP local e faz a associação ao processo OSPF.
interface {intf-id}
no switchport
ip address {ip}/31
ip unnumbered {loopback}
medium p2p

mtu 9216
ip ospf network point-to-point
ip router ospf {nome do processo ospf} area 0
Configura a interface P2P que será o trânsito entre os VTEPs da malha, a conexão entre Leafs e Spines.

Obs: OSPF point-2-point para garantir uma convergência otimizada, removendo LSA-2 e eleição de DR/BDR.

A linha de comando “medium p2p” só é necessária se configurarmos a interface como IP Unnumbered
Obs: Comandos em amarelo são opcionais

Validação do Underlay OSPF

Assim como explicado no começo do post, o protocolo do Underlay para tráfego unicast tem a sua principal função, que é garantir a comunicação entre os VTEPs da malha, e como vimos nas configurações acima, a interface que será utilizada pelos VTEPs é a loopback. O tipo de validação que temos a fazer é se os endereços das loopbacks estão sendo divulgados corretamente, garantindo assim a comunicação entre os VTEPs, já que o ponto de encapsulamento e decapsulamento VXLAN da malha fica nesses VTEPs.

Então podemos simplesmente verificar se estamos recebendo os prefixos correspondentes das Loopbacks da malha.

Obs: Lembrando que nesse cenário estamos com uma topologia Spine-Leaf.



Nas abas abaixo temos a configuração do OSPF e as rotas do Underlay sendo aprendidas através do OSPF.


Em todas as validações conseguimos ver os endereços das loopbacks(futuros VTEPs) sendo aprendidos. É interessante notar que ao usar IP Unnunmbered, vemos as rotas com a interface de saída do equipamento e não um next-hop IP. Isso acontece pela maneira que o IP Unnumbered funciona, já que não temos uma rede nesse link P2P, ele faz o apontamento da interface que o tráfego deverá ser encaminhado.

Referências

Artigo do Daniel Dib sobre BFD x Timers Agressivos
Unicast Routing Config Guide – NX-OS – OSPFv2
RFC1812 – IPv4 – 2.2.7 – IP Unnumbered
RFC2328 – OSPFv2 – 10.5 – Hello Packet Exchange
RFC2328 – OSPFv2 – 12.4.1.1 – Point-to-Point Interfaces
Building Data Centers with VXLAN – Vinit Jain(Cisco Press)



Deixe um comentário