Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
One Arm Topology - Routed Backend
One Arm Topology - Routed Backend is the form of One Arm Topology in which the servers are in other networks (a single network interface and a single IP network in TR7; the vService addresses are in this network; the Backend Services are in different networks behind the routing point, and TR7 reaches them over the same arm, through routing). TR7 does not connect directly to any server network; it reaches all servers through the network's routing point, from the arm on which it receives client traffic.
A single connection and a single address block in the network are enough for TR7. No matter how many separate networks the servers are spread across, TR7 is not given a new interface or address; defining the path to those networks is enough. This is the deployment that is added to an existing network with the least change and serves scattered server networks from a single point.
One Arm
One interface, one network
Client traffic and the traffic going to the servers use the same interface
Single Address Block
vService addresses
All published services are served from addresses in the network TR7 is connected to
Routed
Servers in other networks
TR7 reaches the Backend Services through the paths defined in the route table
SNAT
Return path ready
TR7 connects to the server with its own address; the response returns to this address, that is, to TR7
Server Settings Unchanged
Gateway does not change
The servers continue to use their own gateways
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
One Arm Topology - Routed Backend
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; the Backend Service, however, is in a different network behind the routing point (Internal Firewall in the diagram).
In the diagram's example, on the Internal Firewall, access is allowed from the addresses 172.16.102.90 and 172.16.102.91, which the TR7 devices use when connecting to the Backend Service, to the address and port of the Backend Service (172.16.101.47:80). 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 to TR7 over the same path. 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.101.47 | 80 |
| 3 | Backend Service → TR7 | 172.16.101.47 | 80 | 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 Routed Backend?
| One Arm in the same network as the servers | With Routed Backend |
|---|---|
| TR7 is placed in the network of the servers it load balances. | TR7 stays in its own network; the servers remain in the networks they are in. |
| For servers in different networks, an interface and an address from those networks are defined on TR7. | A new server network is brought into scope when the Backend Service's route table has a path to that network. |
| TR7 is a member of the server network. | TR7 stays outside the server networks; the servers know it only by its address in its own network. |
| The traffic between TR7 and the servers does not pass through the routing point. | The traffic going from TR7 to the servers passes through the network's routing point and is managed by the rules there. |
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), through the routing pointResponseTo TR7's address
Backend ServiceIn another network; sees 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 over the same armTR7 connects to the selected Backend Service through the same interface, with its own address; the connection reaches the server's network through the network's routing point.
- Response returnsThe Backend Service sends the response to TR7's address; the response returns to TR7 through the same routing point and TR7 forwards it to the client.
RequestResponse
Since the server sends its response to TR7's address, the return path is provided by the network's ordinary routing: no additional routing rule or address translation is needed for the return traffic.
Highlights
One arm is enoughAs the number of server networks grows, the number of interfaces and addresses on TR7 does not grow; all servers are reached over the same arm.
The path is defined in the route tableThe path to the server networks is defined in the Backend Service's route table as the default gateway or as a routing entry in the Routes tab.
Automatic return pathSince TR7 connects to the server with its own address, the response returns to this address; the server's gateway is not changed.
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.
Health check over the same pathHealth checks leave from the Backend Service's route table; they reach the servers through the routing point.
Security layers at the same pointBot/DDoS protection is enabled on HTTP and L7 TCP vServices, and WAF and AGS on HTTP vServices; the traffic passes through these layers before being forwarded to the servers.
A specific source addressIf the servers are to allow a single address, a specific device address in the same route table is selected in the Backend Service with Use Device IP; the source address of the health check is set separately in the Health Check Source IP field.
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.
When Is It Preferred?
Many server networks One arm
If the applications are spread across different VLANs and networks, TR7 reaches all of them over the single arm it is connected to, instead of connecting to each of them separately.
Central routing and inspection Routed network
If traffic between networks is to pass through a core switch or firewall, the traffic TR7 sends to the servers also passes through the same point.
Growing infrastructures Simple design
As new server networks are added, TR7's interface and address configuration stays the same; the device's single connection to the network does not change.
Requirements of this deployment
- Path to the server networks. In the Backend Service's route table, a default gateway that reaches the server networks or a routing entry in the Routes tab must be defined.
- Return path. TR7's address must be reachable from the server networks.
- Same arm, two directions. Client traffic and the traffic going to the servers share the same interface; if the clients also use the same routing point, the traffic passes through that point twice.
- Access rules in between. If there is a firewall between TR7 and the servers, access from TR7's address to the service ports and health check ports of the servers must be allowed.
- Access lists on the server. The server sees TR7's address as the source of the connection; IP-based access lists are arranged accordingly. In a cluster setup, since each device connects with its own address, the addresses of both devices are defined in the access lists and in the rules in between.
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.
Related Pages
Two Arm Topology - Routed Backend
The two-arm deployment in which the servers are reached through a transit network dedicated to TR7.
→
Add Static Routing
Defining the paths to the server networks in the route table.
→
Backend Services
The Backend Service's route table, source address selection (SNAT) and Proxy Protocol.
→
Health Checks
Health check profiles of the Backend Services.
→
