LTM Policy is a highly performant-feature of the Big IP which allows administrators to inspect many aspects of the system and runtime traffic, and to take custom actions in response.  As the name suggests, this is accomplished by creating policies, and unlike iRules, does not require programming.

Every policy is a collection of rules, and is associated with a matching strategy.  Every rule in a policy is like an if-then statement: it has a set of conditions and a set of actions, either of which may be empty, but not both.  Conditions are the defined comparisons of runtime values against policy values.  Actions are the commands which will get executed when the conditions match.  As an example, one could define a policy with a condition that inspects the HTTP Referer: header, and if its hostname contains the string, then take 2 actions: write a message to the system logs, and forward the connection to a certain pool.

LTM Policy provides three matching strategies, described below.  Matching strategies come into play when a policy contains more than one rule, because different rules can match at the same time, and different behavior may be desired depending on the situation.

First Match

With a first-match strategy in effect, as soon as any of the rules match, execute the associated actions and then stop all processing.  This can be efficient, because once there is a match, no further effort is expended evaluating the conditions of the other rules.

In the case that multiple rules match at the same time, then the ordinal property of each rule is consulted.  The ordinal value is used for ordering rules, and lower value wins.

All Match

The all-match strategy is perhaps the most straightforward.  It directs the policy engine to keep evaluating rules as traffic flows, executing the associated actions as conditions are matched.   

Best Match

The best-match strategy is interesting and needs a little more background to describe its capability and customizability.  The big idea behind best-match is to find the most specific match.  When multiple rules match, the most specific match is deemed to be the one with either the most number of conditions that matched, the longest matches, or the matches which are deemed to be more significant.

In the case where multiple rules match, and the rules contain the same number of conditions, then the ultimate tiebreaker is to consult the Strategy List.  The Strategy List is the official system ordering or conditions, defining which are to be considered more significant than other conditions.  It can be viewed  in the GUI by visiting Local Traffic >> Policies >> Strategy List >> best-match, or via tmsh command line at ltm policy-strategy.  The conditions at the top of the top of the table are considered more significant than those below, so the winning rule with be the one with the most significant conditions.

The Strategy List is customizable to individual customer needs.  It is probably not all that common, but should the default hierarchy of conditions not match expectations for the situation, the table can be customized by moving conditions up and down relative to each other.  Be aware that that changes to the order affect all policies employing a best-match strategy, so consider trade-offs for customizing the order for one policy versus potential side effects on other policies that use a best-match strategy.