Mankanta vojo en VRF: loka, VPNv4 aŭ plusenda tabelo?

Kliento diras, ke prefikso mankas post ŝanĝo de voja celo, kaj la unua ekrankopio, kiun ili sendas, estas kutime la malĝusta tabelo. Tri malsamaj tabeloj respondas tri malsamajn demandojn: ĉu la prefikso ekzistas ene de la VRF, ĉu ĝi estis anoncita kaj importita kiel VPNv4-vojo, kaj ĉu plusenda ero estis efektive instalita. Legi ilin malĝustorde produktas memfidajn kaj malĝustajn konkludojn. Ĉi tiu gvidlibro kondukas unu lokan kaj unu malproksiman prefikson tra ĉiuj tri tabeloj laŭ ordo kaj finiĝas per restariga plano por la RT-redakto, kiu ĝin kaŭzis.

Nomu la prefikson kaj la tabelon, al kiu ĝi apartenas

Skribu du prefiksojn antaŭ ol entajpi ion ajn. Unu estas loka ĉe la klienta ejo, lernita de konektita interfaco aŭ de CE-anonco. La alia estas malproksima kaj atendiĝas alveni tra la dorsa reto de la provizanto. Ili prenas malsamajn vojojn en la saman VRF, kaj paneo en unu diras nenion pri la alia.

Tenu klara la distingon inter la du identigiloj, ĉar el ĝi venas la plej granda parto de la konfuzo en ĉi tiuj biletoj. La voja distingilo estas parto de la VPNv4-NLRI kaj ekzistas por igi alikaze identajn klientajn prefiksojn unikaj tra la dorsa reto. La voja celo estas etendita komunumo portata kiel atributo, kaj ĝuste al ĝi kongruas la importa kaj eksporta politiko. Ĝi ne estas dua nomo por la distingilo kaj ĝi ne estas portata en la pakaĵoj de la kliento.

Paŝo 1: pruvu, ke la prefikso estas en la VRF

Komencu per la loka vido, poste per la RT-oj, kiuj regas importadon. Se la loka prefikso mankas ĉi tie, nenio pli supre povas kulpi:

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

Prefikso, kiu aperas kiel konektita aŭ statika, estas loke lernita, kaj ĝia ĉeesto diras nenion pri tio, ĉu ĝi estis eksportita. Tio estas la plej ofta malĝusta legado en ĉi tiu laborfluo: sana VRF-tabelo estas pruvo nur pri loka lernado. La eksporta flanko estas aparta demando, kiun respondas la najbara vido kaj la alligita eksporta celo.

Kontrolu la RT-listojn sur la VRF dum vi estas ĉi tie. Se la celata importa celo ne estas en la listo, ĉio malsupre estas senrilata. Se ĝi estas, sed malsamas de tio, kion eksportas la malproksima PE, vi trovis la paneon sen malfermi eĉ unu pakaĵan kaptaĵon.

Paŝo 2: legu la VPNv4-tabelon kaj ĝiajn celojn

La VPNv4-tabelo montras, kion la rega ebeno efektive interŝanĝis. Serĉu la malproksiman prefikson sub la ĝusta distingilo, poste rigardu la komunumojn alligitajn al ĝi:

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

Ero kun la ĝusta voja celo sed sen loka instalaĵo indikas la importan politikon aŭ la vojan elekton, ne la atingeblon. Ero, kiu tute ne aperas en la VPNv4-tabelo, indikas supren: la origina PE eble ne eksportis ĝin, aŭ la sesio eble ne portas la adresan familion.

Estas tria kazo, kiu konfuzas homojn dum ŝanĝoj. Iuj platformoj limigas, kiujn VPN-vojojn ili petas aŭ retenas, uzante informojn pri membreco en vojaj celoj, do la manko de malproksima NLRI en unu filtrita vido ne estas pruvo, ke la anonco ne ekzistas ie ajn. Kontrolu la nefiltritan tabelon kaj la anoncitajn vojojn de la najbaro antaŭ ol konkludi, ke vojo estis tutmonde retirita.

Paŝo 3: konfirmu, ke io estis instalita kaj etikedita

BGP-ero estas decido, ne vojo. La plusendaj tabeloj diras al vi, ĉu la pakaĵoj havas kien iri:

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

CEF-ero kun solvita apudeco kaj elira etikedo signifas, ke trafiko de la datuma ebeno devus funkcii, kaj ĉiu restanta simptomo apartenas al la aplikaĵo aŭ al filtrado ene de la VRF. CEF-ero montranta nesolvitan sekvan salton signifas, ke la etikeda vojo estas nekompleta kvankam BGP aspektas sana, kaj ĝuste tio estas la kazo, en kiu ekrankopio de la BGP-tabelo trompis revizion de ŝanĝo.

Komparu la etikedon, kiun trudas la loka PE, kun tiu, kiun la malproksima PE atendas ricevi. Malkongruo inter la du vidoj estas problemo de etikeda atribuo aŭ de sesio, kaj ĝi ne estos riparita per redaktado de vojaj celoj, kiom ajn da fojoj vi tion faros.

Restarigu la RT-ŝanĝon kun deklarita amplekso

Se la paneo komenciĝis per redakto de voja celo, malfaru ĝin kiel unu intencan paŝon kaj diru, kiun amplekson vi ŝanĝas. Forigi importan celon retiras taŭgecon ene de tiu VRF. Ĝi ne forigas la VPNv4-anoncon el la dorsa reto, kaj sur iuj platformoj la vojo restas retenita en la tabelo. Tiuj estas malsamaj rezultoj kaj la uzanto-videbla efiko dependas de tio, kiun vi celas.

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

Mola enira rekonfiguro sufiĉas, kiam la sesio jam konservas la prefiksojn; malmola restarigo de provizanto-direktita sesio dum labortempo estas decido, kiun devus fari iu alia. En Junos la ekvivalentaj kontroloj legas la VRF-tabelon kaj la VPN-tabelon rekte, kaj la restarigo estas reveno ĉe commit anstataŭ malfaro po komando, do kaptu la konfiguran diferencon antaŭ ol komenci.

Finu per la samaj tri komandoj, per kiuj vi komencis, en la sama ordo, kaj registru ilian eligon kun tempomarko. Bileto, kiu diras, ke la RT estis malĝusta kaj nun ĝi estas ĝusta, ne estas reuzebla; tiu, kiu montras la prefikson en la VRF, en VPNv4 kaj instalita en CEF, estas pruvo, kun kiu la sekva persono povas kompari. Se nur la unuaj du ŝanĝiĝis, vi ne finis la ŝanĝon.