Etichetă per VRF sau per prefix? Factura reală a capacității

Două proiecte anunță același prefix de client în același nucleu al furnizorului. Unul alocă o etichetă per prefix, celălalt alocă o singură etichetă pentru întregul VRF, iar al doilea pare mai ieftin pe fiecare slide. Numărul de etichete este real, dar nu este bugetul care se epuizează de obicei primul. Alegerea între cele două înseamnă numărarea a patru resurse, nu a uneia, iar etichetele sunt cea mai mică dintre ele.

Alegerea depinde și de ce trebuie să facă routerul de ieșire cu pachetul după ce scoate eticheta. Acea diferență funcțională, nu aritmetica etichetelor, ar trebui să ghideze decizia.

Ce economisește de fapt fiecare alocare

O alocare per prefix transportă informația de forwarding în etichetă. Routerul de ieșire poate trimite pachetul direct către adiacența corectă fără o căutare a destinației, motiv pentru care scalează bine pentru seturi mari de rute VRF și pentru care consumă o etichetă pentru fiecare prefix anunțat în fiecare VRF. O alocare per VRF, cum ar fi Junos vrf-table-label, anunță o etichetă per instanță de rutare și folosește acea etichetă pentru a selecta tabela VRF; routerul efectuează apoi o căutare IP în tabelă.

Este o diferență arhitecturală reală, nu un buton de reglaj. Etichetarea per VRF oferă un spațiu de etichete mai mic și un anunț de etichete mai simplu, cu prețul unei căutări și al unei etichete care nu spune nimic despre destinație. Etichetarea per prefix oferă plăcii de linie de ieșire mai multe informații în avans și costă etichete proporțional cu rutele transportate.

Registrul etichetelor este cel mic

Etichetele MPLS sunt finite, dar spațiul de etichete este suficient de mare încât furnizorii obișnuiți de servicii să nu îl epuizeze cu câteva mii de prefixe. Acolo unde etichetarea per VRF ajută cu adevărat este pe platformele cu tabele hardware de etichete mici sau în proiectele în care un singur VRF transportă un feed Internet complet și etichetele per prefix ar multiplica cererea de etichete cu numărul de rute. Acestea sunt constrângeri reale și ele sunt motivul pentru care funcția există. Niciuna nu se referă la numărul de prefixe din tabelă.

Numărați etichetele atât pentru serviciu, cât și pentru transport înainte de a alege. Un proiect per VRF are în continuare nevoie de etichete de transport pentru loopback-uri și pentru fiecare salt de pe traseu și are în continuare nevoie de starea de adiacență. Dacă rezumatul proiectului numără doar etichetele de serviciu, economisirea este măsurată în registrul greșit.

Feed-urile de rute costă memorie înaintea etichetelor

Fiecare cale primită consumă memorie a planului de control, procesarea actualizărilor și timp de convergență, indiferent dacă VRF-ul folosește o etichetă sau zece mii. Un feed Internet complet într-un VRF este scump din cauza căilor BGP, a RIB-ului, a intrărilor FIB și a agitației din spatele lor, nu din cauza etichetei din fața tabelei. Același feed crește și raza de impact a unei scurgeri de rute sau a unei erori de politică în interiorul acelui chiriaș.

Așadar întrebați ce cere de fapt clientul. Dacă contractul este situri private plus o ieșire implicită, o tabelă completă adaugă cost fără a adăuga o cerință. Este o întrebare comercială și merită un răspuns scris în locul unei presupuneri moștenite din proiectul anterior. Dacă serviciul are într-adevăr nevoie de feed pentru politică sau pentru selecția ieșirii locale, faceți din asta un element explicit, cu propria rezervare de capacitate și propriul comportament la defectare.

Când etichetarea per VRF este valoarea implicită corectă

Este o valoare implicită bună atunci când platforma o documentează ca suportată, când numărul de rute VRF este mare și când costul căutării la ieșire este acceptabil pentru profilul de trafic. Este și alegerea naturală atunci când simplitatea operațională contează mai mult decât stoarcerea ultimei microsecunde din forwarding, pentru că o etichetă per chiriaș este mai ușor de explicat și auditat decât o etichetă per prefix.

Este valoarea implicită greșită atunci când documentația platformei leagă funcția de constrângeri specifice de hardware sau de versiune, sau când proiectul depinde de decizii de forwarding per prefix la ieșire. Citiți propria referință statement a platformei înainte de a presupune comportamentul; comanda Junos este documentată, dar limitele de hardware și de versiune din jurul ei sunt cele care decid de fapt implementarea.

Un buget pe care îl puteți apăra

Construiți cazul de capacitate ca cinci numere separate: căi primite, rute selectate, intrări de forwarding instalate, etichete de serviciu și etichete de transport. Adăugați starea next-hop și de adiacență, numărul de chiriași și modelul de redundanță. Instantaneul căii fericite a unui singur VRF nu este o cifră de scară, iar o dimensiune nominală a spațiului de etichete nu este o tabelă hardware disponibilă.

Apoi conveniți și modul de defectare, nu doar starea stabilă. Ce se întâmplă când feed-ul crește cu jumătate, când un chiriaș adaugă un al doilea VRF sau când platforma are nevoie de o repornire pentru a redimensiona o tabelă? Un buget care rezistă acestor întrebări valorează mai mult decât un număr de etichete care funcționează doar pe hârtie.

Alegeți alocarea după acțiunea la ieșire și limitele platformei, apoi faceți din feed-ul de rute o decizie explicită de serviciu. Eticheta este partea vizibilă a proiectului; rutele sunt partea pentru care trebuie plătit în fiecare zi.