En los productos ADC clásicos, la gestión de rutas típicamente se basa en una única tabla global. Eso es suficiente para despliegues pequeños, pero choca rápidamente con sus límites en escenarios multi-tenant, multi-departamento, MSP, red gubernamental, separación DMZ/interna o migración de centros de datos.
El primer problema es el solapamiento de IP. Diferentes clientes, departamentos o entornos pueden usar los mismos bloques de IP privados. Que dos tenants separados usen ambos 10.0.0.0/8 es muy común en el mundo real. Una única tabla de rutas global no puede separar limpiamente esas dos redes en el mismo appliance.
El segundo problema es la división entre enrutamiento estático y dinámico en dispositivos separados. Si un router aprende rutas mediante BGP/OSPF mientras el ADC consulta su propia tabla estática, la mitad de la decisión de tráfico vive en un dispositivo y la otra mitad en otro. Eso alarga significativamente la depuración — si el ADC está reenviando correctamente, si el router ha aprendido la ruta correcta y de dónde viene la ruta de retorno deben investigarse por separado.
El tercer problema es la dependencia del gateway predeterminado. Un gateway puede aparecer físicamente activo mientras es incapaz de alcanzar el upstream. La configuración clásica no detecta esto; el tráfico sigue enviándose hacia un gateway que parece sano pero en realidad es inalcanzable.
El cuarto problema es la necesidad de enrutamiento basado en origen o en políticas. Parte del tráfico debe salir por WAN1, parte por un túnel VPN, el tráfico de algunos tenants por un enlace MPLS dedicado, y algunos servicios por la salida a internet. Si un ADC gestiona esto con solo una tabla de rutas global, el operador se ve obligado a depender de CLI, scripts o un router externo.
TR7 ADC sitúa el modelo de Route Table en el núcleo del ADC: cada tenant y zona de red toma sus propias decisiones de enrutamiento; las rutas estáticas, las rutas dinámicas, la monitorización de gateway y los flujos de servicio se gestionan todos desde una única consola.
TR7 saca el enrutamiento de una tabla global — cada zona de red vive en su propia Route Table independiente.
En TR7, una Route Table no es simplemente una lista de rutas. Es un contexto de red separado que determina desde qué interfaz llega el tráfico, hacia qué gateway se reenvía, a través de qué reglas de seguridad pasa y qué backend alcanza. Este modelo permite que múltiples zonas de red independientes se ejecuten en el mismo appliance, cada una con su propio plan de IP, gateway, rutas estáticas y comportamiento de enrutamiento dinámico.
Las rutas estáticas pueden definirse a través de la UI de TR7 seleccionando la red de destino, el gateway, la interfaz y la métrica. En despliegues más avanzados, los protocolos de enrutamiento dinámico como BGP, OSPF, RIP e IS-IS también pueden ejecutarse en el mismo contexto de Route Table. El tráfico de gestión puede fijarse mediante rutas estáticas mientras el tráfico de producción sigue rutas aprendidas dinámicamente — ambos dentro del mismo appliance, el mismo modelo de gobernanza y la misma vista operacional.
TR7 admite dirigir el tráfico no solo por IP de destino sino también por señales de política. Un flujo de vService específico puede ir a una WAN redundante, el tráfico de un tenant específico puede dirigirse a un enlace dedicado, y un flujo marcado puede colocarse en una route table diferente. Esto es especialmente valioso para WAN redundante, salida a internet activo/activo, separación de enlaces por tenant, selección de ruta por servicio y escenarios de tránsito inline.
TR7 puede rastrear si un gateway predeterminado es realmente accesible. Tras un número configurado de comprobaciones fallidas, el gateway se marca como no saludable y puede activarse una ruta alternativa o un gateway alternativo. Esto es crítico para detectar el escenario de gateway activo pero upstream caído. El tráfico nunca se envía a la oscuridad — TR7 decide basándose en la accesibilidad real.
El modelo de Route Table de TR7 reúne todas las capacidades de enrutamiento necesarias para despliegues multi-tenant y topologías de red complejas.
Cada Route Table de TR7 toma sus propias decisiones de enrutamiento. Los mismos bloques de IP pueden usarse en diferentes Route Tables sin conflicto. Esto proporciona el aislamiento fundamental requerido para entornos MSP, SaaS, gubernamentales, financieros y multi-cliente.
Los operadores definen la red de destino, el gateway, la métrica y la interfaz directamente desde la UI. Las rutas estáticas se usan principalmente para redes de gestión, enlaces dedicados, rutas redundantes, separación DMZ/interna y segmentos de backend específicos.
En algunas configuraciones WAN o punto a punto, la IP del gateway puede no aparecer dentro de la misma subred. TR7 admite el comportamiento gateway-on-link para tales conexiones, reduciendo la necesidad de pasos manuales adicionales en enlaces WAN dedicados, de túnel o de proveedor de servicios.
TR7 proporciona una infraestructura capaz de ejecutar protocolos de enrutamiento dinámico para equipos de red avanzados. BGP, OSPF, RIP, IS-IS y protocolos similares pueden usarse en el contexto de la Route Table. Esto convierte al ADC en un participante activo de enrutamiento en el centro de datos o la red del tenant en lugar de un dispositivo pasivo que solo entiende rutas estáticas.
Hay disponible una consola dedicada vinculada a la Route Table para la gestión avanzada de comandos y protocolos en el lado del enrutamiento dinámico. Las definiciones de vecinos, la inspección de rutas, el estado de protocolos y la depuración detallada son realizadas por usuarios avanzados a través de esta interfaz. La infraestructura de enrutamiento central y el acceso a la consola están presentes; un editor GUI completamente basado en formularios para toda la gestión de vecinos BGP/OSPF es un área de roadmap separada.
TR7 permite colocar tráfico específico en un comportamiento de enrutamiento diferente. Esto se usa para la selección de ruta por servicio, por tenant o por flujo marcado. El tráfico de gestión puede salir por un gateway estático mientras el tráfico de producción sigue rutas dinámicas; el tráfico de tenants específicos puede colocarse en un enlace VPN mientras el tráfico de VIP específicas se dirige a una WAN redundante.
El gateway predeterminado se comprueba a intervalos regulares. Cuando los fallos superan el umbral configurado, la ruta se marca como no saludable. A continuación puede activarse un gateway alternativo o una ruta alternativa. Esta capacidad mira la accesibilidad real del gateway, no solo el estado del enlace.
Cuando el gateway primario falla, puede realizarse una transición a un gateway secundario. Se usa para redundancia de salida a internet, failover WAN, backup MPLS, backup VPN y escenarios de gateway redundante intra-centro-de-datos.
TR7 no reproduce toda la estructura de enrutamiento en cada cambio. Las rutas agregadas, editadas y eliminadas se diferencian y solo se aplican las rutas que han cambiado. Este enfoque reduce el riesgo en sistemas en vivo y permite que los cambios surtan efecto más rápidamente.
TR7 puede gestionar las estructuras de rutas IPv4 e IPv6 por separado. En entornos dual-stack ambas familias de IP operan juntas bajo el mismo modelo de Route Table.
Cada Route Table puede tener sus propios ajustes de resolución de nombres. Esto es útil para DNS por tenant, resolvers internos privados, entornos de prueba aislados y diferentes escenarios de dominios internos.
En escenarios de cluster HA, qué dispositivo tiene la VIP activa importa para la aplicación de rutas. TR7 gestiona la aplicación de rutas según la lógica del dispositivo activo en alineación con el método de transición de VIP en uso: Only VRRP, TR7 link check, TR7 gateway check y TR7 link and gateway check.
Un vService puede escuchar en una Route Table y reenviar tráfico a backends que residen en una Route Table diferente. Ejemplo: el tráfico de internet entrante se recibe en la Route Table de la DMZ y se reenvía de forma controlada al backend en la Route Table interna. El mismo appliance se convierte en un punto de tránsito controlado entre zonas de red.
Las rutas de gestión pueden mantenerse fijas mientras el tráfico de producción fluye por rutas aprendidas dinámicamente. Los valores de métrica establecen la prioridad. El operador fija las rutas críticas como estáticas y delega los segmentos de red variables a los protocolos dinámicos.
El modelo de Route Table va más allá de la autoría de reglas — también cubre el orden de aplicación, los umbrales del monitor de gateway, el ciclo de vida del enrutamiento dinámico y el manejo de fallos.
Cada ruta se define por los siguientes campos principales: red de destino, gateway, interfaz, métrica, comportamiento gateway-on-link y la Route Table asociada. Esta estructura es suficiente tanto para rutas estáticas simples como para escenarios complejos de múltiples gateways.
La aplicación de rutas depende del estado de las interfaces y las IPs. TR7 aplica primero los cambios del lado de interfaces e IPs, luego activa los cambios de rutas. Este orden elimina una clase de errores donde una ruta está presente pero la interfaz aún no está lista.
El monitor de gateway comprueba a intervalos definidos. Tras un número de fallos consecutivos el gateway se considera no saludable; tras un número de éxitos consecutivos se considera saludable de nuevo. Este enfoque de rise/fall evita que las fluctuaciones transitorias desencadenen route flaps.
La infraestructura de enrutamiento dinámico se ejecuta dentro del contexto de la Route Table. Los servicios de protocolo relevantes se inician, los archivos de configuración se generan, la consola de protocolo se prepara y el proceso de aprendizaje de rutas se vincula a la Route Table relevante.
Si una ruta no puede aplicarse, TR7 evalúa el fallo de forma aislada. Las rutas aplicadas con éxito se preservan y el error de la ruta problemática se hace visible. Esto evita que una única ruta incorrecta corrompa toda la estructura de enrutamiento.
El aislamiento de la Route Table adquiere pleno significado cuando se combina con el aislamiento del firewall. Las rutas de un tenant nunca se mezclan con las reglas de firewall de otro tenant. El tráfico no solo atraviesa la Route Table correcta — también pasa por la política de seguridad correcta.
La IP frontend de un vService puede escuchar dentro de una Route Table específica. El lado del backend puede alcanzarse a través de una Route Table diferente. Esto transforma el ADC de un dispositivo que simplemente reenvía el tráfico entrante a un backend cercano en una gateway de servicio controlada entre zonas de red.
El motor de enrutamiento dinámico y el acceso a la consola están disponibles. Sin embargo, gestionar todos los vecinos, filtros, listas de prefijos y route maps completamente a través de una GUI basada en formularios es un área de roadmap separada. Los equipos de redes avanzados realizan la gestión detallada a través de la consola de protocolo.
Un MSP ejecuta muchos clientes en el mismo appliance TR7. El Cliente A y el Cliente B usan los mismos bloques de IP. Cada cliente está aislado en su propia Route Table de TR7; las rutas, el DNS, las reglas de firewall y los flujos de servicio nunca entran en conflicto.
El tráfico de internet se recibe en la Route Table de la DMZ. Después de que TR7 aplica las políticas WAAP y de acceso, el tráfico se reenvía al backend en la Route Table interna. El plan de IP del backend nunca se expone al mundo exterior.
Algunos servicios salen por la WAN primaria, algunos tenants por una WAN redundante y algunos servicios de gestión por un enlace dedicado. El enrutamiento basado en políticas de TR7 selecciona una ruta diferente para cada clase de tráfico.
TR7 puede aprender rutas dinámicamente desde los routers edge. Cuando se agregan nuevos segmentos de red, ya no es necesario escribir rutas estáticas manualmente. El equipo de redes anuncia las rutas y TR7 usa las rutas actuales en la Route Table relevante.
Si la red interna existente ejecuta OSPF, TR7 puede unirse a esa topología dentro de la Route Table relevante. Las redes de servicio interno se aprenden automáticamente y la gestión de rutas se centraliza.
El gateway primario se vuelve inalcanzable. El monitor de gateway detecta el fallo y el tráfico se mueve al gateway alternativo. El operador no necesita realizar cambios de ruta manuales.
Bloques de IP solapados, enrutamiento dinámico estático + BGP/OSPF y monitorización de gateway. Le mostramos una configuración en vivo en su propia topología de red.