Laboratorij MPLS L3VPN ne odgovarja na ping? Preverite teh pet skokov

Dva usmerjevalnika stranke, par naprav provider edge in ping, ki umre brez sporočila o napaki. V majhnem laboratoriju MPLS L3VPN napaka skoraj vedno sedi na eni od petih kontrolnih točk, in vsaka od njih ima ukaz, ki pokaže, ali odvisnost deluje ali manjka. Napaka je znova zagnati BGP vsakič, ko ping spodleti, namesto da bi odvisnosti preizkusili po vrsti. Če skočite naravnost v konfiguracijo VRF, lahko porabite uro za težavo, ki se je začela z nerazrešenim naslednjim skokom dve napravi dlje.

Seznam obdelajte od spodaj navzgor. Kontrolna točka, ki uspe, ostane uspešna, in prva napaka je tista, ki se je vredno lotiti.

Prva kontrolna točka: PE se medsebojno dosežejo

Vsak PE potrebuje pot do loopbacka drugega PE, in ta pot se mora razrešiti skozi nekaj resničnega. Interior gateway protocol je običajna pot tja, a tudi statična pot deluje, dokler se rekurzivno iskanje ustavi na živem adjacencyju. Na napravah v slogu IOS show ip route 10.0.0.2 in nato show ip cef 10.0.0.2 pokažeta, ali predpona obstaja in ali je za njo razrešen adjacency. Pot v tabeli brez adjacencyja za seboj ni dosegljivost.

Preverite obe smeri. Asimetrični stroški IGP, passive interface na napačni strani ali distribute list, ki filtrira loopback, prelomijo vsak samo eno smer, in ena smer je dovolj, da ubije sejo. Če loopbacki odgovarjajo na ping, seja BGP pa stoji v Active, poglejte update source, preden se dotaknete česar koli drugega.

Druga kontrolna točka: pot oznak obstaja

Pot IP do oddaljenega loopbacka ne dokazuje, da bo transport dodal oznako. V zasnovi LDP potrdite, da ima oddaljeni loopback lokalno in oddaljeno vezavo ter da se izhodna oznaka pojavi v tabeli forwarding. show mpls ldp bindings 10.0.0.2 32 prikaže pare oznak, show mpls forwarding-table 10.0.0.2 pa pokaže, kaj bo line card dejansko dodal. Ko drugi ukaz ne pokaže nobene oznake ali pade nazaj na IP, transport ne nosi prometa VPN tako, kot zasnova predpostavlja.

Razlika izhaja iz tega, kako MPLS ločuje forwarding state od ciljnih predpon, model, opisan v RFC 3031. Če vaš laboratorij uporablja RSVP-TE ali oznake, ki mejijo na BGP, namesto LDP, preverite lastno stanje tega mehanizma; domnevati, da LDP razdeljuje vsako oznako spodnjega sloja, je pogost način lovljenja duhove napake. Zlomljena pot oznak se običajno pozneje pokaže kot pot VPN, ki obstaja, a je neuporabna.

Tretja kontrolna točka: pot VPN je prispela nepoškodovana

Poglejte pot VPNv4 ali VPNv6 za točno predpono stranke, ne povzetek seje. show bgp vpnv4 unicast all 10.10.1.0/24 bi moral pokazati route distinguisher, next hop, nastavljen na loopback oddaljenega PE, in oznako. Če predpone ni, je prvi osumljenec izvozna politika na izvornem PE ali uvozna politika na sprejemnem PE, route targeti pa so običajni krivec.

Preverjanje route target preberite ločeno od prejema BGP. Pot lahko prispe s pravilnim next hopom in vseeno ne pristane v VRF, ker se importtarget ne ujema. Na sprejemnem PE je show ip route vrf CUSTOMER 10.10.1.0 preizkus, ki šteje; tabela BGP samo dokazuje, da je pot prečkala krmilno ravnino.

Četrta kontrolna točka: interface je v VRF

Definicija VRF z route distinguisherjem in route targeti ne premakne nobenega interfacea vanjo. Interface proti CE potrebuje dodelitev VRF, in show ip vrf interfaces ali show ip interface brief bi ga moral navesti pod pravilnim primerkom. To je kontrolna točka, kjer kopirana konfiguracija najpogosteje zgreši, ker je blok VRF videti popoln, medtem ko interface še vedno sedi v globalni tabeli.

Nato potrdite, da se je PE naučil lokalno predpono stranke v to VRF in da ima CE pot nazaj skozi priključek. Statični default na CE, ki kaže na PE, zadostuje za laboratorij, pod pogojem, da ima VRF na PE pot do omrežja LAN stranke. Če manjka katera koli polovica, ping spodleti, preden je nameščena kakršna koli oznaka.

Peta kontrolna točka: odgovor najde pot domov

Sledite paketu naprej in nato povratnemu paketu, ker uporabljata različni tabeli. Na vhodnem PE se mora izvor stranke znotraj VRF razrešiti na oddaljeno predpono z oddaljeno oznako. Na izhodnem PE se mora cilj znotraj iste VRF razrešiti na interface proti CE. Ping, poslan s PE sam, ni dokaz: lahko odide skozi globalno tabelo ali drug izvorni naslov, in zato je ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 preizkus, ki ga je treba izvesti.

Požarni zidovi na gostiteljih, reverse-path filtering in dostopni seznami na CE še vedno veljajo. Če pot naprej deluje, odgovor pa umre, je težava v poti ali filtru na povratni strani, ne v transportu MPLS.

Za vsako kontrolno točko vodite eno vrstico z imenom prve odvisnosti, ki je spodletela. Ta vrstica pritožbo, da stranka ne more pingati, spremeni v konkretno vprašanje o dosegljivosti, stanju oznak, uvozu poti, pripadnosti interfacea ali povratni poti in prepreči, da bi naslednja seja razhroščevanja ponovila istih pet ukazov v istem vrstnem redu.