Um switch Leaf que não encontra a rota até uma VM de destino é um dos chamados mais comuns em um fabric VXLAN BGP EVPN. Esta é a ordem de verificação que encontra a falha mais rápido — confirmar que o ARP realmente está lá, confirmar que a rota realmente é gerada, confirmar que ela realmente é aprendida, e confirmar que o VPN Target realmente a deixa passar.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
A rota está faltando por uma de exatamente quatro razões, e elas seguem uma ordem estrita — verifique-as nessa ordem e você para de adivinhar.
Em um switch Leaf de um fabric VXLAN BGP EVPN, «a rota para aquela VM não existe» quase nunca significa que o fabric esteja quebrado de ponta a ponta. Significa que um elo específico de uma cadeia de quatro elos não se completou: o Leaf de destino nunca aprendeu o ARP da VM, esse Leaf nunca transformou o ARP em uma rota EVPN, este Leaf nunca aprendeu a rota anunciada pelo outro lado, ou a rota chegou mas a comunidade VPN Target nunca a deixou entrar na tabela de roteamento local.
A seguir está a divisão de falhas na qual isto se baseia, os comandos display bgp evpn a executar em cada etapa, as causas que aparecem repetidamente depois da primeira verificação, e respostas testadas em campo para as perguntas que surgem em torno dessa falha específica.
As falhas de rota EVPN ausente se dividem em duas metades: o problema ainda está no Leaf remoto, ou o Leaf remoto já fez seu trabalho e o problema está no que voltou para este.
Colocar primeiro o sintoma nessa divisão indica se deve continuar trabalhando no Leaf remoto ou voltar a trabalhar no local — o que evita uma ida e volta ao equipamento errado.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
As verificações 1 e 2 abaixo ficam inteiramente no Leaf remoto; as verificações 3 e 4 ficam inteiramente neste Leaf. Nada sobre alcançabilidade IP, configuração de VLAN em outra parte do fabric, ou o link físico pertence a essa árvore — são falhas separadas com suas próprias verificações.
Quatro verificações, um comando cada, e cada uma indica se deve continuar ou ir corrigir algo específico.
Se o ARP não estiver lá, nada além deste ponto importa ainda — a rota EVPN não pode existir antes do ARP.
<Leaf3> display arp network 192.168.1.11
ARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlow, RD - Redirect
EXP: Expire-time VLAN:VLAN or Bridge Domain
IP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN INTERFACE VPN-INSTANCE
----------------------------------------------------------------------------------------
192.168.1.11 0019-9400-000b 1164 D/BD1012254 Eth-Trunk1.4 ABC
----------------------------------------------------------------------------------------
Total:1 Dynamic:1 Static:0 Interface:0 OpenFlow:0
Redirect:0
// ARP present -> move to check 2. Nothing here -> this is an ARP fault, not an EVPN fault.Uma entrada ARP existir localmente não significa que ela tenha sido transformada em uma rota visível para o resto do fabric.
<Leaf3> display bgp instance overlay evpn all routing-table | include 192.168.1.11
Local AS number : 64888
BGP Local router ID is 172.31.58.20
Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
EVPN address family:
Number of Mac Routes: 82864
*> 0:48:0019-9400-000b:32:192.168.1.11 0.0.0.0
// 0.0.0.0 next-hop = this route was generated locally, on this LeafO Leaf remoto pode ter anunciado uma rota perfeitamente correta e este Leaf ainda assim pode não tê-la — isso é um problema do lado receptor, não do lado que gera.
<Leaf3> display bgp instance overlay evpn all routing-table mac-route 0:48:0019-9400-000b:32:192.168.1.11
BGP local router ID : 172.31.58.20
Local AS number : 64888
Total routes of Route Distinguisher(2101:1012254): 1
BGP routing table entry information of 0:48:0019-9400-000b:32:192.168.1.11:
Imported route.
Label information (Received/Applied): NULL/1012254 1010000
From: 0.0.0.0 (0.0.0.0)
Route Duration: 0d07h52m39s
Original nexthop: 172.31.58.138
Ext-Community: RT <0 : 1010000>, RT <0 : 1012254>, Tunnel Type <VxLan>, Router's MAC <0000-5e00-02c9>
Route Type: 2 (MAC Advertisement Route)
Advertised to such 1 peers:
10.124.138.251
// this is the remote Leaf's own advertised copy -- confirm it looks like this before checking the local sideÉ aqui que quase todos os casos restantes acabam: a rota chegou, e o VPN Target local ainda não a deixa entrar na tabela de roteamento.
<Leaf1> display current-configuration configuration evpn-instance evpn10
evpn vpn-instance evpn10 bd-mode
route-distinguisher 1:10
vpn-target 1:100 10:1 export-extcommunity
vpn-target 10:1 import-extcommunity
// import-extcommunity must share at least one value with the Ext-Community RT the remote Leaf advertisedDepois que as quatro verificações acima indicarem onde está o problema, essas cinco causas explicam a maior parte do que realmente está errado.
SINTOMAdisplay arp network <IP-VM> no Leaf remoto não retorna nada, e nada mais adiante na cadeia EVPN tem ainda com o que trabalhar.
CAUSAA rota EVPN para o IP de uma VM é gerada diretamente a partir da tabela local de ARP/rota de host no Leaf ao qual ela está conectada — se o ARP nunca foi aprendido (host inativo, VLAN errada, interface de acesso errada, supressão de ARP do gateway mal configurada), simplesmente não há dados de origem a partir dos quais construir uma rota EVPN.
SOLUÇÃOTrate isso primeiro como uma falha de aprendizado de ARP no Leaf remoto — verifique a interface do lado de acesso, a associação de VLAN/BD e a configuração do gateway ali — antes de mexer em qualquer coisa relacionada a EVPN.
SINTOMAConfirma-se que o ARP está presente no Leaf remoto, mas display bgp instance overlay evpn all routing-table | include <IP-VM> não retorna nada.
CAUSAA rota MAC/IP só é gerada se a interface Vbdif do BD dessa VM estiver corretamente vinculada à instância VPN correta e a instância EVPN correspondente realmente estiver configurada — um gateway que está ativo mas vinculado à vpn-instance errada, ou uma instância EVPN totalmente ausente para esse BD, produz um Leaf que tem o ARP e simplesmente nunca a transforma em rota.
SOLUÇÃOConfirme que display current-configuration interface vbdif <ID-BD> mostra o ip binding vpn-instance correto, e que existe uma evpn vpn-instance vinculada a esse BD.
SINTOMAA própria tabela EVPN do Leaf remoto mostra a rota gerada e anunciada, mas a tabela do Leaf local não mostra nada para o mesmo prefixo.
CAUSAUma route-policy do BGP aplicada em qualquer um dos Leafs, ou em um refletor de rota Spine no meio, pode filtrar uma rota EVPN do anúncio sem produzir nenhum erro ou entrada de log — a rota simplesmente nunca cruza para o outro lado.
SOLUÇÃOVerifique se há uma route-policy configurada sob o peer BGP EVPN ou a address-family em cada dispositivo no caminho de anúncio, não apenas nas duas pontas, e confirme que ela não está correspondendo a esse prefixo ou RT específico.
SINTOMAConfirma-se que a rota está presente na tabela EVPN do Leaf local (display bgp instance overlay evpn all routing-table mac-route <prefixo> a mostra) mas ela nunca chega à tabela real de encaminhamento/roteamento.
CAUSAO BGP EVPN só aceita uma rota na tabela de roteamento se pelo menos um dos valores Ext-Community RT da rota corresponder a um dos valores import-extcommunity da instância EVPN local — se os conjuntos RT de exportação e importação não se sobrepuserem em nada, a rota é descartada silenciosamente, sem nada nos logs.
SOLUÇÃOCompare o import-extcommunity de display current-configuration configuration evpn-instance <nome> com os valores Ext-Community RT que o lado remoto realmente está anunciando (não os valores que você supõe que ele anuncia), e ajuste a lista de importação local para incluir um valor coincidente.
SINTOMAA tabela EVPN local mostra duas entradas para exatamente o mesmo prefixo, recebidas de dois Router IDs diferentes, com uma marcada como not preferred for peer address, e isso é reportado como «a rota parece errada».
CAUSAEm qualquer fabric com mais de um Spine atuando como refletor de rota, a mesma rota EVPN legitimamente chega duas vezes — uma refletida por cada Spine — e a própria seleção de melhor caminho do BGP escolhe uma como ativa e marca a outra como não preferida. Este é um comportamento normal de caminho redundante, não evidência de uma falha.
SOLUÇÃOConfirme que ambas as cópias carregam a mesma Label information e os mesmos valores Ext-Community RT; se sim, essa não é a causa do chamado de rota ausente — continue verificando a checagem cruzada de VPN Target.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
O tipo de rota 2 é uma MAC Advertisement Route — o tipo de rota EVPN que carrega o endereço MAC de um host e, quando o IP do host é conhecido, também o seu IP. É isso que toda essa sequência de verificação está perseguindo. O tipo 3 (Inclusive Multicast Route) é o que constrói o próprio túnel L2, e o tipo 5 (IP Prefix Route) é o que um gateway IRB anuncia para toda uma sub-rede — uma falha diferente, coberta na nota VXLAN Tunnel Won't Establish.
Verifique o ARP primeiro. A rota MAC/IP EVPN de um host é gerada a partir da entrada ARP aprendida localmente para esse host — não há rota para encontrar na tabela EVPN se o ARP nunca foi aprendido no Leaf ao qual o host está conectado, então começar pela tabela EVPN em um Leaf sem ARP só desperdiça um passo.
Sim, para a entrada ARP dinâmica de um único host — ela só limpa e redispara o aprendizado para esse IP, não para toda a tabela ARP. É razoável tentar isso depois que a configuração já foi confirmada correta, mas é uma solução paliativa para o sintoma, não uma correção; se a rota não voltar depois de um reset, a causa subjacente (RT incompatível, route-policy, instância EVPN ausente) ainda está lá e precisa ser corrigida.
Confirme que você está comparando o par correto: o export-extcommunity do lado remoto (o que ele realmente colocou na linha, visível no campo Ext-Community da rota recebida) contra o import-extcommunity deste Leaf (não seu próprio valor de export, com o qual é fácil comparar por engano). Uma rota só precisa compartilhar um valor RT entre esses dois campos específicos, não corresponder a cada RT que os dois Leafs têm configurado.
Esta nota assume que o vizinho BGP EVPN está Established e que o túnel entre os dois VTEPs já existe — o fabric funciona, mas falta a rota de um host específico. Se o próprio peer BGP EVPN nunca chegar a Established, ou a rota Inclusive Multicast / IP Prefix que constrói o túnel nunca cruzar de forma alguma, essa é uma falha diferente coberta na nota VXLAN Tunnel Won't Establish, que começa uma camada abaixo.
Quando é todo host em um Leaf em vez de um único host, suba as verificações um nível: confirme que o peer BGP EVPN desse Leaf ainda está Established (não que esteve), e que sua configuração de instância EVPN e RT não foi alterada em uma mudança recente — uma má configuração no nível da instância afeta todos os hosts atrás dela de uma vez, enquanto um único ARP ausente afeta apenas aquele host.
Esta nota se baseia no fabric de gateway distribuído BGP EVPN estilo Huawei CloudEngine e seus comandos display bgp instance overlay evpn / display arp network / display current-configuration configuration evpn-instance, além dos casos de campo por trás deles. Ela assume que o relacionamento de vizinho BGP EVPN e o túnel VXLAN subjacente já existem — para as falhas de estabelecimento do próprio túnel, veja a nota VXLAN Tunnel Won't Establish. Não cobre o provisionamento automático de rotas orquestrado por controlador (fabric SDN), onde os mesmos sintomas podem remeter ao controlador em vez de à configuração do dispositivo.
Conte-nos em qual das quatro verificações está falhando — ARP, geração de rota, recepção de rota, ou VPN Target — junto com a saída relevante de display bgp evpn / display arp, e ajudamos você a interpretá-la.