Etikett per VRF eller per prefix? Den verkliga kapacitetsräkningen

Två konstruktioner annonserar samma kundprefix genom samma leverantörskärna. Den ena tilldelar en etikett per prefix, den andra tilldelar en enda etikett för hela VRF:en, och den andra ser billigare ut på varje bild. Antalet etiketter är verkligt, men det är inte den budget som vanligtvis tar slut först. Att välja mellan de två innebär att räkna fyra resurser, inte en, och etiketterna är den minsta av dem.

Valet beror också på vad utgångsroutern måste göra med paketet efter att den har tagit bort etiketten. Det är den funktionella skillnaden, inte etikettaritmetiken, som bör styra beslutet.

Vad varje tilldelning faktiskt sparar

En tilldelning per prefix bär vidarebefordringsinformationen i etiketten. Utgångsroutern kan skicka paketet direkt till rätt grannskap utan en destinationssökning, vilket är anledningen till att den skalar bra för stora VRF-ruttset och till att den förbrukar en etikett för varje annonserat prefix i varje VRF. En tilldelning per VRF, som Junos vrf-table-label, annonserar en etikett per routinginstans och använder den etiketten för att välja VRF-tabellen; därefter gör routern en IP-sökning i tabellen.

Det är en verklig arkitektonisk skillnad och inte en justeringsknapp. Etikettering per VRF ger mindre etikettutrymme och enklare etikettannonsering, till priset av en sökning och en etikett som inte säger något om destinationen. Etikettering per prefix ger utgångslinjekortet mer information i förväg och kostar etiketter i proportion till de rutter du bär.

Etikettliggaren är den lilla

MPLS-etiketter är ändliga, men etikettutrymmet är tillräckligt stort för att vanliga tjänsteleverantörer inte ska uttömma det med några tusen prefix. Där etikettering per VRF verkligen hjälper är på plattformar med små hårdvaruetikettstabeller, eller i konstruktioner där en enda VRF bär ett fullt internetflöde och etiketter per prefix skulle multiplicera etikettbehovet med antalet rutter. Det är verkliga begränsningar, och de är anledningen till att funktionen finns. Ingen av dem handlar om antalet prefix i tabellen.

Räkna etiketterna för både tjänsten och transporten innan du väljer. En konstruktion per VRF behöver fortfarande transportetiketter för loopbackarna och för varje hopp längs vägen, och den behöver fortfarande grannskaptillstånd. Om designbriefen bara räknar tjänsteetiketter mäts besparingen i fel liggare.

Ruttflöden kostar minne före etiketter

Varje mottagen väg förbrukar kontrollplansminne, uppdateringsbearbetning och konvergenstid, oavsett om VRF:en använder en etikett eller tiotusen. Ett fullt internetflöde inuti en VRF är dyrt på grund av BGP-vägarna, RIB:n, FIB-posterna och oron bakom dem, inte på grund av etiketten framför tabellen. Samma flöde ökar också påverkansradien för ett ruttläckage eller ett policyfel inuti den hyresgästen.

Så fråga vad kunden faktiskt kräver. Om avtalet är privata platser plus en standardutgång lägger en full tabell till kostnad utan att lägga till ett krav. Det är en kommersiell fråga, och den förtjänar ett skriftligt svar i stället för ett antagande som ärvts från den förra konstruktionen. Om tjänsten verkligen behöver flödet för policy eller för lokalt utgångsval, gör det till en uttalad post med egen kapacitetsreservation och eget felbeteende.

När etikettering per VRF är rätt standard

Det är en bra standard när plattformen dokumenterar den som stödd, när antalet VRF-rutter är stort och när sökkostnaden vid utgången är acceptabel för trafikprofilen. Det är också det naturliga valet när operativ enkelhet betyder mer än att pressa ut den sista mikrosekunden ur vidarebefordran, eftersom en etikett per hyresgäst är lättare att förklara och granska än en etikett per prefix.

Det är fel standard när plattformens dokumentation binder funktionen till särskilda hårdvaru- eller utgivningsbegränsningar, eller när konstruktionen är beroende av vidarebefordringsbeslut per prefix vid utgången. Läs plattformens egen statement-referens innan du antar beteendet; Junos-kommandot är dokumenterat, men det är hårdvaru- och utgivningsgränserna runt det som faktiskt avgör driftsättningen.

En budget du kan försvara

Bygg kapacitetsärendet som fem separata tal: mottagna vägar, valda rutter, installerade vidarebefordringsposter, tjänsteetiketter och transportetiketter. Lägg till nästa hopp- och grannskaptillstånd, antalet hyresgäster och redundansmodellen. En ögonblicksbild av den lyckliga vägen för en enda VRF är inte en skalsiffra, och en nominell storlek på etikettutrymmet är inte en tillgänglig hårdvarutabell.

Kom sedan överens om felläget också, inte bara det stabila tillståndet. Vad händer när flödet växer med hälften, när en hyresgäst lägger till en andra VRF, eller när plattformen behöver en omstart för att ändra storleken på en tabell? En budget som klarar de frågorna är värd mer än ett etikettantal som bara fungerar på papper.

Välj tilldelningen utifrån åtgärden vid utgången och plattformens gränser, och gör sedan ruttflödet till ett uttalat tjänstebeslut. Etiketten är den synliga delen av konstruktionen; ruttarna är den del som måste betalas varje dag.