Etiket per VRF of per voorvoegsel? Die werklike kapasiteitsrekening

Twee ontwerpe adverteer dieselfde kliëntevoorvoegsel oor dieselfde diensverskaffer se kern. Die een ken 'n etiket per voorvoegsel toe, die ander ken 'n enkele etiket vir die hele VRF toe, en die tweede lyk op elke skyfie goedkoper. Die etikettelling is werklik, maar dit is nie die begroting wat gewoonlik eerste opraak nie. Om tussen die twee te kies beteken om vier hulpbronne te tel, nie een nie, en die etikette is die kleinste daarvan.

Die keuse hang ook daarvan af wat die uitgangsroeteerder met die pakkie moet doen nadat dit die etiket verwyder het. Daardie funksionele verskil, nie die etiketrekenkunde nie, behoort die besluit te dryf.

Wat elke toekenning werklik spaar

Die toekenning per voorvoegsel dra stuurinligting in die etiket. Die uitgangsroeteerder kan die pakkie reguit na die regte aangrensing stuur sonder 'n bestemmingsopsoek, en daarom skaleer dit goed vir groot VRF-roetestelle en daarom verbruik dit een etiket vir elke geadverteerde voorvoegsel in elke VRF. Die toekenning per VRF, soos Junos vrf-table-label, ken een etiket per roeteringsinstansie toe en gebruik daardie etiket om die VRF-tabel te kies; die roeteerder doen dan 'n IP-opsoek binne die tabel.

Dit is 'n werklike argitektoniese verskil, nie 'n instelknop nie. Etikettering per VRF gee jou 'n kleiner etiketruimte en 'n eenvoudiger etiketadvertensie, teen die koste van een opsoek en van 'n etiket wat niks oor die bestemming sê nie. Etikettering per voorvoegsel gee die uitgangslynkaart meer inligting vooraf en kos etikette in verhouding tot die roetes wat jy dra.

Die etiketgrootboek is die klein een

MPLS-etikette is eindig, maar die etiketruimte is groot genoeg dat gewone diensverskaffers dit nie met 'n paar duisend voorvoegsels uitgeput kry nie. Waar etikettering per VRF werklik help, is op platforms met klein hardeware-etikettabelle, of in ontwerpe waar 'n enkele VRF 'n volledige internetvoer dra en etikette per voorvoegsel die etiketvraag met die roetetelling sou vermenigvuldig. Dit is werklike beperkings, en dit is die rede waarom die funksie bestaan. Nie een daarvan gaan oor die aantal voorvoegsels in die tabel nie.

Tel etikette vir beide die diens en die vervoer voordat jy kies. 'n Ontwerp per VRF benodig steeds vervoeretikette vir die loopbacks en vir elke hop langs die pad, en dit benodig steeds aangrensingsstatus. As die ontwerp-opdrag net diensetikette tel, word die besparing op die verkeerde grootboek gemeet.

Roetevoere kos geheue voor etikette

Elke ontvangde pad verbruik beheervlakgeheue, opdateringsverwerking en konvergensie, of die VRF nou een etiket of tien duisend gebruik. 'n Volledige internetvoer binne 'n VRF is duur weens die BGP-paaie, die RIB, die FIB-inskrywings en die veranderinge daarom, nie weens die etiket wat voor die tabel sit nie. Dieselfde voer verhoog ook die impakradius van 'n roetelek of 'n beleidsfout binne daardie huurder.

Vra dus wat die kliënt werklik benodig. As die kontrak private terreine plus 'n verstekuitgang is, voeg 'n volledige tabel koste by sonder om 'n vereiste by te voeg. Dit is 'n kommersiële vraag, en dit verdien 'n geskrewe antwoord eerder as 'n aanname wat van die vorige ontwerp geërf is. As die diens die voer werklik vir beleid of vir plaaslike uitgangskeuse nodig het, maak dit 'n eksplisiete lynitem met sy eie kapasiteitsreservering en sy eie foutgedrag.

Wanneer etikettering per VRF die regte standaard is

Dit is 'n goeie standaard wanneer die platform dit as ondersteun gedokumenteer het, wanneer die VRF-roetetelling groot is, en wanneer die uitgangsoopsoekkoste vir die verkeersprofiel aanvaarbaar is. Dit is ook die natuurlike pas wanneer operasionele eenvoud belangriker is as om die laaste mikrosekonde uit stuur te pers, want een etiket per huurder is makliker om te verduidelik en te oudit as een etiket per voorvoegsel.

Dit is die verkeerde standaard wanneer die platform se dokumentasie die funksie aan spesifieke hardeware- of vrystellingsbeperkings bind, of wanneer die ontwerp op stuurkeuses per voorvoegsel by die uitgang staatmaak. Lees die platform se eie verwysing vir die stelling voordat jy die gedrag aanvaar; die Junos-bevel is gedokumenteer, maar die hardeware- en vrystellingsgrense daarom is wat die ontplooiing werklik bepaal.

'n Begroting wat jy kan verdedig

Bou die kapasiteitsaak as vyf afsonderlike getalle: ontvangde paaie, gekose roetes, geïnstalleerde stuurinskrywings, diensetikette en vervoeretikette. Voeg volgende-hop- en aangrensingsstatus, huurdertelling en die oortolligheidsmodel by. 'n Enkele VRF se gelukkige-pad-momentopname is nie 'n skaalgetal nie, en 'n nominale etiketruimtegrootte is nie 'n beskikbare hardewaretabel nie.

Stem dan die foutmodus sowel as die bestendige toestand ooreen. Wat gebeur wanneer die voer met die helfte groei, wanneer 'n huurder 'n tweede VRF byvoeg, of wanneer die platform 'n herlaai nodig het om 'n tabel te hergroot? 'n Begroting wat daardie vrae oorleef, is meer werd as 'n etikettelling wat net op papier werk.

Kies die toekenning op grond van die uitgangsaksie en die platformgrense, en maak dan die roetevoer 'n eksplisiete diensbesluit. Die etiket is die sigbare deel van die ontwerp; die roetes is die deel waarvoor elke dag betaal moet word.