Guia de Configuração Huawei-QoS

S2750&S5700&S6720 Series Ethernet Switches
V200R008C00
Configuration Guide - QoS
Issue 03
Date 2016-10-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://e.huawei.com
Issue 03 (2016-10-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Configuration Guide - QoS About This Document
About This Document
Intended Audience
This document describes the concepts and configuration procedures of QoS features on the
S2750&S5700&S6720, and provides the configuration examples.
This document is intended for:
l Data configuration engineers

l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation

which, if not avoided, will result in death or
serious injury.
Indicates a potentially hazardous situation

which, if not avoided, could result in death
or serious injury.

which, if not avoided, may result in minor
or moderate injury.

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Issue 03 (2016-10-30) Huawei Proprietary and Confidential ii

Symbol Description
NOTE Calls attention to important information,

best practices and tips.
NOTE is used to address information not
related to personal injury, equipment
damage, and environment deterioration.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n

times.
# A line starting with the # sign is comments.
Interface Numbering Conventions

Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Security Conventions
l Password setting
Issue 03 (2016-10-30) Huawei Proprietary and Confidential iii

– When configuring a password, the cipher text is recommended. To ensure device

security, change the password periodically.
– When you configure a password in plain text that starts and ends with %^%#, %#
%#, %@%@ or @%@% (the password can be decrypted by the device), the
password is displayed in the same manner as the configured one in the
configuration file. Do not use this setting.
– When you configure a password in cipher text, different features cannot use the
same cipher-text password. For example, the cipher-text password set for the AAA
feature cannot be used for other features.
l Encryption algorithm
Currently, the device uses the following encryption algorithms: 3DES, AES, RSA,
SHA1, SHA2, and MD5. 3DES, RSA and AES are reversible, while SHA1, SHA2, and
MD5 are irreversible. The encryption algorithms DES/3DES/RSA (RSA-1024 or
lower)/MD5 (in digital signature scenarios and password encryption)/SHA1 (in digital
signature scenarios) have a low security, which may bring security risks. If protocols
allowed, using more secure encryption algorithms, such as AES/RSA (RSA-2048 or
higher)/SHA2/HMAC-SHA2, is recommended. The encryption algorithm depends on
actual networking. The irreversible encryption algorithm must be used for the
administrator password, SHA2 is recommended.
l Personal data
Some personal data may be obtained or used during operation or fault location of your
purchased products, services, features, so you have an obligation to make privacy
policies and take measures according to the applicable law of the country to protect
personal data.
l The terms mirrored port, port mirroring, traffic mirroring, and mirroing in this manual
are mentioned only to describe the product's function of communication error or failure
detection, and do not involve collection or processing of any personal information or
communication data of users.
Declaration
This manual is only a reference for you to configure your devices. The contents in the manual,
such as web pages, command line syntax, and command outputs, are based on the device
conditions in the lab. The manual provides instructions for general scenarios, but do not cover
all usage scenarios of all product models. The contents in the manual may be different from
your actual device situations due to the differences in software versions, models, and
configuration files. The manual will not list every possible difference. You should configure
your devices according to actual situations.
The specifications provided in this manual are tested in lab environment (for example, the
tested device has been installed with a certain type of boards or only one protocol is run on
the device). Results may differ from the listed specifications when you attempt to obtain the
maximum values with multiple functions enabled on the device.
Mappings between Product Software Versions and NMS

Versions
The mappings between product software versions and NMS versions are as follows.
Issue 03 (2016-10-30) Huawei Proprietary and Confidential iv

S2750&S5700&S6720 Product eSight

Software Version
V200R008C00 eSight V300R003C20
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 03 (2016-10-30) V200R008C00

Some contents are modified according to updates in the product.

This version has the following updates:
Some contents are modified according to updates in the product.

Initial commercial release.
Issue 03 (2016-10-30) Huawei Proprietary and Confidential v

Configuration Guide - QoS Contents
Contents
About This Document.....................................................................................................................ii

1 QoS Overview................................................................................................................................ 1
2 MQC Configuration...................................................................................................................... 4
2.1 Introduction to MQC...................................................................................................................................................... 5
2.2 Configuration Notes....................................................................................................................................................... 7
2.3 Configuring MQC.........................................................................................................................................................11
2.3.1 Configuring a Traffic Classifier.................................................................................................................................11
2.3.2 Configuring a Traffic Behavior................................................................................................................................. 15
2.3.3 Configuring a Traffic Policy......................................................................................................................................21
2.3.4 Applying the Traffic Policy....................................................................................................................................... 22
2.3.5 Checking the Configuration.......................................................................................................................................24
2.4 Maintaining MQC.........................................................................................................................................................25
2.4.1 Displaying MQC Statistics........................................................................................................................................ 25
2.4.2 Clearing MQC Statistics............................................................................................................................................ 25
2.5 References.................................................................................................................................................................... 26
3 Priority Mapping Configuration on the S6720EI, S5720HI, and S5720EI.........................27

3.1 Priority Mapping Overview..........................................................................................................................................28
3.2 Principles...................................................................................................................................................................... 28
3.3 Applicable Scenario......................................................................................................................................................31
3.4 Configuration Notes..................................................................................................................................................... 32
3.5 Default Configuration...................................................................................................................................................34
3.6 Configuring Priority Mapping...................................................................................................................................... 40
3.6.1 Specifying the Packet Priority Trusted on an Interface............................................................................................. 40
3.6.2 (Optional) Configuring an Interface Priority.............................................................................................................41
3.6.3 Configuring a DiffServ Domain................................................................................................................................ 41
3.6.4 Applying the DiffServ Domain................................................................................................................................. 43
3.6.5 (Optional) Configuring the Mappings Between Local Precedences and Queues......................................................43
3.7 Configuring MQC-based Priority Re-marking.............................................................................................................44
3.8 Configuration Examples............................................................................................................................................... 52
3.8.1 Example for Configuring Priority Mapping.............................................................................................................. 52
3.9 Common Misconfigurations......................................................................................................................................... 54
Issue 03 (2016-10-30) Huawei Proprietary and Confidential vi

3.9.1 Packets Enter Incorrect Queues................................................................................................................................. 54

3.9.2 Priority Mapping Results Are Incorrect.................................................................................................................... 56
3.10 FAQ.............................................................................................................................................................................57
3.10.1 Which Priority Does an Interface Trust?................................................................................................................. 57
3.11 References...................................................................................................................................................................58
4 Priority Mapping Configuration on the S2750, S5700LI, S5700S-LI, S5710-X-LI,

S5720SI, and S5720S-SI..................................................................................................................59
4.1 Priority Mapping Overview..........................................................................................................................................60
4.2 Principles...................................................................................................................................................................... 60
4.3 Applicable Scenario......................................................................................................................................................62
4.4 Default Configuration...................................................................................................................................................62
4.5 Configuring Priority Mapping...................................................................................................................................... 64
4.5.1 Specifying the Packet Priority Trusted on an Interface............................................................................................. 64
4.5.2 (Optional) Configuring an Interface Priority.............................................................................................................65
4.5.3 Configuring the Mappings Between DSCP Priorities and Other Priorities...............................................................66
4.5.4 Configuring the Mappings Between IP Precedences and Other Priorities................................................................ 66
4.5.5 (Optional) Configuring the Mappings Between Local Precedences and Queues......................................................67
4.6 Configuring MQC-based Priority Re-marking.............................................................................................................68
4.7 Configuration Examples............................................................................................................................................... 73
4.7.1 Example for Configuring Priority Mapping.............................................................................................................. 73
4.8 Common Misconfigurations......................................................................................................................................... 77
4.8.1 Packets Enter Incorrect Queues................................................................................................................................. 77
4.8.2 Priority Mapping Results Are Incorrect.................................................................................................................... 79
4.9 FAQ...............................................................................................................................................................................80
4.9.1 Which Priority Does an Interface Trust?................................................................................................................... 80
4.10 References.................................................................................................................................................................. 81
5 Traffic Policing, Traffic Shaping, and Interface-based Rate Limiting............................. 82

5.1 Overview...................................................................................................................................................................... 83
5.2 Principles...................................................................................................................................................................... 83
5.2.1 Traffic Metering and Token Bucket Mechanism....................................................................................................... 83
5.2.2 Traffic Policing.......................................................................................................................................................... 92
5.2.3 Traffic Shaping.......................................................................................................................................................... 93
5.2.4 Interface-based Rate Limiting................................................................................................................................... 94
5.3 Applications..................................................................................................................................................................95
5.4 Configuration Notes..................................................................................................................................................... 97
5.5 Default Configuration.................................................................................................................................................102
5.6 Configuring Traffic Policing...................................................................................................................................... 103
5.6.1 Configuring MQC to Implement Traffic Policing................................................................................................... 103
5.6.2 Configuring Hierarchical Traffic Policingon the S5720HI and S5720EI................................................................ 111
5.7 Configuring Traffic Shaping.......................................................................................................................................112
5.7.1 Configuring Traffic Shaping for a Queue................................................................................................................ 112
Issue 03 (2016-10-30) Huawei Proprietary and Confidential vii

5.7.2 (Optional) Configuring the Data Buffer.................................................................................................................. 113

5.7.3 Checking the Configuration.....................................................................................................................................114
5.8 Configuring Interface-based Rate Limiting................................................................................................................115
5.8.1 Configuring Inbound Interface-based Rate Limiting...............................................................................................115
5.8.2 Configuring Outbound Interface-based Rate Limiting............................................................................................116
5.8.3 Configuring Rate Limiting on the Management Interface.......................................................................................117
5.9 Maintaining Traffic Policing, Traffic Shaping, and Interface-based Rate Limiting...................................................118
5.9.1 Displaying Traffic Statistics.....................................................................................................................................118
5.9.2 Clearing Traffic Statistics........................................................................................................................................ 118
5.10 Configuration Examples........................................................................................................................................... 119
5.10.1 Example for Configuring MQC to Implement Traffic Policing............................................................................ 119
5.10.2 Example for Configuring Hierarchical Traffic Policing(Applicable to S5720HI and S5720EI).......................... 123
5.10.3 Example for Configuring Rate Limiting in a Specified Time Range.................................................................... 128
5.10.4 Example for Configuring Rate Limiting for Users on Different Network Segments............................................131
5.10.5 Example for Configuring Traffic Shaping (Applicable to S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI,
and S5720S-SI).................................................................................................................................................................135
5.10.6 Example for Configuring Interface-based Rate Limiting......................................................................................137
5.11 FAQ...........................................................................................................................................................................139
5.11.1 When Both traffic-limit inbound and qos lr inbound Are Configured, Which of Them Will Take Effect?..........139
5.12 References................................................................................................................................................................ 140
6 Congestion Avoidance and Congestion Management Configuration............................ 141

6.1 Overview.................................................................................................................................................................... 142
6.2 Principles.................................................................................................................................................................... 144
6.2.1 Congestion Avoidance............................................................................................................................................. 144
6.2.2 Congestion Management......................................................................................................................................... 146
6.3 Applicable Scenario....................................................................................................................................................155
6.4 Configuration Notes................................................................................................................................................... 157
6.5 Configuring Congestion Avoidance on the S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI.. 159
6.6 Configuring Congestion Avoidance on the S6720EI, S5720HI, and S5720EI.......................................................... 161
6.6.1 (Optional) Configuring CFI as the Internal Drop Priority.......................................................................................161
6.6.2 Configuring a WRED Drop Profile......................................................................................................................... 162
6.6.3 Applying the WRED Drop Profile.......................................................................................................................... 163
6.7 Configuring Congestion Management on the S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI
.......................................................................................................................................................................................... 164
6.8 Configuring Congestion Management on the S6720EI, S5720HI, and S5720EI...................................................... 165
6.9 Configuring Congestion Management on a Stack Interface of the S2750, S5700LI, S5700S-LI, S5710-X-LI,
S5720SI, and S5720S-SI.................................................................................................................................................. 167
6.10 Configuring Congestion Management on a Stack Interfaceon the S6720EI and S5720EI...................................... 168
6.11 Maintaining Congestion Avoidance and Congestion Management..........................................................................169
6.11.1 Displaying Queue-based Traffic Statistics.............................................................................................................169
6.11.2 Clearing Queue-based Traffic Statistics................................................................................................................ 169
Issue 03 (2016-10-30) Huawei Proprietary and Confidential viii


6.12.1 Example for Configuring Congestion Management on the S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI,
and S5720S-SI.................................................................................................................................................................. 170
6.12.2 Example for Configuring Congestion Avoidance and Congestion Managementon the S6720EI, S5720HI, and
S5720EI............................................................................................................................................................................ 173
6.13 References................................................................................................................................................................ 177
7 Packet Filtering Configuration............................................................................................... 178

7.1 Introduction to Packet Filtering.................................................................................................................................. 179
7.3 Configuring Packet Filtering...................................................................................................................................... 180
7.4 Configuration Examples............................................................................................................................................. 188
7.4.1 Example for Configuring Packet Filtering.............................................................................................................. 188
7.5 References.................................................................................................................................................................. 191
8 Redirection Configuration.......................................................................................................192
8.1 Introduction to Redirection.........................................................................................................................................193
8.3 Configuring Redirection............................................................................................................................................. 194
8.4.1 Example for Configuring Redirection..................................................................................................................... 202
8.5 References.................................................................................................................................................................. 207
9 Traffic Statistics Configuration.............................................................................................. 208

9.1 Introduction to Traffic Statistics................................................................................................................................. 209
9.3 Configuring Traffic Statistics..................................................................................................................................... 210
9.4.1 Example for Configuring Traffic Statistics............................................................................................................. 218
10 ACL-based Simplified Traffic Policy Configuration....................................................... 222

10.1 Overview of the ACL-based Simplified Traffic Policy............................................................................................223
10.2 Configuration Notes................................................................................................................................................. 223
10.3 Configuring ACL-based Packet Filtering.................................................................................................................225
10.4 Configuring ACL-based Traffic Policing on the S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-
SI.......................................................................................................................................................................................228
10.5 Configuring ACL-based Traffic Policingon the S6720EI, S5720HI, and S5720EI................................................. 230
10.6 Configuring ACL-based Redirection on the S2750, S5700LI, S5700S-LI, and S5710-X-LI..................................232
10.7 Configuring ACL-based Redirectionon the S6720EI, S5720HI, S5720SI, S5720S-SI, and S5720EI.................... 233
10.8 Configuring ACL-based Re-marking....................................................................................................................... 234
10.9 Configuring ACL-based Traffic Statistics................................................................................................................ 236
10.10 Configuring ACL-based Traffic Mirroring.............................................................................................................238
10.11 Maintaining an ACL-based Simplified Traffic Policy............................................................................................238
10.11.1 Displaying Statistics on ACL-based Packet Filtering..........................................................................................238
10.11.2 Clearing Statistics on ACL-based Packet Filtering............................................................................................. 238
10.12 Configuration Example...........................................................................................................................................239
Issue 03 (2016-10-30) Huawei Proprietary and Confidential ix

10.12.1 Example for Preventing a Specified Host to Access the External Network........................................................239
10.12.2 Example for Configuring Rate Limiting for Services from Different VLANs................................................... 242
10.12.3 Example for Configuring ACL-based Redirection..............................................................................................245
10.12.4 Example for Configuring an ACL-based Simplified Traffic Policy to Implement Priority Mapping.................249
10.12.5 Example for Configuring ACL-based Traffic Statistics...................................................................................... 251
10.12.6 Example for Configuring ACL-based Local Flow Mirroring............................................................................. 253
11 HQoS Configuration...............................................................................................................256
11.1 Introduction to HQoS................................................................................................................................................257
11.2 Principles.................................................................................................................................................................. 257
11.3 Applications.............................................................................................................................................................. 259
11.4 Configuration Notes..................................................................................................................................................259
11.5 Default Configuration............................................................................................................................................... 260
11.6 Configuring HQoS....................................................................................................................................................262
11.6.1 Configuring a Flow Queue.................................................................................................................................... 263
11.6.2 (Optional) Configuring the Mapping Between Flow Queues and Interface Queues.............................................264
11.6.3 Configuring a Subscriber Queue............................................................................................................................264
11.6.4 Checking the Configuration...................................................................................................................................265
11.7 Maintaining HQoS....................................................................................................................................................266
11.7.1 Displaying Traffic Statistics on Subscriber Queues.............................................................................................. 266
11.7.2 Clearing Traffic Statistics on Subscriber Queues.................................................................................................. 266
11.8.1 Example for Configuring HQoS............................................................................................................................ 267
Issue 03 (2016-10-30) Huawei Proprietary and Confidential x

Configuration Guide - QoS 1 QoS Overview
1 QoS Overview
QoS defines a service provider's ability to meet the level of service required by a customers'
traffic. The QoS-enabled device controls enterprise network traffic, implements congestion
management and congestion avoidance, reduces the packet loss ratio, and provides dedicated
bandwidth for enterprise users or differentiated services.
QoS Background
Diversified services result in a sharp increase in network traffic, which may cause network
congestion, increase forwarding delay, or even packet loss. Any of the preceding situations
will cause service quality deterioration or even service interruption. Therefore, real-time
services require a solution to prevent network congestion. The best solution is to increase
network bandwidth, but increasing network bandwidth is not cost effective. The most cost-
effective way is to use a "guarantee" policy to manage traffic congestion.
Quality of service (QoS) technology provides end-to-end service quality guarantee based on
the requirements of different services. It is a tool that helps improve utilization of network
resources and allows different types of traffic to preempt network resources based on their
priorities. Voice, video, and important data applications are processed preferentially on
network devices. QoS is now widely used and plays an important role in Internet applications.
QoS Service Models

l Best-Effort
Best-Effort is the default service model for the Internet and applies to various network
applications, such as the File Transfer Protocol (FTP) and email. It is the simplest service
model, in which an application can send any number of packets at any time without
notifying the network. The network then makes the best effort to transmit the packets but
provides no guarantee of performance in terms of delay and reliability.
The Best-Effort model is suitable for services that do not require short delay time and
high reliability.
l Integrated Services (IntServ)
In the IntServ model, an application uses a signaling protocol to notify the network of its
traffic parameters and apply for a specific level of QoS before sending packets. The
network reserves resources for the application based on the traffic parameters. After the
application receives an acknowledgement message and confirms that sufficient resources
have been reserved, it starts to send packets within the range specified by the traffic
Issue 03 (2016-10-30) Huawei Proprietary and Confidential 1

parameters. The network maintains a state for each packet flow and performs QoS
behaviors based on this state to ensure a guaranteed application performance.
The IntServ model uses the Resource Reservation Protocol (RSVP) as the signaling
protocol. The RSVP protocol reserves resources such as bandwidth and priority on a
known path, and each network element along the path must reserve required resources
for data flows requiring QoS guarantee. That is, each network element maintains a soft
state for each data flow. A soft state is a temporary state that is periodically updated
through RSVP messages. Each network element checks whether sufficient resources can
be reserved based on these RSVP messages. The path is available only when all involved
network elements can provide sufficient resources.
l Differentiated Services (DiffServ)
The DiffServ model classifies packets on a network into multiple classes and takes
different actions for the classes. When network congestion occurs, packets of different
classes are processed based on their priorities to obtain different packet loss rates, delays,
and jitters. Packets of the same class are aggregated and sent as a whole to ensure the
same delay, jitter, and packet loss rate.
In the DiffServ model, traffic classification and aggregation are completed on edge
nodes. Edge nodes classify packets based on a combination of fields in packets, such as
the source and destination addresses, precedence in the Type of Service (ToS) field, and
protocol type, and then mark packets with different priorities. Other nodes only need to
identify the marked priorities for resource allocation and traffic control.
Unlike the IntServ model, the DiffServ model does not require a signaling protocol. In
this model, an application does not need to apply for network resources before sending
packets. Instead, the application sets QoS parameters in the packets, through which the
network can learn the QoS requirements of the application. The network provides
differentiated services based on the QoS parameters of each data flow and does not need
to maintain a state for each data flow. DiffServ takes full advantage of IP networks'
flexibility and extensibility and transforms information in packets into per-hop behaviors
(PHBs), greatly reducing signaling operations. DiffServ is the most commonly used QoS
model on current networks. QoS implementation described in the subsequent sections is
based on this model.
Components in the DiffServ Model

The DiffServ model involves the following QoS mechanisms:
l Traffic classification and marking

Traffic classification and marking are prerequisites for differentiated services. Traffic
classification divides data packets into different classes or sets different priorities, and
can be implemented using traffic classifiers configured on the Modular QoS Command
Line Interface (MQC). Traffic marking sets different priorities for packets and can be
implemented through priority mapping and re-marking.
l Traffic policing, traffic shaping, and interface-based rate limiting
Traffic policing and traffic shaping control the traffic rate within a bandwidth limit.
Traffic shaping drops excess traffic when the traffic rate exceeds the limit, whereas
traffic shaping buffers excess traffic. Traffic policing and traffic shaping can be
performed on an interface to implement interface-based rate limiting.
l Congestion management and congestion avoidance
Congestion management buffers packets in queues upon network congestion and
determines the forwarding order using a specific scheduling algorithm. Congestion

avoidance monitors network resource usage and drops packets to mitigate network
overloading when congestion worsens.
Traffic classification and marking are the basis of differentiated services. Traffic policing,
traffic shaping, interface-based rate limiting, congestion management, and congestion
avoidance control network traffic and resource allocation to implement differentiated services.
Figure 1-1 shows the order in which different QoS mechanisms process packets.
Figure 1-1 QoS processing order
Congestion Tra
av ng eu er
f
management R fic sh
oi es es
C qu Ent
nc n
d a t io
Data
ate ap
e
lim ing
Queue Go it
Outbound interface
0 qu o u
eu t of
Inbound inerface
Queue es
Scheduling
Voice
1
Traffic Other
Classification Queue
policing processing
Marking 2
Rate limit …
…
Video
Queue
N
Figure 1-2 shows where the QoS mechanisms are implemented.
Figure 1-2 Location of QoS mechanisms
Packet classification and marking

Traffic policing
Rate limiting on inbound interface
WAN
Congestion management
Congestion avoidance
Traffic shaping
Traffic policing
Rate limiting on outbound interface
Related Content
Videos
Huawei Switches QoS Feature Introduction

Configuration Guide - QoS 2 MQC Configuration
2 MQC Configuration
About This Chapter
This chapter describes how to configure Modular QoS Command-Line Interface (MQC).
MQC enables you to configure certain rules to classify traffic and specify an action for traffic
of the same type. MQC configuration can implement differentiated services.
2.1 Introduction to MQC

2.2 Configuration Notes
2.3 Configuring MQC
2.4 Maintaining MQC
2.5 References

2.1 Introduction to MQC

Modular QoS Command-Line Interface (MQC) allows you to classify packets based on
packet characteristics and specify the same service for packets of the same type. In this way,
different types of packets can be provided differentiated services.
As more services are deployed on a network, service deployment becomes increasingly
complex because traffic of different services or users requires different services. Using MQC
configuration, you can classify network traffic in a fine-grained way and specify the services
provided to different types of traffic according to your needs. MQC enhances serviceability of
your network.
MQC Entities
MQC involves three entities: traffic classifier, traffic behavior, and traffic policy.
l Traffic classifier
A traffic classifier defines a group of matching rules to classify packets. Table 2-1 lists
traffic classification rules.
Table 2-1 Traffic classification rules

Layer Traffic Classification Rule
Layer 2 l Destination MAC address

l Source MAC address
l VLAN ID in the tag of VLAN-tagged packets
l 802.1p priority in the tag of VLAN-tagged
packets
l VLAN ID in the inner tag of QinQ packets
l 802.1p priority in the inner tag of QinQ packets
l Protocol field in the Layer 2 header
l Matching fields in ACL 4000 to ACL 4999
Layer 3 l DSCP priority in IP packets

l IP precedence in IP packets
l IP protocol type (IPv4 or IPv6)
l TCP-flag in TCP packets
l Matching fields in ACL6 2000 to ACL6 3999
Others l All packets

l Inbound interface
l Outbound interface
(user-defined ACLs)

The relationship between rules in a traffic classifier can be AND or OR. The default
relationship is AND.
– AND: If a traffic classifier contains ACL rules, a packet matches the traffic
classifier only when it matches one ACL rule and all the non-ACL rules. If a traffic
classifier does not contain ACL rules, a packet matches the traffic classifier only
when it matches all the rules in the classifier.
– OR: A packet matches a traffic classifier as long as it matches one of rules.
l Traffic behavior
A traffic behavior defines an action for packets of a specified type.
l Traffic policy
A traffic policy binds traffic classifiers and traffic behaviors, and then actions defined in
traffic behaviors are taken for classified packets. As shown in Figure 2-1, a traffic policy
can be bound to multiple traffic classifiers and traffic behaviors.
Figure 2-1 Multiple pairs of traffic classifiers and traffic behaviors in a traffic policy
Traffic behavior b1
(priority re-marking,
Traffic policy Traffic classifier c1
redirection, packet
filtering)
Traffic behavior b2
Traffic classifier c2
redirection, packet
filtering)
……
Traffic behavior bn
Traffic classifier cn
redirection, packet
filtering)）
MQC Configuration Process

Figure 2-2 outlines the MQC configuration process.
1. Configure a traffic classifier. The traffic classifier defines a group of matching rules to
classify traffic and is the basis for differentiated services.
2. Configure a traffic behavior. The traffic behavior defines a flow control or resource
allocation action for packets matching the rules.
3. Create a traffic policy and bind the traffic classifier to the traffic behavior in the traffic
policy.
4. Apply the traffic policy to system, interface, or VLAN.

Figure 2-2 MQC configuration process
Configure a traffic
classifier
Configure a traffic
behavior
Configure a traffic
policy
Apply the traffic policy

to an interface, a
VLAN, or the system
Involved Network Elements

Other network elements are not required.
License Support
MQC is a basic feature of a switch and is not under license control.
Version Support
Table 2-2 describes the products and minimum version supporting MQC.
Table 2-2 Products and minimum version supporting MQC
Series Product Minimum Version

Required
S1700 S1720GFR V200R006 (The S1720GFR

is unavailable in V200R007
and V200R008.)
S2700 S2700SI Not supported
S2700EI V100R006 (The S2700EI is

unavailable in V200R001
and later versions.)


Required
S2710SI V100R006 (The S2710SI is


and V200R008.)
S2750EI V200R003
S3700 S3700SI V100R006 (The S3700SI is


S3700HI V100R006 (The S3700HI is

S5700 S5700LI/S5700S-LI V200R001
S5710-C-LI V200R001 (The S5710-C-

LI is unavailable in
V200R002 and later
versions.)
S5710-X-LI V200R008



S5720EI V200R007
S5720SI/S5720S-SI V200R008




Required
S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009
Feature Dependencies and Limitations

l Table 2-3 describes the specifications of MQC.
Table 2-3 Specifications of MQC

Item Specification
Maximum number of traffic classifiers l Earlier versions of V100R006: 255

l V100R006 to V200R002: 256
l V200R003 and later versions: 512
Maximum number of if-match rules in a 1024

traffic classifier
Maximum number of traffic behaviors 256
Maximum number of traffic policies 256
Maximum number of traffic classifiers 256

bound to a traffic policy
l If the ACL rule matches the VPN instance name of packets, the ACL-based traffic policy
fails to be delivered.
l When permit and other actions are configured in a traffic behavior, these actions are
performed in sequence. The deny action conflicts with other actions in a traffic behavior.
When deny is configured, other configured actions, except traffic statistics collection
and flow mirroring, do not take effect.
l If you specify a packet filtering action for packets matching an ACL rule, the system first
checks the action defined in the ACL rule. If the ACL rule defines permit, the action
taken for the packets depends on whether deny or permit is specified in the traffic
behavior. If the ACL rule defines deny, the packets are discarded regardless of whether
deny or permit is configured in the traffic behavior. If a non-packet-filtering action is
specified for packets matching an ACL rule that defines deny, the packets are discarded,
and the action specified in the traffic classifier, except disabling MAC address learning,
traffic statistics collection and flow mirroring, does not take effect.
l The remark 8021p inner-8021p command applies only to the inbound direction.
l If a traffic policy containing remark 8021p is applied to the outbound direction on an
interface, the VLAN of the interface must work in tagged mode.

l The MAC address specified in a destination MAC address re-marking action must be a
unicast MAC address.
l If a traffic policy containing remark vlan-id is applied to the outbound direction on an
interface, the VLAN of the interface must work in tagged mode.
l A traffic policy containing remark 8021p inner-8021p, remark local-precedence,
remark ip-precedence, or remark destination-mac cannot be applied to the outbound
direction.
l In V200R005 and later versions, a traffic policy containing redirect cpu allows the
device to redirect the traffic matching traffic classification rules to the CPU, affecting
system performance. Exercise caution when you apply such a traffic policy.
l In V200R006 and earlier versions, if traffic is redirected to an interface in Down state,
traffic is dropped on the interface and cannot be switched to the original forwarding path.
l In V200R007 and later versions, if traffic is redirected to an interface in Down state and
forced is specified in the redirection command, traffic is dropped on the interface and
cannot be switched to the original forwarding path. If forced is not specified, the
redirection action does not take effect.
l A traffic policy can be applied to the system, a VLAN, or an interface. When a traffic
policy needs to be applied in multiple views, apply the traffic policy in the interface
view, VLAN view, and system view in sequence.
l When packets match multiple traffic policies, the following rules apply:
– If traffic classification rules in the traffic policies are of the same type (all user-
defined ACL rules, Layer 2 rules, or Layer 3 rules), only one traffic policy takes
effect. The precedence of the traffic policies depends on the objects to which they
are applied: interface > VLAN > global. That is, the traffic policy applied to an
interface has the highest priority, whereas the traffic policy applied to the system
has the lowest priority. When different traffic policies are applied in the same view,
the precedence of the policies depends on the configuration sequence.
– On the S5700EI, S5700HI, S5710EI, S5710HI, S5720EI, S5720HI, and S6700: If
traffic classification rules in the traffic policies are of different types and the actions
do not conflict, all the traffic policies take effect. If actions conflict, the precedence
of the traffic policies depends on precedence of rules in the policies: Layer 2 rule +
Layer 3 rule > Layer 3 rule > Layer 2 rule > user-defined ACL rule.
– On the S5720SI, S5720S-SI, S5710-X-LI, S5710-C-LI, S5700SI, S5700LI,
S5700S-LI, S2750EI, S2720EI, and S1720GFR: If traffic classification rules in the
traffic policies are of different types, only one traffic policy takes effect. The
precedence of the traffic policies depends on the objects to which they are applied:
interface > VLAN > global. That is, the traffic policy applied to an interface has the
highest priority, whereas the traffic policy applied to the system has the lowest
priority. If traffic policies apply to the same object, the traffic policy that contains
the rule with the highest priority takes effect.
It is recommended that you configure traffic policies in descending order of priority;
otherwise, traffic policies may not take effect immediately. For details about traffic
classification rules, see Traffic classification rules in 2.1 Introduction to MQC.
l Applying traffic policies consumes ACL resources. If there are no sufficient ACL
resources, some traffic policies may fail to be applied. For example, if an if-match rule in
a traffic policy occupies one ACL, M ACL resources will be used to apply the traffic
policy to M interfaces. When a traffic policy is applied to L VLANs, L ACLs are
occupied. When a traffic policy is applied to the system, one ACL is occupied. Table 2-4
describes the ACL resource usage of if-match rules.

Table 2-4 ACLs occupied by traffic classification rules
Traffic Classification Rule ACL Resource Usage
if-match vlan-id start-vlan-id [ to end- Rules are delivered according to the

vlan-id ] (S5720SI, S5720S-SI, S5710-X- VLAN ID range, and multiple ACLs are
LI, S5710-C-LI, S5700SI, S5700EI, occupied. You can run the display acl
S5700LI, S5700S-LI, S2750EI, S2720EI, division start-id to end-id command to
and S1720GFR) check how ACL resources are used in a
if-match cvlan-id start-vlan-id [ to end- specified VLAN range.
vlan-id ] [ vlan-id vlan-id ] (S5700EI,
S5700HI, S5710EI, S5710HI, S5720EI,
S5720HI, and S6700)
if-match acl { acl-number | acl-name } Uplink: When the range resources are
if-match ipv6 acl { acl-number | acl- exhausted (there are 32 ranges for each
name } card), rules containing range port-start
port-end are delivered and multiple ACLs
are occupied. Each rule containing tcp-
flag established occupies two ACLs.(In
V200R006 and later versions, the uplink
ACL resource usage on the S5720HI is
similar to the downlink ACL resource
usage.)
Downlink: Rules containing range port-
start port-end are delivered according to
the port number range, and multiple
ACLs are occupied. In other situations,
one rule occupies one ACL. You can run
the display acl division start-id to end-id
command to check how ACL resources
are used in a specified port number range.
Other if-match rules Each rule occupies one ACL resource.
2.3 Configuring MQC

2.3.1 Configuring a Traffic Classifier
Pre-configuration Tasks
Before configuring a traffic classifier, complete the following tasks:
l Configure link layer attributes of interfaces to ensure that the interfaces work properly.
l Configure an ACL if the ACL needs to be used to classify traffic.
Configuration Process
Non-conflicting rules can be configured in a traffic classifier.

Procedure
1. Run:
system-view
The system view is displayed.

2. Run:
traffic classifier classifier-name [ operator { and | or } ]
A traffic classifier is created and the traffic classifier view is displayed, or the existing
traffic classifier view is displayed.
and is the logical operator between the rules in the traffic classifier, which means that:
– If the traffic classifier contains ACL rules, packets match the traffic classifier only
when they match one ACL rule and all the non-ACL rules.
– If the traffic classifier does not contain any ACL rules, packets match the traffic
classifier only when they match all the rules in the classifier.
The logical operator or means that packets match the traffic classifier as long as they
match one of rules in the classifier.
By default, the relationship between rules in a traffic classifier is AND.
3. Configure matching rules according to the following table.
NOTE
The S5720HI does not support traffic classifiers with advanced ACLs containing the ttl-expired
field or user-defined ACLs.
When a traffic classifier contains if-match ipv6 acl { acl-number | acl-name }, the S5720HI does
not support remark 8021p [ 8021p-value | inner-8021p ], remark cvlan-id cvlan-id, or remark
vlan-id vlan-id.
Matching Command Remarks

Rule
Outer if-match vlan-id start-vlan-id [ to -

VLAN ID end-vlan-id ] (S2750, S5700LI,
S5700S-LI, S5710-X-LI, S5720SI,
S5720S-SI)
Inner and if-match cvlan-id start-vlan-id [ to -

outer end-vlan-id ] [ vlan-id vlan-id ]
VLAN IDs (S5720EI, S5720HI, S6720EI)
in QinQ
packets
802.1p if-match 8021p 8021p-value If you enter multiple 802.1p

priority in &<1-8> priority values in one
VLAN command, a packet matches the
packets traffic classifier as long as it
matches any one of the 802.1p
priorities, regardless of whether
the relationship between rules
in the traffic classifier is AND
or OR.


Rule
Inner if-match cvlan-8021p 8021p-value -

802.1p &<1-8> (S5720EI, S5720HI,
priority in S6720EI)
QinQ
packets

VLAN ID end-vlan-id ] [ cvlan-id cvlan-id ]
or inner and (S5720EI, S5720HI, S6720EI)
outer
VLAN IDs
of QinQ
packets
Drop if-match discard (S5720EI, A traffic classifier containing

packet S5720HI, S6720EI) this matching rule can only be
bound to traffic behaviors
containing traffic statistics
collection and flow mirroring
actions.
Double tags if-match double-tag (S5720EI, -

in QinQ S5720HI, S6720EI)
packets
Destination if-match destination-mac mac- -

MAC address [ mac-address-mask ]
address
Source if-match source-mac mac-address -

MAC [ mac-address-mask ]
address
Protocol if-match l2-protocol { arp | ip | -

type field mpls | rarp | protocol-value }
in the
Ethernet
frame
header
All packets if-match any -


Rule
DSCP if-match dscp dscp-value &<1-8> l If you enter multiple DSCP

priority in values in one command, a
IP packets packet matches the traffic
classifier as long as it
matches any one of the
DSCP values, regardless of
whether the relationship
between rules in the traffic
classifier is AND or OR.
l If the relationship between
rules in a traffic classifier is
AND, the if-match dscp
and if-match ip-
precedence commands
cannot be used in the traffic
classifier simultaneously.
IP if-match ip-precedence ip- l The if-match dscp and if-

precedence precedence-value &<1-8> match ip-precedence
in IP commands cannot be
packets configured in a traffic
classifier in which the
relationship between rules is
AND.
l If you enter multiple IP
precedence values in one
command, a packet matches
the traffic classifier as long
as it matches any one of the
IP precedence values,
regardless of whether the
relationship between rules
in the traffic classifier is
AND or OR.
Layer 3 if-match protocol { ip | ipv6 } -

protocol
type
SYN Flag if-match tcp syn-flag { syn-flag- -

in the TCP value | ack | fin | psh | rst | syn |
packet urg }
Inbound if-match inbound-interface A traffic policy containing this

interface interface-type interface-number matching rule cannot be
applied to the outbound
direction or in the interface
view.


Rule
Outbound if-match outbound-interface A traffic policy containing this

interface interface-type interface-number matching rule cannot be
(S5720EI, S5720HI, S6720EI) applied to the inbound direction
on the S5720HI.
The traffic policy containing
this matching rule cannot be
applied in the interface view.
ACL rule if-match acl { acl-number | acl- l When an ACL is used to

name } define a traffic classification
rule, it is recommended that
the ACL be configured first.
l If an ACL in a traffic
classifier defines multiple
rules, a packet matches the
ACL as long as it matches
one of rules, regardless of
ACL6 rule if-match ipv6 acl { acl-number | acl- Before specifying an ACL6 in a
name } matching rule, configure the
ACL6.
Flow ID if-match flow-id flow-id (S5720EI, The traffic classifier containing

S6720EI) if-match flow-id and the traffic
behavior containing remark
flow-id must be bound to
different traffic policies.
The traffic policy containing if-
match flow-id can be only
applied to an interface, a
VLAN, or the system in the
inbound direction.
4. Run:
quit
Exit from the traffic classifier view.
2.3.2 Configuring a Traffic Behavior

Before configuring a traffic behavior, configure link layer attributes of interfaces to ensure
that the interfaces work properly.
Background

The device supports actions including packet filtering, priority re-marking, flow ID re-
marking, redirection, traffic policing, and traffic statistics collection.
Procedure
Step 1 Run:
system-view

Step 2 Run:
traffic behavior behavior-name
A traffic behavior is created and the traffic behavior view is displayed, or the view of an
existing traffic behavior is displayed.
Step 3 Define actions in the traffic behavior. You can configure multiple non-conflicting actions in a
traffic behavior.
Action Command Remarks
Packet filtering deny | permit In the same traffic behavior,

the deny action cannot be
used with other traffic
actions except for traffic
statistics collection and flow
mirroring.
For details on how to
configure packet filtering,
see 7 Packet Filtering
Configuration.

Priority re-marking remark 8021p [ 8021p- A traffic policy containing

value | inner-8021p ] remark 8021p
remark dscp { dscp-name | inner-8021p, remark local-
dscp-value } precedence, remark ip-
precedence, or remark
remark local-precedence destination-mac can only
{ local-precedence-name | be applied to the inbound
local-precedence-value } direction.
[ green | yellow | red ]
(S5720EI, S5720HI, If a traffic policy containing
S6720EI) remark 8021p is applied to
the outbound direction on an
remark local-precedence interface, the VLAN of the
{ local-precedence-name | interface must work in
local-precedence-value } tagged mode.
(S2750, S5700LI, S5700S-
LI, S5710-X-LI, S5720SI, When a traffic classifier
S5720S-SI) defines if-match ipv6 acl
{ acl-number | acl-name },
remark ip-precedence ip- remark 8021p [ 8021p-
precedence value | inner-8021p ] cannot
be configured on the
S5720HI.
The remark 8021p and
remark local-precedence
commands cannot be used in
the same traffic behavior.
configure MQC-based
priority re-marking on the
S2750, S5700LI, S5700S-
LI, S5710-X-LI, S5720SI,
and S5720S-SI, see 4.6
Configuring MQC-based
Priority Re-marking.
configure MQC-based
priority re-marking on the
S6720EI, S5720EI, and
S5720HI, see 3.7
Priority Re-marking.

Flow ID re-marking remark flow-id flow-id The traffic classifier

(S5720EI, S6720EI) containing if-match flow-id
and the traffic behavior
containing remark flow-id
must be bound to different
traffic policies.
remark flow-id can be only
inbound direction.
remark flow-id, statistic
enable, and car cannot be
configured in the same
traffic behavior.
Redirection redirect cpu (S6720EI, A traffic policy containing

S5720EI, S5720HI) redirect interface and
redirect interface interface- redirect cpu can only be
type interface-number applied to the inbound
[ forced ] direction.
configure redirection, see 8
Redirection Configuration.

Traffic policing car [ aggregation ] cir cir- Only the S5710-X-LI,

value [ pir pir-value ] [ cbs S5720SI, and S5720S-SI
cbs-value pbs pbs-value ] support the aggregation
[ green pass ] [ yellow parameter.
{ discard | pass [ remark- For details on how to
dscp dscp-value | configure MQC-based
remark-8021p 8021p- traffic policing, see 5.6.1
value ] } ] [ red { discard | Configuring MQC to
pass [ remark-dscp dscp- Implement Traffic
value | remark-8021p Policing.
8021p-value ] } ] (S2750,
S5700LI, S5700S-LI,
S5710-X-LI, S5720SI,
S5720S-SI)
car cir cir-value [ pir pir-
value ] [ cbs cbs-value pbs
pbs-value ] [ green
{ discard | pass [ remark-
dscp dscp-value |
remark-8021p 8021p-
value ] } ] [ yellow
{ discard | pass [ remark-
dscp dscp-value |
remark-8021p 8021p-
value ] } ] [ red { discard |
pass [ remark-dscp dscp-
value | remark-8021p
8021p-value ] } ] (S6720EI,
S5720EI)
car cir cir-value [ pir pir-
value ] [ cbs cbs-value pbs
pbs-value ] [ green
{ discard | pass } ] [ yellow
{ discard | pass } ] [ red
{ discard | pass } ]
(S5720HI)
Hierarchical traffic policing car car-name share A traffic policy containing

(S5720EI, S5720HI) car share can only be
applied to the inbound
direction.

Flow mirroring mirroring to observe-port The S2750, S5700LI,

observe-port-index S5700S-LI, S5710-X-LI,
S5720SI, and S5720S-SI do
not support flow mirroring
in the outbound direction.
configure MQC-based flow
mirroring, see Configuring
Traffic Mirroring and
Configuring Remote Traffic
Mirroring.
PBR redirect ip-nexthop ip- The traffic policy containing

address &<1-4> [ forced ] PBR can be applied in the
(S5720SI, S5720S-SI, inbound direction only.
S5720EI, S5720HI, The traffic policy containing
S6720EI) PBR is only valid for IP
redirect ipv6-nexthop packets.
{ ipv6-address | link-local For details on how to
link-local-address interface configure PBR, see PBR
interface-type interface- Configuration.
number } &<1-4> [ forced ]
(S5720SI, S5720S-SI,
S5720EI, S5720HI,
S6720EI)
redirect ip-multihop
{ nexthop ip-address }
&<2-4> (S6720EI, S5720EI,
S5720HI)
redirect ipv6-multihop
{ ipv6-address | link-local
link-local-address interface
interface-type interface-
number } &<2-4>
(S6720EI, S5720EI,
S5720HI)
Disabling MAC address mac-address learning -

learning disable (S6720EI, S5720EI,
S5720HI)

VLAN mapping remark vlan-id vlan-id When the traffic classifier

remark cvlan-id cvlan-id defines if-match outbound-
(S6720EI, S5720EI, interface interface-type
S5720HI) interface-number, VLAN
mapping cannot be defined
in the associated traffic
behavior.
configure MQC-based
VLAN mapping, see
VLAN Mapping.
Traffic statistics statistic enable The S2750, S5700LI,

S5700S-LI, S5710-X-LI,
S5720SI, and S5720S-SI
can only count the number
of packets and not the
number of bytes.
configure traffic statistics,
see 9 Traffic Statistics
Configuration.
Step 4 Run:
quit
Exit from the traffic behavior view.
----End
2.3.3 Configuring a Traffic Policy
Before configuring a traffic policy, complete the following tasks:
l Configure a traffic classifier.
l Configure a traffic behavior.
Procedure
1. Run:
system-view

2. Run the following commands as required.
– On the S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI, run:
traffic policy policy-name

A traffic policy is created and the traffic policy view is displayed, or the view of an
existing traffic policy is displayed.
– On the S6720EI, S5720EI and S5720HI, run:
traffic policy policy-name [ match-order { auto | config } ]
existing traffic policy is displayed.If no matching order is specified when you create
a traffic policy, the default matching order is config.
After a traffic policy is applied, you cannot use the traffic policy command to
modify the matching order of traffic classifiers in the traffic policy. To modify the
matching order, delete the traffic policy, create a new traffic policy and specify the
matching order.
When creating a traffic policy, you can specify the matching order of matching rules
in the traffic policy. The matching order can be either automatic order or
configuration order:
n If automatic order is used, traffic classifiers are matched based on the priorities
of their types. Traffic classifiers based on Layer 2 and Layer 3 information,
Layer 2 information, and Layer 3 information are matched in descending order
of priority. The traffic classifier with the highest priority is matched first. If
data traffic matches multiple traffic classifiers, and the traffic behaviors
conflict with each other, the traffic behavior corresponding to the highest
priority rule takes effect.
n If configuration order is used, traffic classifiers are matched based on the
sequence in which traffic classifiers were bound to traffic behaviors.
NOTE
If more than 128 ACL rules defining CAR are configured, a traffic policy must be applied to
an interface, a VLAN, and the system in sequence in the outbound direction. In the
preceding situation, if ACL rules need to be updated, delete the traffic policy from the
interface, VLAN, and system and reconfigure it in sequence.
3. Run:
classifier classifier-name behavior behavior-name
A traffic behavior is bound to a traffic classifier in a traffic policy.

4. Run:
quit
Exit from the traffic policy view.

5. Run:
quit
Exit from the system view.
2.3.4 Applying the Traffic Policy
Before applying a traffic policy, configure the traffic policy.
Procedure
l Applying a traffic policy to an interface
a. Run:

system-view

b. Run:
interface interface-type interface-number[.subinterface-number ]
The interface view [.subinterface-number ]is displayed.

NOTE
l Only the S6720EI supports sub-interfaces. A sub-interface cannot be assigned an IP

address.
l Only hybrid and trunk interfaces on the preceding switches support sub-interface
configuration.
l After you run the undo portswitch command to switch Layer 2 interfaces on the
preceding series of switches into Layer 3 interfaces, you can configure sub-interfaces on
the interfaces.
l After an interface is added to an Eth-Trunk, sub-interfaces cannot be configured on the
interface.
c. Run:
traffic-policy policy-name { inbound | outbound }
A traffic policy is applied to the interface or sub-interface.

A traffic policy can only be applied to one direction on an interface but can be
applied to different directions on different interfaces. After a traffic policy is applied
to an interface, the system performs traffic policing for all the incoming or outgoing
packets that match traffic classification rules on the interface.
NOTE
l Traffic policies can be applied to only the inbound direction of sub-interfaces on the
S6720EI.
l It is not recommended to use the traffic policy containing remark 8021p, remark
cvlan-id, and remark vlan-id in the outbound direction of an untagged interface. This
configuration may cause incorrect information in the packets.
l Applying a traffic policy to a VLAN
a. Run:
system-view

b. Run:
vlan vlan-id
The VLAN view is displayed.

c. Run:
A traffic policy is applied to the VLAN.

Only one traffic policy can be applied to a VLAN in the inbound or outbound
direction.
After a traffic policy is applied a VLAN, the system performs traffic policing for
the packets that belong to the VLAN and match traffic classification rules in the
inbound or outbound direction.

NOTE
Applying traffic policies consumes ACL resources. If there are not sufficient ACL resources,
some traffic policies may fail to be applied. For example, an if-match rule in a traffic policy
occupies an ACL. When the traffic policy is applied to M interfaces, M ACLs are occupied.
When a traffic policy is applied to a VLAN or in the system, the number of occupied ACLs
is the number of LPUs on the device. For details about ACLs occupied by if-match rules, see
Table 2-4 in 2.2 Configuration Notes.
l Applying a traffic policy to the system
a. Run:
system-view

b. Run:
traffic-policy policy-name global { inbound | outbound } [ slot slot-id ]
A traffic policy is applied to the system.

Only one traffic policy can be applied to the system or slot in one direction. A
traffic policy cannot be applied to the same direction in the system and slot
simultaneously.
n In a stack, a traffic policy that is applied to the system takes effect on all the
interfaces and VLANs of all the member switches in the stack. The system
then performs traffic policing for all the incoming and outgoing packets that
match traffic classification rules on all the member switches. A traffic policy
that is applied to a specified slot takes effect on all the interfaces and VLANs
of the member switch with the specified stack ID. The system then performs
traffic policing for all the incoming and outgoing packets that match traffic
classification rules on this member switch.
n On a standalone switch, a traffic policy that is applied to the system takes
effect on all the interfaces and VLANs of the local switch. The system then
performs traffic policing for all the incoming and outgoing packets that match
traffic classification rules on the local switch. Traffic policies applied to the
slot and system have the same functions.
2.3.5 Checking the Configuration
Procedure
l Run the display traffic classifier user-defined [ classifier-name ] command to check the
traffic classifier configuration.
l Run the display traffic behavior user-defined [ behavior-name ] command to check the
traffic behavior configuration.
l Run the display traffic policy user-defined [ policy-name [ classifier classifier-name ] ]
command to check the user-defined traffic policy configuration.
l Run the display traffic-applied [ interface [ interface-type interface-number ] | vlan
[ vlan-id ] ] { inbound | outbound } [ verbose ] command to check ACL-based
simplified and MQC-based traffic policies applied to the system, a VLAN, or an
interface.
NOTE
Traffic policies can be applied to a sub-interface, but the display traffic-applied command cannot be
used to check the ACL-based simplified and MQC-based traffic policies applied to the sub-interface.

l Run the display traffic policy { interface [ interface-type interface-number

[.subinterface-number ] ] | vlan [ vlan-id ] | global } [ inbound | outbound ] command
to check the traffic policy configuration.
l Run the display traffic-policy applied-record [ policy-name ] command to check the
application record of a specified traffic policy.
2.4 Maintaining MQC
2.4.1 Displaying MQC Statistics
Context
MQC statistics are also traffic policy statistics. To check forwarded and discarded packets in
the system or in a specified object to which a traffic policy has been applied, you can view
traffic policy statistics.
To view traffic policy statistics, ensure that MQC and statistic enable have been configured.
Procedure
l Run the display traffic policy statistics { global [ slot slot-id ] | interface interface-type
interface-number [.subinterface-number ] | vlan vlan-id } { inbound | outbound }
[ verbose { classifier-base | rule-base } [ class classifier-name ] ] command to check
packet statistics in the system, on an LPU, on an interface, or in a VLAN to which a
traffic policy has been applied.
----End
2.4.2 Clearing MQC Statistics
Context
MQC statistics are also traffic policy statistics. Before recollecting traffic policy statistics in
the system or in a specified object, clear existing packet statistics.
NOTICE
Traffic policy statistics cannot be restored after being cleared. Exercise caution when you use
this command.
Procedure
l Run the reset traffic policy statistics { global [ slot slot-id ] | interface interface-type
interface-number [.subinterface-number ] | vlan vlan-id } { inbound | outbound }
command in the user view to clear statistics on packets matching a traffic policy applied
to the system, an LPU, an interface, or a VLAN.
----End

2.5 References
Document Description Remarks
RFC 2474 Definition of the Differentiated Services -

Field (DS Field) in the IPv4 and IPv6
Headers
RFC 2475 An Architecture for Differentiated -

Services
RFC 2597 Assured Forwarding PHB Group -
RFC 2598 An Expedited Forwarding PHB -
RFC 2697 A Single Rate Three Color Marker -
RFC 2698 A Two Rate Three Color Marker -

S2750&S5700&S6720 Series Ethernet Switches 3 Priority Mapping Configuration on the S6720EI,
Configuration Guide - QoS S5720HI, and S5720EI
3 Priority Mapping Configuration on the

S6720EI, S5720HI, and S5720EI
About This Chapter
This chapter describes how to configure priority mapping.
3.1 Priority Mapping Overview

3.2 Principles
3.3 Applicable Scenario
3.5 Default Configuration
3.6 Configuring Priority Mapping
3.7 Configuring MQC-based Priority Re-marking
3.8 Configuration Examples
3.9 Common Misconfigurations
3.10 FAQ
3.11 References


Priority mapping is a method of translating Quality of service (QoS) precedence fields carried
in packets into internal priorities on a device (also called local priorities, which are used to
differentiate classes of service for packets). After priority mapping, the device provides
differentiated services for packets based on the internal priorities.
Packets transmitted over different networks carry different QoS precedence fields, for
example, 802.1p field on a virtual local area network (VLAN), EXP field on a Multiprotocol
Label Switching (MPLS) network, and DSCP field on an IP network. Priority mapping must
be configured on network devices to retain priorities of packets when the packets traverse
different networks. When a device connects different types of networks, it maps external
precedence fields (including 802.1p, MPLS EXP, and DSCP) of all the received packets to
internal priorities. When the device sends packets, it maps internal priorities to external
priorities.
3.2 Principles
Priority Mapping
Packets carry different types of precedence field depending on the network type. For example,
packets carry the 802.1p field in a VLAN network, the EXP field on an MPLS network, and
the DSCP field on an IP network. The mapping between the priority fields must be configured
on the gateway to retain packet priorities when the packets traverse different types of
networks.
The priority mapping mechanism provides the mapping from precedence fields of packets to
internal priorities (local priorities) or the mapping from internal priorities to precedence fields
of packets. This mechanism uses a DiffServ domain to manage and record the mapping
between precedence fields and Class of Service (CoS) values. When a packet reaches the
device, the device maps the priority in the packet or the default 802.1p priority of the inbound
interface to a local priority. The device then determines which queue the packet enters based
on the mapping between internal priorities and queues, and performs traffic policing, queuing,
and scheduling. In addition, the device can re-mark precedence fields of outgoing packets so
that the downstream device can provide differentiated QoS based on packet priorities.
Precedence Fields
Certain fields in the packet header or frame header record QoS information so that network
devices can provide differentiated services. These fields include:
l Precedence field
As defined in RFC 791, the 8-bit Type of Service (ToS) field in an IP packet header
contains a 3-bit IP precedence field. Figure 3-1 shows the Precedence field in an IP
packet.

Figure 3-1 IP Precedence/DSCP field

Version ToS Flags/
Len ID TTL Proto FCS IP-SA IP-DA Data
Length 1 Byte offset
0 1 2 3 4 5 6 7
Precedence D T R C
IP Precedence
DSCP
Bits 0 to 2 constitute the Precedence field, representing precedence values 7, 6, 5, 4, 3, 2,

1 and 0, in descending order of priority. The highest priorities (values 7 and 6) are
reserved for routing and network control communication updates. User-level applications
can use only priority values 0 to 5.
Apart from the Precedence field, a ToS field also contains the following sub-fields:
– Bit D indicates the delay. The value 0 represents a normal delay and the value 1
represents a short delay.
– Bit T indicates the throughput. The value 0 represents normal throughput and the
value 1 represents high throughput.
– Bit R indicates the reliability. The value 0 represents normal reliability and the
value 1 represents high reliability.
l DSCP field
RFC 1349 initially defined the ToS field in IP packets and later added bit C that indicates
the monetary cost. Then, the IETF DiffServ Working Group redefined bits 0 to 5 of a
ToS field as the DSCP field in RFC 2474. In RFC 2474, the field name is changed from
ToS to differentiated service (DS). Figure 3-1 shows the DSCP field in packets.
In the DS field, the first six bits (bits 0 to 5) are the DS CodePoint (DSCP) and the last
two bits (bits 6 and 7) are reserved. The first three bits (bits 0 to 2) are the Class Selector
CodePoint (CSCP), which represents the DSCP type. A DS node selects a Per-Hop
Behavior (PHB) based on the DSCP value.
l 802.1p priority in the Ethernet frame header
Layer 2 devices exchange Ethernet frames. As defined in IEEE 802.1Q, the PRI field
(802.1p priority) in the Ethernet frame header, also called CoS, identifies the QoS
requirement. Figure 3-2 shows the PRI field.
Figure 3-2 802.1p priority in the Ethernet frame header

Destination Source 802.1Q Length
Data FCS
address address Tag /Type
16bits 3bits 1bit 12bits

TPID PRI CFI VLAN ID

The 802.1Q header contains a 3-bit PRI field. The PRI field defines eight service priority
values 7, 6, 5, 4, 3, 2, 1 and 0, in descending order of priority.
l MPLS EXP field
In contrast to IP packets, MPLS packets use labels. A label has 4 bytes. Figure 3-3
shows the format of the MPLS EXP field.
NOTE
Only the S6720EI supports the MPLS EXP field.
Figure 3-3 Format of the MPLS EXP Field
Link layer header Label Layer 3 header Layer 3 payload

Label EXP S TTL
The EXP field contains four sub-fields:

– Label: contains 20 bits and specifies the next hop to which a packet is to be
forwarded.
– EXP: contains 3 bits and is reserved for extensions; also known as the CoS field.
– S: contains 1 bit and identifies the last entry in the label stack. MPLS supports
hierarchical labels. If the S sub-field is 1, the label is at the bottom of the stack.
– TTL: contains 8 bits and is the same as the TTL in IP packets.
The EXP field is used as the CoS field in MPLS packets and is equivalent to the ToS
field in IP packets. The EXP field is used to differentiate data flows on MPLS networks.
The EXP field encodes eight transmission priorities 7, 6, 5, 4, 3, 2, 1 and 0 in descending
order of priority.
– On an IP network, the IP precedence or DSCP field in an IP packet identifies the
CoS value. On an MPLS network, a Label Switching Router (LSR) cannot identify
IP packet headers; therefore, EXP fields are marked at the edge of the MPLS
network.
– By default, the IP precedence in an IP packet is copied to the EXP field in an MPLS
packet at the edge of an MPLS network. If an ISP does not trust a user network or
differentiated service levels defined by an ISP are different from those on a user
network, reconfigure the EXP field in an MPLS packet based on classification
policies and internal service levels. During forwarding on the MPLS network, the
ToS field in an IP packet remains unchanged.
– On an MPLS network, intermediate nodes classify packets based on the EXP field
in MPLS packets and perform PHBs such as congestion management, traffic
policing, and traffic shaping.


Networking Requirements
As shown in Figure 3-4, the enterprise campus network provides voice, video, and data
services, with priorities in descending order. When different service flows of enterprise users
arrive at the ISP network, devices on the ISP network must identify priorities of the services
to provide differentiated services.
The precedence field in a packet depends on the network type. For example, packets on a
Layer 2 network carry the 802.1p field and those on a Layer 3 network carry the DSCP field.
When packets arrive at a device, the device maps packet priorities to CoS values and colors,
and provides different QoS services according to the CoS values and colors. When packets
leave the device, the device remarks the precedence fields of the packets based on the CoS
values and colors. The downstream device can then provide differentiated services based on
packet priorities.
Figure 3-4 Networking of priority mapping
Traffic direction
Voice flow
ISP
Data flow Router
SwitchA SwitchB
Video flow Layer 3

Layer 2
Flow-based priority re-marking in the inbound direction

Mapping from 802.1p priorities to CoS values and colors in the
inbound direction
DSCP priority re-marking in the outbound direction according to
CoS values and colors
Service Deployment
l On SwitchA, configure a traffic policy in the inbound direction to re-mark voice, video,
and data packets with different 802.1p priorities. The priorities of voice, video, and data
services are in descending order.
l Configure SwitchB to map 802.1p priorities of incoming packets to CoS values and
colors. SwitchB then provides differentiated services based on the CoS values and
colors.
l Configure SwitchB to re-mark outgoing packets with DSCP priorities based on CoS
values and colors. In this way, the service packets are provided differentiated services on
the Layer 3 network based on DSCP priorities.


License Support
Priority mapping is a basic feature of a switch and is not under license control.
Version Support
Table 3-1 describes the products and minimum version supporting priority mapping.
Table 3-1 Products and minimum version supporting priority mapping

Required
S1700 S1720GFR V200R006 (The S1720GFR

and V200R008.)
S2700 S2700SI V100R006 (The S2700SI is




and V200R008.)
S2750EI V200R003
S3700 S3700SI V100R006 (The S3700SI is





Required
S5700 S5700LI/S5700S-LI V200R001
S5710-C-LI V200R001 (The S5710-C-

V200R002 and later
versions.)
S5710-X-LI V200R008



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

None.


Mapping from Priorities to CoS Values (PHBs) and Colors in the Inbound
Direction in a DiffServ Domain
By default, the mappings in a DiffServ domain are as follows:
l Table 3-2 lists the mappings from 802.1p priorities to PHBs and colors.
l Table 3-3 lists the mappings from DSCP priorities to PHBs and colors.
l Table 3-4 lists the mappings from EXP priorities in MPLS packets to PHBs and colors.
The mappings from interface priorities to PHBs and colors are similar to the mappings from
802.1p priorities to PHBs and colors. Colors of packets are only used to determine whether to
drop packets and do not affect mappings between internal priorities and queues.
NOTE
Only the S6720EI supports the mappings between EXP priorities and PHBs/colors.
Table 3-2 Mappings from 802.1p priorities to PHBs and colors of incoming VLAN packets in
a DiffServ domain
802.1p Priority PHB Color
0 BE green
1 AF1 green
2 AF2 green
3 AF3 green
4 AF4 green
5 EF green
6 CS6 green
7 CS7 green
Table 3-3 Mappings from DSCP priorities to PHBs and colors of incoming IP packets in the
DiffServ domain
DSCP PHB Color DSCP PHB Color
0 BE green 32 AF4 green
1 BE green 33 BE green
2 BE green 34 AF4 green
4 BE green 36 AF4 yellow

DSCP PHB Color DSCP PHB Color
6 BE green 38 AF4 red
8 AF1 green 40 EF green
10 AF1 green 42 BE green
12 AF1 yellow 44 BE green
14 AF1 red 46 EF green
16 AF2 green 48 CS6 green
22 AF2 red 54 BE green
24 AF3 green 56 CS7 green
30 AF3 red 62 BE green

Table 3-4 Mappings from EXP priorities to PHBs and colors of incoming packets in the
DiffServ domain
EXP Priority PHB Color
0 BE green
1 AF1 green
2 AF2 green
3 AF3 green
4 AF4 green
5 EF green
6 CS6 green
7 CS7 green
Mapping Between CoS Values and Interface Queue Indexes

By default, internal priorities (CoS of packets) and interface queues are mapped on a one-to-
one basis. In real-world applications, you may need to change the mappings between CoS
values and queues or map different CoS values to the same queue to save the device buffer.
The device sends packets to different interface queues based on the internal priorities, and
performs traffic shaping, congestion avoidance, and queue scheduling for the queues.
Table 3-5 lists the mappings between internal priorities and queues supported by the S6720EI,
S5720EI and S5720HI.
Table 3-5 Mappings between internal priorities and queueson the S6720EI, S5720EI and
S5720HI
Internal Priority Queue Index
BE 0
AF1 1
AF2 2
AF3 3
AF4 4
EF 5
CS6 6
CS7 7

Mapping from CoS Values (PHBs) and Colors to Priorities in the Outbound
Direction in the DiffServ Domain
By default, the mappings in a DiffServ domain are as follows:
l Table 3-6 lists the mappings from PHBs and colors to 802.1p priorities.
l Table 3-7 lists the mappings from PHBs and colors to DSCP priorities.
l Table 3-8 lists the mappings from PHBs and colors to EXP priorities in MPLS packets.
The mappings from interface priorities to PHBs and colors are similar to the mappings from
802.1p priorities to PHBs and colors. Colors of packets are only used to determine whether to
drop packets and do not affect mappings between internal priorities and queues.
NOTE
Only the S6720EI supports the mappings between EXP priorities and PHBs/colors.
Table 3-6 Mappings from PHBs and colors to 802.1p priorities of outgoing VLAN packets in
the DiffServ domain
PHB Color 802.1p Priority
BE green 0
BE yellow 0
BE red 0
AF1 green 1
AF1 yellow 1
AF1 red 1
AF2 green 2
AF2 yellow 2
AF2 red 2
AF3 green 3
AF3 yellow 3
AF3 red 3
AF4 green 4
AF4 yellow 4
AF4 red 4
EF green 5
EF yellow 5
EF red 5
CS6 green 6
CS6 yellow 6

PHB Color 802.1p Priority
CS6 red 6
CS7 green 7
CS7 yellow 7
CS7 red 7
Table 3-7 Mappings from PHBs and colors to DSCP priorities of outgoing IP packets in the
DiffServ domain
PHB Color DSCP
BE green 0
BE yellow 0
BE red 0
AF1 green 10
AF1 yellow 12
AF1 red 14
AF2 green 18
AF2 yellow 20
AF2 red 22
AF3 green 26
AF3 yellow 28
AF3 red 30
AF4 green 34
AF4 yellow 36
AF4 red 38
EF green 46
EF yellow 46
EF red 46
CS6 green 48
CS6 yellow 48
CS6 red 48
CS7 green 56

PHB Color DSCP
CS7 yellow 56
CS7 red 56
Table 3-8 Mappings from PHBs and colors to EXP priorities of outgoing packets in the
DiffServ domain
PHB Color EXP Priority
BE green 0
BE yellow 0
BE red 0
AF1 green 1
AF1 yellow 1
AF1 red 1
AF2 green 2
AF2 yellow 2
AF2 red 2
AF3 green 3
AF3 yellow 3
AF3 red 3
AF4 green 4
AF4 yellow 4
AF4 red 4
EF green 5
EF yellow 5
EF red 5
CS6 green 6
CS6 yellow 6
CS6 red 6
CS7 green 7
CS7 yellow 7
CS7 red 7


After you configure priority mapping, the device maps packet priorities or the default
interface priority to PHBs and colors to provide differentiated services for packets.
Priority Mapping Configuration Logic

1. Specify the packet priority trusted by an interface so that priority mapping is performed
according to the trusted priority.
2. Configure a DiffServ domain to determine the mappings between packet priorities and
internal priorities (CoS values) so that the device provides differentiated services
according to internal priorities.
3. Apply the DiffServ domain to an object to make the mappings take effect. Then the
device can re-mark priorities of packets according to the mappings.
4. Configure mappings from internal priorities to queue indexes to schedule packets with
different internal priorities in different queues. This step is optional because the device
provides default mappings from internal priorities to queue indexes.
Before configuring priority mapping, complete the following tasks:
l Set physical parameters for relevant interfaces.
l Set the link-layer attributes for relevant interfaces.
3.6.1 Specifying the Packet Priority Trusted on an Interface

Context
The priority trusted on an interface determines which type of priority to be mapped for
packets on the interface.
Either of the following priorities can be trusted on an interface:
l 802.1p priority
– When receiving a VLAN-tagged packet, the device searches the mapping table for
the 802.1p priority of the packet, and then tags the packet with the mapping internal
priority.
– When receiving an untagged packet, the device searches the mapping table for the
default 802.1p priority, and then tags the packet with the mapping internal priority.
l DSCP priority
When receiving a packet, the device searches the mapping table for the DSCP priority of
the packet, and then tags the packet with the mapping internal priority.
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface interface-type interface-number
The interface view is displayed.

Step 3 Run:
trust { 8021p { inner | outer } | dscp }
The priority trusted on the interface is specified.

By default, an interface trusts 802.1p priorities in outer VLAN tags.
----End
3.6.2 (Optional) Configuring an Interface Priority

Context
An interface's priority is used in the following scenarios:
l If the interface receives untagged packets, the device provides differentiated services for
the packets based on the interface priority.
l If the priority mapping function is disabled on the interface using the trust upstream
none command, packets received on the interface can only be forwarded through priority
mapping. In this case, the device provides differentiated services for the packets based
on the interface priority.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
port priority priority-value
The interface priority is set.

The default interface priority is 0.
NOTE
When an interface has been switched to Layer 3 mode using the undo portswitch command, this
interface uses the priority 0 and you cannot configure a priority for it.
----End
3.6.3 Configuring a DiffServ Domain

Context
When the device is located at the edge of a DiffServ domain of another network, configure
mappings between internal priorities and external priorities:

l When traffic arrives at the device, the device maps packet priorities to PHBs and colors.
The device then performs congestion management based on PHBs and performs
congestion avoidance based on colors.
l When sending traffic out, the device maps PHBs and colors of packets to priorities. The
downstream device then provides QoS services based on packet priorities.
Procedure
Step 1 Run:
system-view
Step 2 Run:
diffserv domain { default | ds-domain-name }
A DiffServ domain is created and the DiffServ domain view is displayed.
The domain default defines default mappings between packet priorities and PHBs/colors. You
can modify the mappings defined in the domain default but cannot delete this domain. In
addition to the domain default, you can create a maximum of seven DiffServ domains.
Step 3 Run the following commands as required.

Operation Command
Map 802.1p priorities of incoming VLAN 8021p-inbound 8021p-value phb

packets on an interface to PHBs and color the service-class [ green | yellow | red ]
packets.
Map PHBs and colors of outgoing VLAN 8021p-outbound service-class { green |

packets on an interface to 802.1p priorities. yellow | red } map 8021p-value
Map DSCP priorities of incoming IP packets on ip-dscp-inbound dscp-value phb

an interface to PHBs and color the packets. service-class [ green | yellow | red ]
Map PHBs and colors of outgoing IP packets ip-dscp-outbound service-class { green

on an interface to DSCP priorities. | yellow | red } map dscp-value
Map EXP priorities of incoming MPLS packets mpls-exp-inbound exp-value phb

on an interface to PHBs and color the packets. service-class [ color ]
Map the PHBs and colors of outgoing MPLS mpls-exp-outbound service-class color
packets on an interface to the EXP priorities. map exp-value
3.5 Default Configuration describes the following default mappings:

l Mappings from 802.1p priorities to PHBs and colors
l Mappings from PHBs and colors to 802.1p priorities
l Mappings from DSCP priorities to PHBs and colors
l Mappings from PHBs and colors to DSCP priorities
l Mappings from MPLS EXP priorities to PHBs and colors
l Mappings from PHBs and colors to MPLS EXP priorities

NOTE
Only the S6720EI supports mappings from MPLS EXP priorities to PHBs and colors on interfaces in the
inbound direction and mappings from PHBs and colors to MPLS EXP priorities on interfaces in the
outbound direction.
----End
3.6.4 Applying the DiffServ Domain
Context
You can bind a DiffServ domain to an inbound or outbound interface of packets to enable the
device to implement mapping between packet priorities and PHBs/colors according to the
mappings defined in the DiffServ domain.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
trust upstream { ds-domain-name | default | none }
A DiffServ domain is bound to the interface.
If trust upstream none is configured on an interface, the system does not perform priority
mapping for incoming and outgoing packets.
To change the DiffServ domain bound to an interface, run the undo trust upstream
command to unbind the original DiffServ domain from the interface, and then run the trust
upstream command to bind the new DiffServ domain to the interface.
Step 4 (Optional) Run:

undo qos phb marking enable
PHB mapping is disabled for outgoing packets.
By default, PHB mapping is enabled for outgoing packets on an interface.
----End
3.6.5 (Optional) Configuring the Mappings Between Local

Precedences and Queues
Context
By configuring the mappings between local priorities and queues, the device sends packets to
the specified queue based on the mappings between local priorities and queues.

NOTE
The S5720HI does not support the mapping between local priorities and queues.
Procedure
Step 1 Run:
system-view

Step 2 Run:
qos local-precedence-queue-map local-precedence queue-index
The mapping between local priorities and queues is configured.

The mappings between local priorities and queues take effect only on the inbound interface.
That is, traffic enters queues based on the mappings.
----End

Procedure
l Run the display diffserv domain [ all | name ds-domain-name ] command to check the
DiffServ domain configuration.
l Run the display qos local-precedence-queue-map command to check the mapping
between local priorities and queues.
----End
Background
Priority re-marking is a method of changing priority fields of the packets that match certain
traffic classification rules. For example, you can configure priority mapping to change the
802.1p priority of VLAN packets or DSCP priority and local priority of IP packets.
Procedure
1. Configure a traffic classifier.
a. Run:
system-view

b. Run:
A traffic classifier is created and the traffic classifier view is displayed, or the view
of an existing traffic classifier is displayed.
and is the logical operator between the rules in the traffic classifier, which means
that:

n If the traffic classifier contains ACL rules, packets match the traffic classifier
only when they match one ACL rule and all the non-ACL rules.
n If the traffic classifier does not contain any ACL rules, packets match the
traffic classifier only when they match all the rules in the classifier.
The logical operator or means that packets match the traffic classifier as long as
they match any one of rules in the classifier.
By default, the logical operator used between rules in a traffic classifier is AND.
c. Configure matching rules according to the following table.
NOTE
The S5720HI does not allow traffic classifiers to reference advanced ACLs containing the
ttl-expired field or user-defined ACLs.
On the S5720HI, if a traffic classifier contains if-match ipv6 acl { acl-number | acl-name },
the associated traffic behavior cannot contain the remark 8021p [ 8021p-value |
inner-8021p ], remark cvlan-id cvlan-id, or remark vlan-id vlan-id action.

Rule
Inner and if-match cvlan-id start-vlan-id -

outer [ to end-vlan-id ] [ vlan-id vlan-
VLAN IDs id ]
in QinQ
packets
802.1p if-match 8021p 8021p-value If you enter multiple 8021p

priority in &<1-8> priority values in the
VLAN command, packets match the
packets traffic classifier as long as
they match one 8021p
priority, regardless of
Inner if-match cvlan-8021p 8021p- -

802.1p value &<1-8>
priority in
QinQ
packets

or inner
and outer
VLAN IDs
of QinQ
packets


Rule
Dropped if-match discard A traffic classifier containing

packet such a matching rule can only
be bound to traffic behaviors
collection and traffic
mirroring actions.
Double if-match double-tag -

tags in
QinQ
packets
Destinatio if-match destination-mac mac- -

n MAC address [ mac-address-mask ]
address

address

encapsulat
ed in the
Ethernet
frame
header
All if-match any -

packets
DSCP if-match dscp dscp-value &<1-8> l If you enter multiple

priority in DSCP priority values in
IP packets the command, packets
match the traffic classifier
as long as they match one
DSCP priority, regardless
of whether the
AND or OR.
l If the relationship
between rules in a traffic
classifier is AND, the if-
match dscp and if-match
ip-precedence commands
cannot be configured in
the traffic classifier
simultaneously.


Rule
IP if-match ip-precedence ip- l If the relationship

precedence precedence-value &<1-8> between rules in a traffic
in IP classifier is AND, the if-
packets match dscp and if-match
simultaneously.
priority values in the
command, packets match
the traffic classifier as
long as they match one IP
between rules in the
traffic classifier is AND
or OR.

protocol
type

packet urg }
header
Inbound if-match inbound-interface A traffic policy containing

interface interface-type interface-number such a matching rule cannot
be applied to the outbound
direction.
A traffic policy containing
such a matching rule cannot
be applied to an interface
view.
Outbound if-match outbound-interface The S5720HI does not allow

interface interface-type interface-number a traffic policy containing
such a matching rule to be
applied to the inbound
direction.
view.


Rule
ACL rule if-match acl { acl-number | acl- If an ACL used in a traffic

name } classifier has multiple rules,
NOTE packets match the ACL as
To use an ACL in a traffic classifier, long as they match any one of
you are advised to configure rules in rules in the ACL, regardless
the ACL first. of whether the relationship
ACL6 rule if-match ipv6 acl { acl-number | -

acl-name }
NOTE
To use an ACL6 in a traffic classifier,
you are advised to configure rules in
the ACL6 first.
Flow ID if-match flow-id flow-id The traffic classifier

traffic policies.
if-match flow-id can be only
inbound direction.
d. Run:
quit
2. Configure a traffic behavior.
a. Run:
A traffic behavior is created and the traffic behavior view is displayed.
b. Run the following commands as required:
n To re-mark the 802.1p priority field of packets matching the traffic classifier,
run remark 8021p [ 8021p-value | inner-8021p ].
NOTE
The remark 8021p inner-8021p action can only be used in the inbound direction.
If a traffic policy containing remark 8021p is applied to the outbound direction on an
interface, the VLAN of the outbound interface must work in tagged mode.
n To re-mark the DSCP priority field of packets matching the traffic classifier,
run remark dscp { dscp-name | dscp-value }.
n To re-mark the local priority field of packets matching the traffic classifier, run
remark local-precedence { local-precedence-name | local-precedence-value }
[ green | yellow | red ]

n To re-mark the IP precedence field of packets matching the traffic classifier,

run remark ip-precedence ip-precedence.
c. Run:
quit

3. Configure a traffic policy.
a. Run:
existing traffic policy is displayed. If you do not specify a matching order for traffic
classifiers in the traffic policy, the default matching order config is used.
change the matching order of traffic classifiers in the traffic policy. To change the
matching order, delete the traffic policy, and create a new traffic policy, and specify
the matching order.
When creating a traffic policy, you can specify the matching order of traffic
classifiers in the traffic policy. The traffic classifiers can be matched in automatic
order (auto) or configuration order (config):
n If the matching order is auto, traffic classifiers are matched in descending
order of priorities pre-defined in the system: traffic classifiers based on Layer
2 and Layer 3 information > traffic classifiers based on Layer 2 information >
traffic classifiers based on Layer 3 information. If a data flow matches multiple
traffic classifiers that are associated with conflicting traffic behaviors, the
traffic behavior associated with the traffic classifier of the highest priority
takes effect.
n If the matching order is config, traffic classifiers are matched in descending
order of priorities manually or dynamically allocated to them. A traffic
classifier with a smaller precedence value has a higher priority and is matched
earlier. If you do not specify precedence-value when creating a traffic
classifier, the system allocates a precedence value to the traffic classifier. The
allocated precedence value is [(max-precedence + 5)/5] x 5, where max-
precedence is the maximum greatest value among existing traffic classifiers.
NOTE
If more than 128 rate limiting ACL rules are configured in the system, traffic policies must
be applied in the sequence of interface view, VLAN view, and system view. To update an
ACL rule, delete all the associated traffic policies from the interface, VLAN, and system,
reconfigure the traffic policies, and then apply them to the interface, VLAN, and system in
sequence again.
b. Run:
A traffic behavior is bound to a traffic classifier in the traffic policy.

c. Run:
quit

d. Run:
quit

4. Apply the traffic policy.

– Applying a traffic policy to an interface
i. Run:
system-view

ii. Run:

NOTE
l Only the S6720EI supports sub-interfaces. A sub-interface cannot be assigned an

IP address.
configuration.
preceding series of switches into Layer 3 interfaces, you can configure sub-
interfaces on the interfaces.
l After an interface is added to an Eth-Trunk, sub-interfaces cannot be configured on
the interface.
iii. Run:

applied to different directions on different interfaces. After a traffic policy is
applied to an interface, the system performs traffic policing for all the
incoming or outgoing packets that match traffic classification rules on the
interface.
NOTE
l Traffic policies can be applied to only the inbound direction of sub-interfaces on

the S6720EI.
cvlan-id, and remark vlan-id in the outbound direction of an untagged interface.
This configuration may cause incorrect information in the packets.
– Applying a traffic policy to a VLAN
i. Run:
system-view

ii. Run:
vlan vlan-id

iii. Run:

direction.
After a traffic policy is applied a VLAN, the system performs traffic policing
for the packets that belong to the VLAN and match traffic classification rules
in the inbound or outbound direction.

NOTE
Applying traffic policies consumes ACL resources. If there are not sufficient ACL
resources, some traffic policies may fail to be applied. For example, an if-match rule in
a traffic policy occupies an ACL. When the traffic policy is applied to M interfaces, M
ACLs are occupied. When a traffic policy is applied to a VLAN or in the system, the
number of occupied ACLs is the number of LPUs on the device. For details about
ACLs occupied by if-match rules, see Table 2-4 in 2.2 Configuration Notes.
– Applying a traffic policy to the system
i. Run:
system-view

ii. Run:
traffic-policy policy-name global { inbound | outbound } [ slot slot-
id ]

simultaneously.
○ In a stack, a traffic policy that is applied to the system takes effect on all
the interfaces and VLANs of all the member switches in the stack. The
system then performs traffic policing for all the incoming and outgoing
packets that match traffic classification rules on all the member switches.
A traffic policy that is applied to a specified slot takes effect on all the
interfaces and VLANs of the member switch with the specified stack ID.
The system then performs traffic policing for all the incoming and
outgoing packets that match traffic classification rules on this member
switch.
○ On a standalone switch, a traffic policy that is applied to the system takes
effect on all the interfaces and VLANs of the local switch. The system
then performs traffic policing for all the incoming and outgoing packets
that match traffic classification rules on the local switch. Traffic policies
applied to the slot and system have the same functions.
Checking the Configuration

interface.
NOTE


3.8.1 Example for Configuring Priority Mapping
The S5720HI is used as an example. After priority mapping is configured, the switch maps
802.1p priorities of packets to different CoS values so that it can provide differentiated
services.
As shown in Figure 3-5, GE0/0/3 on the Switch connects to the router. Department 1 and 2
access the Internet through the Switch and router. Department 1 belongs to VLAN 100 and
Department 2 belongs to VLAN 200.
Department 1 requires better QoS guarantee. 802.1p priorities of packets from Departments 1
and 2 are both 0. A DiffServ domain needs to be defined to map priorities of packets from
Departments 1 and 2 to 4 and 2, respectively so that differentiated services are provided.
Figure 3-5 Networking diagram of priority mapping
Core Network
Router VLAN 300
GE0/0/3
GE0/0/1 GE0/0/2
VLAN 100 Switch VLAN 200
Department 1 Department 2

Configuration Roadmap
The configuration roadmap is as follows:
1. Create VLANs and configure interfaces so that Department 1 and 2 can connect to the
Internet through the Switch.
2. Create DiffServ domains, and map 802.1p priorities to PHBs and colors.
3. Bind DiffServ domains to GE0/0/1 and GE0/0/2 on the Switch, respectively.
Procedure
Step 1 Create VLANs and configure interfaces.
# Create VLAN 100 and VLAN 200.
<HUAWEI> system-view
[HUAWEI] sysname Switch
[Switch] vlan batch 100 200
# Configure GE0/0/1, GE0/0/2, and GE0/0/3 as trunk interfaces, add GE0/0/1 and GE0/0/2 to
VLAN 100 and VLAN 200, and add GE0/0/3 to VLAN 100 and VLAN 200.
[Switch] interface gigabitethernet 0/0/1
[Switch-GigabitEthernet0/0/1] port link-type trunk
[Switch-GigabitEthernet0/0/1] port trunk allow-pass vlan 100
[Switch-GigabitEthernet0/0/1] quit
[Switch-GigabitEthernet0/0/3] port trunk allow-pass vlan 100 200
Step 2 Create and configure DiffServ domains.

# Create DiffServ domains ds1 and ds2 on the Switch and map 802.1p priorities of packets
from Departments 1 and 2 to different CoS.
[Switch] diffserv domain ds1

[Switch-dsdomain-ds1] 8021p-inbound 0 phb af4 green
[Switch-dsdomain-ds1] quit
[Switch-dsdomain-ds2] 8021p-inbound 0 phb af2 green
Step 3 Bind DiffServ domains to interfaces.

# Bind DiffServ domains ds1 and ds2 to interfaces GE0/0/1 and GE0/0/2, respectively.
[Switch-GigabitEthernet0/0/1] trust upstream ds1
----End
Configuration Files
l Switch configuration file

#
sysname Switch
#
vlan batch 100 200
#
diffserv domain ds1
8021p-inbound 0 phb af4 green
diffserv domain ds2
#
interface GigabitEthernet0/0/1
port link-type trunk
port trunk allow-pass vlan 100
trust upstream ds1
#
trust upstream ds2
#
port trunk allow-pass vlan 100 200
#
return
3.9.1 Packets Enter Incorrect Queues

Common Causes
This fault is commonly caused by one of the following:
l The priority mappings configured in the DiffServ domain bound to the inbound interface
do not meet requirements.
l There are configurations affecting packet queuing on the inbound interface.
l There are configurations affecting packet queuing in the VLAN to which the packets
belong.
l There are configurations affecting packet queuing in the system.
Procedure
Step 1 Check whether priority mappings are correct.
Run the display this command in the inbound interface view and check the configuration of
the trust upstream command. Then, run the display diffserv domain name domain-name
command to check whether the priority mappings configured in the trusted DiffServ domain
are correct.
l If not, run the ip-dscp-inbound or 8021p-inbound command to correctly configure
priority mappings.
l If so, go to step 2.
Step 2 Check whether any configurations are affecting packet queuing on the inbound interface.
The following configurations affect the queues that packets enter on the inbound interface:
l If the port vlan-stacking command is configured with remark-8021p specified, the
priorities of packets are re-marked. Local priorities are assigned based on the re-marked

802.1p priorities, so packets do not enter the expected queues according to the priority
mapping configuration.
l If the port vlan-mapping vlan inner-vlan, or port vlan-mapping vlan map-vlan
command is configured with remark-8021p specified, the 802.1p priorities of packets
are re-marked. Local priorities are assigned based on the re-marked 802.1p priorities, so
packets do not enter the expected queues according to the priority mapping
configuration.
l If the packets match a traffic-policy that is applied to the inbound direction and contains
a remark local-precedence traffic behavior, the system sends packets to queues based
on the re-marked local priorities.
a remark 8021p, remark ip-precedence, or remark dscp traffic behavior, the system
assigns local priorities to packets based on the re-marked priorities of packets and sends
the packets to queues based on the local priorities.
l If the trust upstream none command is configured, the system does not perform
priority mapping for any packets received on the interface. All the incoming packets
enter the queue mapped to the interface priority.
l If the port link-type dot1q-tunnel command is configured but the trust 8021p inner
command is not, all the incoming packets enter the queue mapped to the interface
priority.
Run the display this command in the inbound interface view to check whether any of the
preceding commands are configured on the interface.
l If so, delete or modify the configuration as required.
l If not, go to step 3.
Step 3 Check whether any configurations are affecting packet queuing in the VLAN to which the
packets belong.
The following configurations affect packet queuing in a VLAN:
a remark local-precedence traffic behavior, the system sends packets to queues based
on the re-marked PHBs.
a remark 8021p, remark ip-precedence, or remark dscp traffic behavior, the system
maps the re-marked priorities of packets to local priorities and sends the packets to
queues based on the mapped priorities.
Run the display this command in the VLAN view to check whether there are any of the
preceding configurations in the VLAN.
Step 4 Check whether any configurations are affecting packet queuing in the system.
The following configurations affect the queues that packets enter in the system:
l If the qos local-precedence-queue-map command is configured, the system sends
packets to queues based on the mapping between local priorities and queues specified by
this command.
NOTE
The S5720HI does not support the qos local-precedence-queue-map command.

l If the packets match a global policy traffic-policy global that is applied to the inbound
direction and contains a remark local-precedence traffic behavior, the system sends
packets to queues based on the re-marked local priorities.
l If the packets match a global policy traffic-policy global that is applied to the inbound
direction and contains a remark 8021p, remark ip-precedence, or remark dscp traffic
behavior, the system maps the re-marked priorities of packets to local priorities and
sends the packets to queues based on the mapped priorities.
Run the display current-configuration command to check whether there are any of the
preceding configurations in the system. If so, delete or modify the configuration as required.
NOTE
When a traffic policy is applied to different objects simultaneously, it takes effect on the objects in the
order of interface, VLAN, and system.
----End
3.9.2 Priority Mapping Results Are Incorrect

Common Causes
l On the outbound interface, packets do not enter queues corresponding to priorities of
packets.
l The priority types trusted by the inbound and outbound interfaces do not meet service
requirements.
l The priority mappings configured in the DiffServ domains bound to the inbound and
outbound interfaces do not meet service requirements.
l There are configurations affecting priority mapping on the inbound and outbound
interfaces.
Procedure
Step 1 Check that packets enter the correct queues on the outbound interface.
Run the display qos queue statistics interface interface-type interface-number command to
check whether packets enter the correct queues on the outbound interface.
l If not, locate the fault according to 3.9.1 Packets Enter Incorrect Queues.
Step 2 Check that the priority types trusted by the inbound and outbound interface are correct.
Run the display this command in the inbound or outbound interface view to check whether
the trusted priority type set using the trust command is correct. (If the trust command is not
configured, the system trusts the 802.1p priority in the outer VLAN tag by default.)
l If not, run the trust command to specify the correct priority type.
Step 3 Check that the priority mapping configuration in the DiffServ domain bound to the inbound or
outbound interface is correct.
the trust upstream command is configured. If not, the system trusts the DiffServ domain
default by default.

Run the display diffserv domain name domain-name command to check whether the
mappings between local priorities and packet priorities are correct.
NOTE
Local priorities are assigned to packets on the inbound interface after priority mapping.
l If the priority mappings are incorrect, run the ip-dscp-outbound, mpls-exp-outbound

or 8021p-outbound command to correctly configure the mappings between local
priorities and packet priorities.
l If the priority mappings are correct, go to step 4.
Step 4 Check whether there are configurations affecting priority mapping on the inbound and
outbound interfaces.
The following configurations affect priority mapping on the inbound and outbound interfaces:
l If the undo qos phb marking enable command is configured, the system does not
perform PHB mapping for outgoing packets on an interface.
l If the trust upstream none command is configured, the system does not perform PHB
mapping for outgoing packets on an interface.
l If packets match a traffic-policy that is applied to the inbound or outbound direction and
contains a remark 8021p, remark ip-precedence, or remark dscp traffic behavior, the
packet priority is re-marked.
there are any configurations affecting priority mapping. If so, delete or modify the
configuration as required.
----End
3.10 FAQ
3.10.1 Which Priority Does an Interface Trust?

The S3700, S5700, or S6700 interface can be configured to trust DSCP priorities and 802.1p
priorities simultaneously, or trust IP precedences and 802.1p priorities simultaneously. When
an interface is configured to trust DSCP priorities and 802.1p priorities simultaneously, or
trust IP precedences and 802.1p priorities simultaneously, the interface:
l Trusts DSCP priorities or IP priorities if L3 packets are received.
l Trusts 802.1p priorities if L2 packets are received.
NOTE
The DSCP priority and IP precedence use different bits of the ToS field; therefore, an interface cannot be
configured to trust DSCP priorities and IP precedences simultaneously.
The S5720SI, S5720S-SI, and S5710-X-LI do not support the trust ip-precedence command.

3.11 References

Headers

Services

S2750&S5700&S6720 Series Ethernet Switches 4 Priority Mapping Configuration on the S2750, S5700LI,
Configuration Guide - QoS S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI
4 Priority Mapping Configuration on the

S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI,
and S5720S-SI
About This Chapter
This chapter describes how to configure priority mapping.

4.2 Principles
4.9 FAQ
4.10 References


Priority mapping implements conversion between priorities, for example, DSCP to 802.1P, IP
precedence to 802.1p, and DSCP to drop priority.
packets carry the 802.1p field on a VLAN and the DSCP field on an IP network. Packet
priorities must be retained when packets traverse different types of networks; therefore, the
devices connecting the networks must be configured with mappings between the priority
fields. When packets arrive at a device connecting different networks, the device maps
external priority fields (DSCP and IP precedence) of the packets to 802.1p priorities and then
to internal priorities based on 802.1p priorities. The device performs queuing and scheduling
for the packets based on internal priorities.
4.2 Principles
Priority Mapping
packets carry the 802.1p field in a VLAN and the DSCP field on an IP network. The mapping
between the priority fields must be configured on the gateway to retain priorities of packets
when the packets traverse different networks.
The priority mapping mechanism provides the mapping from DSCP priorities to 802.1p
priorities, IP priorities to 802.1p priorities, and DSCP priorities to drop priorities. When
packets reach the device, the device maps DSCP or IP priorities in packets to 802.1p priorities
according to the mapping table. The device then determines which queues packets enter based
on the mapping between 802.1p priorities and queues, and performs traffic shaping,
congestion avoidance, and queue scheduling. In addition, the device can re-mark precedence
fields of outgoing packets so that the downstream device can provide differentiated QoS
based on packet priorities.
QoS Precedence Fields

Certain fields in the packet header or frame header record QoS information so that network
devices can provide differentiated services on the Internet based on QoS information. These
fields include:
l Precedence field
As defined in RFC 791, the 8-bit ToS field in an IP packet header contains a 3-bit IP
precedence field. Figure 4-1 shows the Precedence field in an IP packet.

Figure 4-1 IP Precedence/DSCP field

Version ToS Flags/
Len ID TTL Proto FCS IP-SA IP-DA Data
Length 1 Byte offset
0 1 2 3 4 5 6 7
Precedence D T R C
IP Precedence
DSCP
Bits 0 to 2 constitute the Precedence field, representing precedence values 7, 6, 5, 4, 3, 2,

1 and 0, in descending order of priority. The values 7 and 6 (highest priority) are
reserved for routing and network control communication updates. User-level applications
can use only priority values 0 to 5.
Apart from the Precedence field, a ToS field also contains the following sub-fields:
– Bit D indicates the delay. The value 0 represents a normal delay and the value 1
represents a short delay.
– Bit T indicates the throughput. The value 0 represents normal throughput and the
value 1 represents high throughput.
– Bit R indicates the reliability. The value 0 represents normal reliability and the
value 1 represents high reliability.
l DSCP field
RFC 1349 initially defined the ToS field in IP packets and later added bit C that indicates
the monetary cost. Then, the IETF DiffServ Working Group redefined bits 0 to 5 of a
ToS field as the DSCP field in RFC 2474. In RFC 2474, the field name is changed from
ToS to differentiated service (DS). Figure 4-1 shows the DSCP field in packets.
In the DS field, the first six bits (bits 0 to 5) are the DS CodePoint (DSCP) and the last
two bits (bits 6 and 7) are reserved. The first three bits (bits 0 to 2) are the Class Selector
CodePoint (CSCP). CSCPs with the same value represent a type of the DSCP. A DS
node selects a Per-Hop Behavior (PHB) based on the DSCP value.
l 802.1p priority in the Ethernet frame header
Layer 2 devices exchange Ethernet frames. As defined in IEEE 802.1Q, the PRI field
(802.1p priority) in the Ethernet frame header, also called Class of Service (CoS),
identifies the QoS requirement. Figure 4-2 shows the PRI field.
Figure 4-2 802.1p priority in the Ethernet frame header

Destination Source 802.1Q Length
Data FCS
address address Tag /Type

TPID PRI CFI VLAN ID

The 802.1Q header contains a 3-bit PRI field. The PRI field defines eight service priority
values 7, 6, 5, 4, 3, 2, 1 and 0, in descending order of priority.

As shown in Figure 4-3, the enterprise campus network provides voice, video, and data
services, with priorities in descending order. When different service flows of enterprise users
arrive at the ISP network, devices on the ISP network must identify priorities of the services
to provide differentiated services.
A switch can identify packets based on priority fields, such as 802.1p or DSCP. When packets
arrive at the switch, the switch maps packet priorities to local priorities and drop priorities,
and provides different QoS services based on the local priorities and drop priorities.
Traffic direction
Voice flow
ISP
Data flow Router
SwitchA SwitchB
Video flow
Flow-based priority re-marking in the inbound direction
Mapping from DSCP priorities to 802.1p priorities and drop priorities
Service Deployment
l On SwitchA, configure a traffic policy in the inbound direction to re-mark voice, video,
and data packets with different DSCP priorities. The priorities of voice, video, and data
services are in descending order.
l Configure SwitchB to map DSCP priorities of incoming packets to 802.1p priorities and
drop priorities. SwitchB then provides differentiated services based on local priorities
mapped to the 802.1p priorities and drop priorities.

The default DSCP and IP priority mapping tables are as follows:

l Mappings from DSCP priorities to 802.1p priorities and drop priorities are listed in
Table 4-1. The output DSCP priorities are the same as the input DSCP priorities.
l Mappings from IP priorities to 802.1p priorities and IP priorities are listed in Table 4-2.
NOTE
S5720SI , S5720S-SI, and S5710-X-LI do not support mappings from IP priorities to 802.1p priorities or IP
priorities.
Table 4-1 Mappings from DSCP priorities to 802.1p priorities and drop priorities
Input DSCP Output 802.1p Priority Output Drop Priority
0-7 0 0
8-15 1 0
16-23 2 0
24-31 3 0
32-39 4 0
40-47 5 0
48-55 6 0
56-63 7 0
Table 4-2 Mappings from IP precedences to 802.1p priorities and IP precedences

Input IP Precedence Output 802.1p Priority Output IP Precedence
0 0 0
1 1 1
2 2 2
3 3 3
4 4 4
5 5 5
6 6 6
7 7 7
The default mappings from 802.1p priorities to local priorities are listed in Table 4-3.

Table 4-3 Mappings from 802.1p priorities to local priorities

802.1p Priority Local Priority
0 BE
1 AF1
2 AF2
3 AF3
4 AF4
5 EF
6 CS6
7 CS7
NOTE
The devices use the default mappings from 802.1p priorities to local priorities, and the mappings cannot
be changed.

After priority mapping is configured, the device determines the queues for inbound packets
and priorities of outbound packets based on packet priorities or interface priorities. By doing
this, the device provides differentiated services.
Before configuring priority mapping, configure link layer attributes of interfaces to ensure
that the interfaces work properly.
4.5.1 Specifying the Packet Priority Trusted on an Interface
Context
You can configure the device to trust any of the following priorities on an interface:
l 802.1p priority
For VLAN-tagged incoming packets, the system maps 802.1p priorities of the packets to
local priorities based on the default mappings. For untagged incoming packets, the
system uses the default 802.1p priority of the interface for priority mapping and maps the
default 802.1p priority to a local priority based on the default mappings.
l DSCP priority
The system searches the DSCP priority mapping table based on DSCP priorities of
packets to re-mark 802.1p priorities or DSCP priorities of the packets or map DSCP
priorities of the packets to drop priorities.
l IP priority

The system searches the IP priority mapping table based on IP priorities of packets to re-
mark 802.1p priorities or IP priorities of the packets.
NOTE
The S5720SI, S5720S-SI, and S5710-X-LI do not support trusting the IP priority.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
trust { 8021p | dscp | ip-precedence }
The packet priority trusted on the interface is specified.

By default, no packet priority is trusted on an interface. All packets enter queue 0 and are
assigned 802.1p priority 0.
NOTE
The S5720SI, S5720S-SI, and S5710-X-LI do not support the ip-precedence parameter.
----End
4.5.2 (Optional) Configuring an Interface Priority

Context
An interface's priority is used in the following scenarios:
l When the interface receives untagged VLAN packets, the device forwards the packets
based on the interface priority.
l If the interface is configured to trust 802.1p priorities, the device uses the interface
priority as the 802.1p priority for the untagged packets received on the interface, and
then searches the 802.1p priority mapping table to determine the queue for the untagged
packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

port priority priority-value
The interface priority is set.
By default, the interface priority is 0.
----End
4.5.3 Configuring the Mappings Between DSCP Priorities and

Other Priorities
Context
The device performs priority mapping based on packet priorities. The mappings between
priorities can be configured in the priority mapping table. The device can map DSCP
priorities to 802.1p priorities, drop priorities, or new DSCP priorities.
Procedure
Step 1 Run:
system-view
Step 2 Run:
qos map-table { dscp-dot1p | dscp-dp | dscp-dscp }
The DSCP mapping table view is displayed.
NOTE
l The DSCP priority mapping and IP priority mapping tables cannot be used together. When you configure
DSCP priority mapping after IP priority mapping has been configured, the system displays the message
"Error: Configuration conflicts with IP precedence map-table."
l In a version earlier than V200R007, DSCP priority mapping and IP priority mapping can be configured
simultaneously. When the system software is upgraded to V200R007 or a later version, both DSCP
priority mapping and IP priority mapping tables can be restored, but only the DSCP priority mapping
table takes effect. To modify the DSCP priority mapping table, run the undo input command in the IP
priority mapping table view to delete the IP priority mapping table configuration first.
Step 3 Run:
input { input-value1 [ to input-value2 ] &<1-10> } output output-value
Mappings are configured in the DSCP priority mapping table.
----End
4.5.4 Configuring the Mappings Between IP Precedences and

Other Priorities
Context
The device performs priority mapping based on packet priorities. The mappings between
priorities can be configured in the priority mapping table. The device can map IP priorities to
802.1p priorities or new IP priorities.

NOTE
The S5720SI, S5720S-SI, and S5710-X-LI do not support configuring mappings from IP priorities to
802.1p priorities or new IP priorities.
Procedure
Step 1 Run:
system-view

Step 2 Run:
qos map-table { ip-pre-dot1p | ip-pre-ip-pre }
The IP priority mapping table view is displayed.
NOTE
l The DSCP priority mapping and IP priority mapping tables cannot be used together. When you configure
an IP priority mapping table on a device where a DSCP priority mapping has been configured, the system
displays a message "Error: Configuration conflicts with DSCP map-table."
l In a version earlier than V200R007, DSCP priority mapping and IP priority mapping can be configured
simultaneously. When the system software is upgraded to V200R007 or a later version, both DSCP
priority mapping and IP priority mapping can be restored, but only the DSCP priority mapping table takes
effect. To modify the IP priority mapping table, run the undo input command in the DSCP priority
mapping table view to delete the DSCP priority mapping table configuration first.
Step 3 Run:
input input-value1 [ to input-value2 ] output output-value
The mapping in the IP precedence mapping table is configured.
----End
4.5.5 (Optional) Configuring the Mappings Between Local

Precedences and Queues
Context
By configuring the mappings between local priorities and queues, the device sends packets to
the specified queue based on the mappings between local priorities and queues.
NOTE
The S5720HI does not support the mapping between local priorities and queues.
Procedure
Step 1 Run:
system-view

Step 2 Run:
qos local-precedence-queue-map local-precedence queue-index
The mapping between local priorities and queues is configured.

The mappings between local priorities and queues take effect only on the inbound interface.
That is, traffic enters queues based on the mappings.
----End
Procedure
l Run the display qos map-table [ dscp-dot1p | dscp-dp | dscp-dscp | ip-pre-dot1p | ip-
pre-ip-pre ] command to check the mapping between priorities.
l Run the display qos local-precedence-queue-map command to check the mapping
between local priorities and queues.
----End
Background
Priority re-marking is a method of changing priority fields of the packets that match certain
traffic classification rules. For example, you can configure priority mapping to change the
802.1p priority of VLAN packets or DSCP priority and local priority of IP packets.
Procedure
a. Run:
system-view

b. Run:
traffic classifier classifier-name [ operator
A traffic classifier is created and the traffic classifier view is displayed, or the view
of an existing traffic classifier is displayed.
that:
they match any one of rules in the classifier.
By default, the logical operator used between rules in a traffic classifier is AND.


Rule

VLAN ID end-vlan-id ]
802.1p if-match 8021p 8021p-value If you enter multiple 8021p

priority in &<1-8> priority values in the
VLAN command, packets match the
packets traffic classifier as long as
they match one 8021p

address

address

encapsulat
ed in the
Ethernet
frame
header
All if-match any -

packets

priority in DSCP priority values in
IP packets the command, packets
match the traffic classifier
as long as they match one
DSCP priority, regardless
of whether the
AND or OR.
simultaneously.


Rule
IP if-match ip-precedence ip- l If the relationship

precedence precedence-value &<1-8> between rules in a traffic
in IP classifier is AND, the if-
packets match dscp and if-match
simultaneously.
priority values in the
command, packets match
the traffic classifier as
long as they match one IP
between rules in the
traffic classifier is AND
or OR.

protocol
type

packet urg }
header

interface interface-type interface-number such a matching rule cannot
be applied to the outbound
direction.
view.
ACL rule if-match acl { acl-number | acl- If an ACL used in a traffic

name } classifier has multiple rules,
NOTE packets match the ACL as
To use an ACL in a traffic classifier, long as they match any one of
you are advised to configure rules in rules in the ACL, regardless
the ACL first. of whether the relationship


Rule
ACL6 rule if-match ipv6 acl { acl-number | -

acl-name }
NOTE
To use an ACL6 in a traffic classifier,
you are advised to configure rules in
the ACL6 first.
d. Run:
quit

a. Run:
A traffic behavior is created and the traffic behavior view is displayed.

b. Run the following commands as required:
n To re-mark the 802.1p priority field of packets matching the traffic classifier,
run remark 8021p 8021p-value.
NOTE
If a traffic policy containing remark 8021p is applied to the outbound direction on an

interface, the VLAN of the outbound interface must work in tagged mode.
n To re-mark the DSCP priority field of packets matching the traffic classifier,
run remark dscp { dscp-name | dscp-value }.
n To re-mark the local priority field of packets matching the traffic classifier, run
remark local-precedence { local-precedence-name | local-precedence-
value }.
n To re-mark the IP precedence field of packets matching the traffic classifier,
run remark ip-precedence ip-precedence.
c. Run:
quit

a. Run:
existing traffic policy is displayed.
b. Run:
A traffic behavior is bound to a traffic classifier in the traffic policy.

c. Run:
quit



i. Run:

ii. Run:
A traffic policy is applied to the interface.

interface.
NOTE
It is not recommended to use the traffic policy containing remark 8021p and remark
vlan-id in the outbound direction of an untagged interface. This configuration may
cause incorrect information in the packets.
i. Run:
vlan vlan-id

ii. Run:

direction.
NOTE
i. Run:
id ]

simultaneously.

switch.

[ vlan-id ] ] { inbound | outbound } [ verbose ] command to check traffic actions and
ACL rules applied to the system, a VLAN, or an interface.
l Run the display traffic policy { interface [ interface-type interface-number ] | vlan
[ vlan-id ] | global } [ inbound | outbound ] command to check the traffic policy
configuration.
4.7.1 Example for Configuring Priority Mapping

As shown in Figure 4-4, SwitchA and SwitchB are connected to the router, and enterprise
branches 1 and 2 can access the network through LSW1 and LSW2. Enterprise branch 1
requires better QoS guarantee, so DSCP priorities of data packets from enterprise branches 1
and 2 are mapped to 45 and 30 respectively. The Switch trusts DSCP priorities of packets.
When congestion occurs, the Switch first processes packets of higher DSCP priority.

Figure 4-4 Networking diagram of priority mapping
Core Network
Router
SwitchA SwitchB
GE0/0/2 GE0/0/2
GE0/0/1 GE0/0/1
LSW1 LSW2
Enterprise Enterprise
Branches 1 Branches 2
VLAN 100 VLAN 200
1. Create VLANs and configure interfaces so that the enterprise can access the network.
2. Configure priority mapping to map DSCP priorities of data packets from enterprise
branches 1 and 2 to 45 and 30 respectively.
Procedure
Step 1 Configure SwitchA.
# Create VLAN 100.
[HUAWEI] sysname SwitchA
[SwitchA] vlan batch 100
# Set the link type of GE 0/0/1 and GE 0/0/2 to trunk and add them to VLAN 100.
[SwitchA] interface gigabitethernet 0/0/1
[SwitchA-GigabitEthernet0/0/1] port link-type trunk
[SwitchA-GigabitEthernet0/0/1] port trunk allow-pass vlan 100
[SwitchA-GigabitEthernet0/0/1] quit
# Configure interfaces to trust DSCP priorities of packets.

[SwitchA-GigabitEthernet0/0/1] trust dscp

[SwitchA-GigabitEthernet0/0/2] trust dscp
# Configure priority mapping.

[SwitchA] qos map-table dscp-dscp
[SwitchA-dscp-dscp] input 0 to 63 output 45
[SwitchA-dscp-dscp] quit
Step 2 Configure SwitchB.

# Create VLAN 200.
[HUAWEI] sysname SwitchB
[SwitchB] vlan batch 200
# Set the link type of GE 0/0/1 and GE 0/0/2 to trunk and add them to VLAN 200.
[SwitchB] interface gigabitethernet 0/0/1
[SwitchB-GigabitEthernet0/0/1] port link-type trunk
[SwitchB-GigabitEthernet0/0/1] port trunk allow-pass vlan 200
[SwitchB-GigabitEthernet0/0/1] quit
# Configure interfaces to trust DSCP priorities of packets.

[SwitchB-GigabitEthernet0/0/1] trust dscp
[SwitchB-GigabitEthernet0/0/2] trust dscp
# Configure priority mapping.

[SwitchB] qos map-table dscp-dscp
[SwitchB-dscp-dscp] input 0 to 63 output 30
[SwitchB-dscp-dscp] quit
Step 3 Verify the configuration.

# View priority mapping information on SwitchA.
[SwitchA] display qos map-table dscp-dscp
Input DSCP DSCP
------------------------
0 45
1 45
2 45
3 45
4 45
......
63 45
# View the interface configuration on SwitchA.

[SwitchA-GigabitEthernet0/0/1] display this
#
trust dscp
#

return
[SwitchA-GigabitEthernet0/0/2] display this
#
trust dscp
#
return
# View priority mapping information on SwitchB.

[SwitchB] display qos map-table dscp-dscp
Input DSCP DSCP
------------------------
0 30
1 30
2 30
3 30
4 30
......
63 30
# View the interface configuration on SwitchB.

[SwitchB-GigabitEthernet0/0/1] display this
#
trust dscp
#
return
[SwitchB-GigabitEthernet0/0/2] display this
#
trust dscp
#
return
----End
Configuration Files
l SwitchA configuration file
#
sysname SwitchA
#
vlan batch 100
#
trust dscp
#
trust dscp
#
qos map-table dscp-dscp
input 0 to 44 output 45

#
return
l SwitchB configuration file

#
sysname SwitchB
#
vlan batch 200
#
trust dscp
#
trust dscp
#
qos map-table dscp-dscp
#
return
4.8.1 Packets Enter Incorrect Queues
Common Causes
l The priority type of packets is different from the priority type trusted by the inbound
interface.
l Priority mapping in the priority mapping table is incorrect.
l There are configurations affecting the queues that packets enter on the inbound interface,
including:
l There are configurations affecting the queues that packets enter in the VLAN to which
the packets belong.
l There are configurations affecting the queues that packets enter in the system.
Procedure
Step 1 Check that the priority type of packets is the same as the priority type trusted by the inbound
interface.
Run the display this command in the inbound interface view to check the configuration of the
trust command on the inbound interface (if the trust command is not used, the system does
not trust any priority by default). Then obtain the packet header on the inbound interface, and
check whether the priority type is the same as the priority type trusted by the inbound
interface.
l If not, run the trust command to modify the priority type trusted by the inbound
interface to be the same as the priority type of the captured packets.

The router sends packets to queues based on the internal priority; therefore, check the
mappings between DSCP or 802.1p priorities trusted by the interface and internal priorities.
Enter the priority mapping table view and run the display this command to check whether
priority mapping is configured correctly.
l If priority mapping is configured incorrectly, run the qos map-table command to enter
the priority mapping table view, and then run the input (DSCP priority mapping table
view) or input (IP priority mapping table view) command to configure priority mapping
correctly.
NOTE
The S5720SI, S5720S-SI, S5710-X-LI do not support mappings from IP priorities to 802.1p
priorities or IP priorities, so the input (IP priority mapping table view) command, and the ip-pre-
dot1p and ip-pre-ip-pre parameters in the qos map-table command are not supported.
Step 3 Check whether there are configurations affecting the queues that packets enter on the inbound
interface.
The following configurations affect the queues that packets enter on the inbound interface:
l If the port vlan-stacking command is configured with remark-8021p specified,
priorities of packets are re-marked. The mapping between 802.1p priorities and local
priorities may be incorrect and queues may enter incorrect queues.
l If the port vlan-mapping vlan inner-vlan or port vlan-mapping vlan map-vlan
command is configured with remark 8021p specified, priorities of packets are re-
marked. The mapping between 802.1p priorities and local priorities may be incorrect and
queues may enter incorrect queues.
l If the traffic-policy command is configured with remark local-precedence specified,
the system sends packets to queues based on the re-marked priorities.
l If the traffic-policy command that defines remark 8021p, remark ip-precedence, or
remark dscpis used, the system maps the re-marked priorities of packets to 802.1p
priorities and sends the packets to queues based on the mapped priorities.
l If the port link-type dot1q-tunnel command is configured, all the packets reaching the
interface enter queues based on the default 802.1p priority of the interface. The default
802.1p priority of an interface is set by using the port priority command. The default
802.1p priority of an interface is 0.
Run the display this command in the inbound interface view to check whether there are
configurations affecting packets queuing on the inbound interface.

Step 4 Check whether there are configurations affecting the queues that packets enter in the VLAN
that the inbound interface of the packets belongs to.
The following configurations affect the queues that packets enter:
l If the traffic-policy command where remark local-precedence is defined is used, the
system sends packets to queues based on the re-marked priorities.


remark dscpis used, the system maps the re-marked priorities of packets to 802.1p
priorities and sends the packets to queues based on the mapped priorities.
Run the display this command in the view of the VLAN that the inbound interface of the
packets belongs to and check whether there are configurations affecting the queues that
packets enter in the VLAN.
Step 5 Check whether there are configurations affecting the queues that packets enter in the system.
The following configurations affect the queues that packets enter:

l If the qos local-precedence-queue-map command is configured the system sends
packets to queues based on the mapping between local priorities and queues specified by
this command.
l If the traffic-policy global command that defines remark local-precedence is used, the
system sends packets to queues based on the re-marked priority.
l If the traffic-policy global command that defines remark 8021p, remark ip-
precedence, or remark dscpis used, the system maps the re-marked priorities of packets
to 802.1p priorities and sends the packets to queues based on the mapped priorities.
Run the display current-configuration command to check whether there are configurations
affecting the queues that packets enter in the system. If so, delete or modify the configuration.
NOTE
If the packets match traffic classifiers in two or all traffic policies applied to an interface, a VLAN, and
the system, the traffic policies applied to the interface, VLAN, and system take effect in descending
order of priorities.
----End
4.8.2 Priority Mapping Results Are Incorrect
Common Causes
l On the inbound interface, packets do not enter queues corresponding to the priority of
packets.
l The type of the priority trusted by the inbound interface is incorrect.
l Priority mapping in the priority mapping table is incorrect.
l There are configurations affecting priority mapping on the inbound or outbound
interface.
Procedure
Step 1 Check that packets enter the correct queues on the inbound interface.
Run the display qos queue statistics command to check whether packets enter the correct
queues on the inbound interface.
l If not, locate the fault according to 4.8.1 Packets Enter Incorrect Queues.

Step 2 Check that the priority type trusted by the inbound interface is correct.
Run the display this command in the view of the inbound interface to check whether the
trusted priority type set by using the trust command on the inbound interface is correct. (If
the trust command is not used, the system does not trust any priority by default.)
l If not, run the trust command to correctly configure the priority type trusted by the
inbound interface.
Enter the priority mapping table view and run the display this command to check whether
priority mapping is configured correctly.
l If priority mapping is configured incorrectly, run the qos map-table command to enter
the priority mapping table view and the input (DSCP priority mapping table view) or
input (IP priority mapping table view) command to configure priority mapping correctly.
NOTE
The S5720SI, S5720S-SI, and S5710-X-LI do not support mapping from IP priorities to 802.1p
priorities or IP priorities, so the input (IP mapping table view) command, and the ip-pre-dot1p and ip-
pre-ip-pre parameters in the qos map-table command are not supported.
Step 4 Check whether there are configurations affecting priority mapping on the inbound or
outbound interface.
The following configurations affect priority mapping on the inbound or outbound interface:
remark dscp is used on the inbound or outbound interface, the re-marked priority is the
packet priority.
Run the display this command in the view of the inbound or outbound interface to check
whether there are configurations affecting priority mapping. If so, delete or modify the
configuration.
----End
4.9 FAQ
4.9.1 Which Priority Does an Interface Trust?

The S3700, S5700, or S6700 interface can be configured to trust DSCP priorities and 802.1p
priorities simultaneously, or trust IP precedences and 802.1p priorities simultaneously. When
an interface is configured to trust DSCP priorities and 802.1p priorities simultaneously, or
trust IP precedences and 802.1p priorities simultaneously, the interface:
l Trusts DSCP priorities or IP priorities if L3 packets are received.
l Trusts 802.1p priorities if L2 packets are received.
NOTE
The DSCP priority and IP precedence use different bits of the ToS field; therefore, an interface cannot be
configured to trust DSCP priorities and IP precedences simultaneously.
The S5720SI, S5720S-SI, and S5710-X-LI do not support the trust ip-precedence command.

4.10 References

Headers

Services

S2750&S5700&S6720 Series Ethernet Switches 5 Traffic Policing, Traffic Shaping, and Interface-based
Configuration Guide - QoS Rate Limiting
5 Traffic Policing, Traffic Shaping, and

Interface-based Rate Limiting
About This Chapter
This chapter describes how to configure traffic policing, traffic shaping, and interface-based
rate limiting.
5.1 Overview
5.2 Principles
This section describes the principles behind the token bucket, traffic measurement, traffic
policing, traffic shaping, and interface-based rate limiting mechanisms.
5.3 Applications
5.6 Configuring Traffic Policing
5.7 Configuring Traffic Shaping
5.8 Configuring Interface-based Rate Limiting
5.9 Maintaining Traffic Policing, Traffic Shaping, and Interface-based Rate Limiting
5.11 FAQ
5.12 References

5.1 Overview
Traffic policing, traffic shaping, and interface-based rate limiting can control the traffic rate to
improve network resource utilization and provide better services.
Network congestion may occur when the transmit rate is higher than the receive rate or the
interface rate on a downstream device is lower than the interface rate on an upstream device.
If rates of traffic sent from users are not limited, continuous burst traffic from many users will
worsen network congestion. To deliver better services to users leveraging limited network
resources, user traffic rates must be limited.
Traffic policing, traffic shaping, and interface-based rate limiting are mechanisms to monitor
and control traffic rates and resource usage.
Traffic Policing
Traffic policing monitors rates of traffic entering a network and discards excess traffic to
control incoming traffic rates within a specified range, thereby conserving network resources
and protecting user interests.
Traffic Shaping
Traffic shaping adjusts the traffic rates to enable traffic to be transmitted at an even rate,
preventing congestion on the downstream device.

Interface-based rate limiting controls the total rate of all packets sent or received on an
interface. This mechanism can simplify configuration when you want to limit the rate of all
traffic on an interface regardless of packet types.
5.2 Principles
This section describes the principles behind the token bucket, traffic measurement, traffic
policing, traffic shaping, and interface-based rate limiting mechanisms.
A network needs to transmit various types of service traffic for different types of users. If
rates of service traffic are not limited on the network, the network will be congested when
many users continuously generate burst traffic. To provide better service for more users with
limited network resources, rates of service traffic must be limited.
Traffic policing, traffic shaping, and interface-based rate limiting control traffic rates and
resource usage by monitoring the rates of incoming traffic entering a network. The incoming
traffic must be measured first so that measures can be taken to limit the traffic rate based on
the measurement result. Generally, the token bucket mechanism is used to measure traffic.
5.2.1 Traffic Metering and Token Bucket Mechanism
Overview
Traffic metering is the prerequisite for implementing traffic policing, traffic shaping, and
interface-based rate limiting to provide better service for more users with limited network

resources. Network devices determine whether the incoming traffic rate exceeds the limit and
take measures based on the metering result. Generally, the token bucket mechanism is used to
measure traffic.
A token bucket is a container that can store a certain number of tokens. The system places
tokens into a token bucket at the configured rate. If the token bucket is full, excess tokens
overflow and the number of tokens in the bucket can no longer increase. The system
determines whether there are enough tokens in the bucket for packet forwarding. If so, the
traffic rate conforms to the rate limit. Otherwise, the traffic rate exceeds or violates the rate
limit.
RFC standards define the following token bucket algorithms:

l The single rate three color marker (srTCM) algorithm determines traffic bursts based on
packet lengths.
l The two rate three color marker (trTCM) algorithm determines traffic bursts based on
packet rates.
The token bucket algorithms mark packets red, yellow, or green based on traffic metering
results. Then the system processes packets based on their colors. The two algorithms can
work in color-aware and color-blind modes. The color-blind mode is used as an example in
the following descriptions.
Single-Rate-Two-Bucket Mechanism
The single-rate-two-bucket mechanism uses the srTCM algorithm defined in RFC 2697 to
measure traffic and marks packets green, yellow, or red based on the metering result.
As shown in Figure 5-1 buckets C and E contain Tc and Te tokens respectively. The single-
rate-two-bucket mechanism uses three parameters:
l Committed information rate (CIR): indicates the rate at which tokens are put into bucket
C, that is, the average traffic rate that bucket C allows.
l Committed burst size (CBS): indicates the capacity of bucket C, that is, the maximum
volume of burst traffic that bucket C allows.
l Excess burst size (EBS): indicates the capacity of bucket E, that is, the maximum volume
of excess burst traffic that bucket E allows.
The system places tokens into bucket C at the CIR:

l If Tc is less than the CBS, Tc increases.
l If Tc is equal to the CBS and Te is less than the EBS, Te increases.
l If Tc is equal to the CBS and Te is equal to the EBS, Tc and Te do not increase.
B indicates the size of an arriving packet:

l If B is less than or equal to Tc, the packet is marked green, and Tc decreases by B.
l If B is greater than Tc and less than or equal to Te, the packet is marked yellow and Te
decreases by B.
l If B is greater than Te, the packet is marked red, and Tc and Te remain unchanged.
The single-rate-two-bucket mechanism allows burst traffic. When the traffic rate is lower than
the CIR, packets are marked green. When the burst traffic volume is greater than the CBS and
lower than the EBS, packets are marked yellow. When the burst traffic volume is greater than
the EBS, packets are marked red.

Figure 5-1 Single-rate-two-bucket mechanism

Tokens
CIR
Overflow
CBS EBS
NO NO
B≦Tc B≦Te
YES YES
Packets（B）
Conform Exceed Violate
This example uses the CIR of 1 Mbit/s and the CBS and EBS both of 2000 bytes. Buckets C
and E are initially full of tokens. In single-rate-two-bucket mode, the token buckets process
packets as follows:
NOTE
Here, 1 Mbit/s is calculated by 1x106bit/s.

l If the first packet arriving at the interface is 1500 bytes long, the packet is marked green
because the number of tokens in both buckets P and C is greater than the packet length.
The number of tokens in bucket C then decreases by 1500 bytes, with 500 bytes
remaining. The number of tokens in bucket E remains unchanged.
l Assume that the second packet arriving at the interface after a delay of 1 ms is 1500
bytes long. Additional 125-byte tokens are put into bucket C (CIR x time period = 1
Mbit/s x 1 ms = 1000 bits = 125 bytes). Bucket C now has 625-byte tokens, which are
not enough for the 1500-byte second packet. Bucket E has 2000-byte tokens, which are
enough for the second packet. Therefore, the second packet is marked yellow, and the
number of tokens in bucket E decreases by 1500 bytes, with 500 bytes remaining. The
number of tokens in bucket C remains unchanged.
l Assume that the third packet arriving at the interface after a delay of 1 ms is 1000 bytes
long. Additional 125-byte tokens are put into bucket C. Bucket C now has 750-byte
tokens, which are not enough for the 1000-byte third packet. Tokens in bucket E are
insufficient, so the third packet is marked red. The numbers of tokens in buckets C and E
remain unchanged.
l Assume that the fourth packet arriving at the interface after a delay of 20 ms is 1500

Mbit/s x 20 ms = 20000 bits = 2500 bytes). Bucket C now has 3250-byte tokens. The
excess 1250-byte tokens over the CBS (2000 bytes) are put into bucket E, so bucket E
has 1750-byte tokens. The packet is marked yellow because the number of tokens in
bucket C is greater than the packet length. The number of tokens in bucket C decreases
by 1500 bytes, with 500 bytes remaining. The number of tokens in bucket E remains
unchanged.
Table 5-1 describes the packet processing.
Table 5-1 Packet processing in single-rate-two-bucket mode

Number of Number of
Packe Toke Tokens Tokens After
t n Before Packet Packet
Time Lengt Delay Addit Processing Processing Mark
No.
(ms) h (ms) ion (Bytes) (Bytes) ing
(Byte (Byte
s) s) Buck Buck Buck Buck
et C et E et C et E
- - - - - 2000 2000 2000 2000 -
1 0 1500 0 0 2000 2000 500 2000 Green
2 1 1500 1 125 625 2000 625 500 Yello

w
3 2 1000 1 125 750 500 750 500 Red
4 22 1500 20 2500 2000 1750 500 1750 Green
Single-Rate-Single-Bucket Mechanism
If burst traffic is not allowed, the EBS must be set to 0 in the single-rate-two-bucket system.
In this case, only one token bucket is used because there are always 0 tokens in bucket E.
As shown in Figure 5-2, bucket C contains Tc tokens. The single-rate-single-bucket

mechanism uses two parameters:
l CIR: indicates the rate at which tokens are put into bucket C, that is, the average traffic
rate that bucket C allows.
l CBS: indicates the capacity of bucket C, that is, the maximum volume of burst traffic
that bucket C allows.
The system places tokens into the bucket at the CIR. If Tc is less than the CBS, Tc increases.
If Tc is less than or equal to the CBS, Tc remains unchanged.

l If B is less than or equal to Tc, the packet is marked green, and Tc decreases by B.
l If B is greater than Tc, the packet is marked red, and Tc remains unchanged.
The single-rate-single-bucket mechanism does not allow burst traffic. When the traffic rate is
lower than the CIR, packets are marked green. When the traffic rate is higher than the CIR,
packets are marked red.

Figure 5-2 Single-rate-single-bucket mechanism
Tokens
CIR
CBS
NO
B≦Tc
YES
Packets（B） Violate
Conform
This example uses the CIR of 1 Mbit/s and the CBS of 2000 bytes. Bucket C is initially full of
tokens. In single-rate-single-bucket mode, the token buckets process packets as follows:
NOTE

l If the first arriving packet is 1500 bytes long, the packet is marked green because the
number of tokens in bucket C is greater than the packet length. The number of tokens in
bucket C then decreases by 1500 bytes, with 500 bytes remaining.
Mbit/s x 1 ms = 1000 bits = 125 bytes). Bucket C now has 625-byte tokens. Tokens in
bucket C are insufficient, so the second packet is marked red.
long. Additional 125-byte tokens are put into bucket C. Bucket C now has 750-byte
tokens. Tokens in bucket C are insufficient, so the third packet is marked red.
Mbit/s x 20 ms = 20000 bits = 2500 bytes). Bucket C now has 3250-byte tokens. The
excess 1250-byte tokens over the CBS (2000 bytes) are dropped. The packet is marked
green because the number of tokens in bucket C is greater than the packet length. The
number of tokens in bucket C decreases by 1500 bytes, with 500 bytes remaining.

Table 5-2 Packet processing in single-rate-single-bucket mode

No. Time Packet Delay Token Numbe Numbe Markin
(ms) Length (ms) Additio r of r of g
(Bytes) n Tokens Tokens
(Bytes) Before After
Packet Packet
Process Process
ing ing
(Bytes) (Bytes)
- - - - - 2000 2000 -
1 0 1500 0 0 2000 500 Green
2 1 1500 1 125 625 625 Red
3 2 1000 1 125 750 750 Red
4 22 1500 20 2500 2000 500 Green
Two-Rate-Two-Bucket Mechanism
The two-rate-two-bucket mechanism uses the trTCM algorithm defined in RFC 2698 to
measure traffic and marks packets green, yellow, or red based on the metering result.
As shown in Figure 5-3, buckets P and C contain Tp and Tc tokens respectively. Two-rate-
two-bucket mechanism uses four parameters:
l Peak information rate (PIR): indicates the rate at which tokens are put into bucket P, that
is, the maximum traffic rate that bucket P allows. The PIR is greater than the CIR.
l CIR: indicates the rate at which tokens are put into bucket C, that is, the average traffic
rate that bucket C allows.
l Peak burst size (PBS): indicates the capacity of bucket P, that is, the maximum volume
of burst traffic that bucket P allows.
l CBS: indicates the capacity of bucket C, that is, the maximum volume of burst traffic
that bucket C allows.
The system places tokens into bucket P at the PIR and places tokens into bucket C at the CIR:
l If Tp is less than the PBS, Tp increases. If Tp is greater than or equal to the PBS, Tp
remains unchanged.
l If Tc is less than the CBS, Tc increases. If Tc is greater than or equal to the CBS, Tp
remains unchanged.

l If B is greater than Tp, the packet is marked red.
l If B is greater than Tc and less than or equal to Tp, the packet is marked yellow and Tp
decreases by B.
l If B is less than or equal to Tc, the packet is marked green, and Tp and Tc decrease by B.
The two-rate-two-bucket mechanism allows burst traffic rates. When the traffic rate is lower
than the CIR, packets are marked green. When the traffic rate is higher than the CIR and less

than the PIR, packets are marked yellow. When the traffic rate is higher than the PIR, packets
are marked red.
Figure 5-3 Two-rate-two-bucket mechanism

Tokens Tokens
PIR CIR
PBS CBS
NO NO
B>Tp B>Tc
YES YES
Packets（B）
Violate Exceed Conform
This example uses the CIR of 1 Mbit/s, the PIR of 2 Mbit/s, the CBS of 2000 bytes, and the
PBS of 3000 bytes. Buckets C and P are initially full of tokens. In two-rate-two-bucket mode,
the token buckets process packets as follows:
NOTE

l If the first packet arriving at the interface is 1500 bytes long, the packet is marked green
because the numbers of tokens in both buckets P and C are greater than the packet
length. Then the numbers of tokens in both buckets P and C decrease by 1500 bytes,
with 500 and 1500 bytes remaining in bucket C and bucket P respectively.
bytes long. Additional 250-byte tokens are put into bucket P (PIR x time period = 2
Mbit/s x 1 ms = 2000 bits = 125 bytes). Bucket P now has 1750-byte tokens, and is
smaller than the packet length. Additional 125-byte tokens are put into bucket C (CIR x
time period = 1 Mbit/s x 1 ms = 1000 bits = 125 bytes). Bucket C now has 625-byte
tokens. Therefore, the second packet is marked red, and the numbers of tokens in buckets
P and C remain unchanged.
long. Additional 250-byte tokens are put into bucket P. Bucket P now has 2000-byte
tokens, and is larger than the packet length. Additional 250-byte tokens are put into
bucket C. Bucket C now has 750-byte tokens, and is still smaller than the packet length.

The packet is marked yellow. The number of tokens in bucket P decreases by 1000 bytes,
with 1000 bytes remaining. The number of tokens in bucket C remains unchanged.
bytes long. Additional 5000-byte tokens are put into bucket P (PIR x time period = 2
Mbit/s x 20 ms = 40000 bits = 5000 bytes), but excess tokens over the PBS (3000 bytes)
are dropped. Bucket P has 2000-byte tokens, which are enough for the 1500-byte fourth
packet. Additional 2500-byte tokens are put into bucket C (CIR x time period = 1 Mbit/s
x 20 ms = 2000 bits = 250 bytes), but excess tokens over the CBS (2000 bytes) are
dropped. Bucket C then has 2000-byte tokens, which are enough for the 1500-byte fourth
packet. Therefore, the fourth packet is marked green. The number of tokens in bucket P
decreases by 1500 bytes, with 1500 bytes remaining. The number of tokens in bucket C
decreases by 1500 bytes, with 500 bytes remaining.
Table 5-3 Packet processing in two-rate-two-bucket mode
Number of Number of
Pack Tokens Tokens
Token
et Before After Packet
Dela Addition
Time Leng Packet Processing Mar
No. y (Bytes)
(ms) th Processing (Bytes) king
(ms) (Bytes)
(Byte
s) Buck Buck Buck Buck Buck Buck
et C et P et C et P et C et P
- - - - - - 2000 3000 2000 3000 -
1 0 1500 0 0 0 2000 3000 500 1500 Gree

n
2 1 1800 1 125 250 625 1750 625 1750 Red
3 2 1000 1 125 250 750 2000 750 1000 Yello

w
4 22 1500 20 2500 5000 2000 3000 500 1500 Gree

n
Difference and Application of Three Token Bucket Modes

Table 5-4 describes the difference and relationship of three token bucket modes.
Table 5-4 Difference and relationship of three token bucket modes
Difference Single-Rate- Single-Rate-Two- Two-Rate-Two-

Single-Bucket Bucket Bucket
Parameters CIR and CBS CIR, CBS, and EBS CIR, CBS, PIR, and
PBS

Difference Single-Rate- Single-Rate-Two- Two-Rate-Two-

Single-Bucket Bucket Bucket
Mode in which Tokens are put into When bucket C is Tokens are put into
tokens are placed bucket C at the CIR. full, tokens are put bucket C at the CIR
Excess tokens are into bucket E. When and tokens are put
dropped when buck buckets C and E are into bucket P at the
C is full. not full, tokens are PIR. Buckets C and
put into bucket C P are independent.
only. Excess tokens are
dropped when
tokens in buckets C
and P are full.
Whether traffic burst Traffic burst is not Traffic burst is Traffic burst is
is allowed allowed. Packet allowed. Tokens in allowed. When
processing depends bucket C are first buckets C and P
on whether bucket C used. When tokens have sufficient
has enough tokens. in bucket C are tokens, tokens in
insufficient, tokens both buckets C and
in bucket E are used. P are used. When
tokens in bucket C
are insufficient,
tokens in bucket P
are used only.
Marking result Green or red Green, yellow, or Green, yellow, or

red red
Relationship In single-rate-two-bucket mode, if the EBS is 0, the effect is the

same as that in single-rate-single-bucket mode.
In two-rate-two-bucket mode, if the PIR is equal to the CIR, the
effect is the same as that in single-rate-single-bucket mode.
Table 5-5 describes the functions and scenarios of three token bucket modes.
Table 5-5 Functions and scenarios of three token bucket modes

Token Bucket Mode Function Usage Scenario
Single-rate-single-bucket Limits bandwidth. Discards low-priority

services such as extranet
HTTP traffic, and excess
traffic.
Single-rate-two-bucket Limits bandwidth, allows Reserves bandwidth for

certain traffic burst, and important services or burst
distinguishes burst and traffic (for example, email
normal services. data).

Token Bucket Mode Function Usage Scenario
Two-rate-two-bucket Limits bandwidth, allocates Is recommended for

bandwidth, and determines important services because
whether the bandwidth is it better monitors burst
less than the CIR or is in the traffic and guides traffic
range of the CIR and PIR. analysis.
Color-Aware Mode
In color-aware mode, if an arriving packet has been marked red, yellow, or green, the packet
color affects metering results of the token bucket mechanism in the following ways:
l If the packet has been marked green, the metering mechanism is the same as that in
color-blind mode.
l If the packet has been marked yellow, the systems marks the packet yellow if it conforms
to the limit and marks the packet red if it violates the limit, depending on the packet
length and the number of tokens. In the single-rate-single-bucket system, the packet is
marked red directly.
l If the packet has been marked red, it is marked red in the token bucket.
5.2.2 Traffic Policing
Traffic policing controls the rate of traffic entering a network within a specified range by
metering traffic and taking punitive action on excess traffic. This feature protects network
resources and interests of the enterprise users.
Implementation of Traffic Policing
Figure 5-4 Traffic policing components
Result
Packet Packet
Meter Marker Action
Stream Stream
As shown in Figure 5-4, traffic policing involves the following components:
l Meter: uses the token bucket mechanism to measure network traffic and sends the result
to the marker.
l Marker: colors packets green, yellow, or red based on the measurement result received
from the meter.
l Action: performs actions based on packet colors. The following actions are defined:
– Pass: forwards the packets that conform to the limit.

– Re-mark + pass: changes the local priorities of those packets that exceed the limit
and forwards the packets.
– Discard: drops the packets that exceed the limit.
If the rate of a packet stream exceeds the limit, the system lowers the priority of extra packets
in the stream before forwarding them or discards the packets. By default, the system forwards
green and yellow packets, and discards red packets.
5.2.3 Traffic Shaping
Traffic shaping adjusts the rate of outgoing traffic to reduce traffic bursts so that outgoing
packets can be transmitted at a stable rate. Traffic shaping uses a buffer and token buckets to
control the traffic rate. When packets are sent at a high speed, the system buffers packets and
then sends these packets evenly under the control of the token buckets.
Process
Traffic shaping is a queue-based traffic control mechanism that limits the rate at which
packets pass through an interface.
Figure 5-5 shows an example of the traffic shaping process, using flow-based queue shaping
in single-rate-single-bucket mode.
Figure 5-5 Traffic shaping process

Packets not Packet flow
Queue
requiring queuing
Packet flow
Tokens Adds tokens to bucket
at specified rate
Packets requiring
queuing
Simple Packets within
classification ... ... Token bucket the rate limit
Packets exceeding
the rate limit
Buffer queue
Packets discarded when

the buffer queue is full
The traffic shaping process is as follows:
1. When packets arrive, the system classifies packets and places them into different queues.

2. If a queue is not configured with traffic shaping, packets placed in this queue are
immediately sent. For the queues configured with traffic shaping, the system proceeds to
the next step.
3. The system places tokens in the bucket at the specified rate (CIR):
– If there are sufficient tokens in the bucket, the system sends the packets and
decreases the number of tokens accordingly.
– If tokens in the bucket are insufficient for packet forwarding, the system places the
packets into the buffer queue. If the buffer queue is full, the system discards the
packets.
4. When there are packets in the buffer queue, the system compares the number of packets
with the number of tokens in the token bucket. If there are sufficient tokens, the system
forwards packets until all the packets in the buffer queue are sent.
5.2.4 Interface-based Rate Limiting

Interface-based rate limiting controls the total rate of all packets sent or received on an
interface.
Interface-based rate limiting uses the token bucket mechanism to control traffic rates. If rate
limiting is configured on an interface, all packets passing through this interface must be
processed by the token bucket. If there are enough tokens in the token bucket for packet
forwarding, packets can be sent out from the interface. Otherwise, packets are discarded or
buffered.
Interface-based rate limiting can be configured in the inbound or outbound direction. The
following example describes outbound traffic shaping on an interface.
Process
The following example illustrates the process of outbound traffic shaping on an interface
using the single-rate-single-bucket rate.
Figure 5-6 Interface-based rate limiting

Queue
All packet flows Packet flow
passing through
this interface Put tokens into
Token
the bucket at the
specified rate
... ...
Packets
Token bucket within the
rate limit
Packets exceeding
the rate limit
Buffer queue
Discarded packets when

the buffer queue is full

The interface-based rate limiting process is as follows:

1. If there are sufficient tokens in the bucket, the system sends the packets and decreases
the number of tokens accordingly.
2. If tokens in the bucket are insufficient for packet forwarding, the system places the
packets into the buffer queue. If the buffer queue is full, the system discards the packets.
3. When there are packets in the buffer queue, the system compares the number of packets
with the number of tokens in the token bucket. If there are sufficient tokens, the system
forwards packets until all the packets in the buffer queue are sent.
5.3 Applications
Application of Traffic Policing
As shown in Figure 5-7, voice, video, and data services are transmitted on an enterprise
network. When a large amount of traffic enters the network side, congestion may occur due to
insufficient bandwidth. Different guaranteed bandwidth must be provided for the voice, video,
and data services, listed in descending order of priority. In this situation, traffic policing can
be configured to provide the highest guaranteed bandwidth for voice packets and lowest
guaranteed bandwidth for data packets. This configuration ensures preferential transmission
of voice packets when congestion occurs.
Figure 5-7 Networking of traffic policing
Traffic direction
Voice
Network
Data
Switch
Video Enterprise
campus network
Traffic policing in the inbound direction
Service Deployment
l Configure traffic classifiers to classify voice, video, and data packets.
l Configure traffic behaviors to limit rates of the voice, video, and data packets.
l Associate the traffic classifiers with the traffic behaviors in a traffic policy, and apply the
traffic policy to the inbound direction of an interface.

Application of Traffic Shaping

On an enterprise network, traffic sent to the Internet is discarded if bandwidth is insufficient.
To prevent traffic loss, configure traffic shaping on the outbound interface of the upstream
device to buffer excess traffic. Different traffic shaping rates can be configured for different
branches, as shown in Figure 5-8.
Figure 5-8 Networking of traffic shaping
Traffic direction
Branch 1
Internet
Branch 2 Enterprise campus

network
Priority Mapping in the inbound direction
Traffic shaping in the outbound direction
Service Deployment
l Configure priority mapping for incoming traffic on the interfaces of the switch connected
to the branches. Then packets from different branches are marked with different local
priorities and enter different queues.
l Configure traffic policing on the outbound interface of the switch connected to the egress
gateway to limit rates of traffic from different branches.
Application of Interface-based Rate Limiting

As shown in Figure 5-9, a switch of an enterprise connects to two departments. The rate of
traffic from each department cannot exceed a specified value. Rate limiting can be configured
on the inbound interfaces of the switch to limit the rate of traffic from the two departments.
Excess traffic will be discarded.

Figure 5-9 Networking of interface-based rate limiting
Traffic direction
Department A
Internet
Switch
Department B
Rate limit in the inbound or outbound direction
Service Deployment
l Configure rate limiting on the switch's interfaces connected to departments A and B to
limit the traffic rate of each department within a specified range.

License Support
Traffic policing, traffic shaping, and interface-based rate limiting are basic features of the
switch, and are not under license control.
Version Support
Table 5-6 describes the products and minimum version supporting traffic policing and traffic
shaping.
Table 5-6 Products and minimum version supporting traffic policing and traffic shaping

Required
S1700 S1720GFR V200R006 (The S1720GFR

and V200R008.)


Required

S2710SI Traffic policing: V100R006

Traffic shaping: not
supported
NOTE
The S2710SI is unavailable in
V200R001 and later versions.

and V200R008.)
S2750EI V200R003
S3700 S3700SI V100R006 (The S3700SI is



S5700 S5700LI/S5700S-LI V200R001
S5710-C-LI V200R001 (The S5710-C-

V200R002 and later
versions.)
S5710-X-LI V200R008



S5720EI V200R007
S5720SI/S5720S-SI V200R008


Required


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009
Table 5-7 describes the products and minimum version supporting interface-based rate
limiting.
Table 5-7 Products and minimum version supporting interface-based rate limiting
Required
S1700 S1720GFR V200R006 (The S1720GFR

and V200R008.)
S2700 S2700SI V100R006 (The S2700SI is

NOTE
The S2700SI does not support
interface-base rate limiting in
the inbound direction.


NOTE
The S2710SI does not support
interface-base rate limiting in
the inbound direction.


Required

and V200R008.)
S2750EI V200R003
S3700 S3700SI V100R006 (The S3700SI is



S5700 S5700LI/S5700S-LI V200R001
S5710-C-LI V200R001 (The S5710-C-

V200R002 and later
versions.)
S5710-X-LI V200R008



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006


Required
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

l Table 5-8 describes traffic policing, traffic shaping, and interface-based rate limiting
supported by different switch models.
Table 5-8 Traffic policing, traffic shaping, and interface-based rate limiting supported by
different switch models
Device MQC- Hierarchic Queue- Inbound Outbound
Model based al Traffic based Interface- Interface-
Traffic Policing Traffic based based
Policing Shaping Rate Rate
Limiting Limiting
S1720GFR Supported Not Supported Supported Supported

supported
S2720EI Supported Not Supported Supported Supported

supported
S2750EI Supported Not Supported Supported Supported

supported
S5700LI/ Supported Not Supported Supported Supported

S5700S-LI supported
S5710-X-LI Supported Not Supported Supported Supported

supported
S5720HI Supported Supported Supported Supported Supported
S5720EI Supported Supported Supported Supported Supported
S5720SI/ Supported Not Supported Supported Supported

S5720S-SI supported
S6720EI Supported Supported Supported Supported Supported
S6720S-EI Supported Supported Supported Supported Supported
l To limit the rate of packets from different VLANs, configure rate limiting based on
VLAN IDs. When a traffic policy is applied to a VLAN, the traffic policy is valid for all
interfaces in the VLAN.

l After rate limiting is configured on the device, the Internet access may be slow or packet
loss may occur on the downstream device. The rate limit needs to be set properly.
l Traffic policing, traffic shaping, and interface-based rate limiting are valid only for data
packets and are invalid for protocol packets, so that the device performance is not
affected.
l Traffic suppression in a VLAN, inbound interface-based rate limiting, traffic policy
containing rate limiting, and simplified ACL-based traffic policy containing rate limiting
share CAR resources of the device. When CAR resources are insufficient, some of the
preceding functions may fail to be configured. Run the display acl resource [ slot slot-
id ] command to view the usage of CAR resources.
l The inbound traffic statistics takes effect before interface-based rate limiting. That is,
you cannot check whether interface-based rate limiting takes effect according to the
traffic statistics. Run the display qos statistics interface interface-type interface-number
inbound command on the S5720EI, S5720HI, S6720EI, and S6720S-EI to view traffic
statistics after rate limiting is configured.
l When traffic policing and another flow action are defined in different traffic behaviors of
the same traffic policy and priorities of matching traffic classifiers are different, if
packets match multiple traffic classifiers, only the action corresponding to the high-
priority traffic classifier takes effect. In this case, rate limiting may fail.

Table 5-9 describes the default configuration of traffic policing; Table 5-10 describes the
default configuration of traffic shaping; Table 5-11 describes the default configuration of
interface-based rate limiting.
Table 5-9 Default configuration of traffic policing

Parameter Default Setting
Traffic policing Disabled
Table 5-10 Default configuration of traffic shaping

Traffic shaping Disabled
Table 5-11 Default configuration of interface-based rate limiting

Interface-based rate limiting on a Disabled

service interface
Rate limit on a management 400pps

interface

5.6 Configuring Traffic Policing

Modular QoS Command-Line Interface (MQC) can be used to implement traffic policing that
limits the rate of packets matching configured rules. If the total rate of all traffic also needs to
be limited, configure hierarchical traffic policing after configuring MQC-based traffic
policing.
Before configuring traffic policing on an interface, configure link layer attributes of the
interface to ensure that the interface works properly.
5.6.1 Configuring MQC to Implement Traffic Policing

Context
To control a specific type of traffic in the inbound or outbound direction on an interface,
configure MQC-based traffic policing. MQC-based traffic policing can implement
differentiated services using complex traffic classification. When the receive or transmit rate
of packets matching traffic classification rules exceeds the rate limit, the device discards the
packets.
NOTE
When inbound interface-based rate limiting, VLAN-based broadcast traffic suppression, and inbound
MQC-based traffic policing are configured simultaneously on the S2750, S5700LI, S5700S-LI, S5710-
X-LI, S5720SI, and S5720S-SI, these rules take effect in descending order of priority: inbound
interface-based rate limiting > VLAN-based broadcast traffic suppression > inbound MQC-based
traffic policing. For example, if both inbound interface-based rate limiting and VLAN-based
broadcast traffic suppression are configured, inbound interface-based rate limiting takes effect.
Procedure
a. Run:
system-view

b. Run:
A traffic classifier is created and the traffic classifier view is displayed, or the
existing traffic classifier view is displayed.
that:
they match one of rules in the classifier.


NOTE
The S5720HI does not support traffic classifiers with advanced ACLs containing the ttl-
expired field or user-defined ACLs.
When a traffic classifier contains if-match ipv6 acl { acl-number | acl-name }, the S5720HI
does not support remark 8021p [ 8021p-value | inner-8021p ], remark cvlan-id cvlan-id,
or remark vlan-id vlan-id.

Rule

S5700S-LI, S5710-X-LI, S5720SI,
S5720S-SI)

VLAN IDs id ] (S5720EI, S5720HI, S6720EI)
in QinQ
packets

VLAN command, a packet matches
packets the traffic classifier as long as
it matches any one of the
802.1p priorities, regardless
of whether the relationship

802.1p value &<1-8> (S5720EI, S5720HI,
QinQ
packets

or inner (S5720EI, S5720HI, S6720EI)
and outer
VLAN IDs
of QinQ
packets

packet S5720HI, S6720EI) this matching rule can only
actions.


Rule
Double if-match double-tag (S5720EI, -

tags in S5720HI, S6720EI)
QinQ
packets

address

address

in the
Ethernet
frame
header
All if-match any -

packets

priority in DSCP values in one
IP packets command, a packet
matches the traffic
DSCP values, regardless
of whether the
AND or OR.
cannot be used in the
traffic classifier
simultaneously.


Rule

is AND.
command, a packet
matches the traffic
matches any one of the IP
precedence values,
AND or OR.

protocol
type

packet urg }

interface interface-type interface-number this matching rule cannot be
view.
Outbound if-match outbound-interface A traffic policy containing

(S5720EI, S5720HI, S6720EI) applied to the inbound
direction on the S5720HI.


Rule

name } define a traffic
classification rule, it is
recommended that the
ACL be configured first.
rules, a packet matches
the ACL as long as it
matches one of rules,
AND or OR.
ACL6 rule if-match ipv6 acl { acl-number | Before specifying an ACL6

acl-name } in a matching rule, configure
the ACL6.

traffic policies.
inbound direction.
d. Run:
quit

a. Run:
A traffic behavior is created and the traffic behavior view is displayed, or the view
of an existing traffic behavior is displayed.
b. Run any of the following commands depending on the product model to configure
the CAR action:
n On the S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI,
run:
car [ aggregation ] cir cir-value [ pir pir-value ] [ cbs cbs-value
pbs pbs-value ] [ green pass ] [ yellow { discard | pass [ remark-
dscp dscp-value | remark-8021p 8021p-value ] } ] [ red { discard |
pass [ remark-dscp dscp-value | remark-8021p 8021p-value ] } ]

NOTE
Only the S5710-X-LI, S5720SI, and S5720S-SI support the aggregation parameter.
n On the S5720HI, S5720EI, and S6720EI, run:
car cir cir-value [ pir pir-value ] [ cbs cbs-value pbs pbs-value ]
[ green { discard | pass } ] [ yellow { discard | pass } ] [ red
{ discard | pass } ]
The CAR action is configured.

c. (Optional) Run:
statistic enable
The traffic statistics collection function is enabled.

d. Run:
quit

e. (Optional) Run:
qos-car exclude-interframe
The system is configured not to count the inter-frame gap and preamble of packets
when calculating the traffic rate for traffic shaping.
NOTE
The qos-car exclude-interframe command configures the system not to count the inter-
frame gap and preamble of packets when calculating the traffic rate for traffic policing or
inbound interface-based rate limiting.
f. Run:
quit

a. Run:
system-view

b. Run the following commands as required.
run:
A traffic policy is created and the traffic policy view is displayed, or the view
of an existing traffic policy is displayed.
n On the S6720EI, S5720EI and S5720HI, run:
of an existing traffic policy is displayed.If no matching order is specified when
you create a traffic policy, the default matching order is config.
modify the matching order of traffic classifiers in the traffic policy. To modify
the matching order, delete the traffic policy, create a new traffic policy and
specify the matching order.
When creating a traffic policy, you can specify the matching order of matching
rules in the traffic policy. The matching order can be either automatic order or

○ If automatic order is used, traffic classifiers are matched based on the

priorities of their types. Traffic classifiers based on Layer 2 and Layer 3
information, Layer 2 information, and Layer 3 information are matched in
descending order of priority. The traffic classifier with the highest priority
is matched first. If data traffic matches multiple traffic classifiers, and the
traffic behaviors conflict with each other, the traffic behavior
corresponding to the highest priority rule takes effect.
○ If configuration order is used, traffic classifiers are matched based on the
NOTE
If more than 128 ACL rules defining CAR are configured, a traffic policy must be
applied to an interface, a VLAN, and the system in sequence in the outbound direction.
In the preceding situation, if ACL rules need to be updated, delete the traffic policy
from the interface, VLAN, and system and reconfigure it in sequence.
c. Run:

d. Run:
quit

e. Run:
quit

i. Run:
system-view

ii. Run:

NOTE

IP address.
configuration.
the interface.
iii. Run:



interface.
NOTE

the S6720EI.
i. Run:
system-view

ii. Run:
vlan vlan-id

iii. Run:

direction.
NOTE
i. Run:
system-view

ii. Run:
id ]

simultaneously.

switch.
5.6.2 Configuring Hierarchical Traffic Policingon the S5720HI and

S5720EI
Context
The device supports hierarchical traffic policing. After the system uses MQC to implement
traffic policing (level-1 CAR) for service flows matching a traffic classifier in a traffic policy,
the system aggregates all the service flows matching the traffic classifiers associated with the
level-1 CAR in the same traffic policy and performs traffic policing (level-2 CAR) for the
aggregated flow. Hierarchical traffic policing implements statistical multiplexing of traffic
and fine-grained service control. For details about level-1 CAR, see 5.6.1 Configuring MQC
to Implement Traffic Policing.
Procedure
1. Run:
system-view

2. Run:
qos car car-name cir cir-value [ cbs cbs-value [ pbs pbs-value ] | pir pir-
value [ cbs cbs-value pbs pbs-value ] ]
A QoS CAR profile is created and CAR parameters are configured.

3. Run:
The traffic behavior view is displayed.

4. Run:
car car-name share
The aggregated CAR action is configured.

NOTE
l The S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, S5720S-SI, and S6720EI do not
support aggregated CAR.
l The traffic policy defining the aggregated CAR action can only be used in the inbound
direction.
l After aggregated CAR is configured, all the rules in the traffic classifiers bound to the same
traffic behavior share the CAR index. The system aggregates all the flows matching these
traffic classifiers and uses CAR to limit the rate of the flows. If the traffic classifiers define
both Layer 2 and Layer 3 information, the aggregated CAR configuration is invalid.

5.7 Configuring Traffic Shaping

Unlike traffic policing that discards packets exceeding the rate limit, traffic shaping buffers
excess packets and sends them out at an even rate.
Before configuring traffic shaping on an interface, configure link layer attributes of the
interface to ensure that the interface works properly.
5.7.1 Configuring Traffic Shaping for a Queue
Context
Packets received on an interface enter different queues based on priority mapping. The device
can provide differentiated services for queues of different priorities using different traffic
shaping parameter settings for these queues.
Before configuring traffic shaping for queues on an interface, configure priority mapping to
map packet priorities to per hop behaviors (PHBs) so that packets of different services enter
different queues. For details about priority mapping, see 3.6 Configuring Priority Mapping
for the S5720HI, S5720EI, and S6720EI, and 4.5 Configuring Priority Mapping for the
S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI.
Procedure
Step 1 Run:
system-view

qos-shaping exclude-interframe
The system is configured not to count the inter-frame gap and preamble of packets when
calculating the traffic rate for traffic shaping.
The qos-shaping exclude-interframe command configures the system not to count the inter-
frame gap and preamble of packets when calculating the traffic rate for traffic shaping or
outbound interface-based rate limiting.
Step 3 Run:

Step 4 Run:
qos queue queue-index shaping cir cir-value pir pir-value [ cbs cbs-value pbs pbs-
value ]
The traffic shaping rate is configured for a queue. It is recommended that the CBS should be
120 times the CIR.
By default, the traffic shaping rate for a queue is the maximum bandwidth of the interface.

NOTE
If both queue-based traffic shaping and outbound rate limiting (configured by the qos lr outbound
command) are configured on an interface, the CIR for outbound rate limiting must be greater than or
equal to the sum of CIR values of all queues on the interface; otherwise, the traffic shaping result may
be incorrect. For example, a low-priority queue may preempt the bandwidth of a high-priority queue.
----End
5.7.2 (Optional) Configuring the Data Buffer
Context
The data buffer caches packets to be sent from an interface to prevent packet loss upon traffic
bursts. When the data buffer is full, the device does not cache packets and directly discards
packets not entering the buffer. You can adjust the buffering capacity of interface queues to
improve the forwarding performance.
Procedure
l Configure a burst traffic buffering mode on an interface of the S5720EI and S6720EI.
a. Run:
system-view

b. Run:

c. Run:
qos burst-mode { enhanced | extreme }
A burst traffic buffering mode is configured on the interface.

The enhanced mode is recommended because the extreme mode may affect
forwarding on other interfaces.
l Configure a burst traffic buffering mode on the S5720EI and S6720EI.
a. Run:
system-view

b. Run:
qos burst-mode { enhanced | extreme } slot slot-id
A burst traffic buffering mode is configured on the device.

The enhanced mode is recommended because the extreme mode may affect
forwarding on other interfaces.
l Configure queue lengths on an interface of the S2750, S5700LI, S5700S-LI, S5710-X-
LI, S5720SI, and S5720S-SI.
a. Run:
system-view

b. Run:
qos tail-drop-profile profile-name
A tail drop profile is created and its view is displayed.

c. Run the following commands as required.
n On the S2750 and S5700-10P-LI, run:
qos queue queue-index green max-length packet-number non-green max-
length packet-number
The length of a queue is set.

n On other modules except the S2750 and S5700-10P-LI, run:
qos queue queue-index max-length packet-number [ green max-length
packet-number ]

n On other modules except the S2750 and S5700-10P-LI, run:
qos queue queue-index green max-length packet-number

d. Run:
quit
Return to the system view.

e. Run:

f. Run:
shutdown
The interface is shut down.

g. Run:
The tail drop profile is applied to the interface.

h. Run:
undo shutdown
The interface is restarted.
----End
Procedure
l Run the display qos queue statistics interface interface-type interface-number [ queue
queue-index ] command to check statistics about interface queues.
----End

5.8 Configuring Interface-based Rate Limiting

Interface-based rate limiting controls the total rate of all packets passing through an interface
to ensure that the bandwidth usage is within the allowed range. You can configure interface-
based rate limiting in both inbound and outbound directions or in one direction.
Before configuring interface-based rate limiting on an interface, configure link layer attributes
of the interface to ensure that the interface works properly.
5.8.1 Configuring Inbound Interface-based Rate Limiting

Context
If rates of traffic sent from users are not limited, continuous burst data from many users will
congest the network. Inbound interface-based rate limiting controls the rate of traffic entering
an interface within a specified range.
Procedure
Step 1 Run:
system-view

qos-car exclude-interframe
calculating the incoming traffic rate on an interface.
NOTE
The qos-car exclude-interframe command configures the system not to count the inter-frame gap and
preamble of packets when calculating the traffic rate for inbound interface-based rate limiting and traffic
policing.
Step 3 Run:

Step 4 Run:
qos lr inbound cir cir-value [ cbs cbs-value ]
Inbound interface-based rate limiting is configured.

NOTE
When inbound interface-based rate limiting, Configuring Traffic Suppression in a VLAN, and 5.6.1
Configuring MQC to Implement Traffic Policing are configured simultaneouslyon the S2750,
S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI, these rules take effect in descending order
of priority: inbound interface-based rate limiting > Configuring Traffic Suppression in a VLAN > 5.6.1
Configuring MQC to Implement Traffic Policing. For example, if both inbound interface-based rate
limiting and Configuring Traffic Suppression in a VLAN are configured, inbound interface-based rate
limiting takes effect.
The S2750EI, S5700-10P-LI-AC, and S5700-10P-PWR-LI-AC that are enabled with Layer 3 hardware
forwarding for IPv4 packets do not support inbound interface-based rate limiting.
When interface-based 802.1x authentication is configured and the RADIUS server delivers the rate limit,
the interface does not support the rate limit.
----End
Configuration Tips
Deleting the Configuration of Inbound Interface-based rate Limiting
Run the undo qos lr inbound command in the interface view to delete the configuration of
inbound interface-based rate limiting configuration
5.8.2 Configuring Outbound Interface-based Rate Limiting
Context
To control the rate of all outgoing traffic on an interface, configure outbound interface-based
rate limiting. When the transmit rate of packets exceeds the rate limit, excess packets are
placed in the buffer queue. When there are sufficient tokens in the token bucket, the device
forwards the buffered packets at an even rate. When the buffer queue is full, the device
discards the buffered packets.
Procedure
Step 1 Run:
system-view

qos-shaping exclude-interframe
calculating the outgoing traffic rate.
NOTE
The qos-shaping exclude-interframe command configures the system not to count the inter-frame gap
and preamble of packets when calculating the traffic rate for traffic shaping or outbound interface-based
rate limiting.
Step 3 Run:

Step 4 Run:
qos lr outbound cir cir-value [ cbs cbs-value ]
Outbound interface-based rate limiting is configured.
By default, the rate limit on an interface is the maximum bandwidth of the interface.
NOTE
If both queue-based traffic shaping and rate limiting are configured on an interface, the CIR configured
for the interface must be greater than or equal to the sum of CIR values of all queues on the interface;
otherwise, traffic shaping may be incorrect. For example, a low-priority queue may preempt the
bandwidth of a high-priority queue.
When interface-based 802.1x authentication is configured and the RADIUS server delivers the rate limit,
the interface does not support the rate limit.
S5720HI does not support cbs cbs-value.
----End
Configuration Tips
Deleting the configuration of Outbound Interface-based Rate Limiting
Run the undo qos lr outbound command in the interface view to delete the configuration of
outbound interface-based rate limiting.
5.8.3 Configuring Rate Limiting on the Management Interface
Context
If there is heavy traffic on the management interface due to malicious attacks or network
exceptions, the CPU of the device is overloaded, which affects system operations. You can
configure a rate limit on the management interface to limit the rate of traffic entering the
device through the management interface, ensuring normal system operations.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface meth 0/0/1
The MEth interface view is displayed.
Step 3 Run:
qos lr pps packets
A rate limit is set for the management interface.
NOTE
A small rate limit may affect the FTP, Telnet, SFTP, STelnet, and SSH functions.
----End

Procedure
l Run the display qos car { all | name car-name } command to check the QoS CAR
configuration.
NOTE
Only the S5720HI and S5720EI support the display qos car command.
queue-index ] command to check statistics about interface queues.
l Run the display qos lr { inbound | outbound } interface interface-type interface-
number command to check the interface-based rate limiting configuration.
NOTE
The S2750EI, S5700-10P-LI-AC, and S5700-10P-PWR-LI-AC that are enabled with Layer 3
hardware forwarding for IPv4 packets do not support inbound.
----End
5.9 Maintaining Traffic Policing, Traffic Shaping, and

5.9.1 Displaying Traffic Statistics
Context
To view MQC-based traffic statistics, ensure that a traffic policy has been created and
contains the traffic statistics collection action.
Procedure
l Run the display traffic policy statistics { global [ slot slot-id ] | interface interface-type
interface-number | vlan vlan-id } { inbound | outbound } [ verbose { classifier-base |
rule-base } [ class classifier-name ] ] command to check MQC-based traffic statistics.
l Run the display qos statistics interface interface-type interface-number inbound
command to check packet statistics after inbound rate limiting is configuredon the
S6720EI, S5720HI, and S5720EI.
queue-index ] command to check queue-based traffic statistics on an interface.
----End
5.9.2 Clearing Traffic Statistics

Context
NOTICE
Cleared flow-based traffic statistics cannot be restored. Exercise caution when you run the
reset command.
Procedure
l Run the reset qos queue statistics interface interface-type interface-number command
to clear queue-based traffic statistics on an interface.
----End
5.10.1 Example for Configuring MQC to Implement Traffic

Policing
As shown in Figure 5-10, the Switch connects to the router through GE0/0/2, and the
enterprise connects to the Internet through the Switch and router.
Voice, video, and data services are transmitted in VLAN 120, VLAN 110, and VLAN 100
respectively.
Traffic policing must be configured on the Switch to limit the rates of different service
packets within proper ranges and guarantee bandwidth for each service.
Voice, video, and data services have QoS requirements in descending order of priority. The
Switch needs to re-mark DSCP priorities in different service packets so that the downstream
router can process the service packets based on priorities, ensuring QoS of different services.
Table 5-12 lists QoS requirements of different services.
Table 5-12 QoS guarantee for uplink traffic on the Switch
Traffic Type CIR (kbit/s) PIR (kbit/s) DSCP Priority
Voice 2000 10000 46
Video 4000 10000 30
Data 4000 10000 14

Phone
Traffic direction
VLAN 120
SwitchA GE0/0/1
PC GE0/0/2
Network
VLAN 100 Switch Router
TV
Enterprise
VLAN110 campus network
1. Create VLANs and configure interfaces to enable the enterprise to connect to the Internet
through the Switch.
2. Configure traffic classifiers on the Switch to classify packets based on VLAN IDs.
3. Configure traffic behaviors on the Switch to limit the rate of packets and re-mark DSCP
priorities of packets.
4. Configure a traffic policy on the Switch, associate the traffic behaviors with the traffic
classifiers in the traffic policy, and apply the traffic policy to the interface of the Switch
connected to the LSW.
Procedure
# Create VLAN 100, VLAN 110, and VLAN 120 on the Switch.
[Switch] vlan batch 100 110 120
# Configure GE0/0/1 and GE0/0/2 as trunk interfaces, and add them to VLAN 100, VLAN
110, and VLAN 120.
[Switch-GigabitEthernet0/0/1] port trunk allow-pass vlan 100 110 120
Step 2 Configure traffic classifiers.

# Configure traffic classifiers c1, c2, and c3 on the Switch to match different service flows
from the enterprise based on VLAN IDs.
[Switch] traffic classifier c1 operator and
[Switch-classifier-c1] if-match vlan-id 120
[Switch-classifier-c1] quit
Step 3 Configure traffic behaviors.

# Configure traffic behaviors b1, b2, and b3 on the Switch to limit the rates and re-mark
priorities of the service flows.
[Switch] traffic behavior b1
[Switch-behavior-b1] car cir 2000 pir 10000 green pass
[Switch-behavior-b1] remark dscp 46
[Switch-behavior-b1] statistic enable
[Switch-behavior-b1] quit
Step 4 Configure a traffic policy and apply the traffic policy to the interface connected to the LSW.
# Create a traffic policy named p1 on the Switch, associate the traffic behaviors with the
traffic classifiers in the traffic policy, and apply the traffic policy to GE0/0/1 in the inbound
direction to limit the rates and re-mark packet priorities.
[Switch] traffic policy p1
[Switch-trafficpolicy-p1] classifier c1 behavior b1
[Switch-trafficpolicy-p1] quit
[Switch-GigabitEthernet0/0/1] traffic-policy p1 inbound

# View the traffic classifier configuration.
[Switch] display traffic classifier user-defined
User Defined Classifier Information:
Classifier: c2
Operator: AND
Rule(s) : if-match vlan-id 110
Classifier: c3
Operator: AND
Classifier: c1
Operator: AND
Total classifier number is 3

# View the traffic policy configuration. The traffic policy p1 is used as an example.
[Switch] display traffic policy user-defined p1
User Defined Traffic Policy Information:
Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
Committed Access Rate:
CIR 2000 (Kbps), CBS 250000 (Byte)
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Yellow Action : pass
Red Action : discard
Remark:
Remark DSCP ef
Statistic: enable
Classifier: c2
Operator: AND
Behavior: b2
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Remark:
Remark DSCP af33
Statistic: enable
Classifier: c3
Operator: AND
Behavior: b3
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Remark:
Remark DSCP af13
Statistic: enable
# View information about the traffic policy that is applied to the interface. GE0/0/1 is used as
an example.
[Switch] display traffic policy statistics interface gigabitethernet 0/0/1 inbound
Interface: GigabitEthernet0/0/1
Traffic policy inbound: p1
Rule number: 3
Current status: success
Statistics interval: 300
---------------------------------------------------------------------
Board : 0
---------------------------------------------------------------------
Matched | Packets: 0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
Passed | Packets: 0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
Dropped | Packets: 0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------

Filter | Packets: 0
| Bytes:
0
---------------------------------------------------------------------
Car | Packets: 0
| Bytes: 0
---------------------------------------------------------------------
----End
Configuration Files
#
sysname Switch
#
vlan batch 100 110 120
#
traffic classifier c1 operator and
if-match vlan-id 120
#
traffic behavior b1
car cir 2000 pir 10000 cbs 250000 pbs 1250000 green pass yellow pass red
discard
remark dscp ef
statistic enable
traffic behavior b2
discard
remark dscp af33
statistic enable
traffic behavior b3
discard
remark dscp af13
statistic enable
#
traffic policy p1 match-order config
classifier c1 behavior b1
#
port trunk allow-pass vlan 100 110 120
traffic-policy p1 inbound
#
#
return
5.10.2 Example for Configuring Hierarchical Traffic

Policing(Applicable to S5720HI and S5720EI)
enterprise connects to WAN through the Switch and router.

On an enterprise network, network-side interfaces are often congested because the WAN
network bandwidth is less than enterprise's LAN bandwidth. Congestion may cause loss of
service data. To prevent this problem, configure traffic policing on the inbound interface of
upstream traffic. In this example, the total bandwidth on the interface needs to be limited to
12000 kbit/s, and the rates of voice, video, and data service flows need to be limited within
proper ranges.
respectively, and have QoS requirements in descending order of priority. The Switch needs to
re-mark DSCP priorities in different service packets so that the router can provide QoS
guarantee based on priorities of packets.
Table 5-13 describes QoS requirements of different services.
Table 5-13 QoS guarantee that the Switch provides for upstream traffic
Traffic Type CIR (kbit/s) PIR (kbit/s) DSCP Priority
Voice 2000 10000 46
Video 4000 10000 30
Data 4000 10000 14
Figure 5-11 Networking of hierarchical traffic policing
Phone
Traffic direction
VLAN 120
SwitchA GE0/0/1
PC GE0/0/2
Network
TV
Enterprise
VLAN110 campus network
1. Create VLANs and configure interfaces to enable the enterprise to connect to the
network through the Switch.
2. Configure a CAR profile to limit the total bandwidth of voice, data, and video services.
3. Configure traffic classifiers on the Switch to classify voice, video, and data packets
based on VLAN IDs.

4. Configure traffic behaviors on the Switch to limit the rate of packets and re-mark DSCP
priorities of packets.
5. Configure a traffic policy on the Switch, bind traffic behaviors and traffic classifiers to
the traffic policy, and apply the traffic policy to the interface on the Switch connected to
the enterprise.
Procedure
Step 1 Configure VLANs and interfaces.
# Configure GE 0/0/1 and GE 0/0/2 as trunk interfaces, and add GE0/0/1 and GE 0/0/2 to
VLAN 100, VLAN 110, and VLAN 120.
Step 2 Configure a CAR profile.

[Switch] qos car car1 cir 12000
Step 3 Create traffic classifiers.

# Configure traffic classifiers c1, c2, and c3 on the Switch to match different service flows
from the enterprise based on VLAN IDs.
Step 4 Create traffic behaviors.

# Create traffic behaviors b1, b2, and b3 on the Switch to limit rates of different service flows
and re-mark DSCP priorities.
[Switch-behavior-b1] car car1 share


Step 5 Create a traffic policy and apply it to the interface connected to the enterprise.
# Create a traffic policy p1 on the Switch, associate traffic classifiers with traffic behaviors in
the traffic policy, and apply the traffic policy to the inbound direction on GE 0/0/1to limit the
packets received from the enterprise and re-mark priorities of the packets.

Classifier: c2
Operator: AND
Classifier: c3
Operator: AND
Classifier: c1
Operator: AND
# View the configuration of the traffic policy p1.

Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Share car:
Car car1 share
Remark:
Remark DSCP ef
Statistic: enable
Classifier: c2
Operator: AND
Behavior: b2
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Share car:

Car car1 share

Remark:
Remark DSCP af33
Statistic: enable
Classifier: c3
Operator: AND
Behavior: b3
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Share car:
Car car1 share
Remark:
Remark DSCP af13
Statistic: enable
# View the configuration of the traffic policy applied to GE0/0/1.

Rule number: 3
Current status: success
Statistics interval:
300
---------------------------------------------------------------------
Board : 0
---------------------------------------------------------------------
Matched | Packets:
0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
Passed | Packets: 0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
Filter | Packets: 0
| Bytes: 0
---------------------------------------------------------------------
Car | Packets:
0
| Bytes: 0
---------------------------------------------------------------------
----End
Configuration Files
#
sysname Switch
#
#
qos car car1 cir 12000 cbs 2256000
#


#
traffic behavior b1
discard
car car1 share
remark dscp ef
statistic enable
traffic behavior b2
discard
car car1 share
remark dscp af33
statistic enable
traffic behavior b3
discard
car car1 share
remark dscp af13
statistic enable
#
#
#
#
return
5.10.3 Example for Configuring Rate Limiting in a Specified Time

Range
As shown in Figure 5-12, enterprise users connect to the Internet devices through GE0/0/2 of
the switch.
During work hours from 8:30 to 18:00, the rate of traffic sent to the external network cannot
exceed 4 Mbit/s.

Figure 5-12 Networking for rate limiting in a specified time range
IP:192.168.1.10/24
Traffic direction
HostA
IP:192.168.1.11/24
GE0/0/1 GE0/0/2
Internet
HostB LSW Switch Router
IP:192.168.1.12/24
Enterprise
HostC campus network
A time-range-based traffic policy can be used to implement rate limiting. The configuration
roadmap is as follows:
1. Configure interfaces to enable the enterprise to connect to the Internet through the
Switch.
2. Configure a time range, which will be applied to an ACL.
3. Configure an ACL to match traffic passing through the Switch in the specified time
range.
4. Configure a traffic policy to limit the rate of packets matching the ACL.
5. Apply the traffic policy to the inbound direction of GE0/0/1.
Procedure
# Create VLAN 10 on the Switch.

[Switch] vlan 10
[Switch-vlan10] quit
# Configure GE0/0/1 and GE0/0/2 on the Switch as trunk interfaces and add them to VLAN
10.

NOTE
Configure the interface of the LSW connected to the Switch as a trunk interface and add it to VLAN 10.
# Create VLANIF 10 and assign IP address 192.168.1.1/24 to it.

[Switch] interface vlanif 10
[Switch-Vlanif10] ip address 192.168.1.1 24
[Switch-Vlanif10] quit
NOTE
Configure IP address 192.168.1.2/24 for the router interface connected to the Switch.
Step 2 Create a time range working_time that defines work hours from 8:30 to 18:00.
[Switch] time-range working_time 08:30 to 18:00 working-day
Step 3 Configure ACL 2001 and define three rules to limit the bandwidth of packets from
192.168.1.10, 192.168.1.11, and 192.168.1.12 during work hours.
[Switch] acl number 2001
[Switch-acl-basic-2001] rule permit source 192.168.1.10 0 time-range working_time
[Switch-acl-basic-2001] quit
Step 4 Apply ACL 2001 to a traffic classifier.

[Switch] traffic classifier c1
[Switch-classifier-c1] if-match acl 2001
Step 5 Configure a traffic behavior and set the rate limit to 4 Mbit/s.
[Switch-behavior-b1] car cir 4096
Step 6 Configure a traffic policy and apply the traffic policy on GE0/0/1 in the inbound direction.

[Switch] display traffic classifier user-defined c1
Classifier: c1
Operator: AND
Rule(s) : if-match acl 2001
# View the traffic policy configuration.

Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
PIR 4096 (Kbps), PBS 512000 (Byte)
Green Action : pass


----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
time-range working_time 08:30 to 18:00 working-day
#
acl number 2001
rule 5 permit source 192.168.1.10 0 time-range working_time
#
if-match acl 2001
#
traffic behavior b1
discard
#
#
interface
Vlanif10
ip address 192.168.1.1
255.255.255.0
#
#
port link-type
trunk
port trunk allow-pass vlan
10
#
return
5.10.4 Example for Configuring Rate Limiting for Users on

Different Network Segments
enterprise connects to the Internet through the Switch and router.
Users on different floors connect to the network through different access switches and belong
to different network segments. Different bandwidth needs to be provided for users on different
network segments.
Table 5-14 describes the QoS requirements.


User CIR (kbit/s) PIR (kbit/s)
Users on the first floor 4000 10000
Users on the second 6000 10000

floor
Figure 5-13 Networking for rate limiting for users on different network segments
Floor 1 :
192.168.1.0/24
LSW A
PC1
GE0/0/1
PC2 GE0/0/3 Network
GE0/0/2
Switch Router
PC1
LSW B
PC2 Traffic direction

Floor 2:
192.168.2.0/24
1. Create VLANs and configure interfaces to enable the enterprise to connect to the Internet
through the Switch.
2. Configure ACLs to match different network segments on the Switch.
3. Configure traffic classifiers and apply the ACLs to the traffic classifiers on the Switch.
4. Configure traffic behaviors on the Switch to limit the rates of packets from users on
different floors.
5. Configure a traffic policy on the Switch, associate the traffic behaviors with the traffic
classifiers in the traffic policy, and apply the traffic policy to the interface on the Switch
connected to the router.
Procedure
# Create VLAN 100 and VLAN 200 on the Switch.

# Configure GE0/0/1 and GE0/0/2 as trunk interfaces and add them to VLAN 100 and VLAN
200. Configure GE0/0/3 as a trunk interface and add it to VLAN 100 and VLAN 200.
Step 2 Configure ACLs.
# Configure ACLs to match different network segments.

[Switch] acl 2000
[Switch-acl-basic-2000] rule permit source 192.168.1.0 0.0.0.255
[Switch] acl 2001
[Switch-acl-basic-2001] rule permit source 192.168.2.0 0.0.0.255
# Configure traffic classifiers c1 and c2 on the Switch to classify packets from users in
different floors.
# Create traffic behaviors b1 and b2 on the Switch to limit the rates of different service flows.
Step 5 Configure a traffic policy and apply the traffic policy to the interface connected to the router.
# Create a traffic policy named p1 on the Switch, associate traffic classifiers with traffic
behaviors in the traffic policy, and apply the traffic policy to the outbound direction of
GE0/0/3 to police packets from the enterprise.
[Switch-GigabitEthernet0/0/3] traffic-policy p1 outbound


Classifier: c2
Operator: AND
Classifier: c1
Operator: AND

Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
Classifier: c2
Operator: AND
Behavior: b2
PIR 10000 (Kbps), PBS 1250000 (Byte)
Green Action : pass
----End
Configuration Files
#
sysname Switch
#
vlan batch 100 200
#
acl number 2000
rule 5 permit source 192.168.1.0 0.0.0.255
acl number 2001
rule 5 permit source 192.168.2.0 0.0.0.255
#
if-match acl 2000
if-match acl 2001
#
traffic behavior b1
discard
traffic behavior b2
discard
#

#
#
#
traffic-policy p1 outbound
#
return
5.10.5 Example for Configuring Traffic Shaping (Applicable to

S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI)
The Switch is connected to the router through GE0/0/2. The voice, video, and data services,
with 802.1p priorities of 6, 5, and 2, are transmitted to users through the router and Switch, as
shown in Figure 5-14. The rate of traffic from the enterprise campus network is higher than
the interface rate on the router; therefore, jitter may occur on GE0/0/2. The following
requirements must be met to reduce jitter and ensure bandwidth of services:
l The CIR on GE0/0/2 is 10000 kbit/s.

l The CIR and PIR for the voice service are 3000 kbit/s and 5000 kbit/s respectively.
l The CIR and PIR for the video service are 5000 kbit/s and 8000 kbit/s respectively.
l The CIR and PIR for the data service are 2000 kbit/s and 3000 kbit/s respectively.
Figure 5-14 Networking of traffic shaping
Phone
Traffic direction
8021p=6
SwitchA GE0/0/1
PC GE0/0/2
Network
8021p=2 Switch Router
TV
Enterprise
8021p=5 campus network

1. Create VLANs and configure interfaces to enable the enterprise to access the network
through the Switch.
2. Configure the inbound interface of service packets to trust 802.1p priorities in packets.
3. Configure traffic shaping on the outbound interface of service packets to limit the
bandwidth of the interface.
4. Configure queue-based traffic shaping on the outbound interface to limit the CIR values
of voice, video, and data services.
Procedure
Step 1 Configure VLANs and interfaces.
# Create VLAN 10.
[Switch] vlan batch 10
# Configure GE0/0/1 and GE0/0/2 as trunk interfaces, and add GE0/0/1 and GE0/0/2 to
VLAN 10.
# Create VLANIF 10 and assign IP address 10.10.10.2/24 to VLANIF 10.

[Switch-Vlanif10] ip address 10.10.10.2 255.255.255.0
NOTE
Assign IP address 10.10.10.1/24 to the router interface connected to Switch.
Step 2 Configure the inbound interface of service packets to trust packet priorities.
# Configure gigabitethernet0/0/1 to trust 802.1p priorities of packets.

[Switch-GigabitEthernet0/0/1] trust 8021p
Step 3 Configure traffic shaping on the outbound interface.

# Configure traffic shaping on gigabitethernet 0/0/2 to limit the interface rate to 10000 kbit/s.
[Switch-GigabitEthernet0/0/2] qos lr outbound cir 10000
Step 4 Configure queue-based traffic shaping.

# Configure traffic shaping for queues on GigabitEthernet0/0/ to limit the CIR and PIR of the
voice service to 3000 kbit/s and 5000 kbit/s, the CIR and PIR of the video service to 5000
kbit/s and 8000 kbit/s, and the CIR and PIR of the data service to 2000 kbit/s and 3000 kbit/s.

[Switch-GigabitEthernet0/0/2] qos queue 6 shaping cir 3000 pir 5000


# After the configuration is complete, the committed bandwidth for the packets sent from
GE0/0/2 is 10000 kbit/s; the transmission rate of the voice service ranges from 3000 kbit/s to
5000 kbit/s; the transmission rate of the video service ranges from 5000 kbit/s to 8000 kbit/s;
the transmission rate of the data service ranges from 2000 kbit/s to 3000 kbit/s.
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
interface Vlanif10
ip address 10.10.10.2 255.255.255.0
#
trust 8021p
#
qos lr outbound cir 10000 cbs 1250000
qos queue 2 shaping cir 2000 pir 3000
#
return
5.10.6 Example for Configuring Interface-based Rate Limiting
As shown in Figure 5-15, the Switch connects to the router through GE0/0/3. Enterprise
departments 1 and 2 are connected to GE0/0/1 and GE0/0/2 of the Switch and access the
Internet through the Switch and router.
Services do not need to be differentiated, but bandwidth for each department needs to be
limited. For department 1, incoming traffic must be allocated guaranteed bandwidth of 8
Mbit/s and maximum bandwidth of 10 Mbit/s. For department 2, incoming traffic must be
allocated guaranteed bandwidth of 5 Mbit/s and maximum bandwidth of 8 Mbit/s.

Figure 5-15 Networking of interface-based rate limiting
Network
Router
GE0/0/3
Traffic
GE0/0/1 GE0/0/2 direction
Switch
SwitchA SwitchB
Department 1 Department 2
1. Configure interfaces of the Switch to enable users to access the Internet.
2. Configure rate limiting for all incoming traffic on GE0/0/1 and GE0/0/2 of the Switch.
Procedure
Step 1 Create VLANs and configure interfaces on the Switch.
# Configure GE0/0/1, GE0/0/2, and GE0/0/3 as trunk interfaces, and configure GE0/0/1 to
allow VLAN 100, GE0/0/2 to allow VLAN 200, and GE0/0/3 to allow VLAN 100 and VLAN
200.

Step 2 Configure interface-based rate limiting.
# Set the CIR for incoming traffic on GE0/0/1 to 8192 kbit/s.

[Switch-GigabitEthernet0/0/1] qos lr inbound cir 8192
# Set the CIR for incoming traffic on GE0/0/2 to 5120 kbit/s.

[Switch-GigabitEthernet0/0/2] qos lr inbound cir 5120
# View the interface-based rate limiting configuration.

[Switch] display qos lr inbound interface gigabitethernet 0/0/1
GigabitEthernet0/0/1 lr inbound:
cir: 8192 Kbps, cbs: 1024000 Byte
[Switch] display qos lr inbound interface gigabitethernet 0/0/2
GigabitEthernet0/0/2 lr inbound:
cir: 5120 Kbps, cbs: 640000 Byte
----End
Configuration Files
Switch configuration file
#
sysname Switch
#
vlan batch 100 200
#
qos lr inbound cir 8192 cbs 1024000
#
qos lr inbound cir 5120 cbs 640000
#
#
return
5.11 FAQ
5.11.1 When Both traffic-limit inbound and qos lr inbound Are

Configured, Which of Them Will Take Effect?
The taffic-limit inbound command limits the rate of the packets matching an ACL, whereas
the qos lr inbound command limits the rate of all packets on an interface. If both of them are
configured, they both take effect. However, the actual traffic rate is limited by the smaller
CIR. If you want to limit only the rate of incoming packets matching an ACL, the two

commands have the same effect. If you want to limit the rate of all incoming packets, choose
a proper command.
5.12 References

Headers

Services

S2750&S5700&S6720 Series Ethernet Switches 6 Congestion Avoidance and Congestion Management
Configuration Guide - QoS Configuration
6 Congestion Avoidance and Congestion

Management Configuration
About This Chapter
This chapter describes how to configure congestion avoidance and congestion management.
6.1 Overview
6.2 Principles
This section describes the principles of congestion management and congestion avoidance.
6.5 Configuring Congestion Avoidance on the S2750, S5700LI, S5700S-LI, S5710-X-LI,
6.6 Configuring Congestion Avoidance on the S6720EI, S5720HI, and S5720EI
6.7 Configuring Congestion Management on the S2750, S5700LI, S5700S-LI, S5710-X-LI,
6.8 Configuring Congestion Management on the S6720EI, S5720HI, and S5720EI
6.9 Configuring Congestion Management on a Stack Interface of the S2750, S5700LI,
S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI
6.10 Configuring Congestion Management on a Stack Interfaceon the S6720EI and S5720EI
6.11 Maintaining Congestion Avoidance and Congestion Management
6.13 References

6.1 Overview
Congestion avoidance prevents a network from being overloaded using a packet discarding
policy. Congestion management ensures that high-priority services are preferentially
processed based on the specified packet scheduling sequence.
On a traditional network, quality of service (QoS) is affected by network congestion.
Congestion means the low data forwarding rate and delay resulting from insufficient network
resources. Congestion results in delay of packet transmission, low throughput rate, and high
resource consumption. Congestion frequently occurs in a complex networking environment
where packet transmission and provision of various services are both required.
Congestion avoidance and congestion management are two flow control mechanisms for
resolving congestion on a network.
Congestion Avoidance
Congestion avoidance is a flow control mechanism. A system configured with congestion
avoidance monitors network resources such as queues and memory buffers. When congestion
occurs or aggravates, the system discards packets.
The device supports the following congestion avoidance features:
l Tail drop
Tail drop is the traditional congestion avoidance mechanism that processes all packets
equally without classifying the packets into different types. When congestion occurs,
packets at the end of a queue are discarded until the congestion problem is solved.
Tail drop causes global Transmission Control Protocol (TCP) synchronization. In tail
drop mechanism, all newly arrived packets are dropped when congestion occurs, causing
all TCP sessions to simultaneously enter the slow start state and the packet transmission
to slow down. Then all TCP sessions restart their transmission at roughly the same time
and then congestion occurs again, causing another burst of packet drops, and all TCP
sessions enters the slow start state again. The behavior cycles constantly, severely
reducing the network resource usage.
By default, an interface uses tail drop.
l WRED
Weighted Random Early Detection (WRED) randomly discards packets based on drop
parameters. WRED defines different drop policies for packets of different services.
WRED discards packets based on packet priorities, so the drop probability of packets
with higher priorities is low. In addition, WRED randomly discards packets so that rates
of TCP connections are reduced at different times. This prevents global TCP
synchronization.
WRED defines upper and lower threshold for the length of each queue. The packet drop
policy is as follows:
– When the length of a queue is shorter than the lower threshold, no packet is
discarded.
– When the length of a queue exceeds the upper threshold, all received packets are
discarded.
– When the length of a queue ranges from the lower threshold to the upper threshold,
incoming packets are discarded randomly. Random Early Detection (RED)

generates a random number for each incoming packet and compares it with the drop
probability of the current queue. If the random number is smaller than the drop
probability, the packet is discarded. A longer queue indicates a higher drop
probability.
NOTE
WRED is only supported by the S5720HI, S6720EI, and S5720EI.
Congestion Management
When a network is congested intermittently and delay-sensitive services require higher
bandwidth than other services, congestion management adjusts the scheduling order of
packets.
The device supports the following congestion management features:
l PQ scheduling
Priority queuing (PQ) schedules packets in descending order of priority. Packets in
queues with a low priority can be scheduled only after all packets in queues with a high
priority have been scheduled.
By using PQ scheduling, the device puts packets of delay-sensitive services into queues
with higher priorities and packets of other services into queues with lower priorities so
that packets of delay-sensitive services are preferentially scheduled.
The disadvantage of PQ is that the packets in lower-priority queues are not processed
until all the higher-priority queues are empty. As a result, a congested higher-priority
queue causes all lower-priority queues to starve out.
l WRR scheduling
Weighted Round Robin (WRR) ensures that packets in all the queues are scheduled in
turn.
For example, eight queues are configured on an interface. Each queue is configured with
a weight, namely, w7, w6, w5, w4, w3, w2, w1, and w0. The weight value represents the
percentage of obtaining resources. This example assumes that the weights of queues on a
100M interface are 50, 50, 30, 30, 10, 10, 10, and 10, which correspond to w7, w6, w5,
w4, w3, w2, w1, and w0 respectively. The queue with the lowest priority can obtain at
least 5 Mbit/s bandwidth. This ensures that packets in all the queues can be scheduled.
In addition, WRR can dynamically change the time of scheduling packets in queues. For
example, if a queue is empty, WRR ignores this queue and starts to schedule the next
queue. This ensures efficient use of bandwidth.
WRR scheduling has two disadvantages:
– WRR schedules packets based on the number of packets, whereas users concern the
bandwidth. When the average packet length in each queue is the same or known,
users can obtain the required bandwidth by setting WRR weight values. When the
average packet length in each queue is variable, users cannot obtain the required
bandwidth by setting WRR weight values.
– Delay-sensitive services, such as voice services, cannot be scheduled in a timely
manner.
NOTE
The S5720HI does not support WRR.

l DRR scheduling
Deficit Round Robin (DRR) implementation is similar to WRR implementation.

The difference between DRR and WRR is as follows: WRR schedules packets based on
the number of packets, whereas DRR schedules packets based on the packet length. If
the packet length is too long, DRR allows the negative weight value so that long packets
can be scheduled. In the next round, the queue with the negative weight value is not
scheduled until its weight value becomes positive.
DRR offsets the disadvantages of PQ scheduling and WRR scheduling. That is, in PQ
scheduling, packets in queues with lower priorities cannot be scheduled for a long time,
in WRR scheduling, bandwidth is allocated improperly when the packet length of each
queue is different or variable.
DRR cannot schedule delay-sensitive services such as voice services in a timely manner.
l PQ+WRR/PQ+DRR scheduling
PQ, WRR, and DRR have their own advantages and disadvantages. If only PQ
scheduling is used, packets in the queues with a low priority may not obtain bandwidth
for a long time. If only WRR or DRR scheduling is used, delay-sensitive services, such
as voice services, cannot be scheduled in a timely manner. PQ+WRR or PQ+DRR
scheduling integrates the advantages of PQ scheduling and WRR or DRR scheduling and
can avoid their disadvantages.
By using PQ+WRR or PQ+DRR scheduling, the device puts important packets such as
protocol packets and packets of delay-sensitive services to the PQ queue, and allocates
bandwidth to the PQ queue. Then, the device can put other packets into the WRR or
DRR queues based on the packet priority. Packets in WRR or DRR queues can be
scheduled based on weight values in turn.
NOTE
The S5720HI does not support PQ+WRR.
6.2 Principles
This section describes the principles of congestion management and congestion avoidance.
6.2.1 Congestion Avoidance
Congestion avoidance is a mechanism used to control service flows. A system configured

with congestion avoidance monitors network resource usage such as queues and memory
buffers. When congestion occurs or aggravates, the system starts to discard packets.
Congestion avoidance uses tail drop and WRED to discard packets.
l Traditional tail drop policy

The traditional packet drop policy uses the tail drop method. When the length of a queue
reaches the maximum value, all the packets last added to the queue (at the tail of the
queue) are discarded.
This packet drop policy may cause global TCP synchronization. As a result, TCP
connections cannot be set up. The three colors represent three TCP connections. When
packets from multiple TCP connections are discarded, these TCP connections enter the
congestion avoidance and slow start state. Traffic reduces, and then reaches the peak.
The volume of traffic varies greatly.

Figure 6-1 Tail drop policy
l WRED
To avoid global TCP synchronization, Random Early Detection (RED) is used. The RED
mechanism randomly discards packets so that the transmission speed of multiple TCP
connections is not reduced simultaneously. In this manner, global TCP synchronization is
prevented. The rate of TCP traffic and network traffic become stable.
Figure 6-2 RED
The device provides Weighted Random Early Detection (WRED) based on RED
technology.
– WRED
WRED discards packets in queues based on DSCP priorities or IP priorities. The
upper drop threshold, lower drop threshold, and drop probability can be set for each
priority. When the total size of packets in a queue reaches the lower drop threshold,
the device starts to discard packets. As the total size of packets in the queue
increases, the packet loss ratio increases accordingly. The maximum drop
probability cannot exceed the configured packet loss ratio. All packets are discarded
when the total size of packets in the queue reaches the upper drop threshold. WRED
discards packets in queues based on the drop probability, thereby preventing
congestion to a certain degree.

6.2.2 Congestion Management

As increasing network services are emerging and people are demanding higher network
quality, limited bandwidth cannot meet network requirements. As a result, the delay and
signal loss occur because of congestion. When a network is congested intermittently and
delay-sensitive services require higher QoS than delay-insensitive services, congestion
management is required. If congestion persists on the network after congestion management is
configured, the bandwidth needs to be increased. Congestion management implements
queuing and scheduling when sending packet flows.
Based on queuing and scheduling policies, the device supports Priority Queuing (PQ), Deficit
Round Robin (DRR), Weighted Round Robin (WRR), PQ+DRR, and PQ+WRR for
congestion management. Each scheduling algorithm schedules specific types of traffic, and
affects bandwidth allocation, delay, and jitter.
On the device, there are eight queues on each interface in the outbound direction, which are
identified by index numbers. The index numbers range from 0 to 7. Based on the mappings
between local priorities and queues, the device sends the classified packets to queues, and
then schedules the packets using queue scheduling mechanisms.
l PQ scheduling
PQ scheduling is designed for core services, and is applied to the queues in descending
order of priorities. Queues with lower priories are processed only after all the queues
with higher priorities are empty. In PQ scheduling, packets of core services are placed
into a queue of a higher priority, and packets of non-core services such as email services
are placed into a queue of a lower priority. Core services are processed first, and non-
core services are sent at intervals when core services are not processed.
As shown in Figure 6-3, the priorities of queues 7 to 0 are in descending order of
priorities. The packets in queue 7 are processed first. The scheduler processes packets in
queue 6 only after queue 7 becomes empty. The packets in queue 6 are sent at the link
rate when packets in queue 6 need to be sent and queue 7 is empty. The packets in queue
5 are sent at the link rate when queue 6 and queue 7 are empty, and so on.
PQ scheduling is valid for short-delay services. Assume that data flow X is mapped to
the queue of the highest priority on each node. When packets of data flow X reach a
node, the packets are processed first.
The PQ scheduling mechanism, however, may result in starvation of packets in queues
with lower priorities. For example, if data flows mapped to queue 7 arrive at 100% link
rate in a period, the scheduler does not process flows in queue 6 and queues 0 to 5.
To prevent starvation of packets in some queues, upstream devices need to accurately
define service characteristics of data flows so that service flows mapped to queue 7 do
not exceed a certain percentage of the link capacity. By doing this, queue 7 is not full and
the scheduler can process packets in queues with lower priorities.

Figure 6-3 PQ scheduling
Queue 7 High priority
Packet flow
Queue 6 Packet flow
......
Queue 1
Interface
Queue 0
Low priority
l WRR scheduling
WRR scheduling is an extension of Round Robin (RR) scheduling. Packets in each
queue are scheduled in a polling manner based on the queue weight. RR scheduling
equals WRR scheduling with the weight being 1.
Figure 6-4 shows WRR scheduling.
Figure 6-4 WRR scheduling
Queue 7
Packet flow
Queue 6 Packet flow
......
Queue 1
Interface
Classification
Queue 0
In WRR scheduling, the device schedules packets in queues in a polling manner round
by round based on the queue weight. After one round of scheduling, the weights of all
queues are decreased by 1. The queue whose weight is decreased to 0 cannot be
scheduled. When the weights of all the queues are decreased to 0, the next round of
scheduling starts. For example, the weights of eight queues on an interface are set to 4, 2,
5, 3, 6, 4, 2, and 1. Table 6-1 lists the WRR scheduling results.

Table 6-1 WRR scheduling results

Queu Queu Queu Queu Queu Queu Queu Queu Queu
e e7 e6 e5 e4 e3 e2 e1 e0
Index
Queue 4 2 5 3 6 4 2 1
Weight
Queue Queue Queue Queue Queue Queue Queue Queue Queue

in the 7 6 5 4 3 2 1 0
first
round
of
schedu
ling
Queue Queue Queue Queue Queue Queue Queue Queue -

in the 7 6 5 4 3 2 1
second
round
of
schedu
ling
Queue Queue - Queue Queue Queue Queue - -

in the 7 5 4 3 2
third
round
of
schedu
ling
Queue Queue - Queue - Queue Queue - -

in the 7 5 3 2
fourth
round
of
schedu
ling
Queue - - Queue - Queue - - -

in the 5 3
fifth
round
of
schedu
ling


e e7 e6 e5 e4 e3 e2 e1 e0
Index
Queue - - - - Queue - - -
in the 3
sixth
round
of
schedu
ling
Queue Queue Queue Queue Queue Queue Queue Queue Queue

in the 7 6 5 4 3 2 1 0
sevent
h
round
of
schedu
ling
Queue Queue Queue Queue Queue Queue Queue Queue -

in the 7 6 5 4 3 2 1
eighth
round
of
schedu
ling
Queue Queue - Queue Queue Queue Queue - -

in the 7 5 4 3 2
ninth
round
of
schedu
ling
Queue Queue - - Queue Queue Queue - -

in the 7 4 3 2
tenth
round
of
schedu
ling
Queue - - Queue - Queue - - -

in the 5 3
elevent
h
round
of
schedu
ling


e e7 e6 e5 e4 e3 e2 e1 e0
Index
Queue - - - - Queue - - -
in the 3
twelfth
round
of
schedu
ling
The statistics show that the number of times packets are scheduled in each queue
corresponds to the queue weight. A higher queue weight indicates a greater number of
times packets in the queue are scheduled. The unit for WRR scheduling is packet;
therefore, there is no fixed bandwidth for each queue. If packets are scheduled fairly,
large-sized packets obtain more bandwidth than small-sized packets.
WRR scheduling offsets the disadvantage of PQ scheduling in which packets in queues
with lower priories may be not processed for a long period of time. In addition, WRR
can dynamically change the time of scheduling packets in queues. For example, if a
queue is empty, WRR scheduling ignores this queue and starts to schedule the next
queue. This ensures bandwidth usage. WRR scheduling, however, cannot schedule short-
delay services in time.
l DRR scheduling
DRR is also based on RR. DRR solves the WRR problem. In WRR scheduling, a large-
sized packet obtains less bandwidth than a small-sized packet. DRR schedules packets
considering the packet length, ensuring that packets are scheduled equally.
Deficit indicates the bandwidth deficit of each queue. The initial value is 0. The system
allocates bandwidth to each queue based on the weight and calculates the deficit. If the
deficit of a queue is greater than 0, the queue participates in scheduling. The device
sends a packet and calculates the deficit based on the length of the sent packet. If the
deficit of a queue is smaller than 0, the queue does not participate in scheduling. The
current deficit is used as the basis for the next round of scheduling.

Figure 6-5 Queue weights
(Q7,20%)
400 600 900
(Q6,15%)
500 300 400
(Q5,10%)
800 400 600
(Q4,5%)
800 800 400
(Q3,20%)
500 400 800
(Q2,15%)
700 700 700
(Q1,10%)
700 800 600
(Q0,5%)
700 800 600
In Figure 6-5, the weights of Q7, Q6, Q5, Q4, Q3, Q2, Q1, and Q0 are set to 40, 30, 20,
10, 40, 30, 20, and 10 respectively. During scheduling, Q7, Q6, Q5, Q4, Q3, Q2, Q1, and
Q0 obtain 20%, 15%, 10%, 5%, 20%, 15%, 10%, and 5% of the bandwidth respectively.
Q7 and Q6 are used as examples to describe DRR scheduling. Assume that Q7 obtains
400 bytes/s bandwidth and Q6 obtains 300 bytes/s bandwidth.
– First round of scheduling
Deficit[7][1] = 0+400 = 400
Deficit[6][1] = 0+300 = 300
After packet of 900 bytes in Q7 and packet of 400 bytes in Q6 are sent, the values
are as follows:
Deficit[7][1] = 400-900 =-500
Deficit[6][1] = 300-400 =-100
– Second round of scheduling
Deficit [7][2] = -500 + 400 = -100
Deficit [6][2] = -100 + 300 = 200
Packet in Q7 is not scheduled because the deficit of Q7 is negative. Packet of 300
bytes in Q6 are sent, the value is as follows:
Deficit [6][2] = 200-300 =-100

– Third round of scheduling

Deficit[7][3] = -100+400 = 300
Deficit[6][3] = -100+300 = 200
Packet of 600 bytes in Q7 and packet of 500 bytes in Q6 are sent, the values are as
follows:
Deficit[7][3] = 300-600 =-300
Deficit[6][3] = 200-500 =-300
Such a process is repeated and finally Q7 and Q6 respectively obtain 20% and 15%
of the bandwidth. This illustrates that you can obtain the required bandwidth by
setting the weights.
In DRR scheduling, short-delay services still cannot be scheduled in time.
l WFQ scheduling
Fair Queuing (FQ) equally allocates network resources so that the delay and jitter of all
flows are minimized.
– Packets in different queues are scheduled fairly. The delays of all flows have slight
difference.
– Packets with different sizes are scheduled fairly. If many large and small packets in
different queues need to be sent, small packets are scheduled first so that the total
packet jitter of each flow is reduced.
Compared with FQ, WFQ schedules packets based on priorities. WFQ schedules packets
with higher priorities before packets with lower priorities.
Before packets enter queues, WFQ classifies the packets based on:
– Session information
WFQ classifies flows based on the session information including the protocol type,
source and destination TCP or UDP port numbers, source and destination IP
addresses, and precedence field in the ToS field. Additionally, the system provides a
large number of queues and equally places flows into queues to smooth out the
delay. When flows leave queues, WFQ allocates the bandwidth on the outbound
interface for each flow based on the precedence of each flow. Flows with the lowest
priorities obtain the least bandwidth. Only the packets matching the default traffic
classifier in CBQ can be classified based on session information.
– Priority
The priority mapping technique marks local priorities for traffic and each local
priority maps a queue number. Each interface is allocated four or eight queues and
packets enter queues. By default, queue weights are the same and traffic equally
shares the interface bandwidth. Users can change weights so that high-priority and
low-priority packets are allocated bandwidth based on weight percentage.

Figure 6-6 WFQ scheduling
Queue 1 weight 1
Packet flow
Queue 2 weight 2 Packet flow
Scheduling
......
Queue N-1 weight N-1
Interface
Classification
Queue N weight N
l PQ+WRR scheduling
PQ scheduling and WRR scheduling have advantages and disadvantages. To offset
disadvantages of PQ scheduling or DRR scheduling, use PQ+WRR scheduling. Packets
from queues with lower priorities can obtain the bandwidth by WRR scheduling and
short-delay services can be scheduled first by PQ scheduling.
On the device, you can set WRR parameters for queues. The eight queues on each
interface are classified into two groups. One group includes queue 7, queue 6, and Queue
5, and is scheduled in PQ mode; the other group includes queue 4, queue 3, queue 2,
queue 1, and queue 0, and is scheduled in WRR mode. Only LAN-side interfaces on the
device support PQ+WRR scheduling. Figure 6-7 shows PQ+WRR scheduling.

Figure 6-7 PQ+WRR scheduling
Queue 7
PQ scheduling
Packet flow
Queue 6
Packet flow
Queue 5
WRR scheduling
Queue 4
Interface
Classification Queue 3
Queue 2
Queue 1
Queue 0
During scheduling, the device first schedules traffic in queue 7, queue 6, and queue 5 in
PQ mode. The device schedules traffic in other queues in WRR mode only after the
traffic in queue 7, queue 6, and queue 5 are scheduled. Queue 4, queue 3, queue 2, queue
1, and queue 0 have their own weights. Important protocol packets or short-delay service
packets must be placed in queues using PQ scheduling so that they can be scheduled
first. Other packets are placed in queues using WRR scheduling.
l PQ+DRR scheduling
Similar to PQ+WRR, PQ+DRR scheduling offsets disadvantages of PQ scheduling and
DRR scheduling. If only PQ scheduling is used, packets in queues with lower priorities
cannot obtain bandwidth for a long period of time. If only DRR scheduling is used,
short-delay services such as voice services cannot be scheduled first. PQ+DRR
scheduling has advantages of both PQ and DRR scheduling and offsets their
disadvantages.
Eight queues on the device interface are classified into two groups. You can specify PQ
scheduling for certain groups and DRR scheduling for other groups.

Figure 6-8 PQ+DRR scheduling
Queue 7
PQ scheduling
Packet flow
Queue 6
Packet flow
Queue 5
DRR scheduling
Queue 4
Interface
Classification Queue 3
Queue 2
Queue 1
Queue 0
As shown in Figure 6-8, the device first schedules traffic in queues 7, 6, and 5 in PQ
mode. After traffic scheduling in queues 7, 6, and 5 is complete, the device schedules
traffic in queues 4, 3, 2, 1, and 0 in DRR mode. Queues 4, 3, 2, 1, and 0 have their own
weight.
Important protocol packets or short-delay service packets must be placed in queues using
PQ scheduling so that they can be scheduled first. Other packets are placed in queues
using DRR scheduling.

Congestion Management Application
Congestion management is often deployed in QoS applications to schedule different services
based on priorities
On the enterprise network shown in Figure 6-9, when multiple services compete for the same
resources (such as the bandwidth and buffer), traffic congestion may occur and high-priority
services may be not processed in a timely manner. The enterprise network can mark different
priorities for different services so that packets enter different queues based on priorities. In
this way, different queue scheduling algorithms can implement differentiated services.

Figure 6-9 Networking of congestion management
Traffic direction
Voice flow Voice server
Data flow
Data server
Video flow
Video server
Congestion management in the outbound direction
Congestion Avoidance Application

When congestion occurs or aggravates, congestion avoidance discards low-priority packets to
relieve network overload and ensure forwarding of high-priority packets.
As shown in Figure 6-10, when two LANs need to communicate through the WAN,
congestion may occur on the edge switch between the WAN and LANs because WAN
bandwidth is lower than LAN bandwidth. Congestion avoidance can be configured on the
edge switch to discard low-priority packets such as data packets, reducing network overload
and ensuring forwarding of high-priority services.
Figure 6-10 Networking of congestion avoidance
Traffic direction
Voice flow
WAN
Data flow
Congestion avoidance in the

Video flow outbound direction


License Support
Congestion management and congestion avoidance are basic features of a switch and are not
under license control.
Version Support
Table 6-2 describes the products and minimum version supporting congestion management
and congestion avoidance.
Table 6-2 Products and minimum version supporting congestion management and congestion
avoidance
Required
S1700 S1720GFR V200R006 (The S1720GFR

and V200R008.)
S2700 S2700SI Congestion management:

Not supported
Congestion avoidance:
V100R006
NOTE
The S2700SI is unavailable in
V200R001 and later versions.



and V200R008.)
S2750EI V200R003
S3700 S3700SI V100R006 (The S3700SI is



Required


S5700 S5700LI/S5700S-LI V200R001
S5710-C-LI V200R001 (The S5710-C-

V200R002 and later
versions.)
S5710-X-LI V200R008



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009


l Table 6-3 lists the specifications of congestion management and congestion avoidance.
Table 6-3 Specifications of congestion management and congestion avoidance
Item Specification
Maximum number of tail drop profiles l S1720GFR in V200R006C10: 7

l S1720GFR in V200R009: 6
l S2720EI: 6
l S2750EI in V200R005 and later
versions: 6
l S5700SI in V200R005: 7
l S5700-10P-LI: 6
l Other S5700LI models except the
S5700-10P-LI in earlier versions than
V200R009: 7
l Other S5700LI models except the
S5700-10P-LI in V200R009: 6
l S5700S-LI in earlier versions than
V200R009: 7
l S5700S-LI in V200R009: 6
l S5710-X-LI in V200R008: 7
l S5710-X-LI in V200R009: 6
l S5720SI/S5720S-SI: 6
Maximum number of WRED drop S5720EI, S5720HI, S6720EI, and

profiles S6720S-EI: 64
6.5 Configuring Congestion Avoidance on the S2750,

S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI
Context
The S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI use tail drop to
prevent congestion. When the length of a queue reaches the maximum value, all the packets
last added to the queue (at the tail of the queue) are discarded. You can set the maximum
number of bytes or packets to be cached in a queue to prevent traffic loss.
NOTE
Before setting the maximum number of bytes or packets to be cached in a queue, run the shutdown
command to shut down the interface. After the maximum number of bytes or packets to be cached in a
queue is set, run the undo shutdown command to enable the interface. These operations may cause
network interruption in a short period of time.

Procedure
Step 1 Run:
system-view

Step 2 Run:
A drop profile is created and the drop profile view is displayed.

Set the maximum number of bytes or packets to be cached in a queue.
l On the S2750 and S5700-10P-LI, run:
qos queue queue-index green max-buffer cell-number non-green max-buffer cell-
number
The maximum number of bytes to be cached in a queue is set.

l On other modules except the S2750 and S5700-10P-LI, run:
qos queue queue-index max-buffer cell-number [ green max-buffer cell-number ]

qos queue queue-index green max-buffer cell-number

l On the S2750 and S5700-10P-LI, run:
qos queue queue-index green max-length packet-number non-green max-length
packet-number
The maximum number of packets to be cached in a queue is set.

qos queue queue-index max-length packet-number [ green max-length packet-
number ]

qos queue queue-index green max-length packet-number

If the maximum number of bytes or packets is reached, the device considers that congestion
occurs and will discard subsequent packets.
Step 4 Run:
quit

Step 5 Run:

Step 6 Run:
shutdown
The interface is shut down.

Step 7 Run:
The tail drop profile is applied to the interface.

Step 8 Run:
undo shutdown
The interface is restarted.
----End

l Run the display qos configuration interface interface-type interface-number command
to check all the QoS configurations on the interface.
queue-index ] command to check the queue-based traffic statistics on the interface.
6.6 Configuring Congestion Avoidance on the S6720EI,

S5720HI, and S5720EI
When packets are discarded due to congestion, configure congestion avoidance on the device.
Then the device processes packets of different services (differentiated by CoS values or
colors) in a different manner, and ensures bandwidth of important services so that less packets
of important services are discarded.
Before configuring congestion avoidance, complete the following task, map the priority of
packets to a per-hop behavior (PHB) and color.
NOTE
Congestion avoidance applies only to unicast traffic.
6.6.1 (Optional) Configuring CFI as the Internal Drop Priority
Context
The Canonical Format Indicator (CFI) in the VLAN tag, also called Drop Eligible Indicator
(DEI), identifies the drop priority of packets in certain situations. When the rate of packets on
certain devices exceeds the committed information rate (CIR) value, the value of the DEI field
is set to 1. In this case, the drop priority of the packets is high. When congestion occurs, the
devices first discard the packets whose DEI field is 1.
If packets whose rate exceeds the CIR need to be discarded, configure CFI as the internal drop
priority.
Procedure
Step 1 Run:
system-view

Enter the system view.
Step 2 Run:
Step 3 Run:
dei enable
CFI is configured as the internal drop priority.
By default, CFI is not configured as the internal drop priority.
----End
6.6.2 Configuring a WRED Drop Profile
Context
WRED randomly discards packets based on drop parameters to prevent global TCP
synchronization, and defines different drop policies based on packet colors. WRED discards
packets based on packet priorities, so the drop probability of packets with higher priorities is
low. A WRED drop profile defines upper and lower drop thresholds and maximum drop
probability for packets of different colors. For more information about packet colors, see 3.6
Configuring Priority Mapping.
Procedure
Step 1 Run:
system-view
Step 2 Run:
drop-profile drop-profile-name
A WRED drop profile is created and the drop profile view is displayed.
By default, the WRED drop profile default exists. The WRED drop profile default can be
modified but cannot be deleted.
Step 3 Run:
color { green | non-tcp | red | yellow } low-limit low-limit-percentage high-
limit high-limit-percentage discard-percentage discard-percentage
WRED parameters are set.
By default, the upper threshold, lower threshold, and maximum drop probability of a WRED
drop profile are 100.

queue-depth queue-depth-value
The length of the port queue is set.

NOTE
Only the S5720HI supports this command.
----End
6.6.3 Applying the WRED Drop Profile
Context
On the device, you can apply a WRED drop profile to an interface, the system, or a queue on
an interface.
If a WRED drop profile is applied to the system and an interface simultaneously, the WRED
drop profile applied to the interface takes effect. After a WRED drop profile is applied to the
system, it takes effect on all the interfaces.If you apply a WRED drop profile to an interface
and a queue on an interface simultaneously, the system first matches the packets with the
profile applied to the queue, and then the profile applied to the interface. Then the device
performs congestion avoidance on the packets that match the WRED drop profile.
Procedure
l Applying a WRED drop profile to the system
a. Run:
system-view

b. Run:
qos queue queue-index wred drop-profile-name
A WRED drop profile is applied to the system.

l Apply a WRED drop profile to a queue on an interface.
a. Run:
system-view

b. Run:

c. Run:
qos queue queue-index wred drop-profile-name
A WRED drop profile is applied to a queue on the interface.
NOTE
The parameter drop-profile-name specifies the name of a WRED drop profile. The value
must be the same as that configured in 6.6.2 Configuring a WRED Drop Profile.
----End


Procedure
l Run the display drop-profile [ all | name drop-profile-name ] command to check the
WRED drop profile configuration.
l Run the display qos configuration interface interface-type interface-number command
to check all the QoS configurations on a specified interface.
----End
6.7 Configuring Congestion Management on the S2750,

When a network is congested intermittently, configure congestion management on the device.
The device then determines the sequence at which packets are forwarded according to the
defined scheduling policy and ensures that high-priority services are scheduled preferentially.
Before configuring congestion management, map the priority of packets to a PHB.
Context
Each interface can be configured with a maximum of eight queues. Different queues can use
different scheduling modes. The device schedules the PQ queue first. If multiple PQ queues
exist, the device schedules the queues in descending order of priority. A larger queue index
indicates higher priority of a queue. After all the PQ queues are scheduled, the device
schedules the WRR or DRR queues in turn.
Procedure
Step 1 Run:
system-view

Step 2 Run:
qos schedule-profile profile-name
A global schedule template is created and the schedule template view is displayed.
Step 3 Run:
qos { pq | wrr | drr }
The scheduling mode of a port queue is set to PQ, WRR, or DRR.

By default, WRR scheduling is used.
Step 4 Configure WRR or DRR weights for port queues.
l If the scheduling mode is WRR, run the qos queue queue-index wrr weight weight
command to set the WRR weight for a port queue.
By default, the weight in WRR mode is 1.

NOTE
Perform this step only when the scheduling mode of a port queue is set to PQ+WRR or WRR.
When WRR scheduling is applied and the weight of a queue is set to 0, the queue applies PQ
scheduling and other queues apply WRR scheduling. When configuring the PQ+WRR scheduling
mode, ensure that the queue with weight 0 (PQ queue) is consecutively configured, without being
interrupted by the configuration of the DRR or WRR queue.
l If the scheduling mode is DRR, run the qos queue queue-index drr weight weight
command to set the DRR weight for a port queue.
By default, the weight in DRR mode is 1.
NOTE
Perform this step only when the scheduling mode of a port queue is set to DRR or PQ+DRR.
When DRR scheduling is applied and the weight of a queue is set to 0, the queue applies PQ
scheduling and other queues apply DRR scheduling.
Step 5 Run:
quit

Step 6 Run:

Step 7 Run:
The scheduling template is applied.

----End

l Run the display qos configuration interface [ interface-type interface-number ]
command to check all the QoS configurations on a specified interface.
queue-index ] command to check the queue-based traffic statistics on the interface.
6.8 Configuring Congestion Management on the S6720EI,

S5720HI, and S5720EI
When a network is congested intermittently, configure congestion management on the device.
The device then determines the sequence at which packets are forwarded according to the
defined scheduling policy and ensures that high-priority services are scheduled preferentially.
Before configuring congestion management, map the priority of packets to a PHB.
Context
Each interface can be configured with a maximum of eight queues. Different queues can use
different scheduling modes. The device schedules the PQ queue first. If multiple PQ queues

exist, the device schedules the queues in descending order of priority. A larger queue index
indicates higher priority of a queue. After all the PQ queues are scheduled, the device
schedules the WRR or DRR queues in turn.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
The scheduling mode of queues on the interface is set to PQ, WRR, or DRR.
By default, the scheduling mode of queues on an interface of the S5720HI is DRR, and the
scheduling mode of queues on an interface of other models is WRR.
Step 4 Configure the weight.
l In WRR scheduling, run:
qos queue queue-index wrr weight weight
The weight for WRR scheduling is set.

By default, the weight for WRR scheduling is 1.
NOTE
This step is required only when the scheduling mode is WRR or PQ+WRR.
When WRR scheduling is applied and the weight of a queue is set to 0, PQ scheduling is used.
That is, the queue uses PQ+WRR.
l In DRR scheduling, run:
qos queue queue-index drr weight weight
The weight for DRR scheduling is set.

By default, the weight for DRR scheduling is 1.
NOTE
This step is required only when the scheduling mode is DRR or PQ+DRR.
When DRR scheduling is applied and the weight of a queue is set to 0, PQ scheduling is used.
That is, the queue uses PQ+DRR.
During queue scheduling on the S5720EI and S6720EI, changing the weight may cause packet
loss within 250 ms.
The S5720HI does not support WRR and PQ+WRR.
----End

l Run the display qos configuration interface [ interface-type interface-number ]
command to check all the QoS configurations on the interface.
queue-index ] command to view queue-based traffic statistics on the interface.

6.9 Configuring Congestion Management on a Stack

Interface of the S2750, S5700LI, S5700S-LI, S5710-X-LI,
After congestion management is configured on a stack interface, if congestion occurs on a
network, the device determines the sequence at which packets are forwarded according to the
defined scheduling policy and ensures that high-priority services are sent preferentially.
Before configuring congestion management on a stack interface, complete the following

tasks:
l Perform the stack configuration.
l Configure priority mapping on inbound interface of packets.
Context
After the stack is configured, stack protocol packets and packets between chassis are
exchanged on the stack interface. If a large number of packets are exchanged, congestion may
occur on the stack interface. As a result, core services such as video services and voice
services cannot be processed in a timely manner. You can set the scheduling mode on the
stack interface so that services with the same priority are processed in the same manner and
services with different priorities are processed based on weights.
Procedure
Step 1 Run:
system-view
Step 2 Run:
A global schedule template is created and the schedule template view is displayed.
Step 3 Run:
The scheduling mode of a port queue is set to PQ, WRR, or DRR.
By default, WRR scheduling is used.
Step 4 Configure WRR or DRR weights for port queues.

l If the scheduling mode is WRR, run the qos queue queue-index wrr weight weight
command to set the WRR weight for a port queue.
By default, the weight in WRR mode is 1.

NOTE
Perform this step only when the scheduling mode of a port queue is set to PQ+WRR or WRR.
When WRR scheduling is applied and the weight of a queue is set to 0, the queue applies PQ
scheduling and other queues apply WRR scheduling. When configuring the PQ+WRR scheduling
mode, ensure that the queue with weight 0 (PQ queue) is consecutively configured, without being
interrupted by the configuration of the DRR or WRR queue.
l If the scheduling mode is DRR, run the qos queue queue-index drr weight weight
command to set the DRR weight for a port queue.
By default, the weight in DRR mode is 1.
NOTE
Perform this step only when the scheduling mode of a port queue is set to DRR or PQ+DRR.
When DRR scheduling is applied and the weight of a queue is set to 0, the queue applies PQ
scheduling and other queues apply DRR scheduling.
Step 5 Run:
quit
Step 6 Run:
stack-port qos schedule-profile profile-name
The scheduling profile is applied.
----End
6.10 Configuring Congestion Management on a Stack

Interfaceon the S6720EI and S5720EI
After congestion management is configured on a stack interface, if congestion occurs on a
network, the device determines the sequence at which packets are forwarded according to the
defined scheduling policy and ensures that high-priority services are sent preferentially.
Before configuring congestion management on a stack interface, complete the following

tasks:
l Perform the stack configuration.
l Configure priority mapping on inbound interface of packets.
Context
After the stack is configured, stack protocol packets and packets between chassis are
exchanged on the stack interface. If a large number of packets are exchanged, congestion may
occur on the stack interface. As a result, core services such as video services and voice
services cannot be processed in a timely manner. You can set the scheduling mode on the
stack interface so that services with the same priority are processed in the same manner and
services with different priorities are processed based on weights.

Procedure
Step 1 Run:
system-view
Step 2 Run:
stack-port qos { pq | wrr | drr }
The scheduling mode of queues on the stack interface is set to PQ, WRR, or DRR.
By default, PQ is used.
Step 3 Run:
stack-port qos queue queue-index { wrr | drr } weight weight
The WRR or DRR weight of queues on the stack interface is set.
When using WRR or DRR scheduling, you can set the weight for each queue. Then the device
schedules queues in turn based on the weights. If the weight of a queue is set to 0, the queue
uses PQ scheduling. In this case, PQ+WRR or PQ+DRR is used.
----End
6.11 Maintaining Congestion Avoidance and Congestion

Management
6.11.1 Displaying Queue-based Traffic Statistics
Procedure
queue-index ] command to view queue-based traffic statistics on the interface.
----End
6.11.2 Clearing Queue-based Traffic Statistics
Context
Before recollecting queue-based traffic statistics on an interface, run the following command
in the user view to clear the existing statistics.
NOTICE
The cleared queue-based traffic statistics cannot be restored. Exercise caution when you run
the command.

Procedure
l Run the reset qos queue statistics interface interface-type interface-number command
to clear queue-based traffic statistics on the interface.
----End
6.12.1 Example for Configuring Congestion Management on the

S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI
As shown in Figure 6-11, The Switch is connected to the router through GE 0/0/3. The
802.1p priorities of voice, video, and data services from the Internet are 7, 5, and 2, and these
services can reach users through the router and Switch. To reduce the impact of network
congestion and ensure bandwidth for high-priority and low-delay services, you need to set the
related parameters according to the following table.
Table 6-4 Congestion management parameters

Service Type CoS WRR
Voice CS7 0
Video EF 20
Data AF2 10

Figure 6-11 Networking diagram for configuring congestion management
Network
Router
GE0/0/3
GE0/0/1 GE0/0/2
Switch
PC TV
802.1p=2 LSW LSW 802.1p=5
802.1p=5 802.1p=7 802.1p=2 802.1p=7
TV Phone PC Phone
1. Configure the VLAN for each interface so that devices can communicate with each other
at the link layer.
2. Configure interfaces to trust 802.1p priorities of packets.
3. Configure the scheduling template and apply the scheduling template to the interface.
Procedure
Step 1 Configure the VLAN for each interface so that devices can communicate with each other at
the link layer.

Step 2 Configure interfaces to trust 802.1p priorities of packets.

[Switch-GigabitEthernet0/0/3] trust 8021p
Step 3 Configure congestion management.

# Create a scheduling template and set queue scheduling parameters.
[Switch] qos schedule-profile p1
[Switch-qos-schedule-profile-p1] qos wrr
[Switch-qos-schedule-profile-p1] qos queue 7 wrr weight 0
[Switch-qos-schedule-profile-p1] quit
# Apply the scheduling template to GE 0/0/1 and GE 0/0/2 of the Switch.

[Switch-GigabitEthernet0/0/1] qos schedule-profile p1
[Switch-GigabitEthernet0/0/2] qos schedule-profile p1

# View the scheduling template and queue scheduling parameters.
[Switch] qos schedule-profile p1
[Switch-qos-schedule-profile-p1] display this
#
qos schedule-profile p1
qos queue 2 wrr weight 10
#
return
----End
Configuration Files
#
sysname Switch
#
vlan batch 10 20 30
#
#
#
trust 8021p
#

#
return
6.12.2 Example for Configuring Congestion Avoidance and

Congestion Managementon the S6720EI, S5720HI, and S5720EI
The Switch is connected to the router through GE 0/0/3; the 802.1p priorities of voice, video,
and data services on the Internet are 6, 5, and 2 respectively, and these services can reach
users through the router and Switch, as shown in Figure 6-12. The rate of incoming interface
GE 0/0/3 on the Switch is greater than the rates of outgoing interfaces GE 0/0/1 and GE 0/0/2;
therefore, congestion may occur on these two outgoing interfaces.
To reduce the impact of network congestion and ensure bandwidth for high-priority and
delay-sensitive services, set the related parameters according to Table 6-5 and Table 6-6.
Table 6-5 Congestion avoidance parameters

Types of Color Lower Upper Drop Percent
Services Threshold (%) Threshold (%)
Voice Green 80 100 10
Video Yellow 60 80 20
Data Red 40 60 40
Table 6-6 Congestion management parameters

Type of Services CoS DRR
Voice EF 0
Video AF3 100
Data AF1 50

Figure 6-12 Networking diagram for configuring congestion avoidance and congestion
management
Network
Router
GE0/0/3
GE0/0/1 GE0/0/2
Switch
802.1p
=2 802.1p PC
PC
=2
Individual
Individual
user n
user 1
802.1p
802.1p 802.1p 802.1p
=5
=5 =6 =6
TV Phone TV Phone
1. Configure the VLAN for each interface so that devices can communicate with each
other.
2. Create and configure a DiffServ domain on the Switch, map packets of 802.1p priorities
to PHBs and colors of packets, and bind the DiffServ domain to an incoming interface on
the Switch.
3. Create a WRED drop profile on the Switch and apply the WRED drop profile on an
outgoing interface.
4. Set scheduling parameters of queues of different CoS on outgoing interfaces of the
Switch.
Procedure
Step 1 Configure the VLAN for each interface so that the devices can communicate with each other.


Step 2 Configure priority mapping based on simple traffic classification.
# Create DiffServ domain ds1, map packets of 802.1p priorities being 6, 5, and 2 to PHBs EF,
AF3, and AF1, and color packets as green, yellow, and red.
[Switch-dsdomain-ds1] 8021p-inbound 6 phb ef green
[Switch-dsdomain-ds1] 8021p-inbound 5 phb af3 yellow
[Switch-dsdomain-ds1] 8021p-inbound 2 phb af1 red
# Bind incoming interface GE 0/0/3 on the Switch to DiffServ domain ds1.

[Switch-GigabitEthernet0/0/3] trust 8021p inner
Step 3 Configure congestion avoidance.
# Create drop profile wred1 on the Switch and set parameters of packets of three colors.
[Switch] drop-profile wred1
[Switch-drop-wred1] color green low-limit 80 high-limit 100 discard-percentage 10
[Switch-drop-wred1] color yellow low-limit 60 high-limit 80 discard-percentage 20
[Switch-drop-wred1] color red low-limit 40 high-limit 60 discard-percentage 40
[Switch-drop-wred1] quit
# Apply drop profile wred1 on outgoing interfaces GE 0/0/1 and GE 0/0/2 of the Switch.
[Switch-GigabitEthernet0/0/1] qos wred wred1
[Switch-GigabitEthernet0/0/1] qos queue 5 wred wred1
[Switch-GigabitEthernet0/0/2] qos wred wred1
Step 4 Configure congestion management.
# Set scheduling parameters of queues of different CoS on outgoing interfaces GE 0/0/1 and
GE 0/0/2 of the Switch.
[Switch-GigabitEthernet0/0/1] qos drr
[Switch-GigabitEthernet0/0/1] qos queue 5 drr weight 0
[Switch-GigabitEthernet0/0/2] qos drr


# Check the configuration of DiffServ domain ds1.
[Switch] display diffserv domain name ds1
diffserv domain name:ds1
8021p-inbound 0 phb be green
8021p-inbound 2 phb af1 red
8021p-inbound 5 phb af3 yellow
8021p-inbound 6 phb ef green
8021p-inbound 7 phb cs7 green
8021p-outbound be green map 0
......
# Check the configuration of drop profile wred1.

[Switch] display drop-profile name wred1
Drop-profile[1]: wred1
Queue depth : default
Color Low-limit High-limit Discard-percentage
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Green 80 100 10
Yellow 60 80 20
Red 40 60 40
Non-tcp 100 100 100
-----------------------------------------------------------------
----End
Configuration Files
#
sysname Switch
#
vlan batch 2 5 to 6
#
diffserv domain ds1
#
drop-profile wred1
color green low-limit 80 high-limit 100 discard-percentage 10
color yellow low-limit 60 high-limit 80 discard-percentage 20
color red low-limit 40 high-limit 60 discard-percentage 40
#
port trunk allow-pass vlan 2 5 to 6
qos drr
qos queue 1 drr weight 50
qos wred wred1
qos queue 1 wred wred1
#
qos drr


qos wred wred1
#
trust upstream ds1
trust 8021p inner
#
return
6.13 References

Headers

Services

Configuration Guide - QoS 7 Packet Filtering Configuration
7 Packet Filtering Configuration
About This Chapter
7.1 Introduction to Packet Filtering

7.3 Configuring Packet Filtering
7.5 References

7.1 Introduction to Packet Filtering

Modular QoS Command-Line Interface (MQC) implements packet filtering.
There are many untrusted packets on networks. An untrusted packet is a packet with potential
security risks or a packet that users do not want to receive. The packet filtering function
allows a device to directly discard untrusted packets to improve network security.
With MQC, a device is configured to identify untrusted packets and discard them, as well as
identify trusted packets and permit them to pass through.
MQC-based packet filtering classifies packets in a more precise manner than a blacklist, and
is more flexible to deploy.

Application of Packet Filtering
Packet filtering allows the device to only permit trusted packets to pass through. The device
discards any untrusted packets. This function improves network security and allows flexible
network planning.
As shown in Figure 7-1, to ensure information security between enterprise R&D,
administrative, and marketing departments, mutual access between enterprise R&D,
administrative, and marketing departments needs to be prevented.
Figure 7-1 Networking of packet filtering
Traffic direction
R&D
department
Marketing
Internet department
Switch A
Administrative
A
department
Configure packet filtering in the outbound direction

7.3 Configuring Packet Filtering

Background
A device configured to use packet filtering implements traffic control to filter packets that
match traffic classification rules.
Procedure
a. Run:
system-view

b. Run:
that:
NOTE

Rule

S5700S-LI, S5710-X-LI, S5720SI,
S5720S-SI)

in QinQ
packets


Rule


802.1p value &<1-8> (S5720EI, S5720HI,
QinQ
packets

and outer
VLAN IDs
of QinQ
packets

actions.

QinQ
packets

address

address

in the
Ethernet
frame
header


Rule
All if-match any -

packets

matches the traffic
of whether the
AND or OR.
traffic classifier
simultaneously.

is AND.
command, a packet
matches the traffic
precedence values,
AND or OR.

protocol
type

packet urg }


Rule

view.


AND or OR.

the ACL6.

traffic policies.
inbound direction.
d. Run:
quit


a. Run:
n Run:
permit
The device is configured to forward packets matching the traffic classifier

based on the original policy.
n Run:
deny
The device is configured to reject packets matching the traffic classifier.

NOTE
l When permit and other actions are configured in a traffic behavior, the actions are
performed in sequence. deny cannot be configured with other actions. When deny is
used, other configured actions except traffic statistics and flow mirroring do not take
effect.
l To specify the packet filtering action for packets matching an ACL rule that defines
permit, the action taken for the packets depends on deny or permit in the traffic
behavior. If the ACL rule defines deny, the packets are discarded regardless of whether
deny or permit is configured in the traffic behavior.
c. (Optional) Run:
statistic enable
The traffic statistics function is enabled.

d. Run:
quit

e. Run:
quit

a. Run:
system-view

run:

NOTE
c. Run:

d. Run:
quit

e. Run:
quit

i. Run:
system-view

ii. Run:

NOTE

IP address.
configuration.
the interface.
iii. Run:

interface.
NOTE

the S6720EI.
i. Run:
system-view

ii. Run:
vlan vlan-id

iii. Run:

direction.
NOTE

i. Run:
system-view

ii. Run:
id ]

simultaneously.
switch.

interface.
NOTE


7.4.1 Example for Configuring Packet Filtering
As shown in Figure 7-2, enterprise users connect to external network devices through
GE0/0/2 on SwitchA.
Packets of different services are identified by 802.1p priorities on the LSW. When packets
reach the external network through GE0/0/2, it is required that data service packets be filtered
and voice and video services be ensured.
Figure 7-2 Networking of packet filtering

Video
802.1p=5
Data
802.1p=2
GE0/0/1 GE0/0/2 Core
Network
Voice LSW SwitchA Router
802.1p=6
You can define the deny action in a traffic policy to filter packets. The configuration roadmap
is as follows:
1. Configure interfaces so that enterprise users can access the external network through
SwitchA.
2. Configure traffic classifiers to classify packets based on 802.1p priorities.
3. Configure traffic behaviors so that the device permits or rejects packets matching rules.
4. Configure a traffic policy, bind the traffic policy to the traffic classifiers and traffic
behaviors, and apply the traffic policy to GE0/0/1 in the inbound direction to filter
packets.
Procedure
[SwitchA] vlan 10
[SwitchA-vlan10] quit
# Configure GE0/0/1 and GE0/0/2 on SwitchA as trunk interfaces and add them to VLAN 10.


NOTE
Configure the interface of the LSW connected to SwitchA as a trunk interface and add it to VLAN 10.
# Create VLANIF 10 and configure IP address 192.168.2.1/24 for it.

[SwitchA] interface vlanif 10
[SwitchA-Vlanif10] ip address 192.168.2.1 24
[SwitchA-Vlanif10] quit
NOTE

# Create and configure traffic classifiers c1, c2, and c3 on SwitchA to classify packets based
on 802.1p priorities.
[SwitchA] traffic classifier c1
[SwitchA-classifier-c1] if-match 8021p 2
[SwitchA-classifier-c1] quit

# Configure a traffic behavior named b1 on SwitchA and define the deny action.
[SwitchA] traffic behavior b1
[SwitchA-behavior-b1] deny
[SwitchA-behavior-b1] quit
# Configure traffic behaviors b2 and b3 on SwitchA and define the permit action.
[SwitchA-behavior-b2] permit
[SwitchA-behavior-b3] permit
Step 4 Configure a traffic policy and apply the traffic policy to an interface.
# Create a traffic policy named p1 on SwitchA, bind the traffic behaviors and traffic
classifiers to the traffic policy, and apply the traffic policy to GE0/0/1 in the inbound direction
to filter packets.
[SwitchA] traffic policy p1
[SwitchA-trafficpolicy-p1] classifier c1 behavior b1
[SwitchA-trafficpolicy-p1] quit
[SwitchA-GigabitEthernet0/0/1] traffic-policy p1 inbound

# Check the traffic classifier configuration.

[SwitchA] display traffic classifier user-defined
Classifier: c2
Operator: AND
Rule(s) : if-match 8021p 5
Classifier: c3
Operator: AND
Classifier: c1
Operator: AND
# Check the traffic policy record.

[SwitchA] display traffic-policy applied-record p1
-------------------------------------------------
Policy Name: p1
Policy Index: 0
Classifier:c1 Behavior:b1
Classifier:c2
Behavior:b2
-------------------------------------------------
*interface
GigabitEthernet0/0/1
slot 0 : success
-------------------------------------------------
Policy total applied times: 1.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
if-match 8021p 2
if-match 8021p 5
if-match 8021p 6
#
traffic behavior b1
deny
traffic behavior b2
permit
traffic behavior b3
permit
#
classifier c1 behavior
b1
classifier c2 behavior
b2
#
interface

Vlanif10
255.255.255.0
#
port link-type
trunk
10
traffic-policy p1
inbound
#
port link-type
trunk
10
#
return
7.5 References

Headers

Services

Configuration Guide - QoS 8 Redirection Configuration
8 Redirection Configuration
About This Chapter
This chapter describes how to configure redirection.

8.1 Introduction to Redirection
Modular QoS Command-Line Interface (MQC) can be used to implement redirection.
8.3 Configuring Redirection
8.5 References

8.1 Introduction to Redirection

Modular QoS Command-Line Interface (MQC) can be used to implement redirection.
Redirection is the process of redirecting packets that match traffic classification rules to a
different destination.
The device supports the following redirection functions:
l Redirection to the CPU: redirects packets to the CPU.
l Redirection to an interface: redirects packets to a specified interface by which packets
need to be processed or through which packets are sent to a specified device.
l Redirection to a next hop address: redirects packets to a next hop address when the
received packets need to be processed by a downstream device. This function is valid for
only Layer 3 packets and can be used to implement PBR. For details about PBR, see
"PBR Configuration" in S2750&S5700&S6720 Series Ethernet Switches Configuration
Guide - IP Routing.
NOTE
The S5720EI, S5720HI, and S6720EI support redirection to the CPU.

The S5720SI, S5720S-SI, S5720EI, S5720HI, and S6720EI support redirection to a next hop address
(that is, PBR).

Application of Redirection
Figure 8-1 shows servers in the service area that need to access the Internet. To prevent
attacks and ensure security of the network and data, packets are redirected to the firewall.

Figure 8-1 Example of a network using redirection
Layer 3
Internet
Router
Layer 2
Firewall Switch A
Switch B
……
User 1 User N
Configure redirection
Traffic direction
Service Deployment
l Configure a traffic classifier to match all packets.

l Configure a traffic behavior to redirect matching traffic to the firewall.
l Configure a traffic policy, bind the traffic policy to the traffic classifier and traffic
behavior, and apply the traffic behavior to the inbound direction of SwitchA so that all
traffic from the Internet is redirected to the firewall.
8.3 Configuring Redirection

Background
A device configured with the redirection action redirects the packets matching traffic
classification rules to the CPU or an interface.

A traffic policy that contains redirection can only be applied in the inbound direction of the
system, interface or VLAN.
NOTE
The S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI do not support redirection to
the CPU.
If redirect interface is configured in a traffic behavior, you are advised to apply the traffic policy
containing the traffic behavior only to Layer 2 data traffic.
Procedure
a. Run:
system-view

b. Run:
that:
NOTE

Rule

S5700S-LI, S5710-X-LI, S5720SI,
S5720S-SI)

in QinQ
packets


Rule


802.1p value &<1-8> (S5720EI, S5720HI,
QinQ
packets

and outer
VLAN IDs
of QinQ
packets

actions.

QinQ
packets

address

address

in the
Ethernet
frame
header


Rule
All if-match any -

packets

matches the traffic
of whether the
AND or OR.
traffic classifier
simultaneously.

is AND.
command, a packet
matches the traffic
precedence values,
AND or OR.

protocol
type

packet urg }


Rule

view.


AND or OR.

the ACL6.

traffic policies.
inbound direction.
d. Run:
quit


a. Run:
n Run:
redirect interface interface-type interface-number [ forced ]
The device is configured to redirect packets matching the traffic classifier to a

specified interface.
NOTE
After traffic is redirected to an interface in Down state, if forced is specified, traffic is

lost on the interface and is not switched to the original forwarding path. If forced is
not configured, redirection does not take effect.
n Run:
redirect cpu
The device is configured to redirect packets matching the traffic classifier to

the CPU.
NOTICE
After the traffic policy containing redirect cpu is applied, the device redirects
traffic matching traffic classification rules to the CPU, affecting system
performance. Exercise caution when you run the redirect cpu command.
c. Run:
quit

d. Run:
quit

a. Run:
system-view

run:

NOTE
c. Run:

d. Run:
quit

e. Run:
quit

NOTE
The traffic policy containing redirection cannot be applied in the outbound direction.
– Apply a traffic policy to an interface.
i. Run:
system-view

ii. Run:
The interface view or sub-interface view is displayed.

NOTE

IP address.
configuration.
the interface.
iii. Run:
traffic-policy policy-name inbound

i. Run:
system-view

ii. Run:
vlan vlan-id

iii. Run:
traffic-policy policy-name inbound

NOTE
To apply traffic policies, the device must have sufficient ACL resources. Otherwise,
traffic policies may fail to be applied. For example, an if-match rule in a traffic policy
occupies an ACL. When the traffic policy is applied to M interfaces, M ACLs are
occupied. When a traffic policy is applied to a VLAN or in the system, the number of
occupied ACLs is the number of LPUs on the device. For details about ACLs occupied
by if-match rules, see Table 2-4 in 2.2 Configuration Notes.
– Apply a traffic policy to the system.
i. Run:
system-view

ii. Run:
id ]

simultaneously.
○ In a stack scenario, a traffic policy that is applied to the system takes
effect on all the interfaces and VLANs of all the member switches in the
stack. The system then performs traffic policing for all the incoming and
outgoing packets that match traffic classification rules on all the member
switches. A traffic policy that is applied to a specified slot takes effect on
all the interfaces and VLANs of the member switch with the specified

stack ID. The system then performs traffic policing for all the incoming
and outgoing packets that match traffic classification rules on this
member switch.
○ In a non-stack scenario, a traffic policy that is applied to the system takes

interface.
NOTE

8.4.1 Example for Configuring Redirection
As shown in Figure 8-2, enterprise users need to access the Internet. User devices connect to
the gateway router through access switch SwitchB and core switch SwitchA, and
communicate with the Internet through the gateway.
To ensure enterprise data and network security, the enterprise wants to ensure security of all
traffic from the Internet to servers.
This example illustrates how to configure redirection to send all traffic from the external
network to the internal network to the firewall.

Figure 8-2 Networking of redirection

Lay 3
Internet
Router
GE0/0/1 Lay 2
GE0/0/3
Firewall Switch A
GE0/0/4
GE0/0/2
GE0/0/1
Switch B
GE0/0/2 GE0/0/3
……
User 1 User N
VLAN200 VLAN100
Traffic direction
l Connect SwitchA to the core firewall in bypass mode to filter traffic.
l Configure the device to redirect all traffic from the Internet to the firewall because traffic
entering the firewall is Layer 2 traffic.
l Configure port isolation on the interface of SwitchA connected to the firewall to prevent
loops, and disable MAC address learning to prevent MAC address flapping.
Procedure
Step 1 Create VLANs and configure interfaces to ensure Layer 2 connectivity.
# Create VLAN 100 and VLAN 200 on SwitchB.

[SwitchB] vlan batch 100 200

# Configure GE0/0/2 and GE0/0/3 on SwitchB as access interfaces, add GE0/0/2 to VLAN
200 and GE0/0/3 to VLAN 100, and configure GE0/0/1 as a trunk interface and add GE0/0/1
to VLAN 100 and VLAN 200.
[SwitchB-GigabitEthernet0/0/2] port link-type access
[SwitchB-GigabitEthernet0/0/2] port default vlan 200
[SwitchB-GigabitEthernet0/0/1] port trunk allow-pass vlan 100 200
# Create VLAN 100 and VLAN 200 on SwitchA.

[SwitchA] vlan batch 100 200
# Configure GE0/0/1, GE0/0/2, GE0/0/3, and GE0/0/4 on SwitchA as trunk interfaces and add
them to VLAN 100 and VLAN 200. Add GE0/0/3 and GE0/0/4 to the same port isolation
group. Disable MAC address learning on GE0/0/4 to prevent MAC address flapping.
[SwitchA-GigabitEthernet0/0/1] port trunk allow-pass vlan 100 200
[SwitchA-GigabitEthernet0/0/3] port-isolate enable
[SwitchA-GigabitEthernet0/0/4] mac-address learning disable
Step 2 Configure MQC to implement redirection to an interface.
# Configure a traffic classifier.

[SwitchA-classifier-c1] if-match any
# Configure a traffic behavior.

[SwitchA-behavior-b1] redirect interface gigabitethernet 0/0/3
# Configure a traffic policy.

[SwitchA] traffic policy p1
[SwitchA-trafficpolicy-p1] quit
# Apply the traffic policy to GigabitEthernet0/0/1 on SwitchA in the inbound direction.

[SwitchA-GigabitEthernet0/0/1] traffic-policy p1 inbound

[SwitchA] quit
# Check the traffic classifier configuration.

<SwitchA> display traffic classifier user-defined c1
User Defined Classifier
Information:
Classifier:
c1
Operator:
AND
Rule(s) : if-match any
# View the traffic behavior configuration.

<SwitchA> display traffic behavior user-defined b1
User Defined Behavior Information:
Behavior: b1
Redirect: no
forced
Redirect interface GigabitEthernet0/0/3
# Check the traffic policy configuration.

<SwitchA> display traffic policy user-defined p1
User Defined Traffic Policy
Information:
Policy:
p1
Classifier:
c1
Operator:
AND
Behavior:
b1
Redirect: no
forced
Redirect interface GigabitEthernet0/0/3
# Check the traffic policy record.

<SwitchA> display traffic-policy applied-record
#
-------------------------------------------------
Policy Name: p1
Policy Index: 0
-------------------------------------------------
*interface GigabitEthernet0/0/1
slot 0 : success
-------------------------------------------------
Policy total applied times: 1.
#
----End

Configuration Files
#
sysname SwitchA
#
vlan batch 100 200
#
if-match any
#
traffic behavior b1
redirect interface GigabitEthernet0/0/3
#
#
#
#
port-isolate enable group 1
#
mac-address learning disable
#
return

#
sysname SwitchB
#
vlan batch 100 200
#
#
port link-type access
port default vlan 200
#
#
return

8.5 References

Headers

Services

Configuration Guide - QoS 9 Traffic Statistics Configuration
9 Traffic Statistics Configuration
About This Chapter
This chapter describes how to configure traffic statistics.

9.1 Introduction to Traffic Statistics
9.3 Configuring Traffic Statistics

9.1 Introduction to Traffic Statistics

After MQC is used to implement traffic statistics, the device collects statistics on packets
matching traffic classification rules. The statistics on forwarded and discarded packets
matching a traffic policy help you check whether the traffic policy is correctly applied and
locate faults.
You can run the display traffic policy statistics command to view the statistics on forwarded
and discarded packets matching a traffic policy only after MQC is used to implement traffic
statistics.
Table 9-1 describes the differences between traffic statistics and interface statistics.
Table 9-1 Differences between traffic statistics and interface statistics

Statistics Display Range Remarks
Collection Mode Command
Traffic statistics display traffic Packets matching The packets do not

policy statistics traffic classification include packets sent
rules after a traffic to the CPU.
policy is applied
Interface statistics display interface All packets on an The packets include

interface packets sent to the
CPU.

Application of Traffic Statistics
As shown in Figure 9-1, different users on the enterprise campus network connects to the
Internet through the switch and router. To analyze and evaluate traffic on the entire enterprise
campus network, configure traffic statistics for different users separately.
Figure 9-1 Networking of traffic statistics
Router
Network
Switch
Traffic direction
Configure traffic statistics
in the inbound direction

Service Deployment
l Configure a traffic classifier based on MAC addresses to differentiate different types of
data traffic.
l Configure a traffic behavior and define traffic statistics in the traffic behavior.
l Configure a traffic policy, bind the traffic classifier and traffic behavior to the traffic
policy, and apply the traffic policy to the inbound direction of the switch so that the
device collects statistics on packets from different users.
9.3 Configuring Traffic Statistics

Background
After the traffic statistics function is enabled, the device collects statistics on packets
matching traffic classification rules. The statistics on forwarded and discarded packets
matching a traffic policy help you check whether the traffic policy is correctly applied and
locate faults.
The S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI can only count the
number of packets and not the number of bytes.
Procedure
a. Run:
system-view

b. Run:
that:

NOTE

Rule

S5700S-LI, S5710-X-LI, S5720SI,
S5720S-SI)

in QinQ
packets


802.1p value &<1-8> (S5720EI, S5720HI,
QinQ
packets

and outer
VLAN IDs
of QinQ
packets

actions.


Rule

QinQ
packets

address

address

in the
Ethernet
frame
header
All if-match any -

packets

matches the traffic
of whether the
AND or OR.
traffic classifier
simultaneously.


Rule

is AND.
command, a packet
matches the traffic
precedence values,
AND or OR.

protocol
type

packet urg }

view.



Rule

AND or OR.

the ACL6.

traffic policies.
inbound direction.
d. Run:
quit

a. Run:
b. Run:
statistic enable
The traffic statistics function is enabled.

By default, the traffic statistics function is disabled.
c. Run:
quit

d. Run:
quit

a. Run:
system-view

run:
NOTE
c. Run:

d. Run:
quit

e. Run:
quit


i. Run:
system-view

ii. Run:

NOTE

IP address.
configuration.
the interface.
iii. Run:

interface.
NOTE

the S6720EI.
i. Run:
system-view

ii. Run:
vlan vlan-id

iii. Run:

direction.

NOTE
i. Run:
system-view

ii. Run:
id ]

simultaneously.
switch.

interface.

NOTE

9.4.1 Example for Configuring Traffic Statistics
As shown in Figure 9-2, the MAC address of PC1 is 0000-0000-0003, and PC1 connects to
GE0/0/1 on the Switch. The Switch is required to collect statistics on packets with the source
MAC address of 0000-0000-0003.
Figure 9-2 Networking for configuring traffic statistics

Network
10.10.10.1/24
PC1 Switch Router
MAC:0000-0000-0003
You can define the traffic statistics action in a traffic policy. The configuration roadmap is as
follows:
1. Configure interfaces so that the Switch can connect to the router and PC1.
2. Configure an ACL to match packets with the source MAC address of 0000-0000-0003.
3. Configure a traffic classifier and reference the ACL in the traffic classifier.
4. Configure a traffic behavior so that the Switch collects statistics on packets matching
rules.
5. Configure a traffic policy, bind the traffic policy to the traffic classifier and traffic
behavior, and apply the traffic policy to the inbound direction of GE0/0/1 so that the
Switch collects statistics on packets with the source MAC address of 0000-0000-0003.
Procedure

[Switch] vlan 20
# Configure GE0/0/1 as an access interface and GE0/0/2 as a trunk interface, and add them to
VLAN 20.
[Switch-GigabitEthernet0/0/1] port link-type access
[Switch-GigabitEthernet0/0/1] port default vlan 20

NOTE
Step 2 Configure an ACL.

# Create ACL 4000 (Layer 2 ACL) on the Switch to match packets with the source MAC
address of 0000-0000-0003.
[Switch] acl 4000
[Switch-acl-L2-4000] rule permit source-mac 0000-0000-0003 ffff-ffff-ffff
[Switch-acl-L2-4000] quit
Step 3 Configure a traffic classifier.

# Create a traffic classifier c1 on the Switch and reference ACL 4000 in the traffic classifier.
Step 4 Configure a traffic behavior.

# Create a traffic behavior b1 on the Switch and configure the traffic statistics action in the
traffic behavior.
Step 5 Configure a traffic policy and apply the traffic policy to an interface.
# Create a traffic policy p1 on the Switch and bind the traffic policy to the traffic classifier
and traffic behavior.
# Apply the traffic policy p1 to GE0/0/1.


# View the ACL configuration.

[Switch] display acl 4000

L2 ACL 4000, 1 rule
Acl's step is 5
rule 5 permit source-mac 0000-0000-0003

Classifier: c1
Operator: AND

Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
Statistic: enable
# View the traffic statistics.

Interface:
Rule number: 1
Current status:
success
Statistics interval: 300
---------------------------------------------------------------------
Board : 0
---------------------------------------------------------------------
Matched | Packets: 0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
Passed | Packets: 0
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
| Bytes: 0
| Rate(pps): 0
| Rate(bps): 0
---------------------------------------------------------------------
Filter | Packets: 0
| Bytes: 0
---------------------------------------------------------------------
Car | Packets: 0
| Bytes: 0
---------------------------------------------------------------------
----End
Configuration Files
#
sysname Switch

#
vlan batch 20
#
acl number 4000
#
if-match acl 4000
#
traffic behavior b1
statistic enable
#
#
interface Vlanif20
ip address 10.10.10.2 255.255.255.0
#
port link-type
access
traffic-policy p1
inbound
#
port link-type
trunk
20
#
return

Configuration Guide - QoS 10 ACL-based Simplified Traffic Policy Configuration
10 ACL-based Simplified Traffic Policy

Configuration
About This Chapter
This chapter describes how to configure an ACL-based simplified traffic policy. The device to
which an ACL-based simplified traffic policy is applied filters, polices, re-marks, counts,
mirrors, or redirects packets matching access control list (ACL) rules.
10.1 Overview of the ACL-based Simplified Traffic Policy

10.3 Configuring ACL-based Packet Filtering
10.4 Configuring ACL-based Traffic Policing on the S2750, S5700LI, S5700S-LI, S5710-X-
LI, S5720SI, and S5720S-SI
10.5 Configuring ACL-based Traffic Policingon the S6720EI, S5720HI, and S5720EI
10.6 Configuring ACL-based Redirection on the S2750, S5700LI, S5700S-LI, and S5710-X-
LI
10.7 Configuring ACL-based Redirectionon the S6720EI, S5720HI, S5720SI, S5720S-SI, and
S5720EI
ACL-based redirection allows the device to redirect packets matching an ACL to the CPU, a
specified interface, or a specified next hop address..
10.8 Configuring ACL-based Re-marking
10.9 Configuring ACL-based Traffic Statistics
10.10 Configuring ACL-based Traffic Mirroring
10.11 Maintaining an ACL-based Simplified Traffic Policy
10.12 Configuration Example

10.1 Overview of the ACL-based Simplified Traffic Policy

The device to which an ACL-based simplified traffic policy is applied matches packet
characteristics with access control list (ACL) rules and provides the same QoS for packets
matching ACL rules, implementing differentiated services.
To control traffic entering a network, configure ACL rules to match information such as the
source IP address, fragment flag, destination IP address, source port number, and source MAC
address in packets and then configure an ACL-based simplified traffic policy so that the
device can filter, polices, re-marks, counts, mirrors, or redirects packets matching ACL rules.
Compared with a common traffic policy, an ACL-based simplified traffic policy is easy to
configure because you do not need to configure a traffic classifier, traffic behavior, or traffic
policy independently. However, an ACL-based simplified traffic policy defines less matching
rules than a common traffic policy because only ACL rules are used to match packets.

License Support
The ACL-based simplified traffic policy is a basic feature of a switch and is not under license
control.
Version Support
Table 10-1 describes the products and minimum version supporting the ACL-based simplified
traffic policy.
Table 10-1 Products and minimum version supporting the ACL-based simplified traffic
policy

Required
S1700 S1720GFR V200R006 (The S1720GFR

and V200R008.)



Required


and V200R008.)
S2750EI V200R003
S3700 S3700SI V100R006 (The S3700SI is



S5700 S5700LI/S5700S-LI V200R001
S5710-C-LI V200R001 (The S5710-C-

V200R002 and later
versions.)
S5710-X-LI V200R008



S5720EI V200R007
S5720SI/S5720S-SI V200R008




Required
S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

l When multiple ACL-based simplified traffic policies are configured on an interface, in a
VLAN, or in the system and the ACL referenced by one ACL-based simplified traffic
policy changes, all ACL-based simplified traffic policies will become invalid
temporarily.
l If the traffic-redirect (interface view) or traffic-redirect (system view) command is
executed to redirect traffic to an interface, you are advised to use ACL rules to match
Layer 2 traffic.
l Outbound ACL-based packet filtering, traffic policing, re-marking, or traffic statistics on
an interface does not take effect on the S1720GFR, S2720EI, S2750, S5700LI, S5700S-
LI, S5710-X-LI, S5720SI, and S5720S-SI in the following situations:
– Outbound ACL-based packet filtering, traffic policing, re-marking, or traffic
statistics is configured, and the ACL is based on VLAN IDs.
– VLAN mapping is also configured on the interface, and the mapped VLAN ID is
the same as the VLAN ID in the ACL.
l The S5720HI does not support simplified traffic policies based on user-defined ACLs.
l If the ACL rule matches the VPN instance name of packets, the simplified ACL-based
traffic policy fails to be delivered.
10.3 Configuring ACL-based Packet Filtering

ACL-based packet filtering allows the device to permit or reject packets matching ACL rules
to control network traffic.
Before configuring ACL-based packet filtering, complete the following tasks:

l Configure an ACL.
You can run the traffic-filter or traffic-secure command to configure packet filtering based
on the following rules:
l If the ACL referenced by the traffic-filter or traffic-secure command is not referenced
by other ACL-based simplified traffic policies, and packets do not match both ACLs

associated with packet filtering and simplified traffic policies, use traffic-filter or
traffic-secure.
l If the ACL referenced by the traffic-filter or traffic-secure command is referenced by
other ACL-based simplified traffic policies, or packets match both ACLs associated with
packet filtering and simplified traffic policies, the differences between the traffic-filter
and traffic-secure commands are as follows:
– When the traffic-secure command and other ACL-based simplified traffic policies
are configured simultaneously, and the ACL defines the deny action, only the
traffic-secure, traffic-mirror, and traffic-statistics commands take effect and
packets are filtered.
– When the traffic-secure command and other ACL-based simplified traffic policies
are configured simultaneously, and the ACL defines the permit action, the traffic-
secure command and other ACL-based simplified traffic policies take effect.
– When the traffic-filter command and other ACL-based simplified traffic policies
are configured simultaneously, and the ACL defines the deny action, only the
traffic-filter, traffic-mirror, and traffic-statistics commands take effect and
packets are filtered.
– When the traffic-filter command and other ACL-based simplified traffic policies
are configured simultaneously, and the ACL defines the permit action, the traffic
policy that was configured first takes effect.
NOTE
The S2750EI, S5700-10P-LI-AC, and S5700-10P-PWR-LI-AC that are enabled with Layer 3 hardware
forwarding for IPv4 packets do not support traffic-secure.
Procedure
l Configuring packet filtering globally or in a VLAN
a. Run:
system-view

n Run:
traffic-filter [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl |
adv-acl | name acl-name } | l2-acl | user-acl } [ rule rule-id ]
The device is configured to filter incoming packets matching an ACL.

n Run:
traffic-secure [ vlan vlan-id ] inbound acl { bas-acl | adv-acl | l2-
acl | name acl-name } [ rule rule-id ]

n Run:
traffic-filter [ vlan vlan-id ] outbound acl { [ ipv6 ] {bas-acl |
adv-acl | name acl-name } | l2-acl } [ rule rule-id ]
The device is configured to filter outgoing packets matching an ACL.

n Run:
traffic-filter [ vlan vlan-id ] { inbound | outbound } acl { l2-acl
| name acl-name } [ rule rule-id ] acl { bas-acl | adv-acl | name
acl-name } [ rule rule-id ]
Or,

traffic-filter [ vlan vlan-id ] { inbound | outbound } acl { bas-acl

| adv-acl | name acl-name } [ rule rule-id ] acl { l2-acl | name acl-
name } [ rule rule-id ]
The device is configured to filter packets matching Layer 2 and Layer 3 ACLs.
n Run:
traffic-secure [ vlan vlan-id ] inbound acl { l2-acl | name acl-
name } [ rule rule-id ] acl { bas-acl | adv-acl | name acl-name }
[ rule rule-id ]
The device is configured to filter incoming packets matching Layer 2 and

Layer 3 ACLs.
l Configuring packet filtering on an interface
a. Run:
system-view

b. Run:

n Run:
traffic-filter inbound acl { [ ipv6 ] { bas-acl | adv-acl | name acl-
name } | l2-acl | user-acl } [ rule rule-id ]

n Run:
traffic-secure inbound acl { bas-acl | adv-acl | l2–acl | name acl-
name } [ rule rule-id ]

n Run:
traffic-filter outbound acl { [ ipv6 ] {bas-acl | adv-acl | name acl-
name } | l2-acl } [ rule rule-id ]
The device is configured to filter outgoing packets matching an ACL.

n Run:
traffic-filter { inbound | outbound } acl { l2-acl | name acl-name }
[ rule rule-id ] acl { bas-acl | adv-acl | name acl-name } [ rule
rule-id ]
Or,
traffic-filter { inbound | outbound } acl { bas-acl | adv-acl | name
acl-name } [ rule rule-id ] acl { l2-acl | name acl-name } [ rule
rule-id ]
The device is configured to filter packets matching Layer 2 and Layer 3 ACLs.
n Run:
traffic-secure inbound acl { l2–acl | name acl-name } [ rule rule-
id ] acl { bas-acl | adv-acl | name acl-name } [ rule rule-id ]
The device is configured to filter incoming packets matching Layer 2 and

Layer 3 ACLs.
----End

10.4 Configuring ACL-based Traffic Policing on the S2750,

ACL-based traffic policing allows the device to limit the rate of packets matching ACLs and
take different actions for packets of different colors.
Before configuring ACL-based traffic policing, complete the following tasks:
l Configure IP addresses and routing protocols for interfaces to ensure connectivity.
l Configure an ACL.
Procedure
l Configuring traffic policing globally or in a VLAN
a. Run:
system-view

n Run:
traffic-limit [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl |
adv-acl | name acl-name } | l2-acl | user-acl } [ rule rule-id ] cir
cir-value [ pir pir-value ] [ cbs cbs-value pbs pbs-value ] [ green
pass ] [ yellow { drop | pass [ remark-8021p 8021p-value | remark-
dscp dscp-value ] } ] [ red { drop | pass [ remark-8021p 8021p-value
| remark-dscp dscp-value ] } ]
Traffic policing is configured for incoming packets matching an ACL.

n Run:
traffic-limit [ vlan vlan-id ] outbound acl { [ ipv6 ] { bas-acl |
adv-acl | name acl-name } | l2-acl } [ rule rule-id ] } cir cir-
value [ pir pir-value ] [ cbs cbs-value pbs pbs-value ] [ green
pass ] [ yellow pass ] [ red { drop | pass } ]
Traffic policing is configured for outgoing packets matching an ACL.

n Run:
traffic-limit [ vlan vlan-id ] inbound acl { l2-acl | name acl-
[ rule rule-id ] cir cir-value [ pir pir-value ] [ cbs cbs-value pbs
pbs-value ] [ green pass ] [ yellow { drop | pass [ remark-8021p
8021p-value | remark-dscp dscp-value ] } ] [ red { drop | pass
[ remark-8021p 8021p-value | remark-dscp dscp-value ] } ]
Traffic policing is configured for incoming packets matching Layer 2 and

Layer 3 ACLs.
n Run:
traffic-limit [ vlan vlan-id ] outbound acl { l2-acl | name acl-
pbs-value ] [ green pass ] [ yellow pass ] [ red { drop | pass } ]
Traffic policing is configured for outgoing packets matching Layer 2 and

Layer 3 ACLs.

NOTE
Traffic policing can define packet colors:

l When the size of a packet is less than the CBS, the packet is colored green.
l When the size of a packet is greater than or equal to the CBS but less than the PBS, the
packet is colored yellow.
l When the size of a packet is greater than or equal to the PBS, the packet is colored red.
By default, green packets and yellow packets are allowed to pass through, and red packets
are discarded.
l Configuring traffic policing on an interface
a. Run:
system-view

b. Run:

n Run:
traffic-limit inbound { acl { [ ipv6 ] { bas-acl | adv-acl | name
acl-name } | l2-acl | user-acl } } [ rule rule-id ] cir cir-value
[ pir pir-value ] [ cbs cbs-value pbs pbs-value ] [ green pass ]
[ yellow { drop | pass [ remark-8021p 8021p-value | remark-dscp dscp-
value ] } ] [ red { drop | pass [ remark-8021p 8021p-value | remark-
dscp dscp-value ] } ]

n Run:
traffic-limit outbound { acl { [ ipv6 ] { bas-acl | adv-acl | name
acl-name } | l2-acl } } [ rule rule-id ] } cir cir-value [ pir pir-
value ] [ cbs cbs-value pbs pbs-value ] [ green pass ] [ yellow
pass ] [ red { drop | pass } ]

n Run:
traffic-limit inbound acl { l2-acl | name acl-name } [ rule rule-
id ] acl { bas-acl | adv-acl | name acl-name } [ rule rule-id ] cir
pass ] [ yellow { drop | pass [ remark-8021p 8021p-value | remark-
dscp dscp-value ] } ] [ red { drop | pass [ remark-8021p 8021p-value
| remark-dscp dscp-value ] } ]

Layer 3 ACLs.
n Run:
traffic-limit outbound acl { l2-acl | name acl-name } [ rule rule-
pass ] [ yellow pass ] [ red { drop | pass } ]

Layer 3 ACLs.
----End

10.5 Configuring ACL-based Traffic Policingon the

S6720EI, S5720HI, and S5720EI
ACL-based traffic policing allows the device to limit the rate of packets matching ACLs and
take different actions for packets of different colors.
Before configuring ACL-based traffic policing, complete the following tasks:

l Configure an ACL.
Procedure
l Configuring traffic policing globally or in a VLAN
a. Run:
system-view

n Run:
traffic-limit [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl |
adv-acl | name acl-name } | l2-acl | user-acl } [ rule rule-id ] cir
cir-value [ pir pir-value ] [ cbs cbs-value pbs pbs-value ]
[ [ green { drop | pass } ] [ yellow { drop | pass } ] [ red { drop
| pass } ] ]

n Run:
traffic-limit [ vlan vlan-id ] outbound acl { [ ipv6 ] { bas-acl |
adv-acl | name acl-name } | l2-acl } [ rule rule-id ] cir cir-value
[ pir pir-value ] [ cbs cbs-value pbs pbs-value ] [ [ green { drop |
pass } ] [ yellow { drop | pass } ] [ red { drop | pass } ] ]

n Run:
traffic-limit [ vlan vlan-id ] inbound acl { l2-acl | name acl-
pbs-value ] [ [ green { drop | pass } ] [ yellow { drop | pass } ]
[ red { drop | pass } ] ]

Layer 3 ACLs.
n Run:
traffic-limit [ vlan vlan-id ] inbound acl { bas-acl | adv-acl |
name acl-name } [ rule rule-id ] acl { l2-acl | name acl-name }

Layer 3 ACLs.

n Run:
traffic-limit [ vlan vlan-id ] outbound acl { l2-acl | name acl-

Layer 3 ACLs.
n Run:
traffic-limit [ vlan vlan-id ] outbound acl { bas-acl | adv-acl |
name acl-name } [ rule rule-id ] acl { l2-acl | name acl-name }

Layer 3 ACLs.
NOTE
Traffic policing can define packet colors:

l When the size of a packet is less than the CBS, the packet is colored green.
l When the size of a packet is greater than or equal to the CBS but less than the PBS, the
packet is colored yellow.
l When the size of a packet is greater than or equal to the PBS, the packet is colored red.
By default, green packets and yellow packets are allowed to pass through, and red packets
are discarded.
l Configuring traffic policing on an interface
a. Run:
system-view

b. Run:

n Run:
traffic-limit inbound acl { [ ipv6 ] { bas-acl | adv-acl | name acl-
name } | l2-acl | user-acl } [ rule rule-id ] cir cir-value [ pir
pir-value ] [ cbs cbs-value pbs pbs-value ] [ [ green { drop |
pass } ] [ yellow { drop | pass } ] [ red { drop | pass } ] ]

n Run:
traffic-limit outbound acl { [ ipv6 ] { bas-acl | adv-acl | name acl-
name } | l2-acl } [ rule rule-id ] cir cir-value [ pir pir-value ]
[ cbs cbs-value pbs pbs-value ] [ [ green { drop | pass } ] [ yellow
{ drop | pass } ] [ red { drop | pass } ] ]

n Run:
traffic-limit inbound acl { bas-acl | adv-acl | name acl-name }
[ rule rule-id ] acl { l2-acl | name acl-name } [ rule rule-id ] cir
| pass } ] ]


Layer 3 ACLs.
n Run:
traffic-limit inbound acl { l2-acl | name acl-name } [ rule rule-
| pass } ] ]

Layer 3 ACLs.
n Run:
traffic-limit outbound acl { l2-acl | name acl-name } [ rule rule-
| pass } ] ]

Layer 3 ACLs.
Run:
traffic-limit outbound acl { bas-acl | adv-acl | name acl-name }
[ rule rule-id ] acl { l2-acl | name acl-name } [ rule rule-id ] cir
| pass } ] ]

Layer 3 ACLs.
----End
10.6 Configuring ACL-based Redirection on the S2750,

S5700LI, S5700S-LI, and S5710-X-LI
ACL-based redirection allows the device to redirect packets matching an ACL to the CPU or
a specified interface.
Before configuring ACL-based redirection, complete the following tasks:
l Configure IP addresses and routing protocols for interfaces to ensure connectivity.
l Configure an ACL.
Procedure
l Configuring ACL-based redirection globally or in a VLAN
a. Run:
system-view

n Run:

traffic-redirect [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl |

{ cpu | interface interface-type interface-number }
The device is configured to redirect incoming packets matching an ACL.

n Run:
traffic-redirect [ vlan vlan-id ] inbound acl { l2-acl | name acl-
[ rule rule-id ] { cpu | interface interface-type interface-number }
The device is configured to redirect incoming packets matching Layer 2 and

Layer 3 ACLs.
l Configuring ACL-based redirection on an interface
a. Run:
system-view

b. Run:

n Run:
traffic-redirect inbound acl { [ ipv6 ] { bas-acl | adv-acl | name
acl-name } | l2-acl | user-acl } [ rule rule-id ] { cpu | interface
interface-type interface-number }

n Run:
traffic-redirect inbound acl { l2-acl | name acl-name } [ rule rule-
{ cpu | interface interface-type interface-number }

Layer 3 ACLs.
----End
10.7 Configuring ACL-based Redirectionon the S6720EI,

S5720HI, S5720SI, S5720S-SI, and S5720EI
ACL-based redirection allows the device to redirect packets matching an ACL to the CPU, a
specified interface, or a specified next hop address..
Before configuring ACL-based redirection, complete the following tasks:
l Configure an ACL.
Procedure
l Configuring ACL-based redirection globally or in a VLAN
a. Run:

system-view

n Run:
traffic-redirect [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl |
{ cpu | interface interface-type interface-number | ip-nexthop ip-
nexthop | ipv6-nexthop ipv6-nexthop }

n Run:
traffic-redirect [ vlan vlan-id ] inbound acl { l2-acl | name acl-
[ rule rule-id ] { cpu | interface interface-type interface-number |
ip-nexthop ip-nexthop | ipv6-nexthop ipv6-nexthop }

Layer 3 ACLs.
l Configuring ACL-based redirection on an interface
a. Run:
system-view

b. Run:

n Run:
traffic-redirect inbound acl { [ ipv6 ] { bas-acl | adv-acl | name
acl-name } | l2-acl | user-acl } [ rule rule-id ] { cpu | interface
interface-type interface-number | ip-nexthop ip-nexthop | ipv6-
nexthop ipv6-nexthop }

n Run:
traffic-redirect inbound acl { l2-acl | name acl-name } [ rule rule-
{ cpu | interface interface-type interface-number | ip-nexthop ip-
nexthop | ipv6-nexthop ipv6-nexthop }

Layer 3 ACLs.
----End
10.8 Configuring ACL-based Re-marking
ACL-based re-marking allows the device to re-mark priorities of packets matching an ACL,
for example, MAC address, 802.1p priorities in VLAN packets and DSCP priorities in IP
packets.
Before configuring ACL-based re-marking, complete the following tasks:

l Configure an ACL.
Procedure
l Configuring ACL-based re-marking globally or in a VLAN
a. Run:
system-view

n Run:
traffic-remark [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl |
{ 8021p 8021p-value | dscp { dscp-name | dscp-value } | local-
precedence local-precedence-value | ip-precedence ip-precedence-
value | vlan-id vlan-id }
The device is configured to re-mark incoming packets matching an ACL.

n Run:
traffic-remark [ vlan vlan-id ] outbound acl { [ ipv6 ] { bas-acl |
adv-acl | name acl-name } | l2-acl } [ rule rule-id ] { 8021p 8021p-
value | cvlan-id cvlan-id | dscp { dscp-name | dscp-value } | vlan-
id vlan-id }
The device is configured to re-mark outgoing packets matching an ACL.

n Run:
traffic-remark [ vlan vlan-id ] inbound acl { l2-acl | name acl-
[ rule rule-id ] { 8021p 8021p-value | dscp { dscp-name | dscp-
value } | local-precedence local-precedence-value | ip-precedence ip-
precedence-value | vlan-id vlan-id }
The device is configured to re-mark incoming packets matching Layer 2 and

Layer 3 ACLs.
n Run:
traffic-remark [ vlan vlan-id ] outbound acl { l2-acl | name acl-
[ rule rule-id ] { 8021p 8021p-value | cvlan-id cvlan-id | dscp
{ dscp-name | dscp-value } | vlan-id vlan-id }
The device is configured to re-mark outgoing packets matching Layer 2 and

Layer 3 ACLs.
NOTE
The S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI cannot re-mark
inner VLAN tags in QinQ packets.
l Configuring ACL-based re-marking on an interface
a. Run:
system-view

b. Run:


n Run:
traffic-remark inbound acl { [ ipv6 ] { bas-acl | adv-acl | name acl-
name } | l2-acl | user-acl } [ rule rule-id ] { 8021p 8021p-value |
dscp { dscp-name | dscp-value } | local-precedence local-precedence-
value | ip-precedence ip-precedence-value | vlan-id vlan-id }
The device is configured to re-mark incoming packets matching an ACL.

n Run:
traffic-remark outbound acl { [ ipv6 ] { bas-acl | adv-acl | name
acl-name } | l2-acl } [ rule rule-id ] { 8021p 8021p-value | cvlan-
id cvlan-id | dscp { dscp-name | dscp-value } | vlan-id vlan-id }
The device is configured to re-mark outgoing packets matching an ACL.

n Run:
traffic-remark inbound acl { l2-acl | name acl-name } [ rule rule-
{ 8021p 8021p-value | dscp { dscp-name | dscp-value } | local-
precedence local-precedence-value | ip-precedence ip-precedence-
value | vlan-id vlan-id }
The device is configured to re-mark incoming packets matching Layer 2 and

Layer 3 ACLs.
n Run:
traffic-remark outbound acl { l2-acl | name acl-name } [ rule rule-
{ 8021p 8021p-value | cvlan-id cvlan-id | dscp { dscp-name | dscp-
value } | vlan-id vlan-id }
The device is configured to re-mark outgoing packets matching Layer 2 and

Layer 3 ACLs.
NOTE
The S2750, S5700LI, S5700S-LI, S5710-X-LI, S5720SI, and S5720S-SI cannot re-mark
inner VLAN tags in QinQ packets.
----End
10.9 Configuring ACL-based Traffic Statistics

ACL-based traffic statistics allows the device to collect statistics on packets matching an
ACL.
Before configuring ACL-based traffic statistics, complete the following tasks:

l Configure an ACL.
Procedure
l Configuring ACL-based traffic statistics globally or in a VLAN
a. Run:
system-view


n Run:
traffic-statistic [ vlan vlan-id ] inbound acl { [ ipv6 ] { bas-acl
| adv-acl | name acl-name } | l2-acl | user-acl } [ rule rule-id ]
[ by-bytes ]
The device is configured to collect statistics on incoming packets matching an

ACL.
n Run:
traffic-statistic [ vlan vlan-id ] outbound acl { [ ipv6 ] { bas-acl
| adv-acl | name acl-name } | l2-acl | user-acl } [ rule rule-id ]
The device is configured to collect statistics on outgoing packets matching an

ACL.
n Run:
traffic-statistic [ vlan vlan-id ] inbound acl { l2-acl | name acl-
[ rule rule-id ] [ by-bytes ]
The device is configured to collect statistics on incoming packets matching

Layer 2 and Layer 3 ACLs.
n Run:
traffic-statistic [ vlan vlan-id ] outbound acl { l2-acl | name acl-
[ rule rule-id ]
The device is configured to collect statistics on outgoing packets matching

l Configuring ACL-based traffic statistics on an interface
a. Run:
system-view

b. Run:

n Run:
traffic-statistic inbound acl { [ ipv6 ] {bas-acl | adv-acl | name
acl-name } | l2-acl | user-acl } [ rule rule-id ] [ by-bytes ]
The device is configured to collect statistics on incoming packets matching an

ACL.
n Run:
traffic-statistic outbound acl { [ ipv6 ] {bas-acl | adv-acl | name
acl-name } | l2-acl } [ rule rule-id ]
The device is configured to collect statistics on outgoing packets matching an

ACL.
n Run:
traffic-statistic inbound acl { l2-acl | name acl-name } [ rule rule-
id ] acl { bas-acl | adv-acl | name acl-name } [ rule rule-id ] [ by-
bytes ]
The device is configured to collect statistics on incoming packets matching

n Run:

traffic-statistic outbound acl { l2-acl | name acl-name } [ rule

rule-id ] acl { bas-acl | adv-acl | name acl-name } [ rule rule-id ]
The device is configured to collect statistics on outgoing packets matching

----End
10.10 Configuring ACL-based Traffic Mirroring

ACL-based traffic mirroring allows the device to mirror packets matching an ACL rule to a
specified interface for the ease of packet analysis.
For details on how to configure traffic mirroring using ACLs, see "Configuring ACL-based
Local Traffic Mirroring" and "Configuring ACL-based Remote Traffic Mirroring" in the
S2750&S5700&S6720 Series Ethernet Switches Configuration Guide - Network Management
and Monitoring.
10.11 Maintaining an ACL-based Simplified Traffic Policy
10.11.1 Displaying Statistics on ACL-based Packet Filtering
Context
After ACL-based packet filtering is configured on the device, you can run the following
command to view statistics on forwarded and discarded packets.
Procedure
l Run the following commands to view statistics about ACL-based packet filtering on the
device.
– display traffic-statistics [ vlan vlan-id | interface interface-type interface-
number ] { inbound | outbound } [ acl { bas-acl | adv-acl | user-acl } [ rule rule-
id ] ]
number ] { inbound | outbound } [ acl { acl-name | l2-acl } [ rule rule-id ] [ acl
{ bas-acl | adv-acl | acl-name } [ rule rule-id ] ] ]
– display traffic-statistics interface { inbound | outbound }
number ] { inbound | outbound } [ acl ipv6 { bas-acl | adv-acl | acl-name } [ rule
rule-id ] ]
----End
10.11.2 Clearing Statistics on ACL-based Packet Filtering
Context
To recollect statistics on ACL-based packet filtering, run the following command to clear
existing statistics.

NOTICE
The cleared statistics on ACL-based packet filtering cannot be restored. Exercise caution
when you run the command.
Procedure
l Run the following commands to clear statistics about ACL-based packet filtering on the
device.
– reset traffic-statistics [ vlan vlan-id | interface interface-type interface-number ]
{ inbound | outbound } [ acl { bas-acl | adv-acl | user-acl } [ rule rule-id ] ]
{ inbound | outbound } [ acl { acl-name | l2-acl } [ rule rule-id ] [ acl { bas-acl |
adv-acl | acl-name } [ rule rule-id ] ] ]
– reset traffic-statistics { interface | vlan } { inbound | outbound }
{ inbound | outbound } [ acl ipv6 { bas-acl | adv-acl | acl-name } [ rule rule-id ] ]
----End
10.12 Configuration Example
10.12.1 Example for Preventing a Specified Host to Access the

External Network
As shown in Figure 10-1, enterprise users connect to external network devices through
GE0/0/2 of the switch.
During work hours from 8:30 to 18:00, GE0/0/1 filters packets and prevents access to the
external network.

Figure 10-1 Networking for preventing a specified host to access the external network
IP:192.168.1.10/24
HostA
IP:192.168.1.11/24
GE0/0/1 GE0/0/2
Network
HostB LSW Switch Router
IP:192.168.1.12/24
Enterprise Traffic
campus network direction
HostC
You can define the deny action in a traffic policy to filter packets. The configuration roadmap
is as follows:
1. Configure interfaces so that enterprise users can access the external network through the
Switch.
2. Configure a time range and reference the time range in an ACL.
3. Configure an ACL to deny packets during work hours.
4. Configure packet filtering in the inbound direction of GE0/0/1.
Procedure

[Switch] vlan 10
# Configure GE0/0/1 and GE0/0/2 on the Switch as trunk interfaces and add them to VLAN
10.
NOTE
Configure the interface of the LSW connected to the Switch as a trunk interface and add it to VLAN 10.


NOTE
Step 2 Create a periodic time range working_time that defines work hours from 8:30 to 18:00.
[Switch] time-range working_time 08:30 to 18:00 working-day
Step 3 Configure ACL 3001 and define three rules to prevent packets from 192.168.1.10,
192.168.1.11, and 192.168.1.12 passing through during work hours.
[Switch-acl-adv-3001] rule deny ip source 192.168.1.10 0 time-range
working_time
[Switch-acl-adv-3001] rule deny ip source 192.168.1.11 0 time-range working_time
[Switch-acl-adv-3001] rule deny ip source 192.168.1.12 0 time-range working_time
[Switch-acl-adv-3001] quit
Step 4 Configure packet filtering in the inbound direction of GE0/0/1.

[Switch-GigabitEthernet0/0/1] traffic-filter inbound acl 3001

# Check information about ACL rules and actions on the interface in the inbound direction.
[Switch] display traffic-applied interface gigabitethernet 0/0/1 inbound
-----------------------------------------------------------
ACL applied inbound interface GigabitEthernet0/0/1
ACL 3001
rule 5 deny ip source 192.168.1.10 0 time-range working_time (match-counter 0)
ACTIONS:
filter
-----------------------------------------------------------
ACL 3001
ACTIONS:
filter
-----------------------------------------------------------
ACL 3001
ACTIONS:
filter
-----------------------------------------------------------
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
time-range working_time 08:30 to 18:00 working-day
#
acl number
3001
rule 5 deny ip source 192.168.1.10 0 time-range

working_time
rule 10 deny ip source 192.168.1.11 0 time-range
working_time
rule 15 deny ip source 192.168.1.12 0 time-range working_time
#
interface
Vlanif10
255.255.255.0
#
port link-type
trunk
10
traffic-filter inbound acl
3001
#
port link-type
trunk
10
#
return
10.12.2 Example for Configuring Rate Limiting for Services from

Different VLANs
respectively.
Traffic policing needs to be configured on the Switch to police packets of different services so
that traffic is limited within a proper range and bandwidth of each service is guaranteed.
Table 10-2 describes QoS required by different services.

Traffic Type CIR (kbit/s) PIR (kbit/s)
Voice 2000 10000
Video 4000 10000
Data 4000 10000

Phone
VLAN 120
SwitchA GE0/0/1
PC GE0/0/2
Network
TV
Enterprise Traffic
campus network direction
VLAN 110
1. Create VLANs and configure interfaces so that the enterprise can access the Network
through the Switch.
2. Configure ACLs on the Switch to match services from different VLANs.
3. Configure ACL-based traffic policing on the Switch to limit different packets from the
enterprise.
Procedure
# Configure GE0/0/1 and GE0/0/2 as trunk interfaces, and add GE0/0/1 and GE0/0/2 to
VLAN 100, VLAN 110, and VLAN 120.

# Configure Layer 2 ACLs on the Switch to classify different service flows from the
enterprise based on the VLAN ID.
[Switch] acl 4001
[Switch-acl-L2-4001] rule 1 permit vlan-id 120

[Switch] acl 4002
[Switch] acl 4003
Step 3 Configure traffic policing.

# Configure traffic policing in the inbound direction of GE0/0/1 on the Switch to limit
different packets from the enterprise.

[Switch-GigabitEthernet0/0/1] traffic-limit inbound acl 4001 cir 2000 pir 10000

# Check information about ACLs and actions on the interface in the inbound direction.
-----------------------------------------------------------
ACL 4001
rule 1 permit vlan-id 120
ACTIONS:
limit cir 2000 ,cbs 250000
pir 10000 ,pbs 1250000
green : pass
yellow : pass
red : drop
-----------------------------------------------------------
ACL 4002
ACTIONS:
pir 10000 ,pbs 1250000
green : pass
yellow : pass
red : drop
-----------------------------------------------------------
ACL 4003
ACTIONS:
pir 10000 ,pbs 1250000
green : pass
yellow : pass
red : drop
-----------------------------------------------------------
----End
Configuration Files
Switch configuration file
#
sysname Switch
#

#
acl number 4001
acl number 4002
acl number 4003
#
traffic-limit inbound acl 4001 cir 2000 pir 10000 cbs 250000 pbs 1250000
#
#
return
10.12.3 Example for Configuring ACL-based Redirection
As shown in Figure 10-3, enterprise users need to access the Internet. User devices connect to
the gateway router through access switch SwitchB and core switch SwitchA and communicate
with the Internet through the gateway.
To ensure enterprise data and network security, the enterprise wants to ensure security of all
traffic from the Internet to servers. Redirection can be configured to send all traffic from the
external network to the internal network to the firewall.

Figure 10-3 Networking for configuring redirection

Lay 3
Internet
Router
GE0/0/1 Lay 2
GE0/0/3
Firewall Switch A
GE0/0/4
GE0/0/2
GE0/0/1
Switch B
GE0/0/2 GE0/0/3
……
User 1 User N
VLAN200 VLAN100
Traffic direction
l Connect SwitchA to the core firewall in bypass mode to filter traffic.
l Configure the device to redirect all traffic from the Internet to the firewall because traffic
entering the firewall is Layer 2 traffic.
l Configure port isolation on the interface of SwitchA connected to the firewall to prevent
loops, disable MAC address learning to prevent MAC address flapping..
Procedure
Step 1 Create VLANs and configure interfaces to ensure Layer 2 connectivity.
# Create VLAN 100 and VLAN 200 on SwitchB.
[SwitchB] vlan batch 100 200

# Configure GE0/0/2 and GE0/0/3 on SwitchB as access interfaces, add GE0/0/2 to VLAN
200 and GE0/0/3 to VLAN 100; configure GE0/0/1 as a trunk interface and add GE0/0/1 to
VLAN 100 and VLAN 200.
[SwitchB-GigabitEthernet0/0/1] port trunk allow-pass vlan 100 200
# Create VLAN 100 and VLAN 200 on SwitchA.

[SwitchA] vlan batch 100 200
# Configure GE0/0/1, GE0/0/2, GE0/0/3, and GE0/0/4 on SwitchA as trunk interfaces and add
them to VLAN 100 and VLAN 200. Add GE0/0/3 and GE0/0/4 to the same port isolation
group. Disable MAC address learning on GE0/0/4 to prevent MAC address flapping.
[SwitchA-GigabitEthernet0/0/4] mac-address learning disable
Step 2 Configure ACL-based redirection so that the firewall filters traffic.

# Configure a basic ACL to match all forwarded packets.
[SwitchA] acl 4001
[SwitchA-acl-L2-4001] rule permit vlan-id 100
[SwitchA-acl-L2-4001] rule permit vlan-id 200
[SwitchA-acl-L2-4001] quit
# Configure redirection to a specified interface in the inbound direction of

GigabitEthernet0/0/1 on SwitchA.
[SwitchA-GigabitEthernet0/0/1] traffic-redirect inbound acl 4001 interface
gigabitethernet 0/0/3

# Check information about the ACL and action on the interface in the inbound direction.
[SwitchA] display traffic-applied interface gigabitethernet 0/0/1 inbound
-----------------------------------------------------------

ACL 4001
ACTIONS:
-----------------------------------------------------------
ACL 4001
ACTIONS:
-----------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 200
#
acl number 4001
#
traffic-redirect inbound acl 4001 interface GigabitEthernet0/0/3
#
#
#
mac-address learning disable
#
return

#
sysname SwitchB
#
vlan batch 100 200
#
#
#
#
return

10.12.4 Example for Configuring an ACL-based Simplified Traffic

Policy to Implement Priority Mapping
As shown in Figure 10-4, GE0/0/3 on the Switch connects to the router. Enterprise
departments 1 and 2 access the Internet through the switch and router. Enterprise departments
1 and 2 belong to VLAN 100 and VLAN 200 respectively.
Enterprise branch 1 requires better QoS guarantee. 802.1p priorities of packets from
enterprise departments 1 and 2 are both 0. Priority mapping needs to be configured to map
priorities of packets from enterprise departments 1 and 2 to 4 and 2 respectively so that
differentiated services are provided.
Core Network
Router
GE0/0/3
GE0/0/1 GE0/0/2
VLAN 100 Switch VLAN 200
Enterprise Enterprise
department 1 department 2
1. Create VLANs and configure interfaces so that enterprise departments 1 and 2 can
connect to the Internet through the Switch.
2. Configure ACLs to differentiate packets from enterprise departments based on the
VLAN ID.
3. Configure priority mapping on inbound interfaces GE0/0/1 and GE0/0/2 of the Switch.

Procedure

# Configure GE0/0/1, GE0/0/2, and GE0/0/3 as trunk interfaces, add GE0/0/1 and GE0/0/2 to
VLAN 100 and VLAN 200, and add GE0/0/3 to VLAN 100 and VLAN 200.
Step 2 Configure priority mapping.
# Configure ACL 4001 and 4002 on the Switch to differentiate packets from enterprise
departments based on the VLAN ID.
[Switch] acl 4001

[Switch-acl-L2-4001] rule permit vlan-id 100
[Switch] acl 4002
[Switch-acl-L2-4002] rule permit vlan-id 200
Step 3 Configure priority mapping on inbound interfaces GE0/0/1 and GE0/0/2 of the Switch.
[Switch-GigabitEthernet0/0/1] traffic-remark inbound acl 4001 8021p 4
[Switch-GigabitEthernet0/0/2] traffic-remark inbound acl 4002 8021p 2
# Check information about ACL rules and actions on the interface in the inbound direction.
-----------------------------------------------------------
ACL 4001
ACTIONS:
remark 8021p 4
-----------------------------------------------------------
-----------------------------------------------------------
ACL 4002
ACTIONS:

remark 8021p 2
-----------------------------------------------------------
----End
Configuration Files
#
sysname Switch
#
vlan batch 100 200
#
acl number
4001
rule 5 permit vlan-id

100
acl number
4002

#
traffic-remark inbound acl 4001 8021p 4
#
traffic-remark inbound acl 4002 8021p 2
#
#
return
10.12.5 Example for Configuring ACL-based Traffic Statistics
As shown in Figure 10-5, the MAC address of PC1 is 0000-0000-0003, and PC1 connects to
GE0/0/1 on the Switch. The Switch is required to collect statistics on packets with the source
MAC address of 0000-0000-0003.
Figure 10-5 Networking for configuring traffic statistics

Network
10.10.10.1/24
PC1 Switch Router
MAC:0000-0000-0003

Configure an ACL to match packets with the specified source MAC address so that the
Switch collects statistics on the packets. The configuration roadmap is as follows:
1. Configure interfaces so that the Switch can connect to the router and PC1.
2. Configure an ACL to match packets with the source MAC address of 0000-0000-0003.
3. Configure traffic statistics in the inbound direction of GE0/0/1 so that the statistics on
packets with the source MAC address of 0000-0000-0003 are collected.
Procedure
[Switch] vlan 20
# Configure GE0/0/1 as an access interface and GE0/0/2 as a trunk interface, and add them to
VLAN 20.
[Switch-GigabitEthernet0/0/1] port link-type access
[Switch-GigabitEthernet0/0/1] port default vlan 20

NOTE

# Create ACL 4000 (Layer 2 ACL) on the Switch to match packets with the source MAC
address of 0000-0000-0003.
[Switch] acl 4000
[Switch-acl-L2-4000] rule permit source-mac 0000-0000-0003 ffff-ffff-ffff
Step 3 Configure traffic statistics.

# Configure ACL-based traffic statistics in the inbound direction of GE0/0/1.
[Switch-GigabitEthernet0/0/1] traffic-statistic inbound acl 4000 by-bytes

# Check information about the ACL and action on the interface in the inbound direction.
-----------------------------------------------------------

ACL 4000
ACTIONS:
statistic by bytes
-----------------------------------------------------------
# Check the traffic statistics.

[Switch] display traffic-statistics interface gigabitethernet 0/0/1 inbound acl
4000
---------------------------------------------------------------------------
Interface
ACL:4000 Rule:
5
matched:681.575M Bytes, passed:681.575M Bytes, dropped:0 Bytes

---------------------------------------------------------------------------
----End
Configuration Files
#
sysname Switch
#
vlan batch 20
#
acl number 4000
#
interface Vlanif20
ip address 10.10.10.2 255.255.255.0
#
port link-type
access
traffic-statistic inbound acl 4000 by-
bytes
#
port link-type
trunk
20
#
return
10.12.6 Example for Configuring ACL-based Local Flow Mirroring
As shown in Figure 10-6, HostA connects to SwitchA through GigabitEthernet0/0/1. The
server directly connects to GigabitEthernet0/0/2 on SwitchA.
The server (monitoring device) is required to monitor packets with the 802.1p priority of 6
sent by HostA.

Figure 10-6 Networking of local flow mirroring

GE0/0/1 GE0/0/2
HostA SwitchA Server
1. Configure GigabitEthernet0/0/2 as the local observing interface so that the server can
receive mirroring packets.
2. Configure a Layer 2 ACL to match packets with the 802.1p priority of 6.
3. Configure an ACL-based traffic policy on GigabitEthernet0/0/1 to mirror packets with
the 802.1p priority of 6.
Procedure
Step 1 Configure an observing interface.
# Configure GigabitEthernet0/0/2 on SwitchA as the observing interface

[SwitchA] observe-port 1 interface gigabitethernet 0/0/2
Step 2 Configure a Layer 2 ACL to match packets with the 802.1p priority of 6.
# Create ACL 4001 (Layer 2 ACL) on SwitchA to match packets with the 802.1p priority of
6.
[SwitchA] acl 4001
[SwitchA-acl-L2-4001] rule permit 8021p 6
[SwitchA-acl-L2-4001] quit
Step 3 Configure an ACL-based traffic policy.
# Configure an ACL-based traffic policy on GigabitEthernet0/0/1 to mirror packets with the

802.1p priority of 6.
[SwitchA-GigabitEthernet0/0/1] traffic-mirror inbound acl 4001 to observe-port 1
[SwitchA] quit
# Check the ACL-based traffic policy that has been applied to GigabitEthernet0/0/1 and the
traffic behavior.
<SwitchA> display traffic-applied interface gigabitethernet 0/0/1 inbound
-----------------------------------------------------------
ACL 4001
rule 5 permit 8021p 6
ACTIONS:
mirror to observe-port 1
-----------------------------------------------------------

The preceding information shows that the traffic behavior in the ACL-based traffic policy
defines the action of mirroring packets with the 802.1p priority of 6 on GigabitEthernet0/0/1.
----End
Configuration Files
#
sysname SwitchA
#
observe-port 1 interface GigabitEthernet0/0/2
#
acl number 4001
rule 5 permit 8021p 6
#
traffic-mirror inbound acl 4001 to observe-port 1
#
return

Configuration Guide - QoS 11 HQoS Configuration
11 HQoS Configuration
About This Chapter
This chapter configures how to configure Hierarchical Quality of Service (HQoS). HQoS uses
queue-based hierarchical scheduling to differentiate service flows from different users and
provide fine-granular service quality.
11.1 Introduction to HQoS
11.2 Principles
11.3 Applications
11.6 Configuring HQoS
11.7 Maintaining HQoS

11.1 Introduction to HQoS

Hierarchical Quality of Service (HQoS) uses queue-based hierarchical scheduling to provide
fine-granular quality guarantee for services of different users.
Traditional QoS technologies can provide differentiated services to meet requirements of
voice, video, and data services. However, these technologies are facing new problems as
access users grow in number and the service volume of each user increases continuously.
l Traditional QoS schedules traffic based on the interface bandwidth, so service traffic can
be differentiated based on the service level. However, it is difficult to differentiate
services based on users. Traditional QoS is applicable to the core layer, but inapplicable
to the access layer.
l Traditional QoS cannot manage or schedule traffic of multiple services from multiple
users simultaneously.
To address these issues, HQoS is introduced to differentiate user traffic and schedule traffic
based on service priorities. HQoS uses multiple levels of queues to further differentiate
service traffic, and provides uniform management and hierarchical scheduling for
transmission objects such as users and services. HQoS enables network devices to control
internal resources with the existing hardware, providing QoS guarantee for advanced users
while reducing network construction cost.
NOTE
Only the S5720HI supports the HQoS function.
11.2 Principles
HQoS implements hierarchical scheduling based on queues. The device supports flow queue
(FQ) and subscriber queue (SQ). The HQoS hierarchy is a tree structure, with flow queues as
the leaf nodes and subscriber queues as root nodes. Packets on an interface are first sent to
leaf nodes and then sent out of the root node upon scheduling. In addition, packets can be
further scheduled. For example, the packets can be scheduled in port queues. The device
supports the mapping between flow queues and port queues to schedule the same service from
different users, as shown in Figure 11-1.

Figure 11-1 HQoS scheduling

Flow queue (FQ) Subscriber queue (SQ) Interface Queue (IQ) Target port (TP)
FQ 0
FQ 1
FQ 2 SQ 0
FQ 3 PQ 0
PQ/WFQ
FQ 4 PQ 1
FQ 5 PQ 2
......
shapping
PQ/DRR
FQ 6 PQ 3
TP
FQ 7 shapping
PQ 4
Shapping/ shapping
WRED PQ 5
FQ 0 PQ 6
FQ 1 PQ 7
PQ/WFQ
...... SQ N
FQ 7
Flow Queue
Based on the DiffServ model, HQoS sends packets to flow queues based on mapped internal
priorities to differentiate services. Each user has eight flow queues that correspond to eight
service priorities (BE, AF1, AF2, AF3, AF4, EF, CS6, and CS7). You can configure Priority
Queuing (PQ) or Weighted Fair Queueing (WFQ) for the eight flow queues. Each flow queue
supports Weighted Random Early Detection (WRED) and traffic shaping to ensure that high-
priority services are scheduled preferentially and obtain higher bandwidth.
Subscriber Queue
Subscriber queues differentiate users. Here, a user refers to a VLAN or VPN. Users are
differentiated using access control lists (ACLs). Each user has a subscriber queue that is an
aggregation of eight flow queues. Traffic shaping can be configured for a subscriber queue to
limit the total bandwidth of each user.
Interface Queue
Similar to flow queues, eight port queues correspond to eight service types. You can configure
PQ or Deficit Round Robin (DRR) scheduling for eight port queues. Each queue supports
WRED and traffic shaping. For details, see 6.8 Configuring Congestion Management on
the S6720EI, S5720HI, and S5720EI, 6.6 Configuring Congestion Avoidance on the
S6720EI, S5720HI, and S5720EI, and 5.7 Configuring Traffic Shaping. The device
supports the mapping between flow queues (BE, AF1, AF2, AF3, AF4, EF, CS6, and CS7)
and port queues. The mapping allows the device to flexibly send service traffic in a flow
queue to a port queue.

Target Port
The target port is a physical interface through which data is sent out. After flow Queue and
subscriber Queue scheduling and port queue scheduling are complete, traffic shaping can be
performed for each target port. For details, see 5.8.2 Configuring Outbound Interface-
based Rate Limiting.
11.3 Applications
Voice, video, and data services from multiple users are transmitted on an enterprise campus
network. Because the bandwidth is limited, different guaranteed bandwidth values are
allocated to users in VLAN 10 and VLAN 20, and different scheduling priorities are set for
the three services of each user. Bandwidth guarantee needs to be provided for the voice,
video, and data services in descending order of priority. To meet the requirements, deploy
HQoS, as shown in Figure 11-2.
Figure 11-2 HQoS networking
Video, data, voice
VLAN10 Traffic direction

User 1
Video, data, voice

SwitchA
User 2
Internet
Video, data, voice

Switch Router
VLAN20
User 3
Video, data, voice SwitchB
User 4 Priority mapping in the inbound direction

HQoS in the outbound direction
Service Deployment
l Deploy priority mapping to map packet priorities of different services to local priorities
and mark packets in different colors.
l Deploy ACLs to differentiate users.
l Deploy HQoS to implement differentiated services based on users and services.


License Support
HQoS is a basic feature of a switch and is not under license control.
Version Support
Only the S5720HI in V200R006 and later versions supports HQoS.

l Table 11-1 describes the specifications of HQoS.
Table 11-1 Specifications of HQoS

Item Specifications
Maximum number of flow queues 65528
Maximum number of subscriber queues 8191
Maximum number of flow queues for 16376

which traffic statistics can be collected
Maximum number of port queues 8
Maximum number of flow queue WRED 128

drop profiles
Maximum number of flow queue profiles 128
Maximum number of flow mapping 8

profiles
l The device supports only HQoS in the outbound direction.

l When each service flow of different users has the same priority, the device cannot
provide congestion management for service flows based on users.

Table 11-2 describes default settings of a flow queue WRED drop profile; Table 11-3
describes default settings of a flow queue profile; Table 11-4 describes default settings of a
flow mapping profile; Table 11-5 describes the mapping between internal priorities and flow
queues, which cannot be changed.

Table 11-2 Default settings of a flow queue WRED drop profile
Flow queue WRED drop profile default

name
Lower drop threshold (red, 100

yellow, and green packets)
Upper drop threshold (red, 100

Maximum drop probability (red, 100

Table 11-3 Default settings of a flow queue profile
Flow queue profile name default
Queue scheduling mode PQ scheduling
Traffic shaping rate PIR
WRED drop profile default
Table 11-4 Default settings of a flow mapping profile
Flow mapping profile name default
Queue mapping Flow queues 0 to 7 corresponding to port

queues 0 to 7 respectively
Table 11-5 Mappings between internal priorities and flow queues
Internal Priority Flow Queue Index
BE 0
AF1 1
AF2 2
AF3 3
AF4 4
EF 5

Internal Priority Flow Queue Index
CS6 6
CS7 7
11.6 Configuring HQoS

After HQoS is configured, the device can differentiate multiple services of different users and
offer different scheduling modes to implement fine-granular services.
Before configuring HQoS, configure priority mapping and map packet priorities to CoS
values or colors.
HQoS Configuration Process

Figure 11-3 shows the HQoS configuration process.
1. To configure different drop priorities for different service packets, configure a flow
queue WRED drop profile and define parameters in the flow queue WRED drop profile.
2. Configure a flow queue profile, and set the scheduling mode and traffic shaping
parameters in the profile. If a flow queue WRED drop profile has been configured, bind
the flow queue profile to the flow queue WRED drop profile.
3. When the same service traffic from users with different priorities needs to be scheduled
or shaped, for example, the data service of user A has higher priority than that of user B,
configure a traffic mapping profile and parameters to adjust the mapping between flow
queues and port queues.
4. Configure a subscriber queue and traffic shaping parameters for the subscriber queue,
and reference the flow queue profile if the flow mapping profile has been configured.
Figure 11-3 HQoS configuration process
Configure flow queue

WRED drop profile and
parameters
Configure flow queue Configure flow mapping

profile and parameters profile and parameters
Configure subscriber
queue and parameters
to implement HQoS
Mandatory
Optional

NOTE
The device supports only HQoS in the outbound direction.
11.6.1 Configuring a Flow Queue
Context
Priority mapping enables the device to map packet priorities (802.1p/DSCP priorities) to local
priorities and mark packet colors. Packets enter different flow queues according to the
mapped local priorities so that differentiated services are implemented. For details about
priority mapping, see 3.6 Configuring Priority Mapping.
Procedure
Step 1 (Optional) Configure a flow queue WRED drop profile and congestion avoidance parameters.
1. Run:
system-view

2. Run:
flow-wred-profile flow-wred-profile-name
A flow queue WRED drop profile is created or the view of an existing flow queue
WRED drop profile is displayed.
By default, the system predefines a flow queue WRED drop profile default. This flow
queue WRED drop profile cannot be modified or deleted.
3. Run:
color { green | yellow | red } low-limit low-limit-percentage high-limit high-
limit-percentage discard-percentage discard-percentage
The upper and lower drop thresholds and maximum drop probability are set.
4. (Optional) Run:
queue-depth queue-depth-value
The flow queue length is set.

5. Run:
quit
Exit from the flow queue WRED drop profile view.
NOTE
In the flow queue WRED drop profile default, the upper and lower drop thresholds and maximum
drop probability are 100. To adjust parameters in the flow queue WRED drop profile to implement
congestion avoidance, perform the preceding configurations. If the preceding configurations are
not performed, a flow queue references the flow queue WRED drop profile default.
Step 2 Configure a flow queue profile and set parameters for the flow queue, including congestion
management, traffic shaping, and flow queue WRED drop profile.
1. Run:
flow-queue-profile flow-queue-profile-name
A flow queue profile is created or the view of an existing flow queue profile is displayed.

By default, the system predefines a flow queue profile default. This flow queue profile
cannot be modified or deleted.
2. Run:
qos queue queue-index { { pq | wfq weight weight-value } | { shaping
{ shaping-value | shaping-percentage shaping-percentage-value } } | { flow-
wred-profile flow-wred-profile-name } } *
The scheduling mode, traffic shaping rate, and flow queue WRED drop profile are
configured.
If no flow queue WRED drop profile is specified, the flow queue WRED drop profile
default is used.
----End
11.6.2 (Optional) Configuring the Mapping Between Flow Queues

and Interface Queues
Context
The mapping between flow queues and port queues allows the device to flexibly send service
traffic in a flow queue to a port queue. Then the device can deliver differentiated services for
the same service traffic from different users.
Procedure
Step 1 Run:
system-view
Step 2 Run:
flow-mapping-profile flow-mapping-profile-name
A flow mapping profile is created or the view of an existing flow mapping profile is
displayed.
By default, the system predefines a flow mapping profile default. This flow mapping profile
cannot be modified or deleted.
Step 3 Run:
map flow-queue flow-queue-index to port-queue port-queue-index
The mapping between flow queues and port queues is configured.
To adjust the mapping between flow queues and port queues, perform the preceding
configurations. If the preceding configurations are not performed, a subscriber queue
references the flow mapping profile default.
----End
11.6.3 Configuring a Subscriber Queue

Background
You can set different traffic shaping rates for different users by configuring subscriber queues
so that the device provides higher bandwidth for high-priority users. Traffic from different
users is differentiated based on ACLs that define items such as the source and destination
MAC addresses, source and destination IP addresses, and VLAN IDs.
Before configuring a subscriber queue, configure an ACL.
Procedure
Step 1 Run:
system-view

Step 2 Run:

l Run:
traffic-user-queue outbound acl { [ ipv6 ] { bas-acl | adv-acl | name acl-
name } } pir pir-value [ flow-queue-profile flow-queue-profile-name | flow-
mapping-profile flow-mapping-profile-name ]*
The device is configured to shape packets in a subscriber queue matching a single ACL
rule and to reference the flow queue and flow mapping profile to implement HQoS.
l Run:
traffic-user-queue outbound acl { l2-acl | name acl-name } acl { bas-acl |
adv-acl | name acl-name } pir pir-value [ flow-queue-profile flow-queue-
profile-name | flow-mapping-profile flow-mapping-profile-name ]*
The device is configured to shape packets in a subscriber queue matching both Layer 2
and Layer 3 ACL rules and to reference the flow queue and flow mapping profile to
implement HQoS.
l Run:
traffic-user-queue outbound acl { bas-acl | adv-acl | name acl-name } acl
{ l2–acl | name acl-name } pir pir-value [ flow-queue-profile flow-queue-
profile-name | flow-mapping-profile flow-mapping-profile-name ]*
The device is configured to shape packets in a subscriber queue matching both Layer 2
and Layer 3 ACL rules and to reference the flow queue and flow mapping profile to
implement HQoS.
----End
Procedure
Step 1 Run the display flow-wred-profile [ name flow-wred-profile-name | all ] command to check
the flow queue WRED drop profile.

Step 2 Run the display flow-queue-profile [ name flow-queue-profile-name | all ] command to

check the flow queue profile.
Step 3 Run the display flow-mapping-profile [ name flow-mapping-profile-name | all ] command to

check the flow mapping profile.
Step 4 Run the display traffic-applied [ interface [ interface-type interface-number ] | vlan [ vlan-
id ] ] { inbound | outbound } [ verbose ] command to check the subscriber queue
configuration.
----End
11.7 Maintaining HQoS
11.7.1 Displaying Traffic Statistics on Subscriber Queues
Context
After subscriber queues are configured to implement HQoS, to learn forwarded and discarded
packets in each flow queue of subscriber queues, run the following commands to view traffic
statistics based on matched ACL rules.
Procedure
l Run the display traffic-user-queue statistics interface interface-type interface-number
outbound acl { bas-acl | adv-acl } [ acl { l2-acl | name acl-name } ] command to check
traffic statistics on subscriber queues.
outbound acl l2-acl [ acl { bas-acl | adv-acl | name acl-name } ] command to check
traffic statistics on subscriber queues.
outbound acl name name-acl [ acl { bas-acl | adv-acl | l2-acl | name acl-name } ]
command to check traffic statistics on subscriber queues.
outbound acl ipv6 { bas-acl | adv-acl | name acl-name } command to check traffic
statistics on subscriber queues.
----End
11.7.2 Clearing Traffic Statistics on Subscriber Queues
Context
Before recollecting traffic statistics on subscriber queues, run the following commands in the
user view to clear existing traffic statistics based on matched ACLs.

NOTICE
The cleared traffic statistics on subscriber queues cannot be restored. Exercise caution when
you run the reset command.
Procedure
Step 1 Run the reset traffic-user-queue statistics interface interface-type interface-number
outbound acl { bas-acl | adv-acl } [ acl { l2-acl | name acl-name } ] command to clear traffic

outbound acl l2-acl [ acl { bas-acl | adv-acl | name acl-name } ] command to clear traffic

outbound acl name acl-name [ acl { bas-acl | adv-acl | l2-acl | name acl-name } ] command
to clear traffic statistics on subscriber queues.

outbound acl ipv6 { bas-acl | adv-acl | name acl-name } command to clear traffic statistics
on subscriber queues.
----End
11.8.1 Example for Configuring HQoS
Voice, video, and data services from multiple users are transmitted on an enterprise campus
network, and 802.1p priorities of voice, video, and data services are 6, 5, and 2 respectively.
Bandwidth needs to be guaranteed for the voice, video, and data services in descending order
of priority. Table 11-6 and Table 11-7 describe the configuration requirements.
Because the bandwidth is limited, the device needs to differentiate service priorities and shape
traffic from different users to provide different bandwidth. Table 11-8 describes the
configuration requirement.
Table 11-6 Congestion avoidance parameters of flow queues

Service Type Font Color Lower Drop Upper Drop Maximum
Threshold (%) Threshold (%) Drop
Probability
Voice Green 80 100 10
Video Yellow 60 80 20

Service Type Font Color Lower Drop Upper Drop Maximum

Threshold (%) Threshold (%) Drop
Probability
Data Red 40 60 40
Table 11-7 Congestion management parameters of flow queues

Service Type CoS Value
Voice EF
Video AF3
Data AF1
Table 11-8 Traffic shaping parameters of subscriber queues

User PIR
Users in VLAN 10 8000kbit/s
Users in VLAN 20 5000kbit/s
Figure 11-4 HQoS networking
Video, data, voice
Traffic direction
GE0/0/1
User 1
GE0/0/2 GE0/0/3
Video, data, voice
SwitchA GE0/0/1
GE0/0/1 GE0/0/2
User 2 VLAN10 Internet
GE0/0/2
Video, data, voice GE0/0/3
Switch SwitchC Router
GE0/0/1
User 3 GE0/0/3
GE0/0/2
Video, data, voice SwitchB
VLAN20
User 4

1. Create VLANs and configure interfaces so that the enterprise can access the Internet
through the Switch.
2. Create a DiffServ domain on the Switch, map the 802.1p priorities of different service
packets to PHBs and color, and bind the DiffServ domain to the inbound interface of the
Switch.
3. Configure a flow queue WRED drop profile, flow queue profile, and profile parameters
on the Switch so that the Switch provides different scheduling priorities, drop profile
parameters, and traffic shaping parameters for different services.
4. Configure ACLs on the Switch to differentiate service traffic of different users based on
VLAN IDs.
5. Configure subscriber queues and traffic shaping parameters on the Switch, and reference
the flow queue WRED drop profile and flow queue profile to implement HQoS.
Procedure
# Create VLAN 10 on SwitchA, configure GE0/0/1 and GE0/0/2 on SwitchA as access

interfaces and add them to VLAN 10, and configure GE0/0/3 as a trunk interface and add it to
VLAN 10.
[SwitchA] vlan batch 10
[SwitchA-GigabitEthernet0/0/1] port link-type access
[SwitchA-GigabitEthernet0/0/1] port default vlan 10
[SwitchA-GigabitEthernet0/0/2] port link-type access
[SwitchA-GigabitEthernet0/0/2] port default vlan 10
# Create VLAN 20 on SwitchB, configure GE0/0/1 and GE0/0/2 on SwitchB as access

interfaces and add them to VLAN 20, and configure GE0/0/3 as a trunk interface and add it to
VLAN 20.
[SwitchB] vlan batch 20
# Create VLAN 10 and VLAN 20 on SwitchC, configure GE0/0/1 on SwitchC as a trunk

interface and add it to VLAN 10 and VLAN 20, and configure GE0/0/2 as a trunk interface
and add it to VLAN 10 and VLAN 20.

[HUAWEI] sysname SwitchC
[SwitchC] vlan batch 10 20
[SwitchC] interface gigabitethernet 0/0/1
[SwitchC-GigabitEthernet0/0/1] port link-type trunk
[SwitchC-GigabitEthernet0/0/1] port trunk allow-pass vlan 10 20
[SwitchC-GigabitEthernet0/0/1] quit
[SwitchC] interface gigabitethernet 0/0/2
[SwitchC-GigabitEthernet0/0/2] port link-type trunk
[SwitchC-GigabitEthernet0/0/2] port trunk allow-pass vlan 10 20
[SwitchC-GigabitEthernet0/0/2] quit
# Create VLAN 10 and VLAN 20 on the Switch, configure GE0/0/1, GE0/0/2, and GE0/0/3
as trunk interfaces, and add GE0/0/1 to VLAN 10, GE0/0/2 to VLAN 20, and GE0/0/3 to
Step 2 Configure priority mapping.
# Create DiffServ domain ds1, map 802.1p priorities 6, 5, 2 to EF, AF3, and AF1, and color
packets green, yellow, and red.
[Switch-dsdomain-ds1] 8021p-inbound 6 phb ef green
[Switch-dsdomain-ds1] 8021p-inbound 5 phb af3 yellow
[Switch-dsdomain-ds1] 8021p-inbound 2 phb af1 red
# Bind the DiffServ domain to GE0/0/1 and GE0/0/2 on the Switch.

Step 3 Configure a flow queue WRED drop profile and define parameters in the profile.
# Create flow queue WRED drop profile wred1 on the Switch and set parameters of green,
yellow, and red packets in the flow queue WRED drop profile.
[Switch] flow-wred-profile wred1
[Switch-flow-wred-wred1] color green low-limit 80 high-limit 100 discard-
percentage 10
[Switch-flow-wred-wred1] color yellow low-limit 60 high-limit 80 discard-
percentage 20
[Switch-flow-wred-wred1] color red low-limit 40 high-limit 60 discard-percentage
40
[Switch-flow-wred-wred1] quit

Step 4 Configure a flow queue profile and define parameters in the profile.
# Configure flow queue profile flow1 on the Switch, bind flow queue profile flow1 to flow
queue WRED drop profile wred1, and configure different scheduling parameters.
[Switch] flow-queue-profile flow1
[Switch-flow-queue-flow1] qos queue 5 pq flow-wred-profile wred1
[Switch-flow-queue-flow1] qos queue 3 wfq weight 20 flow-wred-profile wred1
[Switch-flow-queue-flow1] qos queue 1 wfq weight 10 flow-wred-profile wred1
[Switch-flow-queue-flow1] quit

# Configure ACL 4001 and ACL 4002 on the Switch, and configure ACL rules based on
Step 6 Configure subscriber queues and parameters.

# Configure subscriber queues based on ACL 4001 and ACL 4002 on the Switch and
reference flow queue profile flow1.
[Switch-GigabitEthernet0/0/3] traffic-user-queue outbound acl 4001 pir 8000 flow-
queue-profile flow1
[Switch-GigabitEthernet0/0/3] traffic-user-queue outbound acl 4002 pir 5000 flow-
queue-profile flow1
[Switch] quit

# Check the configuration of the flow queue WRED drop profile, including the profile name,
upper and lower drop thresholds of green, yellow, and red packets, and maximum drop
probability.
<Switch> display flow-wred-profile name wred1
Flow-wred-profile[1]: wred1
Queue depth : 1048576
Color Low-limit High-limit Discard-percentage
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Green 80 100 10
Yellow 60 80 20
Red 40 60 40
-----------------------------------------------------------------
# Check the flow queue profile configuration, including the profile name and WFQ weights.
<Switch> display flow-queue-profile name flow1
Flow-queue-profile[1]: flow1
Queue Schedule(Weight) Shaping flow-wred-profile
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0 PQ None default
1 WFQ(10) None wred1
2 PQ None default
3 WFQ(20) None wred1
4 PQ None default
5 PQ None wred1
6 PQ None default
7 PQ None default
-----------------------------------------------------------------------
# Check traffic statistics on subscriber queues.

<Switch> display traffic-user-queue statistics interface gigabitethernet 0/0/3

outbound acl 4001
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Queue ID | Statistics
information
--------------------------------------------------------------------------------
0 | packets: pass:
4,127
| drop:
2,798,787,076
| bytes: pass:
610,796
| drop:
414,220,487,248
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
1 | packets: pass:
4,127
| drop:
5,597,436,717
| bytes: pass:
610,796
| drop:
828,420,634,116
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
2 | packets: pass:
0
| drop:
0
| bytes: pass:
0
| drop:
0
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
3 | packets: pass:
4,127
| drop:
5,597,436,713
| bytes: pass:
610,796
| drop:
828,420,633,524
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
4 | packets: pass:
4,127
| drop:

2,798,716,293
| bytes: pass:
610,796
| drop:
414,210,011,364
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
5 | packets: pass:
4,127
| drop:
2,798,716,294
| bytes: pass:
610,796
| drop:
414,210,011,512
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
6 | packets: pass:
0
| drop:
0
| bytes: pass:
0
| drop:
0
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
7 | packets: pass:
1,119,509,460
| drop:
1,679,210,961
| bytes: pass:
165,687,400,080
| drop:
248,523,222,228
--------------------------------------------------------------------------------
<Switch> display traffic-user-queue statistics interface gigabitethernet 0/0/3

outbound acl 4002
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
0 | packets: pass:
4,125
| drop:
5,218,026
| bytes: pass:
610,500
| drop:
772,267,848
--------------------------------------------------------------------------------

information
--------------------------------------------------------------------------------
1 | packets: pass:
4,125
| drop:
10,440,178
| bytes: pass:
610,500
| drop:
1,545,146,344
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
2 | packets: pass:
0
| drop:
0
| bytes: pass:
0
| drop:
0
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
3 | packets: pass:
4,125
| drop:
10,440,178
| bytes: pass:
610,500
| drop:
1,545,146,344
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
4 | packets: pass:
4,125
| drop:
5,218,027
| bytes: pass:
610,500
| drop:
772,267,996
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
5 | packets: pass:
4,125
| drop:
5,218,027
| bytes: pass:
610,500
| drop:
772,267,996
--------------------------------------------------------------------------------

information
--------------------------------------------------------------------------------
6 | packets: pass:
0
| drop:
0
| bytes: pass:
0
| drop:
0
--------------------------------------------------------------------------------
information
--------------------------------------------------------------------------------
7 | packets: pass:
2,092,988
| drop:
3,129,165
| bytes: pass:
309,762,224
| drop:
463,116,420
--------------------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
vlan batch
10
#
interface
port link-type
access
port default vlan
10
#
interface
port link-type
access
port default vlan
10
#
interface
port link-type
trunk
10
#
return


#
sysname SwitchB
#
vlan batch
20
#
interface
port link-type
access
port default vlan
20
#
interface
port link-type
access
port default vlan
20
#
interface
port link-type
trunk
20
#
return
l SwitchC configuration file

#
sysname SwitchC
#
vlan batch 10
20
#
interface
port link-type
trunk
20
#
interface
port link-type
trunk
20
#
return

#
sysname Switch
#
vlan batch 10 20
#
diffserv domain ds1


#
acl number 4001
acl number 4002
#
flow-wred-profile wred1
color green low-limit 80 high-limit 100 discard-percentage 10
color yellow low-limit 60 high-limit 80 discard-percentage 20
color red low-limit 40 high-limit 60 discard-percentage 40
#
flow-queue-profile flow1
qos queue 1 wfq weight 10 flow-wred-profile wred1
qos queue 3 wfq weight 20 flow-wred-profile wred1
qos queue 5 flow-wred-profile wred1
#
interface
port link-type
trunk
10
trust upstream
ds1
trust 8021p
inner
#
interface
port link-type
trunk
20
trust upstream
ds1
trust 8021p
inner
#
interface
port link-type
trunk
20
traffic-user-queue outbound acl 4001 pir 8000 flow-queue-profile flow1
traffic-user-queue outbound acl 4002 pir 5000 flow-queue-profile flow1
#
return


Guia de Configuração Huawei-QoS

Uploaded by

Copyright:

Available Formats

You might also like

Guia de Configuração Huawei-QoS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guia de Configuração Huawei-QoS

Uploaded by

Copyright:

Available Formats

S2750&S5700&S6720 Series Ethernet Switches

Configuration Guide - QoS

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 03 (2016-10-30) Huawei Proprietary and Confidential i

About This Document

This document is intended for:

l Data configuration engineers

Indicates an imminently hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Issue 03 (2016-10-30) Huawei Proprietary and Confidential ii

NOTE Calls attention to important information,

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

&<1-n> The parameter before the & sign can be repeated 1 to n

# A line starting with the # sign is comments.

Interface Numbering Conventions

Issue 03 (2016-10-30) Huawei Proprietary and Confidential iii

– When configuring a password, the cipher text is recommended. To ensure device

Mappings between Product Software Versions and NMS

Issue 03 (2016-10-30) Huawei Proprietary and Confidential iv

S2750&S5700&S6720 Product eSight

V200R008C00 eSight V300R003C20

Changes in Issue 03 (2016-10-30) V200R008C00

Changes in Issue 02 (2015-10-23) V200R008C00

Changes in Issue 01 (2015-07-31) V200R008C00

Issue 03 (2016-10-30) Huawei Proprietary and Confidential v

About This Document.....................................................................................................................ii

3 Priority Mapping Configuration on the S6720EI, S5720HI, and S5720EI.........................27

Issue 03 (2016-10-30) Huawei Proprietary and Confidential vi

3.9.1 Packets Enter Incorrect Queues................................................................................................................................. 54

4 Priority Mapping Configuration on the S2750, S5700LI, S5700S-LI, S5710-X-LI,

5 Traffic Policing, Traffic Shaping, and Interface-based Rate Limiting............................. 82

Issue 03 (2016-10-30) Huawei Proprietary and Confidential vii

5.7.2 (Optional) Configuring the Data Buffer.................................................................................................................. 113

6 Congestion Avoidance and Congestion Management Configuration............................ 141

Issue 03 (2016-10-30) Huawei Proprietary and Confidential viii

6.12 Configuration Examples........................................................................................................................................... 170

7 Packet Filtering Configuration............................................................................................... 178

9 Traffic Statistics Configuration.............................................................................................. 208

10 ACL-based Simplified Traffic Policy Configuration....................................................... 222

Issue 03 (2016-10-30) Huawei Proprietary and Confidential ix

Issue 03 (2016-10-30) Huawei Proprietary and Confidential x

QoS Service Models

Issue 03 (2016-10-30) Huawei Proprietary and Confidential 1

Components in the DiffServ Model

l Traffic classification and marking

Issue 03 (2016-10-30) Huawei Proprietary and Confidential 2

Figure 1-1 QoS processing order

Figure 1-2 shows where the QoS mechanisms are implemented.

Figure 1-2 Location of QoS mechanisms