A traffic policy is used in QoS multi-field classification to implement various QoS policies.
A traffic policy consists of three parts:
Figure 1 shows relationships between an interface, traffic policy, traffic behavior, traffic classifier, and ACL.
One or more classifier & behavior pairs can be configured in a traffic policy. A packet is matched against traffic classifiers in the order in which those classifiers are configured. If the packet matches a traffic classifier, no further match operation is performed. If not, the packet is matched against the following traffic classifiers one by one. If the packet matches no traffic classifier at all, the packet is forwarded with no traffic policy executed.
The order of the traffic classifiers can be changed by the classifier behavior command.
For example, classifiers (named A, B, and C) are configured in traffic-policy T:
# traffic policy T classifier A behavior A classifier B behavior B classifier C behavior C #
By default, the order of classifier A, B, and C are 1, 2, and 3, which is the same as configuration order. Now if you want to move the classifier A to be the last one, you can run the following command:
classifier A behavior A precedence 4
The result is:
# traffic policy T classifier B behavior B classifier C behavior C classifier A behavior A precedence 4 #
The precedence 1 is not used, so you can add a classifier (named D) before classifier B by the following command:
classifier D behavior D precedence 1
The result is:
# traffic policy T classifier D behavior D precedence 1 classifier B behavior B classifier C behavior C classifier A behavior A precedence 4 #
If you can add the classifier D by the following command not specifying precedence:
classifier D behavior D
The result is:
# traffic policy T classifier B behavior B classifier C behavior C classifier A behavior A precedence 4 classifier D behavior D #
If multiple if-match clauses are configured for a traffic classifier, the packet is matched against them in the order which they are configured. If the packet is matched with one of the if-match clauses, the related behavior is executed or not, depends on the AND/OR Logic.
If a traffic classifier has multiple matching rules, the AND/OR logic relationships between rules are described as follows:
As shown in the Figure 2, for each Classifier, if the logic between If-match clauses is OR, a packet is matched against If-match clauses in the order of the If-match clauses configuration. Once the packet is matched with an if-match clause:
If the packet is not matched any if-match clause, the related behavior is not executed, and the next Classifier is processed for the packet.
If the logic between If-match clauses is AND, the device combines all If-match clauses, and then processes the combined If-match clause according to the procedure of OR logic.
If one of the if-match clauses is applied with ACL, each rule of the ACL is combined with all of the other if-match clauses.
Note: the rules of the ACL will not be combined. Therefore, the order of the If-match clauses in And logic does not impact on the final matching result, but the order of the rules in the ACL still impacts on the final result.
For example, in the following configuration:
# acl 3000 rule 5 permit ip source 18.104.22.168 0 rule 10 deny ip source 22.214.171.124 0 # traffic classifier example operator and if-match acl 3000 if-match dscp af11 #
The device will combine all if-match clauses. The combination result is the same as the following configurations.
# acl 3000 rule 5 permit ip source 126.96.36.199 0 dscp af11 rule 10 deny ip source 188.8.131.52 0 dscp af11 # traffic classifier example operator or if-match acl 3000 # traffic behavior example remark dscp af22 # traffic policy example share-mode classifier example behavior example # interface GigabitEthernet0/1/2 traffic-policy P inbound #
Then, the device process the combined If-match clause according to the procedure of OR logic. The result is, the DSCP of the packets is remark as AF22 if the packet is received from GE2/0/0 and the DSCP is 10 and the source IP address is 184.108.40.206/32; the DSCP of the packets is discarded if the packet is received from GE0/1/2 and the DSCP is 10 and the source IP address is 220.127.116.11/32; other packets are forwarded directly since they are not matched any rule.
In the License, AND logic permits only one if-match clause applied with ACL, and OR logic permits multiple if-match clauses applied with ACL.
If an ACL is specified in an if-match clause, the packet is matched against the multiple rules in the ACL. The device first checks whether the ACL exists. (A non-existent ACL can be applied to a traffic classifier.) If the packet matches a rule in the ACL, no further match operation is performed.
For traffic behavior sampling, even if a packet matches a rule that defines a deny action, the traffic behavior takes effect for the packet.
A permit or deny action can be specified in an ACL for a traffic classifier to work with specific traffic behaviors as follows:
For example, the following configuration leads to such a result: the IP precedence of packets with the source IP address 10.1.1.1/24 are re-marked as 7; the packets with the source IP address 10.1.1.2/24 are dropped; the packets with the source IP address 10.1.2.1/24 are forwarded with the IP precedence unchanged.
acl 3999 rule 5 permit ip source 10.1.1.1 0.0.0.255 rule 10 deny ip source 10.1.1.2 0.0.0.255 traffic classifier acl if-match acl 3999 traffic behavior test remark ip-pre 7 traffic policy test classifier acl behavior test interface GigabitEthernet0/1/1 traffic-policy test inbound
By default, ACL traffic statistics is disabled. You can, however, use the statistics enable command to enable traffic statistics.
# traffic policy example classifier example behavior example statistics enable #