Label per VRF of per prefix? De echte capaciteitsrekening

Twee ontwerpen adverteren hetzelfde klantprefix in dezelfde providercore. Het ene wijst een label per prefix toe, het andere wijst één label voor de hele VRF toe, en het tweede lijkt op elke dia goedkoper. Het aantal labels is reëel, maar het is niet het budget dat meestal het eerst op is. Kiezen tussen de twee betekent vier resources tellen, niet één, en de labels zijn de kleinste daarvan.

De keuze hangt ook af van wat de egress-router met het pakket moet doen nadat hij het label heeft verwijderd. Dat functionele verschil, niet de labelrekenkunde, zou de beslissing moeten sturen.

Wat elke toewijzing werkelijk bespaart

Een toewijzing per prefix draagt de doorstuurinformatie in het label. De egress-router kan het pakket rechtstreeks naar de juiste adjacency sturen zonder een bestemmingsopzoeking, waardoor het goed schaalt voor grote VRF-routesets en waardoor het één label verbruikt voor elk geadverteerd prefix in elke VRF. Een toewijzing per VRF, zoals Junos vrf-table-label, adverteert één label per routinginstantie en gebruikt dat label om de VRF-tabel te selecteren; daarna doet de router een IP-opzoeking in de tabel.

Dat is een echt architectuurverschil en geen afstelknop. Labelen per VRF geeft je een kleinere labelruimte en een eenvoudigere labeladvertentie, ten koste van één opzoeking en van een label dat niets over de bestemming zegt. Labelen per prefix geeft de egress-lijnkaart meer informatie vooraf en kost labels in verhouding tot de routes die je draagt.

Het labelgrootboek is het kleine

MPLS-labels zijn eindig, maar de labelruimte is groot genoeg dat gewone serviceproviders hem niet uitputten met een paar duizend prefixen. Waar labelen per VRF echt helpt, is op platforms met kleine hardware-labeltabellen, of in ontwerpen waarin één VRF een volledige internetfeed draagt en labels per prefix de labelvraag met het aantal routes zouden vermenigvuldigen. Dat zijn echte beperkingen, en ze zijn de reden dat de functie bestaat. Geen ervan gaat over het aantal prefixen in de tabel.

Tel de labels voor zowel de dienst als het transport voordat je kiest. Een ontwerp per VRF heeft nog steeds transportlabels nodig voor de loopbacks en voor elke hop langs het pad, en het heeft nog steeds adjacency-state nodig. Als de ontwerpbrief alleen servicelabels telt, wordt de besparing op het verkeerde grootboek gemeten.

Routefeeds kosten geheugen vóór labels

Elk ontvangen pad verbruikt controlevlakgeheugen, updateverwerking en convergentietijd, of de VRF nu één label of tienduizend gebruikt. Een volledige internetfeed binnen een VRF is duur door de BGP-paden, de RIB, de FIB-vermeldingen en de onrust daarachter, niet door het label dat voor de tabel staat. Dezelfde feed vergroot ook de impactstraal van een routelek of een beleidsfout binnen die tenant.

Vraag dus wat de klant werkelijk nodig heeft. Als het contract privésites plus een standaarduitgang is, voegt een volledige tabel kosten toe zonder een eis toe te voegen. Dat is een commerciële vraag, en die verdient een schriftelijk antwoord in plaats van een aanname die van het vorige ontwerp is geërfd. Als de dienst de feed echt nodig heeft voor beleid of voor lokale uitgangsselectie, maak er dan een expliciete regel van met een eigen capaciteitsreservering en een eigen faalgedrag.

Wanneer labelen per VRF de juiste standaard is

Het is een goede standaard wanneer het platform het als ondersteund documenteert, wanneer het aantal VRF-routes groot is en wanneer de opzoekkosten bij de uitgang aanvaardbaar zijn voor het verkeersprofiel. Het is ook de natuurlijke keuze wanneer operationele eenvoud belangrijker is dan de laatste microseconde uit de doorsturing persen, omdat één label per tenant makkelijker uit te leggen en te auditen is dan één label per prefix.

Het is de verkeerde standaard wanneer de documentatie van het platform de functie aan specifieke hardware- of releasebeperkingen koppelt, of wanneer het ontwerp afhangt van doorsturbeslissingen per prefix bij de uitgang. Lees de eigen statement-referentie van het platform voordat je het gedrag aanneemt; de Junos-opdracht is gedocumenteerd, maar de hardware- en releasebeperkingen eromheen bepalen in werkelijkheid de uitrol.

Een budget dat je kunt verdedigen

Bouw de capaciteitszaak als vijf afzonderlijke getallen: ontvangen paden, geselecteerde routes, geïnstalleerde doorsturingsvermeldingen, servicelabels en transportlabels. Voeg next-hop- en adjacency-state, het aantal tenants en het redundantiemodel toe. Een momentopname van het gelukkige pad van één VRF is geen schaalgetal, en een nominale grootte van de labelruimte is geen beschikbare hardwaretabel.

Spreek daarna ook de faalmodus af, niet alleen de stabiele toestand. Wat gebeurt er als de feed met de helft groeit, als een tenant een tweede VRF toevoegt, of als het platform een herstart nodig heeft om een tabel te verkleinen of te vergroten? Een budget dat die vragen overleeft, is meer waard dan een labeltelling die alleen op papier werkt.

Kies de toewijzing op basis van de actie bij de uitgang en de platformgrenzen, en maak de routefeed daarna een expliciete dienstbeslissing. Het label is het zichtbare deel van het ontwerp; de routes zijn het deel waarvoor elke dag betaald moet worden.