Technical Articles
F5 SMEs share good practice.
Showing results for 
Search instead for 
Did you mean: 
Historic F5 Account


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.



thanks for sharing!



What is the behaviour (what happen) when none of the rules match and I use the first-match strategy?


I have created one specific rule that verifies the content of a specific URI. It should work like this:


  • I have the one backend server ABC that runs services in two differents ports: one service is in 9443 port and the other in 8080 port.
  • If a URI starts with XYZ, the expected behaviour it's to redirect to a specific pool (POOLA) that execute the service in server ABC that is in port 9443.
  • Else, it should redirect to a specific pool (POOLB) service in server ABC that runs in port 8080.

The VS is vinculated to poolB ( that runs service in 8080 port).


Historic F5 Account

Starting from a high level, if no rules match then no actions should be executed. So the trick is to make sure that there is one rule that always matches.


It sounds like what you want is logic like this:


if (URI starts with 'XYZ) { forward to POOLA } else { forward to POOLB }

In LTM Policy, the way to do this is to have 2 rules:


  1. The first rule has a condition that compares the URI, and an action to forward to the desired pool.


  2. The second rule would be what we call a 'default' rule, that is, one that does not have a condition but has an action - in this case forwarding traffic to the other pool. In LTM Policy, when a rule has no conditions specified then it is always considered to be a match. So it is common practice to make the last rule be a default rule, one which is guaranteed to match and give predictable behavior when no other rules apply. One detail to note is that the default rule should have the highest value for the 'ordinal' parameter, which is used for ordering rules in a policy.


Here is what such a policy might look like in bigip.conf:


ltm policy /Common/Drafts/my-forwarding-policy { controls { forwarding } requires { http } rules { default-rule { actions { 0 { forward select pool /Common/POOLB } } ordinal 1 } r1 { actions { 0 { forward select pool /Common/POOLA } } conditions { 0 { http-uri path starts-with values { /XYZ } } } } } strategy /Common/first-match



Note that rule 'default-rule' has no conditions specified, and even though it appears in the config file ahead of rule 'r1', it will be evaluated after since it has ordinal 1, while r1 has ordinal 0 (which is a default and therefore not shown explicitly).


And here is how you'd create such a policy from tmsh:


create ltm policy /Common/Drafts/my-forwarding-policy rules add { r1 { conditions add { 0 { http-uri path starts-with values { /XYZ } }} actions add { 0 { forward select pool POOLA }} ordinal 0 } default-rule { actions add { 0 { forward select pool POOLB } } ordinal 1 }}


Hope this is helpful.



Hi Steve McCarthy,


Thanks for your time and answer.


My problem it was that I wasn't defining a default rule. When none of the rules matched, the LTM randomly choose which rule to use. In my case, even without to match a specific condition, the request it was forward to one port. After some time (not predictable minutes), the same request it was forward to another port. None of my rules had condition that matched my request chracteristics (request's URI). When I decided to define my default rule (without any condition), it worked.


Historic F5 Account

If LTM policy were randomly choosing rules when none matched, then that would be a problem (and I would be interested in getting a repro).


Perhaps what was going on before was just normal load balancing? It sounds like your policy actions were choosing a pool, so if no rules were matching, then connections could be spread out based on whatever load balancing scheme is defined for the virtual server. And that could certainly appear to be somewhat random.



F5 training material for v12.1 lists three evaluations for the 'Best Match' strategy:


  • of conditions/operands matched
  • Matched value length
  • Operand priority

This article only mentions two (but may have been written with v12.0 in mind), which is correct?


I'm also interested in the sentence "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."


What happens if there are two rules, A & B, where A has three operands, B has two and test traffic only matches two out of three for rule A but matches both conditions for B. Does the strategy choose the rule with the greatest percentage of matching operands?


Historic F5 Account

In the situation cited, where traffic matches 2 of rule A's 3 operands, then that rule is not a match. So there would be no need for a further comparison against rule B.



Yeah, I totally overthought that one.


Version history
Last update:
‎27-Jun-2016 14:54
Updated by: