One Arm Topology

One Arm Topology is the deployment in which TR7 connects to the network with a single arm (a single network interface, Bond, LACP or VLAN; a single IP network and a single route table in TR7): client traffic is received on the same network interface and the Backend Services are reached through the same interface. TR7 does not sit in the middle of the traffic path; it is added alongside the existing network. For this reason, load balancing, WAF and access control are brought to a running infrastructure without changing the network design.

The IP addresses, gateways and cabling of the servers stay as they are. When the traffic going to the application is directed to the vService address, TR7 comes into play; when the redirection is rolled back, the infrastructure returns to its previous state. This is the deployment that delivers results in the shortest time with the least risk.

Single Interface

One arm, one network

The client side and the server side work on the same interface and the same network

Hands-off

Existing network is preserved

The IP address, gateway and cabling of the servers do not change

SNAT

Return path ready

TR7 connects to the server with its own address; the response returns to this address, that is, to TR7

Full Scope

L7 capabilities

Load balancing, TLS and Bot/DDoS are used in this deployment; WAF and AGS are also enabled on HTTP vServices

X-Forwarded-For

Client address is forwarded

When enabled, the real client IP address is forwarded to the server with a header or with Proxy Protocol

Cluster

High availability

When the vService address is defined as a VIP, the address moves to the other device on a device failure

One Arm Topology

The diagram shows the flow of traffic: the VIP the client connects to and the address TR7 uses when connecting to the Backend Service are on the same interface (1G-1 in the diagram) and in the same network.

In the diagram's example, the TR7 devices connect to the Backend Service with the addresses 172.16.102.90 and 172.16.102.91. Both the application traffic and the health check are made from these addresses; the Backend Service sees these addresses as the source of the connection and returns the response directly to TR7. For the health check, this applies while the Health Check Source IP field in the Backend Service is at its default value; when another address is selected in the field, the check is made from that address.

In the diagram's example, the source and destination information of the packets in the four steps of the connection is as follows (while TR7-01 is the active device):

Step	Direction	Source IP	Source Port	Destination IP	Destination Port
1	Client → TR7	Client IP	Random	`172.16.102.92` (VIP)	`443`
2	TR7 → Backend Service	`172.16.102.90` (Interface IP)	Random	`172.16.102.161`	`8080`
3	Backend Service → TR7	`172.16.102.161`	`8080`	`172.16.102.90` (Interface IP)	Source port of step 2
4	TR7 → Client	`172.16.102.92` (VIP)	`443`	Client IP	Source port of step 1

Color	Meaning
	Request
	Response

When the VIP moves to the other device, the TR7 address in steps 2 and 3 becomes 172.16.102.91.

Why One Arm?

Deployments that sit in the path	With One Arm Topology
The server network is redesigned; the gateway, VLAN or cabling changes.	The existing network stays as it is; TR7 is added to the same network as a device.
All traffic going to the servers passes through the load balancer.	Only the application traffic arriving at the vService address passes through TR7; backup, management and server-to-server traffic stay on their own path.
Rollout requires a maintenance window and a rollback plan.	It is put into service by switching the traffic to the vService address and rolled back by switching it to the old address.
Making the return traffic come through the correct path is ensured separately on the network side.	Since TR7 connects to the server with its own address, the response returns to TR7.

How Does Traffic Flow?

ClientReaches the application at the vService address

RequestTo the vService addressResponseFrom the vService address

TR7One interface, one networkTLSBot/DDoSLBWAFAGSWAF and AGS on HTTP vServices only

RequestWith TR7's address (SNAT)ResponseTo TR7's address

Backend ServiceSees TR7 as the source

Request arrivesThe client connects to the vService address at which the application is published.
TR7 inspectsTLS termination, Bot/DDoS and rules are applied at the same point; on HTTP vServices, WAF and AGS are also at this point.
Forwards to the serverTR7 connects to the selected Backend Service through the same interface, with its own address.
Response returnsThe Backend Service responds to TR7; TR7 forwards the response to the client.

RequestResponse

Since the request and the response pass through the same device, TR7 sees both ends of the connection: the connection is recorded; on HTTP vServices, the response is also inspected, compressed and cached. A one-arm deployment does not mean compromising on capabilities.

Highlights

Plug-and-play deploymentA single interface, a single route table and one vService address are enough; no additional VLAN or second network is needed.

Easy to roll backSince the servers do not change, returning to the previous state consists only of switching the traffic back to the server address.

Flexible source address selectionWhen connecting to the server, the source address is selected automatically by TR7; if desired, a specific device address in the same route table (Use Device IP) is selected.

Client address stays visibleOn HTTP vServices the X-Forwarded-For header, and on HTTP and L7 TCP vServices Proxy Protocol where the Backend Service supports it, carries the real client IP address to the Backend Service.

Security layers at the same pointBot/DDoS protection on HTTP and L7 TCP vServices, and WAF and AGS on HTTP vServices, are enabled on the same vService.

Health check from the same networkSince the Backend Services are in the same network as TR7, health checks work without requiring additional routing.

High availability with ClusterWhen the vService address is defined as a VIP, if a device goes out of service, the address moves to the other device and publishing continues from that device.

Also valid for L4 trafficOn Network vServices, SNAT mode carries the same one-arm deployment to TCP and UDP services; in this mode the client address is not forwarded to the Backend Service.

When Is It Preferred?

Fast rollout Initial setup

Load balancing and WAF are placed in front of a running application without waiting for a topology change from the network team. It is the shortest path for trial setups and phased migrations.

Networks closed to change Low risk

If the gateway, address plan or cabling of the server network cannot be changed, TR7 is added to the same network and takes over only the application traffic.

Selected applications Gradual migration

Only some of the servers in the same network are placed behind the load balancer; the other services and the management traffic continue to work unaffected.

If the servers are in other networks

If the Backend Services are not in the same network as TR7 but in networks behind the routing point, the same one-arm setup is used with the One Arm Topology - Routed Backend deployment.

How does the client IP address appear on the server?

In this deployment, the Backend Service sees TR7's address as the source of the connection. The real client address is forwarded with the X-Forwarded-For header on HTTP vServices, and with Proxy Protocol on HTTP and L7 TCP vServices where the Backend Service supports it; both options are disabled by default. If the client address needs to be seen as the source address of the connection, the Gateway Mode or Gateway Mode - Spoofing deployment is preferred.

Two Arm Topology

The two-arm deployment in which the client and server networks are separated.

→

Backend Services

Source address selection (SNAT), Proxy Protocol and health check settings.

→

HTTP vService

The form in which the vService address, X-Forwarded-For and the security modules are enabled.

→

Interfaces

Defining Interface IP and VIP addresses.

→