Can I use a condition in negated form ("if not")?

Short answer

Yes. A separate NOT condition is not created: every defined condition (Conditions) is also listed in its negative form next to its positive form in the selection lists where it is used (automatic NOT condition). The negated form is selected in the Conditions field of the Action or of the Conditional Backend Services (Content Switching) block; for a named condition, it appears in the !ConditionName form. The negatives of the ready-made conditions that come with TR7 (e.g. If SSL is NOT terminated) are listed with separate names; in WEB-CLI, negation is set up by writing ! before the condition ID.

Problem: The Rule Must Be Set Up as "If Not"

Many rules depend on the absence of a situation: "block if it does not come from the office network", "send to the desktop servers if it is not mobile". For this, the inverse of the condition needs to be used; defining the inverse condition separately means both extra workload and the risk of the two records drifting apart.

Solution: Three Methods

The negated form can be selected everywhere the condition is used. Which method is used depends on where the negative condition is needed:

Your situation	Suitable method
The action must run when the condition is not met	Method 1: Negated form in the action
Requests that do not meet the condition must go to a separate Backend Service	Method 2: Negated form in the Conditional Backend Services block
From the command line	Method 3: WEB-CLI (!)

Method 1: Selecting the Negated Form in the Action Recommended

• How it works When the negated form of the condition is selected, the action runs when the condition is not met. The negated form is not a separate record; it is a flag kept where the condition is used.
• Where it is openedLoad Balancer → Actions → Add / Edit → Conditions
• Requirement An action type that can take a condition; the condition whose inverse will be used being defined in its positive form (not needed for ready-made conditions)
• vService type HTTP · L7 TCP

Step-by-Step Configuration

1

Adım 1 Create the condition (if needed)

If the condition does not exist yet, it is created in its positive form: the condition form is opened with Load Balancer → Conditions → Add; e.g. for the office network, Criteria = Source IP and Source IP type = Manual are selected, the office addresses are written, and it is saved with Add (how to add). A separate NOT condition is not created. If the inverse of a ready-made condition will be used, this step is skipped.

2

Adım 2 Open the action form

On the Load Balancer → Actions screen, Add is clicked for a new action; for an existing action, the row is selected and Edit is clicked.

3

Adım 3 Select the negated form

In the Select Conditions list in the Conditions field, the negative row of the condition is selected. The negated form is written in short notation: !ConditionName for a named condition; for an unnamed condition, the condition itself with the inverse sign (∉ in an IP list, ≠ in an exact match). The ready-made conditions that come with TR7 are written in italics in the list, and their negatives appear with separate names (e.g. If SSL is NOT terminated, If the client is NOT mobile); some, such as Always and Never, have only a positive form.

4

Adım 4 Save the action

A new action is saved with Add, an existing action with Edit. A new action is also added to the Details → Actions field of the vService, and the vService is saved with Save.

Verification

1Condition summaryTR7 side

The negated form is seen in the Conditions column of the Load Balancer → Actions list and in the Conditions tab of the preview (action preview).

Expected!OfisAgi

2BehaviorClient side

A request is sent from one address that meets the condition and from one that does not; if Hit counter is on in the action, the count is followed in the Live Stats · Action Hits section of the vService.

ExpectedThe action runs only on the request that does not meet the condition

Method 2: In the Conditional Backend Services Block

• How it works The condition selector of the block also lists each condition together with its negated form; requests that do not meet the condition go to the Backend Services of the block.
• Where it is opened vService → Edit → Default Backend Services → + Conditional backend services → Select Conditions
• 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

1

Adım 1 Create the condition (if needed)

If the condition does not exist yet, it is created in its positive form with Load Balancer → Conditions → Add and saved with Add (how to add); the negated form appears in the list automatically.

2

Adım 2 Add the target Backend Services (if needed)

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?

3

Adım 3 Open the vService form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

4

Adım 4 Add the block

+ Conditional backend services in the header of the Default Backend Services table is clicked; if an existing block will be used, it is opened by clicking its header.

5

Adım 5 Select the negated form and the target

In the Select Conditions field of the block, the negative row of the condition is selected, and in the Backend Services table, the target Backend Services or Backend Group.

6

Adım 6 Save the vService

The vService form is saved with Save.

Verification

1RoutingTR7 side

A request that does not meet the condition is sent; in the Left Monitor Panel, the vService is opened and the Backend Service the request went to is checked on the HTTP logs screen in the Logs & Tracking tab.

ExpectedRequest that does not meet the condition → block target

Method 3: WEB-CLI (!)

• How it works In the condition expression, ! is written before the condition ID. A ! written before a parenthesis is also accepted; TR7 distributes it to the condition level: !(A or B) → !A and !B.
• 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

1

Adım 1 Get the condition ID

In the expression, the ID of the condition is used, not its name; the IDs start with lbConditions- (lb condition). If a name is written, 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.

lb condition list

2

Adım 2 Write the condition of the action

--cond replaces the entire current condition of the action (action commands):

lb action update id <action-id> --cond "!<condition-id>"

3

Adım 3 View the position of the block (for a block)

The Conditional Backend Services blocks are kept in the order in the form; the topmost block is 0. The position of the block is read from the vService record:

lb service show <vService>

4

Adım 4 Write the condition of the block (for a block)

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-id>"

Verification

1Condition in the recordTR7 side

The record is displayed again with lb action show or lb service show; the condition field is shown as a WEB-CLI expression, with the condition ID. The display with the condition name is seen in the interface in the Conditions column of the Actions list.

Expected! before the condition ID · !ConditionName in the interface

Common Mistakes

• Trying to negate the group in the interface for "NOT (A and B)". In the interface, negation is at the single condition level; the equivalent is combining !A and !B with or in one group. In WEB-CLI, !(A and B) can be written; TR7 converts it into the same form.
• Looking for a separate NOT record in the Conditions list. Only the positive record appears in the Load Balancer → Conditions list; the negated form comes in the lists where the condition is selected.
• Selecting the negated form in the User authentication (On HTTP request) action. In this action, the positive form of the User Authentication condition is selected; TR7 itself separates the unauthenticated requests and opens the login window only for them.
• Forgetting that a negative condition also matches on an empty value. For example, the condition "if the header is not X" also covers requests that do not carry the header at all.

How it is done in the documentation

• Conditions · Automatic NOT (Negation) Condition Creation
• Conditions · Example: Office IP Whitelist Scenario
• HTTP (L7) vService · Conditional Backend Services
• User Authentication (On HTTP Request) · Conditions

Related questions

• How do I combine multiple conditions with AND / OR?
• What is the difference between a Condition and an Action?
• Why doesn't a Location Redirection or User Authentication (On HTTP request) action work if I add it without a condition?