One of the hardest problems in enterprise networking is managing different network domains on the same device safely and without address conflicts. In MSP, government, finance, healthcare and multi-tenant environments, every tenant may bring its own IP plan. Reusing the same CIDR block across different customers is common.
Classic route separation usually isolates only the routing table. True isolation, however, requires more than routes — interfaces, ARP, firewall, socket and connection behavior must all be separated. Without that, Tenant A's `10.0.0.5` and Tenant B's `10.0.0.5` become operationally and security-wise risky on the same device.
A second problem arises when services must remain in different network domains. A VIP should listen on the DMZ side, the backend should stay on the internal network, management traffic should be confined to its own route table, or old and new networks must coexist during migration. Forcibly merging these domains breaks security segmentation and operational order.
The right approach is to isolate each network domain inside its own route table and provide controlled crossing at the vService level. A vService should be able to listen on multiple route tables and forward traffic to backends in different route tables.
TR7 Cross-NS Routing meets this need: it creates isolated network domains on a single device, separates overlapping IP plans and turns the vService into a controlled traffic bridge between route tables.
TR7 implements a multi-network-domain architecture through route table isolation, cross-domain routing, per-table process management and UI-driven lifecycle.
Each route table has its own routing, interfaces, ARP, firewall and socket namespace. Tenants, service zones or test environments can therefore run on the same device without interfering with each other.
A single vService can listen for VIPs on multiple route tables and forward traffic to backends in different route tables. This enables controlled service handoff without flattening the network.
TR7 can run a separate network monitoring and management process for each route table. Link state, IP addresses, routes, statistics and service health are collected independently for every network domain.
Operators can create, delete, name and configure DNS and hosts settings for route tables. Which route table an interface belongs to can also be changed from the management console.
Multi-Namespace Architecture makes different network domains manageable on a single ADC — from tenant isolation to cross-service routing.
A TR7 route table is not just a separate list of routes. Interface, ARP, firewall, socket and connection behavior all operate independently within the domain. One tenant's network behavior cannot bleed into another's. Operations teams manage multiple network domains on the same device more safely and legibly.
In multi-tenant environments, different customers may use the same private IP blocks. TR7 route tables keep these overlapping address plans in separate network domains. Tenant A's `10.0.0.5` and Tenant B's `10.0.0.5` can coexist on the same device with distinct meanings. This gives MSP and sovereign-cloud architectures substantial IP-plan flexibility.
The vService frontend is not limited to a single network domain. The same service can listen on different VIPs across prod, DMZ, management or tenant route tables. A different policy or backend selection can apply depending on which route table the client arrives from. This model simplifies multi-network publishing scenarios without duplicating service instances.
TR7 can take traffic arriving on one route table and forward it to a backend in a different route table. The VIP can remain in the DMZ while the backend stays on the internal network; the tenant network can remain separate while the shared-service network lives in its own route table. Only permitted service flows pass through TR7 — the networks are never merged. Segmentation is preserved while application access is simplified.
Which route table a physical or virtual interface belongs to can be managed from TR7. This is practical during migration, tenant moves or test-to-production transitions. The impact on routes, IPs and services when moving an interface should be evaluated in full. Operations teams do not have to treat network domains as static, immovable structures.
A V-ETH(peer) pair can be used to create a controlled virtual connection between two different route tables. This is valuable when only specific, defined traffic paths need to cross between otherwise fully isolated domains. Applicable to test, migration, service sharing and tenant shared-service access. The connection is still governed by TR7 policies and firewall rules.
Each route table can operate with its own DNS and hosts records. The same hostname can resolve to a different IP in different tenant route tables, or a test environment can use different name resolution from production. This separation reduces hostname conflicts in multi-tenant environments and migration scenarios. Operators manage DNS behavior at the network-domain level, not globally.
Each dynamic route table can run its own routing process. BGP, OSPF or similar dynamic routing behavior can be isolated per tenant or network domain. A route change in one tenant's domain does not affect another tenant's routing plane. This is a significant security and operational advantage in MSP and multi-region enterprise architectures.
TR7 can apply separate firewall management for each route table. Rules, ipsets and traffic permissions operate within the relevant network domain. A port opened or permission granted for one tenant is not automatically propagated to another tenant's services. Security teams can define policy scope more precisely.
Link, IP, route and traffic statistics can be collected separately for each route table. Operations teams can see which link, IP or route is causing a problem in which network domain in isolation. This visibility reduces troubleshooting time in multi-domain environments. Environments running on a single device are monitored in clearly separated views.
A health check can verify not only whether the backend is up, but also whether it is reachable from the relevant route table. A check issued from the frontend network domain to a backend in a different route table exercises the real traffic path — validating route, ARP and firewall traversal, not just service availability. This delivers critical operational confidence in cross-network routing setups.
Multi-route-table behavior is a native part of TR7's network architecture. Operators do not need to provision a separate virtual device per tenant. Isolation, routing and service handoff on the same ADC all remain within a single management plane. This reduces both resource consumption and operational complexity.
Multi-route-table architecture is operated with full lifecycle management, interface migration, process recovery, per-table DNS/hosts and cross-domain state coordination.
When an operator creates a new route table, TR7 prepares a separate execution context for that network domain. This domain carries its own interface, route and firewall behavior. Name and description fields help operations teams distinguish tenants or service zones from each other.
Deleting a route table that still has interfaces assigned to it is treated as unsafe. The default behavior blocks deletion until interfaces are migrated away. If needed, interfaces can be pulled back to the default domain first, making the deletion controlled and explicit.
If the monitoring and management process running for a route table terminates unexpectedly, it can be restarted automatically. This preserves the continuity of multi-domain monitoring behavior. Operations teams do not permanently lose visibility into a network domain because of a single process failure.
When an interface is moved from one route table to another, the impact on IPs, routes, services and firewall rules must be assessed together. The operation is powerful for migration purposes but should be planned in production environments. TR7 makes this behavior visible in the UI, reducing the risk of unintended moves.
Event-based messaging can be established between the main management process and each route-table process. Link state, IP state, GTM information and service signals are delivered separately to each network domain. This provides controlled coordination between global management and isolated network domains.
An index value can be assigned to each route table. This index is used to derive dynamic routing ports, virtual router ID offsets and per-service auxiliary process identifiers. Port and identity conflicts across multiple network domains are thereby reduced.
An MSP can run multiple customers that all use the `10.0.0.0/8` address block on a single TR7 ADC, each in its own route table. Every tenant remains isolated in its own network domain without any IP conflicts.
Organizations can keep the VIP listening in the DMZ route table while the backend remains in the internal route table. TR7 carries only the permitted service traffic between the two domains — without merging them.
When a service is being moved from an old tenant network to a new route table, vService traffic can be redirected in a controlled way. IP plan and service access are managed together throughout the migration.
A test route table can run with production-like settings but has no direct access to production traffic. The operations team can test specific services through cross-route-table routing when needed, while preserving isolation.
Overlapping IP plans, DMZ-to-internal routing and multi-tenant route table architecture. Let's walk through a live setup in your own environment.