Etikett per VRF eller per prefiks? Den verkelege kapasitetsrekninga

To design annonserer same kundeprefiks gjennom same leverandørkjerne. Det eine tildeler éin etikett per prefiks, det andre tildeler éin einaste etikett for heile VRF-en, og det andre ser billegare ut på kvar lysbilete. Talet på etikettar er reelt, men det er ikkje budsjettet som vanlegvis tek slutt først. Å velje mellom dei to tyder å telje fire ressursar, ikkje éin, og etikettane er den minste av dei.

Valet avheng òg av kva utgangsrutaren må gjere med pakken etter at han har fjerna etiketten. Det er den funksjonelle skilnaden, ikkje etikettaritmetikken, som bør styre avgjerda.

Kva kvar tildeling faktisk sparar

Ei tildeling per prefiks ber videresendingsinformasjonen i etiketten. Utgangsrutaren kan sende pakken rett til rett granne utan eit destinasjonsoppslag, og det er derfor ho skalerer godt for store VRF-rutesett og derfor brukar éin etikett for kvar annonsert prefiks i kvar VRF. Ei tildeling per VRF, som Junos vrf-table-label, annonserer éin etikett per rutingsinstans og brukar den etiketten til å velje VRF-tabellen; deretter gjer rutaren eit IP-oppslag inne i tabellen.

Det er ein reell arkitekturskilnad, ikkje ein justeringsknapp. Etikettering per VRF gjev deg mindre etikettplass og enklare etikettannonsering, men kostar eitt oppslag og ein etikett som ikkje seier noko om destinasjonen. Etikettering per prefiks gjev utgangslinjekortet meir informasjon på førehand og kostar etikettar i høve til rutene du ber.

Etikettrekneskapen er den vesle

MPLS-etikettar er avgrensa, men etikettplassen er stor nok til at vanlege tenesteleverandørar ikkje brukar han opp med nokre tusen prefiks. Der etikettering per VRF verkeleg hjelper, er på plattformer med små maskinvareetikettstabellar, eller i design der éin VRF ber ein full Internett-feed og etikettar per prefiks ville multiplisere etikettbehovet med ruteantalet. Dette er reelle avgrensingar, og dei er grunnen til at funksjonen finst. Ingen av dei handlar om talet på prefiks i tabellen.

Tel etikettar for både tenesta og transporten før du vel. Eit design per VRF treng framleis transportetikettar for loopbackane og for kvart hopp langs vegen, og det treng framleis grannestatus. Viss designoppdraget berre tel tenestetikettar, blir sparinga målt i feil rekneskap.

Rutefeedar kostar minne før etikettar

Kvar motteken rute brukar kontrollplansminne, oppdateringshandsaming og konvergenstid, anten VRF-en brukar éin etikett eller ti tusen. Ein full Internett-feed inne i ein VRF er dyr på grunn av BGP-rutene, RIB-en, FIB-oppføringane og uroa bak dei, ikkje på grunn av etiketten framfor tabellen. Den same feeden aukar òg radiusen for påverknad frå ein rutelekkasje eller ein policyfeil inne i den leigetakaren.

Så spør kva kunden faktisk krev. Viss kontrakten er private nettstader pluss ein standardutgang, legg ein full tabell til kostnad utan å leggje til eit krav. Det er eit kommersielt spørsmål, og det fortener eit skriftleg svar i staden for ei føresetnad arva frå førre design. Viss tenesta faktisk treng feeden for policy eller for lokalt utgangsval, gjer det til ein eksplisitt post med si eiga kapasitetsreservering og si eiga feilåtferd.

Når etikettering per VRF er rett standard

Det er ein god standard når plattformen dokumenterer det som støtta, når talet på VRF-ruter er stort, og når oppslagskostnaden ved utgangen er akseptabel for trafikkprofilen. Det er òg det naturlege valet når operasjonell enkelheit tyder meir enn å presse den siste mikrosekundet ut av videresendinga, fordi éin etikett per leigetakar er lettare å forklare og revidere enn éin etikett per prefiks.

Det er feil standard når dokumentasjonen til plattformen bind funksjonen til bestemte maskinvare- eller utgivingsavgrensingar, eller når designet avheng av videresendingsavgjerder per prefiks ved utgangen. Les den eigne statement-referansen til plattformen før du føreset åtferda; Junos-kommandoen er dokumentert, men det er maskinvare- og utgivingsgrensene rundt han som faktisk avgjer utrullinga.

Eit budsjett du kan forsvare

Bygg kapasitetssaka som fem separate tal: motteke ruter, valde ruter, installerte videresendingsoppføringar, tenestetikettar og transportetikettar. Legg til granne- og neste hopp-status, talet på leigetakarar og redundansmodellen. Eit augeblinksbilete av den lukkelege vegen for éin VRF er ikkje eit skala-tal, og ein nominell storleik på etikettplassen er ikkje ein tilgjengeleg maskinvaretabell.

Bli så samde om feilmodusen i tillegg til stabil tilstand. Kva skjer når feeden veks med halvparten, når ein leigetakar legg til ein andre VRF, eller når plattformen treng ein omstart for å endre storleiken på ein tabell? Eit budsjett som toler desse spørsmåla er verdt meir enn eit etikettal som berre fungerer på papiret.

Vel tildelinga ut frå handlinga ved utgangen og grensene til plattformen, og gjer deretter rutefeeden til ei eksplisitt tenestebeslutning. Etiketten er den synlege delen av designet; rutene er delen som må betalast for kvar dag.