Etikett per VRF eller per prefiks? Den virkelige kapasitetsregningen

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

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

Hva hver tildeling egentlig sparer

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

Dette 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 proporsjonalt med rutene du bærer.

Etikettregnskapet er det lille

MPLS-etiketter er endelige, 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 multiplisert etikettbehovet med antall ruter. Dette er reelle begrensninger, og de er grunnen til at funksjonen eksisterer. 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å påvirkningsradiusen ved 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 som er arvet fra forrige design. Hvis tjenesten faktisk trenger feeden for policy eller for lokalt utgangsvalg, gjør det til en eksplisitt post med egen kapasitetsreservasjon og 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 antall 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 mikrosekundet 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 knytter 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 maskinvare- og utgivelsesgrensene rundt den er det 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 deretter enige om feilmodusen i tillegg til stabil tilstand. 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.