Ruta ausente na VRF: local, VPNv4 ou táboa de reenvío?

Un cliente di que falta un prefixo tras un cambio de obxectivo de ruta, e a primeira captura de pantalla que envía adoita ser a táboa equivocada. Tres táboas distintas responden tres preguntas distintas: se o prefixo existe dentro da VRF, se se anunciou e importou como ruta VPNv4, e se se instalou realmente unha entrada de reenvío. Leelas fóra de orde produce conclusións seguras e erradas. Este manual leva un prefixo local e un remoto polas tres táboas, en orde, e remata cun plan de reversión para o cambio de RT que o comezou.

Nomee o prefixo e a táboa á que pertence

Anote dous prefixos antes de escribir nada. Un é local do sitio do cliente, aprendido dunha interface conectada ou dun anuncio CE. O outro é remoto, e espérase que chegue pola rede troncal do provedor. Toman camiños distintos cara á mesma VRF, e un fallo nun non di nada do outro.

Manteña clara a distinción entre os dous identificadores, porque dela vén a maior parte da confusión nestes tickets. O distinguidor de ruta forma parte do NLRI de VPNv4 e existe para facer únicos na rede troncal prefixos de cliente que doutro xeito serían idénticos. O obxectivo de ruta é unha comunidade estendida que se transporta como atributo, e é con el co que casa a política de importación e exportación. Non é un segundo nome do distinguidor e non se transporta nos paquetes do cliente.

Paso 1: demostre que o prefixo está na VRF

Comece pola vista local e despois polos RT que gobernan a importación. Se o prefixo local falta aquí, nada augas arriba pode ter a culpa:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Un prefixo que aparece como conectado ou estático está aprendido localmente, e a súa presenza non di nada sobre se se exportou. Esa é a lectura errónea máis habitual neste fluxo de traballo: unha táboa de VRF sa só é evidencia de aprendizaxe local. O lado da exportación é unha pregunta aparte, que responden a vista do veciño e o obxectivo de exportación asociado.

Revise as listas de RT da VRF mentres está aquí. Se o obxectivo de importación previsto non está na lista, todo o que hai augas abaixo é irrelevante. Se está pero difire do que exporta o PE remoto, atopou o fallo sen abrir nin unha soa captura de paquetes.

Paso 2: lea a táboa VPNv4 e os seus obxectivos

A táboa VPNv4 mostra que intercambiou realmente o plano de control. Busque o prefixo remoto baixo o distinguidor correcto e despois mire as comunidades que ten asociadas:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Unha entrada co obxectivo de ruta correcto pero sen instalación local apunta á política de importación ou á selección de ruta, non á alcanzabilidade. Unha entrada que nunca aparece na táboa VPNv4 apunta augas arriba: pode que o PE de orixe non a exportase ou que a sesión non transporte a familia de enderezos.

Hai un terceiro caso que desconcerta a xente durante os cambios. Algunhas plataformas limitan que rutas VPN solicitan ou reteñen, usando información de pertenza a obxectivos de ruta, así que a ausencia dunha NLRI remota nunha vista filtrada non é proba de que o anuncio non exista en ningún sitio. Revise a táboa sen filtrar e as rutas anunciadas do veciño antes de concluír que unha ruta se retirou globalmente.

Paso 3: confirme que se instalou e etiquetou algo

Unha entrada BGP é unha decisión, non un camiño. As táboas de reenvío dinlle se os paquetes teñen a onde ir:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Unha entrada CEF cunha adxacencia resolta e unha etiqueta de saída significa que o tráfico do plano de datos debería funcionar, e calquera síntoma restante pertence á aplicación ou ao filtrado dentro da VRF. Unha entrada CEF que mostra un seguinte salto sen resolver significa que a ruta de etiquetas está incompleta aínda que BGP pareza san, e ese é xusto o caso no que unha captura da táboa BGP enganou a unha revisión de cambio.

Compare a etiqueta que impón o PE local coa que o PE remoto espera recibir. Unha discrepancia entre as dúas vistas é un problema de asignación de etiquetas ou de sesión, e non se corrixirá editando obxectivos de ruta por moitas veces que o faga.

Reverta o cambio de RT cun alcance declarado

Se o fallo comezou cunha edición de obxectivo de ruta, desfágaa como un só paso deliberado e diga que alcance cambia. Quitar un obxectivo de importación retira a elixibilidade dentro desa VRF. Non borra o anuncio VPNv4 da rede troncal, e nalgunhas plataformas a ruta queda retida na táboa. Son resultados distintos e o efecto visible para o usuario depende de cal dos dous quere dicir.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Unha reconfiguración suave de entrada abonda cando a sesión xa almacena os prefixos; un reinicio duro dunha sesión orientada ao provedor en horario laboral é unha decisión que debe tomar outra persoa. En Junos as comprobacións equivalentes len directamente a táboa por VRF e a táboa VPN, e a reversión é un retorno no commit e non un desfacer por comando, así que capture a diferenza de configuración antes de comezar.

Remate cos mesmos tres comandos cos que comezou, na mesma orde, e rexistre a súa saída cunha marca de tempo. Un ticket que di que o RT estaba mal e que agora está ben non é reutilizable; un que mostra o prefixo presente na VRF, presente en VPNv4 e instalado en CEF é evidencia coa que a seguinte persoa pode comparar. Se só cambiaron os dous primeiros, non rematou o cambio.