Rrugë që mungon në VRF: lokale, VPNv4 apo tabela e përcjelljes?

Një klient thotë se një prefiks ka humbur pas një ndryshimi të objektivit të rrugës, dhe pamja e parë e ekranit që dërgon është zakonisht tabela e gabuar. Tre tabela të ndryshme u përgjigjen tre pyetjeve të ndryshme: nëse prefiksi ekziston brenda VRF, nëse u shpall dhe u importua si rrugë VPNv4, dhe nëse u instalua vërtet një zë e përcjelljes. Leximi i tyre jashtë radhe jep përfundime të sigurta dhe të gabuara. Ky manual çon një prefiks lokal dhe një të largët nëpër të tre tabelat sipas radhës, dhe përfundon me një plan kthimi për ndryshimin e RT që e nisi.

Emërtoni prefiksin dhe tabelën të cilës i përket

Shkruani dy prefikse përpara se të shtypni çfarëdo. Njëri është lokal në vendndodhjen e klientit, i mësuar nga një ndërfaqe e lidhur ose nga një shpallje CE. Tjetri është i largët dhe pritet të vijë përmes shtyllës kurrizore të ofruesit. Ata marrin rrugë të ndryshme drejt të njëjtës VRF, dhe një defekt në njërin nuk thotë asgjë për tjetrin.

Mbajeni të qartë dallimin midis dy identifikuesve, sepse pjesa më e madhe e konfuzionit në këto tiketa vjen prej andej. Dalluesi i rrugës është pjesë e NLRI-së së VPNv4 dhe ekziston për t'i bërë unike në shtyllën kurrizore prefikset e klientëve që përndryshe do të ishin identike. Objektivi i rrugës është një bashkësi e zgjeruar që mbartet si atribut, dhe me të përputhet politika e importit dhe e eksportit. Nuk është emri i dytë i dalluesit dhe nuk mbartet në paketat e klientit.

Hapi 1: provoni se prefiksi është në VRF

Filloni me pamjen lokale, pastaj me RT-të që drejtojnë importin. Nëse prefiksi lokal mungon këtu, asgjë më lart nuk mund të jetë fajtore:

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

Një prefiks që shfaqet si i lidhur ose statik është mësuar lokalisht, dhe prania e tij nuk thotë asgjë nëse u eksportua. Kjo është lexsimi i gabuar më i zakonshëm në këtë rrjedhë pune: një tabelë VRF e shëndoshë është provë vetëm për mësimin lokal. Ana e eksportit është një pyetje më vete, së cilës i përgjigjen pamja e fqinjit dhe objektivi i eksportit i bashkangjitur.

Kontrolloni listat e RT në VRF ndërsa jeni këtu. Nëse objektivi i synuar i importit nuk është në listë, çdo gjë poshtë është e parëndësishme. Nëse është aty por ndryshon nga ajo që eksporton PE i largët, e keni gjetur defektin pa hapur asnjë kapje pakete.

Hapi 2: lexoni tabelën VPNv4 dhe objektivat e saj

Tabela VPNv4 tregon çfarë shkëmbeu vërtet rrafshi i kontrollit. Kërkoni prefiksin e largët nën dalluesin e saktë, pastaj shikoni bashkësitë që i janë bashkangjitur:

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

Një zë me objektivin e saktë të rrugës por pa instalim lokal tregon politikën e importit ose zgjedhjen e rrugës, jo arritshmërinë. Një zë që nuk shfaqet fare në tabelën VPNv4 tregon lart: PE origjinal mund të mos e ketë eksportuar, ose sesioni nuk mbart familjen e adresave.

Ka një rast të tretë që i huton njerëzit gjatë ndryshimeve. Disa platforma kufizojnë cilat rrugë VPN kërkojnë ose mbajnë, duke përdorur informacionin e anëtarësimit në objektivat e rrugës, prandaj mungesa e një NLRI të largët në një pamje të filtruar nuk është provë se shpallja nuk ekziston askund. Kontrolloni tabelën e pafiltruar dhe rrugët e shpallura të fqinjit përpara se të përfundoni se një rrugë u tërhoq globalisht.

Hapi 3: konfirmoni se diçka u instalua dhe u etiketua

Një zë BGP është vendim, jo shteg. Tabelat e përcjelljes thonë nëse paketat kanë ku të shkojnë:

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

Një zë CEF me afërsi të zgjidhur dhe një etiketë dalëse do të thotë që trafiku i rrafshit të dhënave duhet të funksionojë, dhe çdo simptomë e mbetur i përket aplikacionit ose filtrimit brenda VRF. Një zë CEF që tregon një hap tjetër të pazgjidhur do të thotë që shtegu i etiketës është i paplotë edhe pse BGP duket i shëndoshë, dhe pikërisht ky është rasti kur një pamje e tabelës BGP ka mashtruar një rishikim ndryshimi.

Krahasoni etiketën që imponon PE lokal me atë që PE i largët pret të marrë. Një mospërputhje midis dy pamjeve është problem i ndarjes së etiketave ose i sesionit, dhe nuk do të rregullohet duke ndryshuar objektivat e rrugës, sado herë ta bëni.

Ktheni ndryshimin e RT me një shtrirje të deklaruar

Nëse defekti filloi me një ndryshim të objektivit të rrugës, anulojeni atë si një hap të vetëm të qëllimshëm dhe thoni çfarë shtrirje po ndryshoni. Heqja e një objektivi importi tërheq përsëri eligjibilitetin brenda asaj VRF. Nuk e fshin shpalljen VPNv4 nga shtylla kurrizore, dhe në disa platforma rruga mbetet e mbajtur në tabelë. Këto janë rezultate të ndryshme dhe efekti i dukshëm për përdoruesin varet nga cili prej tyre nënkuptohet.

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

Një rikonfigurim i butë hyrës mjafton kur sesioni i ruan tashmë prefikset; një rivendosje e fortë e një sesioni të kthyer nga ofruesi gjatë orarit të punës është një vendim që duhet ta marrë dikush tjetër. Në Junos kontrollet ekuivalente lexojnë drejtpërdrejt tabelën për çdo VRF dhe tabelën VPN, dhe kthimi është një rikthim në commit dhe jo një anulim për çdo komandë, prandaj regjistroni diferencën e konfigurimit përpara se të filloni.

Përfundoni me të njëjtat tre komanda me të cilat filluat, në të njëjtën radhë, dhe regjistroni daljen e tyre me një vulë kohe. Një tiketë që thotë se RT ishte i gabuar dhe tani është i saktë nuk ripërdoret; ajo që tregon prefiksin në VRF, në VPNv4 dhe të instaluar në CEF është provë me të cilën personi tjetër mund të krahasojë. Nëse ndryshuan vetëm dy të parët, nuk e keni përfunduar ndryshimin.