- Table of Contents
- Related Documents
-
Title | Size | Download |
---|---|---|
02-QoS configuration | 733.17 KB |
QoS processing flow in a device
Configuration procedure diagram
Applying the QoS policy to an interface
Applying the QoS policy to a VLAN
Applying the QoS policy globally
Applying the QoS policy to a control plane
Applying the QoS policy to the management interface control plane
Displaying and maintaining QoS policies
Priority mapping configuration tasks
Configuring a colored priority map
Configuring an uncolored priority map
Configuring a port to trust packet priority for priority mapping
Changing the port priority of an interface
Displaying and maintaining priority mapping
Priority mapping configuration examples
Priority trust mode configuration example
Configuring traffic policing and GTS
Traffic evaluation and token buckets
Displaying and maintaining traffic policing and GTS
Traffic policing configuration example
Configuring hardware congestion management
Configuration approaches and task list
Configuring per-queue hardware congestion management
Displaying and maintaining per-queue hardware congestion management
Configuring queue scheduling profiles
Configuring a queue scheduling profile
Displaying and maintaining queue scheduling profiles
Queue scheduling profile configuration example
Configuring low-latency queuing
Actions supported in the inbound direction and configuration restrictions
Actions supported in the outbound direction and configuration restrictions
Configuring protocol packet rate limiting
Configuring traffic redirecting
Displaying and maintaining global CAR
Configuring class-based accounting·
Configuring traffic accounting
Displaying and maintaining traffic accounting
Configuring queue-based accounting·
Displaying and maintaining queue-based accounting
Appendix B Default priority maps
Appendix C Introduction to packet precedences
In data communications, Quality of Service (QoS) provides differentiated service guarantees for diversified traffic in terms of bandwidth, delay, jitter, and drop rate, all of which can affect QoS.
Network resources are limited. When configuring a QoS scheme, you must consider the characteristics of different applications. For example, when bandwidth is fixed, more bandwidth used by one user leaves less bandwidth for others. QoS prioritizes traffic to balance the interests of users and manage network resources.
The following section describes typical QoS service models and widely used QoS techniques.
QoS service models
This section describes several typical QoS service models.
Best-effort service model
The best-effort model is a single-service model. As the simplest service model, the best-effort model is not as reliable as other models and does not guarantee delay-free delivery.
The best-effort service model is the default model for the Internet and applies to most network applications. It uses the First In First Out (FIFO) queuing mechanism.
IntServ model
The integrated service (IntServ) model is a multiple-service model that can accommodate diverse QoS requirements. This service model provides the most granularly differentiated QoS by identifying and guaranteeing definite QoS for each data flow.
In the IntServ model, an application must request service from the network before it sends data. IntServ signals the service request with the RSVP. All nodes receiving the request reserve resources as requested and maintain state information for the application flow.
The IntServ model demands high storage and processing capabilities because it requires all nodes along the transmission path to maintain resource state information for each flow. This model is suitable for small-sized or edge networks. However, it is not large-sized networks, for example, the core layer of the Internet, where billions of flows are present.
DiffServ model
The differentiated service (DiffServ) model is a multiple-service model that can meet diverse QoS requirements. It is easy to implement and extend. DiffServ does not signal the network to reserve resources before sending data, as IntServ does.
All QoS techniques in this document are based on the DiffServ model.
QoS techniques overview
The QoS techniques include the following features:
· Traffic classification.
· Traffic policing.
· Traffic shaping.
· Congestion management.
· Congestion avoidance (not supported).
The following section briefly introduces these QoS techniques.
All QoS techniques in this document are based on the DiffServ model.
Deploying QoS in a network
Figure 1 Position of the QoS techniques in a network
As shown in Figure 1, traffic classification, traffic shaping, traffic policing, congestion management, and congestion avoidance mainly implement the following features:
· Traffic classification—Uses match criteria to assign packets with the same characteristics to a traffic class. Based on traffic classes, you can provide differentiated services.
· Traffic policing—Polices flows and imposes penalties to prevent aggressive use of network resources. You can apply traffic policing to both incoming and outgoing traffic of a port.
· Traffic shaping—Adapts the output rate of traffic to the network resources available on the downstream device to eliminate packet drops. Traffic shaping usually applies to the outgoing traffic of a port.
· Congestion management—Provides a resource scheduling policy to determine the packet forwarding sequence when congestion occurs. Congestion management usually applies to the outgoing traffic of a port.
· Congestion avoidance—Monitors the network resource usage. It is usually applied to the outgoing traffic of a port. When congestion worsens, congestion avoidance reduces the queue length by dropping packets.
QoS processing flow in a device
Figure 2 briefly describes how the QoS module processes traffic.
1. Traffic classifier identifies and classifies traffic for subsequent QoS actions.
2. The QoS module takes various QoS actions on classified traffic as configured, depending on the traffic processing phase and network status. For example, you can configure the QoS module to perform the following operations:
¡ Traffic policing for incoming traffic.
¡ Traffic shaping for outgoing traffic.
¡ Congestion avoidance before congestion occurs.
¡ Congestion management when congestion occurs.
You can configure QoS by using the MQC approach or non-MQC approach. Some features support both approaches, but some support only one.
Non-MQC approach
In the non-MQC approach, you configure QoS service parameters without using a QoS policy. For example, you can use the traffic shaping feature to limit the traffic rate on an interface without using a QoS policy.
MQC approach
In the modular QoS configuration (MQC) approach, you configure QoS service parameters by using QoS policies. A QoS policy defines the shaping, policing, or other QoS actions to take on different classes of traffic. It is a set of class-behavior associations.
A traffic class is a set of match criteria for identifying traffic, and it uses the AND or OR operator.
· If the operator is AND, a packet must match all the criteria to match the traffic class.
· If the operator is OR, a packet matches the traffic class if it matches any of the criteria in the traffic class.
A traffic behavior defines a set of QoS actions to take on packets, such as priority marking and redirect.
By associating a traffic behavior with a traffic class in a QoS policy, you apply QoS actions in the traffic behavior to the traffic class.
Configuration procedure diagram
Figure 3 shows how to configure a QoS policy.
Figure 3 QoS policy configuration procedure
Defining a traffic class
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured. For more information, see the if-match command in ACL and QoS Command Reference. |
Defining a traffic behavior
A traffic behavior is a set of QoS actions (such as traffic filtering, shaping, policing, and priority marking) to perform on a traffic class.
To define a traffic behavior:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
3. Configure actions in the traffic behavior. |
See the subsequent chapters, depending on the purpose of the traffic behavior: traffic policing, traffic filtering, priority marking, traffic accounting, and so on. |
By default, no action is configured for a traffic behavior. |
Defining a QoS policy
To perform the actions defined in a behavior for a class of packets, associate the behavior with the class in a QoS policy.
To associate a traffic class with a traffic behavior in a QoS policy:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
3. Associate a traffic class with a traffic behavior to create a class-behavior association in the QoS policy. |
classifier classifier-name behavior behavior-name [ mode dcbx ] |
By default, a traffic class is not associated with a traffic behavior. Repeat this step to create more class-behavior associations. The mode dcbx keyword specifies that a class-behavior association applies only to DCBX. For more information about DCBX, see Layer 2—LAN Switching Configuration Guide. |
|
IMPORTANT: When an ACL is used by a QoS policy for traffic classification, the deny action in an ACL rule means not executing the behavior of the corresponding class-behavior association, and the permit action in an ACL rule means executing the behavior of the corresponding class-behavior association. |
Applying the QoS policy
You can apply a QoS policy to the following destinations:
· Interface—The QoS policy takes effect on the traffic sent or received on the interface.
· VLAN—The QoS policy takes effect on the traffic sent or received on all ports in the VLAN.
· Globally—The QoS policy takes effect on the traffic sent or received on all ports.
· Control plane—The QoS policy takes effect on the traffic sent to the control plane.
· Management interface control plane—The QoS policy takes effect on the traffic sent to the management interface control plane.
You can modify traffic classes, traffic behaviors, and class-behavior associations in a QoS policy even after it is applied. If a traffic class uses an ACL for traffic classification, you can delete or modify the ACL.
Global QoS policies, interface QoS policies, and VLAN QoS policies are in the descending order of priority.
Applying the QoS policy to an interface
A QoS policy can be applied to multiple interfaces, but only one QoS policy can be applied to one direction (inbound or outbound) of an interface.
The QoS policy applied to the outgoing traffic on an interface does not regulate local packets. Local packets refer to critical protocol packets sent by the local system for operation maintenance. The most common local packets include link maintenance, routing, LDP, and SSH packets.
To apply the QoS policy to an interface:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
QoS policies cannot be applied to VLAN or aggregate interfaces. |
3. Apply the QoS policy to the interface. |
qos apply policy policy-name { inbound | outbound } |
By default, no QoS policy is applied to an interface. |
Applying the QoS policy to a VLAN
You can apply a QoS policy to a VLAN to regulate traffic of the VLAN.
Configuration restrictions and guidelines
· QoS policies cannot be applied to dynamic VLANs, including VLANs created by MVRP.
· When you apply a QoS policy to VLANs, the QoS policy is applied to the specified VLANs on all interface cards. If the hardware resources of an interface card are insufficient, applying a QoS policy to VLANs will fail on the interface card. The system does not automatically roll back the QoS policy configuration already applied to the MPU or other interface cards. To ensure consistency, use the undo qos vlan-policy vlan command to manually remove the QoS policy configuration applied to them.
Configuration procedure
To apply the QoS policy to a VLAN:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Apply the QoS policy to VLANs. |
qos vlan-policy policy-name vlan vlan-id-list { inbound | outbound } |
By default, no QoS policy is applied to a VLAN. |
Applying the QoS policy globally
You can apply a QoS policy globally to the inbound or outbound direction of all ports.
If the hardware resources of an interface card are insufficient, applying a QoS policy globally will fail on the interface card. The system does not automatically roll back the QoS policy configuration already applied to the main processing unit or other interface cards. To ensure consistency, you must use the undo qos apply policy global command to manually remove the QoS policy configuration applied to them.
To apply the QoS policy globally:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Apply the QoS policy globally. |
qos apply policy policy-name global { inbound | outbound } |
By default, no QoS policy is applied globally. |
Applying the QoS policy to a control plane
A switch provides the data plane and the control plane.
· Data plane—The units (such as various dedicated forwarding chips) at the data plane are responsible for receiving, transmitting, and forwarding packets. They deliver super processing speeds and throughput.
· Control plane—The units (such as CPUs) at the control plane are processing units running most routing and switching protocols. They are responsible for protocol packet resolution and calculation (packets sent from the management interface not included). Compared with data plane units, the control plane units allow for greater packet processing flexibility but have lower throughput.
When the data plane receives packets that it cannot recognize or process, it transmits them to the control plane. If the transmission rate exceeds the processing capability of the control plane, the control plane will be busy handling undesired packets. Then, the control plane will fail to handle legitimate packets correctly or timely. As a result, protocol performance is affected.
To address this problem, apply a QoS policy to the control plane to take QoS actions, such as traffic filtering or rate limiting, on inbound traffic. This ensures that the control plane can correctly receive, transmit, and process packets.
By default, the switch is enabled with the predefined control plane QoS policy. The predefined control plane QoS policy uses the protocol type to identify the packets sent to the control plane. You can use protocol types in if-match commands for traffic classification. Then you can reconfigure traffic behaviors for these traffic classes. You can use the display qos policy control-plane pre-defined command to display predefined control plane QoS policies.
If the hardware resources of an interface card are insufficient, applying a QoS policy to the control plane might fail. The system does not automatically roll back the QoS policy already applied to the MPU or other interface cards. To ensure consistency, you must use the undo qos apply policy command to manually remove the QoS policy applied to them.
In a QoS policy, do not configure the car cir or filter deny command in the associated traffic behavior of a class when the following conditions exist:
· In the class, an Ethernet frame header ACL with a rule that permits all packets is used as the match criterion.
· The QoS policy is to be applied to the control plane of the card where an IRF physical port resides.
Otherwise, an IRF split might occur.
Configuration procedure
To apply the QoS policy to a control plane:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter control plane view. |
· In standalone mode: · In IRF mode: |
N/A |
3. Apply the QoS policy to the control plane. |
qos apply policy policy-name inbound |
By default, no QoS policy is applied to a control plane. |
Applying the QoS policy to the management interface control plane
If the rate of the packets from the management interface to the control plane exceeds the processing capability, the control plane will fail to handle the packets correctly or timely. As a result, protocol performance is affected.
To address this problem, apply a rate-limiting QoS policy to the packets sent from the management interface to the control plane. This ensures that the control plane can correctly receive, transmit, and process packets from the management interface.
By default, the management interface is enabled with predefined rate-limiting QoS policies. A predefined rate-limiting QoS policy uses protocol types or protocol group types to identify the packets sent to the management interface. You can use protocol types or protocol group types in if-match commands for traffic classification and then reconfigure traffic behaviors for these traffic classes. You can use the display qos policy control-plane management pre-defined command to display the predefined rate-limiting QoS policies.
To apply the QoS policy to the management interface control plane:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter management interface control plane view. |
control-plane management |
N/A |
3. Apply the QoS policy to the management interface control plane. |
qos apply policy policy-name inbound |
By default, no QoS policy is applied to the management interface control plane. |
Displaying and maintaining QoS policies
Execute display commands in any view and reset commands in user view.
Task |
Command |
Display traffic class configuration (in standalone mode). |
display traffic classifier user-defined [ classifier-name ] [ slot slot-number ] |
Display traffic class configuration (in IRF mode). |
display traffic classifier user-defined [ classifier-name ] [ chassis chassis-number slot slot-number ] |
Display traffic behavior configuration (in standalone mode). |
display traffic behavior user-defined [ behavior-name ] [ slot slot-number ] |
Display traffic behavior configuration (in IRF mode). |
display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number ] |
Display QoS and ACL resource usage (in standalone mode). |
display qos-acl resource [ slot slot-number ] |
Display QoS and ACL resource usage (in IRF mode). |
display qos-acl resource [ chassis chassis-number slot slot-number ] |
Display the configuration of user-defined QoS policies (in standalone mode). |
display qos policy user-defined [ policy-name [ classifier classifier-name ] ] [ slot slot-number ] |
Display the configuration of user-defined QoS policies (in IRF mode). |
display qos policy user-defined [ policy-name [ classifier classifier-name ] ] [ chassis chassis-number slot slot-number ] |
Display QoS policy configuration on a specific interface or all interfaces. |
display qos policy interface [ interface-type interface-number ] [ inbound | outbound ] |
Display information about QoS policies applied to VLANs (in standalone mode). |
display qos vlan-policy { name policy-name | vlan vlan-id } [ slot slot-number ] [ inbound | outbound ] |
Display information about QoS policies applied to VLANs (in IRF mode). |
display qos vlan-policy { name policy-name | vlan [ vlan-id ] } [ chassis chassis-number slot slot-number ] [ inbound | outbound ] |
Display information about QoS policies applied globally (in standalone mode). |
display qos policy global [ slot slot-number ] [ inbound | outbound ] |
Display information about QoS policies applied globally (in IRF mode). |
display qos policy global [ chassis chassis-number slot slot-number ] [ inbound | outbound ] |
Display information about QoS policies applied to a control plane (in standalone mode). |
display qos policy control-plane slot slot-number |
Display information about QoS policies applied to a control plane (in IRF mode). |
display qos policy control-plane chassis chassis-number slot slot-number |
Display information about QoS policies applied to the management interface control plane. |
display qos policy control-plane management |
Display information about the predefined QoS policy applied to a control plane (in standalone mode). |
display qos policy control-plane pre-defined [ slot slot-number ] |
Display information about the predefined QoS policy applied to a control plane (in IRF mode). |
display qos policy control-plane pre-defined [ chassis chassis-number slot slot-number ] |
Display information about the predefined QoS policy applied to the management interface control plane. |
display qos policy control-plane management pre-defined |
Clear the statistics for the QoS policy applied to VLANs. |
reset qos vlan-policy [ vlan vlan-id ] [ inbound | outbound ] |
Clear the statistics for a QoS policy applied globally. |
reset qos policy global [ inbound | outbound ] |
Clear the statistics for QoS policies applied to a control plane (in standalone mode). |
reset qos policy control-plane slot slot-number |
Clear the statistics for QoS policies applied to a control plane (in IRF mode). |
reset qos policy control-plane chassis chassis-number slot slot-number |
Clear the statistics for QoS policies applied to the management interface control plane. |
reset qos policy control-plane management |
Overview
When a packet arrives, a device assigns a set of QoS priority parameters to the packet based on either of the following:
· A priority field carried in the packet.
· The port priority of the incoming port.
This process is called priority mapping. During this process, the device can modify the priority of the packet according to the priority mapping rules. The set of QoS priority parameters decides the scheduling priority and forwarding priority of the packet.
Priority mapping is implemented with priority maps and involves the following priorities:
· 802.11e priority.
· 802.1p priority.
· DSCP.
· EXP.
· IP precedence.
· Local precedence.
· Drop priority.
Introduction to priorities
Priorities include the following types: priorities carried in packets, and priorities locally assigned for scheduling only.
Packet-carried priorities include 802.1p priority, DSCP precedence, IP precedence, and EXP. These priorities have global significance and affect the forwarding priority of packets across the network. For more information about these priorities, see "Appendixes."
Locally assigned priorities only have local significance. They are assigned by the device only for scheduling. These priorities include the local precedence, drop priority, and user priority, as follows:
· Local precedence—Used for queuing. A local precedence value corresponds to an output queue. A packet with higher local precedence is assigned to a higher priority output queue to be preferentially scheduled.
· Drop priority—Used for making packet drop decisions. Packets with the highest drop priority are dropped preferentially.
Priority maps
The device provides various types of priority maps. By looking through a priority map, the device decides which priority value to assign to a packet for subsequent packet processing.
The default priority maps (as shown in Appendix B Default priority maps) are available for priority mapping. They are adequate in most cases. If a default priority map cannot meet your requirements, you can modify the priority map as required.
Priority mapping configuration tasks
You can configure priority mapping by using any of the following methods:
· Configuring priority trust mode—In this method, you can configure a port to look up a trusted priority type (802.1p, for example) in incoming packets in the priority maps. Then, the system maps the trusted priority to the target priority types and values.
· Changing port priority—If no packet priority is trusted, the port priority of the incoming port is used. By changing the port priority of a port, you change the priority of the incoming packets on the port.
· Configuring a QoS policy containing the priority mapping (called primap) action with the primap command.
To configure priority mapping, perform the following tasks:
Tasks at a glance |
(Optional.) Configuring priority maps |
(Required.) Perform one of the following tasks: · Configuring a port to trust packet priority for priority mapping |
Configuring priority maps
The switch provides the following types of priority map:
Description |
|
dot1p-dot1p |
802.1p-802.1p priority map. |
dot1p-dp |
802.1p-drop priority map. |
dot1p-dscp |
802.1p-DSCP priority map. |
dot1p-exp |
802.1p-EXP priority map. |
dot1p-lp |
802.1p-local priority map. |
dscp-dot1p |
DSCP-802.1p priority map. |
dscp-dp |
DSCP-drop priority map. |
dscp-dscp |
DSCP-DSCP priority map. |
dscp-exp |
DSCP-EXP priority map. |
dscp-lp |
DSCP-local priority map. |
exp-dot1p |
EXP-802.1p priority map. |
exp-dp |
EXP-drop priority map. |
exp-dscp |
EXP-DSCP priority map. |
exp-exp |
EXP-EXP priority map. |
exp-lp |
EXP-local priority map. |
Configuring a colored priority map
Packets processed by traffic policing are colored green, yellow, or red. To perform priority mapping for packets in different colors, the device provides colored priority maps. For how traffic policing processes and colors packets, see "Configuring traffic policing and GTS."
To configure a colored priority map:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter colored priority map view. |
qos map-table color { green | yellow | red } { inbound { dot1p-dot1p | dot1p-dp | dot1p-dscp | dot1p-exp | dot1p-lp | dscp-dot1p| dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-dscp | exp-exp | exp-lp } | outbound { dot1p-dot1p | dot1p-dscp | dot1p-exp | dscp-dot1p| dscp-dscp | dscp-exp | exp-dot1p | exp-dscp | exp-exp } } |
N/A |
3. Configure mappings for the colored priority map. |
import import-value-list export export-value |
By default, the default colored priority maps are used. For more information, see "Appendixes." Newly configured mappings overwrite the old ones. |
Configuring an uncolored priority map
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter priority map view. |
qos map-table { inbound { dot1p-dot1p | dot1p-dp | dot1p-dscp | dot1p-exp | dot1p-lp | dscp-dot1p| dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-dscp | exp-lp } } |
N/A |
3. Configure mappings for the priority map. |
import import-value-list export export-value |
By default, the default priority maps are used. For more information, see "Appendixes." Newly configured mappings overwrite the old ones. |
Configuring a port to trust packet priority for priority mapping
You can configure the switch to trust a particular priority field carried in packets for priority mapping on ports or globally.
When you configure the trusted packet priority type on an interface, use the following available keywords:
· auto—Automatically selects the priority of each received packet according to packet type for mapping.
¡ For non-IP packets, 802.1p priority is used.
¡ For IP packets, DSCP precedence is used.
¡ For MPLS packets, EXP is used.
· dot1p—Uses the 802.1p priority of received packets for mapping.
· dscp—Uses the DSCP precedence of received IP packets for mapping.
· exp—Uses the EXP value of received MPLS packets for mapping.
To configure the trusted packet priority type on an interface:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Configure the trusted packet priority type. |
qos trust { auto | dot1p | dscp | exp } [ override ] |
By default, the port priority is trusted for priority mapping. If the override keyword is configured, the priority mapping process is as follows: 1. The original priority carried in the packet is first mapped to the trusted priority. 2. Then the mapped value is used for other priority mappings. Without this keyword, the original priority carried in the packet is directly used for priority mapping. This keyword is incompatible with the exp keyword. |
Changing the port priority of an interface
If an interface does not trust any packet priority, the device uses its port priority to look for priority parameters for the incoming packets. By changing port priority, you can prioritize traffic received on different interfaces.
To change the port priority of an interface:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Set the port priority of the interface. |
qos priority { dot1p | dp | dscp | exp | lp } priority-value |
The default setting is 2 for local precedence and 0 for drop precedence, and other priority types have no default values. |
Configuring primap
To reassign priority parameters for a traffic class according to the specified priority mapping table, configure a primap traffic behavior and associating it with the traffic class.
To configure primap:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
N/A |
3. Configure match criteria. |
if-match match-criteria |
N/A |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
N/A |
6. Configure a CAR action. |
car cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ red action ] car cir committed-information-rate [ cbs committed-burst-size pir peak-information-rate [ ebs excess-burst-size ] [ red action ] |
Use either of the commands. By default, no CAR action is configured. |
7. Configure the action of assigning priority values to packets using a specified colored priority mapping table. |
primap pre-defined color { dot1p-dot1p | dot1p-dp | dot1p-dscp | dot1p-exp | dot1p-lp | dscp-dot1p | dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-dscp | exp-exp | exp-lp } |
By default, no priority mapping action is configured. |
8. Return to system view. |
quit |
N/A |
9. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
N/A |
10. Associate the traffic behavior with the traffic class. |
classifier classifier-name behavior behavior-name |
N/A |
11. Return to system view. |
quit |
N/A |
12. Apply the QoS policy. |
· Applying the QoS policy to an interface |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
Displaying and maintaining priority mapping
Execute display commands in any view.
Task |
Command |
Display priority map configuration. |
display qos map-table [ inbound [ dot1p-dot1p | dot1p-dp | dot1p-dscp | dot1p-exp | dot1p-lp | dscp-dot1p| dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-dscp | exp-lp ] ] |
Display colored priority map configuration. |
display qos map-table color [ green | yellow | red ] { inbound [ dot1p-dot1p | dot1p-dp | dot1p-dscp | dot1p-exp | dot1p-lp | dscp-dot1p| dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-dscp | exp-exp | exp-lp ] | outbound [ dot1p-dot1p | dot1p-dscp | dot1p-exp | dscp-dot1p| dscp-dscp | dscp-exp | exp-dot1p | exp-dscp | exp-exp ] } |
Display the trusted packet priority type on an interface. |
display qos trust interface [ interface-type interface-number ] |
Priority mapping configuration examples
Priority trust mode configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 4:
· The DSCP value of traffic from Device A to Device C is 20.
· The DSCP value of traffic from Device B to Device C is 2.
Configure Device C to preferentially process packets from Device A to the server when GigabitEthernet 3/0/3 of Device C is congested.
Configuration procedure
(Method 1) Configure Device C to trust DSCP
# Configure GigabitEthernet 3/0/1 and GigabitEthernet 3/0/2 to select DSCP for priority mapping.
<DeviceC> system-view
[DeviceC] interface gigabitethernet 3/0/1
[DeviceC-GigabitEthernet3/0/1] qos trust dscp
[DeviceC-GigabitEthernet3/0/1] quit
[DeviceC] interface gigabitethernet 3/0/2
[DeviceC-GigabitEthernet3/0/2] qos trust dscp
[DeviceC-GigabitEthernet3/0/2] quit
(Method 2) Configure Device C to trust local precedence
# Assign local precedence to GigabitEthernet 3/0/1 and GigabitEthernet 3/0/2. Make sure the following requirements are met:
· The local precedence of GigabitEthernet 3/0/1 is higher than that of GigabitEthernet 3/0/2.
· No trusted packet priority type is configured on GigabitEthernet 3/0/1 and GigabitEthernet 3/0/2.
<DeviceC> system-view
[DeviceC] interface gigabitethernet 3/0/1
[DeviceC-GigabitEthernet3/0/1] qos priority lp 3
[DeviceC-GigabitEthernet3/0/1] quit
[DeviceC] interface gigabitethernet 3/0/2
[DeviceC-GigabitEthernet3/0/2] qos priority lp 1
[DeviceC-GigabitEthernet3/0/2] quit
Primap configuration example
Network requirements
As shown in Figure 5:
· The DSCP value of the traffic sent out of GigabitEthernet 3/0/1 on Device A is 11.
· The DSCP value of the traffic sent out of GigabitEthernet 3/0/2 on Device B is 13.
Configure priority mapping and traffic policing to meet the following requirements:
· Limit the rate to 300 kbps for traffic from Device A and permit the excess traffic.
· Limit the rate to 200 kbps for traffic from Device B and permit the excess traffic.
· When GigabitEthernet 3/0/3 of Device C is congested, Device C schedules packets in the following order:
a. The green packets from Device A.
b. The green packets from Device B.
c. The red packets from Device A and Device B.
Configuration procedure
# Configure the DSCP-to-local precedence mapping table.
<DeviceC> system-view
[DeviceC] qos map-table color green inbound dscp-lp
[DeviceC-maptbl-green-in-dscp-lp] import 11 export 4
[DeviceC-maptbl-green-in-dscp-lp] import 13 export 2
[DeviceC-maptbl-green-in-dscp-lp] quit
[DeviceC] qos map-table color red inbound dscp-lp
[DeviceC-maptbl-red-in-dscp-lp] import 11 export 0
[DeviceC-maptbl-red-in-dscp-lp] import 13 export 0
[DeviceC-maptbl-red-in-dscp-lp] quit
# Create traffic classes named t1 and t2, and use DSCP 11 and DSCP 13 as the match criteria, respectively.
[DeviceC] traffic classifier t1
[DeviceC-classifier-t1] if-match dscp 11
[DeviceC-classifier-t1] quit
[DeviceC] traffic classifier t2
[DeviceC-classifier-t2] if-match dscp 13
[DeviceC-classifier-t2] quit
# Configure traffic behaviors named t1 and t2.
[DeviceC] traffic behavior t1
[DeviceC-behavior-t1] car cir 300 red pass
[DeviceC-behavior-t1] primap pre-defined color dscp-lp
[DeviceC-behavior-t1] quit
[DeviceC] traffic behavior t2
[DeviceC-behavior-t2] car cir 200 red pass
[DeviceC-behavior-t2] primap pre-defined color dscp-lp
[DeviceC-behavior-t2] quit
# Create a QoS policy named p1, and associate traffic classes t1 with traffic behavior t1 in the QoS policy.
[DeviceC] qos policy p1
[DeviceC-qospolicy-p1] classifier t1 behavior t1
[DeviceC-qospolicy-p1] quit
# Create a QoS policy named p2, and associate traffic classes t2 with traffic behavior t2 in the QoS policy.
[DeviceC] qos policy p2
[DeviceC-qospolicy-p2] classifier t2 behavior t2
[DeviceC-qospolicy-p2] quit
# Apply the QoS policy p1 to the incoming traffic of GigabitEthernet 3/0/1.
[DeviceC] interface GigabitEthernet 3/0/1
[DeviceC-GigabitEthernet3/0/1] qos apply policy p1 inbound
[DeviceC-GigabitEthernet3/0/1] quit
# Apply the QoS policy p2 to the incoming traffic of GigabitEthernet 3/0/2.
[DeviceC] interface GigabitEthernet 3/0/2
[DeviceC-GigabitEthernet3/0/2] qos apply policy p2 inbound
[DeviceC-GigabitEthernet3/0/2] quit
Configuring traffic policing and GTS
Overview
Traffic policing helps assign network resources (including bandwidth) and increase network performance. For example, you can configure a flow to use only the resources committed to it in a certain time range. This avoids network congestion caused by burst traffic.
Traffic policing and Generic Traffic Shaping (GTS) control the traffic rate and resource usage according to traffic specifications. You can use token buckets for evaluating traffic specifications.
Traffic evaluation and token buckets
Token bucket features
A token bucket is analogous to a container that holds a certain number of tokens. Each token represents a certain forwarding capacity. The system puts tokens into the bucket at a constant rate. When the token bucket is full, the extra tokens cause the token bucket to overflow.
Evaluating traffic with the token bucket
A token bucket mechanism evaluates traffic by looking at the number of tokens in the bucket. If the number of tokens in the bucket is enough for forwarding the packets, the following events occur:
· The traffic conforms to the specification (called conforming traffic).
· The corresponding tokens are taken away from the bucket.
Otherwise, the traffic does not conform to the specification (called excess traffic).
A token bucket has the following configurable parameters:
· Mean rate at which tokens are put into the bucket, which is the permitted average rate of traffic. It is usually set to the committed information rate (CIR).
· Burst size or the capacity of the token bucket. It is the maximum traffic size permitted in each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater than the maximum packet size.
Each arriving packet is evaluated.
Complicated evaluation
You can set two token buckets, bucket C and bucket E, to evaluate traffic in a more complicated environment and achieve more policing flexibility. For example, traffic policing uses the following mechanisms:
· Single rate two color—Uses one token bucket and the following parameters:
¡ CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or forwarding rate allowed by bucket C.
¡ CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.
When a packet arrives, the following rules apply:
¡ If bucket C has enough tokens to forward the packet, the packet is colored green.
¡ Otherwise, the packet is colored red.
· Single rate three color—Uses two token buckets and the following parameters:
¡ CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or forwarding rate allowed by bucket C.
¡ CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.
¡ EBS—Size of bucket E minus size of bucket C, which specifies the transient burst of traffic that bucket E can forward. The EBS cannot be 0. The size of E bucket is the sum of the CBS and EBS.
When a packet arrives, the following rules apply:
¡ If bucket C has enough tokens, the packet is colored green.
¡ If bucket C does not have enough tokens but bucket E has enough tokens, the packet is colored yellow.
¡ If neither bucket C nor bucket E has sufficient tokens, the packet is colored red.
· Two rate three color—Uses two token buckets and the following parameters:
¡ CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or forwarding rate allowed by bucket C.
¡ CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.
¡ PIR—Rate at which tokens are put into bucket E, which specifies the average packet transmission or forwarding rate allowed by bucket E.
¡ EBS—Size of bucket E, which specifies the transient burst of traffic that bucket E can forward.
When a packet arrives, the following rules apply:
¡ If bucket C has enough tokens, the packet is colored green.
¡ If bucket C does not have enough tokens but bucket E has enough tokens, the packet is colored yellow.
¡ If neither bucket C nor bucket E has sufficient tokens, the packet is colored red.
Traffic policing
Traffic policing supports policing the inbound traffic and the outbound traffic.
A typical application of traffic policing is to supervise the specification of traffic entering a network and limit it within a reasonable range. Another application is to "discipline" the extra traffic to prevent aggressive use of network resources by an application. For example, you can limit bandwidth for HTTP packets to less than 50% of the total. If the traffic of a session exceeds the limit, traffic policing can drop the packets or reset the IP precedence of the packets. Figure 6 shows an example of policing outbound traffic on an interface.
Traffic policing is widely used in policing traffic entering the ISP networks. It can classify the policed traffic and take predefined policing actions on each packet depending on the evaluation result as follows:
· Forwarding the packet if the evaluation result is "conforming."
· Dropping the packet if the evaluation result is "excess."
· Forwarding the packet with its precedence re-marked if the evaluation result is "conforming."
· Delivering the packet to next-level traffic policing with its precedence re-marked if the evaluation result is "conforming."
· Entering the next-level policing (you can set multiple traffic policing levels each focused on objects at different levels).
GTS
GTS supports shaping the outbound traffic. GTS limits the outbound traffic rate by buffering exceeding traffic. You can use GTS to adapt the traffic output rate on a device to the input traffic rate of its connected device to avoid packet loss.
The differences between traffic policing and GTS are as follows:
· Packets to be dropped with traffic policing are retained in a buffer or queue with GTS, as shown in Figure 7. When enough tokens are in the token bucket, the buffered packets are sent at an even rate.
· GTS can result in additional delay and traffic policing does not.
For example, in Figure 8, Router B performs traffic policing on packets from Router A and drops packets exceeding the limit. To avoid packet loss, you can perform GTS on the outgoing interface of Router A so that packets exceeding the limit are cached in Router A. Once resources are released, GTS takes out the cached packets and sends them out.
Configuring traffic policing
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured. For more information about the if-match command, see ACL and QoS Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure a traffic policing action. |
car cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ red action ] car cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ red action ] |
Use either of the commands. By default, no traffic policing action is configured. Traffic policing uses the Color-Aware mode (see RFC 2697). |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the traffic class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, a traffic class is not associated with a traffic behavior. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy. |
· Applying the QoS policy to an interface · Applying the QoS policy to a VLAN · Applying the QoS policy globally · Applying the QoS policy to a control plane · Applying the QoS policy to the management interface control plane |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
12. (Optional.) Display traffic policing configuration. |
display traffic behavior user-defined [ behavior-name ] |
Available in any view. |
Configuring GTS
You can configure the following types of GTS:
· Queue-based GTS—Configures GTS parameters for packets of a queue.
· GTS for all traffic—Configures GTS parameters for all traffic on an interface.
Configuring queue-based GTS
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Configure GTS for a queue. |
qos gts queue queue-number cir committed-information-rate [ cbs committed-burst-size ] |
By default, GTS is not configured on an interface. |
Configuring GTS for all traffic
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Configure GTS on the interface. |
qos gts any cir committed-information-rate [ cbs committed-burst-size ] |
By default, GTS is not configured on an interface. |
Displaying and maintaining traffic policing and GTS
Execute display commands in any view.
Task |
Command |
Display QoS and ACL resource usage (in standalone mode). |
display qos-acl resource [ slot slot-number ] |
Display QoS and ACL resource usage (in IRF mode). |
display qos-acl resource [ chassis chassis-number slot slot-number ] |
Display traffic behavior configuration. |
display traffic behavior user-defined [ behavior-name ] |
Display GTS configuration and statistics on an interface. |
display qos gts interface [ interface-type interface-number ] |
Traffic policing configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 9:
· The server, Host A, and Host B can access the Internet through Device A and Device B.
· The server, Host A, and GigabitEthernet 3/0/1 of Device A are in the same network segment.
· Host B and GigabitEthernet 3/0/2 of Device A are in the same network segment.
Configure traffic policing on GigabitEthernet 3/0/1 of Device A to meet the following requirements:
· Limit the rate of packets from the server to 54 kbps. When the traffic rate is below 54 kbps, the traffic is forwarded. When the traffic rate exceeds 54 kbps, the excess packets are dropped.
· Limit the rate of packets from Host A to 8 kbps. When the traffic rate is below 8 kbps, the traffic is forwarded. When the traffic rate exceeds 8 kbps, the excess packets are dropped.
Limit the outgoing traffic rate on GigabitEthernet 3/0/2 of Device B to 1000 kbps.
Configuration procedure
1. Configure Device A:
# Configure ACLs to permit the packets from the server and Host A.
[DeviceA] acl number 2001
[DeviceA-acl-basic-2001] rule permit source 1.1.1.1 0
[DeviceA-acl-basic-2001] quit
[DeviceA] acl number 2002
[DeviceA-acl-basic-2002] rule permit source 1.1.1.2 0
[DeviceA-acl-basic-2002] quit
# Create traffic classes named t1 and t2, and use basic ACLs 2001 and 2002 as the match criteria, respectively.
[DeviceA] traffic classifier t1
[DeviceA-classifier-t1] if-match acl 2001
[DeviceA-classifier-t1] quit
[DeviceA] traffic classifier t2
[DeviceA-classifier-t2] if-match acl 2001
[DeviceA-classifier-t2] quit
# Create traffic behaviors named t1 and t2 for traffic control.
[DeviceA] traffic behavior t1
[DeviceA-behavior-t1] car cir 54 cbs 4000 ebs 0 red discard
[DeviceA-behavior-t1] quit
[DeviceA] traffic behavior t2
[DeviceA-behavior-t2] car cir 8 cbs 1875 ebs 0 red discard
[DeviceA-behavior-t2] quit
# Create a QoS policy named t, and associate traffic classes t1 and t2 with traffic behaviors t1 and t2 in the QoS policy, respectively.
[DeviceA] qos policy t
[DeviceA-qospolicy-t] classifier t1 behavior t1
[DeviceA-qospolicy-t] classifier t2 behavior t2
[DeviceA-qospolicy-t] quit
# Apply the QoS policy t to the incoming traffic of GigabitEthernet 3/0/1.
[DeviceA] interface gigabitethernet 3/0/1
[DeviceA-GigabitEthernet3/0/1] qos apply policy t inbound
[DeviceA-GigabitEthernet3/0/1] quit
2. Limit the outgoing traffic rate on GigabitEthernet 3/0/2 of Device B to 1000 kbps.
[DeviceB] interface gigabitethernet 3/0/2
[DeviceB-GigabitEthernet3/0/2] qos gts any cir 1000
Overview
Congestion occurs on a link or node when traffic size exceeds the processing capability of the link or node. It is typical of a statistical multiplexing network and can be caused by link failures, insufficient resources, and various other causes.
Figure 10 shows two typical congestion scenarios.
Figure 10 Traffic congestion scenarios
Congestion produces the following negative results:
· Increased delay and jitter during packet transmission.
· Decreased network throughput and resource use efficiency.
· Network resource (memory, in particular) exhaustion and even system breakdown.
Congestion is unavoidable in switched networks and multiuser application environments. To improve the service performance of your network, take measures to manage and control it.
The key to congestion management is defining a resource dispatching policy to prioritize packets for forwarding when congestion occurs.
Congestion management uses queuing and scheduling algorithms to classify and sort traffic leaving a port.
This section describes several common queue-scheduling mechanisms.
SP queuing
SP queuing is designed for mission-critical applications that require preferential service to reduce the response delay when congestion occurs.
In Figure 11, SP queuing classifies eight queues on a port into eight classes, numbered 7 to 0 in descending priority order.
SP queuing schedules the eight queues in descending order of priority. SP queuing sends packets in the queue with the highest priority first. When the queue with the highest priority is empty, it sends packets in the queue with the second highest priority, and so on. You can assign mission-critical packets to a high priority queue to make sure they are always served first. Common service packets can be assigned to low priority queues to be transmitted when high priority queues are empty.
The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if packets exist in the higher priority queues for a long time. In the worst case, lower priority traffic might never get serviced.
WRR queuing
WRR queuing schedules all the queues in turn to ensure that every queue is served for a certain time, as shown in Figure 12.
Assume a port provides eight output queues. WRR assigns each queue a weight value (represented by w7, w6, w5, w4, w3, w2, w1, or w0). The weight value of a queue decides the proportion of resources assigned to the queue. On a 100 Mbps port, you can set the weight values of WRR queuing to 50, 30, 10, 10, 50, 30, 10, and 10 for w7 through w0. In this way, the queues with a weight of 10 can each get a minimum of 5 Mbps bandwidth. WRR solves the problem that SP queuing might fail to serve packets in low-priority queues for a long time.
Another advantage of WRR queuing is that when the queues are scheduled in turn, the service time for each queue is not fixed. If a queue is empty, the next queue will be scheduled immediately. This improves bandwidth resource use efficiency.
WRR queuing includes the following types:
· Basic WRR queuing—Contains multiple queues. You can set the weight for each queue and WRR schedules these queues based on the user-defined parameters in a round robin manner.
· Group-based WRR queuing—All the queues are scheduled by WRR. You can assign an output queue to WRR priority queue group 1 or WRR priority queue group 2. Round robin queue scheduling is performed first for the group which has the highest-numbered queue, and then for the other group when that group is empty.
WFQ queuing
Figure 13 WFQ queuing
WFQ is similar to WRR. The difference is that WFQ enables you to set guaranteed bandwidth that a WFQ queue can get during congestion.
Configuration approaches and task list
The following are approaches to hardware congestion management configuration:
· Configure queue scheduling for each queue in interface view, as described in "Configuring per-queue hardware congestion management."
· Configure a queue scheduling profile, as described in "Configuring queue scheduling profiles."
· Configure low-latency queuing, which can improve the forwarding performance.
To achieve hardware congestion management, perform the following tasks:
Tasks at a glance |
|
(Required.) Configuring per-queue hardware congestion management |
|
(Required.) Configuring queue scheduling profiles |
|
(Required.) Configuring low-latency queuing |
|
Configuring per-queue hardware congestion management
In per-queue hardware congestion management, you manage traffic congestion on a per-queue basis on ports.
Configuring WFQ queuing
To configure a WFQ queue:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Enable WFQ queuing. |
qos wfq weight |
By default, an interface uses SP queuing. |
4. Set a scheduling weight for a WFQ queue. |
qos wfq queue-id weight schedule-value |
The default setting is 1. |
5. Set the minimum guaranteed bandwidth for a WFQ queue. |
qos bandwidth queue queue-id min bandwidth-value |
The default queuing is 40 kbps. |
Displaying and maintaining per-queue hardware congestion management
Execute display commands in any view.
Task |
Command |
Display WFQ queuing configuration. |
display qos queue wfq interface [ interface-type interface-number ] |
Configuring queue scheduling profiles
In a queue scheduling profile, you can configure scheduling parameters for each queue. By applying the queue scheduling profile to an interface, you can implement congestion management on the interface.
Queue scheduling profiles support two queue scheduling algorithms: SP and WRR. In a queue scheduling profile, you can configure SP, WRR, or both. When both of them are configured, SP queues and WRR groups are scheduled in descending order of queue ID. In a WRR group, queues are scheduled based on their weights. When SP and WRR are mixed in a queue scheduling profile, Figure 14 shows the scheduling order.
Figure 14 Queue scheduling profile configured with both SP and WRR
· Queue 7 has the highest priority. Its packets are sent preferentially.
· Queue 6 has the second highest priority. Packets in queue 6 are sent when queue 7 is empty.
· Queue 3, queue 4, and queue 5 are scheduled according to their weights. When both queue 6 and queue 7 are empty, WRR group 1 is scheduled.
· Queue 1 and queue 2 are scheduled according to their weights. WRR group 2 is scheduled when queue 7, queue 6, queue 5, queue 4, and queue 3 are all empty.
· Queue 0 has the lowest priority, and it is scheduled when all the other queues are empty.
Configuring a queue scheduling profile
When you configure a queue scheduling profile, follow these guidelines:
· Only one queue scheduling profile can be applied to an interface.
· You can modify the scheduling parameters in a queue scheduling profile already applied to an interface.
· To guarantee accurate scheduling, make sure the queues in a WRR group have consecutive IDs.
To configure a queue scheduling profile:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a queue scheduling profile and enter queue scheduling profile view. |
qos qmprofile profile-name |
By default, no queue scheduling profile exists. |
3. Configure queue scheduling parameters. |
· Configure a queue to use SP: · Configure a queue to use WRR: |
By default, a newly created queue scheduling profile uses SP queuing for all queues. One queue can use only one queue scheduling algorithm. In a queue scheduling profile, you can configure different queue scheduling algorithms for different queues. |
4. Return to system view. |
quit |
N/A |
5. Enter interface view. |
interface interface-type interface-number |
N/A |
6. Apply the queue scheduling profile to the interface. |
qos apply qmprofile profile-name |
By default, an interface uses SP queuing for its output queues. |
Displaying and maintaining queue scheduling profiles
Execute display commands in any view.
Task |
Command |
Display the configuration of queue scheduling profiles (in standalone mode). |
display qos qmprofile configuration [ profile-name ] [ slot slot-number ] |
Display the configuration of queue scheduling profiles (in IRF mode). |
display qos qmprofile configuration [ profile-name ] [ chassis chassis-number slot slot-number ] |
Display the queue scheduling profiles already applied to interfaces. |
display qos qmprofile interface [ interface-type interface-number ] |
Queue scheduling profile configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
Configure a queue scheduling profile to meet the following requirements on interface GigabitEthernet 3/0/1:
· Queue 7 has the highest priority, and its packets are sent preferentially.
· Queue 4, queue 5, and queue 6 in WRR group 1 are scheduled according to their weights, which are 1, 5, and 10, respectively. When queue 7 is empty, WRR group 1 is scheduled.
· Queue 1, queue 2, and queue 3 in WRR group 2 are scheduled according to their weights, which are 1, 10, and 20, respectively. When queue 4, queue 5, queue 6, and queue 7 are all empty, WRR group 2 is scheduled.
· Queue 0 has the lowest priority. Queue 0 is scheduled when all the other queues are empty.
Configuration procedure
# Enter system view.
<Sysname> system-view
# Create a queue scheduling profile qm1.
[Sysname] qos qmprofile qm1
[Sysname-qmprofile-qm1]
# Configure queue 7 to use SP queuing.
[Sysname-qmprofile-qm1] queue 7 sp
# Assign queue 4, queue 5, and queue 6 to WRR group 1, with the weight of 1, 5, and 10, respectively.
[Sysname-qmprofile-qm1] queue 4 wrr group 1 byte-count 1
[Sysname-qmprofile-qm1] queue 5 wrr group 1 byte-count 5
[Sysname-qmprofile-qm1] queue 6 wrr group 1 byte-count 10
# Assign queue 1, queue 2, and queue 3 to WRR group 2, with the weight of 1, 10, and 20, respectively.
[Sysname-qmprofile-qm1] queue 1 wrr group 2 byte-count 1
[Sysname-qmprofile-qm1] queue 2 wrr group 2 byte-count 10
[Sysname-qmprofile-qm1] queue 3 wrr group 2 byte-count 20
# Configure queue 0 to use SP queuing.
[Sysname-qmprofile-qm1] queue 0 sp
[Sysname-qmprofile-qm1] quit
# Apply the queue scheduling profile qm1 to interface GigabitEthernet 3/0/1.
[Sysname] interface gigabitethernet 3/0/1
[Sysname-GigabitEthernet 3/0/1] qos apply qmprofile qm1
Verifying the configuration
# Verify that interface GigabitEthernet 3/0/1 performs queue scheduling as specified in the queue scheduling profile qm1. (Details not shown.)
Configuring low-latency queuing
In a scenario requiring a low forwarding delay, you can enable low-latency queuing, so that the switch can reduce the forwarding delay.
This feature is supported only by the default MDC. For more information about MDC, see Virtual Technologies Configuration Guide.
To configure low-latency queuing:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable low-latency queuing. |
queue low-latency enable |
By default, low-latency queuing is disabled. |
You can filter in or filter out traffic of a class by associating the class with a traffic filtering action. For example, you can filter packets sourced from an IP address according to network status.
Configuration restrictions
Actions supported in the inbound direction and configuration restrictions
· filter permit conflicts with filter deny and redirect cpu.
· filter deny can only work with accounting.
· redirect cpu conflicts with all other actions.
· redirect interface conflicts with filter deny and mirror-to cpu. For more information about traffic mirroring, see Network Management and Monitoring Configuration Guide.
· car conflicts with filter deny and redirect cpu.
· accounting conflicts with redirect cpu.
· remark dscp/exp/dot1p/lp/dp conflicts with filter deny, redirect cpu, and primap pre-defined color.
· primap pre-defined color conflicts with filter deny, redirect cpu, and remark dscp/exp/dot1p/lp/dp.
Actions supported in the outbound direction and configuration restrictions
· filter permit conflicts with filter deny.
· filter deny conflicts with all other actions.
· car conflicts with filter deny.
· accounting conflicts with filter deny.
· remark dscp/dot1p/exp conflicts with filter deny and marking dscp/dot1p/exp with the primap pre-defined color action.
· Marking dscp/dot1p/exp with the primap pre-defined color action conflicts with filter deny and remark dscp/dot1p/exp.
Configuration procedure
To configure traffic filtering:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure the traffic filtering action. |
filter { deny | permit } |
By default, no traffic filtering action is configured. If the filter deny command is configured for a traffic behavior, all other actions except class-based accounting in the traffic behavior do not take effect. |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the traffic class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, a traffic class is not associated with a traffic behavior. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy. |
· Applying the QoS policy to an interface · Applying the QoS policy to a VLAN |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
12. (Optional.) Display the traffic filtering configuration. |
display traffic behavior user-defined [ behavior-name ] |
Available in any view. |
Configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 15, configure traffic filtering on GigabitEthernet 3/0/1 to filter the incoming packets with a source port number other than 21.
Configuration procedure
# Create advanced ACL 3000, and configure a rule to match packets whose source port number is not 21.
<Device> system-view
[Device] acl number 3000
[Device-acl-adv-3000] rule 0 permit tcp source-port neq 21
[Device-acl-adv-3000] quit
# Create a traffic class named classifier_1, and use ACL 3000 as the match criterion in the traffic class.
[Device] traffic classifier classifier_1
[Device-classifier-classifier_1] if-match acl 3000
[Device-classifier-classifier_1] quit
# Create a traffic behavior named behavior_1, and configure the traffic filtering action to drop packets.
[Device] traffic behavior behavior_1
[Device-behavior-behavior_1] filter deny
[Device-behavior-behavior_1] quit
# Create a QoS policy named policy, and associate traffic class classifier_1 with traffic behavior behavior_1 in the QoS policy.
[Device] qos policy policy
[Device-qospolicy-policy] classifier classifier_1 behavior behavior_1
[Device-qospolicy-policy] quit
# Apply the QoS policy policy to the incoming traffic of GigabitEthernet 3/0/1.
[Device] interface gigabitethernet 3/0/1
[Device-GigabitEthernet3/0/1] qos apply policy policy inbound
Configuration procedure
To configure protocol packet rate limiting:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter class traffic view. |
traffic classifier classifier-name [ operator { and | or } ] |
N/A |
3. Configure match criteria. |
if-match control-plane protocol protocol-name&<1-8> |
By default, no match criteria are configured. For more information, see the if-match command in ACL and QoS Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure protocol packet rate limiting. |
packet-rate value |
By default, protocol packet rate limiting is not configured. |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, a class is not associated with any behavior. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy to the control plane. |
By default, a QoS policy is not applied to the control plane. |
|
12. (Optional.) Display the protocol packet rate limiting configuration. |
display traffic behavior user-defined [ behavior-name ] |
Available in any view. |
Configuration example
Network requirements
As shown in Figure 16, configure protocol packet rate limiting to limit the rate to 500 pps for ARP packets sent to the CPU of the device.
Configuration procedures
# Create a class named classifier_1, and configure the class to match ARP packets.
<Device> system-view
[Device] traffic classifier classifier_1
[Device-classifier-classifier_1] if-match control-plane protocol arp
[Device-classifier-classifier_1] quit
# Create a behavior named behavior_1, and configure the behavior to limit the packet rate to 500 pps.
[Device] traffic behavior behavior_1
[Device-behavior-behavior_1] packet-rate 500
[Device-behavior-behavior_1] quit
# Create a policy named policy, and associate the class classifier_1 with the behavior behavior_1 in the policy.
[Device] qos policy policy
[Device-qospolicy-policy] classifier classifier_1 behavior behavior_1
[Device-qospolicy-policy] quit
# Apply the QoS policy to the control plane of the card in slot 3.
[Device] control-plane slot 3
[Device-cp-slot3] qos apply policy policy inbound
[Device-cp-slot3] quit
Priority marking sets the priority fields or flag bits of packets to modify the priority of packets. For example, you can use priority marking to set IP precedence or DSCP for a traffic class of IP packets to control the forwarding of these packets.
To configure priority marking to set the priority fields or flag bits for a class of packets, perform the following tasks:
1. Configure a traffic behavior with a priority marking action.
2. Associate the traffic class with the traffic behavior.
Configuration procedure
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured. For more information about the if-match command, see ACL and QoS Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure a priority marking action. |
· Set the 802.1p priority for packets: · Set the drop priority for packets: · Set the DSCP value for packets: · Set the local
precedence for packets: · Set the SVLAN for packets: |
Use one of the commands. By default, no priority marking action is configured. The remark drop-precedence command applies only to the incoming traffic. |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the traffic class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, a traffic class is not associated with a traffic behavior. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy. |
· Applying the QoS policy to an interface |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
12. (Optional.) Display the priority marking configuration. |
display traffic behavior user-defined [ behavior-name ] |
Available in any view. |
Configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 17, configure priority marking on the device to meet the following requirements:
Traffic source |
Destination |
Processing priority |
Host A, B |
Data server |
High |
Host A, B |
Mail server |
Medium |
Host A, B |
File server |
Low |
Configuration procedure
# Create advanced ACL 3000, and configure a rule to match packets with destination IP address 192.168.0.1.
<Device> system-view
[Device] acl number 3000
[Device-acl-adv-3000] rule permit ip destination 192.168.0.1 0
[Device-acl-adv-3000] quit
# Create advanced ACL 3001, and configure a rule to match packets with destination IP address 192.168.0.2.
[Device] acl number 3001
[Device-acl-adv-3001] rule permit ip destination 192.168.0.2 0
[Device-acl-adv-3001] quit
# Create advanced ACL 3002, and configure a rule to match packets with destination IP address 192.168.0.3.
[Device] acl number 3002
[Device-acl-adv-3002] rule permit ip destination 192.168.0.3 0
[Device-acl-adv-3002] quit
# Create a traffic class named classifier_dbserver, and use ACL 3000 as the match criterion in the traffic class.
[Device] traffic classifier classifier_dbserver
[Device-classifier-classifier_dbserver] if-match acl 3000
[Device-classifier-classifier_dbserver] quit
# Create a traffic class named classifier_mserver, and use ACL 3001 as the match criterion in the traffic class.
[Device] traffic classifier classifier_mserver
[Device-classifier-classifier_mserver] if-match acl 3001
[Device-classifier-classifier_mserver] quit
# Create a traffic class named classifier_fserver, and use ACL 3002 as the match criterion in the traffic class.
[Device] traffic classifier classifier_fserver
[Device-classifier-classifier_fserver] if-match acl 3002
[Device-classifier-classifier_fserver] quit
# Create a traffic behavior named behavior_dbserver, and configure the action of setting the local precedence value to 4.
[Device] traffic behavior behavior_dbserver
[Device-behavior-behavior_dbserver] remark local-precedence 4
[Device-behavior-behavior_dbserver] quit
# Create a traffic behavior named behavior_mserver, and configure the action of setting the local precedence value to 3.
[Device] traffic behavior behavior_mserver
[Device-behavior-behavior_mserver] remark local-precedence 3
[Device-behavior-behavior_mserver] quit
# Create a traffic behavior named behavior_fserver, and configure the action of setting the local precedence value to 2.
[Device] traffic behavior behavior_fserver
[Device-behavior-behavior_fserver] remark local-precedence 2
[Device-behavior-behavior_fserver] quit
# Create a QoS policy named policy_server, and associate traffic classes with traffic behaviors in the QoS policy.
[Device] qos policy policy_server
[Device-qospolicy-policy_server] classifier classifier_dbserver behavior behavior_dbserver
[Device-qospolicy-policy_server] classifier classifier_mserver behavior behavior_mserver
[Device-qospolicy-policy_server] classifier classifier_fserver behavior behavior_fserver
[Device-qospolicy-policy_server] quit
# Apply the QoS policy named policy_server to the incoming traffic of GigabitEthernet 3/0/1.
[Device] interface gigabitethernet 3/0/1
[Device-GigabitEthernet3/0/1] qos apply policy policy_server inbound
[Device-GigabitEthernet3/0/1] quit
Nesting adds a VLAN tag to the matching packets to allow the VLAN-tagged packets to pass through the corresponding VLAN. For example, you can add an outer VLAN tag to packets from a customer network to a service provider network. This allows the packets to pass through the service provider network by carrying a VLAN tag assigned by the service provider.
Configuration procedure
To configure nesting:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured for a traffic class. For more information about the match criteria, see the if-match command in ACL and QoS Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure a VLAN tag adding action. |
nest top-most vlan vlan-id |
By default, no VLAN tag adding action is configured for a traffic behavior. |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the traffic class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, no class-behavior association is configured for a QoS policy. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy. |
· Applying the QoS policy to an interface |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
Configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 18:
· Site 1 and Site 2 in VPN A are two branches of a company, and they use VLAN 5 to transmit traffic.
· Because Site 1 and Site 2 are located in different areas, the two sites use the VPN access service of a service provider. The service provider assigns VLAN 100 to the two sites.
Configure nesting, so that the two branches can communicate through the service provider network.
Configuration procedure
Configuring PE 1
# Create a class named test to match packets with VLAN ID 5.
<PE1> system-view
[PE1] traffic classifier test
[PE1-classifier-test] if-match service-vlan-id 5
[PE1-classifier-test] quit
# Configure an action to add outer VLAN tag 100 in the traffic behavior named test.
[PE1] traffic behavior test
[PE1-behavior-test] nest top-most vlan 100
[PE1-behavior-test] quit
# Create a QoS policy named test, and associate class test with behavior test in the QoS policy.
[PE1] qos policy test
[PE1-qospolicy-test] classifier test behavior test
[PE1-qospolicy-test] quit
# Configure the downlink port GigabitEthernet 3/0/1 as a hybrid port, and assign the port to VLAN 100 as an untagged member.
[PE1] interface gigabitethernet 3/0/1
[PE1-GigabitEthernet3/0/1] port link-type hybrid
[PE1-GigabitEthernet3/0/1] port hybrid vlan 100 untagged
# Apply the QoS policy test to the incoming traffic of the downlink port GigabitEthernet 3/0/1.
[PE1-GigabitEthernet3/0/1] qos apply policy test inbound
[PE1-GigabitEthernet3/0/1] quit
# Configure the uplink port GigabitEthernet 3/0/2 as a trunk port, and assign it to VLAN 100.
[PE1] interface gigabitethernet 3/0/2
[PE1-GigabitEthernet3/0/2] port link-type trunk
[PE1-GigabitEthernet3/0/2] port trunk permit vlan 100
[PE1-GigabitEthernet3/0/2] quit
Configuring PE 2
Configure PE 2 in the same way PE 1 is configured.
Traffic redirecting redirects packets matching the specified match criteria to a location for processing.
The following redirect actions are supported:
· Redirecting traffic to the CPU—Redirects packets that require processing by the CPU to the CPU.
· Redirecting traffic to an interface—Redirects packets that require processing by an interface to the interface.
¡ In IRF mode, the switch does not support redirecting traffic to an aggregate interface.
¡ In IRF mode, the switch supports multichassis redirecting only for OAP cards. Multichassis redirecting refers to redirecting traffic to an outgoing interface on a different IRF member device than the incoming interface.
Configuration procedure
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured for a traffic class. For more information about the match criteria, see the if-match command in ACL and QoS Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure a traffic redirecting action. |
redirect { cpu | interface interface-type interface-number [ track-oap ] [ vlan vlan-id ] } |
By default, no traffic redirecting action is configured for a traffic behavior. The actions of redirecting traffic to the CPU and redirecting traffic to an interface are mutually exclusive with each other in the same traffic behavior. If both actions are configured, the most recent configuration takes effect. |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the traffic class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, no class-behavior association is configured for a QoS policy. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy. |
· Applying the QoS policy to an interface |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
12. (Optional.) Display traffic redirecting configuration. |
display traffic behavior user-defined [ behavior-name ] |
Available in any view. |
Configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 19, the traffic sourced from 2.2.2.0/24 and 3.3.3.0/24 enters Device A from interface GigabitEthernet 3/0/1.
Redirect the traffic from these two network segments to outgoing interfaces GigabitEthernet 3/0/2 and GigabitEthernet 3/0/3, respectively.
Configuration procedure
# Create basic ACL 2000, and configure a rule to match packets from 2.2.2.0/24.
<DeviceA> system-view
[DeviceA] acl number 2000
[DeviceA-acl-basic-2000] rule permit source 2.2.2.0 0.0.0.255
[DeviceA-acl-basic-2000] quit
# Create basic ACL 2001, and configure a rule to match packets from 3.3.3.0/24.
[DeviceA] acl number 2001
[DeviceA-acl-basic-2001] rule permit source 3.3.3.0 0.0.0.255
[DeviceA-acl-basic-2001] quit
# Create a traffic class named classifier_1, and use ACL 2000 as the match criterion in the traffic class.
[DeviceA] traffic classifier classifier_1
[DeviceA-classifier-classifier_1] if-match acl 2000
[DeviceA-classifier-classifier_1] quit
# Create a traffic class named classifier_2, and use ACL 2001 as the match criterion in the traffic class.
[DeviceA] traffic classifier classifier_2
[DeviceA-classifier-classifier_2] if-match acl 2001
[DeviceA-classifier-classifier_2] quit
# Create a traffic behavior named behavior_1, and configure the action of redirecting traffic to GigabitEthernet 3/0/2.
[DeviceA] traffic behavior behavior_1
[DeviceA-behavior-behavior_1] redirect interface GigabitEthernet 3/0/2
[DeviceA-behavior-behavior_1] quit
# Create a traffic behavior named behavior_2, and configure the action of redirecting traffic to GigabitEthernet 3/0/3.
[DeviceA] traffic behavior behavior_2
[DeviceA-behavior-behavior_2] redirect interface GigabitEthernet 3/0/3
[DeviceA-behavior-behavior_2] quit
# Create a QoS policy named policy, and associate traffic classes classifier_1 and classifier_2 with traffic behaviors behavior_1 and behavior_2 in the QoS policy, respectively.
[DeviceA] qos policy policy
[DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1
[DeviceA-qospolicy-policy] classifier classifier_2 behavior behavior_2
[DeviceA-qospolicy-policy] quit
# Apply the QoS policy policy to the incoming traffic of GigabitEthernet 3/0/1.
[DeviceA] interface GigabitEthernet 3/0/1
[DeviceA-GigabitEthernet 3/0/1] qos apply policy policy inbound
Global committed access rate (CAR) is an approach to policing traffic flows globally. It adds flexibility to common CAR where traffic policing is performed only on a per-traffic class or per-interface basis. In this approach, CAR actions are created in system view and each can be used to police multiple traffic flows as a whole.
Global CAR includes aggregate CAR and hierarchical CAR. The switch supports only aggregate CAR.
An aggregate CAR action is created globally. It can be directly applied to interfaces or used in the traffic behaviors associated with different traffic classes to police multiple traffic flows as a whole. The total rate of the traffic flows must conform to the traffic policing specifications set in the aggregate CAR action.
Configuring aggregate CAR
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
2. Configure an aggregate CAR action. |
qos car car-name aggregative cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ red action ] qos car car-name aggregative cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ red action ] |
Use either of the commands. By default, no aggregate CAR action is configured. |
3. Enter traffic behavior view. |
traffic behavior behavior-name |
N/A |
4. Use the aggregate CAR in the traffic behavior. |
car name car-name |
By default, an aggregate CAR action is not used in a traffic behavior. |
Displaying and maintaining global CAR
Execute display commands in any view and reset commands in user view.
Task |
Command |
Display statistics for global CAR actions. |
display qos car name [ car-name ] |
Clear statistics for global CAR actions. |
reset qos car name [ car-name ] |
Configuration example
# Create an aggregate CAR action named aggcar-1, and configure the following parameters for it: CIR 200, CBS 2000, and dropping red packets. Use aggregate CAR aggcar-1 in behavior be1.
<Sysname> system-view
[Sysname] qos car aggcar-1 aggregative cir 200 cbs 2000 red discard
[Sysname] traffic behavior be1
[Sysname-behavior-be1] car name aggcar-1
Configuration procedure
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a traffic class and enter traffic class view. |
traffic classifier classifier-name [ operator { and | or } ] |
By default, no traffic class exists. |
3. Configure match criteria. |
if-match match-criteria |
By default, no match criterion is configured. For more information about the if-match command, see ACL and QoS Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Create a traffic behavior and enter traffic behavior view. |
traffic behavior behavior-name |
By default, no traffic behavior exists. |
6. Configure the accounting action. |
accounting { byte | packet } |
By default, no traffic accounting action is configured. |
7. Return to system view. |
quit |
N/A |
8. Create a QoS policy and enter QoS policy view. |
qos policy policy-name |
By default, no QoS policy exists. |
9. Associate the traffic class with the traffic behavior in the QoS policy. |
classifier classifier-name behavior behavior-name |
By default, a traffic class is not associated with a traffic behavior. |
10. Return to system view. |
quit |
N/A |
11. Apply the QoS policy. |
· Applying the QoS policy to an interface |
Choose one of the application destinations as needed. By default, a QoS policy is not applied. |
12. (Optional.) Display traffic accounting configuration. |
· In standalone mode: ¡ display qos policy global [ slot slot-number ] [ inbound | outbound ] ¡ display qos policy interface [ interface-type interface-number ] [ inbound | outbound ] ¡ display qos vlan-policy { name policy-name | vlan [ vlan-id ] } [ slot slot-number ] [ inbound | outbound ] · In IRF mode: ¡ display qos policy global [ chassis chassis-number slot slot-number ] [ inbound | outbound ] ¡ display qos policy interface [ interface-type interface-number ] [ inbound | outbound ] ¡ display qos vlan-policy { name policy-name | vlan [ vlan-id ] } [ chassis chassis-number slot slot-number ] [ inbound | outbound ] |
Available in any view. |
Configuration example
By default, Ethernet, VLAN, and aggregate interfaces are down. You must use the undo shutdown command to bring them up. This example assumes that all these interfaces are already up.
Network requirements
As shown in Figure 20, configure class-based accounting to collect statistics for the traffic that GigabitEthernet 3/0/1 receive from 1.1.1.1/24.
Configuration procedure
# Create basic ACL 2000, and configure a rule to match packets with source IP address 1.1.1.1.
<Device> system-view
[Device] acl number 2000
[Device-acl-basic-2000] rule permit source 1.1.1.1 0
[Device-acl-basic-2000] quit
# Create a traffic class named classifier_1, and use ACL 2000 as the match criterion in the traffic class.
[Device] traffic classifier classifier_1
[Device-classifier-classifier_1] if-match acl 2000
[Device-classifier-classifier_1] quit
# Create a traffic behavior named behavior_1, and configure the class-based accounting action.
[Device] traffic behavior behavior_1
[Device-behavior-behavior_1] accounting packet
[Device-behavior-behavior_1] quit
# Create a QoS policy named policy, and associate traffic class classifier_1 with traffic behavior behavior_1 in the QoS policy.
[Device] qos policy policy
[Device-qospolicy-policy] classifier classifier_1 behavior behavior_1
[Device-qospolicy-policy] quit
# Apply the QoS policy named policy to the incoming traffic of GigabitEthernet 3/0/1.
[Device] interface gigabitethernet 3/0/1
[Device-GigabitEthernet3/0/1] qos apply policy policy inbound
[Device-GigabitEthernet3/0/1] quit
# Verify the configuration by displaying traffic statistics.
[Device] display qos policy interface gigabitethernet 3/0/1
Interface: GigabitEthernet3/0/1
Direction: Inbound
Policy: policy
Classifier: classifier_1
Operator: AND
Rule(s) :
If-match acl 2000
Behavior: behavior_1
Accounting enable:
28529 (Packets)
Traffic accounting collects statistics according to system-defined statistics collecting rules. The switch provides two counters to collect outbound and inbound traffic statistics.
You can enable both counters. They collect statistics independently.
Configuration procedure
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable traffic accounting and specify the type of traffic (in standalone mode). |
qos traffic-counter { inbound | outbound } { counter0 | counter1 } slot slot-number [ drop-priority drop-priority | interface interface-type interface-number | vlan vlan-id ] * |
By default, traffic accounting is disabled. |
3. Enable traffic accounting and specify the type of traffic (in IRF mode). |
qos traffic-counter { inbound | outbound } { counter0 | counter1 } chassis chassis-number slot slot-number [ drop-priority drop-priority | interface interface-type interface-number | vlan vlan-id ] * |
By default, traffic accounting is disabled. |
Displaying and maintaining traffic accounting
Execute display commands in any view and reset commands in user view.
Task |
Command |
Display traffic statistics collected by the traffic accounting function (in standalone mode). |
display qos traffic-counter { inbound | outbound } { counter0 | counter1 } slot slot-number |
Display traffic statistics collected by the traffic accounting function (in IRF mode). |
display qos traffic-counter { inbound | outbound } { counter0 | counter1 } chassis chassis-number slot slot-number |
Clear the traffic statistics collected by a counter of the traffic accounting function (in standalone mode). |
reset qos traffic-counter { inbound | outbound } { counter0 | counter1 } slot slot-number |
Clear the traffic statistics collected by a counter of the traffic accounting function (in IRF mode). |
reset qos traffic-counter { inbound | outbound } { counter0 | counter1 } chassis chassis-number slot slot-number |
Overview
Queue-based accounting collects traffic statistics for an interface on a per-queue basis, such as:
· The number of packets forwarded.
· The number of bytes forwarded.
· The number of packets dropped.
· The number of bytes dropped.
This feature can collect traffic statistics only for known unicast packets received from FD and FG cards. This feature cannot collect statistics for unknown unicast packets, broadcast packets, multicast packets, or protocol packets. FD and FG cards refer to the cards with silkscreens ending with FD and FG, respectively, for example, LST1XP40RFD1 and LST1XP40RFG1.
Configuration procedure
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable queue-based accounting in the outbound direction of all interfaces. |
qos queue-statistics outbound |
By default, outbound queue-based accounting is enabled. This command is supported only by the default MDC. After you configure this command on the default MDC, the configuration also takes effect on non-default MDCs. For more information about MDCs, see Virtual Technologies Configuration Guide. |
Displaying and maintaining queue-based accounting
Execute display commands in any view.
Task |
Command |
Display outbound queue-based statistics. |
display qos queue-statistics interface [ interface-type interface-number ] outbound |
Appendixes
Appendix A Acronym
Table 1 Appendix A Acronym
Acronym |
Full spelling |
AF |
Assured Forwarding |
BE |
Best Effort |
BQ |
Bandwidth Queuing |
CAR |
Committed Access Rate |
CBS |
Committed Burst Size |
CBQ |
Class Based Queuing |
CBWFQ |
Class Based Weighted Fair Queuing |
CE |
Customer Edge |
CIR |
Committed Information Rate |
CQ |
Custom Queuing |
DAR |
Deeper Application Recognition |
DCBX |
Data Center Bridging Exchange Protocol |
DiffServ |
Differentiated Service |
DoS |
Denial of Service |
DSCP |
Differentiated Services Code Point |
EBS |
Excess Burst Size |
ECN |
Explicit Congestion Notification |
EF |
Expedited Forwarding |
FEC |
Forwarding Equivalence Class |
FIFO |
First in First out |
FQ |
Fair Queuing |
GTS |
Generic Traffic Shaping |
IntServ |
Integrated Service |
ISP |
Internet Service Provider |
LFI |
Link Fragmentation and Interleaving |
LLQ |
Low Latency Queuing |
LSP |
Label Switched Path |
MPLS |
Multiprotocol Label Switching |
P2P |
Peer-to-Peer |
PE |
Provider Edge |
PHB |
Per-hop Behavior |
PIR |
Peak Information Rate |
PQ |
Priority Queuing |
QoS |
Quality of Service |
QPPB |
QoS Policy Propagation Through the Border Gateway Protocol |
RED |
Random Early Detection |
RSVP |
Resource Reservation Protocol |
RTP |
Real-Time Transport Protocol |
SLA |
Service Level Agreement |
SP |
Strict Priority |
TE |
Traffic Engineering |
ToS |
Type of Service |
TS |
Traffic Shaping |
VoIP |
Voice over IP |
VPN |
Virtual Private Network |
WFQ |
Weighted Fair Queuing |
WRED |
Weighted Random Early Detection |
WRR |
Weighted Round Robin |
Appendix B Default priority maps
Colored priority maps
Packets processed by CAR are colored green, yellow, or red. To perform priority mapping for packets in different colors, the switch provides multiple colored priority mapping tables, as described in subsections.
Unless otherwise specified, the mappings described in this section apply to both directions and are the same for the three colors.
dot1p-dot1p mapping
By default, the output value equals the input value.
dot1p-dp mapping
Table 2 Default dot1p-dp mapping table
Input value |
dot1p-dp mapping (inbound) |
||
green |
yellow |
red |
|
0 to 7 |
0 |
1 |
2 |
dot1p-dscp
By default, the output value equals the input value multiplied by 8.
dot1p-exp
By default, the output value equals the input value.
dot1p-lp
Table 3 Default dot1p-lp mapping table
Input value |
dot1p-lp mapping (inbound) |
||
green |
yellow |
red |
|
0 |
2 |
2 |
2 |
1 |
0 |
0 |
0 |
2 |
1 |
1 |
1 |
3 |
3 |
3 |
3 |
4 |
4 |
4 |
4 |
5 |
5 |
5 |
5 |
6 |
6 |
6 |
6 |
7 |
7 |
7 |
7 |
dscp-dot1p
Table 4 Default dscp-dot1p mapping table
Input value |
dscp-dot1p mapping |
||
green |
yellow |
red |
|
0 to 7 |
0 |
0 |
0 |
8 to 15 |
1 |
1 |
1 |
16 to 23 |
2 |
2 |
2 |
24 to 31 |
3 |
3 |
3 |
32 to 39 |
4 |
4 |
4 |
40 to 47 |
5 |
5 |
5 |
48 to 55 |
6 |
6 |
6 |
56 to 63 |
7 |
7 |
7 |
dscp-dp
Table 5 Default dscp-dp mapping table
Input value |
dscp-dp mapping (inbound) |
||
green |
yellow |
red |
|
0 to 63 |
0 |
1 |
2 |
dscp-dscp
By default, the output value equals the input value.
dscp-exp
Table 6 Default dscp-exp mapping table
Input value |
dscp-exp mapping |
||
green |
yellow |
red |
|
0 to 7 |
0 |
0 |
0 |
8 to 15 |
1 |
1 |
1 |
16 to 23 |
2 |
2 |
2 |
24 to 31 |
3 |
3 |
3 |
32 to 39 |
4 |
4 |
4 |
40 to 47 |
5 |
5 |
5 |
48 to 55 |
6 |
6 |
6 |
56 to 63 |
7 |
7 |
7 |
dscp-lp
Table 7 Default dscp-lp mapping table
Input value |
dscp-lp mapping (inbound) |
||
green |
yellow |
red |
|
0–7 |
0 |
0 |
0 |
8–15 |
1 |
1 |
1 |
16–23 |
2 |
2 |
2 |
24–31 |
3 |
3 |
3 |
32–39 |
4 |
4 |
4 |
40–47 |
5 |
5 |
5 |
48–55 |
6 |
6 |
6 |
56–63 |
7 |
7 |
7 |
exp-dot1p
By default, the output value equals the input value.
exp-dp
Table 8 Default exp-dp mapping table
Input value |
exp-dp mapping (inbound) |
||
green |
yellow |
red |
|
0 to 7 |
0 |
1 |
2 |
exp-dscp
By default, the output value equals the input value multiplied by 8.
exp-exp
By default, the output value equals the input value.
exp-lp (inbound)
By default, the output value equals the input value.
Uncolored priority maps
The switch provides various types of uncolored priority mapping table for the inbound direction. For the default dot1p-dot1p, dot1p-exp, dscp-dscp, exp-lp, and exp-dot1p priority maps, an input value yields a target value equal to it. Other default priority maps are as follows:
Table 9 Default dot1p-lp, dot1p-dp, and dot1p-dscp priority maps
Input priority value |
dot1p-lp map |
dot1p-dp map |
dot1p-dscp map |
dot1p |
lp |
dp |
dscp |
0 |
2 |
0 |
0 |
1 |
0 |
0 |
8 |
2 |
1 |
0 |
16 |
3 |
3 |
0 |
24 |
4 |
4 |
0 |
32 |
5 |
5 |
0 |
40 |
6 |
6 |
0 |
48 |
7 |
7 |
0 |
56 |
Table 10 Default dscp-lp, dscp-dp, dscp-dot1p, and dscp-exp priority maps
Input priority value |
dscp-lp map |
dscp-dp map |
dscp-dot1p map |
dscp-exp map |
dscp |
lp |
dp |
dot1p |
exp |
0 to 7 |
0 |
0 |
0 |
0 |
8 to 15 |
1 |
0 |
1 |
1 |
16 to 23 |
2 |
0 |
2 |
2 |
24 to 31 |
3 |
0 |
3 |
3 |
32 to 39 |
4 |
0 |
4 |
4 |
40 to 47 |
5 |
0 |
5 |
5 |
48 to 55 |
6 |
0 |
6 |
6 |
56 to 63 |
7 |
0 |
7 |
7 |
Table 11 Default exp-dscp and exp-dp priority maps
Input priority value |
exp-dscp map |
exp-dp map |
exp |
dscp |
dp |
0 |
0 |
0 |
1 |
8 |
0 |
2 |
16 |
0 |
3 |
24 |
0 |
4 |
32 |
0 |
5 |
40 |
0 |
6 |
48 |
0 |
7 |
56 |
0 |
Appendix C Introduction to packet precedences
IP precedence and DSCP values
As shown in Figure 21, the ToS field in the IP header contains eight bits. The first three bits (0 to 2) represent IP precedence from 0 to 7. According to RFC 2474, the ToS field is redefined as the differentiated services (DS) field, where a DSCP value is represented by the first six bits (0 to 5) and is in the range 0 to 63. The remaining two bits (6 and 7) are reserved.
Table 12 IP precedence
IP precedence (decimal) |
IP precedence (binary) |
Description |
0 |
000 |
Routine |
1 |
001 |
priority |
2 |
010 |
immediate |
3 |
011 |
flash |
4 |
100 |
flash-override |
5 |
101 |
critical |
6 |
110 |
internet |
7 |
111 |
network |
Table 13 DSCP values
DSCP value (decimal) |
DSCP value (binary) |
Description |
46 |
101110 |
ef |
10 |
001010 |
af11 |
12 |
001100 |
af12 |
14 |
001110 |
af13 |
18 |
010010 |
af21 |
20 |
010100 |
af22 |
22 |
010110 |
af23 |
26 |
011010 |
af31 |
28 |
011100 |
af32 |
30 |
011110 |
af33 |
34 |
100010 |
af41 |
36 |
100100 |
af42 |
38 |
100110 |
af43 |
8 |
001000 |
cs1 |
16 |
010000 |
cs2 |
24 |
011000 |
cs3 |
32 |
100000 |
cs4 |
40 |
101000 |
cs5 |
48 |
110000 |
cs6 |
56 |
111000 |
cs7 |
0 |
000000 |
be (default) |
802.1p priority
802.1p priority lies in the Layer 2 header. It applies to occasions where Layer 3 header analysis is not needed and QoS must be assured at Layer 2.
Figure 22 An Ethernet frame with an 802.1Q tag header
As shown in Figure 22, the 4-byte 802.1Q tag header consists of the 2-byte tag protocol identifier (TPID), whose value is 0x8100, and the 2-byte tag control information (TCI). Figure 23 shows the format of the 802.1Q tag header. The Priority field in the 802.1Q tag header is called the "802.1p priority", because its use is defined in IEEE 802.1p. Table 14 shows the values for 802.1p priority.
Table 14 Description on 802.1p priority
802.1p priority (decimal) |
802.1p priority (binary) |
Description |
0 |
000 |
best-effort |
1 |
001 |
background |
2 |
010 |
spare |
3 |
011 |
excellent-effort |
4 |
100 |
controlled-load |
5 |
101 |
video |
6 |
110 |
voice |
7 |
111 |
network-management |
EXP values
The EXP field is in MPLS labels for MPLS QoS purposes.
Figure 24 MPLS label structure
As shown in Figure 24, the EXP field is 3-bit long and is in the range of 0 to 7.