Etiqueta per VRF o per prefix? El compte real de capacitat

Dos dissenys anuncien el mateix prefix de client pel mateix nucli del proveïdor. Un assigna una etiqueta per prefix, l'altre assigna una sola etiqueta per a tot el VRF, i el segon sembla més barat a cada diapositiva. El nombre d'etiquetes és real, però no és el pressupost que normalment s'esgota primer. Triar entre els dos vol dir comptar quatre recursos, no un, i les etiquetes són el més petit de tots.

L'elecció també depèn del que el router de sortida ha de fer amb el paquet després de treure l'etiqueta. Aquesta diferència funcional, no l'aritmètica de les etiquetes, ha de guiar la decisió.

Què estalvia realment cada assignació

L'assignació per prefix porta la informació de reenviament a l'etiqueta. El router de sortida pot enviar el paquet directament a l'adjacència correcta sense una consulta de destinació, per això escala bé amb conjunts grans de rutes VRF i per això consumeix una etiqueta per cada prefix anunciat a cada VRF. L'assignació per VRF, com Junos vrf-table-label, anuncia una etiqueta per instància d'encaminament i utilitza aquesta etiqueta per seleccionar la taula VRF; després el router fa una consulta IP dins de la taula.

És una diferència arquitectònica real, no un paràmetre d'ajust. L'etiquetatge per VRF dona un espai d'etiquetes més petit i un anunci més simple, a canvi d'una consulta i d'una etiqueta que no diu res sobre la destinació. L'etiquetatge per prefix dona més informació per endavant a la targeta de línia de sortida i costa etiquetes en proporció a les rutes que transporta.

El llibre d'etiquetes és el petit

Les etiquetes MPLS són finites, però l'espai d'etiquetes és prou gran perquè els proveïdors habituals no l'esgotin amb uns quants milers de prefixos. On l'etiquetatge per VRF ajuda de debò és en plataformes amb taules d'etiquetes de maquinari petites, o en dissenys on un sol VRF porta un feed complet d'Internet i les etiquetes per prefix multipliquen la demanda d'etiquetes pel nombre de rutes. Són restriccions reals, i són la raó per la qual existeix la funció. Cap d'elles no tracta del nombre de prefixos a la taula.

Compteu etiquetes tant per al servei com per al transport abans de triar. Un disseny per VRF encara necessita etiquetes de transport per als loopbacks i per a cada salt del camí, i encara necessita estat d'adjacència. Si el plec de disseny només compta etiquetes de servei, l'estalvi es mesura al llibre equivocat.

Els feeds de rutes costen memòria abans que etiquetes

Cada camí rebut consumeix memòria del pla de control, processament d'actualitzacions i temps de convergència, tant si el VRF fa servir una etiqueta com deu mil. Un feed complet d'Internet dins d'un VRF és car per les rutes BGP, la RIB, les entrades de FIB i els canvis que hi ha al darrere, no per l'etiqueta que encapçala la taula. El mateix feed també amplia l'abast d'un vessament de rutes o d'un error de política dins d'aquest client.

Per tant, pregunteu què necessita realment el client. Si el contracte és de seus privades més una sortida per defecte, una taula completa afegeix cost sense afegir cap requisit. És una qüestió comercial i mereix una resposta escrita, no una suposició heretada del disseny anterior. Si el servei necessita de debò el feed per a la política o per a la selecció de sortida local, feu-ne una línia explícita amb la seva reserva de capacitat i el seu comportament de fallada.

Quan l'etiquetatge per VRF és el valor per defecte correcte

És un bon valor per defecte quan la plataforma el documenta com a suportat, quan el nombre de rutes VRF és gran i quan el cost de la consulta de sortida és acceptable per al perfil de trànsit. També és l'opció natural quan la simplicitat operativa importa més que esprémer l'últim microsegon del reenviament, perquè una etiqueta per client és més fàcil d'explicar i auditar que una etiqueta per prefix.

És el valor per defecte equivocat quan la documentació de la plataforma lliga la funció a maquinari o limitacions de versió concretes, o quan el disseny depèn de decisions de reenviament per prefix a la sortida. Llegiu la referència de la plataforma sobre l'afirmació abans de suposar el comportament; l'ordre Junos està documentada, però els límits de maquinari i de versió que l'envolten són els que decideixen el desplegament.

Un pressupost que podeu defensar

Construïu el cas de capacitat com cinc números separats: camins rebuts, rutes seleccionades, entrades de reenviament instal·lades, etiquetes de servei i etiquetes de transport. Afegiu estat de següent salt i d'adjacència, nombre de clients i el model de redundància. Una foto del camí feliç d'un sol VRF no és una xifra d'escala, i una mida nominal de l'espai d'etiquetes no és una taula de maquinari disponible.

Després acordeu el mode de fallada així com l'estat estable. Què passa quan el feed creix a la meitat, quan un client afegeix un segon VRF o quan la plataforma necessita un reinici per redimensionar una taula? Un pressupost que sobreviu a aquestes preguntes val més que un recompte d'etiquetes que només funciona sobre el paper.

Trieu l'assignació a partir de l'acció de sortida i dels límits de la plataforma, i feu després del feed de rutes una decisió de servei explícita. L'etiqueta és la part visible del disseny; les rutes són la part que s'ha de pagar cada dia.