Uno de los problemas más difíciles en las redes empresariales es gestionar diferentes dominios de red en el mismo dispositivo de forma segura y sin conflictos de direcciones. En entornos MSP, administración pública, finanzas, sanidad y multi-tenant, cada tenant puede traer su propio plan de IP. La reutilización del mismo bloque CIDR entre distintos clientes es habitual.
La separación clásica de rutas generalmente aísla solo la tabla de enrutamiento. El aislamiento verdadero, sin embargo, requiere más que rutas — las interfaces, ARP, firewall, socket y el comportamiento de conexión también deben separarse. Sin ello, el `10.0.0.5` del Tenant A y el `10.0.0.5` del Tenant B se vuelven operacional y a nivel de seguridad peligrosos en el mismo dispositivo.
Un segundo problema surge cuando los servicios deben permanecer en diferentes dominios de red. Una VIP debe escuchar en el lado de la DMZ, el backend debe mantenerse en la red interna, el tráfico de gestión debe confinarse a su propia route table, o las redes antigua y nueva deben coexistir durante la migración. Fusionar forzosamente estos dominios rompe la segmentación de seguridad y el orden operacional.
El enfoque correcto es aislar cada dominio de red dentro de su propia route table y proporcionar cruce controlado a nivel de vService. Un vService debe poder escuchar en múltiples route tables y reenviar tráfico a backends en diferentes route tables.
El Enrutamiento Cross-NS de TR7 satisface esta necesidad: crea dominios de red aislados en un único dispositivo, separa los planes de IP solapados y convierte el vService en un puente de tráfico controlado entre route tables.
TR7 implementa una arquitectura multi-dominio de red mediante aislamiento de route tables, enrutamiento cross-domain, gestión de procesos por tabla y ciclo de vida gestionado desde la UI.
Cada route table tiene su propio enrutamiento, interfaces, ARP, firewall y namespace de sockets. Los tenants, zonas de servicio o entornos de prueba pueden ejecutarse en el mismo dispositivo sin interferirse entre sí.
Un único vService puede escuchar VIPs en múltiples route tables y reenviar tráfico a backends en diferentes route tables. Esto permite la transferencia controlada de servicios sin aplanar la red.
TR7 puede ejecutar un proceso separado de monitorización y gestión de red para cada route table. El estado de los enlaces, las direcciones IP, las rutas, las estadísticas y el estado de los servicios se recopilan de forma independiente para cada dominio de red.
Los operadores pueden crear, eliminar, nombrar y configurar ajustes de DNS y hosts para las route tables. A qué route table pertenece una interfaz también puede cambiarse desde la consola de gestión.
La Arquitectura Multi-Namespace hace que diferentes dominios de red sean manejables en un único ADC — desde el aislamiento de tenants hasta el enrutamiento cross-service.
Una route table de TR7 no es simplemente una lista separada de rutas. Las interfaces, ARP, firewall, socket y el comportamiento de conexión operan de forma independiente dentro del dominio. El comportamiento de red de un tenant no puede filtrarse hacia otro. Los equipos de operaciones gestionan múltiples dominios de red en el mismo dispositivo de forma más segura y legible.
En entornos multi-tenant, distintos clientes pueden usar los mismos bloques de IP privados. Las route tables de TR7 mantienen estos planes de direcciones solapados en dominios de red separados. El `10.0.0.5` del Tenant A y el `10.0.0.5` del Tenant B pueden coexistir en el mismo dispositivo con significados distintos. Esto otorga a las arquitecturas MSP y de sovereign cloud una flexibilidad sustancial en la planificación de IP.
El frontend del vService no está limitado a un único dominio de red. El mismo servicio puede escuchar en diferentes VIPs a través de route tables de producción, DMZ, gestión o de tenant. Puede aplicarse una política o selección de backend diferente según desde qué route table llegue el cliente. Este modelo simplifica los escenarios de publicación multi-red sin duplicar instancias de servicio.
TR7 puede tomar el tráfico que llega en una route table y reenviarlo a un backend en una route table diferente. La VIP puede permanecer en la DMZ mientras el backend está en la red interna; la red del tenant puede mantenerse separada mientras la red de servicio compartido vive en su propia route table. Solo los flujos de servicio permitidos pasan a través de TR7 — las redes nunca se fusionan. La segmentación se preserva mientras el acceso a las aplicaciones se simplifica.
A qué route table pertenece una interfaz física o virtual puede gestionarse desde TR7. Esto es práctico durante migraciones, traslados de tenants o transiciones de prueba a producción. El impacto sobre rutas, IPs y servicios al mover una interfaz debe evaluarse en su totalidad. Los equipos de operaciones no tienen que tratar los dominios de red como estructuras estáticas e inamovibles.
Un par V-ETH(peer) puede usarse para crear una conexión virtual controlada entre dos route tables diferentes. Esto es valioso cuando solo rutas de tráfico específicas y definidas necesitan cruzar entre dominios que de otro modo están completamente aislados. Aplicable a escenarios de prueba, migración, uso compartido de servicios y acceso de tenants a servicios compartidos. La conexión sigue estando gobernada por las políticas de TR7 y las reglas de firewall.
Cada route table puede operar con sus propios registros DNS y hosts. El mismo hostname puede resolverse a una IP diferente en distintas route tables de tenants, o un entorno de prueba puede usar una resolución de nombres diferente a la de producción. Esta separación reduce los conflictos de hostname en entornos multi-tenant y escenarios de migración. Los operadores gestionan el comportamiento DNS a nivel de dominio de red, no de forma global.
Cada route table dinámica puede ejecutar su propio proceso de enrutamiento. El comportamiento de enrutamiento dinámico con BGP, OSPF o protocolos similares puede aislarse por tenant o dominio de red. Un cambio de ruta en el dominio de un tenant no afecta al plano de enrutamiento de otro tenant. Esta es una ventaja de seguridad y operacional significativa en arquitecturas MSP y empresariales multi-región.
TR7 puede aplicar una gestión de firewall separada para cada route table. Las reglas, ipsets y permisos de tráfico operan dentro del dominio de red relevante. Un puerto abierto o un permiso concedido a un tenant no se propaga automáticamente a los servicios de otro tenant. Los equipos de seguridad pueden definir el alcance de las políticas con mayor precisión.
Las estadísticas de enlace, IP, ruta y tráfico pueden recopilarse por separado para cada route table. Los equipos de operaciones pueden ver qué enlace, IP o ruta está causando un problema en qué dominio de red de forma aislada. Esta visibilidad reduce el tiempo de resolución de problemas en entornos multi-dominio. Los entornos que se ejecutan en un único dispositivo se monitorizan en vistas claramente separadas.
Un health check puede verificar no solo si el backend está activo, sino también si es accesible desde la route table relevante. Un check emitido desde el dominio de red del frontend hacia un backend en una route table diferente ejerce la ruta de tráfico real — validando el atravesamiento de ruta, ARP y firewall, no solo la disponibilidad del servicio. Esto ofrece una confianza operacional crítica en configuraciones de enrutamiento cross-network.
El comportamiento de múltiples route tables es una parte nativa de la arquitectura de red de TR7. Los operadores no necesitan aprovisionar un dispositivo virtual separado por tenant. El aislamiento, el enrutamiento y la transferencia de servicios en el mismo ADC permanecen dentro de un único plano de gestión. Esto reduce tanto el consumo de recursos como la complejidad operacional.
La arquitectura multi-route-table se opera con gestión completa del ciclo de vida, migración de interfaces, recuperación de procesos, DNS/hosts por tabla y coordinación de estado cross-domain.
Cuando un operador crea una nueva route table, TR7 prepara un contexto de ejecución separado para ese dominio de red. Este dominio lleva su propio comportamiento de interfaces, rutas y firewall. Los campos de nombre y descripción ayudan a los equipos de operaciones a distinguir tenants o zonas de servicio entre sí.
Eliminar una route table que todavía tiene interfaces asignadas se considera no seguro. El comportamiento predeterminado bloquea la eliminación hasta que las interfaces se migran. Si es necesario, las interfaces pueden regresarse al dominio predeterminado primero, haciendo la eliminación controlada y explícita.
Si el proceso de monitorización y gestión que se ejecuta para una route table termina inesperadamente, puede reiniciarse automáticamente. Esto preserva la continuidad del comportamiento de monitorización multi-dominio. Los equipos de operaciones no pierden permanentemente la visibilidad de un dominio de red debido a un único fallo de proceso.
Cuando una interfaz se mueve de una route table a otra, el impacto sobre IPs, rutas, servicios y reglas de firewall debe evaluarse en conjunto. La operación es potente para propósitos de migración pero debe planificarse en entornos de producción. TR7 hace visible este comportamiento en la UI, reduciendo el riesgo de movimientos no deseados.
Puede establecerse mensajería basada en eventos entre el proceso principal de gestión y cada proceso de route table. El estado de los enlaces, el estado de las IPs, la información GTM y las señales de servicio se entregan por separado a cada dominio de red. Esto proporciona coordinación controlada entre la gestión global y los dominios de red aislados.
Puede asignarse un valor de índice a cada route table. Este índice se usa para derivar puertos de enrutamiento dinámico, offsets de ID de router virtual e identificadores de procesos auxiliares por servicio. Los conflictos de puertos e identidades entre múltiples dominios de red se reducen así.
Un MSP puede ejecutar múltiples clientes que todos usan el bloque de direcciones `10.0.0.0/8` en un único TR7 ADC, cada uno en su propia route table. Cada tenant permanece aislado en su propio dominio de red sin ningún conflicto de IP.
Las organizaciones pueden mantener la VIP escuchando en la route table de la DMZ mientras el backend permanece en la route table interna. TR7 transporta solo el tráfico de servicio permitido entre los dos dominios — sin fusionarlos.
Cuando un servicio se está moviendo de una red de tenant antigua a una nueva route table, el tráfico del vService puede redirigirse de forma controlada. El plan de IP y el acceso al servicio se gestionan juntos durante toda la migración.
Una route table de prueba puede ejecutarse con ajustes similares a los de producción pero sin acceso directo al tráfico de producción. El equipo de operaciones puede probar servicios específicos mediante enrutamiento cross-route-table cuando sea necesario, mientras preserva el aislamiento.
Planes de IP solapados, enrutamiento de DMZ a red interna y arquitectura de route tables multi-tenant. Le mostramos una configuración en vivo en su propio entorno.