Ruta que falta a la VRF: local, VPNv4 o taula de reenviament?

Un client diu que un prefix ha desaparegut després d’un canvi d’objectiu de ruta, i la primera captura de pantalla que envia sol ser la taula equivocada. Tres taules diferents responen tres preguntes diferents: si el prefix existeix dins de la VRF, si s’ha anunciat i importat com a ruta VPNv4, i si s’ha instal·lat realment una entrada de reenviament. Llegir-les fora d’ordre produeix conclusions segures i equivocades. Aquest manual porta un prefix local i un de remot per les tres taules, en ordre, i acaba amb un pla de reversió per a l’edició de RT que ho va començar.

Anomeni el prefix i la taula a què pertany

Anoti dos prefixos abans d’escriure res. Un és local del lloc del client, après d’una interfície connectada o d’un anunci CE. L’altre és remot i s’espera que arribi per la xarxa troncal del proveïdor. Segueixen camins diferents cap a la mateixa VRF, i una avaria en un no diu res de l’altre.

Mantingui clara la diferència entre els dos identificadors, perquè la major part de la confusió d’aquests tiquets ve d’aquí. El distingidor de ruta forma part de l’NLRI de VPNv4 i existeix per fer únics a la xarxa troncal prefixos de client que d’altra manera serien idèntics. L’objectiu de ruta és una comunitat estesa que es transporta com a atribut, i és amb ell que casa la política d’importació i exportació. No és un segon nom del distingidor i no es transporta en els paquets del client.

Pas 1: demostri que el prefix és a la VRF

Comenci per la vista local i després pels RT que governen la importació. Si el prefix local falta aquí, res aigües amunt no pot ser-ne la causa:

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 prefix que apareix com a connectat o estàtic és après localment, i la seva presència no diu res sobre si s’ha exportat. Aquesta és la lectura errònia més habitual en aquest flux de treball: una taula VRF sana només és evidència d’aprenentatge local. El costat d’exportació és una pregunta a part, que responen la vista del veí i l’objectiu d’exportació adjunt.

Revisi les llistes de RT de la VRF mentre és aquí. Si l’objectiu d’importació previst no és a la llista, tot el que hi ha aigües avall és irrellevant. Si hi és però difereix del que exporta el PE remot, ha trobat l’avaria sense obrir cap captura de paquets.

Pas 2: llegeixi la taula VPNv4 i els seus objectius

La taula VPNv4 mostra què ha intercanviat realment el pla de control. Busqui el prefix remot sota el distingidor correcte i després mirí les comunitats que hi té adjuntes:

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

Una entrada amb l’objectiu de ruta correcte però sense instal·lació local apunta a la política d’importació o a la selecció de ruta, no a l’abastabilitat. Una entrada que no apareix mai a la taula VPNv4 apunta aigües amunt: potser el PE d’origen no l’ha exportada o la sessió no transporta la família d’adreces.

Hi ha un tercer cas que desconcerta la gent durant els canvis. Algunes plataformes limiten quines rutes VPN sol·liciten o retenen, fent servir informació de pertinença als objectius de ruta, així que l’absència d’una NLRI remota en una vista filtrada no és prova que l’anunci no existeixi enlloc. Comprovi la taula sense filtrar i les rutes anunciades del veí abans de concloure que una ruta s’ha retirat globalment.

Pas 3: confirmi que s’ha instal·lat i etiquetat alguna cosa

Una entrada BGP és una decisió, no un camí. Les taules de reenviament li diuen si els paquets tenen on anar:

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

Una entrada CEF amb una adjacència resolta i una etiqueta de sortida vol dir que el trànsit del pla de dades hauria de funcionar, i qualsevol símptoma restant pertany a l’aplicació o al filtratge dins de la VRF. Una entrada CEF amb un salt següent no resolt vol dir que el camí d’etiquetes és incomplet tot i que BGP sembla sa, i aquest és exactament el cas en què una captura de la taula BGP ha enganyat una revisió de canvi.

Compari l’etiqueta que imposa el PE local amb la que el PE remot espera rebre. Una discrepància entre les dues vistes és un problema d’assignació d’etiquetes o de sessió, i no es corregirà editant objectius de ruta per moltes vegades que ho faci.

Reverteixi el canvi de RT amb un abast declarat

Si l’avaria va començar amb una edició d’objectiu de ruta, desfaci-la com un sol pas deliberat i digui quin abast canvia. Treure un objectiu d’importació retira l’elegibilitat dins d’aquella VRF. No esborra l’anunci VPNv4 de la xarxa troncal, i en algunes plataformes la ruta es queda retinguda a la taula. Són resultats diferents i l’efecte visible per a l’usuari depèn de quin dels dos vol dir.

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

Una reconfiguració suau d’entrada n’hi ha prou quan la sessió ja emmagatzema els prefixos; un reinici dur d’una sessió orientada al proveïdor en horari laboral és una decisió que ha de prendre algú altre. A Junos les comprovacions equivalents llegeixen directament la taula per VRF i la taula VPN, i la reversió és un retorn en el commit i no un desfer per ordre, així que capturi la diferència de configuració abans de començar.

Acabi amb les mateixes tres ordres amb què va començar, en el mateix ordre, i anoti’n la sortida amb una marca de temps. Un tiquet que diu que l’RT era incorrecte i que ara és correcte no és reutilitzable; un que mostra el prefix present a la VRF, present a VPNv4 i instal·lat a CEF és evidència amb què la persona següent pot comparar. Si només han canviat els dos primers, no ha acabat el canvi.