01-23-2015 07:05 AM
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.
Solved! Go to Solution.
01-23-2015 10:41 AM
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.
01-23-2015 10:41 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide