duplicate class names under different multi match policies

axfalk — Fri, 23 Jan 2015 15:05:16 GMT

We've inherited an ACE SM 3.0 (A5.1a) config, where we noticed duplicate class names under different multi match policies, similar to this:

policy-map multi-match POLICY1
   class CLASS1-cm
    loadbalance vip inservice
    loadbalance policy CLASS1-pm
    loadbalance vip icmp-reply active

policy-map multi-match POLICY2
   class CLASS1-cm
    loadbalance vip inservice
    loadbalance policy CLASS1-pm
    loadbalance vip icmp-reply active
    appl-parameter http advanced-options HTTP-8K-HEADER

How would the ACE know which multi match policy to use?

Thanks.

Hi,It's always first match.

Kanwaljeet Singh — Fri, 23 Jan 2015 18:41:40 GMT

Hi,

It's always first match. If if the first one satisfies the condition, we don't even look at the second. We would move on to another type. I guess below explanation would answer all your doubts.

The term "multi-match" refers to execution semantics of the policy; In other words it depicts how the actions are executed for a given flow that matches the classifications in the policy.

The policy has multi-match semantics because the policy allows configuring multiple types of features like loadbalancing, NAT inspect etc; so potentially this policy can result in taking multiple actions (if multiple features are configured) for a given matching flow.

Now given that there can be multiple classifications configured for the same feature type within the policy, the rule is that we always execute *only* the first matching action for a given feature type;

for .eg consider the below;; just for brevity I am ommiting the exact syntax
of the cmds

--------------------
policy-map multi-match MYPOLICY
class LB1
loadbalance policy L7-1
loadbalance vip inservice
class NAT1
nat dynamic 100 vlan 20
class INSP1
inspect http
class LB2
loadbalance policy L7-2
loadbalance vip inservice
class NAT2
nat dynamic 200 vlan 30

interface vlan 10
service-policy input MYPOLICY
-------------------

please note above that there are 2 classes each with features loadbalance and
NAT configured and one class with inspect action;

For an incoming flow, we try to match and *execute* *ONLY* the action specified
against first matching class per feature. In otherwords, if flow matches class
LB1 then we will execute "loadbalance action L7-1" and we wont even try to see
if class LB2 matches as it is of the same feature type. Only if class LB1 does
not match we look at LB2. However we continue matching other class'es since
they have different feature types;

This happens for each feature type; Essentially between the class-maps of same
feature type think of this as first-match and across features its multiple match.

potentially for above policy the flow can match the below possible classes:
LB1, NAT1, INSP1
LB2, NAT1, INSP1
LB2, NAT2, INSP1
LB1, NAT2, INSP1

but the below is not possible;
LB1, LB2, NAT1, INSP1
LB2, NAT1, NAT2, INSP1

you can visualize the above multi-match policy like below; (pls note that below
syntax is not supported and is strictly for illustration purposes only) below has
policy types per FEATURE and each such policy can result in ONLY ONE match/action
being executed;

-------------
policy-map type SLB first-match LBPOLICY
class LB1
loadbalance policy L7-1
loadbalance vip inservice
class LB2
loadbalance policy L7-2
loadbalance vip inservice

policy-map type NAT first-match NATPOLICY
class NAT1
nat dynamic 100 vlan 20
class NAT2
nat dynamic 200 vlan 30

policy-map type inspect first-match INSPECTPOLICY
class INSP1
inspect http

interface vlan 10
service-policy input LBPOLICY
service-policy input NATPOLICY
service-policy input INSPECTPOLICY
-------------

Regards,

Kanwal

Note: Please mark answers if they are helpful.

topic Hi,It's always first match. in Application Networking

duplicate class names under different multi match policies

Hi,It's always first match.