MPLS L3VPN-laboratorio ne pingsas? Kontrolu ĉi tiujn kvin saltojn

Du klientaj enkursigiloj, paro da provider edge-aparatoj kaj ping, kiu mortas sen erarmesaĝo. En malgranda MPLS L3VPN-laboratorio la eraro preskaŭ ĉiam sidas ĉe unu el kvin kontrolpunktoj, kaj ĉiu el ili havas komandon, kiu aŭ montras, ke la dependeco funkcias, aŭ ke ĝi mankas. La eraro estas restarigi BGP ĉiufoje, kiam la ping malsukcesas, anstataŭ testi la dependecojn en ordo. Se vi saltas rekte al la VRF-agordo, vi povas pasigi horon en problemo, kiu komenciĝis per nesolvita sekva salto du aparatojn for.

Prilaboru la liston de malsupre supren. Kontrolpunkto, kiu trapasas, restas trapasita, kaj la unua malsukceso estas tiu, kiun indas sencimigi.

Kontrolpunkto unu: la PE-oj atingas unu la alian

Ĉiu PE bezonas itineron al la loopback de la alia PE, kaj tiu itinero devas solviĝi tra io reala. Interior gateway protocol estas la kutima vojo tien, sed statika itinero ankaŭ funkcias, kondiĉe ke la rekursiva serĉo surteriĝas sur viva adjacency. Sur IOS-similaj aparatoj show ip route 10.0.0.2 sekvata de show ip cef 10.0.0.2 montras, ĉu la prefikso ekzistas kaj ĉu solvita adjacency staras malantaŭ ĝi. Itinero en la tabelo sen adjacency malantaŭ ĝi ne estas atingeblo.

Kontrolu ambaŭ direktojn. Nesimetriaj IGP-kostoj, passive interface sur la malĝusta flanko aŭ distribute list, kiu filtras la loopback, rompas ĉiu nur unu direkton, kaj unu direkto sufiĉas por mortigi la sesion. Se la loopback-oj pingsas sed la BGP-sesio staras en Active, rigardu la update source antaŭ ol tuŝi ion alian.

Kontrolpunkto du: etikeda vojo ekzistas

IP-itinero al la fora loopback ne pruvas, ke la transporto metos etikedon. En LDP-dezajno konfirmu, ke la fora loopback havas lokan kaj foran bindon, kaj ke la elira etikedo aperas en la forwarding-tabelo. show mpls ldp bindings 10.0.0.2 32 montras la etikedajn parojn, kaj show mpls forwarding-table 10.0.0.2 montras, kion la line card efektive metos. Kiam la dua komando montras neniun etikedon aŭ falas reen al IP, la transporto ne portas la VPN-trafikon tiel, kiel la dezajno supozas.

La diferenco venas de tio, kiel MPLS apartigas forwarding state de celprefiksoj, la modelo priskribita en RFC 3031. Se via laboratorio uzas RSVP-TE aŭ BGP-apudajn etikedojn anstataŭ LDP, kontrolu la propran staton de tiu mekanismo; supozi, ke LDP distribuas ĉiun subkuŝan etikedon, estas kutima maniero ĉasi fantomeraron. Rompita etikeda vojo kutime aperas poste kiel VPN-itinero, kiu ekzistas sed estas neuzebla.

Kontrolpunkto tri: la VPN-itinero alvenis sendifekte

Rigardu la VPNv4- aŭ VPNv6-itinero por la preciza klienta prefikso, ne la sesian resumon. show bgp vpnv4 unicast all 10.10.1.0/24 devus montri la route distinguisher, la next hop agorditan al la fora PE-loopback kaj etikedon. Se la prefikso mankas, la eksporta politiko sur la origina PE aŭ la importa politiko sur la ricevanta PE estas la unua suspektato, kaj route targets estas la kutima kulpulo.

Legu la route target-kontrolon aparte de la BGP-ricevo. Itinero povas alveni kun la ĝusta next hop kaj tamen ne surteriĝi en la VRF, ĉar la importtarget ne kongruas. Sur la ricevanta PE show ip route vrf CUSTOMER 10.10.1.0 estas la testo, kiu gravas; la BGP-tabelo pruvas nur, ke la itinero trapasis la stirplatformon.

Kontrolpunkto kvar: la interfaco estas en la VRF

VRF-difino kun route distinguisher kaj route targets movas neniun interfacon en ĝin. La interfaco al la CE bezonas la VRF-atribuon, kaj show ip vrf interfaces aŭ show ip interface brief devus listigi ĝin sub la ĝusta kazo. Ĉi tio estas la kontrolpunkto, kie kopiita agordo plej ofte malsukcesas, ĉar la VRF-bloko aspektas kompleta dum la interfaco ankoraŭ sidas en la tutmonda tabelo.

Poste konfirmu, ke la PE lernis la lokan klientan prefikson en tiun VRF, kaj ke la CE havas itineron reen tra la konekto. Statika default sur la CE montranta al la PE sufiĉas por laboratorio, kondiĉe ke la VRF de la PE havas itineron al la CE-LAN. Se unu el la du duonoj mankas, la ping malsukcesas antaŭ ol iu etikedo metiĝas.

Kontrolpunkto kvin: la respondo trovas vojon hejmen

Spuru la antaŭenan paketon kaj poste la revenan paketon, ĉar ili uzas malsamajn tabelojn. Sur la enira PE la klienta fonto devus solviĝi ene de la VRF al la fora prefikso kun la fora etikedo. Sur la elira PE la celo devus solviĝi ene de la sama VRF al la interfaco al la CE. Ping sendita de la PE mem ne estas pruvo: ĝi povas eliri tra la tutmonda tabelo aŭ alia fonta adreso, kaj tial ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 estas la testo, kiun vi devas ruli.

Gastigantaj fajroŝirmiloj, reverse-path filtering kaj access-listoj sur la CE ankoraŭ validas. Se la antaŭena vojo funkcias kaj la respondo mortas, la problemo estas itinero aŭ filtrilo sur la reena flanko, ne la MPLS-transporto.

Tenu unu linion por kontrolpunkto, nomante la unuan malsukcesintan dependencon. Tiu linio transformas la plendon, ke la kliento ne povas pingi, en konkretan demandon pri atingeblo, etikeda stato, itinera importo, interfaca membreco aŭ la reena vojo, kaj ĝi malhelpas la sekvan sencimigan seancon ripeti la samajn kvin komandojn en la sama ordo.