Etikett per VRF eller per prefiks? Den virkelige kapasitetsregningen

To design annonserer samme kundeprefiks gjennom samme leverandørkjerne. Det ene tildeler én etikett per prefiks, det andre tildeler én enkelt etikett for hele VRF-en, og det andre ser billigere ut på hver lysbilde. Antall etiketter er reelt, men det er ikke budsjettet som vanligvis tar slutt først. Å velge mellom de to betyr å telle fire ressurser, ikke én, og etikettene er den minste av dem.

Valget avhenger også av hva utgangsruteren må gjøre med pakken etter at den har fjernet etiketten. Det er den funksjonelle forskjellen, ikke etikettaritmetikken, som bør styre beslutningen.

Hva hver tildeling faktisk sparer

En tildeling per prefiks bærer videresendingsinformasjonen i etiketten. Utgangsruteren kan sende pakken rett til riktig nabo uten et destinasjonsoppslag, og det er derfor den skalerer godt for store VRF-rutesett og derfor bruker én etikett for hver annonsert prefiks i hver VRF. En tildeling per VRF, som Junos vrf-table-label, annonserer én etikett per rutinginstans og bruker den etiketten til å velge VRF-tabellen; deretter gjør ruteren et IP-oppslag inne i tabellen.

Det er en reell arkitekturforskjell, ikke en justeringsknapp. Etikettering per VRF gir deg mindre etikettplass og enklere etikettannonsering, men koster ett oppslag og en etikett som ikke sier noe om destinasjonen. Etikettering per prefiks gir utgangslinjekortet mer informasjon på forhånd og koster etiketter i forhold til rutene du bærer.

Etikettregnskapet er det lille

MPLS-etiketter er begrensede, men etikettplassen er stor nok til at vanlige tjenesteleverandører ikke bruker den opp med noen tusen prefikser. Der etikettering per VRF virkelig hjelper, er på plattformer med små maskinvareetikettstabeller, eller i design der én VRF bærer en full Internett-feed og etiketter per prefiks ville multiplisere etikettbehovet med ruteantallet. Dette er reelle begrensninger, og de er grunnen til at funksjonen finnes. Ingen av dem handler om antall prefikser i tabellen.

Tell etiketter for både tjenesten og transporten før du velger. Et design per VRF trenger fortsatt transportetiketter for loopbackene og for hvert hopp langs veien, og det trenger fortsatt naboestatus. Hvis designoppdraget bare teller tjenesteetiketter, måles besparelsen i feil regnskap.

Rutefeeder koster minne før etiketter

Hver mottatt rute bruker kontrollplanminne, oppdateringsbehandling og konvergenstid, enten VRF-en bruker én etikett eller ti tusen. En full Internett-feed inne i en VRF er dyr på grunn av BGP-rutene, RIB-en, FIB-oppføringene og uroen bak dem, ikke på grunn av etiketten foran tabellen. Den samme feeden øker også radiusen for påvirkning fra en rutelekkasje eller en policyfeil inne i den leietakeren.

Så spør hva kunden faktisk krever. Hvis kontrakten er private nettsteder pluss en standardutgang, legger en full tabell til kostnad uten å legge til et krav. Det er et kommersielt spørsmål, og det fortjener et skriftlig svar i stedet for en antakelse arvet fra forrige design. Hvis tjenesten faktisk trenger feeden for policy eller for lokalt utgangsvalg, gjør det til en eksplisitt post med sin egen kapasitetsreservasjon og sin egen feilatferd.

Når etikettering per VRF er riktig standard

Det er en god standard når plattformen dokumenterer det som støttet, når antallet VRF-ruter er stort, og når oppslagskostnaden ved utgangen er akseptabel for trafikkprofilen. Det er også det naturlige valget når operasjonell enkelhet betyr mer enn å presse den siste mikrosekunden ut av videresendingen, fordi én etikett per leietaker er lettere å forklare og revidere enn én etikett per prefiks.

Det er feil standard når plattformens dokumentasjon binder funksjonen til bestemte maskinvare- eller utgivelsesbegrensninger, eller når designet avhenger av videresendingsbeslutninger per prefiks ved utgangen. Les plattformens egen statement-referanse før du antar atferden; Junos-kommandoen er dokumentert, men det er maskinvare- og utgivelsesgrensene rundt den som faktisk avgjør utrullingen.

Et budsjett du kan forsvare

Bygg kapasitetssaken som fem separate tall: mottatte ruter, valgte ruter, installerte videresendingsoppføringer, tjenesteetiketter og transportetiketter. Legg til nabo- og neste hopp-status, antall leietakere og redundansmodellen. Et øyeblikksbilde av den lykkelige veien for én VRF er ikke et skala-tall, og en nominell størrelse på etikettplassen er ikke en tilgjengelig maskinvaretabell.

Bli så enige om feilmodusen i tillegg til steady state. Hva skjer når feeden vokser med halvparten, når en leietaker legger til en andre VRF, eller når plattformen trenger en omstart for å endre størrelsen på en tabell? Et budsjett som tåler disse spørsmålene er verdt mer enn et etikettantall som bare fungerer på papiret.

Velg tildelingen ut fra handlingen ved utgangen og plattformens grenser, og gjør deretter rutefeeden til en eksplisitt tjenestebeslutning. Etiketten er den synlige delen av designet; rutene er delen som må betales for hver dag.