Dominios de ruta y VRF de MPLS en F5: mapear la entrega del inquilino
Dos inquilinos, una dirección, dos dominios de ruta. Fije cada objeto con %ID, use el VRF y los objetivos de ruta del proveedor y verifique cada inquilino por separado.
Dos inquilinos ejecutan la misma aplicación en 10.50.0.10. El proveedor los mantiene separados en VPN MPLS distintas, y el BIG-IP guarda su tráfico local en dominios de ruta distintos. Ese arreglo funciona hasta la entrega, donde un sufijo ausente o un objetivo de ruta copiado coloca en silencio el paquete de un inquilino en el contexto del otro. Esta guía une los dos modelos y termina con una prueba por inquilino.
Hoja de trabajo: una fila por inquilino
Rellénela antes de cambiar nada. Cada paso posterior se refiere a una celda de la hoja, y una celda vacía es una decisión que nadie ha tomado todavía.
| Tenant | BIG-IP side | Provider side |
|---|---|---|
| A | VLAN or tunnel, route domain, self address, virtual server | VRF, attachment, route targets for import and export |
| B | Separate VLAN or tunnel, separate route domain, separate self address | Separate VRF, separate route targets |
Paso 1: fije cada objeto a su dominio de ruta
La documentación de dominios de ruta de F5 describe contextos de tráfico aislados, direcciones duplicadas y la notación address%ID para objetos de configuración. Una dirección escrita como 10.50.0.10%2 nombra el contexto local del dominio de ruta, y ese sufijo no es una etiqueta MPLS que viaje en el paquete IP del cliente.
Una VLAN o un túnel compatible pertenece a un solo dominio de ruta en el modelo documentado, así que la interfaz y la dirección deben coincidir. Revise también el dominio de ruta predeterminado de la partición administrativa, porque un sufijo omitido no significa que no haya contexto; significa el contexto que la partición usa por defecto. Ese único valor predeterminado explica la mayoría de los incidentes en los que un objeto nuevo respondía en silencio al inquilino equivocado. Compruébelo antes de añadir una dirección propia.
tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vsPaso 2: use el VRF y los objetivos de ruta del proveedor
En el borde MPLS, el inquilino se identifica por el VRF del proveedor y el servicio de enrutamiento acordado para el cliente. Los objetivos de ruta controlan qué rutas importa y exporta el proveedor entre VRF, y elegir un número de dominio de ruta de BIG-IP parecido no crea nada de esa relación.
Los dos identificadores viven en sistemas distintos y significan cosas distintas. Un ID de dominio de ruta es un contexto local en el dispositivo. Un objetivo de ruta es un atributo de política del lado del proveedor que decide la distribución de rutas, y un distinguidor de ruta es aún una tercera cosa, usada para mantener separados prefijos que de otro modo serían idénticos.
Paso 3: decida si los contextos pueden compartir alcance
Revise a propósito los ajustes de búsqueda en el dominio padre y de aislamiento estricto, porque cambian a qué puede llegar un contexto. La guía de F5 permite el reenvío controlado a través de esas relaciones, y por eso mismo un dominio de ruta no debe tratarse por sí solo como una política de seguridad completa del inquilino.
Si ambos inquilinos necesitan un servicio compartido, especifique la ruta y los permisos aprobados en lugar de apuntar sin más a un inquilino al contexto de enrutamiento del otro. Conserve la identidad de la aplicación y cualquier traducción de origen intencionada junto con el destino de red, o el servicio compartido verá a un inquilino como el otro.
Una entrega enrutada normal conecta el BIG-IP con un router de borde del proveedor sin convertir al BIG-IP en un PE MPLS. Si de verdad hace falta una integración directa de MPLS o de la familia de rutas VPN, obtenga soporte explícito para la plataforma y la versión exactas, porque el aislamiento local del dominio de ruta no establece esa capacidad.
Paso 4: verifique un inquilino a la vez
Pruebe el inquilino A desde un extremo en el contexto de A hasta la dirección de aplicación de A, y después repita para B. Use la forma %ID en los diagnósticos para poder demostrar qué contexto respondió, y confirme que una petición del contexto equivocado falla en lugar de aterrizar en algún lugar verosímil.
Revise el lado del proveedor en la misma pasada: el prefijo está en el VRF correcto, los objetivos de ruta coinciden con la hoja de trabajo y el camino de vuelta usa la conexión prevista. Un ping que funciona desde el propio dispositivo demuestra el contexto del dispositivo, no el del inquilino.
Registre la asignación final en la hoja de trabajo, incluido el dominio de ruta predeterminado de cada partición y cualquier relación de dominio padre que haya habilitado. El próximo cambio en este entorno lo hará alguien que lea esa tabla, no alguien que lea este artículo.