In classic ADC products, route management typically relies on a single global table. That is sufficient for small deployments, but it quickly hits its limits in multi-tenant, multi-department, MSP, government network, DMZ/internal separation or data centre migration scenarios.
The first problem is IP overlap. Different customers, departments or environments may use the same private IP blocks. Having two separate tenants both on 10.0.0.0/8 is very common in the real world. A single global route table cannot cleanly separate those two networks on the same appliance.
The second problem is the split between static and dynamic routing across separate devices. If a router learns routes via BGP/OSPF while the ADC consults its own static table, half of the traffic decision lives on one device and the other half on another. That lengthens debugging significantly — whether the ADC is forwarding correctly, whether the router has learned the right route, and where the return path comes from must all be investigated separately.
The third problem is default gateway dependency. A gateway may appear physically up while being unable to reach upstream. The classic setup does not detect this; traffic continues to be sent toward a gateway that looks healthy but is actually unreachable.
The fourth problem is the need for source-based or policy-based routing. Some traffic must leave via WAN1, some via a VPN tunnel, some tenant traffic via a dedicated MPLS link, and some services via the internet exit. If an ADC manages this with only a global route table, the operator is forced to rely on CLI, scripts or an external router.
TR7 ADC places the Route Table model at the core of the ADC: every tenant and network zone makes its own routing decisions; static routes, dynamic routes, gateway monitoring and service flows are all managed from a single console.
TR7 lifts routing out of a global table — each network zone lives in its own independent Route Table.
In TR7, a Route Table is not merely a list of routes. It is a separate network context that determines from which interface traffic arrives, to which gateway it is forwarded, through which security rules it passes, and which backend it reaches. This model allows multiple independent network zones to run on the same appliance, each with its own IP plan, gateway, static routes and dynamic routing behaviour.
Static routes can be defined through the TR7 UI by selecting the destination network, gateway, interface and metric. In more advanced deployments, dynamic routing protocols such as BGP, OSPF, RIP and IS-IS can also run in the same Route Table context. Management traffic can be pinned via static routes while production traffic follows dynamically learned paths — both within the same appliance, the same governance model and the same operational view.
TR7 supports steering traffic not only by destination IP but also by policy signals. A specific vService flow can go to a redundant WAN, a specific tenant's traffic can be directed to a dedicated link, and a marked flow can be placed on a different route table. This is particularly valuable for redundant WAN, active/active internet exit, per-tenant link separation, per-service route selection and inline transit scenarios.
TR7 can track whether a default gateway is genuinely reachable. After a configured number of failed checks, the gateway is marked unhealthy and an alternative route or alternative gateway can be activated. This is critical for catching the gateway-up-but-upstream-down scenario. Traffic is never sent into the dark — TR7 decides based on actual reachability.
The TR7 Route Table model brings together every routing capability required for multi-tenant deployments and complex network topologies.
Every TR7 Route Table makes its own routing decisions. The same IP blocks can be used in different Route Tables without conflict. This provides the foundational isolation required for MSP, SaaS, government, financial and multi-customer environments.
Operators define the destination network, gateway, metric and interface directly from the UI. Static routes are used primarily for management networks, dedicated links, redundant paths, DMZ/internal separation and specific backend segments.
In some WAN or point-to-point configurations the gateway IP may not appear within the same subnet. TR7 supports gateway-on-link behaviour for such connections, reducing the need for additional manual steps on dedicated WAN, tunnel or service-provider links.
TR7 provides an infrastructure capable of running dynamic routing protocols for advanced networking teams. BGP, OSPF, RIP, IS-IS and similar protocols can be used in the Route Table context. This makes the ADC an active routing participant in the data centre or tenant network rather than a passive device that only understands static routes.
A dedicated console tied to the Route Table is available for advanced command and protocol management on the dynamic routing side. Neighbour definitions, route inspection, protocol state and detailed debugging are performed by advanced users through this interface. The core routing infrastructure and console access are present; a fully form-based GUI editor for all BGP/OSPF neighbour management is a separate roadmap area.
TR7 allows specific traffic to be placed on different routing behaviour. This is used for per-service, per-tenant or per-marked-flow route selection. Management traffic can exit via a static gateway while production traffic follows dynamic routes; specific tenant traffic can be placed on a VPN link while specific VIP traffic is steered to a redundant WAN.
The default gateway is checked at regular intervals. When failures exceed the configured threshold, the route is marked unhealthy. An alternative gateway or alternative route can then be activated. This capability looks at actual gateway reachability, not just link state.
When the primary gateway fails, a transition to a secondary gateway can be made. This is used for internet exit redundancy, WAN failover, MPLS backup, VPN backup and redundant intra-data-centre gateway scenarios.
TR7 does not replay the entire routing structure on every change. Added, edited and deleted routes are differentiated and only the changed routes are applied. This approach reduces risk on live systems and allows changes to take effect more quickly.
TR7 can manage IPv4 and IPv6 route structures separately. In dual-stack environments both IP families operate together under the same Route Table model.
Each Route Table can have its own name resolution settings. This is useful for per-tenant DNS, private internal resolvers, isolated test environments and different internal domain scenarios.
In HA cluster scenarios, which device holds the active VIP matters for route application. TR7 manages route application according to the active-device logic in alignment with the VIP transition method in use: Only VRRP, TR7 link check, TR7 gateway check and TR7 link and gateway check.
A vService can listen on one Route Table and forward traffic to backends residing in a different Route Table. Example: inbound internet traffic is received on the DMZ Route Table and forwarded in a controlled manner to the backend in the internal Route Table. The same appliance becomes a controlled transit point between network zones.
Management routes can be kept fixed while production traffic flows along dynamically learned routes. Metric values set priority. The operator locks critical paths as static and delegates variable network segments to dynamic protocols.
The Route Table model goes beyond rule authoring — it also covers apply ordering, gateway monitor thresholds, dynamic routing lifecycle and fault handling.
Every route is defined by the following core fields: destination network, gateway, interface, metric, gateway-on-link behaviour and the associated Route Table. This structure is sufficient for both simple static routes and complex multi-gateway scenarios.
Route application depends on interface and IP state. TR7 applies interface and IP-side changes first, then activates route changes. This ordering eliminates a class of errors where a route is present but the interface is not yet ready.
The gateway monitor checks at defined intervals. After a number of consecutive failures the gateway is considered unhealthy; after a number of consecutive successes it is considered healthy again. This rise/fall approach prevents transient fluctuations from triggering route flaps.
The dynamic routing infrastructure runs within the Route Table context. The relevant protocol services are started, configuration files are generated, the protocol console is prepared and the route learning process is bound to the relevant Route Table.
If a route cannot be applied, TR7 evaluates the failure in isolation. Successfully applied routes are preserved and the error for the problematic route is surfaced. This prevents a single bad route from corrupting the entire routing structure.
Route Table isolation gains full meaning when combined with firewall isolation. One tenant's routes never mix with another tenant's firewall rules. Traffic does not merely traverse the correct Route Table — it also passes through the correct security policy.
A vService front-end IP can listen within a specific Route Table. The backend side can be reached through a different Route Table. This transforms the ADC from a device that simply forwards incoming traffic to a nearby backend into a controlled service gateway between network zones.
The dynamic routing engine and console access are available. However, managing all neighbours, filters, prefix lists and route maps entirely through a form-based GUI is a separate roadmap area. Advanced networking teams perform detailed management through the protocol console.
An MSP runs many customers on the same TR7 appliance. Customer A and Customer B use the same IP blocks. Each customer is isolated in its own TR7 Route Table; routes, DNS, firewall rules and service flows never conflict.
Internet traffic is received on the DMZ Route Table. After TR7 applies WAAP and access policies, the traffic is forwarded to the backend in the internal Route Table. The backend IP plan is never exposed to the outside world.
Some services exit via the primary WAN, some tenants via a redundant WAN, and some management services via a dedicated link. TR7 policy-based routing selects a different path for each traffic class.
TR7 can learn routes dynamically from edge routers. When new network segments are added, static routes no longer need to be written manually. The networking team announces the routes and TR7 uses the current paths in the relevant Route Table.
If the existing internal network runs OSPF, TR7 can join that topology within the relevant Route Table. Internal service networks are learned automatically and route management is centralised.
The primary gateway becomes unreachable. The gateway monitor detects the failure and traffic is moved to the alternative gateway. The operator does not need to make manual route changes.
Overlapping IP blocks, static + BGP/OSPF dynamic routing and gateway monitoring. Let's walk through a live setup on your own network topology.