Un túnel VXLAN que nunca llega a subir en absoluto es una falla distinta de uno que está activo pero fluctúa, o activo pero al que le falta una ruta. Este es el orden capa por capa que la encuentra — el vecino BGP EVPN, la ruta que realmente construye el túnel, y el cruce de VPN Target que decide si esa ruta es aceptada.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Un túnel que nunca se establece falla en exactamente una de tres capas, y la capa depende de si es un túnel L2 o L3.
En un fabric de gateway distribuido BGP EVPN VXLAN, el túnel entre dos VTEP no se configura directamente — se construye dinámicamente una vez recibida la ruta correcta. Un túnel L2 se construye a partir de una ruta Inclusive Multicast de tipo 3; un túnel L3 se construye a partir de una ruta IP Prefix de tipo 5 (también llamada ruta IRB). Cualquiera de las dos rutas solo se acepta si la lista de importación VPN Target local se superpone con lo que el lado remoto exportó. Un túnel que no se establece en absoluto, entonces, falla en exactamente una de estas tres capas: el propio vecino BGP EVPN, la ruta que construye ese tipo específico de túnel, o el cruce de VPN Target que decide si la ruta se deja pasar.
Esto es distinto de un túnel que sube y luego cae, o de uno donde el túnel existe pero falta una ruta específica dentro de él — esas son fallas propias, referenciadas de forma cruzada al final de esta nota. A continuación, la división en tres capas, las comprobaciones display bgp evpn para túneles L2 y L3 en paralelo, las causas detrás de cada capa, y respuestas probadas en campo.
Las fallas de establecimiento de túnel VXLAN se dividen primero por tipo de túnel — L2 o L3 — y luego por las mismas tres capas subyacentes a ambos.
Un túnel L2 y uno L3 comparten la capa 1 (el vecino BGP EVPN) pero divergen en la capa 2, porque se construyen a partir de dos tipos de ruta EVPN distintos, con dos comandos de configuración distintos a revisar.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La capa 1 es compartida — corrija el vecino una vez y ambos tipos de túnel se benefician. Las capas 2 y 3 son específicas del tipo de túnel que persigue, y los comandos realmente difieren entre ellas.
Una capa compartida, luego dos capas específicas de cada túnel con su propio tipo de ruta y su propio comando VPN Target.
Ningún tipo de túnel puede construir nada antes de que esta capa esté sólida — revísela primero, sin importar si persigue una falla L2 o L3.
<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 problemUn túnel L2 entre dos VTEP se construye enteramente a partir de este único tipo de ruta — si no está, el túnel tampoco.
<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 nextUn túnel L3 se construye a partir de la ruta IP Prefix del gateway en su lugar — misma idea, distinto tipo de ruta y distinto comando.
<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 itLa ruta llegó; el lado local todavía tiene que dejarla entrar — y el comando que controla eso es distinto para túneles L2 y 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 100Una vez que las tres capas anteriores le han indicado dónde está el problema, estas cinco causas explican la mayor parte de lo que realmente falla.
SÍNTOMAdisplay bgp evpn peer muestra un peer atascado indefinidamente en un estado no Established, y nada río abajo — ni ruta Inclusive, ni ruta IP Prefix — tiene con qué construirse.
CAUSATanto las rutas que construyen el túnel L2 como las del L3 viajan sobre la misma sesión BGP EVPN, y esa sesión se origina desde una Loopback en cada VTEP. Si el IGP entre los dos VTEP no lleva realmente una ruta hacia la Loopback del peer, la sesión TCP detrás de BGP no puede formarse en absoluto, y parece un problema de EVPN cuando en realidad es de IGP.
SOLUCIÓNHaga Ping desde la dirección de origen Loopback local directamente hacia la remota (ping -a <local> <remoto>) antes de tocar cualquier configuración de EVPN o VPN-target — si eso falla, corrija primero la ruta IGP.
SÍNTOMALas dos Loopbacks se hacen ping mutuamente sin problema, pero display bgp evpn peer sigue sin llegar a Established.
CAUSALa alcanzabilidad entre las dos loopbacks confirma que el enrutamiento está bien, pero no confirma que la propia sesión TCP de BGP sobreviva a la ruta — una ACL de defensa de CPU, un límite de tasa CPCAR, o un middlebox en algún punto intermedio puede descartar silenciosamente el tráfico del puerto TCP 179 mientras el ICMP sigue pasando limpiamente.
SOLUCIÓNRevise display tcp status para el estado real de la sesión entre los dos Router ID; si no está claramente Established, busque límites CPCAR o ACL en la ruta que afecten específicamente al puerto TCP 179, no solo la alcanzabilidad general.
SÍNTOMAdisplay bgp evpn all routing-table inclusive-route en el VTEP de origen muestra la ruta con From: 0.0.0.0 y la lista como anunciada al peer remoto — pero la propia búsqueda del VTEP remoto para el mismo prefijo no devuelve nada.
CAUSALa ruta Inclusive Multicast del túnel L2 solo se acepta en el extremo remoto si el import-extcommunity de la instancia EVPN de ese VTEP comparte un valor con el RT con el que se exportó la ruta — sin superposición, la ruta se descarta silenciosamente al llegar, sin error en ninguno de los dos lados.
SOLUCIÓNCompare el import-extcommunity de la evpn-instance del VTEP remoto directamente con los valores Ext-Community RT mostrados en la ruta anunciada del lado de origen, no con lo que usted supone que se configuró.
SÍNTOMALa ruta IP Prefix parece generarse correctamente e incluso aparece en la address-family EVPN en el VTEP receptor, pero el túnel hacia ese gateway sigue sin construirse y la subred permanece inalcanzable.
CAUSAUn túnel L3 necesita que su VPN Target esté configurado bajo la ipv4-family de la instancia VPN con la palabra clave evpn final (vpn-target ... export-extcommunity evpn / import-extcommunity evpn) — configurarlo como un vpn-target simple sin esa palabra clave, o configurarlo bajo la instancia EVPN en su lugar (que es donde pertenece la forma L2), deja la ruta visible a nivel EVPN pero nunca resuelta en la tabla de enrutamiento propia de la instancia VPN.
SOLUCIÓNConfirme con display current-configuration configuration vpn-instance <nombre> que las líneas export/import-extcommunity llevan ambas la palabra clave evpn, y que la ruta aparece específicamente bajo la entrada VPN-Instance en la salida de la tabla de enrutamiento, no solo en la sección de address-family EVPN de arriba.
SÍNTOMADespués de resolver un problema de establecimiento de túnel L2 entre dos VTEP, el túnel L3 entre los mismos dos dispositivos sigue sin subir, y parece que la corrección anterior no funcionó.
CAUSALos dos tipos de túnel solo comparten la capa de vecino BGP EVPN — todo lo que está por encima (el tipo de ruta, el nivel de configuración de VPN Target, el comando específico de import/export) es independiente entre L2 y L3. Corregir una discrepancia de RT a nivel de instancia EVPN no hace nada por una discrepancia de RT a nivel de instancia VPN en el mismo equipo.
SOLUCIÓNTrate una corrección L2 y una corrección L3 como dos tickets separados en el mismo par de vecinos, y vuelva a ejecutar las comprobaciones de capa 2 y capa 3 para cada tipo de túnel por separado, incluso después de que el otro se confirme funcionando.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Established solo confirma que la sesión del plano de control BGP EVPN está activa entre los dos VTEP. El túnel en sí todavía necesita que su tipo de ruta — Inclusive Multicast para L2, IP Prefix para L3 — se genere, anuncie, reciba, y acepte mediante el cruce de VPN Target. Un vecino saludable con una ruta faltante o rechazada sigue sin producir túnel.
Inclusive Multicast (tipo de ruta 3) es lo que construye un túnel VXLAN L2 — está ligada a la dirección de origen NVE del VTEP y no lleva información de host en absoluto, solo «este VTEP existe y es alcanzable para este VNI». IP Prefix (tipo de ruta 5) es lo que construye un túnel L3 — está ligada a una subred de gateway (Vbdif) específica y es lo que un gateway IRB anuncia para que otros VTEP puedan enrutar hacia esa subred a través de él.
Revise en qué nivel de comando realmente lo configuró. Para un túnel L2, el VPN Target vive bajo la instancia EVPN (evpn vpn-instance ... vpn-target ... export/import-extcommunity, sin palabra clave final); para un túnel L3 vive bajo la ipv4-family de la instancia VPN con la palabra clave evpn (vpn-target ... export/import-extcommunity evpn). Números RT de apariencia idéntica configurados en el nivel equivocado, o la falta de la palabra clave evpn en el lado L3, producen exactamente este síntoma.
Esta nota asume que el túnel literalmente nunca ha subido — ningún estado Established de BGP EVPN, o ninguna ruta Inclusive/IP Prefix jamás aceptada. Si el túnel sí se estableció y luego cae, fluctúa, o sube bien pero una migración de VM o un flujo de tráfico específico se comporta de forma extraña, esas son comprobaciones distintas — vea la nota Fallas de overlay VXLAN, que retoma desde un túnel que ya existe.
Si cada comprobación de ruta de esta nota vuelve limpia — vecino Established, ruta Inclusive o IP Prefix generada y recibida, VPN Target superpuesto — y el túnel sigue sin reenviar tráfico, la falla ha pasado más allá del establecimiento del túnel hacia una categoría distinta: revise si falta la ruta EVPN de un host específico en lugar del propio túnel, cubierto en la nota Ruta EVPN no aprendida.
Sí — todos los comandos de esta nota son de solo lectura excepto el ping loopback-a-loopback usado para probar la alcanzabilidad, que no toca el plano de datos del fabric. Ninguno requiere cambios de configuración solo para diagnosticar, así que no hay razón para esperar una ventana de mantenimiento antes de ejecutar las comprobaciones en sí.
Esta nota se basa en el fabric de gateway distribuido BGP EVPN de estilo Huawei CloudEngine y sus comandos display bgp evpn peer / display bgp evpn all routing-table inclusive-route / prefix-route / display current-configuration configuration evpn-instance / vpn-instance, además de los casos de campo que los respaldan. Asume un diseño EVPN VXLAN estándar de dos niveles (L2 + L3) y no cubre el aprovisionamiento automático de underlay/overlay orquestado por controlador (fabric SDN), donde estos mismos síntomas pueden remontarse al controlador en lugar de a la configuración del dispositivo mostrada aquí.
Cuéntenos en qué capa está atascado — vecino, ruta, o VPN Target — además de si es un túnel L2 o L3, y la salida relevante de display bgp evpn, y le ayudamos a interpretarla.