Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
I'm coming from F5, Citrix, Kemp or HAProxy; what are the TR7 equivalents of concepts like virtual server, pool, node, monitor and iRule?
Short answer
The basic building blocks are the same; their names are different: virtual server → vService, pool → Backend Group or the vService's Default Backend Services list, pool member → Backend Service, monitor → Health Checks profile, iRule / LTM policy → Condition + Action, SNAT → the SNAT field in the Backend Service. There is no scripting language in TR7; rules are defined from the interface without writing code. For advanced needs that have no equivalent in the interface, there are Manual Condition and Manual Action.
Concept Mapping
The vendor terms in the table are written with the names in the vendors' own documentation (F5 BIG-IP LTM, NetScaler, Progress Kemp LoadMaster, HAProxy).
| Concept | F5 BIG-IP | NetScaler (Citrix ADC) | Kemp LoadMaster | HAProxy | TR7 |
|---|---|---|---|---|---|
| Listener that receives the traffic | Virtual Server | Load balancing virtual server (LB vServer) | Virtual Service | frontend | vService |
| Server pool | Pool | Service Group or services bound to the LB vServer | Real Servers assigned to the Virtual Service | backend | Backend Group or the vService's Default Backend Services list |
| Single server in the pool | Pool Member (Node + port) | Service / Service Group member | Real Server | server | Backend Service (address:port) or a server row in the Backend Group |
| Server object defined only by IP address | Node | Server | - | - | No equivalent; the Backend Service is directly address:port |
| Health check | Monitor | Monitor | Real Server Check | check / option httpchk | Health Checks profile |
| Content-based routing | Local Traffic Policy (LTM Policy) | Content Switching virtual server + CS policy | SubVS / Content Rules | acl + use_backend | Conditional Backend Services (Content Switching) |
| Traffic rule | iRule (Tcl) / LTM Policy | Responder / Rewrite policy | Content Rules: Add / Delete / Replace Header | acl + http-request | Condition + Action |
| Persistence | Persistence profile | Persistence type on the LB vServer | Persistence Options | cookie / stick-table | The Persistence field in the vService |
| Source address of the connection to the server (SNAT) | SNAT / SNAT Automap | SNIP (USNIP mode) | Non-transparent mode | Its own address by default; set with source | The SNAT field in the Backend Service (Default, Use Device IP) |
| Forwarding the client IP to the server while preserving it | Not using SNAT (the server's gateway is BIG-IP) | USIP mode | Transparency | source 0.0.0.0 usesrc clientip | SNAT → Use Client IP |
| Isolated routing domain | Route Domain | Traffic Domain | - | - | Route Table |
Differences to Note
- There is no separate "node" object. The Node object in F5 and the Server object in NetScaler (a server record defined only by IP address) have no equivalent in TR7; the Backend Service is directly an address:port definition. The same Backend Service can be used in more than one vService.
- A pool is set up in two ways. Backend Services can be added one by one to the vService's Default Backend Services list; if servers providing the same service will be managed with common settings, a Backend Group is used. In a Backend Group, Health Check, SSL Service, SNAT and Maintenance Mode are at the group level; the address, Weight, Connection Limit and Cookie Content are at the server level.
- Persistence is not a separate profile. It is selected from the Persistence field in the vService form: New Cookie, Current Cookie, Hash or Session Affinity Manager (SAM). In the Network vService, L4 Persistence and SIP Persistence are used.
- SNAT options: Default makes the source address the Interface IP, on the same subnet as the server (or as the gateway, if the server is reached via a gateway), of the interface that goes to the server in the Backend Service's route table (the closest option to SNAT Automap in F5); Use Device IP makes a specific device IP the source; Use Client IP preserves the client's IP and requires the server's response to return through TR7 (USIP mode in NetScaler, Transparency in Kemp).
- Content-based routing is on a single screen. In NetScaler, Content Switching requires a separate CS virtual server and target LB vServers; in TR7, conditional targets are defined in the Conditional Backend Services section of the same vService.
What Is Used Instead of iRule?
| Need | TR7 |
|---|---|
| Most rules (routing, header editing, blocking, request volume limit, error page…) | Condition ("when") + Action ("what to do"); from the interface, without writing code. For request volume and bot protection, L7 DDoS Protection |
| An advanced need that has no equivalent in the interface | Manual Condition: a single-line raw condition expression · Manual Action: raw lines written to the selected section of the vService configuration |
Manual condition and Manual action are for advanced use
The lines entered are written to the vService configuration as they are, without syntax checking; a faulty expression can stop the vService from working. A condition cannot be bound to a Manual action; if needed, the condition is written inside the line. Both are used only in HTTP and L7 TCP vServices.
Common Misconceptions
- "In TR7, scripts like iRule are written." There is no scripting language; rules are built with Condition + Action.
- "A Backend Group is always required for a pool." More than one Backend Service can be added directly to the vService's Default Backend Services list.
- "The persistence profile is a separate object." It is a field in the vService form.
- "USIP in NetScaler and SNAT Default in TR7 are the same." USIP preserves the client IP; its equivalent in TR7 is Use Client IP. SNAT Default, on the other hand, uses TR7's own IP (SNIP / USNIP in NetScaler).
How it is done in the documentation
