Label kada VRF o kada prefix? Ang totoong singil sa kapasidad

Dalawang disenyo ang nag-aanunsyo ng parehong prefix ng customer sa parehong core ng provider. Ang isa ay naglalaan ng label kada prefix, ang isa ay naglalaan ng isang label para sa buong VRF, at ang pangalawa ay mukhang mas mura sa bawat slide. Ang bilang ng label ay totoo, ngunit hindi ito ang badyet na karaniwang nauubos muna. Ang pagpili sa dalawa ay nangangahulugang pagbilang ng apat na resource, hindi isa, at ang mga label ang pinakamaliit sa kanila.

Nakadepende rin ang pagpili sa kung ano ang dapat gawin ng egress router sa packet pagkatapos nitong alisin ang label. Ang functional na pagkakaibang iyon, hindi ang aritmetika ng label, ang dapat magpatnubay sa desisyon.

Ano ang aktwal na natitipid ng bawat paglalaan

Ang paglalaan kada prefix ay nagdadala ng impormasyon ng forwarding sa label. Maaaring ipadala ng egress router ang packet nang direkta sa tamang adjacency nang walang paghahanap ng destinasyon, kaya mahusay itong nag-scale para sa malalaking set ng ruta ng VRF at kaya kumakain ito ng isang label para sa bawat inanunsyong prefix sa bawat VRF. Ang paglalaan kada VRF, tulad ng Junos vrf-table-label, ay nag-aanunsyo ng isang label kada routing instance at ginagamit ang label na iyon para piliin ang VRF table; pagkatapos ay gumagawa ang router ng IP lookup sa loob ng table.

Ito ay tunay na pagkakaiba sa arkitektura at hindi isang tuning knob. Ang pag-label kada VRF ay nagbibigay ng mas maliit na espasyo ng label at mas simpleng anunsyo ng label, kapalit ng isang lookup at ng label na walang sinasabi tungkol sa destinasyon. Ang pag-label kada prefix ay nagbibigay sa egress line card ng mas maraming impormasyon nang maaga at gumagastos ng label na proporsyonal sa mga rutang dinadala mo.

Ang ledger ng label ang maliit

Ang mga label ng MPLS ay may hangganan, ngunit sapat ang laki ng espasyo ng label upang hindi ito maubos ng mga ordinaryong service provider sa ilang libong prefix. Ang lugar kung saan talagang nakakatulong ang pag-label kada VRF ay sa mga platform na may maliliit na hardware label table, o sa mga disenyong may isang VRF na nagdadala ng buong Internet feed at ang mga label kada prefix ay magpaparami ng pangangailangan sa label sa bilang ng ruta. Tunay na limitasyon ang mga ito, at sila ang dahilan kung bakit umiiral ang feature na ito. Wala sa kanila ang tungkol sa bilang ng prefix sa table.

Bilangin ang mga label para sa serbisyo at sa transport bago pumili. Ang disenyo kada VRF ay kailangan pa rin ng transport label para sa mga loopback at sa bawat hop sa landas, at kailangan pa rin ng adjacency state. Kung ang design brief ay binibilang lamang ang mga service label, ang natitipid ay sinusukat sa maling ledger.

Ang mga ruta feed ay gumagastos ng memory bago ang label

Bawat natanggap na landas ay kumakain ng control-plane memory, pagproseso ng update at oras ng convergence, gumagamit man ang VRF ng isang label o sampung libo. Ang buong Internet feed sa loob ng VRF ay mahal dahil sa mga BGP path, RIB, FIB entry at gulo sa likod nila, hindi dahil sa label na nasa harap ng table. Ang parehong feed ay nagpapalaki rin ng radius ng epekto ng route leak o pagkakamali sa patakaran sa loob ng tenant na iyon.

Kaya itanong kung ano talaga ang kailangan ng customer. Kung ang kontrata ay mga pribadong site at default na labasan, ang buong table ay nagdadagdag ng gastos nang hindi nagdadagdag ng pangangailangan. Tanong ito ng komersyo, at karapat-dapat itong sagutin sa sulat kaysa sa isang palagay na minana mula sa nakaraang disenyo. Kung talagang kailangan ng serbisyo ang feed para sa patakaran o para sa lokal na pagpili ng labasan, gawin itong tahasang linya na may sariling reserbasyon ng kapasidad at sariling pag-uugali kapag nabigo.

Kailan ang pag-label kada VRF ang tamang default

Mabuting default ito kapag dokumentado ng platform na sinusuportahan ito, kapag malaki ang bilang ng ruta ng VRF, at kapag katanggap-tanggap ang gastos ng lookup sa labasan para sa profile ng traffic. Ito rin ang natural na pagpili kapag mas mahalaga ang pagiging simple ng operasyon kaysa sa pagpiga ng huling microsecond mula sa forwarding, dahil ang isang label kada tenant ay mas madaling ipaliwanag at i-audit kaysa isang label kada prefix.

Maling default ito kapag iniuugnay ng dokumentasyon ng platform ang feature sa partikular na hardware o release na limitasyon, o kapag nakadepende ang disenyo sa mga desisyon ng forwarding kada prefix sa labasan. Basahin ang sariling statement reference ng platform bago ipalagay ang pag-uugali; ang Junos command ay dokumentado, ngunit ang hardware at release limit sa paligid nito ang tunay na nagpapasya sa deployment.

Isang badyet na maipagtatanggol mo

Buuin ang kaso ng kapasidad bilang limang hiwalay na numero: mga natanggap na landas, mga piniling ruta, mga naka-install na forwarding entry, mga service label at mga transport label. Idagdag ang next-hop at adjacency state, bilang ng tenant at modelo ng redundancy. Ang snapshot ng maswerteng landas ng isang VRF ay hindi numero ng scale, at ang nominal na laki ng espasyo ng label ay hindi available na hardware table.

Pagkatapos ay pagkasunduan din ang failure mode, hindi lamang ang steady state. Ano ang nangyayari kapag lumaki ng kalahati ang feed, kapag nagdagdag ng pangalawang VRF ang tenant, o kapag kailangan ng platform ng reboot para baguhin ang laki ng table? Ang badyet na nakakayanan ang mga tanong na iyon ay mas mahalaga kaysa sa bilang ng label na gumagana lamang sa papel.

Piliin ang paglalaan mula sa aksyon sa labasan at sa mga limitasyon ng platform, pagkatapos ay gawing tahasang desisyon ng serbisyo ang ruta feed. Ang label ang nakikitang bahagi ng disenyo; ang mga ruta ang bahaging kailangang bayaran araw-araw.