Hi Sebastian,
It works as first match and if the condition is satisfied, no further rules are checked.
class-map match-all TST-BL-REALSERVERS
2 match source-address 10.151.44.0 255.255.255.0
class-map match-all class_map_nat_10.151.44.0-10.252.0.0
2 match access-list acl_nat_10.151.44.0-10.252.0.0
In one condition source is defined and in other condition source and destination is defined. When packet hits ace, and let us say this class "TST-BL-REALSERVERS" condition is met, since source is same and since condition is satisfied , we won't go further. We will then go to different multi-match and do the NAT as suggested. So yes the order matters.
Here's a beautiful example of how matching works.
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 if it was helpful.
