Fallas PE-CE de MPLS L3VPN: discrepancias de RT, fugas de rutas y convergencia lenta
Una ruta VPN que no llega al PE remoto, dos VPN que se filtran entre sí, o una red que tarda dos minutos en reconverger tras un reinicio de PE — la mayoría de los casos de L3VPN caen en unas pocas formas repetibles una vez confirmada la salud de la propia sesión BGP PE-PE. Este es el orden de diagnóstico que encuentra la falla más rápido, los comandos display exactos para cada etapa, y las causas que explican la mayoría de estos casos.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Por qué esto empieza con una sesión BGP funcional, no con la configuración VPN
La mitad de lo que parece una falla de L3VPN es en realidad una falla de BGP o LDP disfrazada de VPN.
Si el propio IBGP PE-PE no llega a Established, eso es un problema del árbol de fallas de BGP antes de ser un problema de L3VPN — consulte primero ¿El vecino BGP no se establece y las rutas se vuelven inestables? Una lista de verificación completa primero. Una vez confirmada la salud de esa sesión, las fallas de L3VPN se dividen en unas pocas formas repetibles: una ruta que nunca llega al PE remoto (discrepancias locales de VPN Target, colisiones de IP entre instancias VPN, etiquetas faltantes, problemas de relevo entre dominios, o un reflector de rutas que la filtra silenciosamente), y una ruta que sí llega pero algo sigue sin estar bien (inestabilidad de capa física por debajo de una VPN por lo demás correcta, o convergencia que toma minutos en lugar de segundos tras una falla de PE).
A continuación, el árbol de fallas en el que se basa este texto, las comprobaciones de cada etapa con los comandos exactos, las causas que aparecen una y otra vez tras las primeras comprobaciones, y algunas respuestas de preguntas frecuentes extraídas de casos reales de campo.
Lea el árbol de fallas antes de tocar cualquier configuración
Las fallas de L3VPN se dividen en exactamente dos formas: la ruta nunca llega al PE remoto, o llega y algo sigue sin estar bien.
Ubicar primero el síntoma en este árbol ahorra mucho retroceso más adelante — indica cuál de las secciones siguientes aplica realmente a lo que está viendo.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Una vez que sabe qué rama aplica, casi cada comprobación siguiente está a un solo comando display de una causa confirmada — la trampa es resolver problemas en la capa VPN cuando la falla real está una capa más abajo, en el IGP, el LDP o el enlace físico subyacente.
Recorriendo cada etapa
Cuatro etapas, cuatro conjuntos diferentes de cosas que revisar — y el comando que le dice exactamente dónde una ruta deja de ser visible.
Etapa 0 — Confirmar que la ruta realmente salió del CE
Antes de tocar la configuración de RT o etiquetas, confirme que la ruta siquiera está presente en la tabla de rutas VPN local del PE cercano.
- Haga primero ping de CE a CE. Si tiene éxito, la ruta CE a CE está bien y la falla está entre el host del usuario VPN y el CE — revise esa ruta por separado.
- Si falla, ejecute display ip routing-table en ambos CE para ver si alguno tiene siquiera una ruta hacia el otro.
- En el PE, ejecute display ip routing-table vpn-instance vpn-instance-name para confirmar que la ruta del CE realmente llegó a la tabla de rutas VPN del PE — si no está ahí, la falla está realmente en la sesión CE-PE o su política de rutas, no en nada aguas abajo.
<PE> display ip routing-table vpn-instance vpna
// confirm the CE-advertised prefix is present before looking at RT, labels, or the far PE at allEtapa 1 — Coincidencia de RT / VPN Target y cruce local
La ruta está en la tabla VPN local, la sesión BGP PE-PE está Established, pero el PE remoto todavía no la tiene — revise la coincidencia de RT en sí, y otra local menos evidente.
- Ejecute display ip vpn-instance verbose en ambos PE y confirme que el Export VPN Target de este PE coincide con el Import VPN Target del PE remoto, y viceversa.
- Si dos VPN comparten deliberadamente el mismo RT para una accesibilidad cruzada controlada entre VPN, confirme también que las dos instancias VPN no están vinculadas a direcciones IP locales idénticas en el mismo PE — el cruce de rutas local prefiere silenciosamente la ruta local directa sobre la ruta BGP importada cuando el direccionamiento colisiona, y la VPN cruzada solo funciona en una dirección.
<PE> display ip vpn-instance verbose
VPN-Instance Name and ID : vpn1, 1
Route Distinguisher : 100:1
Export VPN Targets : 100:1
Import VPN Targets : 1:1
// Export/Import Targets compared directly against the far PE's own values
<PE1> display ip interface brief
Interface IP Address/Mask Physical Protocol VPN
10GE0/0/1 10.1.1.2/30 up up VPN-A
10GE0/0/2 10.1.1.2/30 up up VPN-B
// same IP bound to two different VPN instances -- local crossing picks the wrong routeEtapa 2 — Ruta presente pero no válida/óptima, o no puede alcanzar un túnel
La ruta aparece en la tabla BGP VPNv4 del PE remoto, pero nunca se instala — la razón casi siempre es el siguiente salto, el túnel, o una etiqueta faltante.
- Ejecute display bgp vpnv4 vpn-instance vpn-instance-name routing-table <prefix> y confirme que la ruta se muestra válida y óptima — si no, revise si la tabla de rutas IP tiene siquiera una ruta hacia el siguiente salto BGP (Original nexthop).
- Ejecute display bgp vpnv4 all routing-table <prefix> y busque un campo Relay Tunnel Out-Interface (confirma que la ruta realmente puede iterar hacia un LSP) y un campo Label information (confirma que se asignó una etiqueta privada) — una ruta puede ser válida y óptima y aun así nunca usarse si falta cualquiera de los dos.
- Para un diseño Option-B entre dominios en particular, revise la máscara del Loopback de cada ASBR intermedio a lo largo de la ruta — LDP solo asigna etiquetas para rutas de host /32 por defecto, así que un Loopback configurado con cualquier otra máscara rompe silenciosamente la asignación de etiqueta para ese FEC, y el LSP hacia él nunca se completa aunque BGP mismo muestre la ruta como presente.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1
Relay IP Nexthop : 10.1.1.2
Original nexthop : 3.3.3.3
..., valid, internal, best, select, active, pre 255
<HUAWEI> display bgp vpnv4 all routing-table 10.2.1.2
Label information (Received/Applied): 13316/NULL
Relay IP Out-Interface: 10GE0/0/1
Relay Tunnel Out-Interface: 10GE0/0/1
// both fields present -- route can reach a real LSP with a real label
// cross-domain Option-B fix: ASBR Loopback was 1.1.1.2 255.255.255.252 (/30)
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldpEtapa 3 — Un reflector de rutas la descarta silenciosamente
La configuración de ambos PE parece correcta aisladamente — el filtrado ocurre en el RR que está entre ellos.
- En el RR, revise display current-configuration configuration bgp bajo ipv4-family vpnv4 en busca de policy vpn-target — esto habilita el filtrado VPN-Target en el propio RR, y si el RR no tiene una instancia VPN local configurada para ese RT, descarta silenciosamente toda ruta que lo lleve.
- Revise display ip extcommunity-filter en busca de una regla deny que coincida con el RT de esta ruta, referenciada por rr-filter bajo la vista BGP-VPNv4 del RR — a menudo un resto de una política de reflexión anterior más restrictiva.
<RR> display ip extcommunity-filter
Extended Community filter Number 1
index: 10 deny rt : 100:1
index: 20 permit rt : 200:1
// RT 100:1 is being denied -- this PE's Export VPN Target never gets reflected
[RR] ip extcommunity-filter 1 permit rt 100:1
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo rr-filter
[RR-bgp-af-vpnv4] rr-filter 1Calidad: rutas inestables y convergencia lenta
La configuración VPN es correcta — la falla está una capa más abajo, o en cómo ocurre realmente el failover.
- Si un prefijo VPN específico se vuelve inestable continuamente con la configuración de VPN, RT y BGP todas limpias, baje desde el tipo de ruta: confirme que el vecino IGP es estable, luego revise display mpls lsp include <prefix>/32 en busca de un LSP LDP con poco tiempo activo junto a un LSP RSVP/TE que ha sido estable por mucho tiempo — esa discrepancia apunta a la sesión LDP, no a la VPN.
- Revise display interface en el enlace por el que realmente pasa la sesión LDP inestable — una interfaz física que rebota entre up/down es la capa donde suele estar realmente este tipo de falla.
- Si la convergencia tras un reinicio de PE toma del orden de minutos en lugar de segundos, revise si los PE redundantes que anuncian el mismo prefijo de CE comparten un Route Distinguisher idéntico — si es así, sus rutas VPNv4 se tratan como una sola ruta BGP en lugar de dos rutas de costo igual independientes, y el failover debe esperar a que el RR confirme que la sesión del PE antiguo realmente desapareció mediante una convergencia IGP completa.
<DeviceA> display mpls lsp include 1.1.1.1 32
LSP Information: RSVP LSP ... TimeStamp: 1825411sec // stable for a long time
LSP Information: LDP LSP ... TimeStamp: 10sec // this one keeps resetting
[PE3] ip vpn-instance vpn-access
[PE3-vpn-instance-vpn-access] route-distinguisher 22:1
// distinct RD per PE turns the equal-cost VPNv4 paths into two independently comparable routes6 causas que aparecen una y otra vez
Una vez que las etapas anteriores le han indicado dónde está el problema, estas seis causas explican la mayor parte de lo que realmente está mal.
1. Dos VPN comparten un RT a propósito, pero también una dirección IP por accidente
SÍNTOMAUna VPN con RT compartido deliberadamente, configurada para que dos instancias VPN puedan alcanzarse, solo funciona en una dirección.
CAUSAEl cruce local importa la ruta equivocada cuando dos instancias VPN en el mismo PE terminan vinculando sus interfaces a direcciones IP idénticas. El PE prefiere la ruta local directa sobre la ruta BGP importada durante el cruce de rutas local, así que la VPN cruzada nunca se resuelve realmente en esa dirección, aunque los RT coincidan correctamente.
SOLUCIÓNDé a cada instancia VPN un direccionamiento IP local distinto, luego reconstruya el par BGP afectado una vez que cambie el direccionamiento.
<PE1> display ip interface brief
10GE0/0/1 10.1.1.2/30 up up VPN-A
10GE0/0/2 10.1.1.2/30 up up VPN-B // duplicate -- rebind to a distinct subnet2. RR configurado con policy vpn-target pero sin una instancia VPN local coincidente
SÍNTOMADos PE detrás de un par redundante de reflectores de rutas no ven en absoluto las rutas VPNv4 el uno del otro, sin nada evidentemente mal en ninguno de los dos PE.
CAUSApolicy vpn-target bajo ipv4-family vpnv4 le indica al RR que aplique filtrado VPN-Target a lo que acepta. Si el propio RR no tiene una instancia VPN configurada para ese RT, no acepta silenciosamente nada que lleve ese Import Target — una función de filtrado que solo tiene sentido en un PE, aplicada por error a un rol de reflector de rutas puro.
SOLUCIÓNO bien elimine policy vpn-target en el RR para que acepte y refleje todo (el enfoque común para un RR puro), o añada una instancia VPN coincidente en el RR únicamente para darle el RT con el que comparar.
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo policy vpn-target3. Option-B entre dominios: un Loopback de ASBR que no es /32
SÍNTOMAUna ruta VPNv4 Option-B funciona en una dirección a través del límite de dominio pero no en la otra.
CAUSALDP solo asigna etiquetas para rutas de host /32 por defecto. Si el Loopback de un ASBR intermedio está configurado con una máscara más corta, LDP no puede construir una etiqueta para ese FEC, el LSP hacia él nunca se completa, y la ruta VPNv4 por lo demás presente del PE remoto nunca se instala — porque su LSP subyacente no es válido, no porque algo esté mal en la configuración VPN.
SOLUCIÓNCorrija la máscara del Loopback a /32 en el ASBR afectado y ejecute reset mpls ldp para forzar la resignalización.
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldp4. Un extcommunity-filter residual bloquea selectivamente la reflexión de un RT
SÍNTOMAEl reflector de rutas acepta una ruta VPNv4 de un PE, pero solo algunos de los otros clientes del RR llegan a aprenderla.
CAUSAUn ip extcommunity-filter referenciado por rr-filter bajo la vista BGP-VPNv4 del RR deniega ese RT específico — a menudo un resto de una política de reflexión anterior más restrictiva que nunca se revisó al añadir nuevas instancias VPN a la red.
SOLUCIÓNAñada una entrada permit para el RT (o elimine por completo la referencia del filtro) y vuelva a aplicar rr-filter.
<RR> display ip extcommunity-filter
index: 10 deny rt : 100:1
[RR] ip extcommunity-filter 1 permit rt 100:1
[RR-bgp-af-vpnv4] undo rr-filter
[RR-bgp-af-vpnv4] rr-filter 15. Una ruta inestable que en realidad es un enlace físico bajo la capa LDP/IGP
SÍNTOMAUn prefijo VPN específico se vuelve inestable continuamente aunque la configuración VPN, el RT y la sesión BGP resulten todos limpios.
CAUSALa ruta privada usa un LSP cuyo vecino IGP y túnel TE son estables, pero la sesión LDP subyacente rebota porque la interfaz física sobre la que corre flapea repetidamente entre up y down — algo que ninguna cantidad de resolución de problemas en la capa VPN hará salir a la luz.
SOLUCIÓNBaje desde el tipo de ruta — BGP, luego IGP, luego LDP/RSVP, luego la interfaz física — en lugar de suponer que la falla está en la capa donde el síntoma es visible; una vez encontrada, trátela como una falla física u óptica, no como una de VPN.
<DeviceA> display mpls ldp session
// LDP session itself shows as bouncing
<DeviceA> display interface 10GE0/0/0
Last physical up time : 2010-05-20 21:33:42
Last physical down time : 2010-05-20 21:31:58
// physical layer is where the flap actually originates6. Rutas VPNv4 de costo igual comparten el mismo RD, así que el failover espera al IGP
SÍNTOMATras un reinicio de PE, los PE aguas abajo tardan aproximadamente dos minutos en reaprender el subred de negocio de un CE a través del PE sobreviviente, en lugar de conmutar de inmediato.
CAUSACuando los PE redundantes que anuncian el mismo prefijo de CE usan todos un Route Distinguisher idéntico, sus rutas VPNv4 se tratan como la misma ruta BGP en lugar de dos rutas de costo igual independientes. Los reflectores de rutas solo reenvían una nueva ruta una vez que han confirmado que la sesión IGP/BGP del PE antiguo realmente desapareció, así que la convergencia de MPLS VPN va detrás de la convergencia IGP completa.
SOLUCIÓNAsigne a cada PE un RD distinto para la instancia VPN para que ambas rutas existan como rutas independientes y comparables — una activa, otra inmediatamente disponible — o implemente VPN FRR.
[PE3] ip vpn-instance vpn-access
[PE3-vpn-instance-vpn-access] route-distinguisher 22:1
// PE4 keeps its own distinct RD -- PE5/PE6 now hold two independent, comparable pathsDiseños de soluciones relacionadas
Cinco preguntas que surgen constantemente
Sacadas directamente del campo — las que vale la pena tener respondidas de antemano.
BGP parece Established y LDP se ve bien, pero un prefijo VPN específico sigue sin llegar al PE remoto — ¿cuál es la forma más rápida de encontrar dónde está realmente atascado?
Recorra la cadena en orden en lugar de adivinar: ¿la ruta es válida y óptima en display bgp vpnv4 vpn-instance routing-table (si no, probablemente el siguiente salto BGP no sea alcanzable); si es válida pero no se muestra como enviada, revise la política de salida en el emisor y la política de entrada en el receptor; si ya se envió y se recibió, revise si itera hacia un túnel real (Relay Tunnel Out-Interface) y realmente obtuvo una etiqueta privada (Label information); si todo eso está limpio, la coincidencia Export/Import del RT es el siguiente lugar, y el más común, donde muere silenciosamente.
La ruta cruza bien PE1→PE2 pero no PE2→PE1 — ¿cómo puede una falla ser unidireccional?
Esto casi siempre significa que las dos direcciones en realidad usan mecanismos subyacentes diferentes que resultan parecer simétricos en la configuración — una ruta Option-B entre dominios donde solo el Loopback de un ASBR tiene la máscara incorrecta, o una sesión IBGP donde solo a un lado le falta peer connect-interface loopback para la interfaz de origen de la sesión. Revise la ruta de cada dirección de forma independiente en lugar de suponer una causa raíz compartida.
El Export y el Import VPN Target parecen correctos en ambos PE, pero las rutas todavía no cruzan — ¿qué me falta?
Confirme que la coincidencia de RT no se está filtrando en algún punto entre los dos PE en lugar de en cualquiera de los PE mismos — lo más frecuente es un reflector de rutas con policy vpn-target habilitado pero sin instancia VPN local para ese RT, o un extcommunity-filter residual ligado a rr-filter que es anterior a la VPN actual. Ambos descartan silenciosamente la ruta sin nada visible en ninguno de los PE.
Una ruta VPN se vuelve inestable continuamente aunque nadie tocó la configuración VPN — ¿dónde debo mirar realmente?
Por debajo de la capa VPN. Confirme que el vecino IGP y el túnel (LDP o RSVP-TE) que llevan esa ruta son en sí estables antes de suponer que algo está mal con BGP o la instancia VPN — un LSP con poco tiempo activo casi siempre se remonta a una interfaz física inestable o un problema óptico una capa más abajo.
La convergencia tras una falla de PE toma minutos en lugar de segundos — ¿es normal en MPLS VPN?
No, si se supone que los PE redundantes ofrecen dos rutas de costo igual independientes. Revise si están usando el mismo Route Distinguisher para la instancia VPN — si es así, sus rutas VPNv4 son indistinguibles como una sola ruta BGP, y el failover debe esperar la convergencia IGP completa antes de que una nueva ruta siquiera sea visible. RD distintos por PE, o VPN FRR, convierten eso en una conmutación casi instantánea.
Límites honestos de esta nota
Esta nota se construye en torno al modelo de clasificación de fallas BGP/MPLS L3VPN del router Huawei serie AR y sus comandos display bgp vpnv4 / display ip vpn-instance / display mpls lsp, además de los casos de campo detrás de ellos. Si su PE es de otro fabricante, los comandos exactos cambian, pero la lógica subyacente — coincidencia Export/Import de RT, iteración de túnel, filtrado por reflector de rutas, convergencia impulsada por RD — se traslada directamente. No cubre en profundidad las superposiciones VPN basadas en EVPN, las variantes inter-AS Option-A/Option-C, ni los detalles de VPN IPv6 (L3VPNv6) más allá de lo señalado en el texto.
¿La ruta no cruza, o la convergencia es demasiado lenta?
Díganos de qué PE falta la ruta, o cuánto tiempo está tomando realmente el failover, y le ayudaremos a interpretar la salida de display bgp vpnv4.