Un switch Leaf que no encuentra la ruta hacia una VM de destino es uno de los tickets más comunes en un fabric VXLAN BGP EVPN. Este es el orden de verificación que encuentra la falla más rápido — confirmar que el ARP realmente está, confirmar que la ruta realmente se genera, confirmar que realmente se aprende, y confirmar que el VPN Target realmente la deja pasar.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
La ruta falta por una de exactamente cuatro razones, y siguen un orden estricto — revíselas en ese orden y deja de adivinar.
En un switch Leaf de un fabric VXLAN BGP EVPN, «la ruta hacia esa VM no está» casi nunca significa que el fabric esté roto de extremo a extremo. Significa que un eslabón específico de una cadena de cuatro eslabones no se completó: el Leaf de destino nunca aprendió el ARP de la VM, ese Leaf nunca convirtió el ARP en una ruta EVPN, este Leaf nunca aprendió la ruta anunciada por el otro lado, o la ruta llegó pero la comunidad VPN Target nunca la dejó cruzar a la tabla de enrutamiento local.
A continuación, la división de fallas en la que se basa este texto, los comandos display bgp evpn a ejecutar en cada etapa, las causas que aparecen una y otra vez una vez superada la primera comprobación, y respuestas probadas en campo a las preguntas que surgen en torno a esta falla concreta.
Las fallas de ruta EVPN faltante se dividen en dos mitades: el problema todavía está en el Leaf remoto, o el Leaf remoto ya hizo su trabajo y el problema está en lo que volvió hacia este.
Ubicar primero el síntoma en esta división indica si hay que seguir trabajando en el Leaf remoto o volver a trabajar en el local — lo que ahorra un viaje de ida y vuelta al equipo equivocado.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Las comprobaciones 1 y 2 siguientes viven enteramente en el Leaf remoto; las comprobaciones 3 y 4 viven enteramente en este Leaf. Nada relacionado con la alcanzabilidad IP, la configuración VLAN en otra parte del fabric, o el enlace físico pertenece a este árbol — son fallas separadas con sus propias comprobaciones.
Cuatro comprobaciones, un comando cada una, y cada una indica si hay que seguir adelante o ir a corregir algo específico.
Si el ARP no está, nada más allá de este punto importa todavía — la ruta EVPN no puede existir antes que el 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.Que una entrada ARP exista localmente no significa que se haya convertido en una ruta visible para el resto del 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 LeafEl Leaf remoto puede haber anunciado una ruta perfectamente correcta y este Leaf aún así puede no tenerla — eso es un problema del lado receptor, no del lado que la genera.
<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 sideAquí es donde termina casi todo caso restante: la ruta llegó, y el VPN Target local sigue sin dejarla entrar en la tabla de enrutamiento.
<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 advertisedUna vez que las cuatro comprobaciones anteriores le han indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente falla.
SÍNTOMAdisplay arp network <IP-VM> en el Leaf remoto no devuelve nada, y nada más adelante en la cadena EVPN tiene todavía con qué trabajar.
CAUSALa ruta EVPN para la IP de una VM se genera directamente a partir de la tabla local de ARP/ruta de host en el Leaf al que está conectada — si el ARP nunca se aprendió (host caído, VLAN incorrecta, interfaz de acceso incorrecta, supresión de ARP del gateway mal configurada), simplemente no hay datos de origen a partir de los cuales construir una ruta EVPN.
SOLUCIÓNTrate esto primero como una falla de aprendizaje de ARP en el Leaf remoto — revise la interfaz del lado de acceso, la pertenencia a VLAN/BD y la configuración del gateway allí — antes de tocar nada relacionado con EVPN.
SÍNTOMASe confirma que el ARP está presente en el Leaf remoto, pero display bgp instance overlay evpn all routing-table | include <IP-VM> no devuelve nada.
CAUSALa ruta MAC/IP solo se genera si la interfaz Vbdif del BD de esa VM está correctamente vinculada a la instancia VPN correcta y la instancia EVPN correspondiente realmente está configurada — un gateway activo pero vinculado a la vpn-instance equivocada, o una instancia EVPN completamente ausente para ese BD, produce un Leaf que tiene el ARP y simplemente nunca lo convierte en ruta.
SOLUCIÓNConfirme que display current-configuration interface vbdif <ID-BD> muestra el ip binding vpn-instance correcto, y que existe una evpn vpn-instance vinculada a ese BD.
SÍNTOMALa propia tabla EVPN del Leaf remoto muestra la ruta generada y anunciada, pero la tabla del Leaf local no muestra nada para el mismo prefijo.
CAUSAUna route-policy de BGP aplicada en cualquiera de los dos Leaf, o en un reflector de ruta Spine intermedio, puede filtrar una ruta EVPN del anuncio sin producir ningún error ni entrada de registro — la ruta simplemente nunca cruza al otro lado.
SOLUCIÓNRevise si hay una route-policy configurada bajo el peer BGP EVPN o la address-family en cada dispositivo de la ruta de anuncio, no solo en los dos extremos, y confirme que no está coincidiendo con este prefijo o RT específico.
SÍNTOMASe confirma que la ruta está presente en la tabla EVPN del Leaf local (display bgp instance overlay evpn all routing-table mac-route <prefijo> la muestra) pero nunca llega a la tabla de reenvío/enrutamiento real.
CAUSABGP EVPN solo acepta una ruta en la tabla de enrutamiento si al menos uno de los valores Ext-Community RT de la ruta coincide con uno de los valores import-extcommunity de la instancia EVPN local — si los conjuntos RT de exportación e importación no se superponen en absoluto, la ruta se descarta silenciosamente, sin nada en los registros.
SOLUCIÓNCompare el import-extcommunity de display current-configuration configuration evpn-instance <nombre> con los valores Ext-Community RT que el lado remoto realmente está anunciando (no los que usted supone que anuncia), y ajuste la lista de importación local para incluir un valor coincidente.
SÍNTOMALa tabla EVPN local muestra dos entradas para exactamente el mismo prefijo, recibidas de dos Router ID diferentes, con una marcada como not preferred for peer address, y esto se reporta como «la ruta se ve mal».
CAUSAEn cualquier fabric con más de un Spine actuando como reflector de ruta, la misma ruta EVPN llega legítimamente dos veces — una reflejada por cada Spine — y la propia selección de mejor ruta de BGP elige una como activa y marca la otra como no preferida. Este es un comportamiento normal de ruta redundante, no evidencia de una falla.
SOLUCIÓNConfirme que ambas copias tienen la misma Label information y los mismos valores Ext-Community RT; si es así, esta no es la causa del ticket de ruta faltante — siga revisando la comprobación cruzada de VPN Target en su lugar.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
El tipo de ruta 2 es una MAC Advertisement Route — el tipo de ruta EVPN que lleva la dirección MAC de un host y, cuando se conoce la IP del host, también su IP. Es lo que persigue toda esta secuencia de comprobación. El tipo 3 (Inclusive Multicast Route) es lo que construye el propio túnel L2, y el tipo 5 (IP Prefix Route) es lo que un gateway IRB anuncia para toda una subred — una falla distinta, cubierta en la nota VXLAN Tunnel Won't Establish.
Revise primero el ARP. La ruta MAC/IP EVPN de un host se genera a partir de la entrada ARP aprendida localmente para ese host — no hay ninguna ruta que encontrar en la tabla EVPN si el ARP nunca se aprendió en el Leaf al que el host está conectado, así que empezar por la tabla EVPN en un Leaf sin ARP solo desperdicia un paso.
Sí, para la entrada ARP dinámica de un solo host — solo borra y vuelve a disparar el aprendizaje de esa IP, no de toda la tabla ARP. Es razonable probarlo una vez que la configuración ya se confirmó correcta, pero es un remedio para el síntoma, no una solución; si la ruta no regresa después de un reinicio, la causa subyacente (RT no coincidente, route-policy, instancia EVPN faltante) sigue ahí y necesita corregirse.
Confirme que está comparando el par correcto: el export-extcommunity del lado remoto (lo que realmente puso en el cable, visible en el campo Ext-Community de la ruta recibida) frente al import-extcommunity de este Leaf (no su propio valor de export, con el que es fácil comparar por error). Una ruta solo necesita compartir un valor RT entre esos dos campos específicos, no coincidir con cada RT que los dos Leaf tienen configurado.
Esta nota asume que el vecino BGP EVPN está Established y que el túnel entre los dos VTEP ya existe — el fabric funciona, pero falta la ruta de un host específico. Si el propio peer BGP EVPN nunca llega a Established, o la ruta Inclusive Multicast / IP Prefix que construye el túnel nunca cruza en absoluto, esa es una falla distinta cubierta en la nota VXLAN Tunnel Won't Establish, que comienza una capa más abajo.
Cuando es todo host en un Leaf en lugar de un solo host, suba las comprobaciones un nivel: confirme que el peer BGP EVPN de ese Leaf sigue Established (no que lo estuvo), y que su configuración de instancia EVPN y RT no se tocó en un cambio reciente — una mala configuración a nivel de instancia afecta a todos los hosts detrás de ella a la vez, mientras que un solo ARP faltante solo afecta a ese host.
Esta nota se basa en el fabric de gateway distribuido BGP EVPN de estilo Huawei CloudEngine y sus comandos display bgp instance overlay evpn / display arp network / display current-configuration configuration evpn-instance, además de los casos de campo que los respaldan. Asume que la relación de vecino BGP EVPN y el túnel VXLAN subyacente ya existen — para las fallas de establecimiento del túnel en sí, vea la nota VXLAN Tunnel Won't Establish. No cubre el aprovisionamiento automático de rutas orquestado por controlador (fabric SDN), donde los mismos síntomas pueden remontarse al controlador en lugar de a la configuración del dispositivo.
Cuéntenos en cuál de las cuatro comprobaciones está fallando — ARP, generación de ruta, recepción de ruta, o VPN Target — junto con la salida relevante de display bgp evpn / display arp, y le ayudamos a interpretarla.