RSVP-TE tunel radi, ali korisnički L3VPN nema putanju

Dva tima mogu biti u pravu istovremeno kada korisnik javi da VPN ne radi, a transportni tim da je tunel ispravan. LSP s inženjeringom prometa i MPLS L3VPN odgovaraju na različita pitanja: jedan prenosi označene pakete kroz jezgro, drugi odlučuje kojem usmjerivačkom kontekstu paket pripada. Kada se oni spoje, rasprava ide u krug jer svaka strana mjeri različit objekt i oba mjerenja su valjana.

Transport radi, a usluga ne radi jest normalno stanje

LSP može biti uspostavljen, prenositi promet i biti vidljiv u svakom sistemu nadzora, dok korisnička usluga ostaje neupotrebljiva. Ništa u toj kombinaciji nije proturječno, jer tunel nema mišljenje o tome postoji li udaljeni prefiks, je li ga politika uvoza prihvatila ili propušta li priključeni krug okvire.

Simptom koji obično razotkriva zbrku je asimetričan: pingovi s PE loopbacka prolaze, dok host na korisničkom LAN-u ne dobija ništa, ili obrnuto. Zapišite koje su adrese radile prije nego što stvorite teoriju. Kada primijetite da testirate dva različita objekta, sljedeći je korak pročitati stek oznaka umjesto raspravljati čiji je graf ispravan. Dvije adrese, dva vlasnika i obično dvije različite osobe od kojih svaka vjeruje da je druga nešto pokvarila.

Čitajte stek kao dvije odgovornosti

Donja oznaka pripada usluzi, a gornja putanji. RFC 4364 jednostavno opisuje slijed: prvo se nameće oznaka VPN rute, zatim se taj označeni paket tunelira prema BGP sljedećem skoku, gdje tunel s inženjeringom prometa stavlja svoju oznaku na vrh.

Na udaljenom PE oznaka usluge odabire tretman, koji može biti pretraga VRF-a ili odluka o priključenju. Ta se oznaka ne može zamijeniti onom koja samo prelazi jezgro, i njih dvije nisu zamjenjive čak i kada se obje pojavljuju u istom steku na istom interfejsu.

Šta uspjeh RSVP-a dokazuje, a šta ne

RSVP-TE uspostavlja LSP-ove s eksplicitno određenom rutom, sa ili bez rezervacije resursa, što je konkretno i korisno jamstvo o putanji koju paket prolazi kroz jezgro. To nije tvrdnja o korisničkim rutama, a konfigurirano ime tunela uopće nije ruta.

Ni prisustvo RSVP-a ne daje obećanje o performansama od kraja do kraja. Rezervacija propusnog opsega na jednom LSP-u ne govori ništa o priključenom krugu, korisničkoj vlastitoj pristupnoj liniji ili ponašanju reda na udaljenom rubu. Tretiranje toga kao jamstva daje sigurne odgovore na pitanja koja niko nije postavio. Ako je zahtjev zaista obaveza po pitanju propusnog opsega, mora se sastaviti od dijelova koji je stvarno provode, a LSP je samo sredina tog lanca.

Provjeravajte po redu, pa stanite

Radite od transporta prema van i stanite na prvom koraku koji ne uspije, jer svaki kasniji korak pretpostavlja da su prethodni izdržali. Prvo potvrdite da je LSP uspostavljen i da zapis prosljeđivanja za prefiks usluge zaista pokazuje na njega. Zatim potvrdite da VPN ruta postoji u pravoj tabeli, da je njeno vezivanje oznake prisutno i da ju je politika uvoza prihvatila. Zatim potvrdite priključenje: interfejs, enkapsulaciju i, gdje se primjenjuje, VLAN identifikator koji pripada tom ugovoru.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

Sintaksa komandi zavisi od platforme, pa ta četiri reda tretirajte kao četiri pitanja, a ne kao skriptu. Važno je da svaki od njih ispituje različit objekt, i upravo zato kvar pokazuje na određenog vlasnika.

Slijedite jedan dozvoljeni zahtjev i sačuvajte dobre dokaze

Završite jednim stvarnim korisničkim zahtjevom, dozvoljenim politikom, i njegovim odgovorom. Jedan tok koji radi od kraja do kraja rješava više od stranice očitanja brojača i ispituje kombinaciju, a ne svaki dio izolirano.

Kada kasnija faza ne uspije, sačuvajte uspješno opažanje LSP-a umjesto da ponovno gradite transport. Ponovna izgradnja tunela koji radi ne može popraviti odsutan udaljeni prefiks, pogrešno priključenje VRF-a ili pravilo pristupa odredištu, a uništava dokaz koji vam je prvobitno rekao da je transport zdrav.