Duas VMs no mesmo fabric VXLAN de hardware não conseguem se comunicar, ou o tráfego entre elas cai de forma intermitente, e o caminho passa por um Spine que não dá para simplesmente observar. Este é o método tradicional em duas etapas para encontrar o dispositivo que realmente está descartando pacotes — confirmar primeiro a linha de base Underlay/Overlay, depois configurar estatísticas de fluxo para localizar a perda.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O método tradicional para localizar a perda de pacotes em um fabric Spine-Leaf VXLAN de hardware não é uma lista de quarenta itens para verificar de uma vez — são duas etapas, e a segunda só começa depois que a primeira volta limpa.
Quando duas VMs no mesmo fabric não conseguem se comunicar, ou o tráfego entre elas cai de forma intermitente, o instinto é começar a puxar de uma vez a configuração de cada dispositivo no caminho. O método tradicional em duas etapas usado em fabrics Spine-Leaf VXLAN distribuídos por hardware faz o oposto: primeiro confirmar que a linha de base Underlay e Overlay está realmente saudável de ponta a ponta, e só então — se essa linha de base realmente se confirmar — ativar as estatísticas de fluxo para encontrar o único dispositivo no caminho que está de fato descartando pacotes.
A seguir estão as duas etapas com os comandos display exatos, a configuração de estatísticas de fluxo de cinco tuplas que localiza com precisão o salto que está descartando pacotes, e as armadilhas que pegam as pessoas mesmo quando o método é seguido corretamente.
As estatísticas de fluxo da etapa 2 são casadas de forma diferente em cada salto deste caminho — vale a pena ter esse esquema à vista antes de configurar qualquer coisa.
Este é o padrão de acesso mais comum em um fabric VXLAN distribuído por hardware: Server Leaf de origem, atravessando o fabric por um Spine, passando por um Service/Border Leaf se o destino estiver atrás de um, voltando por um Spine, e chegando ao Server Leaf de destino. A etapa 2 só faz sentido depois que o sintoma pode ser posicionado nesse caminho.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Se a etapa 1 revelar uma quebra — rota ausente, túnel Down, ARP ou rota de host ausente — corrija isso diretamente; é um simples erro de configuração de roteamento, VXLAN ou EVPN, não um mistério de perda de pacotes, e nossa nota de solução de problemas do túnel VXLAN cobre essas causas em profundidade. As estatísticas de fluxo da etapa 2 só valem a pena configurar depois que a linha de base realmente parecer limpa de ponta a ponta.
Cinco verificações na etapa 1, depois uma configuração de estatísticas de fluxo de cinco tuplas na etapa 2 — nessa ordem, não ao contrário.
Usando como exemplo a VM1 (10.120.120.5, gateway vBDIF111 no Server Leaf de origem) que não consegue alcançar a VM2 (10.141.141.3, gateway vBDIF222 no Server Leaf de destino) — cinco verificações, cada uma no Server Leaf de origem e no de destino.
<SourceLeaf> display ip routing-table 3.3.3.100
Routing Table : Public
Destination/Mask Proto Pre Cost NextHop Interface
3.3.3.100/32 OSPF 10 2 10.0.12.2 GE1/0/1
// route to the peer NVE (Dest. Server Leaf) source address exists -> Underlay is reachable this direction
<SourceLeaf> display vxlan tunnel
Tunnel ID Source Destination State Type Uptime
4026531844 4.4.4.100 3.3.3.100 up dynamic 9:14:02
// State up, Type dynamic -> tunnel itself is fine, not the problem here
<SourceLeaf> display arp interface vbdif 111
IP ADDRESS MAC ADDRESS EXP(M) TYPE VLAN/CEVLAN INTERFACE
10.141.141.3 0019-9400-000b 18 dynamic BD1012254 Eth-Trunk1.4
// destination VM's ARP is learned
<SourceLeaf> display ip routing-table vpn-instance ABC 10.141.141.3
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.141.141.3/32 IBGP 255 0 RD 3.3.3.100 VXLAN
// EVPN host route to VM2 is present -> repeat steps 4-5 on Dest. Server Leaf for VM1's ARP/host routeSó se chega aqui depois que a etapa 1 estiver totalmente limpa nas duas pontas. As estatísticas de tráfego funcionam sobre a cinco-tupla, mas só suportam a direção de entrada — e o formato do pacote é diferente em cada salto.
// example flow: source 192.168.20.2, destination 192.168.10.2, VNI 5001
// match rule differs by hop on the reference path:
// Source Server Leaf : if-match acl xxx (original packet, pre-VXLAN)
// Spine (transit) : if-match vxlan transit tag-format none
// Service/Border Leaf : if-match vxlan tag-format none
// Dest. Server Leaf : if-match vxlan tag-format none
[SourceLeaf] acl number 3001
[SourceLeaf-acl-adv-3001] rule 5 permit ip source 192.168.20.2 0 destination 192.168.10.2 0
[SourceLeaf] traffic classifier c_flow
[SourceLeaf-classifier-c_flow] if-match acl 3001
[SourceLeaf] traffic behavior b_count
[SourceLeaf-behavior-b_count] statistic enable
[SourceLeaf] traffic policy p_count
[SourceLeaf-trafficpolicy-p_count] classifier c_flow behavior b_count
[SourceLeaf] interface vbdif 111
[SourceLeaf-Vbdif111] traffic-policy p_count inbound
// repeat the equivalent classifier + policy, matched to that hop's packet format, on Spine / Service Leaf / Dest. Server Leaf
<SourceLeaf> display traffic-policy statistic interface Vbdif111 inbound verbose
// compare this counter against the same query on the next hop down the path ->
// the first hop where the count doesn't carry through is the dropping deviceDepois que as duas etapas acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado — incluindo algumas formas de se enganar mesmo seguindo o método corretamente.
SINTOMAdisplay ip routing-table em direção ao endereço do NVE remoto volta vazio em um Server Leaf, mas parece normal no outro — a etapa 1 pareceu passar só porque apenas um sentido foi verificado.
CAUSAA convergência IGP/BGP em direção a endereços loopback nem sempre é simétrica — uma mudança de custo IGP, uma política de rotas ou um filtro em apenas um dispositivo pode deixar o caminho de volta sem rota até o VTEP remoto enquanto o caminho de ida parece completamente normal.
SOLUÇÃOExecute a verificação da tabela de roteamento tanto no Server Leaf de origem quanto no de destino, cada um em direção ao endereço source NVE do outro, antes de concluir que a etapa 1 passou.
SINTOMAdisplay vxlan tunnel mostra o State como down para o túnel do caminho de referência, mesmo que outros túneis no mesmo dispositivo estejam up.
CAUSAUm túnel VXLAN só sobe quando existe uma rota até o VTEP remoto; se esse estado Down passar despercebido em uma olhada rápida na etapa 1, tudo o que vem depois — ARP, rotas de host, estatísticas de fluxo — acaba sendo verificado em um caminho que de qualquer forma nunca iria carregar tráfego.
SOLUÇÃOTrate um túnel Down como uma falha em si, não como um sintoma de perda de pacotes — primeiro percorra nossa nota de solução de problemas do túnel VXLAN, e volte a este método depois que o túnel for confirmado como up.
SINTOMAO passo 4 (ARP) passa nos dois Server Leafs, mas o passo 5 (a rota de host EVPN) está ausente em um dos lados.
CAUSAO Server Leaf remoto de fato converteu a entrada ARP em uma rota EVPN e a anunciou — mas uma incompatibilidade de VPN-Target, um filtro de política de rotas, ou uma colisão de Router-ID no refletor de rotas impediu que o outro lado a aceitasse em sua tabela de roteamento.
SOLUÇÃOIsso é um erro de configuração de roteamento/EVPN, não uma falha de hardware do fabric — a análise aprofundada sobre incompatibilidades de VPN-Target e filtragem pelo refletor de rotas está em nossa nota de solução de problemas do túnel VXLAN; corrija isso antes de avançar para a etapa 2.
SINTOMAAs estatísticas de fluxo mostram contadores limpos em cada salto, mas o ping entre as VMs continua perdendo pacotes.
CAUSAAs estatísticas de tráfego só suportam a direção de entrada, e o formato do pacote muda em cada salto: o primeiro dispositivo NVE vê o pacote original, antes do VXLAN, e precisa de um classificador baseado em ACL, enquanto cada dispositivo a jusante vê um pacote encapsulado VXLAN e precisa de um classificador vxlan tag-format. Reutilize a regra if-match errada no salto errado e o contador daquele dispositivo simplesmente nunca aumenta — sem dizer nada sobre onde a perda realmente está.
SOLUÇÃOFaça o classificador corresponder ao salto: if-match acl no Server Leaf de origem, if-match vxlan transit tag-format none nos Spines de trânsito, if-match vxlan tag-format none nos Leafs que terminam o túnel.
SINTOMAO sintoma parece intermitente — alguns pings passam, outros não — e executar o mesmo teste novamente não o reproduz de forma consistente.
CAUSAO ECMP entre vários Spines faz hash sobre a cinco-tupla; um ping simples sempre reutiliza a mesma tupla e sempre cairá no mesmo caminho, o que pode esconder uma falha em um Spine que um fluxo diferente teria atingido, ou fazer um Spine genuinamente com defeito parecer intermitente se alguns fluxos o evitarem completamente.
SOLUÇÃOVarie deliberadamente a cinco-tupla ao testar — portas de origem diferentes, não apenas pings repetidos — ou confie nos contadores de estatísticas de fluxo da etapa 2 em vez de depender apenas do ping para decidir se um determinado segmento de caminho está realmente limpo.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Porque a convergência Underlay e EVPN não é garantida como simétrica. Uma rota, uma entrada ARP ou uma rota de host pode estar presente em uma direção e ausente na outra, e verificar apenas o Leaf de origem conta a metade errada da história exatamente quando mais importa.
Você pode, mas isso desperdiça uma rodada de configuração. Cada uma das cinco verificações da etapa 1 é mais rápida de executar do que configurar classificadores, comportamentos e políticas em cada salto, e um problema simples de roteamento, estado do túnel, ARP ou rota de host aparece imediatamente na etapa 1 sem precisar de estatísticas.
Este método lê contadores e tabelas que você configura manualmente, salto por salto — funciona em qualquer fabric VXLAN distribuído por hardware e não precisa de nada além de acesso via CLI. Uma plataforma de análise baseada em controlador automatiza a mesma ideia — registros de perda de pacotes, rastreamento de fluxo, verificações de caminho com percepção de topologia — e leva você à resposta mais rápido se estiver implantada, mas a lógica subjacente é idêntica: confirmar a linha de base, depois localizar a perda.
Sim, importa, e é por isso que o classificador em cada salto precisa corresponder ao que aquele dispositivo específico realmente recebe — o pacote original no primeiro salto NVE, um pacote encapsulado VXLAN em todos os seguintes. Configurar o contador do lado errado de um salto, ou casar o formato de pacote errado, é a forma mais comum de este método retornar uma leitura falsamente “limpa”.
Nesse ponto, o fabric em si foi efetivamente descartado. Verifique se houve uma mudança de configuração manual em algum dispositivo do caminho por volta do momento em que a falha começou, e se os contadores realmente permanecerem limpos em todo o caminho de referência, trate isso como um problema do nó de computação ou da aplicação, e coordene com a equipe de TI/servidores em vez de continuar procurando dentro da rede.
Esta nota é construída em torno do método tradicional em duas etapas, guiado por CLI, para fabrics Spine-Leaf VXLAN distribuídos por hardware — primeiro a linha de base Underlay/Overlay, depois as estatísticas de fluxo de cinco tuplas. Ela pressupõe uma falha já posicionada no caminho VM a VM mostrado acima; um túnel Down, ou uma rota EVPN que nunca atravessou, são falhas por si só e são cobertas em profundidade em nossa nota de solução de problemas do túnel VXLAN, não repetidas aqui. Também não cobre plataformas de análise baseadas em controlador que automatizam a mesma lógica de localização — onde uma estiver implantada, ela normalmente levará à resposta mais rápido do que o método manual aqui descrito. Para a mesma árvore de decisão de três fontes (óptica, camada física/CRC, descartes) aplicada a um único link em vez de um caminho de fabric com múltiplos saltos, veja nossa nota de perda de pacotes em campus.
Diga-nos em qual etapa você está travado — a linha de base Underlay/Overlay ou as estatísticas de fluxo — junto com a saída do display, e ajudaremos você a interpretá-la.