Um túnel VXLAN que nunca sobe de forma alguma é uma falha diferente de um que está ativo mas oscila, ou ativo mas com uma rota faltando. Esta é a ordem camada por camada que a encontra — o vizinho BGP EVPN, a rota que realmente constrói o túnel, e o cruzamento de VPN Target que decide se essa rota é aceita.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Um túnel que nunca se estabelece falha em exatamente uma de três camadas, e a camada depende de ser um túnel L2 ou L3.
Em um fabric de gateway distribuído BGP EVPN VXLAN, o túnel entre dois VTEPs não é configurado diretamente — ele é construído dinamicamente assim que a rota correta é recebida. Um túnel L2 é construído a partir de uma rota Inclusive Multicast do tipo 3; um túnel L3 é construído a partir de uma rota IP Prefix do tipo 5 (também chamada de rota IRB). Qualquer uma das rotas só é aceita se a lista de importação de VPN Target local se sobrepuser ao que o lado remoto exportou. Um túnel que não se estabelece de forma alguma, então, está falhando em exatamente uma dessas três camadas: o próprio vizinho BGP EVPN, a rota que constrói esse tipo específico de túnel, ou o cruzamento de VPN Target que decide se a rota é aceita.
Isso é diferente de um túnel que sobe e depois cai, ou de um em que o túnel existe mas falta uma rota específica dentro dele — essas são falhas próprias, referenciadas de forma cruzada no final desta nota. A seguir está a divisão em três camadas, as verificações display bgp evpn para túneis L2 e L3 lado a lado, as causas por trás de cada camada, e respostas testadas em campo.
As falhas de estabelecimento de túnel VXLAN se dividem primeiro por tipo de túnel — L2 ou L3 — e depois pelas mesmas três camadas subjacentes a ambos.
Um túnel L2 e um L3 compartilham a camada 1 (o vizinho BGP EVPN) mas divergem na camada 2, porque são construídos a partir de dois tipos de rota EVPN diferentes, com dois comandos de configuração diferentes a verificar.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
A camada 1 é compartilhada — corrija o vizinho uma vez e ambos os tipos de túnel se beneficiam. As camadas 2 e 3 são específicas do tipo de túnel que você está perseguindo, e os comandos realmente diferem entre elas.
Uma camada compartilhada, depois duas camadas específicas de cada túnel com seu próprio tipo de rota e seu próprio comando VPN Target.
Nenhum tipo de túnel pode construir nada antes que essa camada esteja sólida — verifique-a primeiro, seja qual for a falha L2 ou L3 que você está perseguindo.
<VTEP2> display bgp evpn peer
BGP local router ID : 10.3.3.3
Local AS number : 100
Total number of peers : 2 Peers in established state : 2
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
10.1.1.1 4 100 4010 4016 0 0066h46m Established 1
10.2.2.2 4 100 4009 4010 0 0066h40m Established 4
<VTEP2> ping -a 10.2.2.2 10.3.3.3
Reply from 10.3.3.3: bytes=32 time=1ms TTL=126
Ping statistics for 10.3.3.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
// loopback-to-loopback reachable -> if peer still isn't Established, check TCP session state next
<VTEP2> display tcp status
TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State
49f3370c 262/8 10.2.2.2:53342 10.3.3.3:179 0 Established
49f339f4 262/7 10.2.2.2:55160 10.1.1.1:179 0 Established
// clean Established state here -> the neighbor layer is not the problemUm túnel L2 entre dois VTEPs é construído inteiramente a partir desse único tipo de rota — se ela não estiver lá, o túnel também não estará.
<VTEP2> display current-configuration interface nve 1
interface Nve1
source 10.2.2.2
vni 10 head-end peer-list protocol bgp
<VTEP2> display bgp evpn all routing-table inclusive-route 0:32:10.2.2.2
Total routes of Route Distinguisher(1:10): 1
BGP routing table entry information of 0:32:10.2.2.2:
Imported route.
From: 0.0.0.0 (0.0.0.0)
Ext-Community: RT <1 : 100>, RT <10 : 1>, Tunnel Type <VxLan(8)>
Route Type: 3 (Inclusive Multicast Route)
Advertised to such 2 peers:
10.3.3.3
10.1.1.1
// From: 0.0.0.0 = generated locally; check the same prefix for the remote VTEP's source address nextUm túnel L3 é construído a partir da rota IP Prefix do gateway em vez disso — mesma ideia, tipo de rota e comando diferentes.
<VTEP2> display current-configuration interface vbdif 10
interface Vbdif10
ip binding vpn-instance vpn1
ip address 192.168.10.1 255.255.255.0
<VTEP2> display bgp evpn all routing-table prefix-route 0:24:192.168.20.0
Total routes of Route Distinguisher(3:100): 1
BGP routing table entry information of 0:192.168.20.0:24:
Ext-Community: RT <1 : 100>, Tunnel Type <VxLan(8)>
Route Type: 5 (Ip Prefix Route)
VPN-Instance vpn1, Router ID 10.2.2.2:
BGP routing table entry information of 192.168.20.0/24:
Relay Tunnel Out-Interface: VXLAN
// showing up under VPN-Instance vpn1, not just the EVPN address family, is what confirms the L3 tunnel can actually use itA rota chegou; o lado local ainda precisa deixá-la entrar — e o comando que controla isso é diferente para túneis L2 e L3.
// L2 -- EVPN instance, no "evpn" keyword
<VTEP2> display current-configuration configuration evpn-instance evpn10
evpn vpn-instance evpn10 bd-mode
vpn-target 1:100 10:1 export-extcommunity
vpn-target 10:1 import-extcommunity
// L3 -- VPN instance, "evpn" keyword required
<VTEP2> display current-configuration configuration vpn-instance vpn1
ip vpn-instance vpn1
ipv4-family
vpn-target 1:100 export-extcommunity evpn
vpn-target 1:100 import-extcommunity evpn
vxlan vni 100Depois que as três camadas acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.
SINTOMAdisplay bgp evpn peer mostra um peer travado indefinidamente em um estado não Established, e nada a jusante — nem rota Inclusive, nem rota IP Prefix — tem com o que se construir.
CAUSATanto as rotas que constroem o túnel L2 quanto as do L3 andam sobre a mesma sessão BGP EVPN, e essa sessão é originada de uma Loopback em cada VTEP. Se o IGP entre os dois VTEPs não carregar de fato uma rota até a Loopback do peer, a sessão TCP por trás do BGP não consegue se formar de forma alguma, e parece um problema de EVPN quando na verdade é de IGP.
SOLUÇÃOFaça Ping do endereço de origem Loopback local diretamente para o remoto (ping -a <local> <remoto>) antes de mexer em qualquer configuração de EVPN ou VPN-target — se isso falhar, corrija primeiro a rota IGP.
SINTOMAAs duas Loopbacks fazem ping uma na outra sem problema, mas display bgp evpn peer ainda não chega a Established.
CAUSAA alcançabilidade entre as duas loopbacks confirma que o roteamento está bem, mas não confirma que a própria sessão TCP do BGP sobrevive ao caminho — uma ACL de defesa de CPU, um limite de taxa CPCAR, ou um middlebox em algum ponto intermediário pode descartar silenciosamente o tráfego da porta TCP 179 enquanto o ICMP ainda passa limpo.
SOLUÇÃOVerifique display tcp status para o estado real da sessão entre os dois Router IDs; se não estiver claramente Established, procure limites de CPCAR ou ACLs no caminho que afetem especificamente a porta TCP 179, não apenas a alcançabilidade geral.
SINTOMAdisplay bgp evpn all routing-table inclusive-route no VTEP de origem mostra a rota com From: 0.0.0.0 e a lista como anunciada ao peer remoto — mas a própria busca do VTEP remoto para o mesmo prefixo não retorna nada.
CAUSAA rota Inclusive Multicast do túnel L2 só é aceita no lado remoto se o import-extcommunity da instância EVPN daquele VTEP compartilhar um valor com o RT com o qual a rota foi exportada — sem sobreposição, a rota é descartada silenciosamente na chegada, sem erro em nenhum dos lados.
SOLUÇÃOCompare o import-extcommunity da evpn-instance do VTEP remoto diretamente com os valores Ext-Community RT mostrados na rota anunciada do lado de origem, não com o que você supõe que foi configurado.
SINTOMAA rota IP Prefix parece gerada corretamente e até aparece na address-family EVPN no VTEP receptor, mas o túnel para aquele gateway ainda não se constrói e a sub-rede permanece inalcançável.
CAUSAUm túnel L3 precisa que seu VPN Target seja configurado sob a ipv4-family da instância VPN com a palavra-chave evpn no final (vpn-target ... export-extcommunity evpn / import-extcommunity evpn) — configurá-lo como um vpn-target simples sem essa palavra-chave, ou configurá-lo sob a instância EVPN em vez disso (que é onde pertence a forma L2), deixa a rota visível no nível EVPN mas nunca resolvida na tabela de roteamento própria da instância VPN.
SOLUÇÃOConfirme com display current-configuration configuration vpn-instance <nome> que as linhas export/import-extcommunity carregam ambas a palavra-chave evpn, e que a rota aparece especificamente sob a entrada VPN-Instance na saída da tabela de roteamento, não apenas na seção de address-family EVPN acima dela.
SINTOMADepois de resolver um problema de estabelecimento de túnel L2 entre dois VTEPs, o túnel L3 entre os mesmos dois dispositivos ainda não sobe, e parece que a correção anterior não funcionou.
CAUSAOs dois tipos de túnel compartilham apenas a camada de vizinho BGP EVPN — tudo acima disso (o tipo de rota, o nível de configuração de VPN Target, o comando específico de import/export) é independente entre L2 e L3. Corrigir uma incompatibilidade de RT no nível da instância EVPN não faz nada por uma incompatibilidade de RT no nível da instância VPN no mesmo equipamento.
SOLUÇÃOTrate uma correção L2 e uma correção L3 como dois chamados separados no mesmo par de vizinhos, e execute novamente as verificações de camada 2 e camada 3 para cada tipo de túnel separadamente, mesmo depois que o outro for confirmado funcionando.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Established só confirma que a sessão do plano de controle BGP EVPN está ativa entre os dois VTEPs. O túnel em si ainda precisa que seu tipo de rota — Inclusive Multicast para L2, IP Prefix para L3 — seja gerado, anunciado, recebido, e aceito através do cruzamento de VPN Target. Um vizinho saudável com uma rota ausente ou rejeitada ainda assim não produz túnel.
Inclusive Multicast (tipo de rota 3) é o que constrói um túnel VXLAN L2 — está ligada ao endereço de origem NVE do VTEP e não carrega nenhuma informação de host, apenas «este VTEP existe e é alcançável para este VNI». IP Prefix (tipo de rota 5) é o que constrói um túnel L3 — está ligada a uma sub-rede de gateway (Vbdif) específica e é o que um gateway IRB anuncia para que outros VTEPs possam rotear até essa sub-rede através dele.
Verifique em qual nível de comando você realmente configurou isso. Para um túnel L2, o VPN Target fica sob a instância EVPN (evpn vpn-instance ... vpn-target ... export/import-extcommunity, sem palavra-chave no final); para um túnel L3 fica sob a ipv4-family da instância VPN com a palavra-chave evpn (vpn-target ... export/import-extcommunity evpn). Números RT de aparência idêntica configurados no nível errado, ou a falta da palavra-chave evpn no lado L3, produzem exatamente esse sintoma.
Esta nota assume que o túnel literalmente nunca subiu — nenhum estado Established do BGP EVPN, ou nenhuma rota Inclusive/IP Prefix jamais aceita. Se o túnel realmente se estabeleceu e depois cai, oscila, ou sobe bem mas uma migração de VM ou um fluxo de tráfego específico se comporta de forma estranha, essas são verificações diferentes — veja a nota Falhas de overlay VXLAN, que retoma a partir de um túnel que já existe.
Se cada verificação de rota nesta nota voltar limpa — vizinho Established, rota Inclusive ou IP Prefix gerada e recebida, VPN Target se sobrepondo — e o túnel ainda não estiver encaminhando tráfego, a falha passou do estabelecimento do túnel para uma categoria diferente: verifique se a rota EVPN de um host específico está faltando em vez do próprio túnel, coberto na nota Rota EVPN não aprendida.
Sim — todos os comandos nesta nota são somente leitura, exceto o ping loopback-para-loopback usado para testar a alcançabilidade, que não toca no plano de dados do fabric. Nenhum deles exige mudanças de configuração só para diagnosticar, então não há razão para esperar uma janela de manutenção antes de executar as próprias verificações.
Esta nota se baseia no fabric de gateway distribuído BGP EVPN estilo Huawei CloudEngine e seus comandos display bgp evpn peer / display bgp evpn all routing-table inclusive-route / prefix-route / display current-configuration configuration evpn-instance / vpn-instance, além dos casos de campo por trás deles. Ela assume um design EVPN VXLAN padrão de duas camadas (L2 + L3) e não cobre o provisionamento automático de underlay/overlay orquestrado por controlador (fabric SDN), onde esses mesmos sintomas podem remeter ao controlador em vez de à configuração do dispositivo mostrada aqui.
Conte-nos em qual camada está travado — vizinho, rota, ou VPN Target — além de se é um túnel L2 ou L3, e a saída relevante de display bgp evpn, e ajudamos você a interpretá-la.