War Stories #01: O Mistério do Host “Congelado” (Hyper-V vs. Cisco ACI)

No dia a dia de um Data Center, existem problemas que não aparecem nos dashboards de “Health” do APIC. Um dos casos mais intrigantes que resolvi recentemente envolveu um cluster Hyper-V, o protocolo COOP e um Bridge Domain inteiro sendo inundado por tráfego desnecessário.

Neste artigo, vamos dissecar como a configuração de rede de um Hypervisor pode “enganar” o Fabric ACI e ativar mecanismos de proteção que, ironicamente, acabam gerando lentidão generalizada.

O Sintoma: O “Silêncio” dos Inocentes

O chamado chegou como muitos outros: “A rede está lenta e alguns servidores perderam conectividade aleatoriamente”.

Ao analisar o Fabric, o cenário era confuso:

1. O status do APIC estava verde (Healthy).
2. Não havia alarmes de Loop (STP) ou quedas de interface.
3. Porém, via Wireshark, notamos um volume absurdo de Unknown Unicast Flooding. O ACI estava replicando pacotes para todas as portas do Bridge Domain (BD) na tentativa de encontrar destinos que deveriam ser conhecidos.

A Investigação: Entra em cena o Endpoint Dampening

Para entender o que aconteceu, precisamos falar sobre o COOP (Council of Oracle Protocol). Ele é o “oráculo” do ACI que reside nos Spines e mapeia onde cada MAC e IP está localizado.

Quando um host se move muito rápido entre portas (MAC Flapping), o ACI ativa o Endpoint Dampening. É um mecanismo de defesa: para não estressar o Control Plane com atualizações infinitas, o Fabric “congela” aquele registro.

No meu caso, ao rodar comandos de CLI nos Leafs, identifiquei que vários MACs vindos do cluster Hyper-V estavam no estado Frozen.

Por que o Hyper-V causou isso?

O culpado era o Dynamic Teaming do Hyper-V. Nesse modo, o Hypervisor tenta balancear a carga movendo os fluxos de rede entre as placas físicas de forma agressiva. Para o ACI, parecia que as máquinas virtuais estavam “saltando” de uma porta para outra em milissegundos.

O COOP interpretou isso como uma instabilidade ou ataque e aplicou o “gelo” (Dampening) nos Endpoints. Com o registro congelado no Spine, o tráfego destinado a essas VMs deixava de ser roteado de forma eficiente e passava a ser inundado (Flooding) no BD.

A Solução: Estabilidade sobre Dinamismo

Para resolver, a estratégia foi alinhar a arquitetura de rede do host com a inteligência do Fabric:

1. Ajuste no Hyper-V: Alteramos o modo de Teaming de Dynamic para Switch Independent (com configuração de porta estática no lado do ACI, se necessário) ou garantimos que o LACP estivesse devidamente configurado e estável.
2. Limpeza do COOP: Foi necessário limpar os registros “congelados” para que o Spine voltasse a aprender as adjacências corretamente.
3. Resultado: O tráfego Unknown Unicast desapareceu instantaneamente e a latência normalizou.

Lições Aprendidas

• O ACI é sensível à movimentação: O que o Windows enxerga como “otimização de fluxo”, o ACI pode enxergar como instabilidade de rede.
• Confie nos Logs, não apenas nos Dashboards: O estado “Frozen” de um Endpoint é um evento de log crucial que muitas vezes passa batido no dashboard principal do APIC.
• Padronização é tudo: A integração VMM (Virtual Machine Manager) ajuda a evitar esses problemas, pois o APIC passa a “conversar” com o Hypervisor e entender essas movimentações.

---

Gostou deste War Story? Se você quer ver como identificar esses MACs congelados via CLI e como configurar o Fabric para evitar esse comportamento, confira o vídeo completo lá no meu canal Cisco DC ACI.