War Stories #07: O Mistério do Contrato Liberado: Quando a TCAM diz “Sim” e o Packet-Log diz “Não” (O Efeito QUIC no Cisco ACI)

Imagine a cena: uma tarde tranquila na operação de infraestrutura de rede. Você acabou de implementar ou validar uma regra de acesso no Cisco ACI para um sistema crítico. O cliente reporta que a aplicação web (HTTPS) não está funcionando.

Com a confiança de quem conhece a fábrica, você acessa o switch Leaf via CLI, roda os comandos para validar as tabelas de hardware (TCAM) e lá está ela: a regra está ativa, em modo permit e com o status enabled. Se o contrato está configurado corretamente e a TCAM diz que o tráfego está liberado, por que os pacotes continuam sendo descartados?

Neste post, vamos analisar um caso real de troubleshooting de microsegmentação, desvendar a anatomia oculta de um log de drop no Cisco ACI e entender como um detalhe sutil nos protocolos modernos pode enganar até os analistas mais experientes.

O Cenário e a Primeira Investigação

Para fins didáticos, vamos mascarar os dados reais da nossa infraestrutura, utilizando nomes e IPs fictícios. O nosso switch Leaf de teste será o DC_Core_Leaf01.

O sintoma clássico: o servidor de origem (192.168.10.25) tenta acessar uma aplicação web segura hospedada no servidor de destino (172.16.50.100), mas a conexão falha por timeout.

O analista executa o comando para verificar se o ID do grupo de endpoint de destino (Dst-EPG) possui alguma regra ativa na TCAM que dê match com o tráfego:

DC_Core_Leaf01# show zoning-rule dst-epg 12345 src-epg 0 | grep 101
| 101 | 0 | 12345 | 101 | uni-dir | enabled | 2048500 | TN-GLOBAL_CORP:EPG-APP-SERVERS | permit | any_dest_filter(14) |

Depois, verifica as regras reversas e o filtro associado a esse ID 101:

DC_Core_Leaf01# show zoning-filter | grep https
| 101 | 101_0 | ip | unspecified | tcp | no | no | unspecified | unspecified | https | https | dport | unspecified | unspecified |
| 102 | 102_1 | ip | unspecified | tcp | no | no | https | https | unspecified | unspecified | sport | unspecified | unspecified |

O diagnóstico inicial pareceria óbvio: * Existe um contrato entre as EPGs (TN-GLOBAL_CORP:EPG-APP-SERVERS).

• O status é enabled e a ação é permit.
• O filtro está olhando para o protocolo TCP e para a porta HTTPS (443).

Tudo perfeito, certo? Errado. A aplicação continua fora do ar.

O Flagrante: Olhando o Log de Drop

Quando o hardware descarta pacotes, o Cisco ACI nos dá uma ferramenta fantástica de inspeção de kernel/hardware: o packet-log internal. Ao filtrar pelo IP de destino que estava falhando, o analista se depara com as seguintes linhas:

[2026-06-09T14:04:04.314076000-03:00]: CName: TN-GLOBAL_CORP:VRF-CORE(VXLAN: 2048500), VlanType: FD_VLAN, VlanId: 140, SMac: 0x0050568c200f, DMac:0x0050568c35e7, SIP: 192.168.10.25, DIP: 172.16.50.100, SPort: 55773, DPort: 443, Src Intf: port-channel10, Proto: 17, PktLen: 1262

Se o contrato permitia HTTPS (porta 443), por que o switch gerou um log de packet-log deny?

Anatomia de um Log de Drop no Cisco ACI

Antes de revelarmos o culpado, vamos fatiar esse log para que você saiba exatamente o que o switch está te dizendo em cada campo em cenários futuros de troubleshooting:

• [2026-06-09T14:04:04...-03:00]: Registro de data, hora e fuso horário do momento exato em que o pacote bateu no circuito do switch e foi descartado. Essencial para correlacionar com os logs da aplicação.
• CName (Context Name): Mostra o Tenant e a VRF onde o tráfego trafega (TN-GLOBAL_CORP:VRF-CORE), além do número de identificação da VXLAN correspondente no fabric.
• VlanType: FD_VLAN, VlanId: 140: Forwarding VLAN. É a tag de VLAN interna que o switch Leaf usa para processar o pacote dentro do seu próprio circuito de hardware (ASIC).
• SMac e DMac: Endereços MAC de Origem (Source) e Destino (Destination) em formato hexadecimal de hardware.
• SIP (Source IP): O IP de quem enviou o pacote (192.168.10.25).
• DIP (Destination IP): O IP do servidor de destino (172.16.50.100).
• SPort (Source Port): A porta alta aleatória aberta pelo cliente para originar a sessão (55773).
• DPort (Destination Port): A porta de destino do serviço (443 – HTTPS).
• Src Intf (Source Interface): A porta física ou lógica por onde o pacote físico entrou no Leaf (port-channel10).
• PktLen (Packet Length): O tamanho total do pacote em Bytes (1262).
• Proto (Protocol Number): O X da questão. Este campo indica qual protocolo da camada de transporte está encapsulado no cabeçalho IP. No log, o valor retornado foi 17.

O Culpado: Decodificando os Códigos de Protocolo IP

O cabeçalho do protocolo IP possui um campo de 8 bits chamado Protocol Number (padronizado pela IANA). O switch lê esse número puro, direto do hardware. Quando configuramos os filtros na interface gráfica do APIC, selecionamos nomes amigáveis como “tcp” ou “udp”, mas o ACI traduz isso para números na TCAM.

Aqui está uma tabela rápida dos principais códigos que você precisa fixar na memória:

Código Decimal	Protocolo	Função Principal
1	ICMP	Mensagens de teste de conectividade (Ping/Traceroute)
2	IGMP	Gerenciamento de grupos Multicast
6	TCP	Conexões confiáveis orientadas a fluxo (HTTP, SSH, BGP)
17	UDP	Transmissões rápidas sem conexão (DNS, DHCP, VXLAN, QUIC)
47	GRE	Encapsulamento de túneis genéricos
50	ESP	Criptografia de pacotes em VPNs IPsec

O “Pulo do Gato” do nosso caso

Ao olharmos a nossa regra de TCAM (show zoning-filter), descobrimos que o nosso contrato só tinha filtros criados para o protocolo TCP (Código 6).

No entanto, o log de drop exibiu de forma categórica: Proto: 17, o que significa que o pacote interceptado estava utilizando UDP.

Por que uma aplicação HTTPS tentaria usar UDP/443 em vez de TCP/443?

A resposta está na evolução da própria Web: o protocolo QUIC (base do HTTP/3). Navegadores modernos (como Chrome, Edge e Firefox) e servidores web atualizados tentam fechar sessões HTTPS inicialmente via UDP utilizando o QUIC para acelerar o carregamento da página e reduzir o handshake de criptografia.

Como a regra do ACI permitia apenas o tráfego TCP tradicional, o switch agiu corretamente conforme as diretrizes de Zero Trust: como o pacote UDP/443 não deu match exato em nenhum contrato permitido, ele caiu na regra implícita de descarte (Implicit Deny).

Como Resolver o Problema

Para sanar este comportamento e permitir que a aplicação funcione em sua máxima performance (com suporte a HTTP/3), a solução consiste em atualizar o filtro do contrato no APIC.

Além da linha existente que libera o protocolo TCP na porta 443, devemos adicionar uma nova entrada sob o mesmo assunto (subject) liberando:

• EtherType: IP
• IP Protocol: udp (Código 17)
• Dest Port: 443 (https)

Assim que a alteração é empurrada para os Leafs, o tráfego QUIC passa a ser permitido e, caso a aplicação precise fazer um fallback por qualquer motivo, o tráfego TCP tradicional também estará garantido.

Conclusão

No mundo do SDN e de firewalls de matriz de comutação como o Cisco ACI, o diabo mora nos detalhes. Confiar cegamente que “HTTPS é apenas TCP/443” pode gerar horas de dor de cabeça desnecessária.

Sempre que se deparar com drops inexplicáveis, recorra aos logs internos de hardware, preste atenção minuciosa no campo Proto e use a tabela de Protocol Numbers a seu favor.