01 QoS Configuration

QoS Configuration QoS Volume
Operation Manual Table of Contents
Table of Contents
1 QoS Overview ............................................................................................................................................1-1

Introduction to QoS .................................................................................................................................1-1
Traditional Packet Forwarding Services .................................................................................................1-1
New Requirements from Emerging Applications ....................................................................................1-1
Congestion: Causes, Impacts, and Countermeasures ...........................................................................1-2
Causes ............................................................................................................................................1-2
Impacts ............................................................................................................................................1-2
Countermeasures ............................................................................................................................1-3
Major Traffic Management Technologies................................................................................................1-3
2 Traffic Classification, Traffic Policing and Traffic Shaping Configuration..........................................2-1

Traffic Classification Overview................................................................................................................2-1
Traffic Classification ........................................................................................................................2-1
IP Precedence .................................................................................................................................2-1
Traffic Policing and Traffic Shaping Overview ........................................................................................2-2
Traffic Evaluation and Token Bucket ......................................................................................................2-2
TP, GTS and Line Rate Configuration ....................................................................................................2-6
Configuring Traffic Policing .............................................................................................................2-6
Configuring GTS..............................................................................................................................2-8
Configuring the Line Rate..............................................................................................................2-10
Displaying and Maintaining TP, GTS and Line Rate ............................................................................2-10
TP and GTS Configuration Example.....................................................................................................2-11
3 QoS Policy Configuration .........................................................................................................................3-1

QoS Policy Overview ..............................................................................................................................3-1
Configuring a QoS Policy........................................................................................................................3-1
Configuration Prerequisites .............................................................................................................3-2
Defining a Class ..............................................................................................................................3-2
Defining a Traffic Behavior ..............................................................................................................3-2
Defining a Policy..............................................................................................................................3-3
QoS Policy Configuration Example .................................................................................................3-4
Applying the QoS Policy..........................................................................................................................3-4
Applying the QoS Policy to an Interface or PVC .............................................................................3-5
Configuring QoS Policy-Based Traffic Rate Measuring Interval .............................................................3-6
Displaying and Maintaining QoS Policies ...............................................................................................3-6
4 Congestion Management Configuration .................................................................................................4-1

Congestion Management Overview........................................................................................................4-1
Congestion Management Policies...................................................................................................4-1
Congestion Management Technology Comparison ........................................................................4-6
Configuring FIFO.....................................................................................................................................4-7
FIFO Configuration Procedure ........................................................................................................4-8
FIFO Configuration Example...........................................................................................................4-8
Huawei Proprietary and Confidential i
Copyright © Huawei Technologies Co., Ltd
Table of Contents Operation Manual
Configuring PQ........................................................................................................................................4-8
PQ Configuration Procedure ...........................................................................................................4-8
PQ Configuration Example..............................................................................................................4-9
Configuring CQ .....................................................................................................................................4-10
Configuration Procedure................................................................................................................4-11
CQ Configuration Example............................................................................................................4-12
Configuring WFQ ..................................................................................................................................4-12
WFQ Configuration Example.........................................................................................................4-13
Configuring CBQ ...................................................................................................................................4-13
Configuring the Maximum Available Interface Bandwidth.............................................................4-14
Defining a Class ............................................................................................................................4-16
Defining a Traffic Behavior ............................................................................................................4-16
Defining a QoS Policy....................................................................................................................4-22
Applying the QoS Policy ................................................................................................................4-22
CBQ Configuration Example .........................................................................................................4-24
Displaying and Maintaining CBQ...................................................................................................4-25
Configuring RTP Priority Queuing.........................................................................................................4-25
RTP Priority Queuing Configuration Example ...............................................................................4-26
Configuring QoS Tokens.......................................................................................................................4-27
QoS Token Configuration Procedure ............................................................................................4-27
QoS Token Configuration Example...............................................................................................4-27
Configuring Packet Information Pre-Extraction.....................................................................................4-28
Configuration Example ..................................................................................................................4-28
Configuring Local Fragment Pre-drop...................................................................................................4-28
Configuration Example ..................................................................................................................4-29
5 Priority Mapping Configuration................................................................................................................5-1

Priority Mapping Overview ......................................................................................................................5-1
Configuring a Priority Mapping Table......................................................................................................5-3
Configuration Procedure..................................................................................................................5-3
Configuration Example ....................................................................................................................5-3
Configuring the Priority for a Port............................................................................................................5-4
Configuring the Trusted Precedence Type for a Port .............................................................................5-5
Displaying and Maintaining Priority Mapping ..........................................................................................5-6
Priority Mapping Configuration Examples...............................................................................................5-7
ii Huawei Proprietary and Confidential

Operation Manual Table of Contents
Example 1........................................................................................................................................5-7
Example 2........................................................................................................................................5-8
6 Congestion Avoidance..............................................................................................................................6-1
Congestion Avoidance Overview ............................................................................................................6-1
Introduction to WRED Configuration.......................................................................................................6-3
Configuration Methods ....................................................................................................................6-3
Introduction to WRED Parameters ..................................................................................................6-3
Configuring WRED on an Interface.........................................................................................................6-3
Applying a WRED Table on an Interface ................................................................................................6-5
Displaying and Maintaining WRED .........................................................................................................6-6
WRED Configuration Example................................................................................................................6-6
7 MPLS QoS Configuration..........................................................................................................................7-1

MPLS QoS Overview ..............................................................................................................................7-1
Configuring MPLS QoS...........................................................................................................................7-2
Configuring MPLS PQ .....................................................................................................................7-2
Configuring MPLS CQ .....................................................................................................................7-3
Configuring a MPLS QoS Policy .....................................................................................................7-3
Configuring MPLS CAR...................................................................................................................7-4
MPLS QoS Configuration Examples.......................................................................................................7-5
Configuring QoS for Traffic Within a VPN .......................................................................................7-5
8 DAR Configuration ....................................................................................................................................8-1

DAR Overview.........................................................................................................................................8-1
IP Packet .........................................................................................................................................8-1
TCP Packet .....................................................................................................................................8-3
UDP Packet .....................................................................................................................................8-4
HTTP Packet ...................................................................................................................................8-4
RTP Packet .....................................................................................................................................8-5
RTCP Packet Overview...................................................................................................................8-5
Static Protocol Overview .................................................................................................................8-6
Configuring DAR .....................................................................................................................................8-8
Configuring Protocol Match Criteria ................................................................................................8-8
Configuring Port Numbers for DAR Application Protocols ..............................................................8-9
Renaming User-defined Protocols ..................................................................................................8-9
Configuring DAR Packet Accounting.............................................................................................8-10
Configuring the Maximum Number of Recognizable Connections ...............................................8-10
Displaying and Maintaining DAR ..........................................................................................................8-10
DAR Configuration Examples ...............................................................................................................8-11
BT Downloading Prohibition Configuration Example ....................................................................8-11
Huawei Proprietary and Confidential iii

Table of Contents Operation Manual
HTTP URL-Based DAR Configuration Example ...........................................................................8-12

HTTP Host-Based DAR Configuration Example ...........................................................................8-13
iv Huawei Proprietary and Confidential

Operation Manual 1 QoS Overview
1 QoS Overview
This chapter covers the following topics:

z Introduction to QoS
z Traditional Packet Forwarding Services
z New Requirements from Emerging Applications
z Congestion: Causes, Impacts, and Countermeasures
z Major Traffic Management Technologies
Introduction to QoS
Quality of Service (QoS) is a concept concerning service demand and supply. It reflects the ability to
meet customer needs. Generally, QoS focuses on improving services under certain conditions rather
than grading services precisely.
In an internet, QoS evaluates the ability of the network to forward packets of different services. The
evaluation can be based on different criteria because the network may provide various services.
Generally, QoS refers to the ability to provide improved service by solving the core issues such as delay,
jitter, and packet loss ratio in the packet forwarding process.
Traditional Packet Forwarding Services

On traditional IP networks, devices treat all packets equally and handle them using the first in first out
(FIFO) policy. All packets share the resources of the network and devices. How many resources the
packets can obtain completely depends on the time they arrive. This service is called best-effort. It
delivers packets to their destinations as possibly as it can, without any guarantee for delay, jitter, packet
loss ratio, reliability and so on.
This service policy is only suitable for applications insensitive to bandwidth and delay, such as WWW,
file transfer and e-mail.
New Requirements from Emerging Applications

The Internet has been growing along with the fast development of networking technologies. More and
more people use the Internet to transmit data, share video and do a lot of other things.
Besides traditional applications such as WWW, e-mail and FTP, network users are experiencing new
services, such as tele-education, telemedicine, video telephone, videoconference and
Video-on-Demand (VoD). Enterprise users expect to connect their regional branches together with VPN
technologies to carry out operational applications, for instance, to access the database of the company
or to monitor remote devices through Telnet.
These new applications have one thing in common, that is, they all have special requirements for
bandwidth, delay, and jitter. For example, videoconference and VoD require high bandwidth, low delay
Huawei Proprietary and Confidential 1-1

1 QoS Overview Operation Manual
and jitter. As for mission-critical applications, such as transactions and Telnet, they may not require high
bandwidth but do require low delay and preferential service during congestion.
The emerging applications demand higher service performance of IP networks. Better network services
during packets forwarding are required, such as providing dedicated bandwidth, reducing packet loss
ratio, managing and avoiding congestion, regulating network traffic, and setting the precedence of
packets. To meet these requirements, networks must provide more improved services.
Congestion: Causes, Impacts, and Countermeasures

Network congestion is a major factor contributed to service quality degrading on a traditional network.
Congestion is a situation where the forwarding rate decreases due to insufficient resources, resulting in
extra delay.
Causes
Congestion easily occurs in complex packet switching circumstances in the Internet. The following
figure shows two common cases:
Figure 1-1 Traffic congestion causes
100M
100M 10M 100M 100M
Congestion on interfaces
with different speeds 100M
Congestion on interfaces
with the same speed
z The traffic enters a device from a high speed link and is forwarded over a low speed link.
z The packet flows enter a device from several interfaces at the same rate and are forwarded out an
interface at the same rate as well.
When traffic arrives at the line speed, a bottleneck is created at the outgoing interface causing
congestion.
Besides bandwidth bottlenecks, congestion can be caused by resource shortage in various forms such
as insufficient processor time, buffer, and memory, and by network resource exhaustion resulting from
excessive arriving traffic in certain periods.
Impacts
Congestion may bring these negative results:

z Increased delay and jitter during packet transmission
z Decreased network throughput and resource use efficiency
z Network resource (memory in particular) exhaustion and even system breakdown
It is obvious that congestion hinders resource assignment for traffic and thus degrades service
performance. The chance of congestion is high in switched networks and multi-user application
1-2 Huawei Proprietary and Confidential

Operation Manual 1 QoS Overview
environments. To improve the service performance of your network, you must address the congestion
issues.
Countermeasures
A simple solution for congestion is to increase network bandwidth. However, it cannot solve all the
problems that cause congestion.
A more effective solution is to provide differentiated services for different applications through traffic
control and resource allocation. In this way, resources can be used more properly. During resources
allocation and traffic control, the direct or indirect factors that might cause network congestion should be
controlled to reduce the probability of congestion. Once congestion occurs, resource allocation should
be performed according to the characteristics and demands of applications to minimize the effects of
congestion on QoS.
Major Traffic Management Technologies

Figure 1-2 End-to-end QoS model
As shown in Figure 1-2, traffic classification, traffic policing (TP), traffic shaping (TS), congestion
management, and congestion avoidance are the foundations for a network to provide differentiated
services. Mainly they implement the following functions:
z Traffic classification uses certain match criteria to organize packets with different characteristics
into different classes, and is the prerequisite for providing differentiated services. Traffic
classification is usually applied in the inbound direction of a port.
z Traffic policing polices particular flows entering a device according to configured specifications and
is usually applied in the inbound direction of a port. When a flow exceeds the specification, some
restriction or punishment measures can be taken to prevent overconsumption of network
resources and protect the commercial benefits of the carrier.
z Traffic shaping proactively adjusts the output rate of traffic to adapt traffic to the network resources
of the downstream device and avoid unnecessary packet drop and congestion. Traffic shaping is
usually applied in the outbound direction of a port.
z Congestion management provides measures for handling resource competition during network
congestion and is usually applied in the outbound direction of a port. Generally, it stores packets in
queues, and then uses a scheduling algorithm to arrange the forwarding sequence of the packets.

1 QoS Overview Operation Manual
z Congestion avoidance monitors the usage status of network resources and is usually applied in the
outbound direction of a port. As congestion becomes worse, it actively reduces the amount of traffic
by dropping packets.
Among these traffic management technologies, traffic classification is the basis for providing
differentiated services by classifying packets with certain match criteria. Traffic policing, traffic shaping,
congestion management, and congestion avoidance manage network traffic and resources in different
ways to realize differentiated services.
Normally, QoS provides the following functions:
z Traffic classification
z Access control
z Traffic policing and traffic shaping
z Congestion management
z Congestion avoidance

QoS Configuration QoS Volume 2 Traffic Classification, Traffic Policing and Traffic
Operation Manual Shaping Configuration
2 Traffic Classification, Traffic Policing and Traffic

Shaping Configuration
When configuring traffic classification, traffic policing, and traffic shaping, go to these sections for
information you are interested in:
z Traffic Classification Overview
z Traffic Policing and Traffic Shaping Overview
z Traffic Evaluation and Token Bucket
z TP, GTS and Line Rate Configuration
z Displaying and Maintaining TP, GTS and Line Rate
z TP and GTS Configuration Example
Traffic Classification Overview

Traffic Classification
Traffic classification organizes packets with different characteristics into different classes using match
criteria. It is the basis for providing differentiated services.
You can define match criteria based on the IP precedence bits in the type of service (ToS) field of the IP
packet header, or based on other header information such as IP addresses, MAC addresses, IP
protocol field and port numbers. Contents other than the header information in packets are rarely used
for traffic classification. You can define a class for packets with a common quintuple (source address,
source port number, protocol number, destination address and destination port number), or for all
packets to a certain network segment.
When packets are classified on the network boundary, the precedence bits in the ToS field of the IP
packet header are generally re-set. In this way, IP precedence can be adopted as a classification
criterion for the packets in the network. On the other hand, IP precedence can also be used in queuing
to prioritize traffic. The downstream network can either adopt the classification results from its upstream
network or classify the packets again according to its own criteria.
To provide differentiated services, traffic classes must be associated with certain traffic control actions
or resource allocation actions. What traffic control actions to adopt depends on the current phase and
the resources of the network. For example, CIR is adopted to police packets when they enter the
network; GTS is performed on packets when they flow out of the node; queue scheduling is performed
when congestion happens; congestion avoidance measures are taken when the congestion
deteriorates.
IP Precedence
The following part introduces some precedence types.

2 Traffic Classification, Traffic Policing and Traffic QoS Configuration QoS Volume
Shaping Configuration Operation Manual
Figure 2-1 DS field and ToS bytes
As shown in Figure 2-1, the ToS field of the IP header contains 8 bits: the first three bits (0 to 2)
represent IP precedence from 0 to 7; the following 4 bits (3 to 6) represent a ToS value from 0 to 15. In
RFC 2474, the ToS field of the IP header is redefined as the DS field, where a DiffServ code point
(DSCP) precedence is represented by the first 6 bits (0 to 5) and is in the range 0 to 63. The remaining
2 bits (6 and 7) are reserved.
Traffic Policing and Traffic Shaping Overview

If user traffic is not limited, burst traffic will make the network more congested. Therefore it is necessary
to limit user traffic in order to better utilize the network resources and provide better services for more
users. For example, you can configure a flow to use only the resources committed to it in a time range,
thus avoiding network congestion caused by burst traffic.
Traffic policing (TP) and generic traffic shaping (GTS) limit traffic rate and resource usage according to
traffic specifications. The prerequisite for TP or GTS is to know whether a traffic flow has exceeded the
specification. If yes, proper traffic control policies are applied. Generally, token buckets are used to
evaluate traffic specifications.
Traffic Evaluation and Token Bucket

Token bucket features
A token bucket can be considered as a container holding a certain number of tokens. The system puts
tokens into the bucket at a set rate. When the token bucket is full, the extra tokens will overflow.

Figure 2-2 Evaluate traffic with the token bucket
Evaluating traffic with the token bucket
The evaluation for the traffic specification is based on whether the number of tokens in the bucket can
meet the need of packet forwarding. If the number of tokens in the bucket is enough to forward the
packets (generally, one token is associated with a 1-bit forwarding authority), the traffic conforms to the
specification, and the traffic is called conforming traffic; otherwise, the traffic does not conform to the
specification, and the traffic is called excess traffic.
A token bucket has the following configurable parameters:
z Mean rate: At which tokens are put into the bucket, namely, the permitted average rate of traffic. It
is usually set to the committed information rate (CIR).
z Burst size: the capacity of the token bucket, namely, the maximum traffic size that is permitted in
each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater
than the maximum packet size.
One evaluation is performed on each arriving packet. In each evaluation, if the number of tokens in the
bucket is enough, the traffic conforms to the specification and the corresponding tokens for forwarding
the packet are taken away; if the number of tokens in the bucket is not enough, it means that too many
tokens have been used and the traffic is excessive.
Complicated evaluation
You can set two token buckets in order to evaluate more complicated conditions and implement more
flexible regulation policies. For example, traffic policing uses four parameters:
z CIR
z CBS
z Excess burst size (EBS)
The rate of putting tokens into the two buckets is CIR, and their sizes are CBS and EBS respectively
(the two buckets are called C bucket and E bucket respectively for short), representing different
permitted burst levels. In each evaluation, different regulation policies can be implemented in different
conditions, including “enough tokens in C bucket”, “insufficient tokens in C bucket but enough tokens in
E bucket” and “insufficient tokens in both C bucket and E bucket”.
Traffic policing
The typical application of traffic policing is to supervise the specification of certain traffic entering a
network and limit it within a reasonable range, or to "discipline" the extra traffic. In this way, the network
resources and the interests of the carrier are protected. For example, you can limit bandwidth
consumption of HTTP packets to less than 50% of the total. If the traffic of a certain session exceeds the
limit, traffic policing can drop the packets or reset the IP precedence of the packets.
Traffic policing is widely used in policing traffic entering the networks of internet service providers (ISPs).
It can classify the policed traffic and perform pre-defined policing actions based on different evaluation
results. These actions include:
z Forwarding the packets whose evaluation result is “conforming”.
z Dropping the packets whose evaluation result is “excess”.
z Modifying the IP precedence of the packets whose evaluation result is “conforming” and forwarding
them.
z Modifying the IP precedence of the packets whose evaluation result is “conforming” and delivering
them into the next-level traffic policing.
z Entering the next-level policing (you can set multiple traffic policing levels with each level focusing
on specific objects).
Traffic shaping
Traffic shaping provides measures to adjust the rate of outbound traffic actively. A typical traffic shaping
application is to limit the local traffic output rate according to the downstream traffic policing parameters.
The difference between TP and GTS is that packets to be dropped in TP are cached in a buffer or queue
in GTS, as shown in Figure 2-3. When there are enough tokens in the token bucket, these cached
packets are sent at an even rate. Traffic shaping may result in an additional delay while traffic policing
does not.
Figure 2-3 Diagram for GTS
Tokens are put into the

bucket at the set rate
Packets to be sent
through this interface
Packets sent
Packet
classification
Token
bucket
Queue
Packets dropped
For example, in Figure 2-4, Router A sends packets to Router B. Router B performs TP on packets from
Router A and drops packets exceeding the limit.

Figure 2-4 GTS application
You can perform traffic shaping for the packets on the outgoing interface of Router A to avoid
unnecessary packet loss. Packets exceeding the limit are cached in Router A. Once resources are
released, traffic shaping takes out the cached packets and sends them out. In this way, all the traffic
sent to Router B conforms to the traffic specification defined in Router B.
Line rate
The line rate of a physical interface specifies the maximum rate for forwarding packets (including critical
packets).
Line rate also uses token buckets for traffic control. With line rate configured on an interface, all packets
to be sent through the interface are firstly handled by the token bucket at line rate. If there are enough
tokens in the token bucket, packets can be forwarded; otherwise, packets are put into QoS queues for
congestion management. In this way, the traffic passing the physical interface is controlled.
Figure 2-5 Line rate implementation
In the token bucket approach to traffic control, bursty traffic can be transmitted so long as enough
tokens are available in the token bucket; if tokens are inadequate, packets cannot be transmitted until
the required number of tokens are generated in the token bucket. Thus, traffic rate is restricted to the
rate for generating tokens, thus limiting traffic rate and allowing bursty traffic.
Compared with traffic policing, line rate can only limit traffic rate on a physical interface. Since traffic
policing operates at the IP layer, it can limit the rate of different flows on a port. However, traffic policing
ignores packets not processed by the IP layer. To limit the rate of all the packets on interfaces, using line
rate is easier.
TP, GTS and Line Rate Configuration

Complete the following tasks to configure TP, GTS, and line rate:
Task Remarks
Configure a CAR list
Configuring CAR-list-based traffic policing
Apply CAR policies to the specified interface
Configure an ACL
Configuring ACL-based traffic policing
Apply CAR policies to the specified interface
Configuring traffic policing for all traffic Apply CAR policies to the specified interface
Configure ACL
Configuring ACL-based GTS
Configure GTS on interfaces
Configuring GTS for all traffic Configure GTS on interfaces
Configuring the Line Rate Configure line rate
Configuring Traffic Policing
Traffic policing configuration involves the following two tasks: the first task is to define the
characteristics of packets to be policed; the second task is to define policing policies for the matched
packets.
Configuring CAR-list-based traffic policing
Follow these steps to configure CAR-list-based traffic policing:
To do… Use the command… Remarks
Enter system view system-view —

qos carl carl-index { precedence
precedence-value | mac mac-address |
dscp dscp-list |
Configure a committed { destination-ip-address |
Required
access rate (CAR) list source-ip-address } { subnet
ip-address mask-length | range
start-ip-address to end-ip-address }
[ per-address [ shared-bandwidth ] ] }
Optional
Display the CAR list display qos carl [ carl-index ]
Available in any view
Enter Enter Use either command

interface interface-type
interface interface
interface-number Settings in interface view take
view or view
effect on the current interface;
port Enter port settings in port group view take
group group port-group manual port-group-name effect on all ports in the port
view view group.

qos car { inbound | outbound } carl

Configure a CAR list carl-index cir
based CAR policy on committed-information-rate [ cbs
Required
the interface/port committed-burst-size [ ebs
group excess-burst-size ] ] [ green action ]
[ red action ]
Display CAR
configuration display qos car interface Optional
information on the [ interface-type interface-number ] Available in any view
interface/all interfaces
Configuring ACL-based traffic policing
Follow these steps to configure ACL-based TP:

Configure an ACL Refer to the ACL module Required

Enter Use either command
Enter interface interface-type
interface
interface interface-number Settings in interface view take
view
view or effect on the current interface;
port group Enter port settings in port group view take
view group port-group manual port-group-name effect on all ports in the port
view group.
qos car { inbound | outbound } acl

[ ipv6 ] acl-number cir
Configure an ACL
committed-information-rate [ cbs
based CAR policy on Required
committed-burst-size [ ebs
the interface/port group
excess-burst-size ] ] [ green action ]
[ red action ]
Display CAR policy Optional

display qos car interface
information on the
[ interface-type interface-number ] Available in any view
interface/all interfaces
Configuring traffic policing for all traffic
Follow these steps to configure traffic policing for all traffic:

interface
view
view or effect on the current interface;
port group Enter port settings in port group view take
view group port-group manual port-group-name effect on all ports in the port
view group.


qos car { inbound | outbound } any
Configure a CAR policy cir committed-information-rate [ cbs
for all traffic on the committed-burst-size [ ebs Required
interface/port group excess-burst-size ] ] [ green action ]
[ red action ]
Display the CAR policy Optional

display qos car interface
information on the
specified interface
Traffic policing configuration example
Configure traffic policing on Ethernet 1/1: rate of packets sent on Ethernet 1/1 cannot exceed 1 Mbps,
and excess packets are dropped.
# Enter system view.
<Sysname> system-view
# Enter interface view.

[Sysname] interface ethernet1/1
# Configure a CAR policy for the interface.

[Sysname-Ethernet1/1] qos car outbound any cir 1000 cbs 1000000 ebs 0 green pass red discard
Configuring GTS
Traffic shaping configuration involves:

z ACL-based generic traffic shaping (GTS): setting GTS parameters for the traffic matching the
specific ACL. By specifying multiple ACLs, you can set GTS parameters for different classes of
traffic.
z GTS for all traffic: configuring GTS parameters for all traffic.
GTS for software forwarding does not support IPv6.
Configuring ACL-based GTS
Follow these steps to configure ACL-based GTS:

Defining an ACL Refer to the ACL module Required


interface interface
view or view
effect on the current interface;
port Enter port settings in port group view take
group group port-group manual port-group-name effect on all ports in the port
view view group.
qos gts acl acl-number cir

Configure ACL-based committed-information-rate [ cbs
(GTS) on the committed-burst-size [ ebs Required
interface/port group excess-burst-size [ queue-length
queue-length ] ] ]
Display GTS
configuration display qos gts interface Optional
information on the [ interface-type interface-number ] Available in any view
interface
Configuring GTS for all traffic
Follow these steps to configure GTS for all traffic:

interface interface
view or view
port effect on the current interface;
group Enter port port-group manual settings in port group view take
view group view port-group-name effect on all ports in the port group.
qos gts any cir

Configure GTS on the
committed-burst-size [ ebs Required
interface/port group
excess-burst-size [ queue-length
queue-length ] ] ]
Display GTS Optional

display qos gts interface
configuration on the
interface
GTS configuration example
Configure GTS on Ethernet 1/1, shaping the packets when the sending rate exceeds 500 kbps.

[Sysname] interface ethernet 1/1
# Configure GTS parameters.

[Sysname-Ethernet1/1] qos gts any cir 500

Configuring the Line Rate
Configuration procedure
The line rate of a physical interface specifies the maximum rate of incoming packets or outgoing
packets.
Follow these steps to configure the line rate:

Enter interface interface interface-type Use either command

Enter view interface-number
interface Settings in interface view
view or take effect on the current
port group Enter port interface; settings in port
port-group manual port-group-name group view take effect on
view group view
all ports in the port group.
qos lr { inbound | outbound } cir

Configure the line rate for the committed-information-rate [ cbs
Required
interface/port group committed-burst-size [ ebs
excess-burst-size ] ]
Display line rate information display qos lr interface
on the interface [ interface-type interface-number ]
Line rate configuration example
Limit the outbound line rate of Ethernet 1/1 to 500 kbps.


# Limit the outbound line rate of Ethernet 1/1 to 500 kbps.

[Sysname-Ethernet1/1] qos lr outbound cir 500
Displaying and Maintaining TP, GTS and Line Rate

Display CAR list information display qos carl [ carl-index ] Available in any view
Display the CAR information on display qos car interface

the specified interface [ interface-type interface-number ]
Display interface GTS display qos gts interface

configuration information [ interface-type interface-number ]
Display interface line rate display qos lr interface [ interface-type

configuration information interface-number ]

TP and GTS Configuration Example

Network requirements
z Ethernet 1/3 of Router A is connected to Ethernet 1/1 of Router B.

z Server, Host A, and Host B can access the Internet through Router A and Router B.
z Server, Host A, and Ethernet 1/1 of Router A are in the same network segment.
z Host B, and Ethernet 1/2 of Router A are in the same network segment.
Perform traffic control for packets received on Ethernet 1/1 of Router A from Server and Host A
respectively as follows:
z Limit the rate of packets from Server to 54 kbps. When the traffic rate is below 54 kbps, the traffic is
forwarded normally. When the traffic rate exceeds 54 kbps, violating packets are marked with IP
precedence 0 and then forwarded.
z Limit the rate of packets from Host A to 8 kbps. When the traffic rate is below 8 kbps, the traffic is
forwarded normally. When the traffic rate exceeds 8 kbps, the violating packets are dropped.
Traffic control for packets forwarded by Ethernet 1/1 and Ethernet 1/2 of Router B is as follows:
z Limit the receiving rate on Ethernet 1/1 of Router B to 500 kbps, and violating packets are dropped.
z Limit the sending rate on Ethernet 1/2 of Router B to 1000 kbps, and violating packets are dropped.
Figure 2-6 Network diagram for TP and GTS
1) Configure Router A
# Configure GTS on Ethernet 1/3 of Router A, shaping the packets when the sending rate exceeds 500
kbps to decrease the packet loss ratio of Ethernet 1/1 of Router B.
<RouterA> system-view
[RouterA] interface ethernet 1/3
[RouterA-Ethernet1/3] qos gts any cir 500
[RouterA-Ethernet1/3] quit
# Configure ACLs to permit the packets from Server and Host A.

[RouterA] acl number 2001
[RouterA-acl-basic-2001] rule permit source 1.1.1.1 0
[RouterA-acl-basic-2001] quit

[RouterA-acl-basic-2002] rule permit source 1.1.1.2 0

[RouterA-acl-basic-2002] quit
# Configure CAR policies for different flows received on Ethernet 1/1.

[RouterA] interface ethernet 1/1
[RouterA-Ethernet1/1] qos car inbound acl 2001 cir 54 cbs 4000 ebs 0 green pass red
remark-prec-pass 0
[RouterA-Ethernet1/1] qos car inbound acl 2002 cir 8 cbs 1875 ebs 0 green pass red discard
[RouterA-Ethernet1/1] qos car inbound any cir 500 cbs 32000 ebs 0 green pass red discard
[RouterA-Ethernet1/1] quit
2) Configure Router B
# Configure a CAR policy on Ethernet 1/2 to limit the sending rate to 1 Mbps. Violating packets are
dropped.
<RouterB> system-view
[RouterB] interface ethernet 1/2
[RouterB-Ethernet1/2] qos car outbound any cir 1000 cbs 65000 ebs 0 green pass red discard

Operation Manual 3 QoS Policy Configuration
3 QoS Policy Configuration
When configuring a QoS policy, go to these sections for information you are interested in:
z QoS Policy Overview
z Configuring a QoS Policy
z Applying the QoS Policy
z Configuring QoS Policy-Based Traffic Rate Measuring Interval
z Displaying and Maintaining QoS Policies
QoS Policy Overview

A QoS policy involves three components: class, traffic behavior, and policy. You can associate a class
with a traffic behavior using a QoS policy.
Class
Classes are used to identify traffic.

A class is identified by a class name and contains some match criteria.
You can define a set of match criteria to classify packets, and the relationship between criteria can be
and or or.
z and: The device considers a packet belongs to a class only when the packet matches all the criteria
in the class.
z or: The device considers a packet belongs to a class as long as the packet matches one of the
criteria in the class.
Traffic behavior
A traffic behavior defines a set of QoS actions for packets.
Policy
A policy associates a class with a traffic behavior.

You can configure multiple class-to-traffic behavior associations in a policy.
Configuring a QoS Policy

Follow these steps to configure a QoS policy:
1) Create a class and define a set of match criteria in class view.
2) Create a traffic behavior and define a set of QoS actions in traffic behavior view.
3) Create a policy and associate the traffic behavior with the class in policy view.

3 QoS Policy Configuration Operation Manual
Configuration Prerequisites
You need to decide on:

z The class name and match criteria.
z The traffic behavior name and actions in the traffic behavior.
z The policy name.
Defining a Class
To define a class, you need to specify a name for it and then configure match criteria in class view.
Follow these steps to define a class:

Required
Create a class and enter class traffic classifier tcl-name
view [ operator { and | or } ] By default, the relation between
match criteria is logic and.
Define a match criterion if-match [ not ] match-criteria Required
display traffic classifier Optional

Display class information { system-defined |
user-defined } [ tcl-name ] Available in any view
Defining a Traffic Behavior
To define a traffic behavior, you should first create a traffic behavior name and then configure attributes
in traffic behavior view.
Follow these steps to define a traffic behavior:

Create a traffic behavior and
traffic behavior behavior-name Required
enter traffic behavior view
car cir committed-information-rate [ cbs Required
Configure a CAR policy committed-burst-size [ ebs excess-burst-size ] ] You can
[ green action ] [ red action ] configure the
Drop or send packets filter { deny | permit } corresponding
traffic behavior
as required.
gts cir committed-information-rate [ cbs
In absolute
committed-burst-size [ ebs excess-burst-size
value
[ queue-length queue-length ] ] ]
Configure a
GTS policy
In gts percent cir cir-percent [ cbs cbs-time [ ebs
percentage ebs-time ] ]
Set the cell loss priority

remark atm-clp atm-clp-value
(CLP) bit for ATM cells


Set the DSCP value for
remark dscp dscp-value
packets
Set the 802.1p precedence

remark dot1p 8021p
for packets
Set the drop precedence for remark drop-precedence

packets drop-precedence-value
Set the DE bit for FR packets remark fr-de fr-de-value
Set the IP precedence for
remark ip-precedence ip-precedence-value
packets
Set the EXP value for MPLS

remark mpls-exp exp-value
packets
Set the QoS local ID for

remark qos-local-id local-id-value
packets
Optional
Display traffic behavior display traffic behavior { system-defined |
configuration information user-defined } [ behavior-name ] Available in any
view
Defining a Policy
A policy defines the mapping between a class and a traffic behavior (a set of QoS actions).
In a policy, multiple class-to-traffic-behavior mappings can be configured, and these mappings are
executed according to the order configured.
Follow these steps to define a policy:

Create a policy and enter policy
qos policy policy-name Required
view
Specify the traffic behavior for a classifier tcl-name behavior

Required
class in the policy behavior-name
Display the specified class and Optional
display qos policy user-defined
its associated traffic behavior in
[ policy-name [ classifier tcl-name ] ] Available in any view
the QoS policy

If an ACL is referenced by a QoS policy for defining traffic match criteria, the operation of the QoS policy
varies by interface or PVC:
z If the QoS policy is applied to a software interface or PVC and the match mode of the if-match
clause is deny, the if-match clause for matching the ACL does not take effect and packets go to
the next match criterion.
z With the QoS policy applied to a hardware interface, packets matching the ACL are organized as a
class and the behavior defined in the QoS policy applies to the class regardless of whether the
match mode of the if-match clause is deny or permit.
QoS Policy Configuration Example
Configure a QoS policy test_policy to limit the rate of packets with IP precedence 6 to 100 kbps.
# Create a class test_class to match the packets with IP precedence 6.

[Sysname] traffic classifier test_class
[Sysname-classifier-test_class] if-match ip-precedence 6
[Sysname-classifier-test_class] quit
# Create a traffic behavior test_behavior and configure the action of limiting the traffic rate to 100 kbps
for it.
[Sysname] traffic behavior test_behavior
[Sysname-behavior-test_behavior] car cir 100
[Sysname-behavior-test_behavior] quit
# Create a QoS policy test_policy and associate the traffic behavior with the class.
[Sysname] qos policy test_policy
[Sysname-qospolicy-test_policy] classifier test_class behavior test_behavior
Applying the QoS Policy

You can apply the QoS policy in different views as follows:
z In interface or PVC view, the policy applies to the inbound or outbound direction of an interface or
PVC.

You can modify the classification rules, traffic behaviors, and classifier-behavior associations of a QoS
policy already applied.
Applying the QoS Policy to an Interface or PVC
A policy can be applied to multiple interfaces or PVCs. Only one policy can be applied in one direction
(inbound or outbound) of an interface or PVC.
Follow these steps to apply the QoS policy to an interface or PVC:

Enter
interface Use either command
Enter interface-number
view Settings in interface view take
interface
view, port Enter port port-group manual effect on the current interface;
group view, group view port-group-name settings in port group view take
or PVC effect on all ports in the port
view interface atm interface-number group; settings in PVC view
Enter PVC take effect on the current PVC.
view
pvc vpi/vci
Apply the policy to the qos apply policy policy-name

Required
interface/port group/PVC { inbound | outbound }
z QoS policies can be applied to all physical interfaces except interfaces encapsulated with X.25 or
LAPB.
z If a QoS policy is applied in the outbound direction of an interface or PVC, the QoS policy cannot
influence local packets (local packets refer to the important protocol packets that maintain the
normal operation of the device. QoS must not process such packets to avoid packet drop.
Commonly used local packets are: link maintenance packets, ISIS packets, OSPF packets, RIP
packets, BGP packets, LDP packets, RSVP packets, and SSH packets and so on.)
Configuration example
# Apply QoS policy test_policy to the inbound direction of Ethernet 1/1.


[Sysname-Ethernet1/1] qos apply policy test_policy inbound
Configuring QoS Policy-Based Traffic Rate Measuring Interval

The QoS policy-based traffic rate measuring function can collect statistics about the average forwarding
and drop rates of traffic over an interval on a per-class basis. The measuring interval is user
configurable and the statistics are refreshed every 15 seconds. You can use the display qos policy
interface command to view the collected traffic rate statistics.
Follow these steps to configure the QoS policy-based traffic rate measuring interval:

Enter interface view —
interface-number
Configure the QoS policy-based traffic Optional

qos flow-interval interval
rate measuring interval 5 minutes by default.
z The QoS policy-based traffic rate measuring interval of an ATM PVC is the same as that of the
ATM interface.
z The QoS policy-based traffic rate measuring interval of an FR DLCI is the same as that of the FR
interface.
z The QoS policy-based traffic rate measuring interval of a subinterface is the same as that of the
main interface.
Displaying and Maintaining QoS Policies

display traffic classifier

Display traffic class information { system-defined | user-defined } Available in any view
[ tcl-name ]
display traffic behavior
Display traffic behavior
{ system-defined | user-defined } Available in any view
configuration information
[ behavior-name ]
Display the configuration of one

display qos policy { system-defined |
or all classes in one or all QoS
user-defined } [ policy-name [ classifier Available in any view
policies and the associated
tcl-name ] ]
behavior(s) of the class(es)
display qos policy interface
Display QoS policy
[ interface-type interface-number ]
configuration on the specified Available in any view
[ inbound | outbound ] [ pvc { pvc-name
or all interfaces/PVCs
[ vpi/vci ] | vpi/vci } ]

Operation Manual 4 Congestion Management Configuration
4 Congestion Management Configuration
When configuring congestion management, go to these sections for information you are interested in:
z Congestion Management Overview
z Configuring FIFO
z Configuring PQ
z Configuring CQ
z Configuring WFQ
z Configuring CBQ
z Configuring RTP Priority Queuing
z Configuring QoS Tokens
z Configuring Packet Information Pre-Extraction
z Configuring Local Fragment Pre-drop
Congestion Management Overview

Congestion occurs on an interface or PVC where the arrival rate of packets is faster than the sending
rate. If there is no enough buffer capacity to store these packets, a part of them will be lost, which may
cause the sending device to retransmit these packets because of timeout, thus leading to a vicious
circle.
The key to congestion management is how to define a dispatching policy for resources to decide the
order of forwarding packets when congestion occurs.
Congestion Management Policies
In general, congestion management adopts queuing technology. The system uses a certain queuing
algorithm for traffic classification, and then uses a certain precedence algorithm to send the traffic. Each
queuing algorithm is used to handle a particular network traffic problem and has significant impacts on
bandwidth resource assignment, delay, and jitter.
Several common queue-scheduling mechanisms are introduced here.

4 Congestion Management Configuration Operation Manual
FIFO
Figure 4-1 FIFO queuing
Packets to be sent
through this interface Packets sent
Queue Interface
Sending queue
As shown in Figure 4-1, First in First Out (FIFO) queuing determines the order of forwarding packets
according to the arrival time. On a device, the resources assigned for the packets are based on the
arrival time of the packets and the current load status of the device. The best-effort service model
adopts FIFO queuing.
If there is only one FIFO output/input queue on each port of a device, malicious applications may
occupy all network resources and seriously affect mission-critical data transmission.
FIFO queuing is adopted by default.
Priority queuing
Figure 4-2 Priority queuing (PQ)
High queue
Packets to be sent
through this interface Packets sent
Middle queue
Interface
Normal queue
Classify Schedule Sending queue

Bottom queue
Priority queuing is designed for mission-critical applications. The key feature of mission-critical
applications is that they require preferential service to reduce the response delay when congestion
occurs. Priority queuing can flexibly determine the order of forwarding packets by network protocol (for
example, IP and IPX), incoming interface, packet length, source/destination address, and so on. Priority
queuing classifies packets into four queues: top, middle, normal, and bottom, in descending priority
order. By default, packets are assigned to the normal queue.
Priority queuing schedules the four queues strictly according to the descending order of priority. It sends
packets in the queue with the highest priority first. When the queue with the highest priority is empty, it
sends packets in the queue with the second highest priority. In this way, you can assign the
mission-critical packets to the high priority queue to ensure that they are always served first. The
common service packets are assigned to the low priority queues and transmitted when the high priority
queues are empty.
The disadvantage of priority queuing is that packets in the lower priority queues cannot be transmitted if
there are packets in the higher queues for a long time.
Custom queuing
Figure 4-3 Custom queuing (CQ)
CQ organizes packets into 16 classes (corresponding to 16 queues) by certain rules. A certain class of
packets enters the corresponding custom queue according to FIFO queuing.
Queues 1 through 16 are customer queues, as shown in Figure 4-3. You can define traffic classification
rules and assign a percentage of interface/PVC bandwidth for each of these 16 customer queues.
During a cycle of queue scheduling, packets in the system queue are sent preferentially till the system
queue is empty. Then round robin queue scheduling is performed for the 16 customer queues, that is, a
certain number of packets (based on the percentage of interface bandwidth assigned for each queue)
are taken out from a queue and forwarded in the ascending order of queue 1 to queue 16. In CQ,
packets of different applications are assigned with different bandwidths. In this way, mission-critical
packets are assigned with more bandwidth, and at the same time, normal packets are also assigned
with certain bandwidth. By default, packets are assigned to queue 1.
Another advantage of CQ is that bandwidth can be assigned according to the utilization of applications,
so CQ is suitable for applications with the special requirement for bandwidth. Though round robin queue
scheduling is performed for the 16 customer queues, no fixed service time segment is assigned for
each queue. When there are no packets of certain classes, the bandwidth allocated to packets of the
existing classes increases.

Weighted fair queuing
Figure 4-4 Weighted fair queuing (WFQ)
Before WFQ is introduced, you need to understand fair queuing (FQ). FQ is designed for fairly sharing
network resources, reducing the delay and jitter of all traffic. FQ takes all the aspects into consideration:
z Different queues have fair dispatching opportunities for delay balancing among streams.
z Short packets and long packets are fairly scheduled: if there are long packets and short packets in
queues, statistically the short packets should be scheduled preferentially to reduce the jitter
between packets on the whole.
Compared with FQ, WFQ takes weights into account when determining the queue scheduling order.
Statistically, WFQ gives high priority traffic more scheduling opportunities than low priority traffic. WFQ
can automatically classify traffic according to the “session” information of traffic (protocol type, TCP or
UDP source/destination port numbers, source/destination IP addresses, IP precedence bits in the ToS
field, etc), and try to provide as many queues as possible so that each traffic flow can be put into these
queues to balance the delay of every traffic flow on a whole. When dequeuing packets, WFQ assigns
the outgoing interface bandwidth to each traffic flow by the precedence. The higher precedence value a
traffic flow has, the more bandwidth it gets.
For example, assume that there are five flows in the current interface, with the precedence being 0, 1, 2,
3, and 4 respectively. The total bandwidth quota is the sum of all the (precedence value + 1)s, that is, 1
+ 2 + 3 + 4 + 5 = 15.
The bandwidth percentage assigned to each flow is (precedence value of the flow + 1)/total bandwidth
quota. The bandwidth percentages for flows are 1/15, 2/15, 3/15, 4/15, and 5/15 respectively.
Because WFQ can balance the delay and jitter of every flow when congestion occurs, it is effectively
applied in some special occasions. For example, WFQ is adopted in the assured forwarding (AF)
services of the Resource Reservation Protocol (RSVP). In Generic Traffic Shaping (GTS), WFQ is used
to schedule buffered packets.
CBQ
Class-based queuing (CBQ) extends WFQ by supporting user-defined classes. CBQ assigns an
independent reserved FIFO queue for each user-defined class to buffer data of the class. In the case of
network congestion, CBQ assigns packets to queues by user-defined traffic classification rules. It is
necessary to perform the congestion avoidance mechanism (tail drop or weighted random early
detection (WRED)) and bandwidth restriction check before packets are enqueued. When being
dequeued, packets are scheduled by WFQ.
CBQ provides an emergency queue to enqueue emergent packets. The emergency queue is a FIFO
queue without bandwidth restriction. However, delay sensitive flows like voice packets may not be
transmitted timely in CBQ since packets are fairly treated. To solve this issue, Low Latency Queuing
(LLQ) was introduced to combine PQ and CBQ to transmit delay sensitive flows like voice packets
preferentially.
When defining traffic classes for LLQ, you can configure a class of packets to be transmitted
preferentially. Such a class is called a priority class. The packets of all priority classes are assigned to
the same priority queue. It is necessary to check bandwidth restriction of each class of packets before
the packets are enqueued. During the dequeuing operation, packets in the priority queue are
transmitted first. WFQ is used to dequeue packets in the other queues.
In order to reduce the delay of the other queues except the priority queue, LLQ assigns the maximum
available bandwidth for each priority class. The bandwidth value is used to police traffic in the case of
congestion. In the case of no congestion, a priority class can use more than the bandwidth assigned to
it. In the case of congestion, the packets of each priority class exceeding the assigned bandwidth are
discarded. LLQ can also specify burst-size.
The system matches packets with classification rules in the following order:
z Match packets with priority classes and then the other classes.
z Match packets with priority classes in the order configured.
z Match packets with other classes in the order configured.
z Match packets with classification rules in a class in the order configured.
RTP priority queuing
Real-time transport protocol (RTP) priority queuing is a simple queuing technology designed to
guarantee QoS for real-time services (including voice and video services). It assigns RTP voice or video
packets to high-priority queues for preferential sending, thus minimizing delay and jitter and ensuring
QoS for voice or video services sensitive to delay.
Figure 4-5 RTP queuing
As shown in Figure 4-5, RTP priority queuing assigns RTP packets to a high-priority queue. An RTP
packet is a UDP packet with an even destination port number in a configurable range. RTP priority
queuing can be used in conjunction with any queuing (such as, FIFO, PQ, CQ, WFQ and CBQ), while it
always has the highest priority. Since LLQ of CBQ can also be used to guarantee real-time service data
transmission, it is not recommended to use RTP priority queuing in conjunction with CBQ.
Congestion Management Technology Comparison
Breaking through the single congestion management policy of FIFO for traditional IP devices, the
current device provides all the congestion management technologies above mentioned to offer
powerful QoS capabilities, meeting different QoS requirements of different applications. The following
table compares these queuing technologies for efficient use.
Table 4-1 Congestion management technology comparison
Number of
Type Advantages Disadvantages
queues
z All packets are treated equally.
The available bandwidth, delay
and drop probability are
determined by the arrival order of
the packets.
z No restriction on the
z No need to configure, easy to incooperative data sources (that
FIFO 1 use is, flows without flow control
z Easy to operate, low delay mechanism, UDP for example),
resulting in bandwidth loss of
cooperative data sources such
as TCP.
z No delay guarantee to
time-sensitive real-time
applications, such as VoIP
z Need to configure; low
processing speed
Provide absolute bandwidth and
delay guarantees for real-time and z If there is no restriction on
PQ 4 bandwidth assigned to
mission critical applications such as
VoIP high-priority packets, low-priority
packets may fail to get
bandwidth.
z Provide different bandwidth
percentages for different
applications Need to configure; low processing
CQ 16
z If packets of certain classes do speed
not exist, it can increase the
bandwidth for existing packets.

Number of
Type Advantages Disadvantages
queues
z Easy to configure
z Provide a bandwidth guarantee
for packets from cooperative
(interactive) sources (such as
TCP packets)
z Reduce jitter
z Reduce the delay for interactive
applications with a small amount The processing speed is faster than
WFQ Configurable of data that of PQ and CQ but slower than
z Assign different bandwidths to that of FIFO
traffic flows with different
priorities
z When the number of traffic
classes decreases, it can
automatically increase the
bandwidth for the existing
classes.
z Flexibly classify traffic based on
various rules and provide
different queue scheduling
mechanisms for expedited
forwarding (EF), assured
forwarding (AF) and best-effort
(BE) services.
z Provide a highly precise
bandwidth guarantee and queue
scheduling on the basis of AF
service weights for various AF
Configurable services.
CBQ The system overhead is large.
(0 to 64)
z Provide absolutely preferential
queue scheduling for the EF
service to meet the delay
requirement of real-time data;
overcome the disadvantage of
PQ that some low-priority
queues are not serviced by
restricting the high-priority traffic.
z Provide WFQ scheduling for
best-effort traffic (the default
class).
If the burst traffic is too heavy, you can increase the queue length to make queue scheduling more
accurate.
Configuring FIFO
FIFO is the default queue scheduling mechanism for an interface or PVC, and the FIFO queue size is
configurable.
FIFO Configuration Procedure
Follow these steps to configure FIFO:

Enter
interface interface-type interface-number
Enter interface view
interface view —
Enter PVC interface atm interface-number
or PVC view
view pvc vpi/vci
Required
Set the FIFO queue size qos fifo queue-length queue-length
75 by default
For the queuing function to take effect on Tunnel interfaces, sub-interfaces, or VT/dialer interfaces
using PPPoE, PPPoA, PPPoEoA, or PPPoFR at the data link layer, you must enable line rate on them.
FIFO Configuration Example
# Set the FIFO queue size to 100.

[Sysname] interface ethernet1/1
[Sysname-Ethernet1/1] qos fifo queue-length 100
Configuring PQ
You can define multiple rules for a priority queue list (PQL) and apply the list to an interface or PVC.
When a packet arrives at the interface or PVC, the system matches the packet with each rule in the
order configured. If a match is found, the packet is assigned to the corresponding queue and the match
procedure is complete. If the packet cannot match any rule, the packet is assigned to the default queue
normal.
PQ Configuration Procedure
Apply a PQ list to an interface or PVC. For an interface or PVC, a newly applied PQ list overwrites the
previous one.
Follow these steps to configure PQ:


qos pql pql-index protocol ip

[ queue-key key-value ] queue { bottom |
middle | normal | top }
Required
Configure a PQ list or
Use either command.
qos pql pql-index inbound-interface
interface-type interface-number queue
{ bottom | middle | normal | top }
Optional
Specify the default queue for qos pql pql-index default-queue This command
the PQ list { bottom | middle | normal | top } specifies the queue to
which unmatched
packets are assigned.
qos pql pql-index queue { bottom |

Set the queue size middle | normal | top } queue-length Optional
queue-length
Enter
interface interface interface-type interface-number
Enter view
interface view —
or PVC view Enter PVC interface atm interface-number
view pvc vpi/vci
Required
Apply the PQ list to the
qos pq pql pql-index FIFO applies by
interface
default
display qos pq interface [ interface-type Optional
Display PQ list configuration
interface-number ] [ pvc { pvc-name
information Available in any view
Display the contents of the Optional
specific PQ list or all the PQ display qos pql [ pql-number ]
lists Available in any view
z PQ is applicable to all physical interfaces except interfaces using the X.25 or LAPB protocol at the
data link layer.
z For the queuing function to take effect on Tunnel interfaces, sub-interfaces, or VT/dialer interfaces
using PPPoE, PPPoA, PPPoEoA, or PPPoFR at the data link layer, you must enable line rate on
them.
PQ Configuration Example
As shown in the figure below, both Server and Host A send data to Host B through Router A. Suppose
Server sends critical packets and Host A sends non-critical packets. Congestion may occur on Serial
1/1 and result in packet loss because the rate of the incoming interface Ethernet 1/1 is greater than that
of the outgoing interface Serial 1/1 on Router A. It is required that the critical packets from Server be
transmitted preferentially when congestion occurs in the network.
Figure 4-6 Network diagram for PQ
Configure Router A:
# Configure ACLs to match the packets from Server and Host A respectively.
[RouterA-acl-basic-2001] rule permit source 1.1.1.1 0.0.0.0
[RouterA-acl-basic-2002] rule permit source 1.1.1.2 0.0.0.0
# Configure a PQ list that assigns the packets from Server to the top queue and those from Host A to the
bottom queue when congestion occurs. The maximum queue size of the top queue is set to 50 while
that of the bottom queue is set to 100.
[RouterA] qos pql 1 protocol ip acl 2001 queue top
[RouterA] qos pql 1 protocol ip acl 2002 queue bottom
[RouterA] qos pql 1 queue top queue-length 50
[RouterA] qos pql 1 queue bottom queue-length 100
# Apply PQ list 1 to Serial 1/1.

[RouterA] interface serial 1/1
[RouterA-Serial1/1] qos pq pql 1
Configuring CQ
You can configure a CQ list that contains up to 16 queues (1-16), with each queue including the match
criteria for packets to enter the queue, the length of the queue and the bytes sent from the queue during
a cycle of round robin queue scheduling. Only one CQ list can be applied to an interface or PVC.

Configuration Procedure
Follow these steps to configure CQ:

qos cql cql-index protocol ip

[ queue-key key-value ] queue
queue-number
Optional
Configure a CQ list or
Use either command.
qos cql cql-index inbound-interface
interface-type interface-number
queue queue-number
Optional
qos cql cql-index default-queue This command specifies
Specify the default queue the queue to which
queue-number
unmatched packets are
assigned.
qos cql cql-index queue

Set the length of a queue queue-number queue-length Optional
queue-length
Configure the bytes sent from a
qos cql cql-index queue
queue during a cycle of round Optional
queue-number serving byte-count
robin queue scheduling
Enter interface view interface-number
interface view —
or PVC view
view pvc vpi/vci
Apply the CQ list to the Required

qos cq cql cql-index
interface or PVC FIFO applies by default.
display qos cq interface Optional

Display interface/PVC CQ list
[ interface-type interface-number ]
configuration information Available in any view
[ pvc { pvc-name [ vpi/vci ] | vpi/vci } ]
Display information about CQ Optional

display qos cql
lists Available in any view
z CQ is applicable to all physical interfaces except interfaces using X.25 or LAPB protocol at the data
link layer.
them.

CQ Configuration Example
Configure CQ to assign packets from Ethernet 1/1 to queue 1 and specify queue 1 to send 2000 bytes
during a cycle of round robin queue scheduling.

# Configure CQ list 1.
[Sysname] qos cql 1 inbound-interface ethernet 1/1 queue 1
[Sysname] qos cql 1 queue 1 serving 2000
# Apply CQ list 1 to Serial 1/0.

[Sysname] interface serial 1/0
[Sysname-Serial 1/0] qos cq cql 1
Configuring WFQ
On an interface/PVC without WFQ configured, the qos wfq command can be used to enable WFQ and
configure WFQ-related parameters. If WFQ is configured for the interface/PVC, the qos wfq command
can be used to modify the WFQ-related parameters.
Follow these steps to configure WFQ:

Enter
interface interface-type interface-number
interface view
Enter
—
interface view Enter PVC interface atm interface-number
view pvc vpi/vci
qos wfq [ precedence | dscp ] Required

Configure WFQ [ queue-length max-queue-length FIFO applies by
[ queue-number total-queue-number ] ] default
display qos wfq interface Optional
Display interface/PVC WFQ
[ interface-type interface-number ] [ pvc
{ pvc-name [ vpi/vci ] | vpi/vci } ]

z WFQ is applicable to all physical interfaces except interfaces using X.25 or LAPB at the data link
layer.
them.
WFQ Configuration Example
Configure WFQ on Serial 2/0, setting the maximum queue size to 100, and the total number of queues
to 512.


# Configure WFQ on Serial 2/0, setting the maximum queue size to 100, and the total number of queues
to 512.
[Sysname-Serial2/0] qos wfq queue-length 100 queue-number 512
Configuring CBQ
Follow these steps to configured CBQ:
1) Create a class and define a set of traffic match criteria in class view.
2) Create a traffic behavior, and define a group of QoS features in traffic behavior view.
3) Create a policy, and associate a traffic behavior with a class in policy view.
4) Apply the QoS policy in the interface or PVC view.
The system pre-defines some classes, traffic behaviors and policies. The detailed description is given
below.
Pre-defined classes
The system pre-defines some classes and defines general rules for them. You can use these
pre-defined classes when defining a policy.
z The default class
default-class: Matches the default traffic.
z DSCP-based pre-defined classes
ef, af1, af2, af3, af4: Matches IP DSCP value ef, af1, af2, af3, af4 respectively.

z IP precedence-based pre-defined classes

ip-prec0, ip-prec1, …ip-prec7: Matches IP precedence value 0, 1, …7 respectively.
z MPLS EXP-based pre-defined classes
mpls-exp0, mpls-exp1, …mpls-exp7: Matches MPLS EXP value 0, 1, …7 respectively.
Pre-defined traffic behaviors
The system pre-defines some traffic behaviors and defines QoS features for them.
z ef: Assigns a class of packets to the EF queue and assigns 20% of the available interface/PVC
bandwidth to the class of packets.
z af: Assigns a class of packets to the AF queue and assigns 20% of the available interface/PVC
bandwidth to the class of packets.
z be: Defines no features.
Pre-defined QoS policy
The system pre-defines a QoS policy, specifies a pre-defined class for the policy and associates a
pre-defined behavior with the class. The policy is named default, with the default CBQ action.
The policy default is defined as follows:
z Associates the pre-defined class ef with the pre-defined traffic behavior ef.
z Associates pre-defined classes af1 through af4 with the pre-defined traffic behavior af.
z Associates the pre-defined class default-class with the pre-defined traffic behavior be.
Configuring the Maximum Available Interface Bandwidth
The maximum available interface bandwidth refers to the maximum interface bandwidth used for
bandwidth check when CBQ enqueues packets, rather than the actual bandwidth of the physical
interface.
Follow these steps to configure the maximum interface available bandwidth:

Enter interface view interface interface-type interface-number —
Configure the maximum
qos max-bandwidth bandwidth Required
available interface bandwidth
If no maximum available interface bandwidth is configured for any type of interfaces, the bandwidth
used in CBQ calculation is as follows:
z The actual baudrate or rate of a physical interface.
z Total bandwidth of the bound logical serial interfaces, such as T1/E1 interfaces and multilink frame
relay (MFR) interfaces.
z 1000000 kbps for template interfaces such as VT, dialer, BRI, and PRI interfaces.
z 0 kbps for the other virtual interfaces such as tunnel interfaces.

z You are recommended to configure the maximum available interface bandwidth to be smaller than
the actual available bandwidth of a physical interface or logical link.
z On a primary channel interface (such as VT, dialer, BRI, or PRI) configured with the qos
max-bandwidth command, AF and EF perform queue bandwidth check and calculation based on
the bandwidth specified with the qos max-bandwidth command. The same is true of AF and EF
synchronized to the sub-channel interfaces (such as VA interfaces or B channels), where
sub-channel interface bandwidth is ignored. As the QoS configurations of the primary channel
interface and the sub-channel interfaces are the same in this case, prompts are output only for the
primary channel interface. If the qos max-bandwidth command is not configured, AF and EF on
the primary channel interface calculate queue bandwidth based on 1 Gbps of bandwidth, while AF
and EF synchronized to the sub-channel interfaces calculate queue bandwidth based on actual
sub-channel interface bandwidth. In this case, if queuing on a sub-channel interface fails due to
bandwidth change, the prompt will be output for the sub-channel interface.
z On an MP-group interface or MFR interface configured with the qos max-bandwidth command,
AF and EF perform queue bandwidth check and calculation based on the bandwidth specified with
the qos max-bandwidth command. On an MP-group interface or MFR interface without the qos
max-bandwidth command configured, if the sum of sub-channel bandwidth equals to or exceeds
the sum of AF bandwidth and EF bandwidth, AF and EF calculate bandwidth based on the actual
interface bandwidth; otherwise, AF and EF calculate bandwidth based on 1 Gbps of bandwidth,
and the message indicating insufficient bandwidth is displayed. In the latter case, the queuing
function may fail to take effect. You can use the qos reserved-bandwidth command to set the
maximum percentage of the reserved bandwidth to the available bandwidth.
z On Tunnel interfaces, sub-interfaces, or VT/dialer interfaces using PPPoE, PPPoA, PPPoEoA, or
PPPoFR at the data link layer, you should configure the qos max-bandwidth command to provide
base bandwidth for CBQ bandwidth calculation.
Maximum available interface bandwidth configuration example
1) Network requirements
Set the maximum available interface bandwidth to 60 kbps.
2) Configuration procedure

# Set the maximum available bandwidth of Ethernet 1/1 to 60 kbps.

[Sysname-Ethernet1/1] qos max-bandwidth 60

Defining a Class
To define a class, you need to create the class with a name specified and then configure matching
criteria in class view.
Follow these steps to define a class:

Required
Create a class and enter traffic classifier tcl-name By default, the and keyword is
class view [ operator { and | or } ] used. That is, the relation between
matching criteria is logic AND.
Define a match criterion if-match [ not ] match-criteria Required
display traffic classifier Optional

Display class information { system-defined |
user-defined } [ tcl-name ] Available in any view
Define a class named test to match packets having an IP precedence value of 6.
# Define a class and enter class view.

[Sysname] traffic classifier test
# Define the match criterion.

[Sysname-classifier-test] if-match ip-precedence 6
Defining a Traffic Behavior
To define a traffic behavior, you should first create the traffic behavior with a name specified and then
configure attributes for it in traffic behavior view.
1) Configure AF and the minimum guaranteed bandwidth

Follow these steps to configure AF and the minimum available bandwidth:



Required
The entered
Create a traffic behavior and behavior-name cannot
traffic behavior behavior-name
enter traffic behavior view be the name of a traffic
behavior pre-defined by
the system.
Configure AF and the minimum queue af bandwidth { bandwidth | pct

Required
guaranteed bandwidth percentage }
display traffic behavior Optional

{ system-defined | user-defined }
[ behavior-name ]
z This traffic behavior can be applied only in the outbound direction of an interface or ATM PVC.
z In the same traffic behavior, the same bandwidth unit must be used to configure the queue ef
command and the queue af command, either bandwidth or percentage.
2) Configuring EF and the maximum bandwidth

Follow these steps to configure EF and the maximum bandwidth:

Required
Create a traffic behavior The entered traffic behavior
and enter traffic behavior traffic behavior behavior-name name cannot be the name of a
view traffic behavior pre-defined by
the system.
queue ef bandwidth { bandwidth
Configure EF and the
[ cbs burst ] | pct percentage Required
maximum bandwidth
[ cbs-ratio ratio] }

[ behavior-name ]

z The queue ef command can not be used in conjunction with the commands queue af,
queue-length, and wred for the same traffic behavior.
z The default class cannot be associated with a traffic behavior including EF.
z In the same traffic behavior, the same bandwidth unit must be used to configure the queue ef
command and the queue af command, either bandwidth or percentage.
3) Configuring WFQ
Follow these steps to configure WFQ:

Required
Create a traffic behavior The entered traffic behavior
and enter traffic behavior traffic behavior behavior-name name cannot be the name of a
view traffic behavior pre-defined by
the system.
queue wfq [ queue-number
Configure WFQ Required
total-queue-number ]

[ behavior-name ]
A traffic behavior with WFQ applied can only be associated with the default class.
4) Configuring the maximum queue size

Configure the maximum queue size and adopt tail drop.
Follow these steps to configure the maximum queue size:

Required
Create a traffic behavior and The entered traffic behavior
traffic behavior behavior-name name cannot be the name of
a traffic behavior pre-defined
by the system.
Set the maximum queue size queue-length queue-length Required


{ system-defined |
user-defined } [ behavior-name ]
The queue-length command can be used only after the queue af command or the queue wfq
command has been configured. Executing the undo queue af command or the undo queue wfq
command cancels the queue-length command configuration as well.
5) Adopting WRED drop

Follow these steps to adopt WRED drop:

Required
Create a traffic behavior
traffic behavior The entered traffic behavior name
and enter traffic behavior
behavior-name cannot be the name of a traffic
view
behavior pre-defined by the system.
Required
dscp: Uses the DSCP precedence
value for calculating drop probability
wred [ dscp | for a packet.
Adopt WRED drop
ip-precedence ] ip-precedence: Uses the IP
precedence value for calculating drop
probability for a packet. This keyword
is adopted by default.

Display traffic behavior { system-defined | Optional
configuration information user-defined } Available in any view
[ behavior-name ]
z The wred [ dscp | ip-precedence ] command must be issued after the queue af command or the
queue wfq command is used.
z The wred command and the queue-length command are mutually exclusive.
z If the WRED drop configuration is removed, other configurations under it are deleted.
z When a QoS policy including the WRED traffic behavior is applied to an interface, the previous
interface-level WRED configuration gets invalid.

6) Configuring the exponent for WRED to calculate average queue size

Follow these steps to configure the exponent for WRED to calculate average queue size:

Required
Create a traffic behavior and traffic behavior The entered traffic behavior
enter traffic behavior view behavior-name name cannot be the name of a
traffic behavior pre-defined by
the system.
Configure the exponent for Required
wred weighting-constant
WRED to calculate average
exponent The default exponent is 9.
queue size

Display traffic behavior { system-defined | Optional
configuration information user-defined } Available in any view
[ behavior-name ]
Before configuring the wred weighting-constant command, make sure the queue af command or the
queue wfq command has been configured and the wred command has been used to enable WRED
drop.
7) Configuring the lower limit, upper limit and drop probability denominator for each DSCP value in
WRED
To perform this configuration, make sure DSCP-based WRED drop has been enabled with the wred
dscp command.
Follow these steps to configure the lower limit, upper limit, and drop probability denominator for a DSCP
value in WRED:

Required
Create a traffic behavior and The entered traffic behavior
traffic behavior behavior-name name cannot be the name of
a traffic behavior pre-defined
by the system.
Configure the lower limit, upper wred dscp dscp-value low-limit
limit and drop probability low-limit high-limit high-limit
Required
denominator for a DSCP value [ discard-probability
in WRED discard-prob ]

{ system-defined |
user-defined } [ behavior-name ]

dscp-value: DSCP value in the range of 0 to 63, which can also be any of the following keywords: ef,
af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2, cs3, cs4, cs5, cs6, cs7,
and default.
z When the wred command is disabled, the wred dscp command is also disabled.
z The WRED drop-related parameters are disabled if the queue af command or the queue wfq
command is disabled.
8) Configuring the lower limit, upper limit and drop probability denominator for each IP precedence
value in WRED
To perform this configuration, make sure IP precedence-based WRED drop has been enabled with the
wred ip-precedence command.
Follow these steps to configure the lower limit, upper limit, and drop probability denominator for an IP
precedence value in WRED:

Required
The entered traffic
Create a traffic behavior and behavior name cannot be
traffic behavior behavior-name
enter traffic behavior view the name of a traffic
behavior pre-defined by
the system.
Configure the lower limit, upper wred ip-precedence precedence

limit and drop probability low-limit low-limit high-limit
Required
denominator for an IP high-limit [ discard-probability
precedence value in WRED discard-prob ]
[ behavior-name ]
z The wred ip-precedence command is disabled when the wred command is disabled.
z The WRED drop-related parameters are disabled if the queue af command or the queue wfq
command is disabled.
Define traffic behavior test, enabling AF and setting the minimum guaranteed bandwidth to 200 kbps.
# Define traffic and enter traffic behavior view.

[Sysname] traffic behavior test
# Enable AF and set the minimum guaranteed bandwidth to 200 kbps.

[Sysname-behavior-test] queue af bandwidth 200
Defining a QoS Policy
A QoS policy associates a class with a traffic behavior, which contains multiple QoS actions, include
queue scheduling, EF, AF, WFQ, TP, GTS, WRED, traffic marking, and so on.
Follow these steps to associate a traffic behavior with a specific class in policy view:

Create a policy and enter
qos policy policy-name —
policy view
Required
tcl-name: Class name. It must be
the name of an existing
Associate a traffic system-defined or user-defined
classifier tcl-name behavior
behavior with a class in the class.
behavior-name
policy behavior-name: Name of a
behavior. It must be the name of an
existing system-defined or
user-defined behavior.
display qos policy

Display QoS policy { system-defined | Optional
configuration information user-defined } [ policy-name Available in any view
[ classifier tcl-name ] ]
Applying the QoS Policy
Use the qos apply policy command to apply a policy to a specific physical interface or ATM PVC. A
policy can be applied to multiple physical interfaces or ATM PVCs.
Follow these steps to apply a policy to the specific interface or ATM PVC:



Enter
interface Use either command
Enter interface-number
view Settings in interface view take
interface
view, port Enter port port-group manual effect on the current interface;
group view, group view port-group-name settings in port group view take
or PVC effect on all ports in the port
view interface atm interface-number group; settings in PVC view
Enter PVC take effect on the current PVC.
view
pvc vpi/vci
Apply a policy to the qos apply policy policy-name

Required
interface or PVC { inbound | outbound }
display qos policy interface

Display interface/PVC Optional
[ interface-type interface-number
policy configuration
[ inbound | outbound ] [ pvc Available in any view
information
Specifications for applying QoS policies are as follows:

z A policy configured with any features (including remark, car, gts, queue af, queue ef, queue wfq,
wred) is applicable to common physical interfaces and the VTs referenced by MPs.
z A policy configured with GTS or queuing (queue ef, queue af, queue wfq) features cannot be
applied in the inbound direction of an incoming interface.
them. At the same time, you should configure the qos max-bandwidth command to provide base
bandwidth for CBQ bandwidth calculation.
Create a policy named test. Associate the traffic behavior test_behavior with the traffic class
test_class in the policy, and apply the policy in the inbound direction of Ethernet 1/1.
# Create the policy and enter policy view

[Sysname] qos policy test
# Associate the traffic behavior with the class.

[Sysname-qospolicy-test] classifier test_class behavior test_behavior
[Sysname-qospolicy-test] quit

# Apply the policy to Ethernet 1/1.

[Sysname-Ethernet1/1] qos apply policy test inbound

CBQ Configuration Example
As shown in Figure 4-7, traffic travels from Router C to Router D through Router A and Router B.
Configure a QoS policy to meet the following requirements:
z Traffic from Router C is classified into three classes based on DSCP precedence; perform AF for
traffic with the DSCP precedence being AF11 and AF21 and set a minimum guaranteed bandwidth
percentage of 5% for the traffic.
z Perform EF for traffic with the DSCP precedence being EF and set the maximum bandwidth
percentage for the traffic to 30%.
Before performing the configuration, make sure that:
z The route from Router C to Router D through Router A and Router B is reachable.
z The DSCP fields have been set for the traffic before the traffic enters Router A.
Figure 4-7 Network diagram for CBQ configuration
Configure Router A:
# Define three classes to match the IP packets with the DSCP precedence AF11, AF21 and EF
respectively.
[RouterA] traffic classifier af11_class
[RouterA-classifier-af11_class] if-match dscp af11
[RouterA-classifier-af11_class] quit
[RouterA]traffic classifier af21
[RouterA-classifier-af21] if-match dscp af21
[RouterA-classifier-af21] quit
[RouterA] traffic classifier ef_class
[RouterA-classifier-ef_class] if-match dscp ef
[RouterA-classifier-ef_class] quit
# Define two traffic behaviors, enable AF and set a minimum guaranteed bandwidth percentage of 5%.
[RouterA] traffic behavior af11_behav
[RouterA-behavior-af11_behav] queue af bandwidth pct 5
[RouterA-behavior-af11_behav] quit
[RouterA] traffic behavior af21_behav

[RouterA-behavior-af21_behav] queue af bandwidth pct 5
[RouterA-behavior-af21_behav] quit
# Define a traffic behavior, enable EF and set a maximum bandwidth percentage of 30% (both
bandwidth and delay guarantees are provided).
[RouterA] traffic behavior ef_behav
[RouterA-behavior-ef_behav] queue ef bandwidth pct 30
[RouterA-behavior-ef_behav] quit
# Define a QoS policy to associate the configured traffic behaviors with classes respectively.
[RouterA] qos policy dscp
[RouterA-qospolicy-dscp] classifier af11_class behavior af11_behav
[RouterA-qospolicy-dscp] classifier af21_class behavior af21_behav
[RouterA-qospolicy-dscp] classifier ef_class behavior ef_behav
[RouterA-qospolicy-dscp] quit
# Apply the QoS policy in the outbound direction of an ATM PVC of Router A.
[RouterA] interface atm 1/0
[RouterA-atm1/0] ip address 1.1.1.1 255.255.255.0
[RouterA-atm1/0] pvc qostest 0/40
[RouterA-atm-pvc-atm1/0-0/40-qostest] qos apply policy dscp outbound
With the above configurations complete, EF traffic is forwarded preferentially when congestion occurs.
Displaying and Maintaining CBQ
To do… Use the command…

Display class configuration display traffic classifier { system-defined | user-defined }
information [ tcl-name ]
Display traffic behavior display traffic behavior { system-defined | user-defined }
configuration information [ behavior-name ]
Display QoS policy configuration display qos policy { system-defined | user-defined }
information [ policy-name [ classifier tcl-name ] ]
display qos policy interface [ interface-type
Display interface/PVC QoS policy
interface-number ] [ inbound | outbound ] [ pvc { pvc-name
Display interface/PVC CBQ display qos cbq interface [ interface-type interface-number ]

configuration information [ pvc { pvc-name [ vpi/vci ] | vpi/vci } ]
Configuring RTP Priority Queuing

Follow these steps to configure RTP priority queuing:


interface view —
or PVC view
view pvc vpi/vci
qos rtpq start-port first-rtp-port-number

Configure RTP priority queuing end-port last-rtp-port-number Required
bandwidth bandwidth [ cbs cbs ]
Set the maximum percentage
of the available interface Optional
qos reserved-bandwidth pct percent
bandwidth to be reserved for 80 by default
the RTP priority queue
Display RTP priority queuing

display qos rtpq interface Optional
configuration information on the
[ interface-type interface-number ] [ pvc
interface/PVC or all Available in any view
interfaces/PVCs
For the queuing function to take effect on Tunnel interfaces, sub-interfaces, or VT/dialer interfaces
using PPPoE, PPPoA, PPPoEoA, or PPPoFR at the data link layer, you must enable line rate on them.
RTP Priority Queuing Configuration Example
Configure RTP priority queuing on an interface, and specify up to 70% of the available interface
bandwidth to be reserved for the RTP priority queue.
Configure RTP priority queuing on Serial 1/0: the start port number is 16384, the end port number is
32767, and 64 kbps bandwidth is reserved for RTP packets. When congestion occurs to the outgoing
interface, RTP packets are assigned to the RTP priority queue.


# Specify up to 70% of the available bandwidth to be reserved for the RTP priority queue.
[Sysname-Serial1/0] qos reserved-bandwidth pct 70

# Configure RTP priority queuing on Serial 1/0: the start port number is 16384, the end port number is
32767, and 64 kbps of bandwidth is reserved for RTP packets. When congestion occurs to the outgoing
interface, RTP packets are assigned to the RTP priority queue.
[Sysname-Serial1/0] qos rtpq start-port 16384 end-port 32767 bandwidth 64
Configuring QoS Tokens

QoS Token Configuration Procedure
Since the upper layer protocol TCP provides traffic control, CQ and WFQ may become invalid during
FTP transmission. QoS tokens are used to solve this problem. The token feature of QoS provides a flow
control mechanism for underlying-layer queues. This feature can control the number of packets sent to
the interface underlying-layer queues based on the number of tokens.
You are recommended to set the token number to 1 on an interface for FTP transmission.
If the upper layer protocol, UDP for example, does not provide flow control, you are recommended not
to use the QoS token function in order to improve data transmission efficiency.
Follow these steps to configure QoS tokens:


Required
Specify the number of QoS
qos qmtoken token-number The QoS token feature is
tokens
disabled by default.
z To validate the above configuration, you must execute the shutdown command and then the undo
shutdown command on the interface.
z So far, this feature is available only for serial interfaces and BRI interfaces.
QoS Token Configuration Example
Specify the number of QoS tokens on an interface.



# Set the number of QoS tokens to 1.

[Sysname-Serial2/0] qos qmtoken 1
Configuring Packet Information Pre-Extraction

The packets that a tunnel interface passes to a physical interface are encapsulated in GRE. Thus, the
IP data (including Layer-3 and Layer-4 information) that the QoS module obtains from the physical
interface is the IP data encapsulated in GRE rather than the IP data in the original packets.
To address the problem, you can configure packet information pre-extraction on the tunnel interface to
buffer the IP data in the original packets for its corresponding physical interface to use.
Follow these steps to configure packet information pre-extraction:

Enter tunnel interface view interface tunnel interface-number —
Enable packet information Required

qos pre-classify
pre-extraction Disabled by default
Configuration Example
Enable packet information pre-extraction on a tunnel interface.
# Enable packet information pre-extraction on tunnel interface Tunnel 0.

[Sysname] interface tunnel 0
[Sysname-Tunnel0] qos pre-classify
Configuring Local Fragment Pre-drop

If the packet size is bigger than the MTU of the egress interface, the packet is fragmented into local
fragments. If the first fragment is dropped, the subsequent fragments become invalid fragments, and
therefore it is insignificant to process and transmit these invalid fragments.
With local fragment pre-drop, if the first fragment of a packet is dropped by the QoS module, the
subsequent fragments will be dropped directly without undergoing QoS processing. The local fragment
pre-drop function thus improves the local fragment processing and transmitting efficiency, and reduces
subsequent invalid fragments’ occupation of system resources and network bandwidth.

Local fragment pre-drop is mutually exclusive with matching fragments by fragment attributes or size.
With local fragment pre-drop enabled, non-first fragments inherit the matching result of the first
fragment.
Local fragment pre-drop applies to IPv4 and IPv6 local fragments.
Follow these steps to configure local fragment pre-drop:

Enable local fragment Required

qos fragment pre-drop
pre-drop Disabled by default
Enable local fragment pre-drop on an interface.
# Enable local fragment pre-drop on interface Serial 2/0.

[Sysname-Serial2/0] qos fragment pre-drop

Operation Manual 5 Priority Mapping Configuration
5 Priority Mapping Configuration
When configuring priority mapping, go to these sections for information you are interested in:
z Priority Mapping Overview
z Configuring a Priority Mapping Table
z Configuring the Trusted Precedence Type for a Port
z Displaying and Maintaining Priority Mapping
z Priority Mapping Configuration Examples
Priority Mapping Overview

When a packet enters a device, the device assigns to the packet a series of predefined parameters
(including 802.11e precedence, 802.1p precedence, DSCP precedence, EXP precedence, IP
precedence, local precedence, and drop precedence).
The local precedence and drop precedence are defined as follows:
z Local precedence is a locally significant precedence that the device assigns to a packet. A local
precedence value corresponds to an output queue. Packets with the highest local precedence are
processed preferentially. The specific process method varies with device models.
z Drop precedence is a parameter used for packet drop. The value 2 corresponds to red packets, the
value 1 corresponds to yellow packets, and the value 0 corresponds to green packets. Packets with
the highest drop precedence are dropped preferentially. The specific process method varies with
device models.
The device provides two priority trust modes on a port:
z Trust packet priority: the device assigns to the packet the priority parameters corresponding to the
packet’s priority from the mapping table.
z Trust port priority: the device assigns a priority to a packet by mapping the priority of the receiving
port.
You can select one priority trust mode as needed. Figure 5-1 shows the process of priority mapping on
a device.

5 Priority Mapping Configuration Operation Manual
Figure 5-1 Priority mapping process
The device provides the dot1p-lp priority mapping table, that is, 802.1p-priority-to-local-precedence
mapping table. The following tables list the default priority mapping tables.
Table 5-1 The default lp-dot1p mappings
Input priority value lp-dot1p mapping

Local precedence (lp) 802.1p precedence (dot1p)
0 1
1 2
2 0
3 3
4 4
5 5
6 6
7 7
Table 5-2 Port-priority-to-local-precedence mappings
Port priority Local precedence

0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7

Table 5-3 Local-precedence-to-queue mappings
Local precedence Queue

0 1
1 0
2 1
3 0
4 2
5 2
6 3
7 3
Configuring a Priority Mapping Table

You can modify the priority mapping tables of a device as needed.
You need to decide on the new mapping values.
Follow these steps to configure a priority mapping table:
Required
Enter priority mapping table
qos map-table dot1p-lp You can enter the corresponding
view
priority mapping table view as required.
Required
Configure the priority import import-value-list
mapping table export export-value Newly configured mappings overwrite
the previous ones.
Display the configuration of display qos map-table Optional

the priority mapping table dot1p-lp Available in any view
Configure a dot1p-lp mapping table as shown below.

Table 5-4 dot1p-lp mappings
802.1p precedence Local precedence

0 0
1 0
2 1
3 1
4 2
5 2
6 3
7 3

# Enter the inbound dot1p-lp priority mapping table view.

[Sysname] qos map-table inbound dot1p-lp
# Modify dot1p-lp priority mapping parameters.

[Sysname-maptbl-in-dot1p-lp] import 0 1 export 0
Configuring the Priority for a Port

Port priority is in the range of 0 to 7. You can set the port priority as needed.
You need to decide on a priority for the port.
Follow these steps to configure port priority:

Enter Enter interface interface-type Use either command

interface interface view interface-number Settings in interface view (Ethernet
view or or WLAN-ESS) take effect on the
port current interface; settings in port
group Enter port port-group manual group view take effect on all ports in
view group view port-group-name the port group.


Required
If the device supports only one
Configure a priority for the Given the device supporting only
port priority type, use qos
port one port priority type, the default port
priority priority-value
priority is 0.
If a WLAN-ESS interface in use has WLAN-DBSS interfaces created, its priority cannot be modified. To
modify the priority of the WLAN-ESS interface, you must stop the service the interface provides (that is,
make the current users on the interface offline).
Set the priority of the port to 7.

# Set the priority of Ethernet 1/1 to 7.

[Sysname-Ethernet1/1] qos priority 7
Configuring the Trusted Precedence Type for a Port

You can configure whether to trust the priority of packets. On a device supporting port trusted
precedence type, the priority mapping process for packets is shown in Priority Mapping Overview.
You can configure dot1p for a port. This trusted precedence type trusts the 802.1p precedence of the
received packets and uses the 802.1p precedence for mapping.
z It is determined to trust port priority.

z The trusted precedence type for the port is determined.
z The priority mapping table corresponding to the trusted precedence type is configured. For the
detailed configuration procedure, refer to Configuring a Priority Mapping Table.
Follow these steps to configure the trusted precedence type:


Enter interface interface interface-type Use either command
view interface-number Settings in interface view
Enter
interface (Ethernet or WLAN-ESS) take
view or port effect on the current interface;
Enter port port-group manual settings in port group view
group view group view port-group-name take effect on all ports in the
port group.
Required
Configure the trusted The default trusted
qos trust dot1p
precedence type precedence type varies by
device.
Display the trusted Optional

display qos trust interface
precedence type
configuration
Configure the port to trust the 802.1p precedence.

# Enter port view.

# Configure the port to trust the 802.1p precedence.

[Sysname-Ethernet1/1] qos trust dot1p
Displaying and Maintaining Priority Mapping

Display priority mapping table
display qos map-table [ dot1p-lp ] Available in any view
Display the trusted precedence type display qos trust interface

on the port [ interface-type interface-number ]

Priority Mapping Configuration Examples

Example 1
z It is required that Router enqueue packets based on the 802.1p precedence of packets.
z The priority mapping table is user-defined, as shown in the table below.
Table 5-5 dot1p-lp mappings
802.1p precedence Local precedence

0 0
1 0
2 1
3 1
4 2
5 2
6 3
7 3
Figure 5-2 Network diagram for trusted precedence type configuration
Server
Router
Eth1/2 Eth1/1
Eth1/3 Eth1/4
Server

<Switch> system-view
# Enter inbound dot1p-lp priority mapping table view and modify the priority mapping table parameters.
[Switch] qos map-table inbound dot1p-lp
[Switch-maptbl-in-dot1p-lp] import 0 1 export 0


[Switch-maptbl-in-dot1p-lp] quit
# Configure Ethernet 1/1 to trust the 802.1p precedence.

[Switch] interface ethernet 1/1
[Switch-Ethernet1/1] qos trust dot1p
[Switch-Ethernet1/1] quit



Example 2
The router assigns local precedences for packets according to the mappings between precedence and
interface. The precedences of Ethernet 1/1, Ethernet 1/2, Ethernet 1/3, and Ethernet 1/4 are 1, 3, 5, and
7, respectively.
The default priority mapping table is adopted.
Figure 5-3 Network diagram for trusted precedence type configuration
Server
Router
Eth1/2 Eth1/1
Eth1/3 Eth1/4
Server


<Switch> system-view

[Switch-Ethernet1/1] qos priority 1




Operation Manual 6 Congestion Avoidance
6 Congestion Avoidance
When configuring congestion avoidance, go to these sections for information you are interested in:
z Congestion Avoidance Overview
z Introduction to WRED Configuration
z Configuring WRED on an Interface
z Applying a WRED Table on an Interface
z Displaying and Maintaining WRED
z WRED Configuration Example
Congestion Avoidance Overview

Serious congestion causes great damages to the network resources, and therefore some measures
must be taken to avoid such congestion. As a flow control mechanism, congestion avoidance can
actively drop packets when congestion deteriorates through monitoring the utilization of network
resources (such as queues or memory buffers) to prevent network overload.
Compared to point-to-point flow control, this flow control mechanism is of broader sense because it can
control the load of more flows in a device. When dropping packets from a source end, it can still
cooperate well with the flow control mechanism (such as TCP flow control) at the source end to better
adjust the network traffic to a reasonable load status. The combination of the packet drop policy of the
local device and the flow control mechanism at the source end can maximize throughput and utilization
rate of the network and minimize packet loss and delay.
Traditional packet drop policy
The traditional packet drop policy is tail drop. When the length of a queue reaches the maximum
threshold, all the subsequent packets are dropped.
Such a policy results in global TCP synchronization. That is, if packets from multiple TCP connections
are dropped, these TCP connections go into the state of congestion avoidance and slow start to reduce
traffic, but traffic peak occurs later. Consequently, the network traffic jitters all the time.
RED and WRED
You can use random early detection (RED) or weighted random early detection (WRED) to avoid global
TCP synchronization.
The RED or WRED algorithm sets an upper threshold and lower threshold for each queue, and
processes the packets in a queue as follows:
z When the queue size is shorter than the lower threshold, no packet is dropped;
z When the queue size reaches the upper threshold, all subsequent packets are dropped;
z When the queue size is between the lower threshold and the upper threshold, the received packets
are dropped at random. The longer a queue is, the higher the drop probability is. However, a
maximum drop probability exists.
6 Congestion Avoidance Operation Manual
Different from RED, WRED determines differentiated drop policies for packets with different IP
precedence values. Packets with a lower IP precedence are more likely to be dropped.
Both RED and WRED avoid global TCP synchronization by randomly dropping packets. When the
sending rate of a TCP session slows down after its packets are dropped, the other TCP sessions remain
in high packet sending rates. In this way, some TCP sessions remain in high sending rates in any case,
and the link bandwidth can be fully utilized.
Average queue size
If the current queue size is compared with the upper threshold and lower threshold to determine the
drop policy, bursty traffic is not fairly treated. To solve this problem, WRED compares the average
queue size with the upper threshold and lower threshold to determine the drop probability.
The average queue size reflects the queue size change trend but is not sensitive to bursty queue size
changes, and thus bursty traffic can be fairly treated. The average queue size is calculated using the
formula: average queue size = previous average queue size × (1-2-n) + current queue size × 2-n, where
n can be configured with the qos wred weighting-constant command.
With WFQ queuing adopted, you can set the exponent for average queue size calculation, upper
threshold, lower threshold, and drop probability for packets with different precedence values
respectively to provide differentiated drop policies.
With FIFO queuing, PQ, or CQ adopted, you can set the exponent for average queue size calculation,
upper threshold, lower threshold, and drop probability for each queue to provide differentiated drop
policies for different classes of packets.
Relation between WRED and queuing mechanism
The relation between WRED and queuing mechanism is shown in the following figure:
Figure 6-1 Relationship between WRED and queuing mechanism
Through combining WRED with WFQ, the flow-based WRED can be realized. Because each flow has
its own queue after classification, a flow with a smaller queue size has a lower packet drop probability,

while a flow with a larger queue size has a higher packet drop probability. In this way, the benefits of the
flow with a smaller queue size are protected.
Introduction to WRED Configuration

Configuration Methods
You can configure WRED using one of the following two methods:
z Interface configuration: configure WRED parameters on an interface or PVC and enable WRED.
z WRED table configuration: configure a WRED table in system view and then apply the WRED table
to an interface.
Support for WRED configuration methods depends on the device model.
Introduction to WRED Parameters
Determine the following parameters before configuring WRED:

z The upper threshold and lower threshold: when the average queue size is smaller than the lower
threshold, no packet is dropped. When the average queue size is between the lower threshold and
the upper threshold, the packets are dropped at random. The longer the queue is, the higher the
drop probability is. When the average queue size exceeds the upper threshold, subsequent
packets are dropped.
z The exponent used for average queue size calculation: a bigger exponent makes the average
queue size less sensitive to real-time queue size changes.
z Denominator for drop probability calculation: the bigger the denominator is, the smaller the
calculated drop probability is.
Configuring WRED on an Interface

z The WRED exponent for average queue size calculation is determined (optional).
z The upper threshold and lower threshold for the queue corresponding to the precedence is
determined (optional).
Follow these steps to configure WRED:

interface view —
or PVC view
view pvc vpi/vci
qos wred [ dscp | ip-precedence ]
Enable WRED Required
enable

Set the WRED exponent for qos wred weighting-constant Optional

average queue size calculation exponent 9 by default
qos wred { ip-precedence Optional
ip-precedence | dscp dscp-value }
Set the drop-related By default, the low-limit is
low-limit low-limit high-limit
parameters for the precedence 10, the high-limit is 30, and
high-limit discard-probability
discard-prob the discard-prob is 10.
Display WRED configuration display qos wred interface

information on the [ interface-type interface-number ] Optional
interface/PVC or all [ pvc { pvc-name [ vpi/vci ] | Available in any view
interfaces/PVCs vpi/vci } ]
The qos wred enable command can be configured on a hardware interface without any prerequisites.
However, to configure this command on a software interface, make sure that WFQ queuing has been
applied on the software interface.
z Enable IP precedence-based WRED on an interface.

z Set the following parameters for packets with IP precedence 3: lower threshold 20, upper threshold
40, and drop probability denominator 15.
z Set the exponential factor for the average queue size calculation to 6.


# Enable IP precedence-based WRED.

[Sysname-Ethernet1/1] qos wred ip-precedence enable
# Set the following parameters for packets with IP precedence 3: lower threshold 20, upper threshold 40,
and drop probability denominator 15.
[Sysname-Ethernet1/1] qos wred ip-precedence 3 low-limit 20 high-limit 40
discard-probability 15
# Set the exponential factor for the average queue size calculation to 6.
[Sysname-Ethernet1/1] qos wred weighting-constant 6

Applying a WRED Table on an Interface

A WRED table contains global WRED parameters. Currently, queue (Queue-based table) is supported.
Packets are dropped based on the queue when congestion occurs.
A queue-based WRED table can only be applied to Layer-2 ports, and only queue-based WRED tables
can be applied to Layer 2 ports.
A WRED table can be applied to multiple interfaces. For a WRED table already applied to an interface,
you can modify the values of the WRED table, but you cannot remove the WRED table.
z The type and values of the WRED table are determined.

z Interfaces where the WRED table is to be applied are determined.
Configuring and applying a queue-based WRED table
Follow these steps to configure and apply a queue-based WRED table:
Create a WRED table and

qos wred queue table table-name —
enter its view
Optional
Configure the other queue queue-value low-limit low-limit
WRED parameters [ discard-probability discard-prob ] By default, the low-limit is 10
and the discard-prob is 30.
Enter interface Settings in interface view
interface-number
interface view take effect on the current
view or port interface; settings in port
group view Enter port group view take effect on all
port-group manual port-group-name
group view ports in the port group.
Required
Apply the WRED table to A queue-based WRED table
qos wred apply table-name
the interface/port group is available on only Layer 2
ports.
Configuring and applying a WRED table of another type (except queue-based WRED table)
Follow these steps to configure and apply a WRED table of another type (except queue-based WRED
table):


Enter interface Settings in interface view take
interface-number
interface view effect on the current interface;
view or port settings in port group view
group view Enter port take effect on all ports in the
group view port group.
Required
Apply the WRED table to WRED tables except
qos wred apply table-name queue-based WRED tables
an interface/port group
are applicable on only Layer 3
ports.
Display configuration
information about a display qos wred table Optional
WRED table or all WRED [ table-name ] Available in any view
tables
Displaying and Maintaining WRED

Display WRED configuration display qos wred interface
information on the interface/PVC [ interface-type interface-number ] Available in any view
or all interfaces/PVCs [ pvc { pvc-name [ vpi/vci ] | vpi/vci } ]
Display configuration information

display qos wred table
about a WRED table or all WRED Available in any view
[ table-name ]
tables
WRED Configuration Example

Apply a queue-based WRED table to a Layer 2 port.
# Enter system view

# Configure a queue-based WRED table.

[Sysname] qos wred queue table queue-table1
[Sysname-wred-table-queue-table1] quit

# Apply the WRED table to Ethernet 1/1.

[Sysname-Ethernet1/1] qos wred apply queue-table1

Operation Manual 7 MPLS QoS Configuration
7 MPLS QoS Configuration
When configuring MPLS QoS, go to these sections for information you are interested in:
z MPLS QoS Overview
z Configuring MPLS QoS
z MPLS QoS Configuration Examples
MPLS QoS Overview
The MPLS-related knowledge is necessary for understanding MPLS QoS. Refer to MPLS Basic
Configuration in the MPLS Volume for more information about MPLS.
MPLS QoS provides the following functions:

z Classify traffic on the CE or PE as required. For example, MPLS QoS can classify traffic into three
classes: voice, video, and data.
z When a PE labels a packet, it maps the IP precedence to the EXP field of the label. In this way, the
class information carried in the IP header is carried in the label.
z Differentiated dispatching (such as PQ, WFQ, or CBQ) is performed between two PEs according to
the EXP field to provide differentiated QoS for labeled traffic on an LSP.
The EXP field in an MPLS label is processed as follows:

z Any QoS-capable device can reset the EXP field of the outer label.
z During label encapsulation, the ToS field of the IP packet is directly changed into the EXP field of
the MPLS label.
z The EXP field remains unchanged when label swapping is performed.
z During a label push operation, the EXP field of the newly pushed outer label inherits the EXP field
of the inner label.
z After a label pop operation, if the packet is still an MPLS packet, the EXP field of the popped label
is not copied to the inner label; if the packet is an IP packet, the EXP field of the popped label is not
copied to the ToS field of the IP packet.

7 MPLS QoS Configuration Operation Manual
Configuring MPLS QoS

Before configuring MPLS QoS, you need to perform the MPLS related configuration and specify the
explicitly routed forwarding. Refer to MPLS Configuration in the MPLS Volume for the detailed MPLS
configuration. This chapter introduces only MPLS QoS configuration.
MPLS QoS has the following four types:
z MPLS PQ: refer to Configuring MPLS PQ for the configuration procedure.
z MPLS CQ: refer to Configuring MPLS CQ for the configuration procedure.
z MPLS QoS policy: refer to Configuring a MPLS QoS Policy for the configuration procedure.
z MPLS CAR: refer to Configuring MPLS CAR for the configuration procedure.
Configuring MPLS PQ
Configuration prerequisites
z MPLS related configurations are completed.

z The relation between the MPLS PQ list and MPLS EXP value is determined.
z The interface to which the PQ list is to be applied is determined.
Follow these steps to configure MPLS PQ:

qos pql pql-index protocol mpls exp exp-value-list
Configure a PQ list Required
queue { bottom | middle | normal | top }
Apply the PQ list to the

qos pq pql pql-index Required
interface
z Create a classification rule for MPLS-based PQ list 10, assigning packets with an EXP value of 5 to
the queue top.
z Apply PQ list 10 to Ethernet 1/1.
The configuration procedure is as follows:
[Sysname] qos pql 10 protocol mpls exp 5 queue top
[Sysname-Ethernet1/1] qos pq pql 10

Configuring MPLS CQ

z The relation between the MPLS CQ list and MPLS EXP value is determined.
z The interface to which the CQ list is to be applied is determined.
Follow these steps to configure MPLS CQ:

qos cql cql-index protocol mpls exp

Configure a EXP based CQ list Required
exp-value-list queue queue-number
Apply the CQ list to the interface qos cq cql cql-index Required
z Create a classification rule for MPLS-based CQ list 10, assigning packets with an EXP value of 1 to
queue 2.
z Apply CQ list 10 to Ethernet 1/1.
The configuration procedure is as follows:
[Sysname] qos cql 10 protocol mpls exp 1 queue 2
[Sysname-Ethernet1/1] qos cq cql 10
Configuring a MPLS QoS Policy

z Match criteria are determined.
z Traffic behaviors are determined.
z The QoS policy is determined.
z Interfaces to which the MPLS QoS policy is to be applied are determined.
Follow these steps to configure a MPLS QoS policy:



Required
The tcl-name cannot be the name
traffic classifier tcl-name of any class pre-defined by the
[ operator { and | or } ] system.
Define a class By default, the relation between
match criteria is logic and.
Required
if-match [ not ] mpls-exp
exp-value-list This rule applies only to MPLS
packets.
Exit the current view quit —
traffic behavior behavior-name Required

Define a traffic behavior
remark mpls-exp exp-value Required
qos policy policy-name Required
Define a QoS policy Required

classifier tcl-name behavior
behavior-name Associate the class with the traffic
behavior in MPLS QoS policy view.

interface
view
view or port effect on the current interface;
group view Enter port port-group manual settings in port group view take
group view port-group-name effect on all ports in the port group..
Apply the QoS policy to qos apply policy policy-name

Required
the interface/port group { inbound | outbound }
Configuring MPLS CAR

z The MPLS CAR policy is determined.
z Interfaces where the MPLS CAR is to be applied are determined.
Follow these steps to configure MPLS CAR:



Enter interface interface interface-type interface-number Settings in interface view
interface view take effect on the current
view or port interface; settings in port
group view Enter port group view take effect on
group view all ports in the port group.
qos car { inbound | outbound } { any |

acl acl-number | carl carl-index } cir
Apply the MPLS CAR
policy to the interface/port Required
committed-burst-size [ ebs
group
excess-burst-size ] ] [ green action ] [ red
action ]
The action argument for MPLS can be:

z remark-mpls-exp-continue new-exp: Sets the EXP value to new-exp and continues to process
the packet using the next CAR policy. The new-exp is in the range of 0 to 7.
z remark-mpls-exp-pass new-exp: Sets the EXP value to new-exp and permits the packet to pass
through. The new-exp is in the range of 0 to 7.
The EXP field of an MPLS packet can be set only on the incoming interface of a PE. If incoming packets
are IP packets and outgoing packets are MPLS packets on the interface, the configured MPS CAR
policy is effective.
MPLS QoS Configuration Examples

Configuring QoS for Traffic Within a VPN
As shown in Figure 7-1:

z Both CE 1 and CE 2 belong to VPN 1.
z The bandwidth of the link between PE 1 and P is 2 M.
z The bandwidth of the link between PE 2 and P is 2 M.
It is required to provide differentiated QoS services for flows with different precedence values in VPN 1:
The configuration in this example involves the following two parts:
First, configure MPLS VPN on CE 1, PE 1, P, PE 2, and CE 2 as follows:
z Run OSPF between PE 1 and P, and between PE 2 and P.
z Form a MP-EBGP neighborship between PE and CE.
z Form a MP-IBGP neighborship between PE and PE.
Second, configure MPLS QoS on PE 1 and P as follows:
z Configure a QoS policy on the incoming interface Ethernet 1/1 on PE 1 and set the EXP field value
for an MPLS packet according to the DSCP attribute of the MPLS packets.
z On the device P, classify traffic on the basis of the EXP field and configure flow-based CBQ:
guarantee 10% of the bandwidth for traffic with an EXP value of 1; guarantee 20% of the bandwidth

for traffic with an EXP value of 2; guarantee 30% of the bandwidth for traffic with an EXP value of 3;
guarantee the delay and 40% of the bandwidth for traffic with an EXP value of 4.
Refer to MPLS Configuration in the MPLS Volume for the MPLS VPN configuration. This section
introduces only the MPLS QoS configuration.
Figure 7-1 Network diagram for MPLS QoS
Device Interface IP address Device Interface IP address

CE 1 Eth1/2 10.1.1.2/24 CE 2 Eth1/3 10.2.1.2/24
PE 1 Eth1/1 10.1.1.1/24 PE 2 Eth1/2 10.2.1.1/24
S2/1 12.1.1.1/24 S2/2 12.2.1.1/24
Loop0 1.1.1.1/32 Loop0 1.1.1.2/32
P S2/1 12.1.1.2/24
S2/2 12.2.1.2/24
1) Configure PE 1
# Define four classes, matching respectively the DSCP values AF11, AF21, AF31 and EF of the MPLS
packets in the same VPN.
<PE1> system-view
[PE1] traffic classifier af11
[PE1-classifier-af11] if-match dscp af11
[PE1-classifier-af11] traffic classifier af21
[PE1-classifier-af21] traffic classifier af31
[PE1-classifier-af31] traffic classifier efclass
[PE1-classifier-efclass] if-match dscp ef

[PE1-classifier-efclass] quit
# Define four traffic behaviors to set the EXP field value for MPLS packets.
[PE1] traffic behavior exp1
[PE1-behavior-exp1] remark mpls-exp 1
[PE1-behavior-exp1] traffic behavior exp2
[PE1-behavior-exp4] quit
# Define a QoS policy to associate configured traffic behaviors with traffic classes, that is, mark different
classes of packets with different EXP values.
[PE1] qos policy REMARK
[PE1-qospolicy-REMARK] classifier af11 behavior exp1
[PE1-qospolicy-REMARK] classifier efclass behavior exp4
[PE1-qospolicy-REMARK] quit
# Apply the QoS policy in the inbound direction of the interface of the PE in the MPLS network.
[PE1] interface ethernet 1/1
[PE1-Ethernet1/1] qos apply policy REMARK inbound
[PE1-Ethernet1/1] quit
2) Configure P
# Define four classes, matching respectively EXP values 1, 2, 3 and 4 of the MPLS packets.
<P> system-view
[P] traffic classifier EXP1
[P-classifier-EXP1] if-match mpls-exp 1
[P-classifier-EXP1] traffic classifier EXP2
[P-classifier-EXP4] quit
# Define traffic behaviors to set respective bandwidth percentages and delays.

[P] traffic behavior AF11
[P-behavior-AF11] queue af bandwidth pct 10
[P-behavior-AF11] traffic behavior AF21
[P-behavior-AF21] traffic behavior AF31
[P-behavior-AF31] traffic behavior EF

[P-behavior-EF] queue ef bandwidth pct 40

[P-behavior-EF] quit
# Define a QoS policy that satisfies the following requirements: guarantee 10% of the bandwidth for
traffic with an EXP value of 1; guarantee 20% of the bandwidth for traffic with an EXP value of 2;
guarantee 30% of the bandwidth for traffic with an EXP value of 3; guarantee the delay and 40% of the
bandwidth for traffic with an EXP value of 4.
[P] qos policy QUEUE
[P-qospolicy-QUEUE] classifier EXP1 behavior AF11
[P-qospolicy-QUEUE] classifier EXP4 behavior EF
[P-qospolicy-QUEUE] quit
# Apply the QoS policy in the outbound direction of Serial 2/2 on device P.
[P] interface serial 2/2
[P-Serial2/2] qos apply policy QUEUE outbound
After the above configuration, when congestion occurs in VPN 1, the bandwidth proportion between
flows with the DSCP value being af11, af21, af31, and ef is 1:2:3:4, and the delay for the flow with the
DSCP value being ef is smaller than the other traffic flows.

Operation Manual 8 DAR Configuration
8 DAR Configuration
When configuring DAR, go to these sections for information you are interested in:
z DAR Overview
z Configuring DAR
z Displaying and Maintaining DAR
z DAR Configuration Examples
The DAR feature is only applicable to IP packets.
DAR Overview
Today, the Internet has become the major media for enterprises to implement their ever growing service
oriented applications. The simple mechanism that only checks the IP header in packets cannot meet the
requirements of current complicated networks any longer. Therefore, the concept of Deeper Application
Recognition (DAR) based on service was put forward.
DAR is an intelligent recognition and classification tool that is capable of checking and recognizing the
contents and dynamic protocols from Layer 4 to Layer 7 (for example, BT, HTTP, FTP, RTP) in the
packets, to distinguish the application-based protocols. This overcomes the disadvantage that the
packets can only be classified in a simple way previously.
DAR recognizes different protocols in the following ways:
z Protocols such as HTTP, FTP, RTP, RTCP and BitTorrent are recognized by protocol rules. DAR
can automatically recognize their dynamic port numbers; match both protocol and data packets.
z All other TCP/UDP based protocols are recognized by port number, that is, only protocol packets
rather than data packets are matched.
Recognizing and classifying packets deeper help enhance users’ control granularity on data streams
and implement high-priority policies for critical service data, thus to better protect users’ investment.
IP Packet
IP packet format
The IP packet format is shown in Figure 8-1. An IP header without the option field is 20 bytes in length.

8 DAR Configuration Operation Manual
Figure 8-1 The format and fields of an IP datagram
The protocol field in the header is 8-bit long. The protocol field value indicates the protocol type of the
data.
Table 8-1 lists the recognizable protocol field values and corresponding protocols.
Table 8-1 Protocols corresponding to the protocol field values
Protocol field value Protocol

1 ICMP
2 IGMP
4 IPinIP
6 TCP
8 EGP
17 UDP
47 GRE
50 ESP
51 AH
88 EIGRP
Flags field for fragmentation in the IP header
Figure 8-2 shows the format of the 3-bit flags in an IP packet.

Figure 8-2 Format of the 3-bit flags
The lower 2 bits of the flags field control IP packet fragmentation. The 3 bits in the flags field are defined
as follows:

z Reserved: must be 0.
z Do not fragment: 0 indicates that fragmentation is allowed, and 1 indicates that fragmentation is
forbidden.
z More fragments: 0 indicates that the packet is the last fragment, and 1 indicates that it is not the last
fragment.
Therefore, the 3-bit flags field 001 indicates that the IP packet is an IP fragment, and the 3-bit flags field
000 indicates that the IP packet is the last IP fragment.
TCP Packet
TCP packet format
Figure 8-3 shows the format of a TCP packet.

Figure 8-3 TCP packet format
Table 8-2 describes the 6 flag bits in the TCP header.
Table 8-2 Description on the 6 flag bits in the TCP header
Flag bit Description

URG The urgent pointer is valid.
ACK The acknowledgement number is valid.
PSH The receiver should pass the data to the application layer as soon as possible.
RST Reset the connection.
SYN Synchronize sequence numbers to initiate a connection

The sender has finished sending data. This field is used to terminate a
FIN
connection.
TCP state transition
Figure 8-4 shows TCP state transition.

Figure 8-4 TCP state transition diagram
The protocols using TCP can be static or dynamic. Static protocols use fixed port numbers for
interaction, while dynamic protocols use negotiated port numbers.
UDP Packet
Figure 8-5 shows the UDP packet format.

Figure 8-5 UDP packet format
Like TCP, protocols employing UDP can be static or dynamic. Static protocols use fixed port numbers
for interaction, while dynamic protocols use negotiated port numbers.
HTTP Packet
There are two types of HTTP packets: request packets and response packets. Figure 8-6 shows the
HTTP packets format.
Figure 8-6 HTTP packet format

z The header of an HTTP request packet consists of a request line and header. The request line
consists of the request type field, the URL field, and the HTTP version field separated by spaces.
z The header of an HTTP response packet consists of a status line and header. The status line
consists of the HTTP version field, the status code field, and the status phrase field separated by
spaces.
z Both the request packet headers and the response packet headers consist of several optional
fields. The response packet header contains the HOST field, which is used to identify the host
name and the port number of the server. The header of a packet with body load contains the
Content-Type field, which is used to identify the MIME type of body load.
z When the length of an HTTP packet with body load exceeds the maximum segment size (MSS) of
TCP, the packet is fragmented.
RTP Packet
A Real-time Transport Protocol (RTP) packet is encapsulated in a UDP packet. Usually a UDP packet
carries only one RTP packet.
Figure 8-7 shows the format of a RTP packet.
Figure 8-7 RTP packet format
The fields are described as follows:

z V: 2 bits, version number.
z P: 1 bit, padding flag.
z X: 1 bit, packet header extension flag.
z CC: 4 bits, contributor count.
z M: 1 bit, special event flag.
z PT: 7 bit, payload type flag.
z Sequence Number: 16 bits, data packet sequence number.
z Time Stamp: 32 bits, time stamp.
z SSRC: 32 bits, synchronization source flag.
z CSRC list; 32 bits, contributing source flag list. The number of contributing source flags depends on
the value of the CC field. The CSRC list field can contain up to 15 contributing source flags.
z Payload: packet payload.
RTCP Packet Overview
A Real-time Transport Control Protocol (RTCP) packet is encapsulated in a UDP packet. Usually a UDP
packet carries at least two RTP packets, and such a UDP packet is called a compound RTCP packet.
Figure 8-8 shows the format of a RTCP packet.

Figure 8-8 Compound RTCP packet format
SSRC
SSRC
SSRC
SSRC
SSRC
SSRC
SSRC
As shown in the above figure, the random 32-bit prefix in the header exists only when the RTCP packet
is encrypted. An encrypted RTCP packet no longer has the features of an RTCP packet and therefore
requires no special processing. Each packet in the figure represents an RTCP packet, and there is no
space between two RTCP packets. The type of the first RTCP packet in a compound RTCP packet must
be SR or RR. Figure 8-9 shows the header format of an SR-type RTCP packet.
Figure 8-9 Header format of an SR-type RTCP packet
The fields are described as follows:

z V: 2 bits, version number.
z P: 1 bits, padding flag.
z RC: 5 bits, the number of receiving report blocks in the RTCP packet.
z PT: 8 bits, RTCP packet type flag. This field is 200 for SR-type RTCP packets.
z Length: 16 bits, length of the RTCP packet.
z SSRC of sender: 32 bits, SSRC of the sender.
The structure of the RR-type RTCP packet header is similar to that of the SR-type RTCP packet header,
except that the PT field of the RR type is 201.
Static Protocol Overview
Some protocols using TCP and UDP are identified by TCP or UDP port numbers. See the following
table for their names and the corresponding port numbers.
Table 8-3 Static port protocols
Protocol name Protocol type Port number

BGP TCP/UDP 179
Citrix TCP 1494

Citrix UDP 1604
CU-SeeMe TCP 7648, 7649
CU-SeeMe UDP 7648, 7649,24032


DHCP/BOOTP UDP 67, 68
DNS TCP/UDP 53
eDonkey TCP 4662
Exchange TCP 135

Fasttrack TCP 1214
Finger TCP 79
Gnutella TCP 6346,6347,6348,6349,6355,5634

Gopher TCP/UDP 70
H323 TCP 1300,1718,1719,1720,11000 to 11999
H323 UDP 1300 ,1718 ,1719 ,1720 ,11720

IMAP TCP/UDP 143, 220
IRC TCP/UDP 194
Kerberos TCP/UDP 88, 749

L2TP UDP 1701
LDAP TCP/UDP 389
Mgcp TCP 2427, 2428, 2727
Mgcp UDP 2427, 2727
6699, 8875, 8888, 7777, 6700, 6666,
Napster TCP
6677, 6688, 4444, 5555
NetBIOS TCP 137, 138, 139
NetBIOS UDP 137, 138, 139
Netshow TCP 1755
NFS TCP/UDP 2049
NNTP TCP/UDP 119
Notes TCP/UDP 1352
Novadign TCP/UDP 3460,3461,3462,3463,3464,3465
NTP TCP/UDP 123
PCAnywhere TCP 5631, 65301
PCAnywhere UDP 22, 5632
POP3 TCP/UDP 110
Pptp TCP 1723
Printer TCP/UDP 515
Rcmd TCP 512 ,513 ,514

RIP UDP 520
RSVP UDP 1698, 1699

RTSP TCP 554
Secure-FTP TCP 990
Secure-HTTP TCP 443
Secure-IMAP TCP/ UDP 585, 993

Secure-IRC TCP/ UDP 994
Secure-LDAP TCP/ UDP 636
Secure-NNTP TCP/ UDP 563

Secure-POP3 TCP/ UDP 995
Secure-TELNET TCP 992
SIP TCP/ UDP 5060

Skinny TCP 2000, 2001, 2002
SMTP TCP 25
SNMP TCP/UDP 161, 162

SOCKS TCP 1080
Sqlnet TCP 1521
Sqlserver TCP 1433
SSH TCP 22
Streamwork UDP 1558
Sunrpc TCP/UDP 111
Syslog UDP 514
Telnet TCP 23
Tftp UDP 69
Vdolive TCP 7000
Winmx TCP 6699
X Windows TCP 6000, 6001, 6002, 6003
Configuring DAR
A device that supports DAR is required.
Configuring Protocol Match Criteria
To apply various policies (e.g. setting packet priority, allocating bandwidth for data streams) to
corresponding data streams, you need to use DAR to classify the data streams first.
Follow these steps to configure protocol match criteria:

traffic classifier tcl-name
Enter class view Required
[ operator { and | or } ]
Optional
if-match [ not ] protocol http DAR can classify HTTP
Configure the match criterion [ url url-string | host packets by the URL address,
for HTTP hostname-string | mime host name, or MIME type in
mime-type ] HTTP packets.
Not configured by default.
Optional
if-match [ not ] protocol rtp DAR can classify RTP packets
Configure the match criterion
[ payload-type { audio | video by the payload type in RTP
for RTP
| payload-string&<1-16> }* ] packets.
Not configured by default.
Configure the match criterion if-match [ not ] protocol Optional

for a protocol protocol-name Not configured by default.
if-match [ not ] Optional
Configure the match criterion
protocol-group
for a protocol group Not configured by default.
protocol-group-id
Configuring Port Numbers for DAR Application Protocols
The system pre-defines large numbers of protocols and their port numbers. The protocols include
known protocols and 10 user-defined protocols, namely user-defined01, user-defined02, …,
user-defined10. You can define port numbers for these protocols to enhance scalability of DAR.
Follow these steps to configure port numbers for DAR application protocols:

Optional
dar protocol protocol-name { tcp | By default, known protocols
Configure port numbers for
udp } port { port-value&<1-16> | have default port numbers, but
DAR application protocols
range port-min port-max } * the 10 user-defined protocols
have no port numbers.
Renaming User-defined Protocols
By default, the names of the ten user-defined protocols are user-defined01, user-defined02,…,
user-defined10. You can rename them following these steps to facilitate memorizing and
management.
Follow these steps to rename user-defined protocols:


Rename a user-defined dar protocol-rename
Optional
protocol old-name user-defined-name
Configuring DAR Packet Accounting
With the packet accounting function of DAR, you can monitor the number of packets, the amount of data
traffic, the historical average traffic rate, and the historical maximum traffic rate of application protocols
on each interface. According to the statistics, you can apply corresponding policies for the traffic.
Follow these steps to configure DAR packets accounting:

dar protocol-statistic [ flow-interval Required

Enable DAR packet accounting
time ] Disabled by default
Configuring the Maximum Number of Recognizable Connections
When a large amount of data traffic passes a device, if DAR recognizes all the traffic, tremendous
system resources are occupied, and the normal operation of other functional modules is affected. To
solve this problem, you can limit the maximum number of connections that DAR can recognize, thus
saving the system resources. When the connection number exceeds the maximum threshold, DAR will
not recognize the corresponding packets and directly mark them as unrecognizable.
Follow these steps to configure the maximum number of connections recognizable to DAR:

Optional
Configure the maximum number dar max-session-count
of recognizable connections count The default maximum number
varies by device.
Displaying and Maintaining DAR

Display information about the
display dar information Available in any view
DAR module
Display DAR protocol display dar protocol { all |

information protocol-name }


Display information about
renamed user-defined display dar protocol-rename Available in any view
protocols
display dar protocol-statistic [ protocol
Display DAR protocol packet protocol-name | top top-number | all ]
statistics [ interface interface-type
interface-number ] [ direction { in | out } ]
reset dar protocol-statistic

Clear DAR protocol packet
{ { { protocol protocol-name } | interface Available in user view
statistics
interface-type interface-number } * | all }
Clear the cache information of
reset dar session Available in user view
all the sessions
DAR Configuration Examples

BT Downloading Prohibition Configuration Example
As shown in Figure 8-10, a router provides access to the BT seed server for the PCs on a network
attached to it.
Make configuration on the router to prohibit PCs from downloading files from the BT seed server.
Figure 8-10 Network diagram for BT downloading prohibition configuration
# Configure the classifier classsample for matching BT packets.

<Router> system-view
[Router] traffic classifier bt
[Router-classifier-bt] if-match protocol bittorrent
[Router-classifier-bt] quit
# Configure a packet filtering behavior.

[Router] traffic behavior deny
[Router-behavior-deny] filter deny
[Router-behavior-deny] quit
# Configure a QoS policy to match and filter BT packets.

[Router] qos policy bt
[Router-qospolicy-bt] classifier bt behavior deny
[Router-qospolicy-bt] quit
# Apply the QoS policy in the inbound direction of Ethernet 1/1.

[Router] interface ethernet1/1
[Router-Ethernet1/1] qos apply policy bt inbound
Run BT seed software on the BT seed server, and run BT client software on PC to start BT downloading.
Check BT client software and you can see that PC cannot perform BT downloading.
HTTP URL-Based DAR Configuration Example
As shown in Figure 8-11, a router provides access to the Web server for the clients on a network
attached to it.
Make configurations on Router to prohibit Client from accessing the webpage
http://www.abcd.com:8080/news/index.html on Web server.
Figure 8-11 Network diagram for HTTP URL-based DAR configuration
# Configure the HTTP URL as the match criterion.

[Router] traffic classifier httpurl
[Router-classifier-httpurl] if-match protocol http url /news/index.html
[Router-classifier-httpurl] quit

# Configure a QoS policy.

[Router] qos policy httpurl
[Router-qospolicy-httpurl] classifier httpurl behavior deny
[Router-qospolicy-httpurl] quit

[Router] interface ethernet 1/1
[Router-Ethernet1/1] qos apply policy httpurl inbound
After the configurations above, Client cannot access the webpage


z When the HTTP URL is configured as the match criterion, url-string only matches the URL fields in
request packets. For example, url-string just matches /news/index.html of the webpage
http://www.abcd.com:8080/news/index.html.
z As url-string matches the fields in request packets, to have the QoS policy take effect, you should
apply the QoS policy to a direction with HTTP URL request packets.
HTTP Host-Based DAR Configuration Example
As shown in Figure 8-12, a router provides access to the Web server for the clients on a network
attached to it.
Make configurations on Router to prohibit Client from accessing the webpage
Figure 8-12 Network diagram for HTTP host-based DAR configuration
# Configure the HTTP Host as the match criterion.

[Router] traffic classifier httphost
[Router-classifier-httphost] if-match protocol http host www.abcd.com:8080
[Router-classifier-httphost] quit

# Configure a QoS policy.

[Router] qos policy httphost
[Router-qospolicy-httphost] classifier httphost behavior deny
[Router-qospolicy-httphost] quit

[Router] interface ethernet 1/1
[Router-Ethernet1/1] qos apply policy httphost inbound

After the configurations above, Client cannot access the webpage

z When the HTTP host is configured as a match criterion, hostname-string only matches the host
names and port numbers in request packets. For example, hostname-string just matches
www.abcd.com:8080 of the webpage http://www.abcd.com:8080/news/index.html.
z As hostname-string matches the fields in request packets, to have the QoS policy take effect, you
should apply the QoS policy to a direction with HTTP Host request packets.


01 QoS Configuration

Uploaded by

Copyright:

Available Formats

You might also like

01 QoS Configuration

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

01 QoS Configuration

Uploaded by

Copyright:

Available Formats

QoS Configuration QoS Volume

Operation Manual Table of Contents

1 QoS Overview ............................................................................................................................................1-1

2 Traffic Classification, Traffic Policing and Traffic Shaping Configuration..........................................2-1

3 QoS Policy Configuration .........................................................................................................................3-1

4 Congestion Management Configuration .................................................................................................4-1

5 Priority Mapping Configuration................................................................................................................5-1

ii Huawei Proprietary and Confidential

7 MPLS QoS Configuration..........................................................................................................................7-1

8 DAR Configuration ....................................................................................................................................8-1

Huawei Proprietary and Confidential iii

HTTP URL-Based DAR Configuration Example ...........................................................................8-12

iv Huawei Proprietary and Confidential

This chapter covers the following topics:

Traditional Packet Forwarding Services

New Requirements from Emerging Applications

Huawei Proprietary and Confidential 1-1

Congestion: Causes, Impacts, and Countermeasures

100M 10M 100M 100M

Congestion may bring these negative results:

1-2 Huawei Proprietary and Confidential

Major Traffic Management Technologies

Huawei Proprietary and Confidential 1-3

1-4 Huawei Proprietary and Confidential

2 Traffic Classification, Traffic Policing and Traffic

Traffic Classification Overview

The following part introduces some precedence types.

Huawei Proprietary and Confidential 2-1

Figure 2-1 DS field and ToS bytes

Traffic Policing and Traffic Shaping Overview

Traffic Evaluation and Token Bucket

2-2 Huawei Proprietary and Confidential

Figure 2-2 Evaluate traffic with the token bucket

Evaluating traffic with the token bucket

Tokens are put into the

2-4 Huawei Proprietary and Confidential

Figure 2-4 GTS application

TP, GTS and Line Rate Configuration

Configuring GTS for all traffic Configure GTS on interfaces

Configuring the Line Rate Configure line rate

Configuring Traffic Policing

Configuring CAR-list-based traffic policing

Follow these steps to configure CAR-list-based traffic policing:

To do… Use the command… Remarks

Enter system view system-view —

Enter Enter Use either command

2-6 Huawei Proprietary and Confidential

To do… Use the command… Remarks

qos car { inbound | outbound } carl

Configuring ACL-based traffic policing

Follow these steps to configure ACL-based TP:

To do… Use the command… Remarks

Configure an ACL Refer to the ACL module Required

qos car { inbound | outbound } acl

Display CAR policy Optional

Configuring traffic policing for all traffic

Follow these steps to configure traffic policing for all traffic:

To do… Use the command… Remarks

Huawei Proprietary and Confidential 2-7