Estava programando para que meu primeiro post técnico fosse referente aos protocolos utilizados no Underlay de uma malha VXLAN, mas durante essa semana fui engajado para auxiliar num problema relacionado à alta disponibilidade de um sistema e tive que explicar sobre GARP-Based EP Move Detection.
Antes de explicar sobre a feature de GARP-Based EP Move Detection dentro do ACI acho importante falar sobre o que é o GARP e por que ele existe.
O que é GARP(Gratuitous ARP)
O GARP costuma ser utilizado em redes de alta-disponibilidade(HA) que fazem uso de um VIP(Virtual IP) para garantir a disponibilidade do sistema com base no conceito de Active/Stand-By. Então temos um IP primário para os nós que fazem parte desse sistema e um IP compartilhado entre os nós para que o tráfego possa ser direcionado para quem estiver atuando como nó ativo nesse sistema.
Em caso de falha do nó ativo, parte do processo de failover do sistema é mover o tráfego para o nó Stand-By que, por sua vez, se tornará o nó ativo do sistema.
Quando esse procedimento de failover do sistema é executado, o novo nó que se tornou o ativo precisa notificar a rede de que ele é o novo responsável pelo tráfego direcionado ao sistema. Então esse novo nó ativo envia um GARP, que, no caso, é basicamente igual a uma requisição ARP, mas que não foi solicitada pela rede; por isso, ele é gratuito, ninguém pediu… A partir do inundamento(flood) desse GARP, todos os nós dentro do seu domínio de broadcast vão receber essa informação e atualizar suas tabelas ARP com o novo mapeamento de IP-para-MAC.
Obs .: O GARP em essência é um ARP Request “falso”, usado para se apresentar à rede em vez de atingir um nó específico. Segue a RFC5227, curiosamente, tive que ler a RFC porque me perguntaram se o GARP era um Request ou Reply e eu não tinha certeza da resposta. Na RFC tem um contexto histórico sobre essa decisão pelo IETF.
Segue o seguinte cenário:
Temos uma aplicação rodando nos VM Clusters ABC e XYZ, essa aplicação faz o uso do conceito de Active/Stand-By para alta-disponibilidade.
VM Cluster ABC MAC: ABC
VM Cluster ABC IP Primário: 192.168.0.100
VM Cluster XYZ MAC: XYZ
VM Cluster XYZ IP Primário: 192.168.0.200
VIP dos Clusters ABC e XYZ: 192.168.0.150
Active: VM Cluster ABC
Stand-By: VM Cluster XYZ
Seguindo o conceito de Active/Stand-By somente o nó ativo do VM Cluster ABC vai enviar e receber tráfego para essa aplicação, então todo tráfego destinado ao VIP(192.168.0.150) vai conter o MAC do VM Cluster ABC.
Assim que ocorre uma falha no nó ativo (no VM Cluster ABC), ou quando a função de ativo é movida para o VM Cluster XYZ, a VM que assumir a aplicação precisa notificar a rede sobre a nova localização do VIP. Para isso, esse novo nó envia um GARP, garantindo que os equipamentos da rede tenham suas tabelas ARP e CAM (ou o EPM, no caso do ACI) atualizadas imediatamente.
Obs: Se for um protocolo/aplicação de redundância que utiliza MAC-Virtual, o GARP vai servir apenas para atualizar a localização do MAC na tabela CAM, e se utilizar o MAC-Fisico, o GARP vai servir para atualizar a localização do MAC na tabela CAM e atualizar a tabela ARP com o novo mapeamento de IP-x-MAC
Agora que sabemos como o processo de GARP funciona, vamos para a parte interessante, que é entender o por que essa configuração existe, e como funciona.
GARP-Based EP Move Detection
A funcionalidade de GARP-Based EP Move Detection foi desenvolvida para resolver um problema antigo(CSCus77627), em que o ACI não conseguia atualizar sua tabela EPM, caso houvesse uma alteração do mapeamento MAC-IP recebido na mesma porta e EPG do mapeamento antigo.
Obs: Lembrando que o ACI só faz o registro de IP-MAC quando temos a função de Unicast Routing habilitada no BD, sem unicast routing no BD, o ACI só faz aprendizados de MAC.
Esse problema acontecia somente em switches Nexus 9k Gen-1, nessa época os switches Nexus ainda utilizavam os chipsets Broadcom, a partir dos Nexus 9K Gen-2 a Cisco passou a utilizar seu chipset proprietario Cisco Cloud Scale e esse problema foi resolvido dos modelos Gen-2 e adiante.
Obs: Nexus 9K Gen-1 possui as nomenclaturas “PQ”, “PX” e “TX”. Esses atingiram status EoS(End-Of-Support) em Outubro de 2023 e a partir do ACI versão 5.0(1), a fabric não consegue mais fazer upgrade de software para esses switches.
A opção para configuração dessa feature fica dentro das configurações de L3 do BD.
Tenant -> Networking -> BD -> Subnet
Obs .: É necessário que Unicast Routing e ARP Flooding estejam configurados para que essa funcionalidade tenha efeito.
Apesar dessa feature ter nascido por causa desse problema dos switches Gen-1, ao longo do tempo ela foi integrada a outras funcionalidades que vieram depois dela. Atualmente essa funcionalidade serve apenas para designs como:
– DSR(Direct Server Return)
– Service-Graph PBR
Utilizando esses designs, a ativação do GARP-Based EP Move Detection possui o propósito de permitir que a malha VXLAN do ACI possa processar mensagens GARP encaminhadas para o ACI, mesmo com o recurso de IP Data-Plane Learning desabilitado.
Obs: IP Data-Plane Learning deve estar desabilitado nesses designs para que, o ACI não aprenda incorretamente a localização dos VIPs, já que em ambos os cenários teriamos diferentes MACs origem para o mesmo IP Origem enviando trafégo para a malha em locais diferentes, e isso iria forçar o ACI a aprender o endpoint original na porta do firewall ao invés da localização correta.
Obs: No futuro farei um post sobre DSR e Service-Graph PBR com uma explicação mais detalhada e com diagramas sobre o porquê IP Data-Plane Learning deve ficar desabilitado para essas arquiteturas.