Falhas PE-CE de MPLS L3VPN: incompatibilidades de RT, vazamentos de rota e convergência lenta
Uma rota de VPN que não chega ao PE remoto, duas VPNs que vazam uma para a outra, ou uma rede que leva dois minutos para reconvergir depois de uma reinicialização de PE — a maioria dos chamados de L3VPN se encaixa em algumas formas repetíveis assim que a própria sessão BGP PE-PE é confirmada saudável. Esta é a ordem de diagnóstico que encontra a falha mais rápido, os comandos display exatos para cada etapa, e as causas que respondem pela maioria desses casos.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Por que isso começa com uma sessão BGP funcional, não com a configuração de VPN
Metade do que parece uma falha de L3VPN é, na verdade, uma falha de BGP ou LDP disfarçada de VPN.
Se o próprio IBGP PE-PE não chegar a Established, isso é um problema da árvore de falhas de BGP antes de ser um problema de L3VPN — veja primeiro O vizinho BGP não se estabelece e as rotas ficam instáveis? Uma lista de verificação completa primeiro. Depois de confirmada a saúde dessa sessão, as falhas de L3VPN se dividem em algumas formas repetíveis: uma rota que nunca chega ao PE remoto (incompatibilidades locais de VPN Target, colisões de IP entre instâncias de VPN, rótulos ausentes, problemas de relé entre domínios, ou um refletor de rotas que a filtra silenciosamente), e uma rota que chega bem mas algo ainda não está certo (instabilidade de camada física sob uma VPN, de resto, correta, ou convergência que leva minutos em vez de segundos depois de uma falha de PE).
A seguir está a árvore de falhas na qual isto se baseia, as verificações de cada etapa com os comandos exatos, as causas que aparecem repetidamente depois das primeiras verificações, e algumas respostas de perguntas frequentes tiradas de casos reais de campo.
Leia a árvore de falhas antes de mexer em qualquer configuração
As falhas de L3VPN se dividem em exatamente duas formas: a rota nunca chega ao PE remoto, ou chega e algo ainda não está certo.
Colocar primeiro o sintoma nesta árvore evita muito retrabalho depois — ela indica qual das seções abaixo realmente se aplica ao que você está vendo.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Depois de saber qual ramo se aplica, quase toda verificação abaixo está a um único comando display de uma causa confirmada — a armadilha é resolver problemas na camada de VPN quando a falha real está uma camada abaixo, no IGP, no LDP ou no enlace físico subjacente.
Percorrendo cada etapa
Quatro etapas, quatro conjuntos diferentes de coisas a verificar — e o comando que diz exatamente onde uma rota deixa de estar visível.
Etapa 0 — Confirmar se a rota realmente saiu do CE
Antes de mexer na configuração de RT ou rótulos, confirme se a rota sequer está presente na tabela de roteamento de VPN local do PE próximo.
- Faça primeiro ping de CE para CE. Se funcionar, o caminho CE a CE está bem e a falha está entre o host do usuário de VPN e o CE — verifique essa rota separadamente.
- Se falhar, execute display ip routing-table nos dois CEs para ver se algum deles sequer tem uma rota para o outro.
- No PE, execute display ip routing-table vpn-instance vpn-instance-name para confirmar se a rota do CE realmente chegou à tabela de roteamento de VPN do PE — se não estiver lá, a falha está de fato na sessão CE-PE ou em sua política de rotas, não em nada a jusante.
<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 — Correspondência de RT / VPN Target e cruzamento local
A rota está na tabela de VPN local, a sessão BGP PE-PE está Established, mas o PE remoto ainda não a tem — verifique a correspondência de RT em si, e uma local menos óbvia.
- Execute display ip vpn-instance verbose nos dois PEs e confirme se o Export VPN Target deste PE corresponde ao Import VPN Target do PE remoto, e vice-versa.
- Se duas VPNs compartilham deliberadamente o mesmo RT para alcançabilidade cruzada controlada entre VPNs, confirme também que as duas instâncias de VPN não estão vinculadas a endereços IP locais idênticos no mesmo PE — o cruzamento de rotas local prefere silenciosamente a rota local direta em vez da rota BGP importada quando o endereçamento colide, e a VPN cruzada só funciona em uma direção.
<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 — Rota presente mas não válida/melhor, ou não consegue alcançar um túnel
A rota aparece na tabela BGP VPNv4 do PE remoto, mas nunca é instalada — o motivo quase sempre é o próximo salto, o túnel, ou um rótulo ausente.
- Execute display bgp vpnv4 vpn-instance vpn-instance-name routing-table <prefix> e confirme se a rota aparece como valid e best — se não, verifique se a tabela de roteamento IP sequer tem uma rota para o próximo salto do BGP (Original nexthop).
- Execute display bgp vpnv4 all routing-table <prefix> e procure um campo Relay Tunnel Out-Interface (confirma que a rota realmente pode iterar para um LSP) e um campo Label information (confirma que um rótulo privado foi alocado) — uma rota pode ser válida e a melhor e mesmo assim nunca ser usada se qualquer um dos dois estiver ausente.
- Para um design Option-B entre domínios em particular, verifique a máscara do Loopback de cada ASBR intermediário ao longo do caminho — o LDP só aloca rótulos para rotas de host /32 por padrão, então um Loopback configurado com qualquer outra máscara quebra silenciosamente a alocação de rótulo para aquele FEC, e o LSP em direção a ele nunca se completa mesmo que o próprio BGP mostre a rota 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 — Um refletor de rota a descarta silenciosamente
A configuração dos dois PEs parece correta isoladamente — a filtragem está ocorrendo no RR entre eles.
- No RR, verifique display current-configuration configuration bgp em ipv4-family vpnv4 procurando por policy vpn-target — isso habilita a filtragem de VPN-Target no próprio RR, e se o RR não tiver uma instância de VPN local configurada para aquele RT, ele descarta silenciosamente toda rota que o carregue.
- Verifique display ip extcommunity-filter em busca de uma regra deny que corresponda ao RT desta rota, referenciada por rr-filter na visão BGP-VPNv4 do RR — muitas vezes um resquício de uma política de reflexão anterior mais restrita.
<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 1Qualidade: rotas oscilantes e convergência lenta
A configuração de VPN está correta — a falha está uma camada abaixo, ou em como o failover realmente acontece.
- Se um prefixo de VPN específico oscilar continuamente com a configuração de VPN, RT e BGP todas limpas, desça a partir do tipo de rota: confirme se o vizinho IGP está estável, depois verifique display mpls lsp include <prefix>/32 em busca de um LSP LDP com pouco tempo ativo ao lado de um LSP RSVP/TE que está estável há muito tempo — essa incompatibilidade aponta para a sessão LDP, não para a VPN.
- Verifique display interface no enlace pelo qual a sessão LDP instável realmente passa — uma interface física oscilando entre up/down é a camada onde essa classe de falha geralmente realmente reside.
- Se a convergência após uma reinicialização de PE levar da ordem de minutos em vez de segundos, verifique se os PEs redundantes que anunciam o mesmo prefixo de CE compartilham um Route Distinguisher idêntico — se sim, suas rotas VPNv4 são tratadas como um único caminho BGP em vez de dois caminhos de custo igual independentes, e o failover precisa esperar o RR confirmar que a sessão do PE antigo realmente desapareceu por meio de uma convergência completa do IGP.
<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 aparecem repetidamente
Depois que as etapas acima indicarem onde está o problema, essas seis causas explicam a maior parte do que realmente está errado.
1. Duas VPNs compartilham um RT de propósito, mas também compartilham um endereço IP por acidente
SINTOMAUma VPN com RT compartilhado deliberadamente, configurada para que duas instâncias de VPN possam se alcançar, só funciona em uma direção.
CAUSAO cruzamento local importa a rota errada quando duas instâncias de VPN no mesmo PE acabam vinculando suas interfaces a endereços IP idênticos. O PE prefere a rota local direta em vez da rota BGP importada durante o cruzamento de rotas local, então a VPN cruzada nunca se resolve de fato naquela direção, mesmo que os RTs coincidam corretamente.
SOLUÇÃODê a cada instância de VPN um endereçamento IP local distinto, depois reconstrua o peer BGP afetado assim que o endereçamento mudar.
<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 com policy vpn-target mas sem instância de VPN local correspondente
SINTOMADois PEs atrás de um par redundante de refletores de rota não conseguem ver as rotas VPNv4 um do outro, sem nada visivelmente errado em nenhum dos PEs.
CAUSApolicy vpn-target em ipv4-family vpnv4 diz ao RR para aplicar filtragem de VPN-Target ao que ele aceita. Se o próprio RR não tiver uma instância de VPN configurada para aquele RT, ele silenciosamente não aceita nada que carregue aquele Import Target — um recurso de filtragem que só faz sentido em um PE, aplicado indevidamente e sem perceber a um papel de refletor de rota puro.
SOLUÇÃOOu remova policy vpn-target no RR para que ele aceite e reflita tudo (a abordagem comum para um RR puro), ou adicione uma instância de VPN correspondente no RR apenas para dar a ele o RT para comparar.
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo policy vpn-target3. Option-B entre domínios: um Loopback de ASBR que não é /32
SINTOMAUma rota VPNv4 Option-B funciona em uma direção através da fronteira de domínio, mas não na outra.
CAUSAO LDP só aloca rótulos para rotas de host /32 por padrão. Se o Loopback de um ASBR intermediário estiver configurado com uma máscara mais curta, o LDP não consegue construir um rótulo para aquele FEC, o LSP em direção a ele nunca se completa, e a rota VPNv4 do PE remoto, de resto presente, nunca é instalada — porque seu LSP subjacente não é válido, não porque haja algo errado na configuração de VPN.
SOLUÇÃOCorrija a máscara do Loopback para /32 no ASBR afetado e execute reset mpls ldp para forçar a re-sinalização.
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldp4. Um extcommunity-filter esquecido bloqueia seletivamente a reflexão de um RT
SINTOMAO refletor de rota aceita uma rota VPNv4 de um PE, mas apenas alguns dos outros clientes do RR chegam a aprendê-la.
CAUSAUm ip extcommunity-filter referenciado por rr-filter na visão BGP-VPNv4 do RR nega esse RT específico — muitas vezes um resquício de uma política de reflexão anterior mais restrita que nunca foi revisada quando novas instâncias de VPN foram adicionadas à rede.
SOLUÇÃOAdicione uma entrada permit para o RT (ou remova totalmente a referência ao filtro) e reaplique 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. Uma rota oscilante que na verdade é um enlace físico sob a camada LDP/IGP
SINTOMAUm prefixo de VPN específico oscila continuamente mesmo que a configuração de VPN, o RT e a sessão BGP estejam todos limpos.
CAUSAA rota privada usa um LSP cujo vizinho IGP e túnel TE são estáveis, mas a sessão LDP por baixo está oscilando porque a interface física sobre a qual ela roda está repetidamente alternando entre up e down — algo que nenhuma quantidade de solução de problemas na camada de VPN jamais revelará.
SOLUÇÃODesça a partir do tipo de rota — BGP, depois IGP, depois LDP/RSVP, depois a interface física — em vez de supor que a falha está na camada onde o sintoma é visível; uma vez encontrada, trate-a como uma falha física ou óptica, não como uma falha 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. Caminhos VPNv4 de custo igual compartilham o mesmo RD, então o failover espera pelo IGP
SINTOMADepois de uma reinicialização de PE, os PEs a jusante levam cerca de dois minutos para reaprender a sub-rede de negócios de um CE através do PE sobrevivente, em vez de fazer failover imediatamente.
CAUSAQuando PEs redundantes que anunciam o mesmo prefixo de CE usam todos um Route Distinguisher idêntico, suas rotas VPNv4 são tratadas como o mesmo caminho BGP em vez de dois caminhos de custo igual independentes. Os refletores de rota só encaminham um novo caminho depois de confirmarem que a sessão IGP/BGP do PE antigo realmente desapareceu, então a convergência de MPLS VPN fica atrás da convergência completa do IGP.
SOLUÇÃOAtribua a cada PE um RD distinto para a instância de VPN para que ambas as rotas existam como caminhos independentes e comparáveis — um ativo, outro imediatamente disponível — ou implante 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 pathsProjetos de soluções relacionadas
Cinco perguntas que surgem constantemente
Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.
O BGP parece Established e o LDP parece bem, mas um prefixo de VPN específico ainda não chega ao PE remoto — qual é a forma mais rápida de descobrir onde ele realmente está travado?
Percorra a cadeia em ordem em vez de adivinhar: a rota é válida e a melhor em display bgp vpnv4 vpn-instance routing-table (se não, o próximo salto do BGP provavelmente não é alcançável); se válida mas não aparece como enviada, verifique a política de saída no remetente e a política de entrada no destinatário; se já foi enviada e recebida, verifique se ela itera para um túnel real (Relay Tunnel Out-Interface) e realmente obteve um rótulo privado (Label information); se tudo isso estiver limpo, a correspondência Export/Import do RT é o próximo lugar, e o mais comum, onde ela morre silenciosamente.
A rota cruza bem de PE1→PE2 mas não de PE2→PE1 — como uma falha pode ser unidirecional?
Isso quase sempre significa que as duas direções na verdade usam mecanismos subjacentes diferentes que acabam parecendo simétricos na configuração — um caminho Option-B entre domínios onde apenas o Loopback de um ASBR tem a máscara errada, ou uma sessão IBGP onde apenas um lado está sem peer connect-interface loopback para a interface de origem da sessão. Verifique o caminho de cada direção independentemente, em vez de supor uma causa raiz compartilhada.
O Export e o Import VPN Target parecem corretos nos dois PEs, mas as rotas ainda não cruzam — o que estou deixando passar?
Confirme se a correspondência de RT não está sendo filtrada em algum ponto entre os dois PEs, em vez de em qualquer um dos PEs — mais frequentemente um refletor de rota com policy vpn-target habilitado mas sem instância de VPN local para aquele RT, ou um extcommunity-filter esquecido ligado a rr-filter que é anterior à VPN atual. Ambos descartam silenciosamente a rota sem nada visível em nenhum dos PEs.
Uma rota de VPN oscila continuamente mesmo que ninguém tenha mexido na configuração de VPN — onde eu realmente devo olhar?
Abaixo da camada de VPN. Confirme se o vizinho IGP e o túnel (LDP ou RSVP-TE) que carregam aquela rota são eles mesmos estáveis antes de supor que algo está errado com o BGP ou a instância de VPN — um LSP com pouco tempo ativo quase sempre remonta a uma interface física oscilando ou um problema óptico uma camada abaixo.
A convergência depois de uma falha de PE leva minutos em vez de segundos — isso é normal para MPLS VPN?
Não, se os PEs redundantes deveriam oferecer dois caminhos de custo igual independentes. Verifique se eles estão usando o mesmo Route Distinguisher para a instância de VPN — se sim, suas rotas VPNv4 são indistinguíveis como um único caminho BGP, e o failover precisa esperar a convergência completa do IGP antes mesmo de um novo caminho ficar visível. RDs distintos por PE, ou VPN FRR, transformam isso em uma comutação quase instantânea.
Limites honestos desta nota
Esta nota é construída em torno do modelo de classificação de falhas de BGP/MPLS L3VPN do roteador Huawei da série AR e de seus comandos display bgp vpnv4 / display ip vpn-instance / display mpls lsp, além dos casos de campo por trás deles. Se o seu PE for de outro fabricante, os comandos exatos mudam, mas a lógica subjacente — correspondência Export/Import de RT, iteração de túnel, filtragem por refletor de rota, convergência orientada por RD — se aplica diretamente. Não cobre em profundidade overlays de VPN baseados em EVPN, variantes inter-AS Option-A/Option-C, ou detalhes de VPN IPv6 (L3VPNv6) além do que é observado no texto.
A rota não está cruzando, ou a convergência está muito lenta?
Diga-nos de qual PE a rota está faltando, ou quanto tempo o failover está realmente levando, e ajudaremos você a interpretar a saída de display bgp vpnv4.