Início / Notas técnicas / Solução de problemas do overlay VXLAN

Falhas do overlay VXLAN: migração de VM, estado do túnel e rastreamento de tráfego

Um túnel VXLAN mostrando Up não significa que o tráfego que importa para você realmente o está atravessando. Esta é a ordem de diagnóstico que separa as quatro coisas que realmente dão errado em um fabric VXLAN baseado em EVPN — o estado do túnel, uma migração de VM que perde pacotes por 20 segundos, contagens de tráfego em nível de pacote nos dois lados do túnel, e se o tráfego de um usuário específico sequer chegou ao overlay.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que o overlay esconde a falha

O túnel é uma abstração. Cada uma dessas falhas acaba residindo no underlay, no plano de controle, ou em um único endereço MAC mal interpretado por baixo.

O trabalho inteiro do VXLAN é fazer uma rede underlay desaparecer e deixar em seu lugar um overlay de aparência plana. É exatamente por isso que as falhas aqui são confusas: display vxlan tunnel pode mostrar Up enquanto o tráfego de negócio real está indo para outro lugar completamente, ou o túnel pode estar perfeitamente saudável enquanto uma tempestade de rotas EVPN totalmente alheia trava uma migração de VM por vinte segundos. A forma mais rápida de resolver qualquer um desses casos é a mesma disciplina de sempre — confirmar o estado real do túnel, e então relacionar o sintoma ao caso específico que ele mais se parece, em vez de adivinhar primeiro a configuração do BGP EVPN.

A seguir: uma topologia VXLAN Spine-Leaf para localizar a falha, a ordem para verificar o estado do túnel antes de mexer em qualquer outra coisa, um caso real de perda de pacotes em migração de VM rastreado até uma tempestade de rotas EVPN no Route Reflector, estatísticas de tráfego em nível de pacote tanto no lado de acesso quanto dentro do túnel, como confirmar que o tráfego de um usuário realmente chegou ao overlay, cinco causas-raiz recorrentes, e respostas de perguntas frequentes testadas em campo.

Leia o fabric antes de ler um único contador

Border Leaf, Spine atuando como route reflector, pares de Server Leaf com hosts em dual-homing via M-LAG — os túneis VXLAN correm de leaf a leaf sobre um plano de controle BGP EVPN que nunca aparece na topologia física.

Cada caso abaixo assume esta forma: VTEPs nos pares de Server Leaf construindo túneis VXLAN dinâmicos via BGP EVPN, com o Spine atuando puramente como route reflector — ele reflete rotas EVPN, não origina um VTEP por conta própria.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

É o plano de controle EVPN que torna este fabric diferente de solucionar em comparação a uma rede comutada comum: uma rota que nunca é refletida, ou um mapeamento de VNI para bridge domain errado em um leaf, produz exatamente o mesmo buraco negro que um cabo rompido — sem nenhum sintoma físico.

Percorrendo o estado do túnel e depois o caso específico

Quatro investigações diferentes, quatro conjuntos de comandos diferentes — e a disciplina de verificar primeiro o estado do túnel antes de presumir qual delas se aplica.

Confirmar o estado do túnel antes de presumir uma falha de VXLAN

display vxlan troubleshooting executa o diagnóstico automático próprio da Huawei e informa o motivo em texto simples — leia isso antes de abrir um caso sobre qualquer outra coisa.

Verifique primeiro display vxlan tunnel. Se State for Down, esse é o seu ponto de partida, não a tabela de rotas EVPN.
Execute display vxlan troubleshooting para obter diretamente um Event Description — por exemplo, túnel down porque a rota até o endereço de origem ou destino está inalcançável, ou porque não existe uma rota de host de 32 bits.
Confirme com display bgp evpn peer que o vizinho EVPN que construiu este túnel está realmente Established, não apenas que o objeto de túnel existe.
Confirme com display ip routing-table que a tabela de rotas IP do underlay realmente tem uma rota até o endereço loopback de origem ou destino do peer.

<HUAWEI> display vxlan tunnel
Number of vxlan tunnel : 1
Tunnel ID    Source                Destination           State
40000001     10.1.1.1              10.1.1.2              down
// state is down -- this is where to start, not the EVPN route table

<HUAWEI> display vxlan troubleshooting
Vxlan Tunnel Troubleshooting Information:
 Tunnel ID       : 40000001
 Event Description : The tunnel is Down because the route to the destination
                      is unreachable, or no 32-bit host route exists for it.

<HUAWEI> display bgp evpn peer
 Peer            V    AS  MsgRcvd  MsgSent  OutQ  Up/Down   State  PrefRcv
 10.1.1.2        4  65001      120      118     0  00:12:40  Established     6

<HUAWEI> display ip routing-table
Destination/Mask    Proto  Pre  Cost      Flags NextHop     Interface
10.1.1.2/32          O_ASE 150  1         D     10.0.0.2    GE1/0/1
// a /32 route to the destination loopback must exist, not just a summary route

Caso: migração de VM perdendo pacotes por mais de 20 segundos

Aqui o problema não é o túnel — é a fila de envio de saída do route reflector.

Sintoma: a migração de VM neste fabric perde pacotes por mais de 20 segundos, bem além do previsto no projeto.
Causa raiz: atualizações frequentes de rotas EVPN (normalmente impulsionadas por MAC/ARP) congestionam a fila de envio do route reflector mais rápido do que ele consegue escoar as rotas para cada peer, então a nova localização da VM não é anunciada a tempo.
Verifique display bgp evpn update-peer-group para encontrar o Group ID que trata os peers afetados.
Na visão diagnose, verifique display bgp evpn update-peer-group index <id> verbose — uma contagem UptPeerGrp PktBuffer diferente de zero significa que o route reflector ainda não terminou de enviar atualizações para esse grupo.
Correção: aumente o tempo de envelhecimento de MAC dinâmico no Server Leaf e no Border Leaf do padrão de 300 segundos para algo como 1800 segundos, reduzindo a taxa de churn de rotas impulsionado por MAC; depois confirme que a contagem UptPeerGrp PktBuffer volta a 0.

<HUAWEI> display bgp evpn update-peer-group
 Group ID   PeerNumber  Description
 3          24          EVPN-RR-Group

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display bgp evpn update-peer-group index 3 verbose
 UptPeerGrp PktBuffer   : 214
// non-zero -- the RR has not finished flushing updates to this peer group

[HUAWEI] mac-address aging-time 1800
// default is 300s; raising it reduces MAC-driven EVPN route churn

[HUAWEI-diagnose] display bgp evpn update-peer-group index 3 verbose
 UptPeerGrp PktBuffer   : 0
// confirms the send queue has cleared after the change

Estatísticas de tráfego em nível de pacote — lado de acesso e dentro do túnel

A interface do lado de acesso vê o pacote original; a interface do lado do túnel o vê envolto em um cabeçalho VXLAN — por isso os dois lados precisam de métodos de correspondência diferentes.

No lado de acesso, crie uma ACL simples que corresponda ao IP de origem/destino do tráfego que deseja contabilizar, e vincule-a a uma política de tráfego na interface de acesso.
No lado do túnel, o pacote agora carrega um cabeçalho VXLAN, então o classificador de tráfego precisa referenciar explicitamente o pacote interno com if-match vxlan transit acl.
Aplique a política do lado do túnel à interface de túnel VXLAN (ou à interface voltada para NVE) na direção de saída ou entrada conforme necessário, e depois leia os contadores com display traffic-policy statistics.

[HUAWEI] acl 3000
[HUAWEI-acl-adv-3000] rule 5 permit ip source 10.10.1.0 0.0.0.255 destination 10.10.2.0 0.0.0.255

[HUAWEI] traffic classifier c_access
[HUAWEI-classifier-c_access] if-match acl 3000
[HUAWEI] traffic behavior b_access
[HUAWEI-behavior-b_access] statistic enable
[HUAWEI] traffic policy p_access
[HUAWEI-trafficpolicy-p_access] classifier c_access behavior b_access
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] traffic-policy p_access inbound

// tunnel side -- match the inner packet through the VXLAN header
[HUAWEI] traffic classifier c_tunnel
[HUAWEI-classifier-c_tunnel] if-match vxlan transit acl 3000
[HUAWEI] traffic policy p_tunnel
[HUAWEI-trafficpolicy-p_tunnel] classifier c_tunnel behavior b_access

<HUAWEI> display traffic-policy statistics interface GigabitEthernet1/0/1 inbound
 Classifier: c_access
   Matched     : 128664 packets / 96 Mbytes

Como confirmar que o tráfego de um usuário realmente chegou à rede VXLAN

Um VNI mapeia 1:1 para um bridge domain; uma vez que se sabe como o VTEP decide a qual bridge domain um quadro pertence, julgar se um usuário está dentro ou fora se torna uma verificação de três etapas.

Verifique se o endereço MAC do usuário foi aprendido no bridge domain esperado com display mac-address bridge-domain. Se estiver, o quadro está no overlay; se não, passe para a próxima etapa.
Verifique a interface de acesso e sua configuração de subinterface para determinar se o usuário deve chegar via acesso baseado em VLAN ou via uma subinterface com terminação 802.1Q.
Verifique as VLANs ou subinterfaces vinculadas ao bridge domain com display bridge-domain <id> — se a VLAN ou subinterface do usuário não estiver nessa lista, o tráfego não consegue chegar ao overlay, por mais correto que tudo o resto pareça.

<HUAWEI> display mac-address bridge-domain 10
MAC Address    VLAN/VSI/BD  Learned-From        Type
5489-98aa-1122 -/-/10       Eth-Trunk1.10        dynamic
// user's MAC is learned into BD 10 -- the frame is in the overlay

<HUAWEI> display this
interface Eth-Trunk1.10
 encapsulation dot1q vid 10
 bridge-domain 10
// confirms this is sub-interface access with 802.1Q termination into BD 10

<HUAWEI> display bridge-domain 10
 Bridge-domain 10 information:
  Binding interface : Eth-Trunk1.10, Eth-Trunk2.10
// if the user's own VLAN/sub-interface is not bound here, it never reaches the overlay

5 causas-raiz que aparecem repetidamente

Depois que as verificações acima indicarem qual das quatro investigações se aplica, essas cinco respondem pela maior parte do que realmente está errado.

1. O churn de rotas EVPN inunda a fila de envio do route reflector

SINTOMAA migração de VM causa perda de pacotes por mais de 20 segundos — bem além do previsto no projeto.

CAUSAAtualizações frequentes de rotas EVPN superam a capacidade do route reflector de escoar sua fila de envio para todos os peers; a nova localização da VM não é anunciada a tempo, então o tráfego continua indo para o leaf antigo durante esse intervalo.

CORREÇÃOAumente o tempo de envelhecimento de MAC dinâmico no Server Leaf e no Border Leaf a partir do padrão de 300 segundos para reduzir a taxa de churn, e depois confirme que a contagem UptPeerGrp PktBuffer voltou a 0.

[HUAWEI] mac-address aging-time 1800

2. Alarme de flapping de MAC por colisão entre a MAC da VM e o gateway

SINTOMAO equipamento relata um alarme de flapping de MAC e o tráfego da VM fica intermitente.

CAUSAO endereço MAC de uma VM colide com a própria MAC do gateway L3 do VXLAN — por exemplo, em uma interface VBDIF — de modo que cada quadro visto pela rede parece vir de dois lugares ao mesmo tempo.

CORREÇÃOVerifique display mac-address flapping-record para a MAC em flapping, cruze-a com display interface vbdif <id>, e então mude a MAC da VM ou do gateway, ou remova de vez uma interface VBDIF não usada.

<HUAWEI> display mac-address flapping-record
 MAC Address      VLAN/BD   Times    Last-Time
 5489-98aa-3344   10        16        2026-07-18 09:14:02

<HUAWEI> display interface vbdif 10
Vbdif10 current state : UP
 Hardware address is 5489-98aa-3344
// same MAC as the flapping VM -- collision with the gateway's own address

3. Túnel caído porque a rota até a origem ou o destino está inalcançável

SINTOMAdisplay vxlan tunnel mostra o State do túnel como down; as VMs por trás dele não conseguem se alcançar entre data centers.

CAUSANão existe rota — nem rota de host de 32 bits — até o endereço loopback de origem ou destino do túnel; display vxlan troubleshooting indica isso diretamente em seu Event Description.

CORREÇÃOConfirme que o vizinho EVPN está Established, depois verifique a tabela de rotas IP do underlay em busca de uma rota até o endereço ausente; corrija o protocolo de roteamento subjacente, não a configuração do VXLAN em si.

4. A tabela de replicação head-end nunca é construída

SINTOMAdisplay vxlan peer mostra zero peers para um VNI que deveria ter replicação head-end configurada; as VMs entre data centers não conseguem se alcançar.

CAUSAGeralmente uma configuração incorreta da interface NVE — um endereço de origem errado, ou um protocolo de peer-list head-end errado — ou um vizinho EVPN que nunca subiu.

CORREÇÃOVerifique a configuração da interface NVE em relação ao projeto de referência, e depois confirme o estado do vizinho EVPN com display bgp evpn peer.

<HUAWEI> display vxlan peer vni 10010
Total 0 peer.
// expected head-end replication peers, but none learned

<HUAWEI> display this
interface Nve1
 source 10.1.1.1
 vni 10010 head-end peer-list protocol bgp
// confirm source address and protocol match the reference config on every leaf

5. Rota EVPN nunca aprendida porque um VPN-Target não coincide, ou o ARP remoto nunca foi convertido

SINTOMAdisplay ip routing-table vpn-instance não mostra absolutamente nada para uma VM de destino que deveria ser alcançável — não há rota, não é uma rota errada.

CAUSATrês suspeitos habituais: o leaf remoto nunca aprendeu a entrada ARP da VM de destino; uma route-policy em um dos leafs está filtrando a rota EVPN; ou os atributos de comunidade estendida VPN-target dos dois leafs não coincidem, de modo que a rota é gerada localmente mas descartada ao ser recebida.

CORREÇÃOConfirme primeiro que a tabela ARP do leaf remoto tem o destino com display arp network <ip>; verifique se a rota local foi gerada com o route-target correto via display bgp instance evpn all routing-table mac-route; se nada estiver filtrado e os route-targets coincidirem, procure uma route-policy aplicada ao peer BGP.

<HUAWEI> display arp network 10.10.2.20
// empty -- the local leaf never learned this VM's ARP entry, so no route was ever generated

<HUAWEI> display bgp instance vpn1 evpn all routing-table mac-route
 Route Distinguisher: 10.1.1.1:1
 VPN-Target       : 65001:10010 export, 65001:10010 import
// compare export community on the originating leaf against import on the receiving leaf

Cinco perguntas para as quais vale a pena ter uma resposta pronta

Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

Rodar VXLAN precisa de uma License separada?

O VXLAN é controlado por uma License (CE-LIC-VXLAN), mas nos switches CloudEngine ela vem pré-instalada e pré-ativada de fábrica — não há nada para ativar manualmente.

O encapsulamento VXLAN empurrou o comprimento do meu pacote além do que os switches do underlay permitem — e agora?

O VXLAN adiciona 54 bytes de overhead a cada pacote original, e isso é suficiente para superar o MTU de um switch underlay comum e ser descartado silenciosamente. Escolha a combinação que o hardware do underlay suporta: aumente o comprimento do quadro Jumbo que o underlay permite passar além do comprimento do pacote VXLAN, aumente em vez disso o MTU da interface do underlay além dele, ou coloque o próprio gateway VXLAN em hardware capaz de fragmentar e remontar, para que o underlay nunca precise lidar com um quadro de tamanho excessivo.

O VXLAN suporta IPv6?

Sim, nos dois lados — a rede overlay transportada dentro do túnel e a rede underlay sobre a qual o próprio túnel roda podem, cada uma, ser IPv6 de forma independente.

Ativei as estatísticas de tráfego do túnel VXLAN e o equipamento começou a relatar um alarme de instabilidade do chip LANSWITCH — eu quebrei alguma coisa?

Você atingiu um limite de recursos de contagem de hardware, não uma falha real. Quando a interface de saída do túnel é uma porta membro de VLAN e você empilha estatísticas de porta de entrada, estatísticas de túnel, estatísticas de túnel+VNI, estatísticas de bridge domain e as próprias estatísticas da VLAN de saída umas sobre as outras, você excede a capacidade de contadores por fluxo do mecanismo de encaminhamento — as estatísticas de VLAN param de funcionar silenciosamente e o chip levanta o alarme de instabilidade. Desative qualquer uma das funções de estatísticas empilhadas e os dois problemas desaparecem.

display vxlan tunnel mostra que o túnel está up mas as VMs por trás ainda não conseguem se comunicar — por onde eu começo?

Duas verificações, em ordem. Primeiro, display bgp evpn peer — confirme que o vizinho EVPN que construiu este túnel está realmente Established, não apenas que o objeto de túnel existe; uma sessão que oscilou e se reestabeleceu silenciosamente pode deixar o túnel up enquanto as rotas ainda não foram reaprendidas. Segundo, display mac-address bridge-domain — confirme que a MAC de destino foi realmente aprendida no bridge domain esperado. Um túnel que mostra Up enquanto protege o bridge domain errado, ou um por trás de uma sessão EVPN obsoleta, parecem idênticos vistos de fora a “túnel up, nada funciona”.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no modelo VXLAN baseado em BGP EVPN do manual de manutenção V300 das séries Huawei CloudEngine 16800/9800/8800/6800 — display vxlan tunnel / vxlan troubleshooting / vxlan peer / bgp evpn peer, além dos casos de campo por trás deles. Se o seu fabric usa VXLAN baseado em multicast sem EVPN, ou um gateway de overlay de outro fabricante, os comandos exatos mudam, mas a ordem de diagnóstico — estado do túnel, vizinho do plano de controle, rota do underlay, e então o próprio tráfego — se aplica diretamente. Não cobre em profundidade os casos extremos de multi-homing EVPN (ESI) nem as particularidades do overlay VXLAN em IPv6.

Travado em um túnel VXLAN específico?

Conte-nos o que display vxlan troubleshooting e display bgp evpn peer mostram, e a qual dessas quatro formas isso corresponde, e ajudamos você a interpretar.

WhatsApp com um engenheiro →