Label pr. VRF eller pr. præfiks? Den reelle kapacitetsregning

To designs annoncerer det samme kundepræfiks gennem den samme udbyderkerne. Det ene tildeler et label pr. præfiks, det andet tildeler et enkelt label til hele VRF'en, og det andet ser billigere ud på hver slide. Labelantallet er reelt, men det er ikke det budget, der normalt løber tør først. At vælge mellem de to betyder at tælle fire ressourcer, ikke én, og labelene er den mindste af dem.

Valget afhænger også af, hvad egress-routeren skal gøre med pakken, efter den har poppet labelen. Det er den funktionelle forskel, ikke labelaritmetikken, der bør styre beslutningen.

Hvad hver tildeling faktisk sparer

Tildelingen pr. præfiks bærer videresendingsinformation i labelen. Egress-routeren kan sende pakken direkte til den rigtige adjacency uden et destinationsopslag, og derfor skalerer den godt til store VRF-rutesæt, og derfor bruger den ét label for hvert annonceret præfiks i hver VRF. Tildelingen pr. VRF, som Junos vrf-table-label, annoncerer ét label pr. routinginstans og bruger det label til at vælge VRF-tabellen; routeren udfører derefter et IP-opslag inde i tabellen.

Det er en reel arkitektonisk forskel og ikke en justeringsknap. Mærkning pr. VRF giver et mindre labelområde og en enklere annoncering, men koster et opslag og et label, der intet siger om destinationen. Mærkning pr. præfiks giver egress-linekortet mere information på forhånd og koster labels i forhold til de ruter, du bærer.

Labelregnskabet er det lille

MPLS-labels er endelige, men labelområdet er stort nok til, at almindelige tjenesteudbydere ikke udtømmer det med et par tusinde præfikser. Mærkning pr. VRF hjælper reelt på platforme med små hardware-labeltabeller eller i designs, hvor en enkelt VRF bærer et fuldt internetfeed, og labels pr. præfiks ville mangedoble efterspørgslen efter labels med antallet af ruter. Det er reelle begrænsninger, og de er grunden til, at funktionen findes. Ingen af dem handler om antallet af præfikser i tabellen.

Tæl labels for både tjenesten og transporten, før du vælger. Et design pr. VRF har stadig brug for transportlabels til loopbacks og til hvert hop på vejen, og det har stadig brug for adjacency-tilstand. Hvis designopgaven kun tæller tjenestelabels, måles besparelsen på det forkerte regnskab.

Rutefeed koster hukommelse før labels

Hver modtaget rute bruger kontrolplanshukommelse, opdateringsbehandling og konvergenstid, uanset om VRF'en bruger ét label eller ti tusind. Et fuldt internetfeed inde i en VRF er dyrt på grund af BGP-ruterne, RIB'en, FIB-posterne og churnet bag dem, ikke på grund af labelen foran tabellen. Det samme feed øger også skadesomfanget af en rutelækage eller en politikfejl inde i den lejer.

Så spørg, hvad kunden faktisk har brug for. Hvis kontrakten er private sites plus en standardudgang, tilføjer en fuld tabel omkostninger uden at tilføje et krav. Det er et kommercielt spørgsmål, og det fortjener et skriftligt svar i stedet for en antagelse, der er arvet fra det sidste design. Hvis tjenesten virkelig har brug for feedet til politik eller til valg af lokal udgang, så gør det til en eksplicit post med sin egen kapacitetsreservation og sin egen fejlopførsel.

Hvornår mærkning pr. VRF er det rigtige standardvalg

Det er et godt standardvalg, når platformen dokumenterer det som understøttet, når VRF-ruteantallet er stort, og når prisen for egress-opslaget er acceptabel for trafikprofilen. Det er også det naturlige valg, når operationel enkelhed betyder mere end at presse det sidste mikrosekund ud af videresendingen, fordi ét label pr. lejer er lettere at forklare og revidere end ét label pr. præfiks.

Det er det forkerte standardvalg, når platformens dokumentation binder funktionen til bestemt hardware eller udgivelsesbegrænsninger, eller når designet afhænger af videresendingsbeslutninger pr. præfiks ved egress. Læs platformens egen referencetekst om udsagnet, før du antager opførslen; Junos-kommandoen er dokumenteret, men hardware- og udgivelsesgrænserne omkring den er det, der reelt afgør udrulningen.

Et budget, du kan forsvare

Byg kapacitetssagen som fem separate tal: modtagne ruter, valgte ruter, installerede videresendingsposter, tjenestelabels og transportlabels. Tilføj next-hop- og adjacency-tilstand, lejerantal og redundansmodellen. Et øjebliksbillede af en enkelt VRF's lykkelige vej er ikke et skalatal, og en nominel labelområdestørrelse er ikke en tilgængelig hardwaretabel.

Aftal derefter fejltilstanden såvel som steady state. Hvad sker der, når feedet vokser med halvdelen, når en lejer tilføjer en anden VRF, eller når platformen skal genstartes for at ændre størrelsen på en tabel? Et budget, der overlever de spørgsmål, er mere værd end et labelantal, der kun virker på papir.

Vælg tildelingen ud fra egress-handlingen og platformens grænser, og gør derefter rutefeedet til en eksplicit servicebeslutning. Labelen er den synlige del af designet; ruterne er den del, der skal betales for hver dag.