Esse é o primeiro post de uma série que vou fazer sobre a rede Underlay de malhas VXLAN. A ideia é ter uma postagem dedicada para cada protocolo que pode ser utilizado nessa estrutura.
Antes de publicar com detalhes sobre os protocolos que são utilizados no Underlay da malha, acho importante entendermos o que é essa rede.
ATENÇÃO: Se você já sabe o que é o Underlay da malha VXLAN, talvez esse post não seja pra você. Não entrarei em detalhes dos protocolos, darei apenas um resumo do que roda por debaixo dos panos.
A rede Underlay é a rede de transporte utilizada pela malha VXLAN para fazer o encaminhamento do tráfego da camada Overlay. Essa rede tem como objetivo garantir a comunicação entre os VTEPs(Virtual Tunnel Endpoint) da malha, já que esses VTEPs são responsáveis por fazer o encapsulamento e decapsulamento de todo o tráfego da rede Overlay.
Obs: Por padrão, os VTEPs ficam localizados nos Leafs, pontos de entrada e saída de tráfego da malha VXLAN. Eu digo por padrão porque existem implementações ou plataformas diferentes que possuem um design diferente disso, por exemplo ACI possui VTEPs no Spines.
O tráfego da rede Overlay seria toda a comunicação que precisa ser encaminhada através da malha VXLAN, ou seja, qualquer tráfego que precise ser transportado pela malha, e que terá o cabeçalho VXLAN adicionado no momento de entrada na malha e será encaminhado para algum destino dentro da mesma com base no cabeçalho de IP externo.
Dentro do domínio de rede Underlay, fazemos o uso de alguns protocolos para garantir a comunicação entre os VTEPs, garantindo que a malha VXLAN possa encaminhar tráfego Unicast, Multicast ou Broadcast.
Tráfego Unicast no Underlay
É importante deixar claro o que significa tráfego unicast no Underlay. Quando me refiro a esse tipo de comunicação não estou falando do tipo que o endpoint manda para a malha, e sim que ação de encaminhamento o Underlay vai tomar com base no tráfego recebido de seus endpoints.
Exemplo: Host-A quer se comunicar com Host-B, esse tráfego é unicast para a malha a partir do momento que o VTEP de entrada sabe a localização desses hosts, ou seja, quando o VTEP-A sabe que para chegar no Host-B ele deve encaminhar o tráfego para o VTEP-B onde o Host-B se encontra.
Temos algumas opções de protocolos que podemos utilizar na rede underlay para esse propósito:
- OSPF
- IS-IS
- BGP
Obs: Esses são os protocolos utilizados e recomendados pela indústria, mas em teoria podemos usar RIP ou EIGRP também, no final das contas, basta garantir que os Leafs vão conseguir estabelecer comunicação entre os VTEPs para que o tráfego (da malha VXLAN) possa ser transportado. Lembrando que esses dois protocolos possuem limitações que fizeram a indústria desconsiderá-los para esse tipo de implementação.
Esses protocolos são utilizados para que o Underlay consiga aprender os endereços dos VTEPs que serão utilizados para o encaminhamento de pacotes pertencentes à malha e, com base nas métricas de roteamento, tomar a decisão de encaminhamento de tráfego. Como estamos utilizando o exemplo de design Spine-Leaf geralmente utilizado em ambientes de Data-Center, é esperado que todos os destinos da malha tenham a mesma métrica, dessa forma, ela faz o uso do design/função ECMP(Equal-Cost Multipath), utiliza todos os links disponíveis para enviar o tráfego para o destino, balanceando e utilizando todos os links da malha.
Obs.: O ECMP é habilitado por padrão em alguns protocolos.
Como podemos ver na imagem, se o Servidor-A e o Servidor-D quiserem se comunicar, o design da rede aplicaria ECMP e poderíamos usar todos os links disponíveis para chegar ao destino(Servidor-D). Dessa maneira, a malha faz uma distribuição de tráfego pelos links de forma orgânica entre todos os links da rede, garantindo redundância, alta-disponibilidade e balanceamento de uso dos links, já que temos múltiplos caminhos válidos para o destino.
Obs.: O ECMP faz o balanceamento com base em flow para evitar que pacotes cheguem fora de ordem em seu destino.
Trafégo Multidestino no Underlay
O tráfego multidestino seria, qualquer tráfego BUM(Broadcast, Unknown Unicast e Multicast). Para o tráfego multidestino, temos apenas duas opções para garantir o encaminhamento desse tipo de tráfego.
Seguiremos o mesmo pensamento explicado acima para o Unicast, estou me referindo à decisão qual a malha toma para o encaminhamento do tráfego, nesse caso quando é decidido que a comunicação deve ter caracteristicas de inundamento.
Para o Underlay performar o inundamento desse pacote/frame, temos 2 protocolos disponiveis para a entrega desse tipo de tráfego:
- PIM
- Ao usar PIM, fazemos a implementação de uma árvore multicast no Underlay que fará o encaminhamento de tráfego multidestino através da replicação de pacotes.
Podemos usar os seguintes designs de PIM:
- PIM-ASM
- PIM-BiDir
- O mapeamento da árvore multicast nesse caso é feito com base na associação de grupos multicast em seus respectivas VNIs(Virtual Network Identifier), campo encontrado no cabeçalho VXLAN.
Dessa forma o Underlay sabe quais VTEPs tem interesse em receber comunicação multidestino para suas respectivas VNIs.
- Ao usar PIM, fazemos a implementação de uma árvore multicast no Underlay que fará o encaminhamento de tráfego multidestino através da replicação de pacotes.
- Ingress-Replication
- Ao usar Ingress-Replication o encaminhamento de tráfego multidestino é feito através de vários pacotes unicast, então ao invés dele ser replicado na rede de acordo com as portas participantes da árvore multicast, ele faz o envio de 1 cópia do pacote para cada VTEP interessado no recebimento de tráfego multidestino. Os VTEPs mantêm um mapeamento de quais VTEPs tem interesse em receber pacotes multidestino para determinado domínio.
É feito o envio desse tráfego com endereçamento unicast para todos os VTEPs interessados. Dessa forma, o tráfego multidestino é tratado como unicast na rede underlay. Essa diferença é imperceptível para os endpoints conectados.
Para fazer o mapeamento dos VTEPs interessados no método Ingress-Replication, temos duas opções:
- Estático
- BGP-EVPN
- Ao usar Ingress-Replication o encaminhamento de tráfego multidestino é feito através de vários pacotes unicast, então ao invés dele ser replicado na rede de acordo com as portas participantes da árvore multicast, ele faz o envio de 1 cópia do pacote para cada VTEP interessado no recebimento de tráfego multidestino. Os VTEPs mantêm um mapeamento de quais VTEPs tem interesse em receber pacotes multidestino para determinado domínio.
Essas duas opções para encaminhamento de tráfego Multidestino são necessárias para que a nossa malha VXLAN tenha a capacidade de fazer a entrega de frames ou pacotes com caracteristicas de inundamento para a comunicação, dessa maneira garantindo que os endpoints conectados possam fazer o encaminhamento de BUM(Broadcast, Unknown Unicast e Multicast).
O que vem depois?
Agora sim, os próximos posts sobre o Underlay serão específicos sobre os protocolos listados até agora.
NOTA: O objetivo do post é falar sobre implementação padrão de VXLAN, não estou entrando em especificidades de malhas operadas por SDN, já que elas têm nuances específicas de plataforma.