MPLS L3VPN-i labor ei pingi? Kontrolli neid viit hüpet

Kaks kliendirouterit, paar provider edge-seadet ja ping, mis sureb ilma veateateta. Väikeses MPLS L3VPN-i laboris istub viga peaaegu alati ühes viiest kontrollpunktist ja igal neist on käsk, mis näitab kas sõltuvus töötab või puudub. Viga on BGP iga kord uuesti käivitada, kui ping ebaõnnestub, selle asemel et sõltuvusi järjekorras testida. Kui hüppad kohe VRF-i seadistuse juurde, võid kulutada tunni probleemile, mis algas lahendamata järgmise hüppega kahe seadme kaugusel.

Tööta nimekiri alt üles läbi. Kontrollpunkt, mis läbib, jääb läbituks, ja esimene viga on see, mida tasub siluda.

Kontrollpunkt üks: PE-d jõuavad üksteiseni

Iga PE vajab marsruuti teise PE loopbacki juurde ja see marsruut peab lahenema millegi reaalse kaudu. Interior gateway protocol on tavaline tee sinna, aga staatiline marsruut töötab samuti, kui rekursiivne otsing maandub elaval adjacencyl. IOS-sarnastel seadmetel näitab show ip route 10.0.0.2, millele järgneb show ip cef 10.0.0.2, kas prefiiks on olemas ja kas selle taga on lahendatud adjacency. Marsruut tabelis ilma adjacencyta selle taga ei ole kättesaadavus.

Kontrolli mõlemat suunda. Asümmeetrilised IGP kulud, vale pool olev passive interface või loopbacki filtreeriv distribute list lõhuvad igaüks ainult ühe suuna ja ühest suunast piisab sessiooni tapmiseks. Kui loopbackid pingivad, aga BGP sessioon seisab Active olekus, vaata enne millegi muu puutumist update source'i.

Kontrollpunkt kaks: siltide tee on olemas

IP-marsruut kaugesse loopbacki ei tõesta, et transport paneb sildi peale. LDP lahenduses kinnita, et kaugel loopbackil on nii kohalik kui kaugside ja et väljuv silt ilmub forwarding-tabelisse. show mpls ldp bindings 10.0.0.2 32 näitab sildipaare ja show mpls forwarding-table 10.0.0.2 näitab, mida line card tegelikult peale paneb. Kui teine käsk ei näita ühtegi silti või langeb tagasi IP-le, ei kanna transport VPN-liiklust nii, nagu lahendus eeldab.

Erinevus tuleb sellest, kuidas MPLS eraldab forwarding state'i sihtprefiksitest, mudel, mida kirjeldatakse dokumendis RFC 3031. Kui sinu labor kasutab LDP asemel RSVP-TE-d või BGP-ga külgnevaid silte, kontrolli selle mehhanismi enda olekut; eeldada, et LDP jagab iga aluskihi silti, on tavaline viis tondivea tagaajamiseks. Katkine siltide tee ilmub hiljem tavaliselt VPN-marsruudina, mis on olemas, aga kasutamatu.

Kontrollpunkt kolm: VPN-marsruut saabus tervena

Vaata täpselt kliendi prefiiksi VPNv4- või VPNv6-marsruuti, mitte sessiooni kokkuvõtet. show bgp vpnv4 unicast all 10.10.1.0/24 peaks näitama route distinguisherit, kaugse PE loopbackile seatud next hopi ja silti. Kui prefiiks puudub, on esimene kahtlane lähtev PE ekspordipoliitika või vastuvõtva PE impordipoliitika, ja route targetid on tavaline süüdlane.

Loe route targeti kontrolli BGP vastuvõtust eraldi. Marsruut võib saabuda õige next hopiga ja siiski VRF-i mitte maanduda, sest importtarget ei klapi. Vastuvõtval PE-l on show ip route vrf CUSTOMER 10.10.1.0 see test, mis loeb; BGP tabel tõestab ainult, et marsruut ületas juhtplaani.

Kontrollpunkt neli: interface on VRF-is

VRF definitsioon route distinguisheri ja route targetitega ei liiguta ühtegi interface'i sinna sisse. CE poole jääv interface vajab VRF-i määramist ja show ip vrf interfaces või show ip interface brief peaks selle õige instantsi all loetlema. See on kontrollpunkt, kus kopeeritud seadistus kõige sagedamini nurjub, sest VRF plokk näib täielikuna, samal ajal kui interface istub endiselt globaalses tabelis.

Seejärel kinnita, et PE on õppinud kohaliku kliendi prefiiksi sellesse VRF-i ja et CE-l on marsruut tagasi ühenduse kaudu. Staatiline default CE-l, mis osutab PE-le, on labori jaoks piisav, eeldusel et PE VRF-is on marsruut CE-LAN-i. Kui üks kahest poolest puudub, ebaõnnestub ping enne, kui ükski silt peale pannakse.

Kontrollpunkt viis: vastus leiab tee koju

Jälgi edasisuunalist paketti ja seejärel vastupaketti, sest need kasutavad erinevaid tabeleid. Sissetuleval PE-l peaks kliendi allikas lahenema VRF-i sees kaugesse prefiiksi koos kaugse sildiga. Väljamineval PE-l peaks sihtkoht lahenema sama VRF-i sees CE poole jäävasse interface'i. PE enda pealt saadetud ping ei ole tõend: see võib väljuda globaalse tabeli või teise lähteaadressi kaudu ja seetõttu on ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 see test, mida tuleb käivitada.

Hostide tulemüürid, reverse-path filtering ja CE access-listid kehtivad endiselt. Kui teekond edasi töötab ja vastus sureb, on probleem tagasitee marsruudis või filtris, mitte MPLS transportis.

Hoia iga kontrollpunkti kohta üks rida, mis nimetab esimese ebaõnnestunud sõltuvuse. See rida muudab väite, et klient ei saa pingida, konkreetseks küsimuseks kättesaadavuse, sildi oleku, marsruudi impordi, interface'i kuulumise või tagasitee kohta ja hoiab ära, et järgmine silumine kordaks samu viit käsku samas järjekorras.