In traditional ADC deployment projects the largest cost is usually not the product itself — it is reshaping the existing network to fit the product. Changing backend default gateways, redesigning IP plans, reworking route behaviour or opening maintenance windows all carry significant risk in production environments.
In environments with hundreds or thousands of backends, the "change every server's gateway" approach is not viable. Some backends may have no gateway defined at all, others may rely on static routes, and others still may run on legacy systems that are difficult or impossible to modify. In these cases, inserting an ADC becomes a full network redesign project.
Forced network-segment merging is another problem. The VIP must sit in the DMZ, the backend must stay on the internal network, tenant networks must remain isolated, and the management plane must be kept separate. If the ADC cannot carry traffic across these domains in a controlled way, security segmentation breaks down or application teams are forced into unnecessary IP migration work.
A single reverse proxy model also fails to cover every need. Some applications require backends to see the real client IP; some L4 services need return traffic to bypass the ADC entirely; some inline scenarios require inserting the ADC without changing IPs or touching gateways. A single NAT-based model cannot address this range of requirements.
TR7 Deployment Topology Modes provide this flexibility: they let you choose the right traffic placement for each service without touching backend IP addresses, gateways or Route Table assignments.
TR7 turns the deployment topology into an architectural decision that can be tailored to service type, network placement and migration risk.
In the classic reverse proxy model the client connects to TR7 and TR7 connects to the backend. In a transparent bind scenario, traffic flow is preserved so that the backend sees the real client IP as the source address.
In NAT mode both destination and source translation are managed together. In SNAT mode only the source side is adjusted. In DR mode, return traffic goes directly to the client, providing a more efficient path for high-volume L4 workloads.
The Route Table hosting the VIP and the Route Table hosting the backend can be different. TR7 carries traffic across the two network domains in a controlled way, connecting DMZ, internal, tenant and management segments without flattening them.
TR7 can take ownership of traffic destined for specific backend IPs and operate inline. The backend's IP address, gateway and application configuration remain unchanged while the ADC is inserted into the path.
Deployment Topology Modes cover network placements ranging from rapid single-interface setup to high-throughput L4 forwarding.
In one-arm mode, client and backend traffic can be handled on the same network side. TR7 receives service traffic through a single interface and forwards it to the relevant backend using routing rules. This model is suited to fast ADC deployment with minimal network changes. It is a practical starting point for pilot deployments, temporary transitions or low-risk rollout scenarios.
In two-arm mode, TR7 is positioned between two distinct network segments. One side faces the client or DMZ network; the other faces the backend network. This makes the ADC not just a traffic forwarder but a policy-enforcing transit point at the network boundary. It is suited to enterprise architectures that require security and segmentation.
In reverse proxy mode the client connects to the VIP or vService on TR7, and TR7 opens a separate connection to the backend. TLS termination, WAAP, header manipulation, cookie security, content-aware rules and AAM integration are all fully applicable in this mode. This is the most common application delivery topology for HTTP and API traffic. Backends are never exposed directly to the internet or external networks.
In a transparent L7 scenario, the source IP seen by the backend is the real client address rather than the ADC address. This mode is valuable for applications that cannot rely solely on header-based client IP forwarding. Logs, access control and in-application IP-based decisions work more naturally. The network return path must be planned accordingly.
Bridge mode allows TR7 to sit in the traffic path as a Layer 2 bridge. In this scenario the need for additional IP renumbering or broad routing changes is reduced. Existing addressing can be preserved when entering the traffic path across VMs, containers or segments. Bridge mode is useful in environments where network changes must be kept to a minimum.
In transparent gateway mode TR7 is positioned at the transit point of the backend network. Source IP is preserved and NAT is not required. This mode is valuable in scenarios where backends must see the client IP naturally. Default route changes must be planned carefully and the return path must be explicitly controlled.
TR7 can take traffic ownership for designated backend IPs and operate inline. This mode is particularly valuable when a backend's IP address, default gateway or route settings cannot be changed. Even when the backend has no gateway configured, TR7 can position itself as the control point in the relevant traffic path. In large environments, controlled inline insertion replaces the need to modify hundreds of backends individually.
TR7 can listen on a VIP in one Route Table and forward traffic to a backend in a different Route Table. This allows DMZ, internal, tenant, management and distinct service zones to be connected to each other in a controlled way without being moved to the same network plane. Operators do not need to renumber backends or flatten networks. TR7 becomes a controlled transit point between Route Tables where security policy can be applied.
In L4 NAT mode, destination and source translation are used together to guarantee the return path through TR7. In SNAT mode only the source side is adjusted, and the backend's existing return path design is respected. These two modes allow L4 traffic to be carried in a way that fits the network topology. Separate behaviour can be selected for UDP, TCP or specific port ranges.
In DR mode, request traffic is forwarded to the backend through TR7 while response traffic returns directly to the client. This model is advantageous for high-volume streaming, gaming, DNS or latency-sensitive L4 services. Because the ADC does not carry return traffic, the data path becomes more efficient. Backend and network return behaviour must be prepared correctly for DR scenarios.
L4 persistence helps ensure that traffic from a specific client stays on the same backend target. CONNMARK, recent records and a configurable persistence window maintain flow continuity. SIP persistence provides specialised behaviour for session-sensitive protocols such as SIP traffic. This gives L4-level session consistency in addition to basic load distribution.
The required ingress permissions for L4 and vService definitions can be generated automatically. Appropriate accept rules are created for each front-end IP, port and protocol, reducing manual firewall errors. Automatic rule generation is especially important in inline and L4 scenarios. The operator selects the topology; TR7 consistently generates the basic permissions for the relevant traffic path.
Topology modes are operated together with L4 defaults, inline process behaviour, TR7 Route Tables, cluster role and error visibility.
Round-robin algorithm, NAT mode and UDP protocol are available as the default starting values for a new L4 pool. Operators can change these to TCP, UDP, any protocol, port range or a different L4 algorithm based on service requirements. Defaults are intended for fast start-up; production behaviour should be reviewed explicitly.
Algorithms such as round-robin and weighted round-robin can be used for L4 distribution. The weighted model provides more balanced traffic distribution across backends with different capacities. Algorithm selection should be planned together with service type, capacity and session behaviour.
IP-takeover inline mode operates based on the relevant interface, backend IP and gateway information. If a gateway is not explicitly specified, the appropriate path can be derived from the existing network information. If the process stops unexpectedly, automatic restart can be applied.
In inline mode, conditions such as noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice and inactiveClusterIp can be surfaced as explicit error reasons. This tells the operations team precisely why something is not working rather than simply that it is not working. Error visibility is critical for operating inline topologies safely.
In a cluster environment, the inline takeover process should run only on the device that holds the active role. When the active device changes, inline traffic ownership moves to the relevant node. This model helps prevent two nodes from simultaneously claiming ownership of the same IP.
Inline transparent mode reduces dependency on the backend's default gateway setting. If the backend has no gateway or the gateway cannot be changed, TR7 can take over the relevant traffic path using the IP-takeover method. This capability enables controlled ADC deployment without opening maintenance windows or modifying backends.
The TR7 Route Table on which the VIP listens and the TR7 Route Table where the backend resides can be different. TR7 carries traffic between these two network domains, reducing the need for topology changes. This behaviour is particularly valuable for controlled transition from DMZ to internal network, from tenant network to shared service network, or between old and new network domains during migration.
In large organisations, changing the IP, route or gateway of hundreds of backends is high risk. IP-takeover inline mode lets TR7 ADC be inserted into the traffic path while existing addressing is preserved.
Some legacy or isolated backends may have no default gateway configured. In inline transparent mode TR7 can take over the relevant traffic without touching the backend's gateway setting.
Organisations can listen for VIPs on a DMZ Route Table while keeping backends on an internal Route Table. TR7 provides controlled traffic transit between the two domains without merging networks or renumbering service IPs.
Gaming or streaming teams can use DR mode to send response traffic directly to the client. While TR7 makes the forwarding decision, load on the return data path is reduced and high-throughput scenarios become more efficient.
From one-arm to transparent inline, L4 DR to cross-Route-Table forwarding — let's walk through the right topology in a live setup.