War Story 08: Troubleshooting de Multi-Pod Bring-up (Back-to-Back) – Da Análise de Logs à Consistência da MIT

Contexto de Atuação: Fui acionado neste projeto para atuar de forma independente no papel de auditoria técnica e malha de segurança. Minha missão primária era acompanhar a janela de mudança executada por uma equipe terceira de integração, garantindo que a ativação do novo Pod não causasse qualquer impacto no Pod 1, que já operava em produção crítica. No entanto, quando a implementação falhou e o troubleshooting pela interface gráfica se esgotou, precisei intervir com uma análise de baixo nível no sistema operacional do controlador para diagnosticar a causa raiz e destravar o projeto.

Cenário: Ativação de um novo Pod (Pod 2) em uma arquitetura Cisco ACI Multi-Pod utilizando topologia Back-to-Back (Spine-to-Spine, sem switches IPN intermediários).

Problema Reportado: Durante o processo de bring-up, os Spines do Pod 2 ([SERIAL-SPINE-01] e [SERIAL-SPINE-02]), devidamente registrados no Fabric Membership com os Node IDs XX1 e XX2, permaneciam travados no status discovering com IP 0.0.0.0. O tráfego de Control Plane não evoluía para a formação da adjacência OSPF/BGP.

Fase 1: Validação do Trânsito (DHCP Relay) no Underlay

A primeira hipótese em falhas de Multi-Pod geralmente recai sobre o Data Plane da rede inter-pod (ISN). Para isolar problemas físicos e de roteamento da VRF overlay-1, a investigação foi direcionada imediatamente para os logs do daemon de DHCP no APIC do Pod 1.

Comando executado no APIC:

Bash

cat /var/log/dme/log/dhcpd.bin.log | grep DHCPDISCOVER

Evidência (Log):

Plaintext

5385||2026-06-11T11:55:25.426087299||dhcp||INFO||||ISC dhcpd: DHCPDISCOVER from [MAC-OMITIDO] via 10.X.X.9||../svc/dhcpd/src/gen/ifc/beh/imp/./DhcpdSvc.cc||70

Análise: O pacote DHCP Discover originado no Pod 2 estava cruzando com sucesso os links Back-to-Back. O DHCP Relay configurado na sub-interface do Spine 1 estava operacional, encapsulando e entregando a requisição ao APIC. Isso descartou qualquer falha física ou de L3Out de trânsito no Pod 1.

Fase 2: O Bloqueio na Alocação de IP (Falha na Política de Extensão)

Se o pacote chegava, o APIC estava ativamente descartando a requisição. A análise do log revelou o motivo exato da recusa.

Evidência (Log):

Plaintext

5392||...||dhcp||DBG4||...||Ignoring dhcpClient as Node Id is not assigned..[SERIAL-SPINE-01]
5385||...||dhcp||ERR||...||network ifabric: no free leases

Análise: O erro no free leases indicava que o daemon de DHCP (ifabric) não possuía um Pool de IPs válido vinculado ao Pod 2 para distribuir via Relay.

Para validar como o TEP Pool do Pod 2 havia sido instanciado, a base de dados de objetos (MIT) foi consultada via CLI.

Comandos executados:

Bash

apic1# moquery -c fabricSetupP | egrep "podId|tepPool"
# Retornou o TEP Pool 10.X.0.0/16 associado ao Pod 2 como um Pod local padrão.

apic1# moquery -c fabricExtSetupP
No Mos found

Causa Raiz 1: A configuração inicial do Multi-Pod havia sido interrompida (o summary do wizard de configuração ficou em branco e não compilou). Como resultado, o bloco IP foi injetado na base genérica (fabricSetupP), mas a política de extensão L3 (fabricExtSetupP) nunca foi criada. Sem essa classe, o APIC não autoriza o repasse de IPs para sub-redes remotas via Relay.

Resolução: O Pod Fabric Setup Policy foi recriado corretamente via GUI, vinculando o TEP Pool de extensão ao Pod 2. O Node XX1 assumiu o IP e subiu para o status Active.

Fase 3: O Paradoxo do Node Zumbi (Loop de DHCP no Spine 2)

Após a correção da base, os Leafs e o Spine 1 subiram, mas o Spine 2 (Node XX2) entrou em um loop infinito de DHCP, recebendo a oferta (DHCPOFFER), mas falhando na consolidação do lease.

Evidência (Log):

Plaintext

5392||2026-06-11T11:55:36.430636755||ifc_dhcpd||DBG4||...||Ignoring the dhcpLease.dhcpClient id=[SERIAL-SPINE-02]-eth1/30 doen't exist.

Uma consulta profunda ao objeto do Node XX2 revelou uma inconsistência estrutural na base de dados:

Bash

apic1# cat /var/log/dme/log/dhcpd.bin.log | grep node-XX2
<fvNodeDef ... id="XX2" ... podId="0" rn="node-XX2" ...>
<fabricCreatedBy ... creatorDn="uni/tn-infra/out-b2b_l3out/lnodep-b2b_LNodeP/rsnodeL3OutAtt-[topology/pod-2/node-XX2]" .../>

Causa Raiz 2: O objeto apresentava podId="0" (status de placeholder corrompido). Isso ocorreu porque o Node XX2 foi associado manualmente ao Logical Node Profile do L3Out no Tenant infra antes de o equipamento ter concluído o Discovery inicial limpo. Essa dependência circular impediu o banco de dados de instanciar a interface eth1/30 como um cliente DHCP válido, gerando o descarte recursivo do lease.

Resolução: 1. Remoção do Node XX2 do perfil L3Out no Tenant infra. 2. Decommission do nó corrompido no Fabric Membership. 3. O equipamento enviou um novo Discover, recebeu o IP normalmente e atingiu o estado Active. 4. Reassociação do nó à política de roteamento.

Fase 4: Anomalia Isolada em um dos Leafs

Com a infraestrutura de Spines e a maioria dos Leafs online, restou um único Leaf ([SERIAL-LEAF-XX]), que não prosseguia com o registro.

Evidência (Log XML processado pelo APIC):

XML

<dhcpClient ... configIssues="model-empty" ... id="[SERIAL-LEAF-XX]" ip="0.0.0.0" ... nodeRole="unsupported" ... status="deleted" supported="no"/>

Causa Raiz 3: A recusa por model-empty e supported="no" indica uma incompatibilidade severa de firmware. O hardware estava realizando boot no modo NX-OS Standalone (imagem de fábrica) ou possuía uma versão não reconhecida pelo catálogo atual do APIC, impedindo o processamento do header ACI.

Resolução: Acionamento da equipe de Smart Hands local para acesso via cabo console, formatação do bootflash e carregamento da imagem ACI correta via prompt de loader>.

Conclusão e Lições Aprendidas

Este caso reforça o quão determinística é a arquitetura SDN da Cisco. Falhas em processos automatizados de interface gráfica (como a interrupção de um wizard) podem deixar resíduos inconsistentes na Management Information Tree (MIT) que os painéis web nem sempre refletem com clareza.

A resolução eficiente exigiu descer à camada do sistema operacional (Linux/NX-OS), validar contadores do DHCP Relay e auditar a coerência das classes na base de dados (moquery). Respeitar a ordem de provisionamento — garantir que o Control Plane básico e o Discovery ocorram antes de forçar o amarre lógico em políticas de L3Out — é mandatório para evitar loops de dependência na arquitetura.