The classic ADC routing model is inadequate for multi-tenant networks.
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.
Our approach
TR7 lifts routing out of a global table — each network zone lives in its own independent Route Table.
TR7 Route Table isolation
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 and dynamic routing together
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.
Policy-based routing
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.
Gateway monitor and automatic failover
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.
Capabilities
The TR7 Route Table model brings together every routing capability required for multi-tenant deployments and complex network topologies.
Per-Route-Table independent routing
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.
Route Health Injection — the address is advertised only while the service is healthy
The service address is announced into BGP or OSPF only while the services behind it pass their health checks, and withdrawn within seconds when they do not — so upstream routers stop sending traffic to a site that cannot serve it, without anyone opening a ticket. Only the node actually holding the address advertises it, which is what stops a cluster failover from turning into a routing black hole. BFD brings failure detection down to sub-second.
Static route management
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.
Gateway-on-link support
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.
Dynamic routing protocol infrastructure
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. Dynamic routing is stated per address family, because it is two protocols and not one: OSPFv2 carries IPv4 and OSPFv3 carries IPv6, so a dual-stack network does not run out of routing halfway through its IPv6 migration.
Neighbours in forms, raw config and console still yours
BGP peers and OSPF areas are defined in the interface as forms — router address, AS numbers, authentication, a BFD checkbox that brings failure detection under a second, and an advertise-this-address switch that turns on Route Health Injection — and TR7 generates the routing configuration from them. Deeper protocol work is not walled off: a raw configuration field is appended to what TR7 generates and is never overwritten, and the protocol console stays for reading state and debugging in the language of the protocol.
Policy-based routing
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.
Gateway monitor
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.
Default gateway failover
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.
Next-hop load distribution (NHLD)
Outbound traffic is distributed across several upstream gateways, with per-link health tracking. A failed link is withdrawn within seconds, and connection marking keeps an established flow on the link it started on, so return traffic stays symmetric and stateful devices upstream never see half a conversation. This is the multi-WAN answer for sites with two or more internet providers.
Delta route sync
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.
IPv4 and IPv6 route support
TR7 can manage IPv4 and IPv6 route structures separately. In dual-stack environments both IP families operate together under the same Route Table model.
Per-Route-Table DNS and hosts management
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.
Cluster-aware route behaviour
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.
Cross-Route-Table service flow via vService
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.
Static + dynamic hybrid routing
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.
Operational depth
The Route Table model goes beyond rule authoring — it also covers apply ordering, gateway monitor thresholds, dynamic routing lifecycle and fault handling.
Route entry model
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.
Apply ordering
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.
Gateway monitor thresholds
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.
Dynamic routing lifecycle
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.
Rollback logic on route failures
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 and Firewall relationship
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.
Route Table and vService relationship
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.
Peer and area definitions under the same change control
Peer and area definitions go through the same validate-then-apply flow as the rest of the configuration, and every change is recorded in the audit log with who made it. What the forms do not express — detailed filtering, route maps, protocol tuning — belongs in the raw configuration field, which is stored with the object and preserved every time the configuration is regenerated. Teams that prefer the protocol console keep working exactly as before.
vDevices — hardware-grade virtual appliances inside one chassis
A Route Table isolates routing. A vDevice goes further and isolates the whole appliance: each one owns its interfaces, its firewall, its route tables, its own L4 DDoS protection set and its own DNS, and vDevices are allocated per user. A DDoS storm against one vDevice is contained by design rather than by tuning, which is what makes a single chassis usable as several independent devices.
When to use it
MSP multi-tenant routing
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.
DMZ-to-internal backend transit
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.
Redundant WAN and source-based routing
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.
BGP integration with the data centre
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.
Adding the ADC to an OSPF area
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.
Default gateway failover
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.
Frequently asked questions
Can two tenants using the same IP block run on the same TR7 appliance?
Can static and dynamic routes coexist in the same Route Table?
Is BGP and OSPF configuration done directly from the UI?
How does gateway monitoring work and when is failover triggered?
Can a vService forward traffic to a backend in a different Route Table from the one it listens on?
Does Route Table isolation require an additional licence?
Can outbound traffic be balanced across two internet lines at the same time?
Per-tenant independent routing — managed from one console
Overlapping IP blocks, static + BGP/OSPF dynamic routing and gateway monitoring. Let's walk through a live setup on your own network topology.