How do I combine multiple conditions with AND / OR?
Short answer
In the Conditions field of the Action or of the Conditional Backend Services (Content Switching) block, more than one condition (Conditions) is selected in a group; with the switch that appears when a second condition is added to the group, the logic within the group is set to and or or (default and). If a part with different logic is needed, a new group is added with + (at most 3 groups); the new group is connected to the previous group with or by default. Between groups, and is evaluated before or: G1 or G2 and G3 means G1 or (G2 and G3) (multiple condition logic).
Problem: A Single Condition Is Not Enough
Real rules are often based on more than one criterion: "if the path starts with /admin and the client is not on the office network" or "if it is Host A or Host B". These criteria need to be combined with the correct logic in a single rule. In TR7, conditions and actions (Conditions & Actions; similar to F5 Local Traffic Policy / iRules, Citrix Responder / Rewrite policy) make this combination without writing code.
Solution: Four Methods
| Your situation | Suitable method |
|---|---|
| Determining when an action will run | Method 1: Conditions field in the action form |
| Making the Backend Service a request goes to depend on a condition | Method 2: Conditional Backend Services block |
| From the command line | Method 3: WEB-CLI condition expression |
| The logic does not fit into 3 groups | Method 4: Splitting into multiple actions |
Method 1: Conditions Field in the Action Form Recommended
- How it works The conditions within a group are combined with the group's switch, and the groups with the switch between them; consecutive groups connected with and are combined first.
- Where it is openedLoad Balancer → Actions → Add / Edit → Conditions
- Requirement An action type that can take a condition (actions that take and do not take conditions); the conditions to be combined are defined
- vService type HTTP · L7 TCP
Step-by-Step Configuration
If the conditions to be combined do not exist yet, each of them is created separately: the condition form is opened with Load Balancer → Conditions → Add, Criteria and the fields of the criterion are filled in, and it is saved with Add (how to add). Example: Path /admin/ for the management path, Source IP (Manual) for the office network. The negated form of each condition is in the list automatically; it is not created separately (automatic NOT condition).
In a new action, first the Action Type and, in types that can select a stage, the Execution Level (On Request / On Response) are determined. When the stage is changed, the selected conditions are reset; in addition, the condition list shows only the conditions that work in the selected stage and protocol.
In the Conditions field, conditions are selected from the Select Conditions list of the first group; the list is multi-select. When there are two conditions in the group, the and/or switch appears next to the group (default and); it is set to or by clicking it.
For a part with different logic, the + next to the first group is clicked; when three groups are reached, + becomes disabled. An extra group is deleted with the trash can icon next to it.
The switch that appears between two groups comes as or in the new group; if needed, it is set to and by clicking it. Example: for "(A or B) and C", Group 1 = A, B (or), Group 2 = C, and between groups.
A new action is saved with Add, an existing action with Edit. In an existing action, the change is applied to all the vServices that use the action.
A new action does not work until it is bound to a vService: on the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked, and the action is selected from the Actions field in the Details section.
The vService form is saved with Save.
Verification
The combination is seen in the Conditions column of the Load Balancer → Actions list and in the Conditions tab of the preview that opens when the row is clicked (action preview). In the column, and is shown with & and or with |; a group with more than one condition is enclosed in parentheses.
(A | B) & CMethod 2: Conditional Backend Services Block
- How it works The condition field of the block works in the same way as the one in the action form; if the combined condition is met, the request goes to the Backend Services of the block. The blocks are evaluated from top to bottom, and the first matching block wins.
- Where it is opened vService → Edit → Default Backend Services → + Conditional backend services
- Requirement HTTP or L7 TCP vService; only request-stage conditions can be selected in the block
- vService type HTTP · L7 TCP
Step-by-Step Configuration
If the conditions to be combined do not exist yet, each of them is created separately with Load Balancer → Conditions → Add and saved with Add (how to add).
If the servers the block will route to are not yet defined in TR7 as Backend Services, they are added first; if they are defined, this step is skipped. With Load Balancer → Backend Services → Add, the Backend Service Name and Address (IP or domain name and port) are entered for each server; if no profile is selected in the Health Check field (default No check), it is not detected that the server is unreachable. If the servers are to be managed as a single target, a Backend Group is created with Load Balancer → Backend Groups → Add. Details: How is a Backend Service added; which information is required?
On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.
An existing block is opened by clicking its header; for a new block, + Conditional backend services in the header of the Default Backend Services table is clicked.
In the Select Conditions field of the block, conditions are selected into the groups; the and/or switches within groups and between groups are set as in Method 1 (at most 3 groups).
The target Backend Services or Backend Group are selected from the Backend Services table of the block.
The vService form is saved with Save.
Verification
In the vService form, a short summary of the condition appears in the header of the block; in a block without a condition, the header is a sequence number such as CONDITIONAL BACKEND #1.
(A | B) & COne request that matches the condition and one that does not are sent; in the Left Monitor Panel, the vService is opened and the Backend Service the requests went to is checked on the HTTP logs screen in the Logs & Tracking tab.
Matching request → block target · non-matching → Default backend servicesMethod 3: WEB-CLI Condition Expression
- How it works The conditions are written with their IDs as an expression in quotation marks;
and/or,!for negation, and at most one level of parentheses are used. TR7 converts the expression into the groups in the interface: a parenthesis becomes a group, and and is again evaluated before or. - Where it is opened TR7 WEB-CLI →
lb action update·lb service update - Requirement WEB-CLI access; the IDs of the conditions (not their names)
- vService type HTTP · L7 TCP
Step-by-Step Configuration
In the expression, the ID of the condition is used, not its name; the IDs start with lbConditions- and are taken from the list (lb condition). If a name is written in the expression, the command gives no error, but since this item does not correspond to a defined condition, it is dropped from the condition when the configuration is applied; if it is the only condition, the action becomes unconditional.
lb condition list--cond replaces the entire current condition of the action (action commands). Example "(A or B) and C":
lb action update id <action-id> --cond "(<condition-A> or <condition-B>) and <condition-C>"The Conditional Backend Services blocks are kept in the dynamicBackendList list in the order in the form; the topmost block is 0. The position of the block to be changed is read from the vService record:
lb service show <vService>The position number in the command changes only the condition of the existing block at that position; the targets of the block and the other blocks are preserved (WEB-CLI · lb service). Example: the condition of the topmost block:
lb service update id <vService> --dynamicBackendList.0.cond "(<condition-A> or <condition-B>) and <condition-C>"Verification
The action record is displayed again with the lb action show command, and the vService record with the lb service show command; the condition field is shown as a WEB-CLI expression, with the condition IDs and operators. The display with condition names is seen in the interface in the Conditions column of the Actions list.
The IDs of A, B and C in the desired and / or structureMethod 4: Splitting into Multiple Actions
- How it works An "or" logic that does not fit into the 3 groups of a single action is split into multiple actions that do the same job; each action runs with its own condition.
- Where it is openedLoad Balancer → Actions
- Requirement The action not terminating the request, or the order being set up deliberately (If an action blocks or redirects traffic, do the subsequent actions run?)
- vService type HTTP · L7 TCP
Step-by-Step Configuration
An action is created with Load Balancer → Actions → Add; the conditions of the first branch are selected in the Conditions field and Add & Repeat is clicked. The form stays open.
For the second action of the same type, the name and the conditions of the second branch are entered, and it is saved with Add.
The vService is opened with Edit; the two actions are selected in the Details → Actions field. The actions run in the order in the list (In what order do Actions run; how do I change the order?).
The vService form is saved with Save.
Verification
If Hit counter is turned on in the actions, how many times each branch ran is seen separately in the Live Stats · Action Hits section of the vService.
The counter of each branch increases on its own conditionCommon Mistakes
- Assuming the new group is connected with and. In the interface, the new group is connected to the previous group with or by default; the switch within a group, on the other hand, is and by default.
- Evaluating the groups from left to right.
G1 or G2 and G3is evaluated asG1 or (G2 and G3); and is always combined first. - Looking for a fourth group. There are at most 3 groups in the interface; more complex logic is split into actions.
- Changing the Execution level in a new action after the conditions. When the stage changes, the selected conditions are reset; first the stage, then the conditions are selected.
- Writing the name of the condition in the WEB-CLI expression. The expression is built with IDs; an item written as a name is dropped from the condition, and the action may be applied to broader traffic than expected. Nested parentheses cannot be used in WEB-CLI either.
How it is done in the documentation
