Basic steps for creating and using policies
BIG-IP® local traffic policies comprise a prioritized list of rules that match defined conditions and run specific actions, which you can associate with a virtual server that directs traffic accordingly. For example, you might create a policy that determines whether a client is using a mobile device, and then redirects its requests to the applicable mobile web site's URL.
Each BIG-IP® local traffic policy requires a matching strategy to determine which rule applies if more than one rule matches.
The BIG-IP local traffic policies provide three predefined policy matching strategies: a first-match, best-match, and all-match strategy. Each policy matching strategy prioritizes rules according to the rule's position within the Rules list.
As needed, you can create a user-defined best-match strategy to customize the precedence (order of preference) of added operands and selectors. For example, to meet your preferred operand and selector combinations, you might create a user-defined best-match strategy that changes the precedence of added operands and selectors, compared to the predefined best-match strategy.
|all-match strategy||An all-match strategy starts the actions for all rules in the Rules list
Note: In an all-match strategy, when multiple rules match, but specify conflicting actions, only the action of the best-match rule is implemented. A best-match rule can be the lowest ordinal, the highest priority, or the first rule that matches in the Rules list.
|best-match strategy||A best-match strategy selects and starts the actions of the rule in the
Rules list with the best match, as determined by the following factors.
Note: In a best-match strategy, when multiple rules match and specify an action, conflicting or otherwise, only the action of the best-match rule is implemented. A best-match rule can be the lowest ordinal, the highest priority, or the first rule that matches in the Rules list.
|first-match strategy||A first-match strategy starts the actions for the first rule in the Rules list that matches.|
BIG-IP® local traffic policy rules match defined conditions and start specific actions. You can create a policy with rules that are as simple or complex as necessary, based on the passing traffic. For example, a rule might simply determine that a client's browser is a Chrome browser that is not on an administrator network, and restrict access to certain administrative tools. Or a rule might determine that a request URL starts with /video, that the client is a mobile device, and that the client's subnet does not match 172.27.56.0/24, and then that the request to a video file is designed for mobile devices on a Content Delivery Network (CDN).
Local traffic policy rules provide you with different types of logical operators for matching conditions, which are determined by the order and configuration of the conditions within and between the rules. The different types of logical operators that you can configure are AND logical operators for conditions within a rule, and OR logical operators for values within a condition and for conditions between rules. When AND logical operators apply, then all logical operators must match the matching strategy. When OR logical operators apply, then any logical operator must match the matching strategy.
When you create a rule, you can configure two or more conditions that use AND logic within that rule. For example, you can create Rule1 with two conditions, a and b, which use AND logic when Rule1 is used by the matching strategy. This means that all conditions within a rule must succeed in order to be used by a matching strategy.
When you configure multiple values within a condition, OR logic determines if any matching value within the condition succeeds. For example, you can create a condition configured with two or more values. The matching strategy uses OR logic to determine if any configured value matches.
Similarly, when you create two or more rules, you can configure each rule with applicable conditions that use OR logic between the rules. For example, you can create Rule1 with a set of conditions, and Rule 2 with another set of conditions. The matching strategy uses OR logic to determine if a rule matches.
These examples show the logical operation of three conditions (a, b, and c) and two rules (Rule1 and Rule2).
In this first example, consider the following scenario, where you want to match condition a or b, and c ((a | b) & c). You can configure this logic by creating Rule1 to use conditions a and c (a & c), and Rule 2 to use conditions b and c (b & c). The result is when Rule1 matches the strategy, conditions a and c (a & c) are used, or when Rule 2 matches, conditions b and c (b & c) are used.
In this second example, consider the scenario where you want to match conditions a and b, or c ((a & b) | c). You can configure this logic by creating Rule1 to use conditions a and b, and Rule2 to use condition c. The result is when Rule1 matches the strategy, both conditions a and b are used, or when Rule2 matches the strategy, condition c is used.
The conditions for a local traffic policy rule define the necessary criteria that must be met in order for the rule's actions to be applied. For example, a policy might include the following condition type and settings, which, when met by a request, would allow the rule's specified actions to be applied.
|Condition Type||HTTP Host|
You can apply one or more conditions to a rule, as needed.
|Client SSL||Inspects the properties of the SSL connection on the client side of the device.
|CPU Usage||Specifies a condition that is determined by CPU usage during 15-second, 1-minute, or 5-minute intervals.|
|Geo. IP||Specifies a condition that is based on the properties of the geographical location of
the IP address.
|HTTP Basic Auth.||Inspects the username and password specified for basic authentication for the HTTP request.
|HTTP Cookie||Inspects the Cookie header of an HTTP request.|
|HTTP Header||Matches any HTTP header.|
|HTTP Host||Matches the host of an HTTP request.
|HTTP Method||Inspects the HTTP method for the request, for example, GET, POST, or HEAD.|
|HTTP Referer||Inspects the HTTP Referer header or parts of the URI.
|HTTP Set Cookie||Inspects the Set-Cookie header of an HTTP response.
|HTTP Status||Inspects the status of the HTTP response.
|HTTP URI||Inspects the URI on a request and matches parts of or the entire URI.
|HTTP User Agent||Specifies a condition that is based upon the User Agent header.
|HTTP Version||Inspects the version of an HTTP request or response.
|SSL Certificate||Inspects the properties of an SSL certificate.|
|SSL Extension||Inspects the SSL extensions that are negotiated during the HELLO phase.
|TCP||Inspects and matches the parameters associated with TCP connections.
|WebSocket||Specifies a condition based upon the properties of a websocket's connection.
Conditions for a local traffic policy enable you to assign a datagroup type and value to an operand, as applicable. For example, you could configure a condition for an HTTP Referer host that ends with a datagroup value of partner-domains.
This table describes the datagroup types and supported comparison operators.
|Datagroup type||Comparison operator|
The actions for a local traffic policy rule determine how traffic is handled. For example, actions for a rule could include the following ways of handling traffic.
|Enable||Enables the following actions.
|Disable||Disables the following actions.
|Forward traffic||Controls where a connection is forwarded.
|Insert||Inserts an HTTP header into the request or response.
|Remove||Removes an HTTP header from the request or response.
|Redirect||Redirects traffic to a different URL.|
|Reset traffic||Resets the connection.|
|Log||Writes messages to the local or remote system log.|
|Persist session||Controls how a connection is persisted.
|Set variable||Sets a Tcl variable in the runtime environment.|
Certain BIG-IP® local traffic policy actions support Tcl command substitutions, giving you significant flexibility in configuring policies. Tcl command substitutions provide quick, read-only access to immediately available runtime data, such as information about a current request’s URI, or a header or cookie in the request or response.
When using Tcl command substitutions, the following guidelines apply.
The following Tcl command is an example of a Tcl command substitution that can be used within a policy.
You can apply options to conditions and actions, as determined by the selected condition or action type. For example, you might want to constrain a condition based on the case-sensitivity of a string, which is easily applied by selecting the applicable option for that condition.
|CPU Usage||Not applicable.|
|HTTP Basic Auth.||
|HTTP Set Cookie||
|HTTP Status||Not applicable.|
|HTTP User Agent||
Note: Applies only to protocol and full string settings.
|Forward traffic||Override default forward action using:
|Reset traffic||Not applicable.|
|Persist session||Not applicable.|
|Set variable||Not applicable.|
You can use tmsh commands with policies, as necessary. Common commands include those in the table.
|Create a draft policy.||
(tmos)# create ltm policy /Common/Drafts/policy_name strategy first-match
|Publish a draft policy.||
(tmos)# publish ltm policy /Common/Drafts/policy_name
|List all draft policies.||
(tmos)# show ltm policy /Common/Drafts/*
|List all published policies.||
(tmos)# show ltm policy
|List configuration details for a draft policy.||
(tmos)# list ltm policy /Common/Drafts/policy_name
|List configuration details for a published policy.||
(tmos)# list ltm policy policy_name