Predor RSVP-TE deluje, a strankin L3VPN nima poti

Dve ekipi imata lahko hkrati prav, ko stranka poroča, da je VPN mrtev, transportna ekipa pa poroča, da je predor v redu. LSP z inženiringom prometa in MPLS L3VPN odgovarjata na različni vprašanji: eden premika označene pakete skozi jedro, drugi odloča, kateremu usmerjevalnemu kontekstu paket pripada. Ko ju zmešamo, razprava kroži, ker vsaka stran meri drug objekt in sta obe meritvi veljavni.

Transport dela, storitev pa ne – to je normalno stanje

LSP je lahko vzpostavljen, prenaša promet in je viden v vsakem nadzornem sistemu, medtem ko storitev stranke ostaja neuporabna. V tej kombinaciji ni nič protislovnega, ker predor nima mnenja o tem, ali oddaljena predpona obstaja, ali jo je uvozna politika sprejela ali ali priključeno vezje prepušča okvire.

Simptom, ki običajno razkrije zmedo, je asimetričen: pingi iz zanke PE uspejo, medtem ko gostitelj v LAN-u stranke ne prejme ničesar, ali obratno. Zapišite, kateri naslovi so delovali, preden oblikujete teorijo. Ko opazite, da preizkušate dva različna objekta, je naslednji korak branje skladovnice oznak, namesto prepiranja, čigav graf je pravilen. Dva naslova, dva lastnika in običajno dve različni osebi, od katerih vsaka verjame, da je druga nekaj pokvarila.

Berite skladovnico kot dve odgovornosti

Spodnja oznaka pripada storitvi, zgornja oznaka pa poti. RFC 4364 preprosto opisuje zaporedje: najprej se vstavi oznaka poti VPN, nato se ta označeni paket tunelira proti naslednjemu skoku BGP, kjer predor z inženiringom prometa natakne svojo oznako na vrh.

Na oddaljenem PE oznaka storitve izbere obravnavo, ki je lahko iskanje v VRF ali odločitev o priklopu. Te oznake ni mogoče zamenjati z oznako, ki zgolj prečka jedro, in obe nista zamenljivi, tudi ko se obe pojavita v isti skladovnici na istem vmesniku.

Kaj dokazuje uspeh RSVP in kaj ne

RSVP-TE vzpostavi izrecno usmerjene LSP, z rezervacijami virov ali brez njih, kar je konkretno in koristno jamstvo glede poti, ki jo paket prepotuje skozi jedro. To ni trditev o strankini poti, in nastavljeno ime predora sploh ni pot.

Tudi prisotnost RSVP ne daje obljube o zmogljivosti od konca do konca. Rezervacija pasovne širine na enem LSP ne pove ničesar o priključenem vezju, strankini lastni dostopni liniji ali obnašanju čakalne vrste na oddaljenem robu. Obravnavanje tega kot jamstva daje samozavestne odgovore na vprašanja, ki jih nihče ni postavil. Če je zahteva resnično zaveza glede pasovne širine, jo je treba sestaviti iz delov, ki jo resnično uveljavljajo, LSP pa je le sredina te verige.

Preverjajte po vrsti, nato se ustavite

Delajte od transporta navzven in se ustavite pri prvem koraku, ki ne uspe, ker vsak poznejši korak predpostavlja, da so prejšnji zdržali. Najprej potrdite, da je LSP vzpostavljen in da vnos posredovanja za predpono storitve resnično kaže nanj. Nato potrdite, da pot VPN obstaja v pravi tabeli, da je njena vezava oznake prisotna in da jo je uvozna politika sprejela. Nato potrdite priklop: vmesnik, enkapsulacijo in, kjer se uporablja, identifikator VLAN, ki pripada tej pogodbi.

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 ukazov se razlikuje glede na platformo, zato teh štirih vrstic ne obravnavajte kot skript, temveč kot štiri vprašanja. Pomembno je, da vsako od njih poizveduje drug objekt, in prav zato napaka kaže na določenega lastnika.

Sledite eni dovoljeni zahtevi in ohranite dobre dokaze

Končajte z eno resnično zahtevo stranke, ki jo dovoljuje politika, in njenim odgovorom. En delujoč pretok od konca do konca razreši več kot stran odčitkov števcev in preizkusi kombinacijo, ne vsakega dela posebej.

Ko poznejša stopnja ne uspe, ohranite uspešno opazovanje LSP, namesto da bi transport znova zgradili. Ponovna gradnja delujočega predora ne more popraviti manjkajoče oddaljene predpone, napačnega priklopa VRF ali pravila dostopa do cilja, in uniči dokaz, ki vam je sprva povedal, da je transport zdrav.