SJ-20130205142913-017-ZXR10 M6000 (V1.00.60) Carrier-Class Router Configuration Guide (QoS)

ZXR10 M6000
Carrier-Class Router
Configuration Guide (QoS)
Version: 1.00.60
ZTE CORPORATION
NO. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://ensupport.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright © 2013 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by
contractual confidentiality obligations.
All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided “as is”, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit ZTE technical support website http://ensupport.zte.com.cn to inquire related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No. Revision Date Revision Reason
R2.2 2012-02-28 Fourth edition
R2.0 2012-07-20 Third edition
R1.1 2012-03-30 Second edition
R1.0 2011-12-10 First edition
Serial Number: SJ-20130205142913-017
Publishing Date: 2013-02-28 (R2.2)
SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Contents
About This Manual ......................................................................................... I
Chapter 1 QoS Overview............................................................................ 1-1
Chapter 2 CAR Configuration.................................................................... 2-1
2.1 CAR Overview ................................................................................................... 2-1
2.2 TrTCM Overview ................................................................................................ 2-3
2.3 Configuring CAR ................................................................................................ 2-4
2.4 Maintaining CAR ................................................................................................ 2-6
2.5 CAR Configuration Example ............................................................................... 2-7
Chapter 3 Flow Classification Configuration........................................... 3-1

3.1 Flow Classification Overview............................................................................... 3-1
3.2 Configuring Flow Classification............................................................................ 3-2
3.3 Maintaining Flow Classification............................................................................ 3-3
3.4 Flow Classification Configuration Instances.......................................................... 3-4
3.4.1 Configuring Null-Rule Flow Classification ................................................... 3-4
3.4.2 Configuring Port-Based Flow Classification ................................................ 3-5
3.4.3 Configuring EXP-Based Flow Classification ............................................... 3-6
3.4.4 Configuring MAC Address-Based Flow Classification.................................. 3-8
3.4.5 Configuring IPv4 ACL-Based Flow Classification ........................................ 3-9
3.4.6 Classifying Flows in the Match-Any Mode ................................................ 3-10
Chapter 4 Flow Action Configuration ....................................................... 4-1

4.1 Flow Action Overview ......................................................................................... 4-1
4.2 Configuring Flow Actions .................................................................................. 4-10
4.3 Maintaining Flow Action .................................................................................... 4-13
4.4 Flow Action Configuration Instances .................................................................. 4-13
4.4.1 Configuring Packet Marking (Set) ............................................................ 4-13
4.4.2 Configuring Traffic Supervision (Police Rate Limit).................................... 4-15
4.4.3 Configuring PQ (Priority-Level)................................................................ 4-16
4.4.4 Configuring WFQ Scheduling .................................................................. 4-18
4.4.5 Configuring CBWFQ (LLQ + WFQ).......................................................... 4-20
4.4.6 Configuring VLAN-ID-Based Scheduling (Match Interface) ........................ 4-22
4.4.7 Configuring WRED ................................................................................. 4-23
4.4.8 Configuring H-QoS (L1 CBWFQ + L2 Police) ........................................... 4-24
Chapter 5 H-QoS Configuration ................................................................ 5-1

5.1 H-QoS Overview ................................................................................................ 5-1
5.2 Configuring H-QoS ............................................................................................. 5-1
5.3 Maintaining H-QoS ............................................................................................. 5-2
5.4 H-QoS Configuration Instances ........................................................................... 5-3
5.4.1 Priority Scheduling Configuration Example................................................. 5-3
5.4.2 WRED Configuration Example .................................................................. 5-6
Chapter 6 Priority Inheritance Configuration........................................... 6-1

6.1 Priority Inheritance Overview............................................................................... 6-1
6.2 Configuring Priority Inheritance ........................................................................... 6-2
6.3 Maintaining Priority Inheritance ........................................................................... 6-3
6.4 Priority Inheritance Configuration Instances ......................................................... 6-3
6.4.1 802.1P Inheritance Configuration Example ................................................ 6-3
6.4.2 Pipe Mode Configuration Example............................................................. 6-5
Chapter 7 QPPB Configuration ................................................................. 7-1

7.1 QPPB Overview ................................................................................................. 7-1
7.2 Configuring QPPB .............................................................................................. 7-2
7.3 Maintaining QPPB .............................................................................................. 7-2
7.4 QPPB Configuration Example ............................................................................. 7-3
Figures............................................................................................................. I
Tables ............................................................................................................ III
Glossary .........................................................................................................V
II

About This Manual
Purpose
This manual describes the principle, configuration commands, maintenance commands,
and configuration examples about QoS function of the ZXR10 M6000.
Intended Audience
This manual is intended for:
l Network planning engineers
l Commissioning engineers
l On-duty personnel
What Is in This Manual

This manual contains the following chapters:
Chapter Summary
1, QoS Overview Describes an overview of QoS, differences between integrated

service and differentiated service, principle of QoS tool, queue policy
and drop policy.
2, CAR Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the CAR.
3, Flow Classification Describes the Flow Classification principle, configuration commands,

Configuration maintenance commands, and configuration examples.
4, Flow Action Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the flow action.
5, H-QoS Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the H-QoS.
6, Priority Inheritance Describes the principle, configuration commands, maintenance

Configuration commands, and configuration examples of the priority inheritance.
7, QPPB Configuration Describes the principle, configuration commands, maintenance

commands, and configuration examples of the QPPB.
Conventions
This manual uses the following typographical conventions:
Typeface Meaning
Italics Variables in commands. It may also refers to other related manuals and documents.

Typeface Meaning
Bold Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters and commands.
Constant Text that you type, program codes, filenames, directory names, function names.
width
[] Optional parameters.
{} Mandatory parameters.
| Separates individual parameter in series of parameters.
Danger: indicates an imminently hazardous situation. Failure to comply can result in

death or serious injury, equipment damage, or site breakdown.
Warning: indicates a potentially hazardous situation. Failure to comply can result in

serious injury, equipment damage, or interruption of major services.
Caution: indicates a potentially hazardous situation. Failure to comply can result in

moderate injury, equipment damage, or interruption of minor services.
Note: provides additional information about a certain topic.
II

Chapter 1
QoS Overview
QoS Introduction
In traditional Internet Protocol (IP) networks, all packets are treated without any difference.
Routers use the First In First Out (FIFO) policy to process these packets. Routers transmit
packets to destinations with the best-effort principle. However, routers cannot guarantee
the performance such as transmission reliability and delay.
With the development of new applications in IP networks, there are new requirements for
Quality of Service (QoS). The best-effort principle in traditional IP networks cannot meet
the requirements of applications. For VoIP services for example, long delays in packets
transmission are not tolerated. A feasible method to solve this problem is to provide the
Quality of Service (QoS) ability for the Internet.
QoS is used to provide different service qualities (such as providing special bandwidth,
reducing the packet loss rate, and reducing delay and delay jitter) in accordance with
different requirements of applications. To achieve this purpose, QoS provides the following
functions:
l Packet classification
l Packet marking
l Traffic supervision and shaping
l Congestion avoidance
l Congestion management
Integrated Service and Differentiated Service

To implement QoS in IP networks, it is necessary to provide better and more predictable
network services through the configurations of characteristics, such as allocating
bandwidth, reducing packet loss rate, avoiding and managing congestion, measuring
network traffic, and setting the priority for cross-network service flows.
QoS provides a series of measures for service guarantee at the best-effort IP layer. There
are two QoS models:
l Integrated Service (IntServ)
l Differentiated Service (DiffServ)
l The IntServ model can meet different QoS requirements. This model requests
specific resources before packets are sent. The request is sent through a signal.
An application advertises its traffic parameters and specific service quality request
(including bandwidth, and delay) to the network. The application sends packets after
receiving the confirmation message, that is, confirming that the network has reserved
resources for this application. At the same time, the packets sent by the application
are controlled within the description range of traffic parameters.
1-1

ZXR10 M6000 Configuration Guide (QoS)
This model can meet the QoS requirement. However, because the network needs to
maintain a QoS record for each flow, the network extension may be affected, and this
model is not widely used in practical applications.
l Different from the IntServ model, the DiffServ model does not need a signal. That
is, before packets are sent, an application program does not need to notify routers.
The network does not need to maintain the QoS record for each flow. This module
provides specific services in accordance with the QoS designated in each packet.
Users can use different methods to designate the QoS of each packet, such as in the
IP precedence, source address, and destination address. The network implements
packet classification, traffic shaping, traffic supervision, and queuing in accordance
with the information.
The DiffServ model can be considered as a compromise of IntServ model and
best-effort mode. The service granularity of the DiffServ model is larger than that of
the IntServ model. Compared with best-effort, the DiffServ model supports the traffic
priority.
The DiffServ model contains the following two complementary parts:
l Traffic classification: Including classification in accordance with Access Control
List (ACL), traffic amount, Type Of Service (ToS) and Network Based Application
Recognition (NBAR).
l Classification management policy: Including the queuing policy, dropping policy, and
shaping policy.
QoS Tool
In general, the QoS tool in router devices includes the classification and marking tool, traffic
supervision and shaping tool, congestion avoidance tool, and congestion management
tool.
l Packet classification: The packet classification tool can classify network service flows
into several priorities or service classes.
For example, in accordance with the Differentiated Services Code Point (DSCP) field
in IP packet headers, packets can be classified into 64 service classes at most. After
the packet classification, different QoS policies, such as congestion management,
traffic supervision and shaping, packet marking and re-marking, can be applied to
different service classes.
Common packet classification basis include physical interface, sub-interface, PVC,

Medium Access Control (MAC) address, 802.1Q/p CoS, Multi Protocol Label
Switching (MPLS) EXP, DSCP, IP precedence (IPP), IP quintuple group, packet
header, and Uniform Resource Locator (URL) in payload.
l Packet marking: The marking tool is normally used to create the trust boundary relied
on by other QoS tools. Users can make different marks for different service classes
in accordance with user policies. A mark of a packet can be the criteria for the next
classification, and the mark also can be carried to other devices by the packet. In
1-2

Chapter 1 QoS Overview
addition, the routers can re-mark packets in accordance with traffic supervision results,
such as packet degradation.
l Traffic supervision and shaping: The traffic supervision is used to check traffic rate in
real time and take corresponding actions when the traffic exceeds the committed rate.
Traffic supervision can fix whether the traffic on the ingress exceeds the committed
rate. It will re-mark or drop the traffic that exceeds the committed rate.
The traffic shaping is a traffic smoothing tool that operates together with the queuing
mechanism. The traffic shaping function is used to ensure that the traffic is smoothly
sent at a specified rate. If the incoming traffic exceeds the designated rate temporarily,
the traffic that exceeds the committed rate will be stored in a buffer and transmitted
with delay.
l Congestion avoidance tool: The congestion avoidance tool is a supplement to the
congestion management tool. The congestion management tool manages the head
of a queue, while the congestion avoidance tool manages the tail of a queue.
Common congestion avoidance tools include Random Early Detection (RED),
Weighted Random Early Detection (WRED) and Explicit Congestion Notification
(ECN).
l Congestion management tool: Among all QoS tools, the congestion management
tool has the most obvious effect on the service quality of application programs.
The congestion management tool is also considered as a queuing tool. When
the congestion occurs in a network, the congestion management determines the
de-queuing policies of different service flows. Common congestion management
tools include Priority Queuing (PQ), Weighted Fair Queuing (WFQ), and Class Based
Weighted Fair Queuing (CBWFQ).
Queuing Policy
The queuing policies consists of the following three types:
l First In First Out (FIFO) Queuing
The FIFO queuing is the simplest queuing and it is the default queuing mode in a
router. All packets to be sent on the interface go to the FIFO queue tail of an interface
in accordance with the sequence they arrive. When a router sends packets, it begins
from the FIFO queue head. During packet transmission, packets are treated without
any difference. There is no guarantee for the packet transmission quality.
l Priority Queuing (PQ)
PQ classifies traffic into four queues, including the high priority queue, the medium
priority queue, the normal priority queue, and the low priority queue. The queues
are handled in accordance with their respective priorities strictly. Packets in the
high priority queue are first sent by using the PQ policy. The packets in the medium
priority queue leave the queue after all the packets in the high priority queue are
sent. Similarly, the packets in the normal priority queue leave the queue after all the
packets in the medium priority queue are sent. At last, the packets in the low priority
queue are sent.
1-3

In this way, the packets in the higher priority queues are sent in preference to other
packets. When congestion occurs in the network, the packets with lower priorities will
be delayed by the packets with higher priorities. As a result, the packets for important
services will always be processed first, and packets for unimportant services will be
processed when the network is idle. In this way, the important services are handled
quickly and network resources are used fully.
l Weighted Fair Queuing (WFQ)
WFQ is a flow-based fair queuing. It is a queuing mode developed to adjust the
advantages of flows with larger packets over the flows with smaller packets. Through
the scheduling policy based on virtual sending clock, WFQ can allocate relatively fair
bandwidths for flows with different sizes of packets.
Dropping Policy
A dropping policy is to determine the dropping mode to drop packets when a queue reaches
the threshold. Common dropping policies include tail drop, RED, and WRED.
Figure 1-1 shows the common QoS flow in router devices.
Figure 1-1 Common QoS Flow in Router Devices
1-4

Chapter 2
CAR Configuration
Table of Contents
CAR Overview............................................................................................................2-1
TrTCM Overview ........................................................................................................2-3
Configuring CAR ........................................................................................................2-4
Maintaining CAR ........................................................................................................2-6
CAR Configuration Example.......................................................................................2-7
2.1 CAR Overview

CAR Introduction
The typical function of traffic supervision is to limit the traffic entering a link of a network
and limit burst on a link.
When packets meet specific conditions, if the packet traffic on a link is too large, the traffic
supervision can take different actions on the packets, such as dropping packets, and
resetting packet priorities. A common method is to use Committed Access Rate (CAR)
to limit the packet traffic of a specific type, for example, limiting the bandwidth used by
HTTP packets within 50%.
For Internet Service Providers (ISPs), it is necessary to control the traffic that enters the
network. For enterprise networks, controlling the traffic for some applications is a helpful
tool to control network operations. Network administrators can use the CAR to control
traffic.
CAR is a type of basic traffic supervision technology. It is composed of traffic classification
and rate limit. The CAR classification can be made on the basis of 802.1P, IP priority,
DSCP, and MPLS-EXP.
Token Bucket
CAR uses Token Bucket (TB) to control traffic, see Figure 2-1.
2-1

Figure 2-1 Traffic Control Through CAR
1. A device classifies packets in accordance with the predefined matching rules. For
the packets with defined traffic characteristics, the device will send them directly
without the processing of the token bucket. For the packets with no defined traffic
characteristics, they will be sent to the token bucket for processing.
2. If there are enough tokens to send the packets, the packets are allowed to pass and
then be sent. If there are not enough tokens in the token bucket to send the packets,
the packets will be dropped. In this way, packet traffic of a specific class can be
controlled.
3. Tokens can be put to the bucket in accordance with the rate set by users. Users also
can set the capacity of the token bucket. When the amount of tokens is equal to the
capacity, the amount will not increase.
4. When a packet is handled by the token bucket, if there are enough tokens in the bucket,
the packet will be allowed to pass and the appropriate amount of tokens in the bucket
will be removed in accordance with the length of the packet. When there are not
enough tokens, the packet will be dropped.
The token bucket is a good tool to control the data flow.
l When the bucket is full of tokens, all the packets represented by tokens can be
transmitted. This allows the burst transmission of data.
l When there is no token in the bucket, packets will not be sent until enough new
tokens are generated in the bucket. Therefore, the rate of packet traffic should
not be larger than the rate to generate tokens, which achieves traffic limit.
In practical applications, CAR not only can be used to control traffic, but also can be used
to mark or re-mark packets. That is, CAR can be used to set or modify the priorities of IP
packets, which achieves marking packets.
For example, when packets meet the traffic characteristics, set the priorities of the packets
to 5. When the packets do not meet the traffic characteristics, drop the packets, or set the
priorities to 1 and then send them. In this way, the device ensures not to drop packets
with priority 5 in the following processing if possible. When there is no congestion on the
2-2

Chapter 2 CAR Configuration
network, the packets with priority 1 are also sent. When congestion occurs, the packets
with priority 1 are dropped first, and then the packets with priority 5 may be dropped.
2.2 TrTCM Overview

TrTCM Introduction
Two-rate Three Color Marker (TrTCM) classifies IP packet flows based on the Peak
Information Rate (PIR), Committed Information Rate (CIR), and their related burst sizes.
TrTCM marks these packets in green, yellow, or red. If the rate of a packet exceeds the
PIR, it is marked in red. Otherwise, the packet is marked in yellow or green in accordance
with the fact that whether the packet exceeds the CIR.
The classification operates in the following two modes:
l Color-blind mode: In this mode, all packets are assumed to be uncolored.
l Color-aware mode: In this mode, all packets are assumed to be colored.
IP packets are colored in accordance with the classification results.
TrTCM Configuration
The configuration of the TrTCM is implemented by setting its mode and assigning values
for the four traffic parameters. The parameters are:
l Peak Information Rate (PIR)
l Peak Burst Size (PBS)
l Committed Information Rate (CIR)
l Committed Burst Size (CBS)
The unit of PIR and CIR is Kbit/s, and the unit of PBS and CBS is Kbytes.
The PIR and CIR are measured in bytes of IP packets per second. The value of PIR must
not be less than the value of CIR.
The PBS and CBS are measured in bytes of IP packets. Their values must be more than 0
and must not be less than the maximum bytes of IP packets that may pass every second.
TrTCM Classification
Two buckets are needed to complete the classification: Bucket P and bucket C. The filling
rate of bucket P is PIR, and the filling rate of bucket C is CIR. The two rates are independent
of each other. The largest size of bucket P is PBS, and the largest size of bucket C is CBS.
In initialization, the two buckets are full of tokens, Tp (0) = PBS, and Tc (0) = CBS. Then
the number of the tokens in bucket P (that is, Tp) increases by PIR every second, and the
upper limit is PBS. The number of the tokens in bucket C (that is, Tc) increases by CIR
every second, and the upper limit is CBS.
l In the color-blind mode, when a packet of size B bytes arrives at the time t, it is
processed in the following way:
1. If Tp (t) - B < 0, the packet is colored in red.
2-3

2. If Tc (t) - B < 0, the packet is colored in yellow, and Tp is reduced by B.

3. Otherwise, the packet is colored in green, and both Tp and Tc are reduced by B.
l In the non-color-blind mode, when a packet of size B bytes arrives at the time t, it is
processed in the following way:
1. If the packet is colored in red, or if Tp (t) - B < 0, it is colored in red.
2. If the packet is colored in yellow, or if Tc (t) - B < 0, it is colored in yellow, and Tp
is reduced by B.
3. If the packet is colored in green, both Tp and Tc are reduced by B.
TrTCM Mark
TrTCM marks reflect the results of classification. It is implemented by setting the DS fields
in packets.
2.3 Configuring CAR

To configure CAR on the ZXR10 M6000, perform the following steps:
Step Command Function
1 ZXR10(config)#qos Enters QoS configuration mode.
2 ZXR10(config-qos)#interface <interface-name> Enters QoS interface configuration

mode.
3 ZXR10(config-qos-if)#rate-limit {input | output}{unicast | broadcast Applies CAR on an interface and

| unknown | ipv4-access-list <acl-name>| ipv6-access-list sets traffic supervision on input
<acl-name>| localport | dscp <dscp-value>| mpls-exp <mpls-exp-value>| interface or output interface (the
precedence <prec-value>| inner-802.1p <in802.1p-value>[outer-802.1p IP type is not specified).
<out802.1p-value>]| outer-802.1p <out802.1p-value> - [inner-802.1p
<in802.1p-value>]| inner-vlan <inVlan-value>[outer-vlan
<outVlan-value>]| outer-vlan <outVlan-value>[inner-vlan
<inVlan-value>]} cir <cir-value> cbs <cbs-value> pir <pir-value>
pbs <pbs-value> conform-action <action> exceed-action <action>
violate-action <action>[statistical-share]
ZXR10(config-qos-if)#rate-limit {input | output}{ipv4 | ipv6}{dscp Applies CAR on an interface and

<dscp-value>| precedence <prec-value>} cir <cir-value> cbs sets traffic supervision on input
<cbs-value> pir <pir-value> pbs <pbs-value> conform-action <action> interface or output interface (the
exceed-action <action> violate-action <action>[statistical-share] IP type is specified).
Parameter descriptions are as follows:
Parameter Description
input | output Input/Output interface.
ipv4 | ipv6 On the basic of IPv4 or IPv6.
loaclport Local port.
2-4

broadcast L2 VPN broadcast traffic.
unicast L2 VPN unicast traffic.
unknown L2 VPN unknown traffic.
cir <cir-value> CIR value.

Range: 66 Kbit/s to 16777215 Kbit/s.
cbs <cbs-value> CBS value.

Range: 15000 Kbytes to 2000000000 Kbytes.
pir <pir-value> PIR value.

Range: 66 Kbit/s to 16777215 Kbit/s.
pbs <pbs-value> PBS value.

Range: 15000 Kbytes to 2000000000 Kbytes.
dscp <dscp-value> DSCP value.

Range: 0 to 63.
mpls-exp <mpls-exp-value> MPLS-EXP value.

Range: 0-7.
precedence <prec-value> IP priority.

Range: 0-7.
outer-8021p <outer-802.1p-value> Outer-8021p value.

Range: 0-7.
inner-8021p <inner-802.1p-value> Inner-8021p value.

Range: 0-7.
outer-vlan <outer-vlan-value> Outer-vlan value.

Range: 1-4094.
inner-vlan <inner-vlan-value> Inner-vlan value.

Range: 1-4094.
conform-action <action> Use one of the following keyword to take action on packets matching
the designated rate:
l drop: To drop packets.
l transmit: To transmit packets.
l set-dscp-transmit: To set the DSCP value (0-63) and transmit
packets.
l set-prec-transmit: To set the IP priority (0-7) and transmit packets.
l set-exp-transmit: To set the MPLS priority value (0-7) and
transmit packets.
l set-8021p-transmit: To set the 802.1P priority (0-7) and transmit
packets.
2-5

exceed-action <action> Use one of the following keyword to take action on packets matching
l drop: dropping packets.
packets.
transmit packets.
packets.
violate-action <action> Use one of the following keywords to take action on packets matching
l drop: To drop packets.
packets.
transmit packets.
packets.
statistical-share Flow division mark.
2.4 Maintaining CAR

To maintain CAR on the ZXR10 M6000, run the following command:
Command Function
ZXR10#show running-config carset Displays the CAR configuration on interfaces.
The following is a sample output from the show running-config carset command:
ZXR10(config)#show running-config carset
!<QOS_CAR>
qos
interface gei-0/1/1/1
rate-limit output precedence 1 cir 100000 cbs 200000
pir 150000 pbs 300000 conform-action set-prec-transmit 7
exceed-action set-prec-transmit 7 violate-action drop
rate-limit output precedence 2 cir 100000 cbs 200000
pir 150000 pbs 300000 conform-action set-prec-transmit 7
2-6

exceed-action set-prec-transmit 7 violate-action drop

$
!</QOS_CAR>
The following is a sample output from the show running-config-interface command:

ZXR10(config)#show running-config-interface gei-0/0/1/4
!<QOS_CAR>
qos
rate-limit input localport cir 10000 cbs 15000 pir 15000 pbs 15000
conform-action transmit exceed-action drop violate-action drop
$
!</QOS_CAR>
!<INTERFACE>
no shutdown
ip address 125.1.1.1 255.255.255.0
!</INTERFACE>
Command Output Description
rate-limit Rate limit policy.
Output Input/Output.
precedence IP priority. Range:-7.
conform-action set-prec-transmit 7 Actions on packets matching the designated rate: set IP priority to 7
and transmit packets.
exceed-action set-prec-transmit 7 Actions on packets matching the designated rate: set IP priority to 7
and transmit packets.
violate-action drop Action on packets matching the designated rate: drop packets.
2.5 CAR Configuration Example

Configuration Description
User1 connects to the network through gei-0/1/0/1, and user2 connects to the network
through gei-0/1/0/2. The precedence of user1 is 1, and the precedence of user2 is 2.
Packets of user1 and user2 leave the device through gei-0/1/0/3. It is required that the
precedence of packets that leave the device through gei-0/1/0/3 is 7, the guaranteed
bandwidth is 100Mbps, and the maximum bandwidth is 150 Mbps, see Figure 2-2.
2-7

Figure 2-2 CAR Configuration Example
Configuration Flow
1. Configure two CARs on gei-0/3.
2. Set the precedence of user1 to 1 and that of user2 to 2.
3. Set the precedence of packets that pass gei-0/3 to 7.
Configuration Command
1. Run the following commands to enter CAR configuration mode:
ZXR10(config)#qos
ZXR10(config-qos)#
2. Run the following commands to enter interface configuration mode:
ZXR10(config-qos)#interface gei-0/1/0/3
ZXR10(config-qos-if)#
3. Run the following commands to configure CARs:
ZXR10(config-qos-if)#rate-limit output precedence 1 cir 100000 cbs 20000000
pir 150000 pbs 30000000 conform-action set-prec-transmit 7 exceed-action
set-prec-transmit 7 violate-action drop
ZXR10(config-qos-if)#rate-limit output precedence 2 cir 100000 cbs 20000000 pir
150000 pbs 30000000 conform-action set-prec-transmit 7 exceed-action
set-prec-transmit 7 violate-action drop
Configuration Verification
Run the show running-config carset command to check CAR configuration on interfaces,
which is displayed as follows:
ZZXR10(config)#show running-config carset
!<QOS_CAR>
qos
rate-limit output precedence 1 cir 100000 cbs 20000000 pir 150000 pbs 30000000
2-8

conform-action set-prec-transmit 7 exceed-action set-prec-transmit 7

violate-action drop
rate-limit output precedence 2 cir 100000 cbs 20000000 pir 150000 pbs 30000000
conform-action set-prec-transmit 7 exceed-action set-prec-transmit 7
violate-action drop
$
!</QOS_CAR>
2-9

This page intentionally left blank.
2-10

Chapter 3
Flow Classification
Configuration
Table of Contents
Flow Classification Overview ......................................................................................3-1
Configuring Flow Classification...................................................................................3-2
Maintaining Flow Classification...................................................................................3-3
Flow Classification Configuration Instances................................................................3-4
3.1 Flow Classification Overview

Services are packet flows on networks. Before end-to-end QoS of services are provided,
it is necessary to classify and mark (or color) the packet flows entering the network, thus
ensuring that special packets can be treated and processed differently.
Flow classification is implemented in accordance with the values in specified fields.
Internet Engineering Task Force (IETF) defines the IPv4 ToS field and IPv6 traffic class,
see Figure 3-1.
Figure 3-1 ToS Field and IPv6 Traffic Class
The class of packets is marked by the DSCP field in IP packet headers, see Figure 3-2.
Figure 3-2 Class of Packets by Using DSCP
Packet classification is used to classify packets into several service classes. The DSCP
field of an IP header consists of 6 bits, so at most 64 service classes are supported
in theory. After packets are classified, QoS can be used to customize proper policies
to handle the flows, for example, accomplishing congestion management, bandwidth
allocation, and delay limit for flows of a specified level.
An MPLS packet uses the Exp field in an MPLS shim, see Figure 3-3.
3-1

Figure 3-3 Exp Field in an MPLS Shim
The Exp field consists of 3 bits, so 8 different QoS priorities are supported. A Label Edge
Router (LER) in the MPLS domain sets the value of the Exp field in a packet after flow
classification. The packet is then treated differently in accordance with the value when
Label Switch Routers (LSRs) in the MPLS domain forwards labels.
Packet classification in accordance with classification policies should be implemented on
the basis of network structures and service requirements. The classification policies at
the network edge are flexible. The packets can be classified in accordance with layer-3
features of packets. A packet flow may be determined by a quintuple (source address,
source port number, protocol number, destination address, and destination port number).
A packet flow may also consist of all packets in a specified network segment.
After classification, it is necessary to set the value of the DSCP field in the IP header or the
value of the Exp field in the MPLS shim. This type of setting is called re-mark. For details,
refer to Chapter 4 in this document.
After the re-mark operation, the value of the DSCP field or the Exp field is used as the
basis of classification in the next processing. The next processing (or forwarding) node
can accept the classification result of the previous hop processing (or forwarding) node,
or classify and mark the packets again in accordance with its own classification policies.
3.2 Configuring Flow Classification

To configure flow classification on the ZXR10 M6000, perform the following stepss:
1 ZXR10(config)#class-map<class-map-name>match-al Creates a class-map and enters class mapping

l[ipv4|ipv6] configuration mode.
2 ZXR10(config-cmap)#match dscp <dscp-value>[,<dscp Configures the data flow in accordance with the IP
-min>–<dscp-max>] DSCP value.
ZXR10(config-cmap)#match precedence Configures the data flow in accordance with the IP

<precedence>[,<precedence-min>–<precedence-max>] precedence value.
ZXR10(config-cmap)#match mpls-exp <mpls-exp-value Configures the data flow in accordance with the
>[,<mpls-exp-min>–<mpls-exp -max>] EXP field in MPLS label packets.
ZXR10(config-cmap)#match in-vlan <invlan-value>[,<i Configures the data flow in accordance with the
nvlan-min>–<invlan-max>] inner VLAN-ID.
ZXR10(config-cmap)#match out-vlan <exvlan-value Configures the data flow in accordance with the
>[,<exvlan-min>–<exvlan-max>] outer layer VLAN-ID.
3-2

Chapter 3 Flow Classification Configuration
ZXR10(config-cmap)#match in-8021p<in8021p-value Configures the data flow in accordance with the

>[,<in8021p-min>–<in8021p-max>] inner 802.1p.
ZXR10(config-cmap)#match out-8021p<ex8021p-value Configures the data flow in accordance with the

>[,<ex8021p-min>–<ex8021p-max>] outer 802.1p.
ZXR10(config-cmap)#match qos-group< qos-id> Configures the data flow in accordance with the
QoS ID.
ZXR10(config-cmap)#match vrf-name<vrf-name> Configures the data flow in accordance with the

VRF name.
ZXR10(config-cmap)#match uni-cast Configures the data flow in accordance with the

unicast rule.
ZXR10(config-cmap)#match multi-cast Configures the data flow in accordance with the

multicast rule.
ZXR10(config-cmap)#match mac-address Configures the data flow in accordance with the

<mac-address> MAC address.
ZXR10(config-cmap)#match ipv4-access-list<acl4-n Configures the data flow in accordance with the

ame> IPv4 access list.
ZXR10(config-cmap)#match ipv6-access-list Configures the data flow in accordance with the

<acl6-name> IPv6 access list.
ZXR10(config-cmap)#match interface [untag]<inter Configures a data flow in accordance with the

face-name> interface name.
ZXR10(config-cmap)#match child Identifies a data flow of that no entry matches.
Caution!
l In “match all” mode, “Match dscp” conflicts with “match precedence”.“Match uni-cast”
conflicts with “match multi-cast”, and “Match interface” and “Match child” conflict with
any other matching rules.
l Before a class map is created, the match mode must be specified.
l The relationship of several “match” entries in the same class-map is “match all”. The
relationship of the “match” values in the same “match” entry is “match any”.
3.3 Maintaining Flow Classification

To maintain flow classification on the ZXR10 M6000, run the following command:
Command Function
ZXR10#show class-map [<class-map-name>] Displays class-maps and configurations of all matching

rules.
3-3

3.4 Flow Classification Configuration Instances

3.4.1 Configuring Null-Rule Flow Classification
1. In class-map configuration, the “match child” rule conflicts with other matching rules.
If the matching rule is “match child”, no other matching rule can be configured. If other
matching rules are configured, the “match child” rule cannot be configured.
2. On the ZXR10 M6000, a class-map is used in a policy-map (policy-map based on flow
classification), that is, the object for which a policy takes effect is a flow of a specified
class. The flow is defined by the class-map. Nested policy-maps can be used. The
“match child” rule has the following differences when a class-map is in different layers.
l If a class-map that classifies packets in accordance with the “match child” rule
is used in a single-layer policy-map, the matching rule of the object (that is, a
class-map) for which the policies in the policy-map take effect is null. All packets
are classified into this class.
l If a class-map that classifies packets in accordance with the “match child” rule
is used in a policy-map in several nested policy-maps, and if the policy-map is
not the home layer, the traffic that can enter this layer can be classified into this
class. The matching traffic at the subordinate hierarchies is not differentiated at
the current layer and the traffic is aggregated to a class-map at this layer.
l In general, the “match child” rule is not used on the home layer in a multi-layer
policy-map.
Configuration Flow
1. Create a class-map, set the name to ipv4-all, set the matching mode to “match all”,
and set the protocol stack to IPv4.
2. Configure a “match” rule for this class-map, and set the classification rule to match
child (in the same class-map, the “match child” rule conflicts with other matching
rules).
Run the following commands on the the ZXR10 M6000:
ZXR10(config)#class-map ipv4-all match-all ipv4
ZXR10(config-cmap)#match child
ZXR10(config-cmap)#exit
Run the show class-map command to view all class-maps on the device, which is displayed
as follows:
ZXR10(config)#show class-map
class-map ipv4-all match-all ipv4
3-4

match child
ZXR10(config)#
Run the show class-map ipv4-all command to view a specified class-map (named ipv4-all),
ZXR10(config)#show class-map ipv4-all
class-map ipv4-all match-all ipv4
match child
ZXR10(config)#
3.4.2 Configuring Port-Based Flow Classification

1. In class-map configuration, the “match interface” rule conflicts with any other matching
rules. If the matching rule is “match interface”, no other matching rule can be
configured. If other matching rules are configured, the “match interface” rule cannot
be configured.
2. As a classification rule, a class-map can only be bound to a physical interface by
configuring the append keyword. This is to differentiate the traffic in accordance with
different interface (sub-interface or physical interface) encapsulation when the traffic
passes the physical link. In this way, queue scheduling will be implemented. For
details, refer to 3.4.1 Configuring Null-Rule Flow Classification.
Configuration Flow
1. Create a class-map, set the name to <interface-name>, and set the matching mode to
“match all”.
2. Configure a “match” rule for this class-map. The classification rule is matching the
<interface-name>.
1. Run the following commands to configure a class-map matching a sub-interface.
ZXR10(config)#class-map gei-0/0/0/8.1 match-all
ZXR10(config-cmap)#match interface gei-0/0/0/8.1
/*Matching interface gei-0/0/0/8.1 means that all packets passing gei-0/0/0/8.1
belong to this class-map.*/
2. Run the following commands to configure a class-map matching a physical interface.
ZXR10(config)#class-map gei-0/0/0/8 match-all
ZXR10(config-cmap)# match interface untag gei-0/0/0/8
/*If the specified interface is a physical interface, it is necessary to add the
untag keyword before the interface name.*/
3-5

Run the show class-map command to view the class-map configuration, which is
displayed as below.
ZXR10#show class-map
class-map gei-0/0/0/8 match-all
match interface untag gei-0/0/0/8
class-map gei-0/0/0/8.1 match-all
match interface gei-0/0/0/8.1
3.4.3 Configuring EXP-Based Flow Classification

1. There are three methods to specify an MPLS-EXP value: specifying a single value,
specifying multiple values, and specifying an MPLS-EXP value range. Any method
can be used.
2. In a class-map, it is not allowed to configure multiple “match mpls-exp” rules. This is the
same as most other matching rules. If multiple “match mpls-exp” rules are configured,
an error alarm is displayed.
3. The “match mpls-exp” rule conflicts with the “match child” rule and the “match interface”
rule.
Configuration Flow
1. Create a class-map, specify a name for it, set the matching mode to “match all”, and
use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the
same time.
2. Add a “match” rule to this class-map. The classification rule is “mpls-exp”.
l If the MPLS-EXP value is a single value, set the name to exp, and set the matching
rule to “match all”. Use the default protocol stack configuration, that is, supporting IPv4
and IPv6 at the same time. The classification rule is matching a single MPLS-EXP
value.
ZXR10(config)#class-map exp match-all
ZXR10(config-cmap)#match mpls-exp 1
l If the MPLS-EXP value is a range, set the name to exp1, and set the matching rule to
“match all”. Use the default protocol stack configuration, that is, supporting IPv4 and
IPv6 at the same time. The classification rule is matching an MPLS-EXP value range.
It is only necessary to match a value in the value range.
ZXR10(config)#class-map exp1 match-all
ZXR10(config-cmap)#match mpls-exp 0-4
3-6

l If the MPLS-EXP value has several values, in a “match mpls-exp” cause, four
MPLS-EXP values can be configured at most. A value here can be a single value
or a value range.
Set the name to exp2, and set the matching rule to “match all”. Use the default
protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. The
classification rule is matching four MPLS-EXP single values.
ZXR10(config-cmap)#match mpls-exp 0,2,4,7
Set the name to exp3, and set the matching rule to “match all”. Use the default
protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. The
classification rule is matching the combination of three MPLS-EXP single values and
an MPLS-EXP value range.
ZXR10(config-cmap)#match mpls-exp 0,2-4,5,7
l Run the show class-map command to check the configuration of matching a single
MPLS-EXP value, which is displayed as follows:
class-map exp match-all
match mpls-exp 1
ZXR10(config)#
l Run the show class-map exp1 command to check the configuration of matching an
MPLS-EXP value range, which is displayed as follows:
ZXR10(config)#show class-map exp1
class-map exp1 match-all
match mpls-exp 0-4
/*If the MPLS-EXP value in a packet matches a value in the MPLS-EXP value range,
the packet is classified into this class.*/
l Run the following commands to check the configuration of matching multiple
MPLS-EXP values, which is displayed as follows:
Run the show class-map exp2 command to verify the class-map exp2 configuration.
match mpls-exp 0,2,4,7
Run the show class-map exp3 command to verify the class-map exp3 configuration.

match mpls-exp 0,2-4,5,7
3-7

3.4.4 Configuring MAC Address-Based Flow Classification

1. In L2VPN environment, configure the flow classification based on the MAC address.
2. The packets of the L2VPN Ethernet private network have both the source MAC ad-
dress and the destination MAC address. For a sender, the flow can be classified in
accordance with the destination MAC address. For a receiver, the flow can be classi-
fied in accordance with the source MAC address.
3. In class-map configuration, when a rule is used to classify packets in accordance with
a MAC address, this MAC address is not specified to be a source MAC address or a
destination MAC address. When the class-map is used by a policy-map, the direction
(input or output) in which the policy-map is bound on an interface determines whether
the source MAC address or the destination MAC address is matched. If the policy-map
is bound in the input direction, the packets will be classified in accordance with the
source MAC address. If the policy-map is bound in the output direction, the packets
will be classified according to the destination MAC address.
4. The “match mac_address” rule conflicts with the “match child” rule and the “match
interface” rule.
Configuration Flow
1. Create a class-map named mac_address, and set the matching mode to “match all”.
Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the
same time.
2. Add a “match” rule to this class-map. The classification rule is matching a specified
MAC address.
1. Run the following command to create a class-map named mac_address.
PE1(config)#class-map mac_address match-all
/*When the default protocol stack is used in a class-map, the class-map supports
IPv4 and IPv6 at the same time.*/
2. Run the following command to configure a matching rule.
PE1(config-cmap)#match mac-address 0010.9400.0002
/*The MAC address is in dotted hex notation.*/
PE1(config-cmap)#exit
Run the show class-map mac_address command to check the configuration of MAC
address-based flow classification, which is displayed as follows:
PE1(config)#show class-map mac_address
class-map mac_address match-all
match mac-address 0010.9400.0002
PE1(config)#
3-8

3.4.5 Configuring IPv4 ACL-Based Flow Classification

1. If there are matching entities of the same type in a class-map, matching entities of the
same type are not allowed to be configured any more, unless the previous matching
entities are deleted. The “match ipv4-access-list” rule is an exception. In a class-map,
at most 64 IPv4 ACLs can be configured.
2. If multiple “match ipv4-access-list” rules are configured in a class-map, the packets
that match any of the ACLs can be classified into this class.
3. The “match ipv4-access-list” rule conflicts with the “match child” rule and the “match
interface” rule.
Configuration Flow
1. Create a class-map, set the name to v4_sip, set the matching rule to “match all”, and
set the protocol stack to IPv4.
2. Configure a “match” rule for this class-map. The classification rule is matching the
IPv4 access list named v4_sip.
3. Configure an IPv4 access list named v4_sip. In the IPv4 ACL, the packets with the
source address 100.1.1.128 are permitted.
Run the following commands to configure a class-map named v4_sip and configure the
matching rule.
ZXR10(config)#class-map v4_sip match-all ipv4
ZXR10(config-cmap)#match ipv4-access-list v4_sip
ZXR10(config)#
Run the following commands to create an IPv4 access list named v4_sip and specify the
permitted packets.
ZXR10(config)#ipv4-access-list v4_sip
ZXR10(config-ipv4-acl)#rule permit 100.1.1.128
ZXR10(config-ipv4-acl)#exit
1. Run the show ipv4-access-lists name v4_sip command to check the configuration of the
IPv4 access list, which is displayed as follows:
ZXR10(config)#show ipv4-access-lists name v4_sip
ipv4-access-list v4_sip
1/1 (showed/total)
10 permit 100.1.1.128 0.0.0.0
ZXR10(config)#
3-9

2. Run the show class-map v4_sip command to check the configuration of the class-map,
ZXR10(config)#show class-map v4_sip
class-map v4_sip match-all ipv4
match ipv4-access-list v4_sip
ZXR10(config)#
3.4.6 Classifying Flows in the Match-Any Mode

1. In class-map configuration, if the matching rule is “match-any”, the packets that match
any matching rule in the class-map will be classified into this class.
2. In the “match-any” mode, the “match interface” rule and the “match child” rule still
conflict with any other matching rules.
3. In a class-map whose matching rule is “match-any”, only one matching entity can be
configured for each type (except for ACL).
Configuration Flow
1. Create a class-map, set the name to anyone, and set the matching mode to “match
any”. Set the class-map to take effect for IPv4 and IPv6 packets. Configure multiple
matching rules in the class-map. The packets that match any rule will be classified
into this class.
2. Configure matching rule b, set the name of the IPv4 ACL to v4_sip. In the IPv4 ACL,
packets with the source address 100.1.1.128 are permitted.
3. Configure matching rule c that matches a MAC address. The MAC address is
0010.9400.0002.
Run the following commands on the ZXR10 M6000:
ZXR10(config)#class-map anyone match-any

ZXR10(config-cmap)#match ipv4-access-list v4_sip
ZXR10(config-cmap)#match mac-address 0010.9400.0002
The configuration of the IPv4 ACL named v4_sip is as shown below.
Run the following commands to create an IPv4 ACL named v4_sip and configure the
permitted traffic.
ZXR10(config)#ipv4-access-list v4_sip
ZXR10(config-ipv4-acl)# rule permit 100.1.1.128
ZXR10(config-ipv4-acl)#exit
3-10

Run the show ipv4-access-lists name v4_sip command to view the configuration of the IPv4
ACL, which is displayed as follows:
ZXR10(config)#show ipv4-access-lists name v4_sip
ipv4-access-list v4_sip
1/1 (showed/total)
10 permit 100.1.1.128 0.0.0.0
ZXR10(config)#
Run the show class-map anyone command to view the configuration of the class-map, which
is displayed as follows:
ZXR10(config)#show class-map anyone
match ipv4-access-list v4_sip
match mac-address 0010.9400.0002
3-11

3-12

Chapter 4
Flow Action Configuration
Table of Contents
Flow Action Overview .................................................................................................4-1
Configuring Flow Actions..........................................................................................4-10
Maintaining Flow Action............................................................................................4-13
Flow Action Configuration Instances.........................................................................4-13
4.1 Flow Action Overview

Flow Action Introduction
In traditional Internet Protocol (IP) networks, all packets are treated without any difference.
Routers use the First In First Out (FIFO) policy to process these packets. Routers transmit
packets to destinations with the best-effort principle. However, routers cannot guarantee
the performance such as transmission reliability and delay.
With the development of new applications in IP networks, there are new requirements for
Quality of Service (QoS). The best-effort principle in traditional IP networks cannot meet
the requirements of applications. For VoIP services for example, long delays in packets
transmission are not tolerated. A feasible method to solve this problem is to provide the
Quality of Service (QoS) ability for the Internet.
QoS is used to provide different service qualities (such as providing special bandwidth,
reducing the packet loss rate, and reducing delay and delay jitter) in accordance with
different requirements of applications. To achieve this purpose, QoS provides the following
functions:
l Packet classification
l Packet marking
l Traffic supervision and shaping
l Congestion avoidance
l Congestion management
Flow actions includes packet marking, traffic supervision and shaping, congestion
avoidance, and congestion management.
Packet Marking
The packet marking tool is normally used to create the trust boundary relied by other QoS
tools. Users can make different marks for different service classes in accordance with user
policies. A mark of a packet can be the criteria for the next classification, and the mark
4-1

also can be carried to other devices by the packet. In addition, the routers can re-mark
packets in accordance with traffic policing result, such as packet degradation.
Traffic Supervision and Traffic Sharing

Traffic policies are helpful to accomplish QoS. Traffic supervision and traffic shaping can
manage burst flows that enter a network.
l Traffic supervision
CAR is used to limit the traffic of some type of packets. CAR uses the token bucket
to control traffic. For the principle, see Figure 4-1.
Figure 4-1 Traffic Control Through CAR
A device classifies packets in accordance with the predefined matching rules. For
the packets with defined traffic characteristics, the device will send them directly
without the processing of the token bucket. For the packets with no defined traffic
characteristics, they will be sent to the token bucket for processing.
à If there are enough tokens to send the packets, the packets are allowed to pass
and then be sent.
à If there are not enough tokens in the token bucket to send the packets, the
packets will be dropped. In this way, packet traffic of a specific class can be
controlled.
Tokens can be put to the bucket in accordance with the rate set by users. Users
also can set the capacity of the token bucket. When the amount of tokens is equal
to the capacity, the amount will not increase. When a packet is handled by the token
bucket, if there are enough tokens in the bucket, the packet will be allowed to pass
and the amount of tokens in the bucket will reduce in accordance with the lengths of
the packet. When there are not enough tokens, the packet will be dropped.
When the bucket is full of tokens, all the packets represented by tokens can be
transmitted. This allows the burst transmission of data. When there is no token in the
4-2

Chapter 4 Flow Action Configuration
bucket, packets will not be sent until enough new tokens are generated in the bucket.
Therefore, the rate of packet traffic should not be larger than the rate to generate
tokens, which achieves traffic limit.
l Traffic shaping
The typical function of traffic shaping is to limit the traffic and burst that leave a
connection in a network, so that the packets of this type can be sent out at an even
speed. In general, traffic shaping uses a buffer and a token bucket to accomplish its
function. When the packets are sent quickly, they are stored in the buffer, and then
the buffered packets are sent at an even speed under the control of the token bucket.
The technology used by traffic shaping is called Generic Traffic Shaping (GTS). GTS
can shape the traffic that is fitful or the traffic that does not meet the predefined
traffic characteristics. It is helpful to match the bandwidths between upstream and
downstream in the network.
The same as CAR, GTS also uses the token bucket to control traffic. When CAR is
used to control the traffic, it drops the packets that do not meet the predefined traffic
characteristics. However, GTS buffers the packets that do not meet the predefined
traffic characteristics, so the number of dropped packets is reduced. At the same time,
the flow characteristics are met. This is the main difference between CAR and GTS.
For the GTS principle, see Figure 4-2. The queue used to buffer the packets is called
a GTS queue.
Figure 4-2 GTS Principle
GTS can shape specified packet traffic or all packet traffic on a specified interface.
When packets arrive, the packets are classified first.
à If the packets do not need GTS processing, they are sent without being processed
by the token bucket.
à If the packets need GTS processing, they are compared with the tokens in the
bucket, and the tokens are put to the bucket in accordance with the rate defined
by users. When there are enough tokens in the bucket, the packets are sent, and
the number of the tokens in the bucket decreases in accordance with the length
of the packets. When there are less tokens in the token bucket, the packets are
buffered in the GTS queue.
4-3

When there are packets in the GTS queue, GTS takes out the packets from the queue
to send the packets at a specific interval. Before sending the packets, GTS compares
the number of the packets with the number of the tokens in the bucket. GTS stops
sending packets if there are not enough tokens or all packets are sent out.
For example, Router A is connected to Router B. To reduce packet loss, packets can
be handled by GTS on the egress of Router A. The packets that do not meet the GTS
traffic characteristics are stored in the buffer of Router A. When Router A sends the
next batch of packets, GTS takes out the packets from the buffer queue and sends the
packets. In this way, the packets sent to Router B meet the traffic characteristics on
Router B, and packet loss on Router B is reduced. If the packets are not processed by
GTS on the egress of Router A, all packets that do not meet the traffic characteristics
on Router B will be dropped by Router B.
Congestion Management
Congestion management is used to manage and control packet flows to meet the QoS
requirements of services when congestion occurs.
When there is no congestion on a network interface, data packets will be sent out
immediately after the data packets arrive at the interface. When the speed of the data
packets arriving at the interface is greater than the speed to handle the packets on the
interface, the interface will be congested. For congestion management on an interface, it
is necessary to classify the packets into different classes in accordance with the principle
(such as the priority of the packets) and put the packets to different queues. Queue
scheduling treats packets of different priorities with differences.
Congestion management can be accomplished by using a queuing technology. The
queuing technology consists of creating queues, classifying packets, and putting packets
to different queues, and scheduling queues. Different queue algorithms can be used in
different situations to make different congestion management effects.
At present, the widely used queuing technologies include FIFO, PQ, Custom Queuing
(CQ), WFQ, and CBWFQ.
l FIFO
FIFO does not classify packets. Packets enter the queue in accordance with the arrival
sequence. At the same time, packets are sent in accordance with the sequence in
which the packets enter the queue, that is, the packets entering the queue first will be
sent first, and the packets entering the queue later will be sent later. For the principle,
see Figure 4-3.
4-4

Figure 4-3 FIFO Principle
l PQ
PQ classifies packets first and then put the packets to the corresponding queues in
accordance with the classes. When packets leave the queues, packets in the queue
with high priority leave first. The packets in the medium priority queue leave the queue
after all the packets in the high priority queue are sent. As the same, the packets in
the normal priority queue leave the queue after all the packets in the medium priority
queue are sent.
The packets in the higher priority queues are sent with preference to other packets.
When congestion occurs on the network, the packets with lower priorities will be
delayed by the packets with higher priorities. As a result, the packets for important
services will always be processed first, and packets for unimportant services will be
processed when the network is idle. In this way, the important services are handled
timely and network resources are used fully.
PQ always ensures that the packets with higher priority are sent in preference to other
packets with lower priorities. When there is too much higher priority traffic, the traffic
with lower priority may have no opportunity to be sent. It is necessary to plan the traffic
of different priorities when PQ is used. The traffic with higher priority should be limited
properly, so that the traffic with lower priority also has the opportunity to be sent.
Both the ToS field in IP headers and the Exp field in MPLS shims support 8 priorities
at most. So the PQ on the ZXR10 devices supports 8 priority queues. The priorities
of the queues are in decreasing order. For the PQ principle, see Figure 4-4.
Figure 4-4 PQ Principle
4-5

l CQ
There are 17 CQ queues. First, CQ classifies packets into 17 classes at most. And
then CQ puts the packets to the corresponding queues in accordance with the packets
classes.
No.0 queue has the highest priority. CQ always sends the packets in No.1–No.16
queues after all the packets in No.0 queue are sent out. Customers can define
the proportion of the bandwidths allocated to the packets in No.1–No.16 queues
on the interface. When the packets leave the queues, CQ takes out the packets
from No.1–No.16 queues in accordance with defined bandwidth proportion and then
sends the packets.
In this way, packets of different services can obtain proper bandwidths. This ensures
that the important service can obtain more bandwidths and the unimportant service
also can obtain some bandwidths.
CQ provides the advantage of customizing queues. It also has a disadvantage, that is,
the delay of the service with the same priority is not foreseeable. For the CQ principle,
see Figure 4-5.
Figure 4-5 CQ Principle
l WFQ
WFQ classifies packets in accordance with flows, so it is also called flow-based
WFQ. The packets with the same source IP address, destination IP address, source
port number, and destination port number belong to a flow (sometimes, ToS/DSCP is
also used as the criterion to classify flows). Each flow corresponds to a queue. When
packets leave queues, WFQ schedules the queues in accordance with specified
weights. The weights are defined through a certain algorithm. In this way, packets
with different priorities are treated differently on the basis of fairness. For the WFQ
principle, see Figure 4-6.
4-6

Figure 4-6 WFQ Principle
l CBWFQ
CBWFQ classifies packets in accordance with the network device port, packet
protocol, and ACL rule. Each class of traffic corresponds to a queue. There are
64 classes at most. Different classes of packets are put to different queues. The
packets that do not match any class are put to the default queue. The queues use the
Weighted Round Robin (WRR) algorithm when round-robin classification technique
is used.
Users can customize some transport characteristic for each traffic class, such as
bandwidth, transport weight, and transport limit. The bandwidth specified for a queue
is the bandwidth that is ensured for the queue when bandwidth congestion occurs.
The scheduler ensures that each queue can obtain some bandwidths in accordance
with the weights defined for each traffic class. Users can configure the limit of the
length for the queue of each traffic class. The limit of the length is the maximum
number of packets that can be put in a queue. If the length of a queue reaches the
limit, the packet dropping policy takes effect. CBWFQ can be combined with dropping
mechanisms (such as tail drop and WRED).
In this way, when there is no congestion on an interface, packets of different traffic
classes can obtain certain bandwidths. When congestion occurs on the interface, the
bandwidths of the packets in the queue with higher priority will not exceed the defined
value, which ensures that other packets can obtain corresponding bandwidths.
CBWFQ provides certainty or rigid guarantee for the bandwidths that is allocated
to each traffic class. High-speed links or backbone networks focus on the strict
guarantee of bandwidth allocation. CBWFQ is a strong QoS tool. For the CBWFQ
principle, see Figure 4-7.
4-7

Figure 4-7 CBWFQ Principle
Congestion Avoidance
Network congestion will reduce the network performance, and bandwidth cannot be fully
used. To avoid congestion, queues can prevent any possible congestion by dropping
packets.
The dropping policies include tail drop, RED, and WRED.
1. Tail drop
Tail drop is used to drop packets that enter the queue later when the queue buffer is
full.
Tail drop may cause “TCP global synchronization”. Packet dropping consists of
triggering Transfer Control Protocol (TCP) slow-start and the congestion avoidance
mechanism to reduce TCP transmission rate by dropping packets on the base of
the applicability characteristic of TCP communication. However, when a queue
drops several TCP connection packets at the same time, the number of the packets
sent to the queue by these TCP connections will decrease. So packets sent to the
queue are less than that the packets sent by the connections, which reduces the
bandwidth usage on the connections. When the connections start to send packets
again, congestion will occur again. This causes wave-type network congestion on the
network, that is, “TCP global synchronization”, see Figure 4-8.
4-8

Figure 4-8 Tail Drop
2. RED
RED solves the “TCP global synchronization” problem caused by simple dropping.
The RED algorithm executes early dropping for specified packets (and specified
connection) by monitoring the length of the queue buffer. Few TCP senders will
withdraw and retransmit the packets. For the RED dropping policy, see Figure 4-9.
Figure 4-9 RED Dropping Policy
RED sets the minimum threshold and the maximum threshold of the queue length in
the output buffer. The device monitors the thresholds when making packet sending
policies later. During the packet switching policy procedure, the average queue length
is checked.
l If the average queue length is less than the minimum threshold, the packets enter
the queue and they are switched later.
l If the average queue length is between the minimum threshold and the maximum
threshold, the packets will be dropped in accordance with certain probability.
4-9

l If the average queue length is greater than the maximum threshold, all packets
will be dropped.
3. WRED
WRED combines DSCP in IP headers with RED to provide the dropping thresholds
for communication flows with higher priority. There are differentials between the
dropping thresholds for a communication flow with higher priority and those of a
standard communication flow with lower priority. That is to say, WRED drops packets
in accordance with the DSCP field in IP headers selectively. For different dropping
thresholds accomplished by a WRED policy, see Figure 4-10.
Figure 4-10 WRED Principle
WRED monitors the average queue length in a network device, so it can determine
when to start to drop packets in accordance with the queue length. The average queue
length is the result of the queue length after low-pass filter. The average queue length
reflects the change trend of queue changes, and it is not sensitive to the change burst
of the queue length. This avoids unfair treatment to burst data flows.
When the average queue length is greater than the defined minimum threshold,
WRED starts to drop data packets (including TCP and UDP) in accordance with
a certain probability. When the average queue length is greater than the defined
maximum threshold, WRED uses the tail drop rule, that is, all packets arriving later
will be dropped first. WRED intends to keep the queue length between the minimum
threshold and the maximum threshold.
4.2 Configuring Flow Actions

To configure flow actions on the ZXR10 M6000, perform the following steps:
4-10

1 ZXR10(config)#policy-map <policy-map-name> Creates a policy-map and enters

policy mapping configuration mode.
2 ZXR10(config-pmap)#class <class-map-name> Associates a class with a class-map

and enters policy class configuration
mode.
3 ZXR10(config-pmap-c)#bandwidth percent <percentage> Configures the minimum available

bandwidth percentage for the policy
class.
ZXR10(config-pmap-c)#priority-level <pq-level> Configures the PQ priority for the

policy class.
ZXR10(config-pmap-c)#priority-llq Configures the Low Latency Queuing

(LLQ) priority for the policy class.
ZXR10(config-pmap-c)#police <cir><cbs>[<pir><pbs>] Configures the traffic supervision for

the policy class.
ZXR10(config-pmap-c)#set dscp {<dscp-value>| inherit-from {dscp | Configures the policy class to use a
precedence | 8021p | mpls-exp}} designated value to mark the DSCP
field of packets.
ZXR10(config-pmap-c)#set precedence {<ipp-value>| inherit-from { Configures the policy class to use

dscp| precedence | 8021p | mpls-exp}} a designated value to mark the IP
precedence field of packets.
ZXR10(config-pmap-c)#set 8021p {<8021p-value>| inherit-from Configures the policy class to use an

{dscp| precedence | 8021p | mpls-exp}} inheritance value to mark the 802.1p
field of packets.
ZXR10(config-pmap-c)#set mpls-exp {<exp-value>| inherit-from Configures the policy class to use

{dscp| precedence | 8021p | mpls-exp}} a designated value to mark the
MPLS-EXP field of packets.
ZXR10(config-pmap-c)#random-detect enable Enables WRED of a policy.
ZXR10(config-pmap-c)#random-detect weight <weight-len> Configures the average queue

length of WERD.
ZXR10(config-pmap-c)#random-detect precedence Configures the IP precedence-based

<precedence><min-threshold><max-threshold><probability> WRED parameters.
ZXR10(config-pmap-c)#service-policy <policy-map-name> Configures a hierarchical policy for

the policy class.
4 ZXR10(config)#service-policy <interface-name>{input | Binds the policy-map to an interface.

output}<policy-map-name>[{overwrite | append}][statistical-share]
ZXR10(config)#switch-fabric service-policy<policy-map-name> Binds the H-QoS policy to a switching

network.
4-11

<class-map-name> Class-map name.
<dscp-value> IP DSCP value. Range: 0-63.
<precedence> IP precedence value. Range: 0-7.
<mpls-exp-value> MPLS-EXP value. Range: 0-7.
<invlan-value> In-VLAN value. Range: 1-4094.
<invlan-min> Minimum value of in-VLAN. Range: 1-4094.
<invlan-max> Maximum value of in-VLAN. Range: 1-4094.
<exvlan-value> Ex-VLAN value. Range: 1-4094.
<exvlan-min> Minimum value of ex-VLAN. Range: 1-4094.
<exvlan-max> Maximum value of ex-VLAN. Range: 1-4094.
<in8021p-value> In-8021p value. Range: 0-7.
<in8021p-min> Minimum valueof in-8021p. Range: 0-7.
<in8021p-max> Maximum value of in-8021p. Range: 0-7.
<ex8021p-value> Ex-8021p value. Range: 0-7.
<ex8021p-min> Minimum value of ex-8021p. Range: 0-7.
<ex8021p -max> Maximum value of ex-8021p. Range: 0-7.
<policy-map-name> Policy-map name.
<percentage> The percentage of the minimum bandwidth. Range: 1-100.
<pq-level> Priority level of PQ. Range: 1-4.
<cir> CIR value. Range: 8 Kbit/s to 20000000 Kbit/s.
<cbs> CBS value. Range: 1 Kbyte to 5120000 Kbytes.
<pir> PIR value. Range: 8 Kbit/s to 20000000 Kbit/s.
<pbs> PBS value. Range: 1 Kbyte 5120000 Kbytes.
<modified> TrTCM.
<weight-len> Average queue length.
<min-threshold> The WRED minimum threshold. Range: 1 to 1024000 Kbytes.
<max-threshold> The WRED maximum threshold. Range: 1 to 1024000 Kbytes.
<probability> WRED dropping probability. Range: 1 to 100.
<interface-name> Name of the designated interface.
4-12

Caution!
l “Set dscp” conflicts with “set precedence”.
l The “bandwidth” action and “priority-level” action are mutually exclusive in the same
policy-map, except for the default queue.
l During the priority scheduling configuration, four priorities (including the default
priority) can be designated. By default, the default priority is the lowest. Packets that
do not match the QoS policy on an interface will go to the default queue to participate
in PQ scheduling.
l During the configuration of bandwidth scheduling, users can designate a default class
explicitly and configure the weight. When users do not configure the class explicitly,
packets that do not match the QoS policy on the interface will go to a default class.
The class participates in WFQ scheduling as other configured classes do.
l When the append keyword is selected, there is only one layer of policy-map bound,
and only global ports can be matched. (The class is not allowed to exceed the range
of sub-interfaces that have been configured. It can be less than the range, but cannot
be larger than the range. The configured actions can be rate-limit, WFQ, and PQ.)
4.3 Maintaining Flow Action

To maintain the flow action on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show class-map[<class-map-name>] Displays all class-maps and configurations of all

matching rules.
ZXR10#show policy-map[<policy-map-name>[class Displays all policy-maps and configurations of all

<class-name>]] policy classes.
ZXR10#show service-policy[<interface-name>] Displays all policy bindings on interfaces.
ZXR10#show switch-fabric Displays the H-QoS policy binding of the switching

network.
4.4 Flow Action Configuration Instances

4.4.1 Configuring Packet Marking (Set)
1. The marking function is supported in the following fields in packets.
l 802.1p: It marks the 802.1p field in the Layer 2 header of packets
l Precedence/dscp: It marks the precedence field (0–7)/DSCP field (0–63) in Layer
3 header of packets
4-13

l MPLS-EXP: It marks the MPLS-EXP field of labelled packets

2. The “set dscp” action conflicts with the “set precedence” action. Other actions can be
configured at the same time.
3. In a policy-map, if multiple actions are configured, the “set mpls-exp” action takes effect
for the matching labelled flows, the “set precedence” action or the “set dscp” action
takes effect for ordinary IPv4 flows, and the “set 802.1p” action takes effect for all
matching flows.
4. This example shows how to configure the “set 8021p”, “set mpls-exp”, and “set
precedence” actions.
Configuration Flow
1. Create a policy-map named mark.
2. Specify a class-map for this policy-map (to ensure that this class-map matches with
both labeled packets and ordinary packets, select a class-map whose matching rule
is “match mac-address”/“match child”/“match interface”), and then configure the “set
mpls-exp” and “set precedence” actions in policy-map configuration mode.
1. Run the following commands to configure a class-map whose matching rule is “match
interface”.
ZXR10(config)#class-map gei-0/0/0/8 match-all
ZXR10(config-cmap)#match interface untag gei-0/0/0/8
2. Run the following commands to configure a policy.
ZXR10(config)#policy-map mark
ZXR10(config-pmap)#class gei-0/0/0/8
ZXR10(config-pmap-c)#set 8021p 5
ZXR10(config-pmap-c)#set mpls-exp 7
ZXR10(config-pmap-c)#set precedence 2
ZXR10(config-pmap-c)#set dscp 0
%Code 5553: The set dscp is incompatible with the set precedence in the same
policy class, please check!
ZXR10(config-pmap-c)#exit
Run the show policy-map mark command to check the packet marking configuration, which
ZXR10(config)#show policy-map mark
policy-map mark
class gei-0/0/0/8
set 8021p 5
set mpls-exp 7
set precedence 2
4-14

ZXR10(config)#
4.4.2 Configuring Traffic Supervision (Police Rate Limit)

1. Traffic supervision (police) supports two rates, CIR and PIR, and their burst sizes, that
is, CBS and PBS.
2. PIR and CIR are measured in bytes of IP packets per second. The unit is Kbit/s. The
value of PIR must be greater than or equal to the value of CIR.
3. PBS and CBS mean that when the transient traffic does not reach the specified rates,
the rest can be used to process other traffic received before or after this moment.
4. PBS and CBS are measured by the number of bytes contained in IP packets. The unit
is Kbytes. The values must be more than 0 and must be greater than or equal to the
maximum bytes of IP packets that may pass.
Configuration Flow
1. Create a policy-map named police.
2. Specify a class-map for this policy-map, and then configure police rate limit in
policy-map configuration mode.
Run the following commands to configure traffic supervision on the ZXR10 M6000:
ZXR10(config)#policy-map police
ZXR10(config-pmap)#class exp3
ZXR10(config-pmap-c)#police 100000 10 120000 10
/*Police the traffic matching class exp3. The CIR is 100000 Kbit/s
the PIR is 120000 Kbps.The size of the token bucket is 10Kbytes.*/
ZXR10(config-pmap)#exit
Run the show policy-map police command to view the traffic supervision configuration,
ZXR10(config)#show policy-map police

policy-map police
class exp3
police 100000 10 120000 10
ZXR10(config)#
4-15

4.4.3 Configuring PQ (Priority-Level)

1. There are several types of queue scheduling, including FIFO, PQ, WFQ, and CBWFQ.
The scheduling technologies are used for the congestion management. When the
traffic does not exceed the bandwidths, queue scheduling does not affect the traffic.
2. Among the queue scheduling supported by the ZXR10 M6000, except the default
FIFO queue, other queues perform scheduling on the basis of packet classification. In
policy-map configuration, a priority can be specified for the current type of traffic after
the class-map is configured.
3. In PQ, there are four priorities. Each type of packet corresponds to a priority. Packets
in the highest priority queue are always sent first. After all the packets in the highest
priority queue are sent, the packets in the next priority queue will be sent.
4. PQ always ensures that packets with the high priorities are sent with precedence,
so packets with low priorities may have no chance to be sent when there are many
packets with high priorities. Therefore, it is necessary to plan the traffic with different
priorities reasonably when PQ is used. The traffic with high priorities should be limited
properly so that the traffic with low priorities also have a chance to be sent.
5. PQ configuration conflicts with the bandwidth percentage. That is to say, in a
policy-map, between PQ and the bandwidth percentage, only one can be used.
Configuration Flow
1. Configure the queue scheduling (priority-level) based on the PQ.
2. In accordance with the configuration description, configure different rate limits (police)
for the packets with different priorities. This ensures that packets with high priorities
can be sent with precedence, and also ensures that packets with low priorities have a
chance to be sent.
3. This configuration example is applicable to an MPLS forwarding situation. By
classifying packets and configuring priorities in accordance with the MPLS-EXP field
values, the following effects can be achieved.
l Packets whose MPLS-EXP field value is 1 have the highest priority. The rate limit
is 100 M.
l Packets whose MPLS-EXP field value is 2 have the second priority. The rate limit
is 50 M.
l Packets whose MPLS-EXP field value is 3 have the lowest priority. The rate limit
is 30 M.
l Other packets are not affected and they are forwarded properly.
1. Run the following commands to configure a class-map that will be used in the
policy-map.
4-16

2. Run the following commands to configure a policy-map, set the name to pq, set the
class-map configured in Step 1 in this policy-map, and then configure the PQ policy.
ZXR10(config)#policy-map pq
ZXR10(config-pmap-c)#priority-level 1
ZXR10(config-pmap-c)#police 100000 100
Run the show class-map command to view the PQ configuration, which is displayed as
follows:
match mpls-exp 1
match mpls-exp 2
class-map exp4match-all
match mpls-exp 3
ZXR10(config)#show policy-map pq
policy-map pq
class exp1
priority-level 1
police 100000 100
class exp2
priority-level 2
police 50000 50
class exp4
priority-level 3
4-17

police 30000 30
4.4.4 Configuring WFQ Scheduling

1. WFQ is on the basis of flow classification. Each flow class corresponds to a WFQ
queue. The priority of WFQ queues are the same. When packets leave queues,
specific weights are used for scheduling. The queue weights are accomplished
through a certain algorithm. In this way, on a fair basis, services with different
priorities are treated differently.
2. For all policy classes in a policy-map, the sum of the configured bandwidth percentages
must not be greater than 100 percent.
3. Bandwidth percentage configuration conflicts with PQ configuration. That is to say, in
a policy-map, between PQ and the bandwidth percentage, only one can be used.
4. After WFQ is configured, interface traffic is sent properly if there is no congestion.
When congestion occurs, bandwidths are allocated in accordance with configured
weights. The traffic that does not match any class can take up the remaining bandwidth
percentages.
Configuration Flow
1. Classify packets into four classes in accordance with the IP precedence field values
in packets.
2. Configure a policy-map named WFQ.
l For the packets whose IP precedence is 1, set the bandwidth percentage to 30%.
3. In this way, 100 percent of bandwidth resources are reserved by the four classes of
packets. The traffic that does not match any class cannot be forwarded.
1. Run the following commands to configure class-maps.
ZXR10(config)#class-map pre1 match-all
ZXR10(config-cmap)#match precedence 1
4-18

2. Run the following commands to configure a policy-map and set the name to WFQ.
ZXR10(config)#policy-map WFQ
ZXR10(config-pmap)#class pre1
ZXR10(config-pmap-c)#bandwidth percent 30
Check the configuration of the class-maps by running the show class-map command, which
class-map pre1 match-all
match precedence 1
match precedence 2
match precedence 3
match precedence 4
View the configuration of the policy-map by running the show policy-map command, which
ZXR10(config)#show policy-map WFQ
policy-map WFQ
class pre1
bandwidth percent 30
class pre2
class pre3
class pre4
4-19

4.4.5 Configuring CBWFQ (LLQ + WFQ)

1. CBWFQ is a queue scheduling technology on the basis of flow classification. Each
flow class corresponds to a queue. In general, it is only necessary to set one queue
as the LLQ queue and set others as the WFQ queues.
2. In CBWFQ, the bandwidth allocated to the LLQ queue is the committed bandwidth of
this queue when bandwidth congestion occurs. The left bandwidths are allocated to
each WFQ queue by the scheduler in accordance with the weights.
3. In this way, when there is no congestion on a port, packets with different flow types can
be sent properly. When congestion occurs on a port, the packets in the LLQ queue
will not take up extra bandwidth, thus ensuring that the bandwidths are used by other
packets.
Configuration Flow
1. Assume that there are four users. The IP precedence of the users is different. They
are 1, 2,3, and 4, respectively. Four class-maps can be configured in accordance with
these features.
2. Configure a policy-map named CBWFQ.
l User1 is in an LLQ queue, and the rate limit is 500 Mbps.
l User2 is in a WFQ queue, and the bandwidth percentage is 30%.
1. Run the following commands to configure class-maps.
2. Run the following commands to configure a policy-map named CBWFQ, and configure
CBWFQ scheduling for the traffic of different classes.
ZXR10(config)#policy-map CBWFQ
ZXR10(config-pmap-c)#priority-llq
4-20


ZXR10(config-pmap-c)# bandwidth percent 10
Run the show class-map command to view the class-map configuration, which is displayed
as follows:
match precedence 1
match precedence 2
match precedence 3
match precedence 4
Run the show policy-map command to view the policy-map configuration, which is
displayed as follows:
ZXR10(config)#show policy-map
policy-map CBWFQ
class pre1
priority-llq
police 500000 500
class pre2
class pre3
class pre4
4-21

4.4.6 Configuring VLAN-ID-Based Scheduling (Match Interface)

1. The previous three configuration examples describe three types of queues supported
at present in terms of queue scheduling technologies. This configuration example
describes queue scheduling in terms of flow classification.
2. As described previously, PQ, WFQ and CBWFQ are scheduling technologies on the
basis of flow classification. VLAN-ID-based scheduling is used to classify flows on the
basis of VLAN-ID, and then schedule the classes. The scheduling technology can be
PQ, WFQ or CBWFQ.
3. Besides VLAN-ID-based scheduling, there are IP packet quintuplet-based, MAC
address-based, and MPLS-EXP-based scheduling technologies. The features that
support flow classification can be used as the basis to configure scheduling.
Configuration Flow
1. Create VLAN-ID-based class-maps. Match several sub-interfaces of a physical
interface in the class-maps.
2. Create a policy-map named vlanid. Call the class-maps, and configure PQ, WFQ or
CBWFQ.
3. Shows the configuration of VLAN-ID-based PQ.
1. Run the following command to configure the class-maps for the “match interface” rules.
2. Run the following command to configure a policy-map with the name being vlanid, and
dispatch the class-maps to configure police rate limits.
ZXR10(config)#policy-map vlanid
ZXR10(config-pmap)#class gei-0/7/0/1.1
4-22

Run the show class-map command to view the VLAN-ID-based class-map configuration,
ZXR10#show class-map
Run the show policy-map vlanid command to view the policy-map configuration, which is
ZXR10#show policy-map vlanid
policy-map vlanid
class gei-0/7/0/1.1
priority-level 2
class gei-0/7/0/1.2
priority-level 3
class gei-0/7/0/1.3
priority-level 4
4.4.7 Configuring WRED

1. WRED is used for dropping congested traffic randomly (congestion avoidance).
2. WRED monitors the average length of a queue on a device, so it can determine when
to drop the packets in accordance with the average length of the queue.
3. A maximum threshold and a minimum threshold are configured in WRED configuration.
When the average queue length is greater than the defined minimum threshold, WRED
starts to drop data packets in accordance with a certain probability. When the average
queue length is greater than the defined maximum threshold, WRED becomes tail
drop, that is, all packets arriving later will be dropped.
4. WRED intends to keep the queue length between the minimum threshold and the
maximum threshold.
Configuration Flow
1. Configure a WRED whose precedence is set to 0 manually.
2. Set WRED together with police rate limit.
4-23

3. Create a policy-map named WRED and dispatch a class-map whose matching rule is
“match child”.
4. Configure rate limit and WRED in the policy-map.
1. Run the following commands to create a class-map.
ZXR10(config)#class-map child match-all
ZXR10(config-cmap)#match child
2. Run the following commands to create a policy-map, set the name to WRED, and
configure police rate limit and WRED.
ZXR10(config)#policy-map WRED
ZXR10(config-pmap)#class child
ZXR10(config-pmap-c)#random-detect enable
ZXR10(config-pmap-c)#random-detect precedence 0 10000 20000 100
Run the show class-map child command to viw the configuration of the class-map, which
ZXR10(config)#show class-map child
class-map child match-all
match child
Run the show policy-map WRED command to view the configuration of the policy-map,
ZXR10(config)#show policy-map WRED
policy-map WRED
class any
police 100000 100
random-detect enable
random-detect precedence 0 10000 20000 100
4.4.8 Configuring H-QoS (L1 CBWFQ + L2 Police)

Four users (user1, user2, user3 and user4) are connected to gei-0/1/0/1 and gei-0/1/0/2,
see Figure 4-11.
Configuration requirements:
4-24

l Packets of user1 pass through with precedence, and the maximum bandwidth is 500
Mbps.
l The CIR of user2 is 300 Kbit/s, and the rate can be greater than 300 Kbit/s.
l The CIR of user3 is 100 Kbit/s, and the burst rate is 150 Kbit/s.
Figure 4-11 Configuring H-QoS (L1 CBWFQ + L2 Police)
Configuration Flow
1. Configure H-QoS on the gei-0/1/1/3 downlink. This ensures that appropriate
bandwidth is allocated to each user when congestion occurs on the interface.
2. Configure four class-maps. The precedence of the four users is 1, 2, 3, and 4,
respectively.
3. Configure that user1 is in the LLQ, and the rate is limited to 500 Mbps.
4. Configure that user2 is in the WFQ, and the bandwidth percentage is 30%.
5. Configure that user3 and user4 are in the WFQs, and the bandwidth percentage is
20%.
6. Configure rate limit for the next level policy in class-maps of user3 and user4.
7. In the second-layer policy, configure that the CIR of user3 and user4 is 100 Kbit/s, and
the PIR of user3 and user4 is 150 Kbit/s.
1. Run the following commands to configure the interfaces:
ZXR10(config)#interface gei-0/1/0/1
ZXR10(config-if)#ip address 10.20.1.1 255.255.255.0
ZXR10(config-if)#exit
2. Run the following commands to configure the class-maps:
4-25

ZXR10(config-cmap)#match precedence 3,4
3. Run the following commands to configure a Level-2 policy-map:
ZXR10(config)#policy-map car1
ZXR10(config)#policy-map test
ZXR10(config-pmap-c)#service-policy car1
5. Run the following command to bind the policy to the corresponding interface:
ZXR10(config)#service-policy gei-0/1/0/3 output test overwrite
Run the show policy-map command to view the configuration of the policy-maps, which is
policy-map car1
class pre3
police 100000 100 150000 150
class pre4
police 100000 100 150000 150
policy-map test
4-26

class pre1
priority-llq
police 500000 500
class pre2
class pre34
service-policy car1
Run the show service-policy command to view the binding on the interface, which is
ZXR10#show service-policy
service-policy gei-0/1/1/1 output test overwrite
4-27

4-28

Chapter 5
H-QoS Configuration
Table of Contents
H-QoS Overview ........................................................................................................5-1
Configuring H-QoS .....................................................................................................5-1
Maintaining H-QoS .....................................................................................................5-2
H-QoS Configuration Instances ..................................................................................5-3
5.1 H-QoS Overview

Through the hierarchy-QoS (H-QoS), users can set the hierarchical relationships of
schedulers based on actual needs. Multi-layer logical schedulers are deployed, and the
upper-layer scheduler controls the total bandwidth of lower-layer schedulers and decides
the Committed Information Rate (CIR) and Peak Information Rate (PIR) of lower-layer
schedulers in accordance with the layers and weights of the lower-layer schedulers.
H-QoS controls the bandwidth flexibly through multi-layer schedulers. Specifically, it
controls the total bandwidth of multiple queues that may result from one or more user
services, and implements the total quality control of one or more services.
For example, an operator allocate a bandwidth of 400 Kbps to a user, which is occupied by
audio streams and data streams. Based on the user requirement, the data stream at least
occupies 250 Kbps and the audio stream at least occupies 150 Kbps. If the bandwidth
that the audio stream occupies does not reach 150 Kbps, the data stream can occupy a
bandwidth of more than 250 Kbps. If the bandwidth that the data stream occupies does
not reach Kbps, the audio stream can occupy a bandwidth of more than Kbps.
For the introduction and principle of H-QoS, refer to Chapter 1 “QoS Overview”.
5.2 Configuring H-QoS

To configure a QoS binding policy after the flow classification and flow actions are
configured on the ZXR10 M6000, run the following commands:
Command Function
ZXR10(config)#service-policy <interface-name>{input | Binds a policy to an interface.

output}<policy-map-name>[{overwrite | append}][statistical-share]
ZXR10(config)#switch-fabric service-policy <policy-map-name> Binds an H-QoS policy to a switching network.
5-1

5.3 Maintaining H-QoS

To maintain a H-QoS on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show class-map [<class-map-name>] Displays all class-maps and configuration of

matching rules.
ZXR10#show policy-map [<policy-map-name>[class [class-name]]] Displays all policy-maps and configuration of

policy classes.
ZXR10#show service-policy [ interface-name] Displays all policy bindings on interfaces.
ZXR10#show running-config hqos Displays the information of class-map and

policy-map.
ZXR10#show running-config hqos-if Displays the H-QoS policies bound to

interfaces.
ZXR10#show switch-fabric Displays policy bindings to the switching

network.
ZXR10#show qos-statistics interface <interface-name>{input|output} Displays the H-QoS statistics for the specified
direction of an interface.
The following is sample output from the show qos-statistics interface command:
ZXR10(config)#show qos-statistics interface gei-0/0/0/1 input
Interface gei-0/0/0/1 current service-policy configuration:
service-policy input : police
dwCurQueueDepth : 3994624 (byte)
drop rate / transmit rate : 98543296 / 10657776 (bps)
total drops / total transmits : 5994573 / 5976185 (packets)
class-map : pre1
dwCurQueueDepth : 3994624 (byte)
drop rate / transmit rate : 98543296 / 10657776 (bps)
total drops / total transmits : 5994573 / 650068 (packets)
history transmit rate : 25128 ; 0 ; 0 ; 0 ; 0 (bps)
history drop rate : 226136 ; 0 ; 0 ; 0 ; 0 (bps)
history transmit packet : 585592 ; 64476 ; 0 ; 0 ; 0 (packets)
history drops packet : 5414468 ; 580105 ; 0 ; 0 ; 0 (packets)
service-policy input: police Name of the H-QoS bound in the input direction is police.
dwCurQueueDepth: 3994624 (byte) Depth value of the current queue. It is set to the threshold when the
queue is congested continuously.
drop rate / transmit rate: 98543296 / Drop rate/transmit rate of the current interface.
10657776 (bps)
5-2

Chapter 5 H-QoS Configuration
class-map: pre1 Effective object of the current policy is the flow classification named
pre1.
5.4 H-QoS Configuration Instances

5.4.1 Priority Scheduling Configuration Example
Four users (user1, user2, user3 and user4) are connected to interface gei-0/1/0/1 and
interface gei-0/1/0/2, see Figure 5-1.
The configuration requirements are as follows:
l Packets of user1 pass through with preference, and the maximum bandwidth is 500
Mbps.
l The CIR of user2 is 300 Kbit/s, and the rate can be larger than 300 Kbit/s.
Figure 5-1 Priority Scheduling Configuration Example
Configuration Flow
1. Configure H-QoS on the downlink gei-0/1/0/3. This ensures the bandwidth of each
user when congestion occurs on the interface.
2. Configure four class-maps. The precedence of the four users is 1, 2, 3, and 4
respectively.
3. Configure that user1 is in the LLQ queue, and the rate is limited within 500 Mbps.
4. Configure that user2 is in the WFQ queue, and the bandwidth percentage is 30%.
5. Configure that user3 and user4 are in the WFQ queues, and the bandwidth percentage
is 20%.
6. Configure rate limit for the next level policies in class-maps of user3 and user4.
7. In the second-layer policy, configure that the CIR is 100 Kbit/s and the PIR is 150
Kbit/s.
5-3

1. Run the following commands to configure interfaces:
2. Run the following commands to configure class-maps:
ZXR10(config-cmap)#match precedence 3,4
ZXR10(config)#policy-map car1
ZXR10(config)#policy-map test
5-4

ZXR10(config-pmap-c)#service-policy car1
5. Run the following command to bind the policy to the corresponding interface:
ZXR10(config)#service-policy gei-0/1/0/3 output test overwrite
Run the show class-map command to check whether the class-map configuration is correct,
match precedence 1
match precedence 2
match precedence 3
match precedence 4
match precedence 3,4
Run the show policy-map command to check whether the policy configuration is correct,
policy-map car1
class pre3
police 100000 100 150000 150
class pre4
police 100000 100 150000 150
policy-map test
class pre1
priority-llq
police 500000 500
class pre2
class pre34
service-policy car1
Run the show service-policy command to check whether interface binding is correct, which
ZXR10#show service-policy
5-5

service-policy gei-0/1/0/3 output test overwrite
5.4.2 WRED Configuration Example

This procedure describes how to configure a WRED policy on an upperstream interface
to make packets with different priorities have different dropping policies when congestion
occurs.
l The minimum dropping threshold of the queue with priority 0 is 30 kb, and the
maximum dropping threshold is 100 kb. The dropping probability is 90%. The
exponent of the average queue length is 8.
Configuration Flow
1. Create a new class-map that matches precedence 0-2.
2. Create a new policy-map, add the class matching precedence 0-2 to the policy, and
add WRED to different priority queues in the class.
3. Bind the policy-map configured in Step 2 to the incoming direction on an interface.
1. Run the following commands to configure a class-map.
ZXR10 (config)#class-map pr0-2 match-all
ZXR10 (config-cmap)#match precedence 0-2
ZXR10 (config-cmap)#exit
2. Run the following commands to configure a policy-map.
ZXR10(config)#policy-map wred
ZXR10(config-pmap)#class pr0-2
ZXR10(config-pmap-c)#random-detect enable
ZXR10(config-pmap-c)#random-detect weight 8
3. Run the following commands to bind the policy to an interface.
ZXR10(config)#service-policy gei-0/7/1/7 output wred
5-6

Run the show policy-map command to view the configuration of the policy-map, which is
ZXR10#show policy-map
policy-map wred
class pr0-2
random-detect enable
random-detect weight 8
5-7

5-8

Chapter 6
Priority Inheritance
Configuration
Table of Contents
Priority Inheritance Overview......................................................................................6-1
Configuring Priority Inheritance ..................................................................................6-2
Maintaining Priority Inheritance ..................................................................................6-3
Priority Inheritance Configuration Instances................................................................6-3
6.1 Priority Inheritance Overview

Priority inheritance is an important function of QoS. It is used to accomplish priority
inheritance among different types of packets (including common IP packets, Virtual
Local Area Network (VLAN) packets and MPLS packets), that is, the conversion among
IP-Precedence, VLAN-802.1p, and MPLS-EXP.
There are two types of priority inheritances:
l Inheritance of priority field from Layer 2 to Layer 3
It is the mapping of priority field from Layer 2 to Layer 3, realizing mapping from 802.1p
field to IPP field and MPLS-EXP field.
l Mapping from MPLS-EXP field to IP-Precedence field
This mapping conforms to the RFC standard (RFC3270). There are three modes:
à Uniform mode: On the access ingress of a Provider Edge (PE) device, IPP, and
Time To Live (TTL) are inherited to the EXP and TTL fields of a label. On the
access egress of a PE device, the EXP and TTL fields of a label are inherited to
IPP and TTL of an IP packet.
à Pipe mode: On the access ingress of a PE device, IPP and TTL are not inherited
to the EXP and TTL fields of a label. On the access egress of a PE device, EXP
field and TTL field of a label are not inherited to IPP and TTL of an IP packet.
Therefore, a packet has two inconsistent priorities. The device has to designate
a priority to be trusted during the QoS configuration. In pipe mode, when QoS is
configured on the access egress of a PE device, the MPLS-EXP field is trusted,
that is, the priority to send the packet is decided by the MPLS-EXP field.
à Short-pipe mode: On the access ingress of a PE device, IPP and TTL are not
inherited to the EXP field and TTL fields of a label. On the access egress of a
PE device, the EXP and TTL fields of a label are not inherited to IPP and TTL of
6-1

an IP packet. Therefore, a packet has two inconsistent priorities. The device has
to designate a priority to be trusted during the QoS configuration. In short-pipe
mode, when QoS is configured on the access egress of a PE device, IPP field is
trusted, that is, the priority to send the packet is decided by the IPP field.
6.2 Configuring Priority Inheritance

l To configure EXP-IPP priority inheritance and 802.1p inheritance on an interface of
the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#mls-qos-mode <interface-name>{uniform | Configures priority inheritance on a

pipe | short-pipe} designated interface.
2 ZXR10(config)#qos-dot1p <interface-name>[ cvlan-in] Configures 802.1p inheritance on a

designated interface.
3 ZXR10(config)#ttl-qos-mode <interface-name>{uniform | Configures TTL inheritance on a designated

pipe} interface.
l The following method can be used to configure EXP-IPP priority inheritance and
802.1p inheritance for packets that match flow classes in H-QoS.
à Configure flow classification. For details, refer to 3.2 Configuring Flow
Classification.
à Configure the inheritance relationship among 802.1p, MPLS-EXP and IPP.
1 ZXR10(config)#policy-map<policy-map-name> Creates a policy-map and enters policy

mapping configuration mode.
2 ZXR10(config-pmap)#class <class-map-name> Associates with a class-map and enters policy

class configuration mode.
3 ZXR10(config-pmap-c)#set {8021p | mpls-exp | Configures the inheritance relationship among

precedence} inherit-from {8021p | mpls-exp | precedence} 802.1p, MPLS-EXP and IPP.
à Bind the policy-map to an interface. For details, refer to 5.2 Configuring H-QoS.
l To configure EXP-IPP priority inheritance and TTL inheritance on a VRF interface,

perform the following steps:
1 ZXR10(config)#ip vrf <WORD> Configures a VRF example. The name length

of the example is from 1 to 32 characters.
2 ZXR10(config-vrf)#ds-mode {pipe| short-pipe| uniform } Configures the priority of the MPLS label and
the inheritance of priority field in the IP packets.
6-2

Chapter 6 Priority Inheritance Configuration
3 ZXR10(config-vrf)#ttl-mode {pipe | uniform} Configures the priority of the MPLS label and
the inheritance of ttl value in the IP packets.
6.3 Maintaining Priority Inheritance

To maintain priority inheritance on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show mls-qos-mode [<interface-name>] Displays all priority inheritance configurations

on interfaces.
ZXR10#show qos-dot1p [<interface-name>] Displays all 802.1p inheritance configurations

on interfaces.
ZXR10#show class-map [<class-map-name>] Displays all class-maps and configurations of

matching rules.
ZXR10#show policy-map [<policy-map-name>[class <class-name>]] Displays all policy-maps and configurations of

policy classes.
ZXR10#show service-policy [<interface-name>] Displays all policy bindings on interfaces.
ZXR10#show running-config hqos Displays the information of class-map and

policy-map.
ZXR10#show running-config hqos-if Displays the H-QoS policies and priority

inheritance of the binding interfaces.
6.4 Priority Inheritance Configuration Instances

6.4.1 802.1P Inheritance Configuration Example
R2 sends packets received from the VLAN sub-interface (gei-0/1.1) to map the 802.1P
from the ingress to the IPP of the egress, see Figure 6-1.
Figure 6-1 802.1P Inheritance Configuration Example
6-3

Configuration Flow
1. Create a VLAN sub-interface
2. Configure a VLAN ID
3. Configure an IP address of the VLAN sub-interface
4. Configure the 802.1P inheritance policy
Run the following commands on R2:
R2(config)#interface gei-0/1/0/1.1
R2(config-subif)#exit
R2(config)#vlan-configuration
R2(config-vlan)#interface gei-0/1/0/1.1
R2( config-subvlan-if)#encapsulation-dot1q 100
R2(config-subvlan-if)#exit
R2(config-vlan)#interface gei-0/1/1/1.1
R2(config-subvlan-if)#encapsulation-dot1q 200
R2(config-subvlan-if)#exit
R2(config-vlan)#exit
R2(config-subif)#ip address 23.22.21.1 255.255.255.0
R2(config-subif)#ip address 33.32.31.1 255.255.255.0
R2(config)#class-map child match-all
R2(config-cmap)#match child
R2(config-cmap)#exit
R2(config)#policy-map 802.1p
R2(config-pmap)#class child
R2(config-pmap-c)#set precedence inherit-from 8021p
R2(config-pmap-c)#exit
R2(config-pmap)#exit
R2(config)#service-policy gei-0/1/0/1.1 input 802.1p
Only VLAN sub-interfaces and IP addresses configuration are required for R1 and R3. The
configuration commands are omitted here.
Run the show running-config hqos command to view the configuration results on R2, which
are displayed as follows:
R2(config)#show running-config hqos
!<HQoS>
6-4

class-map child match-all

match child
!
policy-map 802.1p
class 802.1p
set precedence inherit-from 8021p
$
!
!</HQoS>
ZXR10 (config)#show running-config hqos-if
!<HQoS_IF>
service-policy gei-0/1/0/1.1 input 802.1p
!
!</HQoS_IF>
6.4.2 Pipe Mode Configuration Example

When the QoS is configured for the interface from PE to CE, the MPLS-EXP field should
be trusted, that is, the MPLS-EXP field determines the priority to send packets, see Figure
6-2.
Figure 6-2 Topology of Pipe Mode Configuration Example
In Figure 6-2, CE1 and CE2 are in the same Virtual Private Network (VPN). The loopback
address of CE1 is 100.1.1.1/32, and the loopback address of CE2 is 200.1.1.1/32. It is
required to configure VPN to make CE1 and CE2 learn the loopback route from each other.
CE1 and PE1 use the BGP protocol. CE2 and PE2 use the Open Shortest Path First
(OSPF) protocol.
For the address on each interface, refer to Table 6-1.
6-5

Table 6-1 MPLS VPN Interface Address
Device Interface Address
CE1 gei-0/1/0/1 10.1.1.2/24
gei-0/1/0/2 10.1.1.1/24
PE1
gei-0/1/0/3 10.10.12.1/24
gei-0/1/0/4 10.10.12.2/24
P
gei-0/1/0/5 10.10.23.2/24
gei-0/1/0/6 10.10.23.3/24
PE2
gei-0/1/0/7 10.10.10.1/24
CE2 gei-0/1/0/8 10.10.10.2/24
Configuration Flow
1. Configure a Layer 3 VPN
2. Configure pipe mode in vrf test1 of PE1 and vrf test1 of PE2.
Run the following commands on CE1:
CE1(config)#interface loopback1
CE1(config-if)#ip address 100.1.1.1 255.255.255.255
CE1(config-if)#exit
CE1(config)#interface gei-0/1/0/1
CE1(config-if)#exit
CE1(config)#router bgp 200
CE1(config-bgp)#network 100.1.1.1 255.255.255.255
CE1(config-bgp)#neighbor 10.1.1.1 remote-as 200
CE1(config-bgp)#exit
Run the following commands on PE1:

PE1(config)#ip vrf test1
PE1(config-vrf)#rd 100:1
PE1(config-vrf)#route-target import 100:1
PE1(config-vrf)#route-target export 100:1
PE1(config-vrf)#ds-mode pipe
PE1(config-vrf)#address-family ipv4
PE1(config-vrf-af)#exit-address-family
PE1(config-vrf)#exit
PE1(config)#interface loopback1
PE1(config-if)#ip address 10.10.1.1 255.255.255.255
PE1(config-if)#exit
6-6

PE1(config)#interface gei-0/1/0/3
PE1(config-if)#exit
PE1(config)#mpls ldp instance 1

PE1(config-ldp)#interface gei-0/1/0/3
PE1(config-ldp-if)#exit
PE1(config-ldp)#exit
PE1(config-if)#ip vrf forwarding test1
PE1(config-if)#exit
PE1(config)#router ospf 1
PE1(config-ospfv2)#router-id 10.10.1.1
PE1(config-ospfv2)#network 10.0.0.0 0.255.255.255 area 0.0.0.0
PE1(config-ospfv2)#exit
PE1(config)#router bgp 200

PE1(config-bgp)#neighbor 10.10.3.3 remote-as 200
PE1(config-bgp)#neighbor 10.10.3.3 update-source loopback1
PE1(config-bgp)#address-family ipv4 vrf test1
PE1(config-bgp-af)#redistribute connected
PE1(config-bgp-af)#neighbor 10.1.1.2 remote-as 200
PE1(config-bgp-af)#exit-address-family
PE1(config-bgp)#address-family vpnv4
PE1(config-bgp-af)#neighbor 10.10.3.3 activate
PE1(config-bgp)#exit

PE1(config-ldp)#router-id loopback1
Run the following commands on P:
P(config)#interface gei-0/1/0/4
P(config-if)#ip address 10.10.12.2 255.255.255.0
P(config-if)#exit
P(config)#mpls ldp instance 1
P(config-ldp)#interface gei-0/1/0/4
P(config-ldp-if)#exit
P(config-ldp)#exit
P(config)#interface gei-0/1/0/5
P(config-if)#exit
6-7


P(config-ldp)#interface gei-0/1/0/5
P(config-ldp-if)#exit
P(config-ldp)#exit
P(config)#interface loopback1
P(config-if)#exit
P(config)#router ospf 1
P(config-ospfv2)#network 10.0.0.0 0.0.0.255 area 0.0.0.0
P(config-ospfv2)#exit
P(config-ldp)#router-id loopback1
P(config-ldp)#exit
Run the following commands on PE2:

PE2(config)#ip vrf test1
PE2(config-vrf)#rd 100:1
PE2(config-vrf)#route-target import 100:1
PE2(config-vrf)#route-target export 100:1
PE2(config-vrf)#ds-mode pipe
PE2(config-vrf)#address-family ipv4
PE2(config-vrf-af)#exit-address-family
PE2(config-vrf)#exit
PE2(config)#interface loopback1
PE2(config-if)#exit
PE2(config-if)#exit
PE2(config-ldp)#interface gei-0/1/0/6
PE2(config-ldp-if)#exit
PE2(config-subif)#ip vrf forwarding test1
PE2(config-subif)#ip address 10.10.10.1 255.255.255.0
PE2(config-subif)#exit
PE2(config)#router ospf 1
6-8

PE2(config)#router ospf 2 vrf test1

PE2(config-ospfv2)#redistribute bgp-int
PE2(config)#router bgp 200

PE2(config-bgp)#neighbor 10.10.1.1 remote-as 200
PE2(config-bgp)#neighbor 10.10.1.1 update-source loopback1
PE2(config-bgp)#address-family ipv4 vrf test1
PE2(config-bgp-af)#redistribute ospf-int 2
PE2(config-bgp-af)#redistribute connected
PE2(config-bgp)#address-family vpnv4
PE2(config-bgp-af)#neighbor 10.10.1.1 activate
PE2(config-bgp)#exit

PE2(config-ldp)#router-id loopback1
Run the following commands on CE2:

CE2(config)#interface loopback1
CE2(config-if)#exit
CE2(config)#interface gei-0/1/0/8
CE2(config-if)#exit
CE2(config)#router ospf 1
CE2(config-ospfv2)#network 10.10.10.2 0.0.0.0 area 0
CE2(config-ospfv2)#network 200.1.1.1 0.0.0.0 area 0
CE2(config-if)#exit
Run the show ip bgp summary command to view the information of IBGP connection
between CE1 and PE1, which is displayed as follows:
CE1#show ip bgp summary
Neighbor Ver As MsgRcvd MsgSend Up/Down(s) State/PfxRcd
10.1.1.1 4 200 0 12 00:00:09 0
Run the show running-config vrf | begin ip vrf test1 command to view the interface pipe
configuration on PE1, which is displayed as follows:
PE1(config)#show running-config vrf | begin ip vrf test1
ip vrf test1
6-9

rd 100:1
route-target import 100:1
route-target export 100:1
address-family ipv4
$
！
！</VRF>
Run the show running-config vrf | begin ip vrf test1 command to view the interface pipe
configuration on PE2, which is displayed as follows:
PE2(config)#show running-config vrf | begin ip vrf test1
ip vrf test1
rd 100:1
route-target import 100:1
route-target export 100:1
address-family ipv4
$
！
！</VRF>
For changes in priority fields, see Figure 6-3.
Figure 6-3 Priority Changes in Pipe Mode
6-10

Chapter 7
QPPB Configuration
Table of Contents
QPPB Overview .........................................................................................................7-1
Configuring QPPB ......................................................................................................7-2
Maintaining QPPB ......................................................................................................7-2
QPPB Configuration Example ....................................................................................7-3
7.1 QPPB Overview

QPPB Introduction
QoS Policy Propagation through the Border Gateway Protocol (QPPB) technology is a
QoS technology deployed through Border Gateway Protocol (BGP) routing policies. On
the base of BGP routes (such as community, AS paths list, and prefix list), QPPB classifies
routes and applies different QoS policies for different classes.
In network environments with high traffic, to meet the requirements of services (such as
QoS), it is recommended to classify the traffic. However, it is impossible to classify packets
in accordance with Autonomous System (AS) path, community, and other attributes. The
configuration and modification load is too heavy to be executed. With QPPB technology,
routes can be classified in advance by setting BGP routes on BGP route senders. This
simplifies route modification on route receivers. To meet the requirements, it is necessary
to configure BGP routing policies.
QPPB Work Flow

QPPB transmits QoS policies through BGP. The principle of QPPB is as follows:
1. When BGP sends routes to neighbors, it matches routing policies first to set different
BGP route attributes for different routes. The BGP route attributes include AS_PATH,
community, and extended community.
2. When a BGP neighbor receives routes, it takes the following actions:
l Identify BGP attributes
l Set QoS attributes of the Routing Table Management (RTM) entities with BGP
attributes
l Enable QPPB on an interface
l Configure a QoS policy
3. When an interface receives and forwards traffic, it will take corresponding measures
on the QoS policy. Therefore, during the data forwarding, different QoS policies can
be used for the packets sent to the destination segments in accordance with the IP
7-1

priorities, QoS IDs and other parameters obtained from the RTM. In this way, QoS
policies are transmitted through BGP.
In fact, QPPB technology does not send QoS policies in BGP routes. Instead, it is
used to set route attributes through route classification on the route senders, and to set
QoS policies on the receivers in accordance with the route attributes of the destination
segments.
7.2 Configuring QPPB

To configure QPPB on the ZXR10 M6000, perform the following steps:
1 ZXR10(config)#qos-policy {destination | source}{ip-precedence | Enables QPPB on an interface.

qos-id}<interface-name>
2 ZXR10(config)#interface <interface-name> Enters interface configuration mode.
3 ZXR10(config-if)#qos-policy {destination | source}{ip-precedence | Enables QPPB on an interface in

qos-id} interface configuration mode.
source The source IP address used to look for the routing table.
destination The destination IP address used to look for the routing table.
ip-precedence Looking for the routing table to obtain the IP precedence value.
qos-id Looking for the routing table to obtain the QoS ID value.
<interface-name> The name of an interface on which QPPB is configured.
7.3 Maintaining QPPB

To maintain QPPB on the ZXR10 M6000, run the following commands:
Command Function
ZXR10#show qppb-groups [[by-direction { destination | source Displays QPPB configuration information

}][by-interface <interface-name>]][by-option { ip-precedence | (information can be displayed in accordance
qos-id }] with the optional keywords).
ZXR10#show running-config qppb Displays all QPPB configuration information.
ZXR10#show running-config-interface qppb [<interface-name>] Displays QPPB configuration information on an

interface.
7-2

Chapter 7 QPPB Configuration
{ destination | source } Using the destination or source IP address to look for the routing table
and display the QPPB configuration.
<interface-name> Displays the QPPB configuration in accordance with the interface

name.
{ ip-precedence | qos-id } Looking for the routing table to display the QPPB configuration with
the specific IP precedence value or QoS ID.
The following is sample output from the show qppb-groups command:

ZXR10(config)#show qppb-groups
Direction Option Interface name
--------------------------------------------------
source ip-precedence fei-0/1/0/1
source qos-id fei-0/1/0/1
Direction Displays whether the source or destination IP address is used to look

for the routing table.
Option Displays whether the IP precedence value or the QoS ID is obtained

by looking for the routing table.
Interface name Displays the name of an interface on which QPPB is configured.
7.4 QPPB Configuration Example

Two ZXR10 M6000 devices (R1 and R2) operate as PEs. R1 connects to Port 1 of
ZXR10–1, and R2 connects to Port 2 of ZXR10–2. ZXR10 devices simulate CE devices,
see Figure 7-1.
7-3

Figure 7-1 QPPB Configuration Example
Configuration targets:
1. Port2 of the ZXR10-2 advertises a tagged BGP route.
2. Port1 of the ZXR10-1 sends a flow with the advertised route as the destination address
to Port 2 on the ZXR10–2.
3. The ZXR10 M6000 executes QOS policy for the flow with the advertised route as the
destination address.
Configuration Flow
1. Enable the BGP protocol on R1 and R2.
2. Configure a BGP route with community tag 100:200 on Port 2 of the ZXR10–2 to R2.
3. Configure a QPPB policy on R1 to set the limit of the flow with community attribute
100:200 to the destination to 100 Mbps.
1. Configure an interface
Run the following commands on the interface of R1:
R1(config)#interface gei-0/3/0/3
R1(config-if)#ip address 111.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config-if)#exit
Run the following commands on the interface of R2:

R2(config-if)#exit
R2(config-if)#exit
2. Configure the BGP protocol
7-4

Chapter 7 QPPB Configuration

R1(config)#router bgp 300
R1(config-bgp)#neighbor 111.1.1.2 remote-as 200
R1(config-bgp)#neighbor 111.1.1.2 activate
R1(config-bgp)#exit

R2(config-bgp)#exit
3. Run the following commands to configure the community attribute for the sent BGP
route on R2
R2(config-bgp)#neighbor 130.1.1.28 send-community
R2(config-bgp)#exit
4. Run the following command to configure QPPB on the interface of R1
R1(config)#qos-policy destination qos-id gei-0/3/0/3
5. Run the following commands to configure a route-map on R1 to match the BGP route
with community attribute as 100:200
R1(config)#ip community-list 1 permit 100:200
R1(config)#route-map 1
R1(config-route-map)#match community-list 1
R1(config-route-map)#set qos-id 1
R1(config-route-map)#exit
6. Run the following commands to map the information of the route-map to BGP
R1(config-bgp)#table-map 1
R1(config-bgp)#exit
7. Run the following commands to configure a QoS policy on R1
R1(config)#class-map qppb match-all
R1(config-cmap)#match qos-id 1
R1(config-cmap)#exit
R1(config)#policy-map qppb
R1(config-pmap)#class qppb
R1(config-pmap-c)#police 100000 100
R1(config-pmap-c)#exit
R1(config-pmap)#exit
8. Run the following command to bind the QoS policy to an interface
R1(config)#service-policy gei-0/3/0/3 input qppb
7-5

Run the show service-policy, show policy-map and show class-map commands to check the
interface and direction bound to the policy.
R1#show service-policy
service-policy gei-0/3/0/3 input qppb
R1#show policy-map
policy-map qppb
class qppb
police 100000 100
R1#show class-map
class-map qppb match-all
match qos-group
Run the show qppb-groups command to check the QPPB policy configured on the interface.
R1#show qppb-groups
Direction Option Interface name
----------------------------------------------
destination qos-id gei-0/3/0/3
Run the show running-config community-list and show route-map commands to check the
configuration information of the IP community-list and the route-map.
R1#show running-config community-list
!<COMMUNITY>
ip community-list 1 permit 100:200
!</COMMUNITY>
R1#show route-map
[route-map 1]IP type: Not set
route-map 1 permit 10
match community-list 1
set qos-id 1
7-6

Figures
Figure 1-1 Common QoS Flow in Router Devices ..................................................... 1-4
Figure 2-1 Traffic Control Through CAR .................................................................... 2-2
Figure 2-2 CAR Configuration Example .................................................................... 2-8
Figure 3-1 ToS Field and IPv6 Traffic Class .............................................................. 3-1
Figure 3-2 Class of Packets by Using DSCP............................................................. 3-1
Figure 3-3 Exp Field in an MPLS Shim ..................................................................... 3-2
Figure 4-1 Traffic Control Through CAR .................................................................... 4-2
Figure 4-2 GTS Principle .......................................................................................... 4-3
Figure 4-3 FIFO Principle.......................................................................................... 4-5
Figure 4-4 PQ Principle............................................................................................. 4-5
Figure 4-5 CQ Principle ............................................................................................ 4-6
Figure 4-6 WFQ Principle ......................................................................................... 4-7
Figure 4-7 CBWFQ Principle..................................................................................... 4-8
Figure 4-8 Tail Drop .................................................................................................. 4-9
Figure 4-9 RED Dropping Policy ............................................................................... 4-9
Figure 4-10 WRED Principle ................................................................................... 4-10
Figure 4-11 Configuring H-QoS (L1 CBWFQ + L2 Police) ....................................... 4-25
Figure 5-1 Priority Scheduling Configuration Example .............................................. 5-3
Figure 6-1 802.1P Inheritance Configuration Example .............................................. 6-3
Figure 6-2 Topology of Pipe Mode Configuration Example ........................................ 6-5
Figure 6-3 Priority Changes in Pipe Mode............................................................... 6-10
Figure 7-1 QPPB Configuration Example .................................................................. 7-4

Figures
II

Tables
Table 6-1 MPLS VPN Interface Address ................................................................... 6-6
III

Tables
IV

Glossary
ACL
- Access Control List
AS
- Autonomous System
BGP
- Border Gateway Protocol
CAR
- Committed Access Rate
CBS
- Cell Broadcast Service
CBWFQ
- Class Based Weighted Fair Queuing
CIR
- Committed Information Rate
CQ
- Custom Queuing
DSCP
- Differentiated Services Code Point
FIFO
- First In and First Out
GTS
- Generic Traffic Shaping
H-QoS
- Hierarchical-QoS
IETF
- Internet Engineering Task Force
IP
- Internet Protocol
ISP
- Internet Service Provider
LER
- Label Edge Router
LLQ
- Low Latency Queueing

LSR
- Label Switch Router
MAC
- Medium Access Control
MPLS
- Multiprotocol Label Switching
PBS
- Peak Burst Size
PE
- Provider Edge
PIR
- Peak Information Rate
PQ
- Priority Queuing
QPPB
- QoS Policy Propagation through the Border Gateway Protocol
QoS
- Quality of Service
RED
- Random Early Detection
RTM
- Routing Table Management
TCP
- Transmission Control Protocol
TTL
- Time To Live
ToS
- Type of Service
URL
- Uniform Resource Locator
VLAN
- Virtual Local Area Network
VPN
- Virtual Private Network
WFQ
- Weighted Fair Queuing
WRED
- Weighted Random Early Detection
VI

Glossary
WRR
- Weighted Round Robin
VII

SJ-20130205142913-017-ZXR10 M6000 (V1.00.60) Carrier-Class Router Configuration Guide (QoS)

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SJ-20130205142913-017-ZXR10 M6000 (V1.00.60) Carrier-Class Router Configuration Guide (QoS)

Încărcat de

Drepturi de autor:

Formate disponibile

ZXR10 M6000

Revision No. Revision Date Revision Reason

R2.2 2012-02-28 Fourth edition

R2.0 2012-07-20 Third edition

R1.1 2012-03-30 Second edition

R1.0 2011-12-10 First edition

Serial Number: SJ-20130205142913-017

Publishing Date: 2013-02-28 (R2.2)

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Chapter 3 Flow Classification Configuration........................................... 3-1

Chapter 4 Flow Action Configuration ....................................................... 4-1

Chapter 5 H-QoS Configuration ................................................................ 5-1

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Chapter 6 Priority Inheritance Configuration........................................... 6-1

Chapter 7 QPPB Configuration ................................................................. 7-1

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

What Is in This Manual

1, QoS Overview Describes an overview of QoS, differences between integrated

2, CAR Configuration Describes the principle, configuration commands, maintenance

3, Flow Classification Describes the Flow Classification principle, configuration commands,

4, Flow Action Configuration Describes the principle, configuration commands, maintenance

5, H-QoS Configuration Describes the principle, configuration commands, maintenance

6, Priority Inheritance Describes the principle, configuration commands, maintenance

7, QPPB Configuration Describes the principle, configuration commands, maintenance

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

| Separates individual parameter in series of parameters.

Danger: indicates an imminently hazardous situation. Failure to comply can result in

Warning: indicates a potentially hazardous situation. Failure to comply can result in

Caution: indicates a potentially hazardous situation. Failure to comply can result in

Note: provides additional information about a certain topic.

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Integrated Service and Differentiated Service

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Common packet classification basis include physical interface, sub-interface, PVC,

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Figure 1-1 Common QoS Flow in Router Devices

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

2.1 CAR Overview

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

Figure 2-1 Traffic Control Through CAR

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

2.2 TrTCM Overview

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

2. If Tc (t) - B < 0, the packet is colored in yellow, and Tp is reduced by B.

2.3 Configuring CAR

Step Command Function

1 ZXR10(config)#qos Enters QoS configuration mode.

2 ZXR10(config-qos)#interface <interface-name> Enters QoS interface configuration

3 ZXR10(config-qos-if)#rate-limit {input | output}{unicast | broadcast Applies CAR on an interface and

ZXR10(config-qos-if)#rate-limit {input | output}{ipv4 | ipv6}{dscp Applies CAR on an interface and

Parameter descriptions are as follows:

input | output Input/Output interface.

ipv4 | ipv6 On the basic of IPv4 or IPv6.

loaclport Local port.

SJ-20130205142913-017|2013-02-28 (R2.2) ZTE Proprietary and Confidential

broadcast L2 VPN broadcast traffic.

unicast L2 VPN unicast traffic.

unknown L2 VPN unknown traffic.

cir <cir-value> CIR value.

cbs <cbs-value> CBS value.

pir <pir-value> PIR value.

pbs <pbs-value> PBS value.

dscp <dscp-value> DSCP value.