War Story #03 | O Túnel SD-WAN Fantasma e a Ilusão da Interface Gráfica

Toca o alerta para entrar numa sala de guerra. O cenário relatado: o Hub SD-WAN (Viptela) precisava alcançar o Firewall de Internet. O Cisco ACI estava no meio do caminho.

O sintoma clássico? “O tráfego sai do roteador, mas não chega um pacote sequer no Firewall. O ACI deve estar dropando.”

Fui fazer o feijão com arroz do troubleshooting. E é aqui que a interface gráfica quase me pregou uma peça.

A “Verdade” da Observabilidade

No ACI, a ferramenta de Visibility & Troubleshooting é fantástica. Configurei a validação de External IP to External IP, coloquei os Distinguished Names (DNs) dos L3Outs de origem e destino e mandei rodar.

O resultado parecia perfeito:

• O mapa mostrava o caminho completo.
• A tabela de roteamento indicava o next-hop correto.
• Havia um contrato com a regra de permit liberando a comunicação.
• Zero drops reportados.

Porém, o Firewall continuava sem receber nada.

A Pulga Atrás da Orelha

O primeiro detalhe que chamou a minha atenção foi o contador de pacotes: os hits não estavam incrementando no contrato específico daquele tráfego, mas sim num contrato genérico de permit any.

Para tirar a prova, fiz um ERSPAN da comunicação. Abri o Wireshark e lá estavam os pacotes (origem e destino do DTLS batendo certinho para chegar na controller).

Disparei então um ELAM Express para ver se o hardware (ASIC) estava encaminhando ou dropando. Resultado? Origem ok, destino ok, pacote interceptado, contrato aplicado e nenhum drop.

Eu tinha a tela de Observabilidade me mostrando o caminho, o Wireshark confirmando a chegada do pacote e o ELAM Express confirmando o contrato. Mas a conta não fechava. O tráfego passava pelo ACI, mas definitivamente não estava indo para onde deveria.

O Detalhe Escondido no ELAM (Detail/Raw)

Decidi ignorar a interface simplificada e abri o ELAM no modo detalhado para ver a decisão de encaminhamento real do hardware. Foi aí que a farsa caiu.

O ELAM me mostrou que o pacote estava entrando por um Leaf do SD-WAN, mas o Destination VTEP (o destino interno do túnel VXLAN no ACI) era o Leaf do outro roteador SD-WAN, e não o Leaf de borda do Firewall.

Aprofundando no Bridge Domain reportado no log, descobri que a origem e o destino da comunicação eram os próprios roteadores Viptela. Eles estavam fazendo um “U-Turn” dentro do ACI e enviando o tráfego de volta para a infraestrutura SD-WAN (em direção ao link MPLS).

A Causa Raiz: Configuração do Viptela

O problema não era roteamento ou contrato no ACI. O problema estava na configuração do Viptela.

O time de SD-WAN havia colocado a interface conectada ao ACI e o link MPLS na mesma Color (tag de transporte). E o pior: a opção de tunnel interface estava ativa na porta virada para o ACI.

O roteador Viptela ignorava a rota para o Firewall. Ele estava forçando o fechamento de um túnel IPsec/DTLS com o roteador vizinho através da nossa rede, usando o ACI como um mero switch de trânsito. O ACI via pacotes válidos, roteava internamente e aplicava contratos genéricos, mas o IP de destino final do encapsulamento era a rede MPLS, não o Firewall.

A solução? Removemos a opção de túnel da interface do Viptela virada para o ACI. O tráfego começou a fluir para o Firewall instantaneamente.

A Lição: O Bit não mente, a GUI sim

A ferramenta de Observabilidade mostra como o ACI está configurado para encaminhar o pacote baseado na RIB/FIB lógica. Ela pressupõe que o dispositivo vizinho está enviando o tráfego limpo.

O ELAM mostra o que o ASIC está fazendo com o elétron naquele milissegundo.

Nem sempre podemos confiar cegamente nas ferramentas visuais. Quando o diagnóstico se estender e a lógica parecer falhar, desça o nível. Confie no bit passando pelo hardware.