Dy routera klienti, një palë kuti provider edge dhe një ping që vdes pa mesazh gabimi. Në një laborator të vogël MPLS L3VPN, defekti pothuajse gjithmonë qëndron në një nga pesë pikat e kontrollit, dhe secila prej tyre ka një komandë që tregon ose se varësia funksionon ose se mungon. Gabimi është të rinisni BGP sa herë që ping dështon në vend që të provoni varësitë sipas radhës. Nëse hidheni direkt në konfigurimin VRF, mund të shpenzoni një orë për një problem që filloi me një hop të ardhshëm të pazgjidhur dy pajisje më tutje.

Punojeni listën nga poshtë lart. Një pikë kontrolli që kalon mbetet e kaluar, dhe dështimi i parë është ai që ia vlen të debugohet.

Pika e kontrollit një: PE-të arrijnë njëri-tjetrin

Secili PE ka nevojë për një rrugë drejt loopback-ut të PE-së tjetër, dhe ajo rrugë duhet të zgjidhet përmes diçkaje reale. Një interior gateway protocol është rruga e zakonshme, por një rrugë statike funksionon gjithashtu për sa kohë kërkimi rekurziv përfundon në një adjacency të gjallë. Në pajisje të stilit IOS, show ip route 10.0.0.2 i ndjekur nga show ip cef 10.0.0.2 tregon nëse prefiksi ekziston dhe nëse pas tij ka një adjacency të zgjidhur. Një rrugë në tabelë pa adjacency pas saj nuk është arritshmëri.

Kontrolloni të dy drejtimet. Kostot asimetrike të IGP-së, një passive interface në anën e gabuar ose një distribute list që filtron loopback-un prishin secila vetëm një drejtim, dhe një drejtim mjafton për të vrarë sesionin. Nëse loopback-ët bëjnë ping por sesioni BGP qëndron në Active, shikoni update source para se të prekni ndonjë gjë tjetër.

Pika e kontrollit dy: ekziston një rrugë etiketash

Një rrugë IP drejt loopback-ut të largët nuk provon se transporti do të vendosë një etiketë. Në një projekt LDP, konfirmoni që loopback-u i largët ka një lidhje lokale dhe një të largët, dhe që etiketa dalëse shfaqet në tabelën forwarding. show mpls ldp bindings 10.0.0.2 32 tregon çiftet e etiketave, dhe show mpls forwarding-table 10.0.0.2 tregon çfarë do të vendosë vërtet line card-i. Kur komanda e dytë nuk tregon asnjë etiketë ose bie përsëri në IP, transporti nuk e mbart trafikun VPN siç supozon projekti.

Dallimi vjen nga mënyra se si MPLS ndan forwarding state nga prefikset e destinacionit, modeli i përshkruar në RFC 3031. Nëse laboratori juaj përdor RSVP-TE ose etiketa ngjitur me BGP në vend të LDP, kontrolloni gjendjen e vetë atij mekanizmi; supozimi se LDP shpërndan çdo etiketë të shtresës së poshtme është një mënyrë e zakonshme për të ndjekur një bug fantazmë. Një rrugë etiketash e thyer zakonisht shfaqet më vonë si një rrugë VPN e pranishme por e papërdorshme.

Pika e kontrollit tre: rruga VPN mbërriti e paprekur

Shikoni rrugën VPNv4 ose VPNv6 të prefiksit të saktë të klientit, jo përmbledhjen e sesionit. show bgp vpnv4 unicast all 10.10.1.0/24 duhet të tregojë route distinguisher-in, next hop-in e vendosur në loopback-un e PE-së së largët dhe një etiketë. Nëse prefiksi mungon, politika e eksportit në PE-në burimore ose politika e importit në PE-në pritëse është i dyshuari i parë, dhe route target-at janë fajtori i zakonshëm.

Lexoni kontrollin e route target-it ndaras nga pritja e BGP-së. Një rrugë mund të mbërrijë me next hop-in e duhur dhe prapëseprapë të mos ulet në VRF sepse importtarget nuk përputhet. Në PE-në pritëse, show ip route vrf CUSTOMER 10.10.1.0 është testi që ka rëndësi; tabela BGP provon vetëm se rruga kaloi planin e kontrollit.

Pika e kontrollit katër: interface-i është në VRF

Një përkufizim VRF me route distinguisher dhe route target-a nuk lëviz asnjë interface brenda tij. Interface-i nga ana e CE ka nevojë për caktimin VRF, dhe show ip vrf interfaces ose show ip interface brief duhet ta listojë nën instancën e duhur. Kjo është pika e kontrollit ku një konfigurim i kopjuar gabon më shpesh, sepse blloku VRF duket i plotë ndërsa interface-i ende qëndron në tabelën globale.

Pastaj konfirmoni që PE-ja ka mësuar prefiksin lokal të klientit në atë VRF, dhe që CE-ja ka një rrugë kthimi përmes lidhjes. Një default statike në CE që tregon drejt PE-së mjafton për një laborator, me kusht që VRF-ja e PE-së të ketë një rrugë drejt LAN-it të CE-së. Nëse mungon njëra nga dy gjysmat, ping-u dështon para se të vendoset ndonjë etiketë.

Pika e kontrollit pesë: përgjigjja gjen rrugën për në shtëpi

Gjurmoni paketën e shkuarjes dhe më pas paketën e kthimit, sepse përdorin tabela të ndryshme. Në PE-në hyrëse, burimi i klientit duhet të zgjidhet brenda VRF-së drejt prefiksit të largët me etiketën e largët. Në PE-në dalëse, destinacioni duhet të zgjidhet brenda të njëjtës VRF drejt interface-it nga ana e CE. Një ping i nisur nga vetë PE-ja nuk është provë: mund të dalë përmes tabelës globale ose një adrese tjetër burimi, dhe për këtë arsye ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 është testi që duhet ekzekutuar.

Firewalls e hosteve, reverse-path filtering dhe listat e aksesit të CE-së vazhdojnë të zbatohen. Nëse rruga e shkuarjes funksionon dhe përgjigjja vdes, problemi është një rrugë ose një filtër në anën e kthimit, jo transporti MPLS.

Mbani një rresht për çdo pikë kontrolli që emërton varësinë e parë që dështoi. Ai rresht e kthen ankesën se klienti nuk mund të bëjë ping në një pyetje konkrete për arritshmërinë, gjendjen e etiketave, importin e rrugëve, anëtarësimin e interface-it ose rrugën e kthimit, dhe e pengon sesionin e ardhshëm të debugimit të përsërisë të njëjtat pesë komanda në të njëjtën radhë.

Artikuj të ngjashëm