Obs .: O GARP em ess\u00eancia \u00e9 um ARP Request “falso”, usado para se apresentar \u00e0 rede em vez de atingir um n\u00f3 espec\u00edfico. Segue a RFC5227<\/a>, curiosamente, tive que ler a RFC porque me perguntaram se o GARP era um Request ou Reply e eu n\u00e3o tinha certeza da resposta. Na RFC tem um contexto hist\u00f3rico sobre essa decis\u00e3o pelo IETF.<\/p>\n\n\n\n
Segue o seguinte cen\u00e1rio: Seguindo o conceito de Active\/Stand-By somente o n\u00f3 ativo do VM Cluster ABC vai enviar e receber tr\u00e1fego para essa aplica\u00e7\u00e3o, ent\u00e3o todo tr\u00e1fego destinado ao VIP(192.168.0.150) vai conter o MAC do VM Cluster ABC. Agora que sabemos como o processo de GARP funciona, vamos para a parte interessante, que \u00e9 entender o por que essa configura\u00e7\u00e3o existe, e como funciona.<\/p>\n\n\n\n Esse problema acontecia somente em switches Nexus 9k Gen-1, nessa \u00e9poca 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 .: \u00c9 necess\u00e1rio que Unicast Routing e ARP Flooding estejam configurados para que essa funcionalidade tenha efeito. Estava programando para que meu primeiro post t\u00e9cnico fosse referente aos protocolos utilizados no Underlay de uma malha VXLAN, mas durante essa semana fui engajado para auxiliar num problema relacionado \u00e0 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 … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[],"class_list":["post-56","post","type-post","status-publish","format-standard","hentry","category-aci"],"_links":{"self":[{"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=\/wp\/v2\/posts\/56","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=56"}],"version-history":[{"count":20,"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=\/wp\/v2\/posts\/56\/revisions"}],"predecessor-version":[{"id":155,"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=\/wp\/v2\/posts\/56\/revisions\/155"}],"wp:attachment":[{"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=56"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=56"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pingsemresposta.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=56"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Temos uma aplica\u00e7\u00e3o rodando nos VM Clusters ABC e XYZ, essa aplica\u00e7\u00e3o faz o uso do conceito de Active\/Stand-By para alta-disponibilidade.
VM Cluster ABC MAC: ABC
VM Cluster ABC IP Prim\u00e1rio: 192.168.0.100
VM Cluster XYZ MAC: XYZ
VM Cluster XYZ IP Prim\u00e1rio: 192.168.0.200
VIP dos Clusters ABC e XYZ: 192.168.0.150
Active: VM Cluster ABC
Stand-By: VM Cluster XYZ<\/p>\n\n\n\n![\"\"](\"https:\/\/pingsemresposta.com.br\/wp-content\/uploads\/2026\/07\/image-1.png\")
<\/figure>\n\n\n\n
Assim que ocorre uma falha no n\u00f3 ativo (no VM Cluster ABC), ou quando a fun\u00e7\u00e3o de ativo \u00e9 movida para o VM Cluster XYZ, a VM que assumir a aplica\u00e7\u00e3o precisa notificar a rede sobre a nova localiza\u00e7\u00e3o do VIP. Para isso, esse novo n\u00f3 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\u00e7\u00e3o de redund\u00e2ncia que utiliza MAC-Virtual, o GARP vai servir apenas para atualizar a localiza\u00e7\u00e3o do MAC na tabela CAM, e se utilizar o MAC-Fisico, o GARP vai servir para atualizar a localiza\u00e7\u00e3o do MAC na tabela CAM e atualizar a tabela ARP com o novo mapeamento de IP-x-MAC<\/p>\n\n\n\n![\"\"](\"https:\/\/pingsemresposta.com.br\/wp-content\/uploads\/2026\/07\/image-3-1024x605.png\")
<\/figure>\n\n\n\nGARP-Based EP Move Detection<\/h4>\n\n\n\n
A funcionalidade de GARP-Based EP Move Detection foi desenvolvida para resolver um problema antigo(CSCus77627), em que o ACI n\u00e3o conseguia atualizar sua tabela EPM, caso houvesse uma altera\u00e7\u00e3o do mapeamento MAC-IP recebido na mesma porta e EPG do mapeamento antigo.
Obs: Lembrando que o ACI s\u00f3 faz o registro de IP-MAC quando temos a fun\u00e7\u00e3o de Unicast Routing habilitada no BD, sem unicast routing no BD, o ACI s\u00f3 faz aprendizados de MAC.
<\/p>\n\n\n\n![\"\"](\"https:\/\/pingsemresposta.com.br\/wp-content\/uploads\/2026\/07\/image-4-1024x357.png\")
<\/figure>\n\n\n\n
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\u00e3o 5.0(1), a fabric n\u00e3o consegue mais fazer upgrade de software para esses switches.
A op\u00e7\u00e3o para configura\u00e7\u00e3o dessa feature fica dentro das configura\u00e7\u00f5es de L3 do BD.
Tenant -> Networking -> BD -> Subnet<\/em><\/strong>
<\/p>\n\n\n\n![\"\"](\"https:\/\/pingsemresposta.com.br\/wp-content\/uploads\/2026\/07\/image-6-1024x539.png\")
<\/figure>\n\n\n\n
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\u00e7\u00e3o do GARP-Based EP Move Detection possui o prop\u00f3sito 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\u00e3o aprenda incorretamente a localiza\u00e7\u00e3o dos VIPs, j\u00e1 que em ambos os cen\u00e1rios teriamos diferentes MACs origem para o mesmo IP Origem enviando traf\u00e9go para a malha em locais diferentes, e isso iria for\u00e7ar o ACI a aprender o endpoint original na porta do firewall ao inv\u00e9s da localiza\u00e7\u00e3o correta.
Obs: No futuro farei um post sobre DSR e Service-Graph PBR com uma explica\u00e7\u00e3o mais detalhada e com diagramas sobre o porqu\u00ea IP Data-Plane Learning deve ficar desabilitado para essas arquiteturas.
<\/p>\n","protected":false},"excerpt":{"rendered":"