The traffic policy command creates a traffic policy and specifies the matching order of traffic classifiers in the traffic policy.
The undo traffic policy command deletes a traffic policy.
By default, no traffic policy is created in the system.
traffic policy policy-name [ match-order { auto | config } ] [ atomic ]
undo traffic policy policy-name
Only the S5720-EI, S5720-HI, S5730-HI, S5731-H, S5731-S, S5731S-H, S5731S-S, S5732-H, S5735-L, S5735S-L, S5735S-L-M, S5735-S, S5735S-S, S5735-S-I, S6720-EI, S6720-HI, S6720S-EI, S6730-H, S6730S-H, S6730-S, and S6730S-S support match-order { auto | config }.
Parameter |
Description |
Value |
---|---|---|
policy-name |
Specifies the name of a user-defined traffic policy. |
The value is a string of 1 to 64 case-sensitive characters, spaces not supported. When double quotation marks are used around the string, spaces are allowed in the string. The value cannot be f, fa, fas , fast, fast-, fast-m, fast-mo, fast-mod, or fast-mode. |
match-order |
Specifies the matching order of traffic classifiers in the traffic policy. By default, the matching order of traffic classifiers in a traffic policy is config. |
- |
auto |
Indicates that the matching order depends on priorities of traffic classifier types. If the traffic policy is applied to the inbound direction on the S5720-EI, S6720-EI, or S6720S-EI, traffic classifiers based on the following information are matched in descending order of priority: Layer 2 and IPv4 Layer 3 information > advanced ACL6 > basic ACL6 > IPv4 Layer 3 information > Layer 2 information > user-defined ACL information. In other cases, traffic classifiers based on the following information are in descending order of priority:
If this parameter is specified, ACL resources are saved. |
- |
config |
Indicates that the matching order depends on the sequence in which traffic classifiers were bound to traffic behaviors. If this parameter is specified, more ACL resources are consumed. |
- |
atomic |
Indicates the atomic attribute of a traffic policy. After this parameter is specified, if a traffic policy references an ACL and the ACL is applied to a specified object, dynamically updating the ACL does not interrupt services. |
- |
Usage Scenario
Packets are obtained based on Layer 2 information, Layer 3 information, or ACLs. To implement differentiated services for service flows of packets, bind a traffic classifier and a traffic behavior to the created traffic policy and apply the traffic policy. You can use the traffic policy command to create a traffic policy. A maximum of 256 traffic policies can be created on the device.
Pre-configuration Tasks
A traffic classifier and a traffic behavior have been created.
Follow-up Procedure
Precautions
For the S5720-HI, S5730-HI, S5731-H, S5731-S, S5731S-H, S5731S-S, S5732-H, S6720-HI, S6730-H, S6730S-H, S6730-S, and S6730S-S, no matter whether the traffic policy defines the auto or config matching order, traffic classifiers bound to the traffic policy always take effect in the config matching order.
For the S5720-EI, S5735-L, S5735S-L, S5735S-L-M, S5735-S, S5735-S-I, S5735S-S, S6720-EI, and S6720S-EI, when the traffic policy that defines the config matching order is applied to the inbound direction, traffic classifiers bound to the traffic policy take effect in the config matching order. When the traffic policy is applied to the outbound direction, even if the matching order is config, traffic classifiers bound to the traffic policy still take effect in the auto matching order.
For the S5720-EI, S6720-EI, and S6720S-EI, when any of the following actions is defined in a traffic action of a traffic policy, even if the matching order is config, traffic classifiers bound to the traffic policy still take effect in the auto matching order:
You cannot directly modify the atomic attribute of a created traffic policy. To modify the atomic attribute, delete the traffic policy, and then recreate the traffic policy with the atomic attribute being specified or deleted.
The atomic attribute is valid for the traffic policy only containing the permit or deny action. If the traffic policy in which the atomic attribute is specified contains other actions in addition to permit or deny, applying the traffic policy will cause a failure to deliver the configuration.
For the traffic policy with specified atomic attribute, when the ACL configuration is being updated dynamically, ensure that the device has sufficient ACL resources. Otherwise, the updated ACL configuration will fail to be delivered.
If the atomic attribute is specified for a traffic policy and the device is downgraded from the current version to a version earlier than V200R011C10, the traffic policy configuration cannot be restored during device restart.
If the traffic policy that you want to delete has been applied to the system, an interface, or a VLAN, run the undo traffic-policy command to unbind the traffic policy in the corresponding view. Then run the undo traffic policy command in the system view to delete the traffic policy. The traffic policy that is not applied can be deleted directly.
When rule is configured in the traffic policy and permit ip is specified, many ARP Miss packets may be sent to the CPU. As a result, the device is disconnected.
# Create a traffic policy p1, and associate the traffic classifier c1 with the traffic behavior b1 in the traffic policy.
<HUAWEI> system-view [HUAWEI] traffic classifier c1 [HUAWEI-classifier-c1] if-match any [HUAWEI-classifier-c1] quit [HUAWEI] traffic behavior b1 [HUAWEI-behavior-b1] remark 8021p 2 [HUAWEI-behavior-b1] quit [HUAWEI] traffic policy p1 [HUAWEI-trafficpolicy-p1] classifier c1 behavior b1
# Delete the traffic policy p1 that has been applied to the inbound indirection on GE0/0/1.
<HUAWEI> system-view [HUAWEI] interface gigabitethernet 0/0/1 [HUAWEI-GigabitEthernet0/0/1] undo traffic-policy p1 inbound [HUAWEI-GigabitEthernet0/0/1] quit [HUAWEI] undo traffic policy p1