Bakit hindi pinapansin ng iyong L2VPN ang RSVP-TE LSP na kagagawa mo lang

Dalawang inhinyero ang maaaring umalis sa parehong maintenance window na kumbinsido na gumagana na ang bagong ruta, at parehong nagkakamali sa magkaibang dahilan. Itinayo ng isa ang LSP at inakalang susunod ang serbisyo. Iniwan ng isa ang serbisyo at inakalang walang nagbago. Gumagamit lamang ang pseudowire ng transport na nire-resolve ng peer address nito sa sandaling iyon, kaya ang tunay na tanong ay kung ano ang ginagawa ng resolution na iyon ngayon, at magkaiba ang sagot ng dalawang disenyo.

Isang label ang nagpapangalan ng serbisyo, ang isa ay naglilipat ng packet

Ang pseudowire label, na sinasenyasan ng target na LDP gaya ng inilalarawan sa RFC 4447, ay nagsasabi sa tumatanggap na provider edge kung aling attachment circuit ang dapat tumanggap ng frame. Wala itong sinasabi tungkol sa kung paano nakarating doon ang frame. Ang label sa ilalim nito ay pag-aari ng transport, at ang stack na iyon ay itinatayo ng anumang nag-anunsyo ng reachability para sa peer loopback, maging LDP, RSVP-TE o segment-routed na ruta. Dahil magkaibang protocol ang nagse-senyas sa dalawang layer, maaaring malusog ang isa habang lipas na ang isa. Ang paghihiwalay na iyon ang buong pinagmulan ng kalituhan.

Sulit sabihin nang tapat: hindi pinipili ng pseudowire ang LSP. Ibinibigay nito ang frame sa transport, at nagpapasya ang transport batay sa destination address na ibinigay dito.

Iyon din ang dahilan kung bakit napakakaunting pinatutunayan ng malinis na ping sa bagong LSP. Maaaring buhay, may label at nagdadala ng ibang serbisyo ang LSP habang nagre-resolve pa rin ang iyong pseudowire sa ibang susunod na hop. Hangga't hindi mo binabasa ang binding, walang kaugnayan ang dalawang katotohanang iyon.

Opsyon A: i-pin ang pseudowire sa piniling transport

Ang pag-pin ay nangangahulugang gawing deterministiko ang transport resolution ng serbisyo. Depende sa platform, ito ay nagiging policy sa pagpili ng tunnel, tahasang transport endpoint sa serbisyo, o route policy na nagsusulat muli ng susunod na hop para sa peer address. Ginagawa ng tatlo ang parehong bagay sa ilalim: pinipilit nila ang resolution ng isang destinasyon sa isang partikular na LSP. Iyon ang nagpapaging-auditable ng resulta pagkatapos.

Ang halaga ay ang saklaw. Ang policy na tumutugma sa isang peer address ay nakakaapekto sa bawat serbisyong nakaturo sa peer na iyon, hindi lamang sa pseudowire na nasa isip mo.

Ang fallback ay karapat-dapat na pagpasyahan bago ang change window, hindi habang ito ay nangyayari. Kung bumagsak ang naka-pin na LSP, hinahayaan mo ang serbisyo na dumaan sa ibang aprubadong ruta o hinahayaan mo itong huminto. Ang policy na tahimik na bumabalik sa rutang lumalabag sa limitasyon sa latency o disjunction ay ginawang mas mahirap ipaliwanag sa kahit sino ang isang malinis na pagkakagambala.

Opsyon B: hayaang pumili ang IGP at panoorin ang mangyayari

Ang pag-iwan sa serbisyo ay isang lehitimong disenyo, at madalas ang mas mahusay. Sinusunod ng pseudowire ang parehong resolution gaya ng ibang trapiko patungo sa peer loopback, kaya nagmamana ito ng IGP convergence, prefix suppression at anumang redundancy na iniaalok na ng core. Mas kaunting policy ay nangangahulugang mas kaunting lugar kung saan maaaring magtago ang lipas na tugma. Ang kapalit ay hindi mo na kontrolado kung aling ruta ang tinatahak ng serbisyo, may ruta lang.

Ang equal-cost multipath ay nagpapatalas sa kapalit na iyon nang higit sa tila sa unang tingin. Ang hashing ay per flow, kaya ang dalawang usapan sa loob ng isang pseudowire ay maaaring umalis sa magkaibang panlabas na label.

Basahin ang naka-install na forwarding bago magtiwala sa alinman

Magsimula sa peer address kaysa sa serbisyo. Sa Junos, ipinapakita ng show route 203.0.113.1 detail ang piniling susunod na hop at ang label operation, at ipinapamapa ng show route table mpls.0 ang papasok na label sa operasyong iyon. Sa IOS XR, ibinibigay ng show mpls l2transport vc 100 detail ang estado ng pseudowire kasama ang ipinataw na stack.

Kumpirmahin ang LSP na aktuwal na ginagamit ng transport, hindi ang pinapangalanan ng iyong design document. Sa IOS XR, nilalakad ng traceroute mpls ipv4 203.0.113.1/32 ang label-switched na ruta at inililista ang mga label at palabas na interface sa kahabaan nito, na pinakamalapit sa sarili mong pagtingin sa ruta. Pagkatapos, ulitin ang ehersisyo mula sa malayong provider edge, dahil ang pabalik na direksyon ay hiwalay na nire-resolve at karaniwan ang asimetriya pagkatapos ng bahagyang pag-deploy ng policy. Ang rutang tama sa isang direksyon at mali sa isa ay mas malala kaysa sa pantay na mali, dahil kalahati ng iyong mga pagsubok ay papasa.

Itabi ang ebidensiya kasama ng rekord ng serbisyo: peer address, susunod na hop, panlabas na label at ang petsang sinuri mo. Ang mga route policy ay tumatanda nang hindi maganda, at walang nakakaalala kung alin ang may bisa dalawang quarter na ang nakalipas.

Pumili ayon sa mode ng pagkasira, hindi sa kagustuhan

Ang pag-pin ay angkop sa mga serbisyong may hadlang na hindi maipahayag ng IGP, at sa mga team na kayang panatilihin ang policy sa bawat pagbabago. Ang pag-iwan nito sa IGP ay angkop sa mga serbisyong kailangang makalampas sa anumang nag-iisang pagkasira nang walang tao sa loop.

Ang mapagpasyang tanong ay kung magkano ang gastos sa iyo ng maling ruta. Kung ang serbisyo sa maling LSP ay bahagya lamang mas mahina, hayaan ang IGP na magpasya at gugulin ang pagsisikap sa pagmamanman. Kung ang maling ruta ay lumalabag sa kontrata, natuklasan sa audit o pangangailangan sa disjunction, i-pin ito at isulat ang fallback. Pagkatapos, subukan ang fallback, dahil ang hindi nasubukang fallback ay isang palagay at hindi isang plano. Alinman, basahin muli ang naka-install na binding pagkatapos ng anumang pagbabago sa core, at ituring ang pseudowire na umangat na patunay ng wala maliban sa gumagana ang signaling.