Can my backends be on different networks / in different route tables?
Short answer
Yes. On HTTP and L7 TCP vServices, the Backend Services of the same vService can be in different subnets and even in different route tables; TR7 connects to each Backend Service from the table selected in the Route Table field of that Backend Service and also performs the health check from the same table. If the server is reachable from the DEFAULT table through a gateway, defining a static route in that table is enough; if the server is in an isolated network in a separate route table, that table is selected in the Route Table field of the Backend Service. On a Network vService, the Backend Services must be in the same route table as the vService.
Problem: How Does TR7 Reach a Server on a Different Network?
For TR7 to be able to connect to the Backend Service, it must have a route to the network of that server. If the servers are not on a network to which TR7 is directly connected, the connection goes through a gateway. Route tables, on the other hand, are network spaces isolated from each other (similar to VRF): the interfaces and routes in one table are not visible in the other table. If it is not explicitly set from which table the Backend Service is to be connected to, TR7 tries from the default table and may not be able to reach the server.
Solution: Two Methods
| Your situation | Suitable method |
|---|---|
| The server is in another subnet but is reachable from the DEFAULT table with a gateway | Method 1: Defining a route in the same table |
| The server is in an isolated network in a separate route table | Method 2: Selecting a route table in the Backend Service |
Method 1: Defining a Route in the Same Table Recommended
- How it works The Backend Service stays in the default table; TR7 connects over the route defined to the network of the server.
- Where it is openedNetwork → Interfaces → Actions → Add Route
- Requirement A gateway leading to the network of the server
- vService type All
Step-by-Step Configuration
The Add Static Routing form is opened with Network → Interfaces → Actions → Add Route. If the server is reachable through the default gateway of the table, no separate route is required; step 4 is next.
As the Route Interface, the interface that is in the route table of the Backend Service (default DEFAULT) and connected to the gateway is selected; Destination Network (e.g. 203.0.113.0/24) and Gateway are entered. The table of the route is the table of the selected interface.
The Add Route button at the bottom of the form is clicked.
The form is opened with Load Balancer → Backend Services → Add; the name and the Address are entered, and Route Table is left at its default.
If the server needs to see TR7 from a specific IP, an IP of the table is selected with Details → SNAT → Use Device IP; if none is selected (Default), the source is the Interface IP of the interface leading to the server that is in the same subnet as the server (as the gateway, if the server is reached through a gateway).
The Add button at the bottom of the form is clicked. While Clustering is on and Manual Sync Mode is off (default), the Backend Service is transferred to the peer device automatically.
Verification
The Health indicator of the Backend Service in the Backend Services list is checked.
Health: OKMethod 2: Selecting a Route Table in the Backend Service
- How it works TR7 connects to this Backend Service from the network space of the selected route table; the health check is also performed from the same table. The other Backend Services on the same vService can be in other tables.
- Where it is opened Backend Service → Route Table
- Requirement An interface or route in the selected table connected to the network of the server
- vService type HTTP and L7 TCP (on a Network vService, only the Backend Services in the route table of the vService appear in the list)
Step-by-Step Configuration
On the Network → Route Tables screen, it is checked that the table to be selected has an interface or route connected to the network of the server.
If the table does not exist, it is created with Network → Interfaces → Actions → Add Route Table (how to add): Route Table Name is 1–15 characters, required and unique; if dynamic routing is not required, Dynamic Route Table is left unchecked. The table is created empty: the interface connected to the network of the server is created in this table or moved to this table with the Route Table field in the Edit Interface form, and an IP is added to the interface; if the server is behind a gateway, a route or a default gateway is defined in the table. All the steps: What do I need to do on the network side first to open a vService on an IP in a different subnet / VLAN?
On the Load Balancer → Backend Services screen, the Backend Service is added or edited; the table in which the server is located is selected in the Route Table field. This field is meaningful only when there is more than one table.
The SNAT IP and Health Check Source IP lists are limited to the IPs of the selected table; if needed, they are selected here.
The Add (Edit when editing) button at the bottom of the form is clicked. While Clustering is on and Manual Sync Mode is off (default), the Backend Service is transferred to the peer device automatically; it is checked that the route table and interface settings are the same on the peer device as well.
Verification
The Health and Route Table columns in the Backend Services list are checked; on the server, the source address of the incoming connection is checked.
Health: OK · source IP is the TR7 IP in the selected tableCommon Mistakes
- Selecting a table that has no route to the server. TR7 cannot reach the server; the health check fails, and requests receive 503.
- Looking for another table when there is only one table. If there is a single route table, the Backend Service stays in the DEFAULT table; different subnets are managed with Method 1.
- Not checking the SNAT IP when the table changes. The SNAT IP and Health Check Source IP lists change according to the table.
- Expecting communication between tables. Route tables are isolated from each other; for traffic between tables, a V-ETH (Peer) connection is set up as recommended in docs.
How it is done in the documentation
