Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
Two Arm Topology - Routed Backend
Two Arm Topology - Routed Backend is the deployment in which the server arm of Two Arm Topology is a transit network (all vService addresses in a single publishing network; on the server side, a separate network dedicated only to TR7 that contains no servers; the Backend Services are in different networks behind this network, and TR7 reaches them through routing). TR7 does not connect directly to any server network; it reaches all of them from a single arm, through the network's routing point.
No matter how many separate networks the servers are spread across, the number of connections on the TR7 side does not change: one publishing arm, one transit arm. When a new server network is added, TR7 is not given a new interface or address; defining the path to that network is enough. This is the natural deployment for data centers that have many server networks and in which routing is gathered at a central point.
Single Publishing Network
All vService addresses
All published services are served from addresses in the same network
Transit Network
Arm dedicated to TR7
There are no servers on the server-side arm; this network only connects TR7 and the routing point
Routed
Servers in the networks behind
TR7 reaches the Backend Services through the paths defined in the route table
SNAT
Return path ready
TR7 connects to the server with its address in the transit network; 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
Two Arm Topology - Routed Backend
The diagram shows the flow of traffic: the VIP the client connects to is on the interface in the publishing network (1G-1, VLAN_102 in the diagram), while the address TR7 uses when connecting to the Backend Service is on the second interface in the transit network (1G-2, VLAN_101 in the diagram). The Backend Service is in a different network (VLAN_103) behind the routing point (Internal Firewall in the diagram); TR7 has no interface in this network.
In the diagram's example, on the Internal Firewall, access is allowed from the addresses 172.16.101.48 and 172.16.101.49, which the TR7 devices use when connecting to the Backend Service, to the address and port of the Backend Service (172.16.103.77: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.101.48 (Interface IP) | Random | 172.16.103.77 | 80 |
| 3 | Backend Service → TR7 | 172.16.103.77 | 80 | 172.16.101.48 (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.101.49.
Why Routed Backend?
| A separate arm for each server network | With Routed Backend |
|---|---|
| An interface or VLAN and an address from that network are defined on TR7 for each server network. | On TR7, there is a single arm and a single network for the server side. |
| A new server network means a new interface and address on TR7. | A new server network is brought into scope when the Backend Service's route table has a path to that network. |
| Access rules between server networks are managed at more than one point. | The traffic going from TR7 to the servers passes through the network's routing point and is managed by the rules there. |
| TR7 is a member of each server network. | TR7 stays outside the server networks; the servers know it only by its address in the transit network. |
How Does Traffic Flow?
ClientReaches the vService address in the publishing network
RequestTo the vService addressResponseFrom the vService address
TR7Publishing arm and transit armTLSBot/DDoSLBWAFAGSWAF and AGS on HTTP vServices only
RequestWith the address in the transit network (SNAT), through the routing pointResponseTo TR7's address in the transit network
Backend ServiceIn a network behind; sees TR7 as the source
- Request arrivesThe client connects to the vService address in the publishing network.
- 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 transit armTR7 connects to the selected Backend Service with its address in the transit network; the connection reaches the server's network through the network's routing point.
- Response returnsThe Backend Service sends the response to TR7's address in the transit network; 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 on the server sideAs the number of server networks grows, the number of interfaces and addresses on TR7 does not grow; all servers are reached over the same transit 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 passing to the server networks.
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 a single transit arm, 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 publishing network and the transit network are preserved as two fixed points.
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. If the two arms are in the same route table, since the default gateway is used on the publishing arm, a routing entry is defined for the server networks.
- Return path. TR7's address in the transit network must be reachable from the server networks; the transit network must be defined on the routing point.
- Access rules in between. If there is a firewall between TR7 and the servers, access from TR7's address in the transit network 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 in the transit network 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 in the transit network 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
The two-arm deployment in which the publishing network and the server network are separated.
→
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.
→
