The inbound network traffic destined to, or passing through, the ACE is classified based on a series of flow match criteria specified by a class map. Each class map defines a traffic classification: network traffic that is of interest. A policy map defines a series of actions (functions) that you want applied to a set of classified inbound traffic.
Class maps and Policy maps
The class-map command defines each Layer 3 and Layer 4 traffic class and each Layer 7 protocol class. The individual match commands specify the criteria for classifying Layer 3 and Layer 4 network traffic as well as the Layer 7 HTTP server load balancing and application protocol-specific fields. When multiple match criteria exist in the traffic class, you can identify evaluation instructions by using the match-any or match-all keywords. If you specify match-any as the evaluation instruction, the traffic being evaluated must match one of the specified criteria, which are typically match commands of the same type. If you specify match-all as the evaluation instruction, the traffic being evaluated must match all of the specified criteria, which are typically match commands of different types. The policy-map command creates the traffic policy. The purpose of a traffic policy is to implement specific ACE functions associated with a traffic class.
Understanding Traffic Classification
The traffic classification process consists of the following three steps:
Step 1. Creating a class map by using the class-map command and the associated match commands, which comprise a set of match criteria related to Layer 3 and Layer 4 traffic classifications or Layer 7 protocol classifications.
Step 2. Creating a policy map by using the policy-map command, which refers to the class maps and identifies a series of actions to perform based on the traffic match criteria.
Step 3. Activating the policy map and attaching it to a specific VLAN interface or globally to all VLAN interfaces associated with a context by using the service-policy command that are to filter traffic received by the ACE.
Multi-match Policy maps
For policy-map commands that contain the multi-match keyword, these commands specify that multiple sets of classes exist in the policy map and allow a multi-feature policy map. The ACE applies a first-match execution process to each class set in which a packet can match multiple classes within the policy map, but the ACE executes the action for only one matching class within each of the class sets. Layer 7 policy-maps use the first-match parameter. It means that the first match that the incoming traffic matches under the policy-map, will make that a match to this policy-map. No other match statements will be compared to the traffic at that point. Layer 3/4 policy-maps use the multi-match parameter. This is because client traffic may match more than one layer 3/4 class-map under the policy-map. The ACE will check to see if the client traffic matches each one of the classes under the policy-map, but only once for each feature. Features include loadbalancing, NAT, inspection, etc.
For example 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 , the ACE won't go further. ACE will then go to different multi-match and do the NAT as suggested. So the order in which these are put does matter.
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 ACE always execute *only* the first matching action for a given feature type; for .eg consider the below; just for brevity the exact syntax of the commands is omitted.
-------------------- 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
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, ACE will try to match and *execute* *ONLY* the action specified against first matching class per feature. In otherwords, if flow matches class LB1 then ACE will execute "loadbalance action L7-1" and wont even try to see if class LB2 matches as it is of the same feature type. Only if class LB1 does not match ACE will look at LB2. However ACE continue matching other classes 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
Dear Experts, One of our customer is evaluating DCI to connect 2 sites across L3 mpls circuit. For DCI they are considering Vxlan (only open standard no OTV or juniper specific etc). From design perspective what i dont understand is, its easy t...
Hi all, we've been using a hardware version of the ACI Simulator for quite some time and really grew fond of it for testing automation solutions we developed for our production fabric. Recently we decided to switch to VM. Our Production-Fabric runs o...
Hello, We would like to change the airflow direction (and thus the fan module) on a CISCO C3850-24-XS-S switch.Is it possible on this type of switch ? We have also seen that the CISCO C3850-48-XS-S had two fan modules (FAN-T3-R= & FAN-T3-F=)...
Hello ACI Gurus. I am currently migrating a two sets of Palo Alto Physical firewalls directly counted to old Cisco 6509 switches to ACI. The way current environment is communicating between ACI and legacy 6509 switches is via a L2 link with a S...