
Chapters Download(361.27 KB)
Table of Contents
Applying QoS Techniques in a Network
Applying the QoS Policy to an Interface
Displaying and Maintaining QoS Policies
3 Priority Mapping Configuration
Introduction to Priority Mapping
Priority Mapping Configuration Tasks
Configuring a Priority Mapping Table
Configuring the Priority Trust Mode on a Port
Configuring the Port Priority of a Port
Displaying and Maintaining Priority Mapping
Priority Mapping Configuration Examples
Priority Mapping Table Configuration Example
Line rate configuration example
5 Congestion Management Configuration
Congestion Management Overview
Causes, Impacts, and Countermeasures of Congestion
Congestion Management Policies
Congestion Management Configuration Methods
6 Traffic Filtering Configuration
Traffic Filtering Configuration Example
Traffic Filtering Configuration Example
7 Traffic Redirecting Configuration
Configuring Traffic Redirecting
Appendix B Default Priority Mapping Tables
Appendix C Introduction to Packet Precedences
This chapter covers the following topics:
In data communications, Quality of Service (QoS) is the ability of a network to provide differentiated service guarantees for diverse traffic in terms of bandwidth, delay, jitter, and drop rate.
Network resources are always scarce. The contention for resources demands that QoS prioritize important traffic flows over trivial traffic flows. When making a QoS scheme, a network administrator must consider the characteristics of various applications to balance the interests of diversified users and fully utilize network resources.
The subsequent section describes some typical QoS service models and widely-used mature QoS techniques. By appropriately using these techniques, you can improve QoS effectively.
This section covers three typical QoS service models:
Best effort is a single service model and also the simplest service model. In the best effort service model, the network does its best to deliver packets but does not guarantee delay or reliability.
The best-effort service model is the default model in the Internet and applies to most network applications. It uses the first in first out (FIFO) queuing mechanism.
The integrated service (IntServ) model is a multiple-service model that can accommodate multiple QoS requirements. It provides the most granularly differentiated QoS by definitely identifying and guaranteeing QoS for each data flow.
In the IntServ model, an application must request a specific kind of service from the network before it sends data. IntServ signals the service request with the Resource Reservation Protocol (RSVP). All nodes that receive 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 that all nodes along the transmission path maintain resource state information for each flow. The model is suitable for small-sized or edge networks, but not large-sized networks, for example, the core layer of the Internet, where billions of flows are present.
The differentiated service (DiffServ) model is a multiple-service model that can satisfy diverse QoS requirements. Unlike IntServ, DiffServ does not require an application to signal the network to reserve resources before sending data. DiffServ is easy to implement and extend.
All QoS techniques in this document are based on the Diff-Serv model.
The QoS techniques fall into traffic classification, traffic policing, traffic shaping, line rate, congestion management, and congestion avoidance. The following part briefly introduces these QoS techniques.
Figure 1-1 Position of the QoS techniques in a network

As shown in Figure 1-1, traffic classification, traffic shaping, traffic policing, congestion management, and congestion avoidance mainly implement the following functions:
l Traffic classification uses certain match criteria to assign packets with the same characteristics to a class. Based on classes, you can provide differentiated services.
l Traffic policing polices flows entering or leaving a device, and imposes penalties on traffic flows that exceed the pre-set threshold to prevent aggressive use of network resources. You can apply traffic policing to both incoming and outgoing traffic of a port.
l Traffic shaping proactively 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.
l 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.
l Congestion avoidance monitors the network resource usage and is usually applied to the outgoing traffic of a port. As congestion worsens, congestion avoidance actively reduces the queue length by dropping packets.
When configuring a QoS policy, go to these sections for information you are interested in:
l Displaying and Maintaining QoS Policies
A QoS policy involves three components: class, traffic behavior, and policy. You can associate a class with a traffic behavior using a QoS policy.
Classes are used to identify traffic.
A class is identified by a class name and contains some match criteria.
A class is a set of match criteria for identifying traffic. It uses the AND or OR operator:
If the operator is AND, a packet must match all the criteria to match the class.
If the operator is OR, a packet matches the class if it matches any of the criteria in the class.
A traffic behavior defines a set of QoS actions to take on packets, such as filtering and redirect.
By associating a traffic behavior with a class in a QoS policy, you apply the specific set of QoS actions to the class of traffic.
Follow these steps to configure a QoS policy:
1) Create a class and define a set of match criteria in class view.
2) Create a traffic behavior and define a set of QoS actions in traffic behavior view.
3) Create a policy and associate the traffic behavior with the class in policy view.
4) Apply the policy to an interface.
To define a class, you need to specify a name for it and then configure match criteria in class view.
Follow these steps to define a class:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a class and enter class view |
traffic classifier tcl-name [ operator { and | or } ] |
Required By default, the relation between match criteria is AND. The operator of a class can be AND or OR. l AND: A packet is considered belonging to a class only when the packet matches all the criteria in the class. l OR: A packet is considered belonging to a class if it matches any of the criteria in the class. |
|
Define a match criterion |
if-match match-criteria |
Required |
match-criteria: Matching rules to be defined for a class. Table 2-1 describes the available forms of this argument.
Table 2-1 The form of the match-criteria argument
|
Form |
Description |
|
acl { access-list-number | name acl-name } |
Specifies to match an IPv4 ACL specified by its number or name. The access-list-number argument specifies an ACL by its number, which ranges from 2000 to 4999; the name acl-name keyword-argument combination specifies an ACL by its name. In a class configured with the operator and, the logical relationship between rules defined in the referenced IPv4 ACL is or. |
|
any |
Specifies to match all packets. |
|
customer-dot1p 8021p-list |
Specifies to match packets by 802.1p precedence of the customer network. The 8021p-list argument is a list of CoS values, in the range of 0 to 7. |
|
customer-vlan-id vlan-id-list |
Specifies to match the packets of specified VLANs of user networks. The vlan-id-list argument specifies a list of VLAN IDs, in the form of vlan-id to vlan-id or multiple discontinuous VLAN IDs (separated by space). You can specify up to eight VLAN IDs for this argument at a time. VLAN ID is in the range 1 to 4094. |
|
destination-mac mac-address |
Specifies to match the packets with a specified destination MAC address. |
|
dscp dscp-list |
Specifies to match packets by DSCP precedence. The dscp-list argument is a list of DSCP values in the range of 0 to 63. |
|
ip-precedence ip-precedence-list |
Specifies to match packets by IP precedence. The ip-precedence-list argument is a list of IP precedence values in the range of 0 to 7. |
|
protocol protocol-name |
Specifies to match the packets of a specified protocol. The protocol-name argument can be IP. |
|
service-vlan-id vlan-id-list |
Specifies to match the packets of the VLANs of the operator’s network. The vlan-id-list argument is a list of VLAN IDs, in the form of vlan-id to vlan-id or multiple discontinuous VLAN IDs (separated by space). You can specify up to eight VLAN IDs for this argument at a time. VLAN ID is in the range of 1 to 4094. |
|
source-mac mac-address |
Specifies to match the packets with a specified source MAC address. |
![]()
The matching criteria listed below must be unique in a traffic class with the operator being AND. Therefore, even though you can define multiple if-match clauses for these matching criteria or input multiple values for a list argument (such as the 8021p-list argument) listed below in a traffic class, avoid doing that. Otherwise, the QoS policy referencing the class cannot be applied to interfaces successfully.
l customer-dot1p 8021p-list
l customer-vlan-id vlan-id-list
l destination-mac mac-address
l dscp dscp-list
l ip-precedence ip-precedence-list
l service-vlan-id vlan-id-list
l source-mac mac-address
To create multiple if-match clauses or specify multiple values for a list argument for any of the matching criteria listed above, ensure that the operator of the class is OR.
A traffic behavior is a set of QoS actions. To define a traffic behavior, you must first create it and then configure actions for the behavior as required in traffic behavior view.
Follow these steps to define a traffic behavior:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a traffic behavior and enter traffic behavior view |
traffic behavior behavior-name |
Required |
|
Configure actions in the traffic behavior |
See the following chapters based on the purpose of the traffic behavior: traffic policing, traffic filtering, traffic redirecting, priority marking, traffic accounting, and so on. |
|
A policy defines the mapping between a class and a traffic behavior.
In a policy, multiple class-to-traffic-behavior mappings can be configured, and these mappings are executed according to the order configured.
Follow these steps to define a policy:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a policy and enter policy view |
qos policy policy-name |
Required |
|
Specify the traffic behavior for a class in the policy |
classifier tcl-name behavior behavior-name |
Required |
![]()
If an ACL is referenced by a QoS policy for defining traffic match criteria, , packets matching the ACL are organized as a class and the behavior defined in the QoS policy applies to the class regardless of whether the match mode of the ACL clause is deny or permit.
You can apply the QoS policy to an interface.
![]()
You can modify the classification rules, traffic behaviors, and classifier-behavior associations of a QoS policy already applied.
A policy can be applied to multiple interfaces. Only one policy can be applied in inbound direction of an interface.
Follow these steps to apply the QoS policy to an interface:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view, |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Apply the policy to the interface/port group |
qos apply policy policy-name inbound |
Required |
|
# Apply QoS policy test_policy to the inbound direction of GigabitEthernet 1/0/1.
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] qos apply policy test_policy inbound
|
To do… |
Use the command… |
Remarks |
|
Display traffic class information |
display traffic classifier user-defined [ tcl-name ] |
Available in any view |
|
Display traffic behavior configuration information |
display traffic behavior user-defined [ behavior-name ] |
Available in any view |
|
Display the configuration of user-defined QoS policies |
display qos policy user-defined [ policy-name [ classifier tcl-name ] ] |
Available in any view |
|
Display QoS policy configuration on the specified or all interfaces |
display qos policy interface [ interface-type interface-number ] [ inbound ] |
Available in any view |
When configuring priority mapping, go to these sections for information you are interested in:
l Priority Mapping Configuration Tasks
l Configuring Priority Mapping
l Displaying and Maintaining Priority Mapping
l Priority Mapping Configuration Examples
The priorities of a packet determine its transmission priority. There are two types of priority: priorities carried in packets and priorities locally assigned for scheduling only.
The packet-carried priorities include 802.1p priority, DSCP precedence, IP precedence, EXP, and so on. These priorities have global significance and affect the forwarding priority of packets across the network.
The locally assigned priorities have only local significance. They are assigned by the device for scheduling only. These priorities include the local precedence and drop precedence, as follows.
l Local precedence is 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.
l Drop precedence is used for making packet drop decisions. Packets with the highest drop precedence are dropped preferentially.
When a packet enters the device from a port, the device assigns a set of QoS priority parameters to the packet based on a certain priority and sometimes may modify its priority, according to certain rules depending on device status. This process is called priority mapping. The priority based on which priority mapping is performed depends on the priority trust mode configured on the port (see section Priority Trust Mode on a Port. The set of QoS priority parameters decides the scheduling priority and forwarding priority of the packet.
Priority mapping is implemented with priority mapping tables. The device provides various types of priority mapping tables, or rather, priority mappings. By looking up a priority mapping table, the device decides which priority value is to assign to a packet for subsequent packet processing.
l dot1p-dot1p: 802.1p-to-802.1p priority mapping table.
l dot1p-dscp: 802.1p-to-DSCP priority mapping table.
l dot1p-lp: 802.1p-to-local priority mapping table.
l dscp-dot1p: DSCP-to-802.1p priority mapping table, which is applicable to only IP packets.
l dscp-dscp: DSCP-to-DSCP priority mapping table, which is applicable to only IP packets.
l dscp-lp: DSCP-to-local priority mapping table, which is applicable to only IP packets.
The default priority mapping tables (as shown in Appendix B Default Priority Mapping Tables) are available for priority mapping. Generally, they are sufficient for priority mapping. If a default priority mapping table cannot meet your requirements, you can modify the priority mapping table as required.
The priority trust mode on a port decides which priority is used for priority mapping table lookup. For the priority mapping purpose, port priority was introduced so that you can use it for priority mapping in addition to priority fields carried in packets. There are three priority trust modes on H3C S5120-SI series switches:
l dot1p: Uses the 802.1p priority carried in packets for priority mapping.
l dscp: Uses the DSCP carried in packets for priority mapping.
l undo qos trust: Uses the port priority as the 802.1p priority for priority mapping. The port priority is user configurable.
The priority mapping procedure varies with the priority modes, as described in the next section Priority Mapping Procedure.
Upon receiving an Ethernet packet on a port, the switch marks the scheduling priorities (local precedence and drop precedence) for the Ethernet packet according to the priority trust mode of the receiving port and the 802.1q tagging status of the packet, as shown in Figure 3-1.
Figure 3-1 Priority mapping procedure for an Ethernet packet

You can modify priority mappings by modifying priority mapping tables, priority trust mode on a port, and port priority.
You are recommended to plan QoS throughout the network before making QoS configuration.
Complete the following task to configure priority mapping:
|
Task |
Remarks |
|
Optional |
|
|
Optional |
|
|
Optional |
Follow these steps to configure an uncolored priority mapping table:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter priority mapping table view |
qos map-table { dot1p-dot1p | dot1p-dscp | dot1p-lp | dscp-dot1p | dscp-dscp | dscp-lp } |
Required |
|
Configure the priority mapping table |
import import-value-list export export-value |
Required Newly configured mappings overwrite the old ones. |
Follow these steps to configure the trusted packet priority type on an interface/port group:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure the priority trust mode |
Trust the 802.1p or DSCP priority in packets |
qos trust { dot1p | dscp } |
Use either command By default, the device trusts the port priority. |
|
Trust the port priority |
undo qos trust |
||
You can change the port priority of a port used for priority mapping. For the priority mapping procedure, see Figure 3-1.
Follow these steps to configure the port priority of a port for priority mapping:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure the port priority |
qos priority priority-value |
Required The default port priority is 0. |
|
|
To do… |
Use the command… |
Remarks |
|
Display priority mapping table configuration information |
display qos map-table [ dot1p-dot1p | dot1p-dscp | dot1p-lp | dscp-dot1p | dscp-dscp | dscp-lp ] |
Available in any view |
|
Display the trusted precedence type on the port |
display qos trust interface [ interface-type interface-number ] |
Available in any view |
As shown in Figure 3-2, the enterprise network of a company interconnects all departments through Device. The network is described as follows:
l The marketing department connects to GigabitEthernet 1/0/1 of Device, which sets the 802.1p priority of traffic from the marketing department to 3.
l The R&D department connects to GigabitEthernet 1/0/2 of Device, which sets the 802.1p priority of traffic from the R&D department to 4.
l The management department connects to GigabitEthernet 1/0/3 of Device, which sets the 802.1p priority of traffic from the management department to 5.
Configure port priority, 802.1p-to-local priority mapping table, and priority marking to implement the plan as described in Table 3-1.
|
Traffic destination |
Traffic Priority order |
Queuing plan |
||
|
Traffic source |
Output queue |
Queue priority |
||
|
Public servers |
R&D department > management department > marketing department |
R&D department |
6 |
High |
|
Management department |
4 |
Medium |
||
|
Marketing department |
2 |
Low |
||
Figure 3-2 Network diagram for priority mapping table and priority marking configuration

1) Configure trusting port priority
# Set the port priority of GigabitEthernet 1/0/1 to 3.
<Device> system-view
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] qos priority 3
[Device-GigabitEthernet1/0/1] quit
# Set the port priority of GigabitEthernet 1/0/2 to 4.
[Device] interface gigabitethernet 1/0/2
[Device-GigabitEthernet1/0/2] qos priority 4
[Device-GigabitEthernet1/0/2] quit
# Set the port priority of GigabitEthernet 1/0/3 to 5.
[Device] interface gigabitethernet 1/0/3
[Device-GigabitEthernet1/3] qos priority 5
[Device-GigabitEthernet1/3] quit
2) Configure the priority mapping table
# Configure the 802.1p-to-local priority mapping table to map 802.1p priority values 3, 4, and 5 to local precedence values 2, 6, and 4.
[Device] qos map-table dot1p-lp
[Device-maptbl-dot1p-lp] import 3 export 2
[Device-maptbl-dot1p-lp] import 4 export 6
[Device-maptbl-dot1p-lp] import 5 export 4
[Device-maptbl-dot1p-lp] quit
The line rate of a physical interface specifies the maximum rate for forwarding packets (including critical packets).
Line rate uses token buckets for traffic control. With line rate configured on an interface, all packets to be sent through the interface are firstly handled by the token bucket at line rate. If there are enough tokens in the token bucket, packets can be forwarded; otherwise, packets are put into QoS queues for congestion management. In this way, the traffic passing the physical interface is controlled.
Figure 4-1 Line rate implementation

In the token bucket approach to traffic control, bursty traffic can be transmitted so long as enough tokens are available in the token bucket; if tokens are inadequate, packets cannot be transmitted until the required number of tokens are generated in the token bucket. Thus, traffic rate is restricted to the rate for generating tokens, thus limiting traffic rate and allowing bursty traffic.
The line rate of a physical interface specifies the maximum rate of incoming packets or outgoing packets.
Follow these steps to configure the line rate:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure the line rate for the interface/port group |
qos lr { inbound | outbound } cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] |
Required |
|
|
Display line rate information on the interface |
display qos lr interface [ interface-type interface-number ] |
Available in any view |
|
Limit the outbound line rate of GigabitEthernet 1/0/1 to 1280 kbps.
# Enter system view.
<Sysname> system-view
# Enter interface view.
[Sysname] interface gigabitethernet 1/0/1
# Limit the outbound line rate of GigabitEthernet 1/0/1 to 500 kbps.
[Sysname-GigabitEthernet1/0/1] qos lr outbound cir 500
When configuring congestion management, go to these sections for information you are interested in:
l Congestion Management Overview
l Congestion Management Configuration Methods
Network congestion is a major factor contributed to service quality degrading on a traditional network. Congestion is a situation where the forwarding rate decreases due to insufficient resources, resulting in extra delay.
Congestion easily occurs in complex packet switching circumstances in the Internet. The following figure shows two common cases:
Figure 5-1 Traffic congestion causes

Congestion may bring these negative results:
l Increased delay and jitter during packet transmission
l Decreased network throughput and resource use efficiency
l Network resource (memory in particular) exhaustion and even system breakdown
Congestion is unavoidable in switched networks and multi-user application environments. To improve the service performance of your network, you must take some proper measures to address the congestion issues.
The key to congestion management is how to define a dispatching policy for resources to decide the order of forwarding packets when congestion occurs.
In general, congestion management adopts queuing technology. The system uses a certain queuing algorithm for traffic classification, and then uses a certain precedence algorithm to send the traffic. Each queuing algorithm deals with a particular network traffic problem and has significant impacts on bandwidth resource assignment, delay, and jitter.
Queue scheduling processes packets by their priorities, preferentially forwarding high-priority packets. In the following section, Strict Priority (SP) queuing, Weighted Fair Queuing (WFQ), and SP+WRR queuing are introduced.
SP queuing is specially designed for mission-critical applications, which require preferential service to reduce the response delay when congestion occurs.
Figure 5-2 Schematic diagram for SP queuing

As shown in Figure 5-2, 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 strictly according to the descending order of priority. It 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. Thus, you can assign mission-critical packets to the high priority queue to ensure that they are always served first and common service packets to the low priority queues and transmitted when the high priority queues are empty.
The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if there are packets in the higher priority queues. This may cause lower priority traffic to starve to death.
WRR queuing schedules all the queues in turn to ensure that every queue can be served for a certain time, as shown in Figure 5-3.
Figure 5-3 Schematic diagram for WRR queuing

Assume there are four output queues on a port. WRR assigns each queue a weight value (represented by w3, w2, w1, or w0) to decide the proportion of resources assigned to the queue. On a 100 Mbps port, you can configure the weight values of WRR queuing to 50, 25, 25, and 25 (corresponding to w3, w2, w1, and w0 respectively). In this way, the queue with the lowest priority is assured of 20 Mbps of bandwidth at least, thus avoiding the disadvantage of SP queuing that packets in low-priority queues may fail to be served for a long time.
Another advantage of WRR queuing is that while the queues are scheduled in turn, the service time for each queue is not fixed, that is, if a queue is empty, the next queue will be scheduled immediately. This improves bandwidth resource use efficiency.
S5120-SI series support group-based WRR queuing, that is, all the queues are scheduled by WRR. You can divide the output queue to WRR priority queue group 1 and WRR priority queue group 2. Round robin queue scheduling is performed for group 1 first. If group 1 is empty, round robin queue scheduling is performed for group 2.
You can implement SP+WRR queue scheduling on a port by assigning some queues on the port to the SP scheduling group and the others to the WRR scheduling group (that is, group 1 and group 2). Packets in the SP scheduling group are scheduled preferentially. When the SP scheduling group is empty, packets in the WRR scheduling group are scheduled. Queues in the SP scheduling group are scheduled by SP. Queues in the WRR scheduling group are scheduled by WRR.
Complete the following tasks to achieve congestion management:
|
Task |
Remarks |
|
Optional |
|
|
Optional |
|
|
Optional |
Follow these steps to configure SP queuing:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure SP queuing |
undo qos wrr |
Optional The default queuing algorithm on an interface is SP queuing. |
|
1) Network requirements
Configure GigabitEthernet 1/0/1 to adopt SP queuing.
2) Configuration procedure
# Enter system view
<Sysname> system-view
# Configure GigabitEthernet1/0/1 to adopt SP queuing.
[Sysname]interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] undo qos wrr
Follow these steps to configure basic WRR queuing:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure a WRR queue |
qos wrr queue-id group group-id weight schedule-value |
Required The default queuing algorithm on an interface is SP queuing. |
|
|
Display WRR queuing configuration information on interface(s) |
display qos wrr interface [ interface-type interface-number ] |
Optional Available in any view |
|
1) Network requirements
l Enable WRR queuing on the interface.
l Assign queue 0 and queue 1 to the WRR group 1, with the weight of 10 and 20 respectively.
l Assign queue 2 and queue 3 to the WRR group 2, with the weight of 30 and 50 respectively.
2) Configuration procedure
# Enter system view.
<Sysname> system-view
# Configure WRR queuing on GigabitEthernet 1/0/1.
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] qos wrr 0 group 1 weight 10
[Sysname-GigabitEthernet1/0/1] qos wrr 1 group 1 weight 20
[Sysname-GigabitEthernet1/0/1] qos wrr 2 group 2 weight 30
[Sysname-GigabitEthernet1/0/1] qos wrr 3 group 2 weight 50
Follow these steps to configure an SP+WRR queue:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure SP queuing |
qos wrr queue-id group sp |
Required |
|
|
ConfigureWRR queuing |
qos wrr queue-id group group-id weight schedule-value |
Required |
|
1) Network requirements
l Configure to adopt SP+WRR queue scheduling algorithm on GigabitEthernet1/0/1.
l Configure queue 0 on GigabitEthernet1/0/1 to be in SP queue scheduling group.
l Configure queue 1 on GigabitEthernet1/0/1 to be in WRR queue scheduling group 1, with the weight being 20.
l Configure queue 2 and queue 3 on GigabitEthernet1/0/1 to be in WRR queue scheduling group 2, with the weight being 10 and 50 respectively.
2) Configuration procedure
# Enter system view.
<Sysname> system-view
# Enable the SP+WRR queue scheduling algorithm on GigabitEthernet1/0/1.
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] qos wrr 0 group sp
[Sysname-GigabitEthernet1/0/1] qos wrr 1 group 1 weight 20
[Sysname-GigabitEthernet1/0/1] qos wrr 2 group 2 weight 10
[Sysname-GigabitEthernet1/0/1] qos wrr 3 group 2 weight 50
When configuring traffic filtering, go to these sections for information you are interested in:
l Configuring Traffic Filtering
l Traffic Filtering Configuration Example
You can filter in or filter out a class of traffic by associating the class with a traffic filtering action. For example, you can filter packets sourced from a specific IP address according to network status. By using ACL rules configured with a time range for traffic classification, you can implement time-based traffic filtering.
![]()
Alternatively, you can implement traffic filtering on a port by directly applying an ACL on the port. For the configuration procedure, refer to ACL Configuration.
Follow these steps to configure traffic filtering:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a class and enter class view |
traffic classifier tcl-name [ operator { and | or } ] |
— |
|
Configure the match criteria |
if-match match-criteria |
— |
|
Exit class view |
quit |
— |
|
Create a behavior and enter behavior view |
traffic behavior behavior-name |
— |
|
Configure the traffic filtering action |
filter { deny | permit } |
Required l deny: Drops packets. l permit: Permits packets to pass through. |
|
Exit behavior view |
quit |
— |
|
Create a policy and enter policy view |
qos policy policy-name |
— |
|
Associate the class with the traffic behavior in the QoS policy |
classifier tcl-name behavior behavior-name |
— |
|
Exit policy view |
quit |
— |
|
Apply the QoS policy to an interface |
— |
|
|
Display the traffic filtering configuration |
display traffic behavior user-defined [ behavior-name ] |
Optional Available in any view |
![]()
The action of dropping the packets and the action of redirecting traffic to an interface are mutually exclusive with each other in the same traffic behavior.
As shown in Figure 6-1, Host is connected to GigabitEthernet 1/0/1 of Device.
Figure 6-1 Network diagram for traffic filtering configuration

# Create advanced ACL 3000, and configure a rule to match packets whose source port number is 21.
<DeviceA> system-view
[DeviceA] acl number 3000
[DeviceA-acl-basic-3000] rule 0 permit tcp source-port eq 21
[DeviceA-acl-basic-3000] quit
# Create a class named classifier_1, and reference ACL 3000 in the class.
[DeviceA] traffic classifier classifier_1
[DeviceA-classifier-classifier_1] if-match acl 3000
[DeviceA-classifier-classifier_1] quit
# Create a behavior named behavior_1, and configure the traffic filtering action for the behavior to drop packets.
[DeviceA] traffic behavior behavior_1
[DeviceA-behavior-behavior_1] filter deny
[DeviceA-behavior-behavior_1] quit
# Create a policy named policy, and associate class classifier_1 with behavior behavior_1 in the policy.
[DeviceA] qos policy policy
[DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1
[DeviceA-qospolicy-policy] quit
# Apply the policy named policy to the incoming traffic of GigabitEthernet 1/0/1.
[DeviceA] interface gigabitethernet 1/0/1
[DeviceA-GigabitEthernet1/0/1] qos apply policy policy inbound
When configuring traffic redirecting, go to these sections for information you are interested in:
l Traffic Redirecting Overview
l Configuring Traffic Redirecting
Traffic redirecting is the action of redirecting the packets matching the specific match criteria to a certain location for processing.
Currently, the S5120-SI series can redirect packets which require processing by an interface to the interface. Note that this action is applicable to only Layer 2 packets, and the target interface should be a Layer 2 interface.
Follow these steps to configure traffic redirecting:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a class and enter class view |
traffic classifier tcl-name [ operator { and | or } ] |
— |
|
Configure the match criteria |
if-match match-criteria |
— |
|
Exit class view |
quit |
— |
|
Create a behavior and enter behavior view |
traffic behavior behavior-name |
Required |
|
Configure a traffic redirecting action |
redirect interface interface-type interface-number |
Optional |
|
Exit behavior view |
quit |
— |
|
Create a policy and enter policy view |
qos policy policy-name |
— |
|
Associate the class with the traffic behavior in the QoS policy |
classifier tcl-name behavior behavior-name |
— |
|
Exit policy view |
quit |
— |
|
Apply the QoS policy to an interface |
— |
This chapter includes these sections:
l Appendix B Default Priority Mapping Tables
l Appendix C Introduction to Packet Precedences
Table 8-1 Appendix A Acronym
|
Acronym |
Full spelling |
|
AF |
Assured Forwarding |
|
BE |
Best Effort |
|
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 |
|
DiffServ |
Differentiated Service |
|
DSCP |
Differentiated Services Codepoint |
|
EACL |
Enhanced ACL |
|
EBS |
Excess Burst Size |
|
EF |
Expedited Forwarding |
|
FEC |
Forwarding Equivalence Class |
|
FIFO |
First in First out |
|
GTS |
Generic Traffic Shaping |
|
IntServ |
Integrated Service |
|
ISP |
Internet Service Provider |
|
LFI |
Link Fragmentation & Interleaving |
|
LLQ |
Low Latency Queuing |
|
LR |
Line Rate |
|
LSP |
Label Switched Path |
|
MPLS |
Multiprotocol Label Switching |
|
PE |
Provider Edge |
|
PHB |
Per-hop Behavior |
|
PIR |
Peak Information Rate |
|
PQ |
Priority Queuing |
|
QoS |
Quality of Service |
|
RED |
Random Early Detection |
|
RSVP |
Resource Reservation Protocol |
|
RTP |
Real Time Protocol |
|
SLA |
Service Level Agreement |
|
TE |
Traffic Engineering |
|
ToS |
Type of Service |
|
TP |
Traffic Policing |
|
TS |
Traffic Shaping |
|
VoIP |
Voice over IP |
|
VPN |
Virtual Private Network |
|
WFQ |
Weighted Fair Queuing |
|
WRED |
Weighted Random Early Detection |
Table 8-2 The default dot1p-lp, dot1p-dp, dot1p-dscp, and dot1p-rpr priority mapping tables
|
Input priority value |
dot1p-lp mapping |
dot1p-dscp mapping |
|
802.1p priority (dot1p) |
Local precedence (lp) |
DSCP |
|
0 |
2 |
0 |
|
1 |
0 |
8 |
|
2 |
1 |
16 |
|
3 |
3 |
24 |
|
4 |
4 |
32 |
|
5 |
5 |
40 |
|
6 |
6 |
48 |
|
7 |
7 |
56 |
Table 8-3 The default dscp-lp, dscp-dp, dscp-dot1p, and dscp-exp priority mapping tables
|
Input priority value |
dscp-lp mapping |
dscp-dot1p mapping |
|
DSCP |
Local precedence (lp) |
802.1p priority (dot1p) |
|
0 to 7 |
0 |
0 |
|
8 to 15 |
1 |
1 |
|
16 to 23 |
2 |
2 |
|
24 to 31 |
3 |
3 |
|
32 to 39 |
4 |
4 |
|
40 to 47 |
5 |
5 |
|
48 to 55 |
6 |
6 |
|
56 to 63 |
7 |
7 |

As shown in Figure 8-1, 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 8-4 Description on 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 8-5 Description on 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 lies in the Layer 2 header and applies to occasions where Layer 3 header analysis is not needed and QoS must be assured at Layer 2.
Figure 8-2 An Ethernet frame with an 802.1Q tag header

As shown in Figure 8-2, the 4-byte 802.1Q tag header consists of the tag protocol identifier (TPID, two bytes in length), whose value is 0x8100, and the tag control information (TCI, two bytes in length). Figure 8-3 presents 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 8-6 presents the values for 802.1p priority.

Table 8-6 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 |