LTM Policy – Matching Strategies

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).

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.

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?

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.