Etiqueta por VRF ou por prefixo? A factura real de capacidade

Dous deseños anuncian o mesmo prefixo de cliente polo mesmo núcleo do provedor. Un asigna unha etiqueta por prefixo, o outro asigna unha única etiqueta para todo o VRF, e o segundo parece máis barato en todas as diapositivas. O número de etiquetas é real, pero non é o orzamento que adoita esgotarse primeiro. Decidir entre os dous significa contar catro recursos, non un, e as etiquetas son o máis pequeno deles.

A elección tamén depende do que o encamiñador de saída debe facer co paquete despois de retirar a etiqueta. Esa diferenza funcional, e non a aritmética das etiquetas, debería guiar a decisión.

O que aforra realmente cada asignación

Unha asignación por prefixo leva a información de reenvío na etiqueta. O encamiñador de saída pode enviar o paquete directamente á adxacencia correcta sen unha busca de destino, e por iso escala ben para conxuntos grandes de rutas VRF e por iso consome unha etiqueta por cada prefixo anunciado en cada VRF. Unha asignación por VRF, como Junos vrf-table-label, anuncia unha etiqueta por instancia de encamiñamento e usa esa etiqueta para seleccionar a táboa VRF; o encamiñador realiza despois unha busca IP dentro da táboa.

Iso é unha diferenza arquitectónica real e non un axuste. O etiquetado por VRF dá un espazo de etiquetas menor e un anuncio de etiquetas máis simple, a cambio dunha busca e dunha etiqueta que non di nada sobre o destino. O etiquetado por prefixo dá á tarxeta de liña de saída máis información por adiantado e custa etiquetas en proporción ás rutas que transportas.

O libro de etiquetas é o pequeno

As etiquetas MPLS son finitas, pero o espazo de etiquetas é abondo grande como para que os provedores de servizos comúns non o esgoten con uns poucos milleiros de prefixos. Onde o etiquetado por VRF axuda de verdade é en plataformas con táboas de etiquetas de hardware pequenas, ou en deseños nos que un único VRF transporta unha fonte completa de Internet e as etiquetas por prefixo multiplicarían a demanda de etiquetas polo número de rutas. Esas son restricións reais, e son a razón de que a funcionalidade exista. Ningunha delas ten que ver co número de prefixos na táboa.

Conta as etiquetas tanto do servizo como do transporte antes de elixir. Un deseño por VRF aínda necesita etiquetas de transporte para os loopbacks e para cada salto ao longo do camiño, e aínda necesita estado de adxacencia. Se o prego de deseño só conta as etiquetas de servizo, o aforro estase a medir no libro contable equivocado.

As fontes de rutas custan memoria antes ca etiquetas

Cada camiño recibido consome memoria do plano de control, procesamento de actualizacións e tempo de converxencia, tanto se o VRF usa unha etiqueta coma dez mil. Unha fonte completa de Internet dentro dun VRF é custosa polos camiños BGP, a RIB, as entradas FIB e a axitación que hai detrás, non pola etiqueta que precede a táboa. A mesma fonte tamén aumenta o radio de impacto dunha fuga de rutas ou dun erro de política dentro dese inquilino.

Pregunta, pois, que require realmente o cliente. Se o contrato é de sitios privados máis unha saída por defecto, unha táboa completa engade custo sen engadir un requisito. Iso é unha cuestión comercial, e merece unha resposta escrita en vez dunha suposición herdada do deseño anterior. Se o servizo necesita de verdade a fonte para políticas ou para a selección de saída local, fai diso unha liña explícita coa súa propia reserva de capacidade e o seu propio comportamento ante fallos.

Cando o etiquetado por VRF é o valor predeterminado correcto

É un bo valor predeterminado cando a plataforma o documenta como compatíbel, cando o número de rutas do VRF é grande e cando o custo da busca na saída é aceptábel para o perfil de tráfico. Tamén é a opción natural cando a simplicidade operativa importa máis ca raspar o último microsegundo ao reenvío, porque unha etiqueta por inquilino é máis doada de explicar e auditar ca unha etiqueta por prefixo.

É o valor predeterminado incorrecto cando a documentación da plataforma vincula a funcionalidade a restricións específicas de hardware ou de versión, ou cando o deseño depende de decisións de reenvío por prefixo na saída. Le a propia referencia de sentenzas da plataforma antes de supor o comportamento; o comando de Junos está documentado, pero son os límites de hardware e de versión que o rodean os que deciden realmente o despregue.

Un orzamento que podes defender

Constrúe o caso de capacidade como cinco números separados: camiños recibidos, rutas seleccionadas, entradas de reenvío instaladas, etiquetas de servizo e etiquetas de transporte. Engade o estado de next-hop e de adxacencia, o número de inquilinos e o modelo de redundancia. A instantánea do camiño feliz dun único VRF non é unha cifra de escala, e un tamaño nominal do espazo de etiquetas non é unha táboa de hardware dispoñíbel.

Acorda despois o modo de fallo ademais do réxime permanente. Que ocorre cando a fonte medra á metade, cando un inquilino engade un segundo VRF ou cando a plataforma precisa un reinicio para redimensionar unha táboa? Un orzamento que sobrevive a esas preguntas vale máis ca un número de etiquetas que só funciona sobre o papel.

Elixe a asignación a partir da acción na saída e dos límites da plataforma, e despois fai da fonte de rutas unha decisión de servizo explícita. A etiqueta é a parte visíbel do deseño; as rutas son a parte que hai que pagar todos os días.