¿Etiqueta por VRF o por prefijo? La factura real de capacidad

Dos diseños anuncian el mismo prefijo de cliente por el mismo núcleo del proveedor. Uno asigna una etiqueta por prefijo, el otro asigna una sola etiqueta para todo el VRF, y el segundo parece más barato en cada diapositiva. El número de etiquetas es real, pero no suele ser el presupuesto que se agota primero. Elegir entre ambos significa contar cuatro recursos, no uno, y las etiquetas son el más pequeño de ellos.

La elección también depende de lo que el router de salida debe hacer con el paquete después de extraer la etiqueta. Esa diferencia funcional, no la aritmética de etiquetas, debería guiar la decisión.

Qué ahorra realmente cada asignación

La asignación por prefijo lleva la información de reenvío en la etiqueta. El router de salida puede enviar el paquete directamente a la adyacencia correcta sin una búsqueda de destino, por eso escala bien con conjuntos grandes de rutas VRF y por eso consume una etiqueta por cada prefijo anunciado en cada VRF. La asignación por VRF, como Junos vrf-table-label, anuncia una etiqueta por instancia de enrutamiento y usa esa etiqueta para seleccionar la tabla VRF; el router realiza después una búsqueda IP dentro de la tabla.

Es una diferencia arquitectónica real, no un parámetro de ajuste. El etiquetado por VRF ofrece un espacio de etiquetas más pequeño y un anuncio más simple, a costa de una búsqueda y de una etiqueta que no dice nada sobre el destino. El etiquetado por prefijo da más información por adelantado a la tarjeta de línea de salida y cuesta etiquetas en proporción a las rutas que transporta.

El libro de etiquetas es el pequeño

Las etiquetas MPLS son finitas, pero el espacio de etiquetas es lo bastante grande como para que los proveedores habituales no lo agoten con unos miles de prefijos. Donde el etiquetado por VRF ayuda de verdad es en plataformas con tablas de etiquetas de hardware pequeñas, o en diseños donde un solo VRF transporta un feed completo de Internet y las etiquetas por prefijo multiplicarían la demanda de etiquetas por el número de rutas. Son restricciones reales, y son la razón por la que existe la función. Ninguna de ellas tiene que ver con el número de prefijos de la tabla.

Cuente etiquetas tanto para el servicio como para el transporte antes de elegir. Un diseño por VRF aún necesita etiquetas de transporte para los loopbacks y para cada salto del camino, y aún necesita estado de adyacencia. Si el pliego de diseño solo cuenta etiquetas de servicio, el ahorro se mide en el libro equivocado.

Los feeds de rutas cuestan memoria antes que etiquetas

Cada ruta recibida consume memoria del plano de control, procesamiento de actualizaciones y tiempo de convergencia, tanto si el VRF usa una etiqueta como diez mil. Un feed completo de Internet dentro de un VRF es caro por las rutas BGP, la RIB, las entradas de FIB y los cambios que hay detrás, no por la etiqueta que encabeza la tabla. El mismo feed también amplía el alcance de un derrame de rutas o de un error de política dentro de ese inquilino.

Así que pregunte qué necesita realmente el cliente. Si el contrato son sedes privadas más una salida por defecto, una tabla completa añade costo sin añadir un requisito. Es una cuestión comercial y merece una respuesta escrita en lugar de una suposición heredada del diseño anterior. Si el servicio necesita de verdad el feed para la política o para la selección de salida local, hágalo una partida explícita con su propia reserva de capacidad y su propio comportamiento ante fallos.

Cuándo el etiquetado por VRF es el valor por defecto correcto

Es un buen valor por defecto cuando la plataforma lo documenta como compatible, cuando el número de rutas VRF es grande y cuando el costo de la búsqueda de salida es aceptable para el perfil de tráfico. También es la opción natural cuando la simplicidad operativa importa más que exprimir el último microsegundo al reenvío, porque una etiqueta por inquilino es más fácil de explicar y auditar que una etiqueta por prefijo.

Es el valor por defecto equivocado cuando la documentación de la plataforma vincula la función a hardware o limitaciones de versión concretos, o cuando el diseño depende de decisiones de reenvío por prefijo en la salida. Lea la referencia de la propia plataforma sobre la afirmación antes de suponer el comportamiento; el comando Junos está documentado, pero los límites de hardware y de versión que lo rodean son los que deciden el despliegue.

Un presupuesto que puede defender

Construya el caso de capacidad como cinco números separados: rutas recibidas, rutas seleccionadas, entradas de reenvío instaladas, etiquetas de servicio y etiquetas de transporte. Añada estado de siguiente salto y de adyacencia, número de inquilinos y el modelo de redundancia. Una instantánea del camino feliz de un solo VRF no es una cifra de escala, y un tamaño nominal del espacio de etiquetas no es una tabla de hardware disponible.

Después acuerde el modo de fallo además del estado estable. ¿Qué ocurre cuando el feed crece a la mitad, cuando un inquilino añade un segundo VRF o cuando la plataforma necesita un reinicio para redimensionar una tabla? Un presupuesto que sobrevive a esas preguntas vale más que un recuento de etiquetas que solo funciona sobre el papel.

Elija la asignación a partir de la acción de salida y de los límites de la plataforma, y haga después del feed de rutas una decisión de servicio explícita. La etiqueta es la parte visible del diseño; las rutas son la parte que hay que pagar cada día.