War Stories #02 | O Caso das iLOs “Mudas”: Por que o Hardware Proxy derrubou o acesso?

Na engenharia de redes, o problema mais difícil de resolver não é aquele que “está tudo parado”, mas aquele que “funciona às vezes”.

Recentemente, peguei um chamado onde a rede de gerenciamento (OOB/iLO) de vários servidores estava inacessível externamente. O cenário era o seguinte:

• Topologia: ACI operando apenas como L2 (Layer 2).
• Gateway: O Default Gateway da rede ficava num Firewall externo.
• Sintoma Bizarro: Se alguém acessasse o servidor fisicamente (console/KVM) e disparasse um ping para fora, a iLO magicamente voltava a ficar acessível na rede.

Se você já viu isso, sabe que estamos lidando com um caso de “Silent Host” (Host Silencioso). Mas por que o ACI estava bloqueando isso? A resposta estava na configuração do Bridge Domain.

A Investigação: O Silêncio é o Inimigo

No Cisco ACI, o aprendizado de Endpoints (MAC e IP) acontece baseada em pacotes de dados. Se o servidor fala, o switch aprende onde ele está. Se o servidor fica quieto, o switch não sabe de nada.

As interfaces de gerenciamento (iLO, iDRAC, IPMI) são famosas por serem “mudas”. Elas não ficam enviando tráfego ou ARP gratuitous constantemente. Elas ficam lá, passivas, esperando uma conexão.

Ao analisar a configuração do Bridge Domain (BD) dessa rede, encontrei o culpado:

• L2 Unknown Unicast: Configurado como Hardware Proxy.

O Mecanismo do Erro (Hardware Proxy)

No modo Hardware Proxy, quando o Leaf recebe um pacote destinado a um MAC que ele não conhece (o PC do administrador tentando acessar a iLO), ele envia esse pacote para o Spine (Proxy). O Spine consulta o banco de dados central (COOP).

1. O Spine pergunta: “Alguém sabe onde está a iLO X?”
2. O COOP responde: “Nunca ouvi falar (porque ela é muda e nunca enviou nada)”.
3. Resultado: O Spine dropa o pacote silenciosamente.

Por isso, quando o técnico pingava de dentro para fora, a iLO gerava tráfego, o ACI aprendia o MAC, atualizava o COOP, e o tráfego de retorno passava a funcionar.

A Solução: Voltando às Origens (Flood)

A correção foi cirúrgica. Alteramos a configuração do L2 Unknown Unicast do BD de Hardware Proxy para Flood.

Por que funcionou?

Ao mudar para Flood, mudamos o comportamento do switch para atuar como uma rede Ethernet clássica:

1. O pacote chega procurando a iLO.
2. O Leaf não sabe onde ela está.
3. Em vez de perguntar ao Spine e dropar, o Fabric faz um BUM Traffic (Broadcast, Unknown Unicast, Multicast). Ele inunda esse pacote para todas as portas desse BD.
4. O pacote chega na iLO.
5. A iLO responde (Unicast).
6. Bingo: Nesse momento, o ACI aprende o MAC da iLO e cadastra no COOP. O “Flood” cessa e a comunicação vira Unicast direto.

Lição Aprendida

O modo Hardware Proxy é excelente para performance e para evitar ruído na rede, mas ele assume que todos os hosts são “falantes” ou que o ACI é o Gateway (fazendo ARP Gleaning).

Para redes legadas, dispositivos industriais ou redes de gerenciamento passivo (como iLOs) onde o Gateway é externo, o modo Flood ainda é o rei.

Não assuma que “moderno” é sempre melhor. Às vezes, o bom e velho Flood é o que salva o dia.

---

Dica de Troubleshooting

Se você suspeita desse problema, use o comando no Leaf para ver se o Endpoint existe: show system internal epm endpoint mac <MAC_DA_ILO>

Se não retornar nada e o Gateway for externo, verifique o modo do seu BD.