What is Content Switching?

Short answer

Content Switching is the routing method that sends the request to different Backend Services or Backend Groups by looking at the content of the incoming request (such as the path, Host, header, cookie, client IP). In TR7, it is done with the Conditional Backend Services blocks of the vService: each block carries a condition and a target, the blocks are evaluated from top to bottom and the first matching block receives the request. If none matches, the request goes to Default Backend Services.

How Does It Work?

Content Switching is the general name for content-based routing in application delivery controllers (e.g. Content Switching in Citrix NetScaler, pool selection with Local Traffic Policy in F5 BIG-IP). In TR7, no separate virtual server or policy object is created for this; the rules are defined in the vService form.

1. The request arrives at the vService.
2. The Conditional Backend Services blocks are tried in order from top to bottom; the condition of each block is applied to the request.
3. The request goes to the Backend Services of the first block whose condition is met; the subsequent blocks are not checked.
4. If no block matches, the request goes to Default Backend Services.

Within the selected block, the server is selected with the LB algorithm and the persistence setting of the vService.

Example

Order	Condition	Target
1	Path starts with /api/	API Backend Services
2	Host admin.example.com	Management panel Backend Services
-	None matched	Website Backend Services in Default Backend Services

By vService Type

vService type	Content Switching	Selectable conditions
HTTP	Yes	Request-stage HTTP conditions (e.g. Path, URL, HTTP header, User Cookie Name, Query parameter, Source IP)
L7 TCP	Yes	Connection-level conditions (e.g. Source IP, Destination IP, Destination port, SSL SNI Info, RDP cookie)
Network	No	-

In TR7

• The blocks are added in the vService form with the + Conditional backend services button in the Default Backend Services table; the field does not appear in the form until the first block is added (Conditional Backend Services).
• There are at most 3 groups in the condition of a block; conditions are combined with AND / OR and the NOT form of each condition can be selected (Multiple conditions: AND / OR).
• The order of the blocks is changed by drag and drop.
• Conditions are central: a condition is defined once under Load Balancer → Conditions and used in more than one vService.
• Individual Backend Services or a Backend Group can be selected as the target; both can also be selected together.

Common Misconceptions

• "Content Switching is an action." Server selection is done in the Conditional Backend Services field of the vService. The Location Redirection action sends the client to another address; it does not select a server.
• "A block with no condition selected receives every request." A block with no condition matches no request.
• "If the Backend Services of the block are unreachable, the request falls back to Default." Default is used only when no block matches; if the Backend Services of the matching block are unreachable, the request is not passed to Default Backend Services.
• "Routing is also done with response conditions." Only request-stage conditions can be selected in the blocks; response conditions such as Status code are not in the list.

How it is done in the documentation

• HTTP (L7) vService · Conditional Backend Services
• L7 TCP vService · Conditional Backend Services
• L7 TCP vService · Content Awareness (SNI and Content Switching)
• Conditions · Condition Matching Criteria

Related questions

• How do I route to different servers based on the URL path (e.g. /api → API servers)?
• What is the difference between Conditional Backend Services and Default Backend Services?
• Where does traffic go if no condition matches?
• How do I change the evaluation order of Conditional Backend Services blocks?