ACL and QoS Configuration Guide

H3C SR8800 10G Core Routers
ACL and QoS Configuration Guide
Hangzhou H3C Technologies Co., Ltd.

http://www.h3c.com
Software version: SR8800-CMW520-R3347

Document version: 6W103-20120224
Copyright 2011-2012, Hangzhou H3C Technologies Co., Ltd. and its licensors
All rights reserved
No part of this manual may be reproduced or transmitted in any form or by any means without prior
written consent of Hangzhou H3C Technologies Co., Ltd.
Trademarks
H3C, , Aolynk, , H3Care, , TOP G, , IRF, NetPilot, Neocean, NeoVTL,

SecPro, SecPoint, SecEngine, SecPath, Comware, Secware, Storware, NQA, VVG, V2G, VnG, PSPT,
XGbus, N-Bus, TiGem, InnoVision and HUASAN are trademarks of Hangzhou H3C Technologies Co.,
Ltd.
All other trademarks that may be mentioned in this manual are the property of their respective owners
Notice
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Preface
The H3C SR8800 documentation set includes 13 configuration guides, which describe the software
features for the H3C SR8800 10G Core Routers and guide you through the software configuration
procedures. These configuration guides also provide configuration examples to help you apply software
features to different network scenarios.
The ACL and QoS Configuration Guide describes ACL and QoS fundamentals and configurations. It
describes how to use ACLs or other match criteria to classify traffic into multiple classes and implement
per-class traffic control. ACL and QoS help you allocate limited network resources reasonably and
improve the network utilization. You can use HQoS to control internal resources of a router based on
policies. HQoS guarantees QoS for advanced users and saves the overall networking costs.
This preface includes:
Audience
Conventions
About the H3C SR8800 documentation set
Obtaining documentation
Technical support
Documentation feedback
Audience
This documentation is intended for:
Network planners
Field technical support and servicing engineers
Network administrators working with the SR8800 series
Conventions
This section describes the conventions used in this documentation set.
Command conventions
Convention Description
Boldface Bold text represents commands and keywords that you enter literally as shown.
Italic Italic text represents arguments that you replace with actual values.
[] Square brackets enclose syntax choices (keywords or arguments) that are optional.
Braces enclose a set of required syntax choices separated by vertical bars, from which
{ x | y | ... }
you select one.
Square brackets enclose a set of optional syntax choices separated by vertical bars, from
[ x | y | ... ]
which you select one or none.
Asterisk marked braces enclose a set of required syntax choices separated by vertical
{ x | y | ... } *
bars, from which you select at least one.
Asterisk marked square brackets enclose optional syntax choices separated by vertical
[ x | y | ... ] *
bars, from which you select one choice, multiple choices, or none.
The argument or keyword and argument combination before the ampersand (&) sign can
&<1-n>
be entered 1 to n times.
# A line that starts with a pound (#) sign is comments.
GUI conventions
Window names, button names, field names, and menu items are in Boldface. For
Boldface
example, the New User window appears; click OK.
> Multi-level menus are separated by angle brackets. For example, File > Create > Folder.
Symbols
An alert that calls attention to important information that if not understood or followed can
WARNING result in personal injury.
An alert that calls attention to important information that if not understood or followed can
CAUTION result in data loss, data corruption, or damage to hardware or software.
IMPORTANT An alert that calls attention to essential information.
NOTE An alert that contains additional or supplementary information.
TIP An alert that provides helpful information.
Network topology icons
Represents a generic network device, such as a router, switch, or firewall.
Represents a routing-capable device, such as a router or Layer 3 switch.
Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports
Layer 2 forwarding and other Layer 2 features.
Port numbering in examples

The port numbers in this document are for illustration only and might be unavailable on your router.
About the H3C SR8800 documentation set

The H3C SR8800 documentation set includes:
Category Documents Purposes
Product description and Marketing brochures Describe product specifications and benefits.
Category Documents Purposes
specifications Provide an in-depth description of software features
Technology white papers
and technologies.
Card datasheets Describe card specifications, features, and standards.
Compliance and safety Provides regulatory information and the safety

manual instructions that must be followed during installation.
Provides a complete guide to hardware installation

Installation guide
and hardware specifications.
H3C N68 Cabinet

Guides you through installing and remodeling H3C
Installation and Remodel
N68 cabinets.
Hardware specifications Introduction
and installation
H3C Pluggable SFP
[SFP+][XFP] Transceiver Guides you through installing SFP/SFP+/XFP
Modules Installation transceiver modules.
Guide
H3C High-End Network Describes the hot-swappable modules available for

Products Hot-Swappable the H3C high-end network products, their external
Module Manual views, and specifications.
Describe software features and configuration

Configuration guides
Software configuration procedures.
Command references Provide a quick reference to all available commands.
Provide information about the product release,

including the version history, hardware and software
Operations and
Release notes compatibility matrix, version upgrade information,
maintenance
technical support information, and software
upgrading.
Obtaining documentation
You can access the most up-to-date H3C product documentation on the World Wide Web
at http://www.h3c.com.
Click the links on the top navigation bar to obtain different categories of product documentation:
[Technical Support & Documents > Technical Documents] Provides hardware installation, software
upgrading, and software feature configuration and maintenance documentation.
[Products & Solutions] Provides information about products and technologies, as well as solutions.
[Technical Support & Documents > Software Download] Provides the documentation released with the
software version.
Technical support
service@h3c.com
http://www.h3c.com
Documentation feedback
You can e-mail your comments about product documentation to info@h3c.com.
We appreciate your comments.
Contents
Configuring ACLs 1
ACL overview 1
ACL categories 1
ACL numbering and naming 1
Match order 2
ACL rule numbering 3
Implementing time-based ACL rules3
IPv4 fragments filtering with ACLs 3
Flow templates 4
ACL application 4
ACL configuration task list 5
Configuring an ACL 5
Configuring a time range 5
Configuring a basic ACL 6
Configuring an advanced ACL 8
Configuring an Ethernet frame header ACL 10
Configuring a user-defined ACL 10
Copying an ACL 11
Configuring a flow template 12
Configuring an ACL rule length limit mode 13
Displaying and maintaining ACLs 13
ACL configuration examples 14
IPv4 ACL configuration example 14
IPv6 ACL configuration example 16
Flow template configuration example 17
ACL rule length limit mode configuration example 17
QoS overview 19
Introduction to QoS 19
Networks without QoS guarantee 19
QoS requirements of new applications 19
Congestion: causes, impacts, and countermeasures 20
Causes 20
Impacts 20
Countermeasures 20
Major traffic management technologies 21
Configuring traffic shaping and line rate 22

Traffic shaping overview 22
Traffic evaluation and token bucket 22
Traffic shaping configuration 25
Configuring traffic shaping 25
Displaying and maintaining GTS 26
Traffic shaping configuration example 27
Line rate configuration 27
Configuring the line rate 27
Displaying and maintaining line rate 28
Line rate configuration example 28
i
Configuring a QoS policy 29
QoS policy overview 29
Traffic classification overview 29
Traffic classification 29
Packet precedences 30
QoS policy configuration procedure 32
Defining a class 32
Defining a traffic behavior 33
Defining a policy 34
Applying the QoS policy 35
QoS policy configuration example 36
Displaying and maintaining QoS policies 37
Configuring hardware congestion management 38

Congestion management overview 38
Causes, impacts, and countermeasures of congestion 38
Congestion management policies 38
Weighted fair queuing 39
CBQ 40
Configuring WFQ queuing 40
Configuration procedure 40
Configuration example 41
Configuring CBQ 41
Defining a class 41
Defining a traffic behavior 42
Defining a QoS policy 43
Applying the QoS policy 43
Displaying and maintaining CBQ 44
CBQ configuration example 44
Configuring priority mapping 48

Priority mapping overview 48
Configuring a priority mapping table 49
Configuration prerequisites 49
Changing the port priority of a port 51
Configuring the port to trust packet priority for priority mapping 52
Displaying and maintaining priority mapping 52
Priority mapping configuration example 53
Configuring congestion avoidance 55

Congestion avoidance overview 55
Introduction to WRED configuration 56
Configuration methods 56
Introduction to wred parameters 56
Configuring and applying a WRED table on an interface 57
Configuring and applying a queue-based wred table 57
Displaying and maintaining WRED 57
WRED configuration example 58
ii
Configuring aggregation CAR 59
Aggregation CAR overview 59
Referencing aggregation CAR in a traffic behavior 59
Displaying and maintaining aggregation CAR 60
Configuring a queue scheduling profile 61

Introduction to queue scheduling profile 61
Configuring a queue scheduling profile 61
Displaying and maintaining queue scheduling profiles 62
Queue scheduling profile configuration example 63
Configuring QoS traffic accounting 64

QoS traffic accounting overview 64
Per-port queue-based accounting overview 64
Configuring traffic accounting 64
Displaying and maintaining traffic accounting and per-port queue-based accounting 64
Configuring FR QoS 66
Overview 66
Why FRTS 66
How FRTS works 66
Configuring FR QoS 67
FR QoS configuration task list 67
Creating and configuring an FR class 67
Configuring FRTS 68
Displaying and maintaining FR QoS 69
FR QoS configuration example 69
FRTS configuration example 69
Configuring HQoS 71
HQoS overview 71
Introduction to HQoS 71
How HQoS works 71
Terminology 72
HQoS configuration task list 73
HQoS basic configuration 75
Configuring an forwarding class 75
Configuring a drop profile 75
Configuring an forwarding profile 76
Configuring an forwarding group 78
Configuring an scheduler policy 80
Instantiating an forwarding group 81
Applying an scheduler policy to an interface 83
Copying an forwarding group or scheduler policy 84
Copying an forwarding group 84
Copying an scheduler policy 85
Displaying and maintaining HQoS 85
HQoS configuration examples 85
HQoS configuration example I 86
HQoS configuration example II 92
Index 98
iii
Configuring ACLs
NOTE:
Unless otherwise stated, ACLs refer to both IPv4 and IPv6 ACLs throughout this document.
In this documentation, SPC cards refer to the cards prefixed with SPC, for example, SPC-GT48L. SPE
cards refer to the cards prefixed with SPE, for example, SPE-1020-E-II.
ACL overview
An access control list (ACL) is a set of rules (or permit or deny statements) for identifying traffic based on
criteria such as source IP address, destination IP address, and port number.
ACLs are primarily used for packet filtering. A packet filter drops packets that match a deny rule and
permits packets that match a permit rule. ACLs are also used by many modules, for example, QoS and
IP routing, for traffic identification.
ACL categories
Category ACL number IP version Match criteria
IPv4 Source IPv4 address
Basic ACLs 2000 to 2999
IPv6 Source IPv6 address
Source IPv4 address, destination IPv4 address,

IPv4 protocols over IPv4, and other Layer 3 and Layer
4 header fields
Advanced ACLs 3000 to 3999
Source IPv6 address, destination IPv6 address,
IPv6 protocols over IPv6, and other Layer 3 and Layer
4 header fields
Layer 2 header fields, such as source and

Ethernet frame
4000 to 4999 IPv4 and IPv6 destination MAC addresses, 802.1p priority,
header ACLs
and link layer protocol type
User-defined User specified matching patterns in protocol (for

5000 to 5999 IPv4 and IPv6
ACLs example, IP and MPLS) headers
ACL numbering and naming

Each ACL category has a unique range of ACL numbers. When creating an ACL, you must assign it a
number for identification. In addition, you can assign the ACL a name for the ease of identification. After
creating an ACL with a name, you cannot rename it or delete its name.
For an Ethernet frame header, or user-defined ACL, the ACL number and name must be globally unique.
For an IPv4 basic or advanced ACL, its ACL number and name must be unique among all IPv4 ACLs, and
1
for an IPv6 basic or advanced ACL, among all IPv6 ACLs. You can assign an IPv4 ACL the same number
and name as an IPv6 ACL.
Match order
The rules in an ACL are sorted in certain order. When a packet matches a rule, the device stops the
match process and performs the action defined in the rule. If an ACL contains overlapping or conflicting
rules, the matching result and action to take depend on the rule order.
The following ACL match orders are available:
configSorts ACL rules in ascending order of rule ID. A rule with a lower ID is matched before a
rule with a higher ID. If you use this approach, check the rule content and order carefully.
autoSorts ACL rules in depth-first order. Depth-first ordering guarantees that any subset of a rule
is always matched before the rule. Table 1 lists the sequence of tie breakers that depth-first ordering
uses to sort rules for each type of ACL.
NOTE:
The match order of user-defined ACLs can only be config.
Table 1 Sort ACL rules in depth-first order
ACL category Sequence of tie breakers

1. VPN instance
2. More 0s in the source IP address wildcard (more 0s means a narrower IP
IPv4 basic ACL
address range)
3. Smaller rule ID
4. VPN instance
5. Specific protocol type rather than IP (IP represents any protocol over IP)
6. More 0s in the source IP address wildcard mask
IPv4 advanced ACL
7. More 0s in the destination IP address wildcard
8. Narrower TCP/UDP service port number range
9. Smaller ID
10. VPN instance
11. Longer prefix for the source IP address (a longer prefix means a narrower IP
IPv6 basic ACL
address range)
12. Smaller ID
13. VPN instance
14. Specific protocol type rather than IP (IP represents any protocol over IPv6)
15. Longer prefix for the source IPv6 address
IPv6 advanced ACL
16. Longer prefix for the destination IPv6 address
17. Narrower TCP/UDP service port number range
18. Smaller ID
19. More 1s in the source MAC address mask (more 1s means a smaller MAC
address)
Ethernet frame header ACL
20. More 1s in the destination MAC address mask
21. Smaller ID
2
NOTE:
A wildcard mask, also called an inverse mask, is a 32-bit binary and represented in dotted decimal
notation. In contrast to a network mask, the 0 bits in a wildcard mask represent 'do care' bits, and the 1
bits represent 'dont care' bits. If the 'do care' bits in an IP address are identical to the 'do care' bits in an
IP address criterion, the IP address matches the criterion. All 'dont care' bits are ignored. The 0s and 1s
in a wildcard mask can be noncontiguous. For example, 0.255.0.255 is a valid wildcard mask.
ACL rule numbering

What is the ACL rule numbering step
If you do not assign an ID to the rule you are creating, the system automatically assigns it a rule ID. The
rule numbering step sets the increment by which the system automatically numbers rules. For example, the
default ACL rule numbering step is 5. If you do not assign IDs to rules you are creating, they are
numbered 0, 5, 10, 15, and so on. The wider the numbering step, the more rules you can insert between
two rules.
By introducing a gap between rules rather than contiguously numbering rules, you have the flexibility of
inserting rules in an ACL. This feature is important for a config order ACL, where ACL rules are matched
in ascending order of rule ID.
Automatic rule numbering and renumbering

The ID automatically assigned to an ACL rule takes the nearest higher multiple of the numbering step to
the current highest rule ID, starting with 0.
For example, if the numbering step is 5 (the default), and there are five ACL rules numbered 0, 5, 9, 10,
and 12, the newly defined rule will be numbered 15. If the ACL does not contain any rule, the first rule will
be numbered 0.
Whenever the step changes, the rules are renumbered, starting from 0. For example, if there are five rules
numbered 5, 10, 13, 15, and 20, changing the step from 5 to 2 causes the rules to be renumbered 0, 2,
4, 6 and 8.
Implementing time-based ACL rules

You can implement ACL rules based on the time of day by applying a time range to them. A time-based
ACL rule takes effect only in any time periods specified by the time range.
The following basic types of time range are available:
Periodic time rangeRecurs periodically on a day or days of the week.
Absolute time rangeRepresents only a period of time and does not recur.
You may apply a time range to ACL rules before or after you create it. However, the rules using the time
range can take effect only after you define the time range.
IPv4 fragments filtering with ACLs

Traditional packet filtering matches only first fragments of IPv4 packets, and allows all subsequent
non-first fragments to pass through. Attackers can fabricate non-first fragments to attack networks.
To avoids the risks, the H3C ACL implementation:
Filters all fragments by default, including non-first fragments.
3
Provides ACL-based firewalls with standard and exact match modes for matching ACLs that contain
advanced attributes such as TCP/UDP port number and ICMP type. Standard match is the default
mode. It considers only Layer 3 attributes. Exact match considers all header attributes defined in
IPv4 ACL rules. For more information, see Security Configuration Guide.
Flow templates
Flow templates are sets of criteria based on header fields such as source IP address, destination IP
address, source TCP port, and destination TCP port. Flow templates apply only to hardware-based ACLs.
You use a flow template to limit the match criteria that can be applied to an interface. ACL rules that
contain any criterion beyond the flow template on an interface cannot be assigned to hardware.
There are default flow templates and user-defined templates, where a user-defined template can be basic
or extended. By default, an interface uses the default flow template.
ACL application
You can use ACLs in QoS, packet-filter firewall, routing, and other technologies for identifying traffic. For
examples of ACL application, see ACL configuration examples.
1. The inbound packet-filter firewall, policy-based routing (PBR), and QoS policy on an interface
process an incoming packet as shown in Figure 1.
Figure 1 Incoming packet processing procedure
An incoming packet
arrives
Packet-filter firewall
Yes
Match a deny rule? Drop
No
PBR
Yes Process the

Match an ACL rule?
packet
No
QoS policy
2. The outbound packet-filter firewall and QoS policy on an interface process an outgoing packet as
shown in Figure 2.
4
Figure 2 Outgoing packet processing procedure
An outgoing packet
arrives
Packet-filter firewall
deny permit
rule rule
Drop Find a match? Forward
No
QoS policy
For information about packet-filter firewall configuration, see Security Configuration Guide. For
information about policy-based routing, see Layer 3IP Routing Configuration Guide. For information
about and QoS policy configuration, see the chapter " Configuring a QoS policy."
ACL configuration task list

Complete the following tasks to configure an ACL:
Task Remarks
Optional
Configuring a time range
Applicable to IPv4 and IPv6 ACLs.
Configuring a basic ACL

Required
Configuring an advanced ACL
Configure at least one task.
Configuring an Ethernet frame header ACL
Configuring a user-defined ACL
Optional
Copying an IPv4 ACL
Optional
Configuring a flow template
Configuring an ACL
Configuring a time range
To configure a time range:
Step Command Remarks

1. Enter system view. system-view N/A
5
time-range time-range-name By default, no time range exists.
{ start-time to end-time days [ from Repeat this command with the
2. Configure a time range. time1 date1 ] [ to time2 date2 ] | same time range name to create
from time1 date1 [ to time2 date2 ] multiple statements for a time
| to time2 date2 } range.
You can create multiple statements in a time range. The active period of a time range is calculated as
follows:
1. Combining all periodic statements
2. Combining all absolute statements
3. Taking the intersection of the two statement sets as the active period of the time range
You can create a maximum of 256 time ranges, each with a maximum of 32 periodic statements and 12
absolute statements.
Configuring a basic ACL

Configuring an IPv4 basic ACL
IPv4 basic ACLs match packets based only on source IP addresses.
To configure an IPv4 basic ACL:

By default, no ACL exists.

IPv4 basic ACLs are numbered in the
acl number acl-number [ name
2. Create an IPv4 basic ACL range 2000 to 2999.
acl-name ] [ match-order { auto |
and enter its view. You can use the acl name acl-name
config } ]
command to enter the view of a named
IPv4 ACL.
Optional.
3. Configure a description
description text By default, an IPv4 basic ACL has no
for the IPv4 basic ACL.
ACL description.
4. Set the rule numbering Optional.

step step-value
step. The default setting is 5.
By default, an IPv4 basic ACL does not

rule [ rule-id ] { deny | permit } contain any rule.
[ counting | fragment | logging | To create or edit multiple rules, repeat
source { sour-addr sour-wildcard | this step.
5. Create or edit a rule.
any } | time-range The logging keyword takes effect only
time-range-name | vpn-instance when the module (for example, a
vpn-instance-name ] * packet-filter firewall) that uses the ACL
supports logging.
Optional.
6. Configure or edit a rule
rule rule-id comment text By default, an IPv4 ACL rule has no rule
description.
description.
6
7. Enable rule match Optional.
counting for the IPv4 hardware-count enable By default, rule match counting is
basic ACL. disabled.
Configuring an IPv6 basic ACL

To configure an IPv6 basic ACL:


IPv6 basic ACLs are numbered in
acl ipv6 number acl6-number
2. Create an IPv6 basic ACL the range 2000 to 2999.
[ name acl6-name ] [ match-order
view and enter its view. You can use the acl ipv6 name
{ auto | config } ]
acl6-name command to enter the
view of a named IPv6 ACL.
Optional.
3. Configure a description for
description text By default, an IPv6 basic ACL has
the IPv6 basic ACL.
no ACL description.
Optional.
4. Set the rule numbering step. step step-value
The default setting is 5.
By default, an IPv6 basic ACL does

rule [ rule-id ] { deny | permit } not contain any rule.
[ counting | fragment | logging |
To create or edit multiple rules,
source { ipv6-address prefix-length
repeat this step.
5. Create or edit a rule. | ipv6-address/prefix-length |
any } | time-range The logging keyword takes effect
time-range-name | vpn-instance only when the module (for
vpn-instance-name ] * example, a packet-filter firewall)
using the ACL supports logging.
Optional.
rule rule-id comment text By default, an IPv6 basic ACL rule
description.
has no rule description.
Optional.
7. Enable rule match counting
hardware-count enable By default, rule match counting is
for the IPv6 basic ACL.
disabled.
NOTE:
When configuring IPv6 basic ACLs for a QoS policy that is to be applied to an SPC card, you must set the
ACL rule length limit to 80 bytes. For more information about the ACL rule length limit, see ACL and QoS
Command Reference.
7
Configuring an advanced ACL
Configuring an IPv4 advanced ACL
IPv4 advanced ACLs match packets based on source and destination IP addresses, protocols over IP, and
other protocol header information, such as TCP/UDP source and destination port numbers, TCP flags,
ICMP message types, and ICMP message codes.
IPv4 advanced ACLs also allow you to filter packets based on these priority criteria: type of service (ToS),
IP precedence, and differentiated services codepoint (DSCP) priority.
Compared to IPv4 basic ACLs, IPv4 advanced ACLs allow more flexible and accurate filtering.
To configure an IPv4 advanced ACL:


IPv4 advanced ACLs are
acl number acl-number [ name numbered in the range 3000 to
2. Create an IPv4 advanced
acl-name ] [ match-order { auto | 3999.
ACL and enter its view.
config } ] You can use the acl name acl-name
command to enter the view of a
named IPv4 ACL.
Optional.
description text By default, an IPv4 advanced ACL
the IPv4 advanced ACL.
has no ACL description.
Optional.
rule [ rule-id ] { deny | permit }

protocol [ { { ack ack-value | fin
fin-value | psh psh-value | rst
rst-value | syn syn-value | urg
urg-value } * | established } | By default, an IPv4 advanced ACL
counting | destination { dest-addr does not contain any rule.
dest-wildcard | any } |
destination-port operator port1
repeat this step.
5. Create or edit a rule. [ port2 ] | dscp dscp | fragment |
icmp-type { icmp-type [ icmp-code ] The logging keyword takes effect
| icmp-message } | logging | only when the module (for
precedence precedence | reflective example, a packet-filter firewall)
| source { sour-addr sour-wildcard using the ACL supports logging.
| any } | source-port operator
port1 [ port2 ] | time-range
time-range-name | tos tos |
vpn-instance vpn-instance-name ] *
Optional.
rule rule-id comment text By default, an IPv4 advanced ACL
description.
rule has no rule description.
8
Optional.
for the IPv4 advanced ACL.
disabled.
Configuring an IPv6 advanced ACL

IPv6 advanced ACLs match packets based on the source IPv6 address, destination IPv6 address,
protocol carried over IPv6, and other protocol header fields such as the TCP/UDP source port number,
TCP/UDP destination port number, ICMP message type, and ICMP message code.
Compared to IPv6 basic ACLs, IPv6 advanced ACLs allow more flexible and accurate filtering.
To configure an IPv6 advanced ACL:


IPv6 advanced ACLs are
acl ipv6 number acl6-number [ name numbered in the range 3000 to
2. Create an IPv6 advanced
acl6-name ] [ match-order { auto | 3999.
ACL and enter its view.
config } ] You can use the acl ipv6 name
acl6-name command to enter the
view of a named IPv6 ACL.
3. Configure a description Optional.

for the IPv6 advanced description text By default, an IPv6 advanced
ACL. ACL has no ACL description.
4. Set the rule numbering Optional.

step step-value
step. The default setting is 5.
rule [ rule-id ] { deny | permit } protocol

[ { { ack ack-value | fin fin-value | psh
psh-value | rst rst-value | syn syn-value |
urg urg-value } * | established } | By default IPv6 advanced ACL
counting | destination { dest dest-prefix | does not contain any rule.
dest/dest-prefix | any } |
destination-port operator port1 [ port2 ]
repeat this step.
5. Create or edit a rule. | dscp dscp | flow-label flow-label-value
| fragment | icmp6-type { icmp6-type The logging keyword takes effect
icmp6-code | icmp6-message } | only when the module (for
logging | source { source source-prefix | example, a packet-filter firewall)
source/source-prefix | any } | using the ACL supports logging.
source-port operator port1 [ port2 ] |
time-range time-range-name |
vpn-instance vpn-instance-name ] *
Optional.
rule rule-id comment text By default, an IPv6 advanced
description.
ACL rule has no rule description.
7. Enable rule match Optional.

counting for the IPv6 hardware-count enable By default, rule match counting is
advanced ACL. disabled.
9
NOTE:
When configuring IPv6 advanced ACLs for a QoS policy that is to be applied to an SPC card, you must set
the ACL rule length limit to 80 bytes. For more information about the ACL rule length limit, see ACL and
QoS Command Reference.
Configuring an Ethernet frame header ACL

Ethernet frame header ACLs, also called "Layer 2 ACLs," match packets based on Layer 2 protocol
header fields such as source MAC address, destination MAC address, 802.1p priority (VLAN priority),
and link layer protocol type.
To configure an Ethernet frame header ACL:


Ethernet frame header ACLs are
numbered in the range 4000 to
2. Create an Ethernet frame acl number acl-number [ name
4999.
header ACL and enter its acl-name ] [ match-order { auto |
view. config } ] You can use the acl name acl-name
named Ethernet frame header
ACL.
Optional.
the Ethernet frame header description text By default, an Ethernet frame
ACL. header ACL has no ACL
description.
Optional.
rule [ rule-id ] { deny | permit } [ cos

vlan-pri | counting | dest-mac
By default, an Ethernet frame
dest-addr dest-mask | { lsap
header ACL does not contain any
lsap-type lsap-type-mask | type
5. Create or edit a rule. rule.
protocol-type protocol-type-mask }
| source-mac sour-addr To create or edit multiple rules,
source-mask | time-range repeat this step.
time-range-name ] *
Optional.
6. Configure or edit a rule By default, an Ethernet frame
rule rule-id comment text
description. header ACL rule has no rule
description.
7. Enable rule match counting Optional.

for the Ethernet frame header hardware-count enable By default, rule match counting is
ACL. disabled.
Configuring a user-defined ACL
10
NOTE:
This feature is available only on SPC cards.
User-defined ACLs allow you to customize rules based on information in protocol headers such as the IP
header. You can define a user-defined ACL to deny or permit packets in which a specific number of bytes
after the specified offset (relative to the specified header), matches the specified match pattern after
being ANDed with a match pattern mask.
To configure a user-defined ACL:

2. Set the ACL rule length limit
acl mode { 3 | 4 } The default setting is 2.
mode.
By default, no ACL exists, and the
match order of a user-defined ACL
is config.
3. Create a user-defined ACL acl number acl-number [ name User-defined ACLs are numbered
and enter its view. acl-name ] in the range 5000 to 5999.
You can use the acl name acl-name
user-defined ACL.
Optional.
description text By default, a user-defined ACL has
the user-defined ACL.
no ACL description.
rule [ rule-id ] { deny | permit } By default, a user-defined ACL

[ { { ipv4 | ipv6 | l2 | l4 } rule-string does not contain any rule.
5. Create or edit a rule. rule-mask offset }&<1-8> ]
[ counting | time-range To create or edit multiple rules,
time-range-name ] * repeat this step.
Optional.
rule rule-id comment text By default, a user-defined ACL rule
description.
has no rule description.
Optional.
for the user-defined ACL.
disabled.
Copying an ACL
You can create an ACL by copying an existing ACL. The new ACL has the same properties and content
as the source ACL, but not the same ACL number and name.
To successfully copy an ACL, make sure that:
The destination ACL number is from the same category as the source ACL number.
The source ACL already exists but the destination ACL does not.
Copying an IPv4 ACL

To copy an IPv4 ACL:
11
Step Command
1. Enter system view. system-view
2. Copy an existing IPv4 ACL to create a new IPv4 acl copy { source-acl-number | name source-acl-name }
ACL. to { dest-acl-number | name dest-acl-name }
Copying an IPv6 ACL

To copy an IPv6 ACL:
Step Command
acl ipv6 copy { source-acl6-number | name

2. Copy an existing IPv6 ACL to generate a new
source-acl6-name } to { dest-acl6-number | name
one of the same category.
dest-acl6-name }
Configuring a flow template

NOTE:
This feature is available only on SPE cards.
To create a flow template and apply it to an interface:

flow-template flow-template-name
basic { customer-vlan-id | dip |
dmac | dport | dscp |
ethernet-protocol | fragments |
2. Create a flow template. N/A
icmp-code | icmp-type |
ip-precedence | ip-protocol |
mpls-exp | service-cos | sip | smac
| sport | tcp-flag | tos } *
Enter interface view:

interface interface-type
interface-number
3. Enter interface view or port group view. N/A
Enter port group view:
port-group manual
port-group-name
Optional.
4. Apply the flow template to the interface
flow-template flow-template-name The default one applies
or port group.
by default.
12
NOTE:
The user-defined flow template you are applying to an interface must already exist.
You can apply only one user-defined flow template on an interface.
The default flow template defines five fields: the source IP address, destination IP address, source port
number, destination port number, and protocol type.
When the length limit for the match criteria in an ACL rule is 18 bytes for an SPE card, available
parameters of the default flow template are sip, dip, ip-protocol, sport, and dport.
When the length limit for the match criteria in an ACL rule is 36 bytes for an SPE card, available
parameters of the default flow template are sip, dip, ip-protocol, sport, dport, icmp-code, icmp-type,
tos, dscp, ip-precedence, mpls-exp, tcp-flag, and fragment.
Configuring an ACL rule length limit mode

The ACL rule length limit mode defines the length of the fields available for an ACL flow template. When
a large number of ACL rules are required on the router, you may need to change this mode.
To configure an ACL rule length limit mode:

2. Set the ACL rule

acl mode { 1 | 2 | 3 | 4 } The default setting is 2.
length limit mode.
NOTE:
The limit mode setting is saved automatically, but it takes effect only after you restart your router.
The limit mode setting does not take effect on an SPE card with an ATM subcard.
The limit mode setting does not take effect for IPv6 ACLs on an SPE card.
When configuring IPv6 ACLs for a QoS policy that is to be applied to an SPC card, you must set the ACL
rule length limit to 80 bytes. For more information about the ACL rule length limit, see ACL and QoS
Command Reference.
Displaying and maintaining ACLs

Task Command Remarks
display acl { acl-number | all | name
Display configuration and match
acl-name } [ | { begin | exclude | include } Available in any view
statistics for one or all IPv4 ACLs.
regular-expression ]
display acl ipv6 { acl6-number | all | name

Display configuration and match
acl6-name } [ | { begin | exclude | include } Available in any view
statistics for one or all IPv6 ACLs.
Display the ACL rule length limit display acl mode [ | { begin | exclude |
Available in any view
mode. include } regular-expression ]
13
display acl resource [ | { begin | exclude |
Display the usage of ACL rules. Available in any view
include } regular-expression ]
display flow-template interface [ interface-type

Display information about flow
interface-number ] [ | { begin | exclude | Available in any view
templates applied to interfaces.
display flow-template user-defined

Display the configuration of one or
[ flow-template-name ] [ | { begin | exclude | Available in any view
all user-defined flow templates.
display time-range { time-range-name | all }

Display the configuration and
[ | { begin | exclude | include } Available in any view
status of one or all time ranges.
Clear statistics for one or all IPv4 reset acl counter { acl-number | all | name
Available in user view
ACLs. acl-name }
Clear statistics for one or all IPv6 reset acl ipv6 counter { acl6-number | all |
Available in user view
basic and advanced ACLs. name acl6-name }
ACL configuration examples

IPv4 ACL configuration example
Network requirements
A company interconnects its departments through Device A. Configure an ACL to:
Permit access from the President's office at any time to the salary server.
Deny access from any other department to the salary server from 8:00 to 18:00.
Figure 3 Network diagram
Configuration procedure
1. Create a time range for office hours:
14
# Create a periodic time range spanning 8:00 to 18:00 in working days.
<Device> system-view
[Device] time-range trname 8:00 to 18:00 working-day
2. Configure an ACL to control accesses to the salary server:
# Create and enter the view of advanced IPv4 ACL 3000.
[Device] acl number 3000
# Create a rule to control access of the Presidents Office to the salary server.
[Device-acl-adv-3000] rule 1 permit ip source 129.111.1.2 0.0.0.0 destination
129.110.1.2 0.0.0.0
[Device-acl-adv-3000] quit
# Create and enter the view of advanced IPv4 ACL 3100.
[Device] acl number 3100
# Create a rule to control accesses of other departments to the salary server.
[Device-acl-adv-3100] rule 2 permit ip source any destination 129.110.1.2 0.0.0.0
time-range trname
[Device-acl-adv-3100] quit
3. Apply the ACL:
# Configure traffic classification.
[Device] traffic classifier c1
[Device-classifier-c1] if-match acl 3000
[Device-classifier-c1] quit
[Device] traffic classifier c2
[Device-classifier-c2] if-match acl 3100
[Device-classifier-c2] quit
4. Configure traffic behavior:
# Configure traffic behavior.
[Device] traffic behavior b1
[Device-behavior-b1] filter permit
[Device-behavior-b1] quit
[Device] traffic behavior b2
[Device-behavior-b2] filter deny
[Device-behavior-b2] quit
5. Associate classification rules and actions:
# Configure a QoS policy.
[Device] qos policy p1
[Device-qospolicy-p1] classifier c1 behavior b1
[Device-qospolicy-p1] classifier c2 behavior b2
[Device-qospolicy-p1] quit
6. Apply the QoS policy:
# Apply the QoS policy to the outbound direction of interface GigabitEthernet 2/1/1.
[Device] interface GigabitEthernet 2/1/1
[Device-GigabitEthernet2/1/1] qos apply policy p1 outbound
15
IPv6 ACL configuration example
Perform packet filtering in the inbound direction of interface GigabitEthernet 2/1/1 to deny all IPv6
packets but those with source addresses in the range 4050::9000 to 4050::90FF.
1. Create ACLs:
# Create an IPv6 ACL 2000.
<Sysname> system-view
[Sysname] acl ipv6 number 2000
[Sysname-acl6-basic-2000] rule permit source 4050::9000/120
# Create an IPv6 ACL 2100.
[Sysname] acl ipv6 number 2100
[Sysname-acl6-basic-2100] rule permit source any
[Sysname-acl6-basic-2000] quit
2. Apply the ACL:
# Configure traffic classification.
[Sysname] traffic classifier c1
[Sysname-classifier-c1] if-match acl ipv6 2000
[Sysname-classifier-c1] quit
[Sysname] traffic classifier c2
[Sysname-classifier-c2] if-match acl ipv6 2100
[Sysname-classifier-c2] quit
3. Configure traffic behaviors:
# Configure traffic behavior.
[Sysname] traffic behavior b1
[Sysname-behavior-b1] filter permit
[Sysname-behavior-b1] quit
[Sysname] traffic behavior b2
[Sysname-behavior-b2] filter deny
[Sysname-behavior-b2] quit
4. Associate traffic classification rules and actions:
# Configure a QoS policy.
[Sysname] qos policy p1
[Sysname-qospolicy-p1] classifier c1 behavior b1
[Sysname-qospolicy-p1] classifier c2 behavior b2
[Sysname-qospolicy-p1] quit
5. Apply the QoS policy:
# Apply QoS policy to the outbound direction of interface GigabitEthernet2/1/1.
[Sysname] interface GigabitEthernet 2/1/1
[Sysname-GigabitEthernet2/1/1] qos apply policy p1 outbound
16
Flow template configuration example
Create flow templates and apply them to interfaces.
# Create basic user-defined flow template aaa.
[Sysname] flow-template aaa basic smac customer-vlan-id
# Reference user-defined flow template aaa on interface GigabitEthernet 2/1/1.

[Sysname] interface Gigabitethernet 2/1/1
[Sysname-GigabitEthernet2/1/1] flow-template aaa
# Display information about user-defined flow template aaa.

[Sysname] display flow-template user-defined aaa
user-defined flow template: basic
name:aaa, index:1, total reference counts:1
fields: smac customer-vlan-id
# Display information about all user-defined flow templates.

[Sysname] display flow-template user-defined
name:1, index:2, total reference counts:0
fields: service-cos
name:2, index:3, total reference counts:0
fields: ip-protocol dscp
# Display information about the user-defined flow templates referenced to interfaces.

[Sysname] display flow-template interface
Interface: GigabitEthernet2/1/1
# Delete user-defined flow template aaa. As it is being referenced by interface Gigabitethernet 2/1/1,
remove it from the interface first.
[Sysname] interface Gigabitethernet 2/1/1
[Sysname-GigabitEthernet2/1/1] undo flow-template
[Sysname-GigabitEthernet2/1/1] quit
[Sysname] undo flow-template name aaa
ACL rule length limit mode configuration example

Configure the ACL rule length limit for an SPE card to 18 bytes and that for an SPC card to 80 bytes.
17
# Set the ACL rule length limit mode to 3.
[Sysname] acl mode 3
ACL has been set to mode 3, and will take effect after the next system reboot.
# Display the ACL rule length limit mode.

[Sysname] display acl mode
Current ACL mode : mode 2 (SPE ACL key long, SPC ACL key short)
Acl mode after system restart : mode 3 (SPE ACL key short, SPC ACL key long)
Notice: Changing ACL mode will take effect only after system restart.
# Restart the router.

[Sysname] return
<Sysname> reboot
18
QoS overview
NOTE:
In this documentation, SPC cards refer to the cards prefixed with SPC, for example, SPC-GT48L, and SPE
cards refer to the cards prefixed with SPE, for example, SPE-1020-E-II.
Introduction to QoS
In data communications, Quality of Service (QoS) is the ability of a network to provide differentiated
service guarantees for diversified traffic in terms of bandwidth, delay, jitter, and drop rate.
Network resources are always scarce. The contention for resources requires QoS to prioritize important
traffic flows over trivial ones. When making a QoS scheme, a network administrator must consider the
characteristics of various applications to balance the interests of diversified users and fully utilize network
resources.
Networks without QoS guarantee

On traditional IP networks without QoS guarantee, routers treat all packets equally and handle them
using the first in first out (FIFO) policy. All packets share the resources of the network and routers. How
many resources the packets can obtain completely depends on the time they arrive. This service is called
best-effort. It delivers packets to their destinations when it can, without any guarantee for delay, jitter,
packet loss ratio, and so on.
This service policy is only suitable for applications insensitive to bandwidth and delay, such as Word
Wide Web (WWW) and email.
QoS requirements of new applications

The Internet is growing along with the fast development of networking technologies.
Besides traditional applications, such as WWW, email, and FTP, network users are experiencing new
services, such as tele-education, telemedicine, video telephone, videoconference, and
Video-on-Demand (VoD). Enterprise users expect to connect their regional branches together with VPN
technologies to carry out operational applications, for instance, to access the database of the company
or to monitor remote routers through Telnet.
These new applications all have special requirements for bandwidth, delay, and jitter. For example,
videoconference and VoD require high bandwidth, low delay and jitter. As for mission-critical
applications, such as transactions and Telnet, they may not require high bandwidth, but do require low
delay and preferential service during congestion.
The emerging applications demand higher service performance of IP networks. Better network services
during packets forwarding are required, such as providing dedicated bandwidth, reducing packet loss
ratio, managing and avoiding congestion, and regulating network traffic. To meet these requirements,
networks must provide more improved services.
19
Congestion: causes, impacts, and countermeasures
Network congestion is a key factor to degrade the service quality of a traditional network. Congestion
refers to the fact that the forwarding rates are decreased due to insufficient resources, resulting in extra
delay and degrading the quality.
Causes
Congestion easily occurs in complex packet switching circumstances in the Internet, Figure 4 shows some
common cases.
Figure 4 Traffic congestion causes
100M
100M 10M 10M 100M
100M > 10M

50M
(100M + 10M + 50M) > 100M
(1) (2)
The traffic enters a router from a high-speed link and is forwarded over a low-speed link.
The packet flows enter a router from several interfaces and are forwarded out an interface, whose
speed is smaller than the sum of the incoming interfaces.
When traffic arrives at the line speed, congestion may occur due to the network resource bottleneck.
Besides the link bandwidth bottleneck, congestion can also be caused by resource shortages (such as
insufficient processor time, buffer, and memory). In addition, congestion may occur if the arriving traffic
is not managed efficiently, thus resulting in inadequate network resources.
Impacts
Congestion can bring the following negative results:
Increased delay and jitter during packet transmission
Decreased network throughput and resource use efficiency
Network resource (memory, in particular) exhaustion and even system breakdown
Congestion hinders resource assignment for traffic and degrades service performance. Congestion is
unavoidable in switched networks and multi-user application environments. To improve the service
performance of your network, you must address the congestion issues.
Countermeasures
A simple solution for congestion is to increase network bandwidth. However, this solution cannot solve all
the problems that cause congestion because you cannot increase network bandwidth infinitely.
A more effective solution is to provide differentiated services for different applications through traffic
control and resource allocation. In this way, resources can be used more properly. During resources
allocation and traffic control, the direct or indirect factors that might cause network congestion must be
controlled to reduce the probability of congestion. Once congestion occurs, resource allocation must be
20
performed according to the characteristics and demands of applications to minimize the effects of
congestion.
Major traffic management technologies

Figure 5 Positions of the QoS techniques in a network
As shown in Figure 5, traffic classification, traffic shaping, traffic policing, congestion management, and
congestion avoidance mainly implement the following functions:
Traffic classification uses certain match criteria to assign packets with the same characteristics to a
class. Based on classes, you can provide differentiated services.
Traffic policing polices flows entering or leaving a device. You can apply traffic policing to both
incoming and outgoing traffic of a port. When a flow exceeds the pre-set threshold, some restriction
or punishment measures can be taken to prevent overconsumption of network resources.
Traffic shaping proactively adapts the output rate of traffic to the network resources available on the
downstream device to eliminate packet drop. Traffic shaping is usually applied to the outgoing
traffic of a port.
Congestion management provides a resource scheduling policy to arrange the forwarding
sequence of packets when congestion occurs. Congestion management is usually applied to the
outgoing traffic of a port.
Congestion avoidance monitors the usage status of network resources and is usually applied to the
outgoing traffic of a port. As congestion becomes worse, it actively reduces the queue length by
dropping packets.
21
Configuring traffic shaping and line rate
Traffic shaping overview

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

Token bucket features
A token bucket is analogous to a container holding a certain number of tokens. The system puts tokens
into the bucket at a set rate. When the token bucket is full, the extra tokens will cause the token bucket to
overflow.
Figure 6 Evaluate traffic with the token bucket
Evaluating traffic with the token bucket

The evaluation of traffic specifications is based on whether the number of tokens in the bucket is enough
for forwarding the packets. Generally, one token is associated with a 1-bit forwarding authority. When
a packet of n bits is forwarded, n tokens are taken out of the token bucket. If the number of tokens in the
bucket is enough for forwarding the packets, the traffic conforms to the specification, and is called the
conforming traffic. Otherwise, the traffic does not conform to the specification, and is called the excess
traffic.
22
A token bucket has the following configurable parameters:
Mean rateRate at which tokens are put into the bucket, or the permitted average rate of traffic. It
is also called the committed information rate (CIR).
Burst sizeCapacity of the token bucket, or the maximum traffic size that is permitted in each burst.
It is also called the committed burst size (CBS). The set burst size must be greater than the
maximum packet size.
One evaluation is performed on each arriving packet. In each evaluation, if the number of tokens in the
bucket is enough, the traffic conforms to the specification and the tokens for forwarding the packet are
taken away; if the number of tokens in the bucket is not enough, it means that too many tokens have been
used and the traffic is excessive.
Complicated evaluation
You can set two token buckets, bucket C and bucket E, to evaluate traffic in a more complicated
environment and achieve more policing flexibility. For example, traffic policing uses the following
parameters:
CIRRate at which tokens are put into bucket C, that is, the average packet transmission or
forwarding rate allowed by bucket C.
CBSSize of bucket C, that is, transient burst of traffic that bucket C can forward.
Peak information rate (PIR)Rate at which tokens are put into bucket E, that is, the average packet
transmission or forwarding rate allowed by bucket E.
Excess burst size (EBS)Size of bucket E, that is, transient burst of traffic that bucket E can forward.
Figure 7 Two-bucket structure
The two-bucket structure is as shown in Figure 7. CBS is implemented with bucket C and EBS with bucket
E. In each evaluation, packets are measured against the following bucket scenarios:
If bucket C has enough tokens, packets are colored green.
If bucket C does not have enough tokens but bucket E has enough tokens, packets are colored
yellow.
If neither bucket C nor bucket E has sufficient tokens, packets are colored red.
Traffic policing
A typical application of traffic policing is to supervise the specification of certain traffic entering a
network and limit it within a reasonable range, or to discipline the extra traffic to prevent aggressive
use of network resources by a certain application. For example, you can limit bandwidth for HTTP
packets to less than 50% of the total. If the traffic of a certain session exceeds the limit, traffic policing can
drop the packets or reset the IP precedence of the packets.
Traffic policing is widely used in policing traffic into the networks of internet service providers (ISPs). It can
classify the policed traffic and perform pre-defined policing actions based on different evaluation results.
These actions include the following:
Forwarding the packets whose evaluation result is conforming
Dropping the packets whose evaluation result is nonconforming
23
Modifying the IP precedence of the packets whose evaluation result is conforming and
forwarding them
Modifying the IP precedence of the packets whose evaluation result is conforming and delivering
them into the next-level Traffic policing
Entering the next-level policing (you can set multiple traffic policing levels with each level focusing
on specific objects)
Traffic shaping
Traffic shaping limits the outbound traffic rate by buffering exceeding traffic. You can use traffic shaping
to adapt the traffic output rate on a device to the input traffic rate of its connected device to avoid packet
loss.
The difference between traffic policing and GTS is that packets to be dropped in traffic policing are
cached in a buffer or queue in GTS, as shown in Figure 8. When the token bucket has enough tokens,
these cached packets are sent at an even rate. Traffic shaping may result in an additional delay, but
traffic policing does not.
Figure 8 GTS
For example, in Figure 9, Router B performs traffic policing on packets from Router A and drops packets
exceeding the limit. To avoid packet loss, you can perform traffic shaping on the outgoing interface of
Router A so packets exceeding the limit are cached in Router A. Once resources are released, traffic
shaping takes out the cached packets and sends them out.
Figure 9 GTS application
24
Line rate
The line rate of a physical interface specifies the maximum rate for forwarding packets (including critical
packets).
Line rate also uses token buckets for traffic control. With line rate configured on an interface, all packets
to be sent through the interface are first handled by the token bucket at line rate. If the token bucket has
enough tokens, packets can be forwarded. Otherwise, packets are put into QoS queues for congestion
management. In this way, the traffic passing the physical interface is controlled.
Figure 10 Line rate implementation
The token bucket mechanism limits traffic rate and accommodates bursts. It allows bursty traffic to be
transmitted as long as enough tokens are available. If tokens are inadequate, packets cannot be
transmitted until efficient tokens are generated in the token bucket. It restricts the traffic rate to the rate for
generating tokens.
Line rate limits the total rate of all packets on a physical interface. It is easier to use than traffic policing
in controlling the total traffic rate on a physical interface.
Traffic shaping configuration

Configuring traffic shaping
Traffic shaping supports queue-based GTS, which configures GTS parameters for packets of a certain
queue.
To configure queue-based GTS:

25
Enter interface view: Use either command.

interface interface-type Settings in interface view are
2. Enter interface view or port interface-number effective on the current
group view. interface. Settings in port
group view are effective on all
port-group manual port-group-name
ports in the port group.
CBS is the traffic transmitted at

the rate of CIR in 500 ms by
3. Configure GTS for the qos gts queue queue-number cir default.
interface or port group. committed-information-rate [ cbs
committed-burst-size ] The command is not available
on low-speed CPOS
interfaces.
4. Display GTS configuration display qos gts interface [ interface-type Optional.

information. interface-number ] [ | { begin | exclude |
include } regular-expression ] Available in any view
Configuring GTS for all traffic

To configure GTS for all traffic:

Use either command.

2. Enter interface Settings in interface view are
interface interface-type interface-number
view or port group effective on the current interface.
view. Enter port group view: Settings in port group view are
port-group manual port-group-name effective on all ports in the port
group.
For interfaces except low-speed

CPOS interfaces, CBS is the traffic
3. Configure GTS on
qos gts any cir committed-information-rate transmitted at the rate of CIR in
the interface or
[ cbs committed-burst-size ] 500 ms by default.
port group.
For low-speed CPOS interfaces,
CBS is 1024 bytes by default.
4. Display GTS display qos gts interface [ interface-type Optional.
configuration interface-number ] [ | { begin | exclude |
information. include } regular-expression ] Available in any view
NOTE:
Do not configure a CIR exceeding the interface bandwidth. Otherwise, the configuration will fail.
Do not configure the qos lr command and the qos gts any command on the same interface or port
group at the same time.
Displaying and maintaining GTS
26
display qos gts interface
Display interface GTS [ interface-type interface-number ]
configuration information. [ | { begin | exclude | include }
Traffic shaping configuration example

Configure GTS on queue 0 of GigabitEthernet 3/1/2 of the router to shape the traffic at rates higher than
480 kbps.
# Enter system view.
# Enter interface view.

# Configure the GTS parameter.

[Sysname-GigabitEthernet3/1/2] qos gts queue 0 cir 480
Line rate configuration

Configuring the line rate
The line rate of a physical interface specifies the maximum rate of outgoing packets.
To configure the line rate:

interface interface-type Use either command.
interface-number Settings in interface view take effect
2. Enter interface view, on the current interface. Settings in
port group view, or port group view take effect on all
subinterface view. ports in the port group. Settings in
Enter subinterface view: subinterface view take effect on the
current subinterface.
interface-number.subnumber
3. Configure the line rate qos lr outbound cir By default, the CBS is the traffic
for the interface or committed-information-rate [ cbs transmitted at the rate of CIR in 500
port group. committed-burst-size ] ms.
27
NOTE:
Do not configure a CIR exceeding the interface bandwidth. Otherwise, the configuration will fail.
The qos lr command is available for the interfaces on the subcards PIC-GP10L, PIC-GP20R, and
PIC-GT20R.
The first time you configure the qos lr, queue ef bandwidth, queue af bandwidth, queue wfq, or
remark local-precedence command for a subinterface, you must use the undo qos lr command to
disable line rate on the main interface if none of these commands is configured on any other
subinterfaces.
Do not configure the qos lr command and the qos gts any command on the same interface or port
group at the same time.
Displaying and maintaining line rate

display qos lr interface
Display interface line rate [ interface-type interface-number ]
configuration information. [ | { begin | exclude | include }
Line rate configuration example

1. Network requirements
Configure line rate on interface GigabitEthernet 3/1/2 to limit the rate of outgoing packets to 480
kbps.
2. Configuration procedure
# Configure line rate on the interface.
[Sysname-GigabitEthernet3/1/2] qos lr outbound cir 480
28
Configuring a QoS policy
QoS policy overview

A QoS policy involves three components: class, traffic behavior, and policy. You can associate a class
with a traffic behavior using a QoS policy.
Class
Classes identify traffic.
A class is identified by a class name and contains some match criteria.
You can define a set of match criteria to classify packets, and the relationship between criteria can be
one of the following:
andThe router considers that a packet belongs to a class only when the packet matches all the
criteria in the class.
orThe router considers that a packet belongs to a class as long as the packet matches one of the
criteria in the class.
Traffic behavior
A traffic behavior, identified by a name, defines a set of QoS actions for packets.
Policy
A policy associates a class with a traffic behavior.
You can configure multiple class-to-traffic behavior associations in a policy.
Traffic classification overview

Traffic classification
When defining match criteria for classifying traffic, you can use IP precedence bits in the type of service
(ToS) field of the IP packet header, or other header information such as IP addresses, MAC addresses, IP
protocol field, and port numbers. You can define a class for packets with the same quintuple (source
address, source port number, protocol number, destination address, and destination port number for
example), or for all packets to a certain network segment.
When packets are classified on the network boundary, the precedence bits in the ToS field of the IP
packet header are usually reset. In this way, IP precedence can be directly used to classify the packets in
the network. IP precedence can also be used in queuing to prioritize traffic. The downstream network can
either use the classification results from its upstream network or classify the packets again according to
its own criteria.
To provide differentiated services, traffic classes must be associated with certain traffic control actions or
resource allocation actions. What traffic control actions to use depends on the current phase and the
resources of the network. For example, CAR polices packets when they enter the network, GTS is
performed on packets when they leave the node, queue scheduling is performed when congestion
happens, and congestion avoidance measures are taken when the congestion deteriorates.
29
Packet precedences
This section introduces IP precedence, ToS precedence, differentiated services codepoint (DSCP) values,
802.1p priority, and EXP values.
1. IP precedence, ToS precedence, and DSCP values
Figure 11 DS field and ToS bytes
As shown in Figure 11, the ToS field in the IP header contains eight bits: the first three bits (0 to 2)
represent IP precedence from 0 to 7; the subsequent four bits (3 to 6) represent a ToS value from 0 to 15.
According to RFC 2474, the ToS field is redefined as the differentiated services (DS) field, where a DSCP
value is represented by the first six bits (0 to 5) and ranges from 0 to 63. The remaining two bits (6 and
7) are reserved.
Table 2 Description on IP Precedence
IP precedence (decimal) IP precedence (binary) Description

0 000 Routine
1 001 priority
2 010 immediate
3 011 flash
4 100 flash-override
5 101 critical
6 110 internet
7 111 network
In a network in the Diff-Serve model, traffic is grouped into the following classes, and packets are
processed according to their DSCP values:
Expedited forwarding (EF) classIn this class, packets are forwarded regardless of link share of
other traffic. The class is suitable for preferential services requiring low delay, low packet loss, low
jitter, and high bandwidth.
Assured forwarding (AF) classThis class is divided into four subclasses (AF 1 to AF 4), each
containing three drop priorities for more granular classification. The QoS level of the AF class is
lower than that of the EF class.
Class selector (CS) classThis class is derived from the IP ToS field and includes eight subclasses.
Best effort (BE) classThis class is a special CS class that does not provide any assurance. AF traffic
exceeding the limit is degraded to the BE class. All IP network traffic belongs to this class by default.
30
Table 3 Description on DSCP values
DSCP value (decimal) DSCP value (binary) Description

46 101110 ef
10 001010 af11
12 001100 af12
14 001110 af13
18 010010 af21
20 010100 af22
22 010110 af23
26 011010 af31
28 011100 af32
30 011110 af33
34 100010 af41
36 100100 af42
38 100110 af43
8 001000 cs1
16 010000 cs2
24 011000 cs3
32 100000 cs4
40 101000 cs5
48 110000 cs6
56 111000 cs7
0 000000 be (default)
2. 802.1p priority
802.1p priority lies in Layer 2 packet headers and is applicable to occasions where Layer 3
header analysis is not needed and QoS must be assured at Layer 2.
Figure 12 An Ethernet frame with an 802.1Q tag header
802.1Q
Destination Source header FCS
Length/Type Data
Address Address (CRC-32)
TPID TCI
6 bytes 6 bytes 4 bytes 2 bytes 46 to 1500 bytes 4 bytes
As shown in Figure 12, the 4-byte 802.1Q tag header consists of the tag protocol identifier (TPID, two
bytes in length), whose value is 0x8100, and the tag control information (TCI, two bytes in length). Figure
13 presents the format of the 802.1Q tag header.
31
Figure 13 802.1Q tag header
The priority in the 802.1Q tag header is called 802.1p priority, because its use is defined in IEEE
802.1p. Table 4 presents the values for 802.1p priority.
Table 4 Description on 802.1p priority
802.1p priority (decimal) 802.1p priority (binary) Description

0 000 best-effort
1 001 background
2 010 spare
3 011 excellent-effort
4 100 controlled-load
5 101 video
6 110 voice
7 111 network-management
3. EXP values
The EXP field lies in MPLS labels for QoS purposes.
Figure 14 MPLS label structure
As shown in Figure 14, the EXP field is 3 bits long and ranges from 0 to 7.
QoS policy configuration procedure

To configure a QoS policy:
1. Create a class and define a set of match criteria in class view.
2. Create a traffic behavior and define a set of QoS actions in traffic behavior view.
3. Create a policy and associate the traffic behavior with the class in policy view.
4. Apply the QoS policy.
Defining a class
To define a class, specify its name and then configure the match criteria in class view.
32
To define a class:

2. Create a class and enter class traffic classifier tcl-name [ operator By default, the operator of a class
view. { and | or } ] is logic and.
3. Configure match criteria. if-match match-criteria N/A
display traffic classifier

user-defined [ tcl-name ] [ | { begin Optional.
4. Display class information.
| exclude | include } Available in any view
Configuration example
Configure a class named test_class. Packets with the destination MAC address 0050-BA27-BED3
belong to the class.
# Define a class and enter class view.
[Sysname] traffic classifier test_class
# Define a match criterion.
[Sysname-classifier-test_class] if-match destination-mac 0050-ba27-bed3
Defining a traffic behavior

A traffic behavior is a set of QoS actions (such as traffic filtering, shaping, policing, and priority marking)
to take on a class of traffic. To define a traffic behavior, first create it and then configure QoS actions
(such as priority marking and traffic redirecting) in traffic behavior view.
To define a traffic behavior:

6. Create a traffic behavior and

enter traffic behavior view. traffic behavior behavior-name N/A
7. Enable traffic accounting. accounting [ byte | packet ]
car cir committed-information-rate [ cbs

committed-burst-size [ ebs N/A
8. Configure a CAR action. excess-burst-size ] ] [ pir You can configure the traffic
peak-information-rate ] [ red { discard | behavior as required.
pass } ]
9. Drop or send packets. filter { deny | permit }
33
redirect { cpu | next-hop { ipv4-add
[ track track-entry-number ] [ ipv4-add
[ track track-entry-number ] ] | ipv6-add
10. Redirect traffic to a specified [ interface-type interface-number ] [ track
target. track-entry-number ] [ ipv6-add
[ interface-type interface-number ] [ track
track-entry-number ] ] } [ fail-action
{ discard | forward } ] | vpn-instance
vpn-instance-name }
11. Set the DSCP value for
packets. remark dscp dscp-value
12. Set the 802.1p priority for

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

packets. drop-precedence-value
14. Set the IP precedence for remark ip-precedence
packets. ip-precedence-value
15. Set the local precedence for remark local-precedence
packets. local-precedence
16. Set the EXP value for MPLS
packets. remark mpls-exp exp-value
17. Assign priority values to primap { pre-defined { color { up-dot1p

packets using a specified | up-dscp | up-exp | up-lp } |
priority mapping table. dscp-dscp } | color-map-dp }
18. Configure the default traffic redirect-default next-hop ipv4-add1

redirecting action. [ track track-entry-number ] [ ipv4-add2
[ track track-entry-number ] ]
19. Display traffic behavior display traffic behavior user-defined Optional.

configuration information. [ behavior-name ] [ | { begin | exclude |
include } regular-expression ] Available in any view
NOTE:
The priority mapping table to be included in the primap pre-defined command must be configured
beforehand. For more information, see the chapter Configuring priority mapping.
For an ordinary port in an isolation group, only the following commands take effect on its incoming
traffic: accounting, filter deny, car cir committed-information-rate red discard, and mirror-to.
In a traffic behavior, redirecting traffic to the CPU, redirecting traffic to the next hop, and redirecting
traffic to a VPN-instance cannot co-exist and the one configured the last overwrites the previous one.
Defining a policy
In a policy, you can define multiple class-behavior associations, and these associations are matched in
the order they are configured. A behavior is performed for an associated class of packets. In this way,
various QoS features can be implemented.
To define a policy:
34
2. Create a policy and enter policy view. qos policy policy-name N/A
3. Associate a class with a behavior in the classifier tcl-name behavior
policy. N/A
behavior-name
4. Display the information about a QoS display qos policy user-defined Optional.
policy information or a traffic behavior [ policy-name [ classifier tcl-name ] ] [ |
{ begin | exclude | include } Available in any
associated with a QoS policy. view
Applying the QoS policy

You can apply the QoS policy in different views.
You can apply a QoS policy to the following destinations:
An interfaceThe policy takes effect on the traffic sent or received on the interface.
A VLANThe policy takes effect on the traffic sent or received on all ports in the VLAN.
GloballyThe policy takes effect on the traffic sent or received on all ports.
You can modify the match criteria, traffic behaviors, and classifier-behavior associations of a QoS policy
already applied. If a class in the QoS policy uses an ACL as a match criterion, you can modify or delete
the ACL, for example, add, delete, and modify the ACL rules.
NOTE:
VLANs do not support user-defined flow templates. In case an interface referencing a user-defined flow
template and a VLAN on the interface have been each associated with a module QoS command (MQC)
policy in the same direction, the one on the interface takes effect and the one on the VLAN do not take
effect.
Applying the QoS policy to an interface

A policy can be applied to multiple interfaces. Only one policy can be applied in one direction (inbound
or outbound) of an interface.
To apply a policy to an interface:


2. Enter interface view or interface-number effective on the current interface.
port group view. Settings in port group view are
effective on all ports in the port
group.
3. Apply a policy to the qos apply policy policy-name { inbound
interface or port group. N/A
| outbound }
35
NOTE:
You can apply QoS policies to all physical interfaces except interfaces configured with X.25 or LAPB.
The QoS policy applied to the outgoing traffic on an interface does not regulate local packets. Local
packets refer to the critical protocol packets sent by the local system for maintaining the normal
operation of the router. To avoid drop of local packets, QoS does not process them. Commonly used
local packets include link maintenance packets, IS-IS packets, OSPF packets, RIP packets, BGP packets,
LDP packets, RSVP packets, and SSH packets.
Applying the QoS policy to a VLAN

To apply the QoS policy to a VLAN:
Step Command
2. Apply the QoS policy to one or multiple VLANs. qos vlan-policy policy-name vlan vlan-id-list { inbound
| outbound }
NOTE:
You cannot apply QoS policies to dynamic VLANs, for example, VLANs created by GVRP.
Applying the QoS policy globally

You can apply a QoS policy globally to the inbound or outbound direction of all ports.
To apply the QoS policy globally:
Step Command
2. Apply the QoS policy globally. qos apply policy policy-name global { inbound |
outbound }
NOTE:
If the hardware resources of an interface card are insufficient, applying a QoS policy globally may fail
on the interface card. The system does not automatically roll back the QoS policy configuration already
applied to the main processing unit or other interface cards. To ensure consistency, you must use the
undo qos apply policy global command to manually remove the QoS policy configuration applied to
them.
The qos apply policy global command is available only on the SPC cards.
QoS policy configuration example

Configure a QoS policy named test_policy. Associate the traffic behavior test_behavior with the
traffic class test_class in the policy, and apply the policy to the following occasions:
{ The incoming traffic of GigabitEthernet 2/1/1
{ The incoming traffic of VLANs 200, 300, 400, 500, 600, 700, 800, and 900
36
# Create a QoS policy test_policy.
[Sysname] qos policy test_policy
[Sysname-qospolicy-test_policy] classifier test_class behavior test_behavior
[Sysname-qospolicy-test_policy] quit
# Apply the QoS policy test_policy to the incoming traffic of GigabitEthernet 2/1/1.
[Sysname] interface GigabitEthernet2/1/1
[Sysname-GigabitEthernet2/1/1] qos apply policy test_policy inbound
[Sysname-GigabitEthernet2/1/1] quit
# Apply the QoS policy test_policy to the incoming traffic of the specified VLANs.
[Sysname] qos vlan-policy test_policy vlan 200 300 400 500 600 700 800 900 inbound
Displaying and maintaining QoS policies

Display the configuration
display qos policy user-defined
information of the specified class
[ policy-name [ classifier
or all the classes and associated Available in any view
tcl-name ] ] [ | { begin | exclude |
behaviors in the specified policy or
all policies.
display qos policy interface

Display QoS policy configuration [ interface-type interface-number ]
information of the specified [ inbound | outbound ] [ | { begin Available in any view
interface or all interfaces. | exclude | include }
display traffic behavior

Display traffic behavior user-defined [ behavior-name ] [ |
configuration information. { begin | exclude | include }
display traffic classifier

user-defined [ tcl-name ] [ | { begin
Display traffic class information. Available in any view
| exclude | include }
display qos vlan-policy { name

policy-name | vlan [ vlan-id ] }
Display VLAN QoS policy
[ slot slot-number ] [ inbound | Available in any view
information.
outbound ] [ | { begin | exclude |
reset qos vlan-policy [ vlan vlan-id ]

Clear VLAN QoS policy statistics. Available in user view
[ inbound | outbound ]
37
Configuring hardware congestion
management
Congestion management overview

Causes, impacts, and countermeasures of congestion
Congestion occurs on a link or node when traffic size exceeds the processing capability of the link or
node. It is typical of a statistical multiplexing network and can be caused by link failures, insufficient
resources, and various other causes. Figure 15 shows some common congestion scenarios.
Figure 15 Traffic congestion causes
Congestion can bring the following negative results:

Increased delay and jitter during packet transmission
Decreased network throughput and resource use efficiency
Network resource (memory in particular) exhaustion and even system breakdown
Congestion is unavoidable in switched networks or multi-user application environments. To improve the
service performance of your network, you must take measures to manage and control it.
One major issue that congestion management deals with is how to define a resource dispatching policy
to prioritize packets for forwarding when congestion occurs.
Congestion management policies

Queuing is a common congestion management technique. It classifies traffic into queues and picks out
packets from each queue by using a certain algorithm. Various queuing algorithms are available, each
addressing a particular network traffic problem. Your choice of algorithm affects bandwidth assignment,
delay, and jitter significantly.
Congestion management involves queue creating, traffic classification, packet enqueuing, and queue
scheduling. Queue scheduling treats packets with different priorities differently to transmit high-priority
packets preferentially.
Several common queue-scheduling mechanisms are introduced here.
38
Weighted fair queuing
NOTE:
WFQ is applicable to only SPE cards.
Figure 16 Weighted fair queuing (WFQ)
WFQ is an enhancement to fair queuing (FQ). FQ is designed for fairly sharing network resources,
reducing delay and jitter of traffic. To this end, FQ takes many aspects into consideration to guarantee
fairness among different queues and packets of different sizes during scheduling to
Prevent packets in low-priority queues from being starved.
Minimize jitter between packets in each stream by preferentially scheduling short packets in case
both large packets and short packets are waiting in the queues.
Compared with FQ, WFQ takes weights into account when determining the queue scheduling order.
Statistically, WFQ gives high priority traffic more scheduling opportunities than low priority traffic. When
dequeuing packets, WFQ assigns the outgoing interface bandwidth to each traffic flow by precedence.
The higher precedence a traffic flow has, the more bandwidth it gets.
For example, assume that three flows exist on the current interface, with the precedence 1, 2, and 3
respectively. The total bandwidth quota is 6, that is, the sum of all the precedence values. The bandwidth
percentage assigned to each flow is (precedence value of the flow)/total bandwidth quota. Thus, the
bandwidth percentages for the flows are 1/6, 2/6, and 3/6 respectively.
Hardware WFQ provides multiple queues, each with its individual weight.
NOTE:
Queue 0 is a BE queue, queues 1 through 4 are AF queues, queue 5 and queue 6 are EF queues, and
queue 7 is a NC queue. Different types of queues are scheduled by SP, and queues of the same type are
scheduled based on their weights.
39
CBQ
Class-based queuing (CBQ) extends WFQ by supporting user-defined classes. CBQ assigns an
independent reserved FIFO queue for each user-defined class to buffer data of the class. When network
congestion occurs, CBQ enqueues packets by user-defined match criteria. Before that, congestion
avoidance actions such as tail drop or weighted random early detection (WRED) and bandwidth
restriction check are performed before packets are enqueued. When being dequeued, packets are
scheduled by WFQ.
CBQ provides an emergency queue to enqueue emergent packets. The emergency queue is a FIFO
queue without bandwidth restriction. However, delay sensitive flows like voice packets may not be
transmitted timely in CBQ since packets are fairly treated. To solve this issue, Low Latency Queuing (LLQ)
was introduced to combine PQ and CBQ to transmit delay sensitive flows like voice packets
preferentially.
When defining traffic classes for LLQ, you can configure a class of packets to be transmitted preferentially.
Such a class is called a priority class. The packets of all priority classes are assigned to the same priority
queue. Bandwidth restriction on each class of packets is checked before the packets are enqueued.
During the dequeuing operation, packets in the priority queue are transmitted first. WFQ dequeues
packets in the other queues.
In order to reduce the delay of the other queues except the priority queue, LLQ assigns the maximum
available bandwidth for each priority class. The bandwidth value polices traffic during congestion.
When no congestion is present, a priority class can use more than the bandwidth assigned to it. During
congestion, the packets of each priority class exceeding the assigned bandwidth are discarded. LLQ can
also specify burst-size.
In a QoS policy, the class-behavior associations take effect in the order they are configured, and the one
configured first takes effect first. Similarly, the match criteria configured in a class take effect in the order
they are configured, and the one configured first takes effect first. Therefore, when you configure a QoS
policy, configure the class-behavior associations in the order of EF, AF, and BE.
Configuring WFQ queuing

With a WFQ queue configured on an interface, WFQ queuing is enabled on the interface, and other
queues on the interface use the default WFQ scheduling value.
To configure basic WFQ queuing:

Settings in interface view are
2. Enter interface view or port interface-number
effective on the current interface.
group view. Enter port group view: Settings in port group view are
port-group manual effective on all ports in the port
port-group-name group.
3. Set the scheduling weight qos wfq queue weight Repeat this step to configure other
for a basic WFQ queue. schedule-value queues as required.
40
Optional.
4. Configure the minimum The value for the bandwidth-value

guaranteed bandwidth for qos bandwidth queue queue-number argument cannot exceed the
a WFQ queue. min bandwidth-value interface bandwidth.
Repeat this step to configure other
queues as required.
display qos wfq interface

5. Display WFQ queuing [ interface-type interface-number ] [ | Optional.
configuration on interfaces. { begin | exclude | include } Available in any view
Configure the weights of queue 2, queue 3, and queue 4 as 5, 10, and 20, respectively.
# Configure WFQ queuing on GigabitEthernet 2/1/1.

[Sysname-GigabitEthernet2/1/1] qos wfq 2 weight 5
Configuring CBQ
To configured CBQ:
1. Create a class and define a set of traffic match criteria in class view.
2. Create a traffic behavior, and define a group of QoS features in traffic behavior view.
3. Create a policy, and associate a traffic behavior with a class in policy view.
4. Apply the QoS policy to the outgoing traffic of an interface.
Defining a class
For how to define a class, see the chapter Configuring a QoS policy.
NOTE:
To make sure that the traffic not entering the EF and AF queues enters the BE queue (the default priority
queue), you must configure a default class that permits any traffic, and use the default class in the last
class-behavior association of the QoS policy.
41
Defining a traffic behavior
To define a traffic behavior, you should first create the traffic behavior with a name specified and then
configure attributes for it in traffic behavior view.
Configure AF and the guaranteed bandwidth

To configure AF and the guaranteed bandwidth:
Step Command
2. Create a traffic behavior and enter traffic
behavior view. traffic behavior behavior-name
3. Configure AF and the guaranteed bandwidth. queue af bandwidth bandwidth
NOTE:
You cannot configure the queue af command together with the queue ef or queue wfq command in the
same traffic behavior.
You can apply this traffic behavior only to the outgoing traffic of an interface.
The guaranteed bandwidth specifies the bandwidth that is guaranteed for the AF traffic, regardless of
congestion on the interface. The AF traffic exceeding the guaranteed bandwidth and the BE traffic
compete for bandwidth. The forwarding for the exceeding AF traffic depends on the congestion
conditions on the interface.
Configuring EF and the guaranteed bandwidth

To configure EF and the guaranteed bandwidth:
Step Command
3. Configure EF and the guaranteed bandwidth. queue ef bandwidth bandwidth [ cbs burst ]
NOTE:
You cannot configure the queue ef command together with any of the commands queue af, queue wfq,
and wred in the same traffic behavior.
You can apply this behavior only to the outgoing traffic of an interface.
The bandwidth argument ranges from 64 to 10000000 in kbps. The burst argument ranges from 1600
to 1000000000 in bytes. If the burst argument is not configured, it is 25 times of the bandwidth
argument.
The guaranteed bandwidth specifies the bandwidth that is guaranteed for the EF traffic, regardless of
congestion on the interface. The forwarding for the EF traffic exceeding the guaranteed bandwidth
depends on the congestion conditions on the interface.
Configuring WFQ
To configure WFQ:
42
Step Command
3. Configure WFQ. queue wfq
NOTE:
You cannot configure the queue wfq command together with the queue ef or queue af command in the
same traffic behavior.
You can apply this behavior only to the outgoing traffic of an interface.
Using WRED drop

To use WRED drop:

2. Create a traffic behavior and
enter traffic behavior view. traffic behavior behavior-name N/A
dscp: Uses the DSCP value for

calculating the drop probability
for a packet.
3. Use WRED drop. ip-precedence: Uses the IP

wred [ dscp | ip-precedence ]
precedence value for
calculating the drop probability
for a packet. This keyword is
used by default.
NOTE:
You cannot configure the wred command together with the queue ef command in the same traffic
behavior.
Before configuring the wred [ dscp | ip-precedence ] command, make sure that you have configured
the queue af or queue wfq command.
You can apply this behavior to only the outgoing traffic of an interface.
Defining a QoS policy

For how to define a QoS policy, see the chapter Configuring a QoS policy.
Applying the QoS policy

Use the qos apply policy command to apply a policy to a specific physical interface or subinterface. A
policy can be applied to multiple physical interfaces.
To apply a policy to the specific interface:
43

group.
3. Apply a policy to the qos apply policy policy-name { inbound |
interface. N/A
outbound }
NOTE:
Depending on the match criteria configured in classes of a QoS policy, you may need to apply a flow
template to an interface before applying the QoS policy to the interface.
You can apply a QoS policy containing a CBQ action only to the outgoing traffic of an interface.
The QoS policy applied to the outgoing traffic on an interface does not regulate local packets. Local
packets refer to the critical protocol packets sent by the local system for maintaining the normal
operation of the router. To avoid drop of local packets, QoS does not process them. Commonly used
local packets include link maintenance packets, IS-IS packets, OSPF packets, RIP packets, BGP packets,
LDP packets, RSVP packets, and SSH packets.
An RPR interface does not support CBQ.
You can apply a QoS policy containing a CBQ action only to an interface.
To apply a QoS policy to an ATM interface, configure the ATM interface as the P2P type.
To guarantee that a QoS policy containing a CBQ action works properly, do not configure a GTS action
or any of the queuing features (queue ef, queue af, and queue wfq) in the QoS policy.
Frame relay traffic shaping (FRTS) on an MFR interface may affect the operation of CBQ. Therefore, do
not configure a FRTS action together with a CBQ action in a QoS policy applied to an MFR interface.
You cannot apply a QoS policy containing a CBQ action to an HQoS-configured interface. You cannot
configure HQoS on an interface configured with a QoS policy containing a CBQ action.
In a QoS policy, make sure that the sum of bandwidth assigned to EF queues, AF queues, and BE queues
does not exceed the actual bandwidth of the target interface. Otherwise, CBQ does not work as
expected.
Displaying and maintaining CBQ

For how to display and maintain CBQ, see the chapter Configuring a QoS policy.
CBQ configuration example

As shown in Figure 17, traffic travels from Router C to Router D through Router A and Router B.
Configure a QoS policy to meet the following requirements:
Traffic from Router C is classified into three classes based on DSCP values; perform AF for traffic
with the DSCP values AF11 and AF21 and set the guaranteed bandwidth to 5 Mbps.
44
Perform EF for traffic with the DSCP value EF and set the guaranteed bandwidth to 30 Mbps.
Before performing the configuration, make sure that:
Router C can reach Router D through Router A and Router B.
The DSCP fields have been set for the traffic before the traffic enters Router A.
Configure Router A
# Define three classes to match the IP packets with the DSCP values AF11, AF21 and EF respectively.
<RouterA> system-view
[RouterA] traffic classifier ef_class
[RouterA-classifier-ef_class] if-match dscp ef
[RouterA-classifier-ef_class] quit
[RouterA] traffic classifier af11_class
[RouterA-classifier-af11_class] if-match dscp af11
[RouterA-classifier-af11_class] quit
[RouterA]traffic classifier af21_class
[RouterA-classifier-af21_class] if-match dscp af21
[RouterA-classifier-af21_class] quit
# Define a default class named be_class to match all IP packets.

[RouterA] acl number 3000
[RouterA] rule 0 permit ip
[RouterA] traffic classifier be_class
[RouterA-classifier-be_class] if-match acl 3000
[RouterA-classifier-be_class] quit
# Define a traffic behavior named ef_behav, configure EF in the behavior, and set the guaranteed
bandwidth to 30720 kbps.
[RouterA] traffic behavior ef_behav
[RouterA-behavior-ef_behav] queue ef bandwidth 30720
[RouterA-behavior-ef_behav] quit
# Define a traffic behavior af11_behav, configure AF in the traffic behavior, and set the guaranteed
bandwidth to 5120 kbps. Configure traffic behavior af21_behav in a similar way.
[RouterA] traffic behavior af11_behav
[RouterA-behavior-af11_behav] queue af bandwidth 5120
45
[RouterA-behavior-af11_behav] quit
[RouterA] traffic behavior af21_behav
[RouterA-behavior-af21_behav] queue af bandwidth 5120
[RouterA-behavior-af21_behav] quit
# Define a traffic behavior named be_behav, configure WFQ in the traffic behavior, and configure the
drop mode as WRED.
[RouterA] traffic behavior be_behav
[RouterA-behavior-be_behav] queue wfq
[RouterA-behavior-be_behav] wred
[RouterA-behavior-be_behav] quit
# Create a QoS policy named dscp, and associate the defined classes with the behaviors as needed.
[RouterA] qos policy dscp
[RouterA-qospolicy-dscp] classifier ef_class behavior ef_behav
[RouterA-qospolicy-dscp] classifier af11_class behavior af11_behav
[RouterA-qospolicy-dscp] classifier af21_class behavior af21_behav
[RouterA-qospolicy-dscp] classifier be_class behavior be_behav
[RouterA-qospolicy-dscp] quit
# Apply QoS policy dscp to the outgoing traffic of interface GigabitEthernet 3/1/1.
[RouterA-GigabitEthernet3/1/1] qos apply policy dscp outbound
[RouterA-GigabitEthernet3/1/1] quit
# After the configuration, display the QoS policy configuration on interface GigabitEthernet 3/1/1 to
verify the configuration.
[RouterA] display qos policy interface GigabitEthernet 3/1/1 outbound
Interface: GigabitEthernet3/1/1
Direction: Outbound
Policy: dscp
Classifier: ef_class
Operator: AND
Rule(s) : If-match dscp ef
Behavior: ef_behav
Expedited Forwarding:
Bandwidth 30720 (Kbps), CBS 768000 (Bytes)
Matched : 100/6400 (Packets/Bytes)
Enqueued : 100/6400 (Packets/Bytes)
Discarded: 0/0 (Packets/Bytes)
Classifier: af11_class
Operator: AND
Rule(s) : If-match dscp af11
Behavior: af11_behav
Assured Forwarding:
Bandwidth 5120 (Kbps)
Classifier: af21_class
Operator: AND
46
Rule(s) : If-match dscp af21
Behavior: af21_behav
Assured Forwarding:
Bandwidth 5120 (Kbps)
Classifier: be_class
Operator: AND
Rule(s) : If-match acl 3000
Behavior: be_behav
Flow Based Weighted Fair Queuing
Discard Method: IP Precedence based WRED
47
Configuring priority mapping
Priority mapping overview

When a packet enters a router, the router assigns a set of QoS priority parameters to the packet based
on a certain priority field carried in the packet or the port priority of the incoming port, depending on
your configuration. This process is called priority mapping. During this process, the router may modify
the priority of the packet depending on router status. The set of QoS priority parameters decides the
scheduling priority and forwarding priority of the packet.
Priority mapping is implemented with priority mapping tables and involves priorities such as 802.11e
priority, 802.1p priority, DSCP, EXP, IP precedence, local precedence, and drop precedence.
The local precedence and drop precedence are defined as follows:
Local precedence is a locally significant precedence that the router assigns to a packet. A local
precedence value corresponds to an output queue. Packets with the highest local precedence are
processed preferentially.
Drop precedence is a parameter used for packet drop. The value 2 corresponds to red packets, the
value 1 corresponds to yellow packets, and the value 0 corresponds to green packets. Packets with
the highest drop precedence are dropped preferentially.
The router provides the following port priority trust modes:
Trust packet priorityThe router assigns to the packet the priority parameters corresponding to the
packets priority from the priority mapping table.
Trust port priorityThe router assigns a priority to a packet by mapping the priority of the receiving
port.
You can select one priority trust mode as needed. Figure 18 shows the process of priority mapping on a
router.
Figure 18 Priority mapping process
The router provides the following types of priority mapping tables

dscp-dscp: DSCP-to-DSCP priority mapping table, which only applies to IP packets.
up-dot1p: User-to-802.1p priority mapping table.
up-dscp: User-to-DSCP priority mapping table.
48
up-up: User-to-user priority mapping table.
up-dp: User-to-drop priority mapping table.
up-lp: User-to-local priority mapping table.
up-rpr: User-to-RPR priority mapping table.
up-fc: User-to-forwarding-class priority mapping table.
up-exp: User-to-EXP priority mapping table.
For more information about forwarding classes, see the chapter Configuring HQoS.
NOTE:
You can use the display qos map-table command to display the configured priority mapping tables.
The user precedence represents the 802.1p priority for Layer-2 packets, the IP precedence for Layer-3
packets, and the EXP precedence for MPLS packets.
Configuring a priority mapping table

You can modify the priority mapping tables of a router as needed.
Configuration prerequisites
Decide on the new mapping values.
To configure a priority mapping table:

qos map-table { dscp-dscp |

inbound { up-dp | up-lp | up-up } |
2. Enter priority mapping table outbound { up-dp | up-fc | up-lp | You can enter the priority mapping
view. up-rpr } | color { green | red | table view as required.
yellow } { up-dot1p | up-dscp |
up-lp | up-exp } }
3. Configure a priority mapping. import import-value-list export Newly configured mappings

export-value overwrite the previous ones.
display qos map-table [ dscp-dscp

| inbound [ up-dp | up-lp | up-up]
| outbound [ up-dp | up-fc | up-lp
4. Display priority mapping | up-rpr ] | color [ green | yellow Optional.
table configuration. | red ] [ up-dot1p | up-dscp | Available in any view
up-lp | up-exp ] ] [ | { begin |
exclude | include }
49
NOTE:
In a DSCP-to-DSCP priority mapping table, only entries with an odd number as the input can take effect.
To configure a DSCP-to-DSCP mapping for an even source DSCP value, use the even source DSCP value
plus one as the input value. For example, to create a mapping for source DSCP precedence 4, you need
to use 5 as the input value for the mapping.
Priority mapping can be implemented in one of the following approaches:

1. Identifying the priority trust mode.
{ On an SPE card, if the packet priority is trusted, the port analyzes the received packets
automatically: 802.1p priority is used as the packet priority for Layer-2 packets; IP precedence
is used as the packet priority for Layer-3 packets; EXP precedence is used as the packet priority
for MPLS packets. Then, the port uses the packet priority to search a priority mapping table for
the priority. If the port priority is trusted, the port searches a priority mapping table for the
priority, taking its own priority as the packet priority.
{ On an SPC card, if the packet priority is trusted, the port analyzes the received packets
automatically: 802.1p priority is used as the packet priority for non-IP packets; IP precedence
is used as the packet priority for IP packets; EXP precedence is used as the packet priority for
MPLS packets. Then, the port uses the packet priority to search a priority mapping table for the
priority. If the port priority is trusted, the port searches a priority mapping table for the priority,
taking its own priority as the packet priority.
2. Using the remark command and the primap command in the MQC policy. This approach can set
the DSCP precedence, EXP precedence, 802.1p priority, and drop precedence for packets.
3. Using the car command and the primap command in the MQC policy. This approach can meter
and mark the received packets. Single rate TCM (srTCM) and two-rate TCM (trTCM) are supported
in this approach.
Configure an up-dot1p priority mapping table as shown in Table 5.
Table 5 The dot1p-lp mapping for green packets
User precedence 802.1p priority

0 0
1 0
2 1
3 1
4 2
5 2
6 3
7 3
50
# Enter the green dot1p-lp priority mapping table view.

[Sysname] qos map-table color green up-dot1p
# Modify the green up-dot1p priority mapping parameters.

[Sysname-maptbl-green-up-dot1p] import 0 1 export 0
Changing the port priority of a port

If a port does not trust any packet priority, the router uses its port priority to look for the set of priority
parameters for the incoming packets. By changing port priority, you can prioritize traffic received on
different interfaces.
The port priority is in the range of 0 to 7. You can set the port priority as needed.
Decide on a priority for the port.
To configure port priority:


2. Enter interface view or port interface-number effective on the current
group view. interface. Settings in port
group view are effective on
all ports in the port group.
3. Configure a priority for the By default, the port priority is
port. qos priority priority-value
0.
Set the priority of the port to 7.
# Set the priority of GigabitEthernet 2/1/1 to 7.

[Sysname-GigabitEthernet2/1/1] qos priority 7
51
Configuring the port to trust packet priority for
priority mapping
You can configure the router to trust a particular priority field carried in packets for priority mapping on
a port. On a router supporting trusted priority type configuration, the priority mapping process for
packets is shown in Priority mapping overview.
To configure the trusted priority type:


group.
3. Configure the trusted
priority type. qos trust auto N/A
4. Display the trusted display qos trust interface

[ interface-type interface-number ] [ | Optional.
priority type and port
priority of the port. { begin | exclude | include } Available in any view
Configure the trusted priority type as auto.
[Sysname-GigabitEthernet2/1/1] qos trust auto
Displaying and maintaining priority mapping

display qos map-table [ dscp-dscp
| inbound [ up-dp | up-lp | up-up]
| outbound [ up-dp | up-fc | up-lp
Display priority mapping table
| up-rpr ] | color [ green | yellow | Available in any view
configuration information.
red ] [ up-dot1p | up-dscp | up-lp
| up-exp ] ] [ | { begin | exclude |
52
display qos trust interface
Display the trusted priority type [ interface-type interface-number ]
and port priority of the port. [ | { begin | exclude | include }
Priority mapping configuration example

As shown in Figure 19, different departments of a company assigned to different VLANs are
interconnected on the intranet through the ports of a router.
Configure priority mapping, so that the router enqueues packets based on the 802.1p priority of packets.
The priority mapping table is user-defined.
<Router> system-view
# Enter inbound up-up priority mapping table view and modify the priority mapping table parameters.
[Router] qos map-table inbound up-up
[Router-maptbl-in-up-up] import 0 1 export 0
[Router-maptbl-in-up-up] quit
# Configure the trusted priority type as auto for GigabitEthernet 2/1/1.

[Router] interface GigabitEthernet 2/1/1
[Router-GigabitEthernet2/1/1] qos trust auto
[Router-GigabitEthernet2/1/1] quit
53


54
Configuring congestion avoidance
Congestion avoidance overview

Avoiding congestion before it occurs is a proactive approach to improving network performance. As a
flow control mechanism, congestion avoidance actively drops packets when congestion is expected to
occur or deteriorate by monitoring the utilization of network resources (such as queues or memory buffers)
to alleviate the load on the network.
Compared with end-to-end flow control, this flow control mechanism controls the load of more flows in a
router. When dropping packets from a source end, it cooperates with the flow control mechanism (such
as TCP flow control) at the source end to regulate the network traffic size. The combination of the local
packet drop policy and the source-end flow control mechanism helps maximize throughput and network
use efficiency and minimize packet loss and delay.
Traditional packet drop policy

Tail drop is the traditional approach to congestion avoidance. In this approach, when the size of a queue
reaches the maximum threshold, all the subsequent packets are dropped.
This results in global TCP synchronization. If packets from multiple TCP connections are dropped, these
TCP connections go into the state of congestion avoidance and slow start to reduce traffic, but traffic
peak occurs later. Consequently, the network traffic jitters all the time.
RED and WRED

You can use random early detection (RED) or weighted random early detection (WRED) to avoid global
TCP synchronization.
Both RED and WRED avoid global TCP synchronization by randomly dropping packets. When the
sending rate of a TCP session slows down after its packets are dropped, the other TCP sessions remain
in high packet sending rates. Because always some TCP sessions in high sending rates exist, link
bandwidth is utilized more efficiently.
The RED or WRED algorithm sets an upper threshold and lower threshold for each queue, and processes
the packets in a queue following these rules:
When the queue size is shorter than the lower threshold, no packet is dropped.
When the queue size reaches the upper threshold, all subsequent packets are dropped.
When the queue size is between the lower threshold and the upper threshold, the received packets
are dropped at random. The drop probability in a queue increases along with the queue size under
the maximum drop probability.
Different from RED, WRED determines differentiated drop policies for packets with different IP
precedence values. Packets with a lower IP precedence are more likely to be dropped.
Average queue size

If the current queue size is compared with the upper threshold and lower threshold to determine the drop
policy, bursty traffic is not fairly treated. To solve this problem, WRED compares the average queue size
with the upper threshold and lower threshold to determine the drop probability.
The average queue size reflects the queue size change trend but is not sensitive to bursty queue size
changes, and thus bursty traffic can be fairly treated. The average queue size is calculated using the
55
formula: average queue size=previous average queue size(1-2-n)+Current queue size 2-n, where n can
be configured with the qos wred weighting-constant command.
Relation between WRED and the queuing mechanism

The relation between WRED and the queuing mechanism is shown in Figure 20:
Figure 20 Relationship between WRED and queuing mechanism
Introduction to WRED configuration

NOTE:
WRED is applicable to only SPE cards.
Configuration methods
You can configure WRED by configuring a WRED table in system view and then apply the WRED table
to an interface.
Introduction to wred parameters

Determine the following parameters before configuring WRED:
Upper threshold and lower thresholdWhen the average queue size is smaller than the lower
threshold, no packet is dropped. When the average queue size is between the lower threshold and
the upper threshold, the packets are dropped at random. The longer the queue is, the higher the
drop probability is. When the average queue size exceeds the upper threshold, subsequent packets
are dropped.
Drop precedenceA parameter used for packet drop. The value 0 corresponds to green packets,
the value 1 corresponds to yellow packets, and the value 2 corresponds to red packets. Red packets
are dropped preferentially.
Exponent used for average queue size calculationThe bigger the exponent is, the more
insensitive to real-time queue size changes the average queue size is.
56
Denominator for drop probability calculationThe bigger the denominator is, the smaller the
calculated drop probability is.
Configuring and applying a WRED table on an

interface
Configuring and applying a queue-based wred table
To configure and apply a queue-based WRED table:

2. Create a WRED table
and enter its view. qos wred queue table table-name N/A
3. Set the WRED exponent

queue queue-number Optional.
for average queue size
calculation. weighting-constant exponent The default setting is 8.
queue queue-number [ drop-level Optional.

4. Configure the other drop-level ] low-limit low-limit high-limit By default, the low-limit is 10224,
WRED parameters. high-limit [ discard-probability the high-limit is 10240, and the
discard-prob ] discard-prob is 100.

group.
6. Apply the WRED table
to the interface/port qos wred apply table-name N/A
group.
Displaying and maintaining WRED

display qos wred interface
Display WRED configuration [ interface-type interface-number ]
information on interfaces. [ | { begin | exclude | include }
Display configuration information display qos wred table

about a WRED table or all WRED [ table-name ] [ | { begin | exclude Available in any view
tables. | include } regular-expression ]
57
WRED configuration example
Apply a queue-based WRED table to interface GigabitEthernet 2/1/1.
# Enter system view
# Create a queue-based WRED table named queue-table1, and modify the lower and upper thresholds
and drop probability for each queue.
NOTE:
Configure the lower and upper thresholds for each queue in the WRED table depending on the interface
buffer size, which varies by interface type.
[sysname] qos wred queue table queue-table1

[Sysname-wred-table-queue-table1]queue 0 low-limit 128 high-limit 4096
discard-probability 100
[Sysname-wred-table-queue-table1] quit

# Apply the WRED table to interface GigabitEthernet 2/1/1.

[Sysname-GigabitEthernet2/1/1] qos wred apply queue-table1
58
Configuring aggregation CAR
Aggregation CAR overview

Aggregation CAR uses the same CAR for traffic on multiple ports. If aggregation CAR is enabled for
multiple ports, the total traffic on these ports must conform to the traffic policing parameters set in the
aggregation CAR.
Referencing aggregation CAR in a traffic behavior

Decide on aggregation CAR parameters and the traffic behavior to reference the aggregation CAR.
To reference aggregation CAR in a traffic behavior:

qos car car-name aggregative cir By default:

committed-information-rate [ cbs CBS is half of the traffic
8. Configure aggregation CAR committed-burst-size [ ebs transmitted over 500 ms at the
parameters. excess-burst-size ] ] [ pir rate of CIR.
peek-information-rate ] [ red
{ discard | pass } ] EBS is 0 bytes.
9. Enter traffic behavior view. traffic behavior behavior-name N/A
10. Reference the aggregation
CAR. car name car-name N/A
display traffic behavior

11. Display traffic behavior user-defined [ behavior-name ] [ |
configuration information. { begin | exclude | include }
Optional.
12. Display information about the display qos car name [ car-name ]
aggregation CAR. [ | { begin | exclude | include }
# Specify the aggregation CAR aggcar-1 to use the following parameters: CIR is 200, CBS is 2,000, and
red packets are dropped. Reference aggregation CAR aggcar-1 in traffic behavior be1.
[Sysname] qos car aggcar-1 aggregative cir 200 cbs 2000 red discard
59
[Sysname] traffic behavior be1
[Sysname-behavior-be1] car name aggcar-1
Displaying and maintaining aggregation CAR

display qos car name [ car-name ]
Display statistics about
[ | { begin | exclude | include } Available in any view
aggregation CAR policies.
Clear the statistics for aggregation

reset qos car name [ car-name ] Available in any view
CAR policies.
60
Configuring a queue scheduling profile
NOTE:
Queue scheduling profile configuration is applicable to only SPC cards.
Introduction to queue scheduling profile

In a queue scheduling profile, you can configure scheduling parameters for each queue. By applying the
queue scheduling profile to an interface, you can implement congestion management on the interface.
You can modify the scheduling parameters in a queue scheduling profile already applied to an interface.
Queue scheduling profiles support two queue scheduling algorithms: SP and WRR. In a queue
scheduling profile, you can configure SP, WRR, or both of them. When both algorithms are configured
in a queue scheduling profile, SP queues and WRR groups are scheduled in the strict priority order, that
is, in the descending order of queue ID, and in each WRR priority group, queues are scheduling based
on their weights, as shown in Figure 21.
Figure 21 Queue scheduling profile configured with both SP and WRR
Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0
SP Group WRR Group 1 WRR Group 2
Queue 7 has the highest priority. Its packets are sent preferentially.
Queue 6 has the second highest priority. Packets in queue 6 are sent when queue 7 is empty.
Queue 3, queue 4, and queue 5 are scheduled according to their weights. When both queue 6
and queue 7 are empty, WRR group 1 is scheduled.
Queue 1 and queue 2 are scheduled according to their weights. WRR group 2 is scheduled when
queue 7, queue 6, queue 5, queue 4, and queue 3 are all empty.
Queue 0 has the lowest priority, and it is scheduled when all the other queues are empty.
Configuring a queue scheduling profile

To configure a queue scheduling profile, create the queue scheduling profile first, and then enter the
queue scheduling profile view to configure its queue scheduling parameters. At last, apply the queue
scheduling profile to the specified interface.
To configure a queue scheduling profile:
61
2. Create a queue
scheduling profile and
enter queue scheduling qos qmprofile profile-name N/A
profile view.
Configure a queue to use SP: One queue can use only

queue queue-number sp one queue scheduling
3. Configure queue
Configure a queue to use WRR: algorithm.
scheduling parameters.
queue queue-number wrr group group-id By default, queues are
weight weight-value scheduled with SP.
4. Exit to system view. quit N/A
Use either command.

Settings in interface view
5. Enter interface view or interface interface-type interface-number
are effective on the current
port group view. Enter port group view: interface. Settings in port
port-group manual port-group-name group view are effective on
all ports in the port group.
6. Apply the queue
scheduling profile to the qos apply qmprofile profile-name N/A
interface or port group.
NOTE:
Only one queue scheduling profile can be applied to an interface.
The queue IDs in a WRR group must be successive. If not, queue scheduling may be performed
inaccurately.
Displaying and maintaining queue scheduling

profiles
display qos qmprofile
Display the configuration of queue configuration [ profile-name ] [ |
scheduling profiles. { begin | exclude | include }
display qos qmprofile interface

Display queue scheduling profiles [ interface-type interface-number ]
already applied to interfaces. [ | { begin | exclude | include }
62
Queue scheduling profile configuration example
Configure a queue scheduling profile on GigabitEthernet 3/1/1 to do the following:
Assign queue 7 the highest priority to forward its packets preferentially.
Assign queue 4, queue 5, and queue 6 to WRR group 1 to schedule them according to their
weights, which are 1, 5, and 10, respectively. When queue 7 is empty, WRR group 1 is scheduled.
Assign queue 1, queue 2, and queue 3 to WRR group 2 to schedule them according to their weights,
which are 1, 10, and 20, respectively. When queues 4 to 7 are all empty, WRR group 2 is
scheduled.
Assign queue 0 the lowest priority. Queue 0 is scheduled when all the other queues are empty.
# Create queue scheduling profile qm1.

[Sysname] qos qmprofile qm1
[Sysname-qmprofile-qm1]
# Configure queue 7 to use SP queuing.

[Sysname-qmprofile-qm1] queue 7 sp
# Assign queue 4, queue 5, and queue 6 to WRR group 1, with the weight of 1, 5, and 10, respectively.
[Sysname-qmprofile-qm1] queue 4 wrr group 1 weight 1
# Assign queue 1, queue 2, and queue 3 to WRR group 2, with the weight of 1, 10, and 20, respectively.
# Configure queue 0 to use SP queuing.

[Sysname-qmprofile-qm1] queue 0 sp
[Sysname-qmprofile-qm1] quit
# Apply queue scheduling profile qm1 to the incoming traffic of GigabitEthernet 3/1/1.
[Sysname] interface gigabitethernet 3/1/1
[Sysname-GigabitEthernet3/1/1] qos apply qmprofile qm1
After the configuration is completed, GigabitEthernet 3/1/1 performs queue scheduling as specified in
queue scheduling profile qm1.
63
Configuring QoS traffic accounting
QoS traffic accounting overview

A router provides two counters to collect outbound and inbound traffic statistics.
You can configure each counter to collect statistics for traffic on a card, or traffic identified by any
combination of interface, VLAN, local precedence, and drop precedence.
Per-port queue-based accounting overview

Per-port queue-based accounting collects statistics for each port on a per-queue basis, such as the
number of forwarded or dropped packets.
NOTE:
The per-port queue-based accounting function is enabled by default. You can use the display qos
queue-statistics interface command to view the statistics.
Configuring traffic accounting

To configure traffic accounting:

qos traffic-counter { inbound |

outbound } { counter0 | counter1 }
2. Enable traffic accounting and slot slot-number [ interface
By default, traffic accounting is
specify the type of traffic. interface-type interface-number |
disabled.
vlan vlan-id | local-precedence
lp-value | drop-priority dp-value ]
*
NOTE:
This feature is applicable to only the interfaces operating in bridge mode on SPC cards.
Displaying and maintaining traffic accounting and

per-port queue-based accounting
64
display qos traffic-counter
{ inbound | outbound } { counter0
Display traffic statistics. | counter1 } slot slot-number [ | Available in any view
{ begin | exclude | include }
display qos queue-statistics

interface [ interface-type
Display statistics collected by the
interface-number ] [ pvc { pvc-name
per-port queue-based accounting Available in any view
[ vpi/vci ] | vpi/vci } ] [ outbound ]
function.
[ | { begin | exclude | include }
reset qos traffic-counter { inbound

Clear the traffic statistics collected
| outbound } { counter0 | Available in user view
by a counter.
counter1 } slot slot-number
65
Configuring FR QoS
Overview
FR QoS allows you to deploy QoS (frame relay traffic shaping) on each PVC of an FR interface. By
configuring Committed Information Rate Allowed (CIR ALLOW), which is the transmitting rate an FR
network allows, you can guarantee CIR ALLOW for user data transmission when no congestion occurs in
the network.
Why FRTS
Frame Relay Traffic Shaping (FRTS) limits traffic of packets and bursty packets sent from a PVC, so that
these packets can be transmitted at relatively even rate.
In an FR network, the bottleneck often occurs at the network segment juncture if the bandwidth of different
segments does not match. As shown in Figure 22, Router B transmits packets to Router A at the rate of 128
kbps whereas the maximum interface rate of Router A is only 64 kbps. Then, bottleneck occurs at the
place where Router A is connected to the FR network, and results in congestion that interrupts normal
data transmission. With FRTS applied on the outgoing interface Serial2/1/6:0 of Router B, the interface
can transmit packets at a relatively even rate of 64 kbps, and the network congestion is avoided.
Figure 22 FRTS implementation
FRTS is applied on the outgoing interfaces of the router. It allows you to configure the CIR ALLOW
parameter. FR PVCs can transmit packets at the rate of CIR ALLOW when the network is normal.
How FRTS works

FRTS is implemented using token buckets. The meanings of the related parameters in the protocol are
modified as required by the actual algorithm and principles. For how a token bucket works, see Figure
23.
66
Figure 23 How a token bucket works
In the token bucket approach, packets requiring traffic control are put into the token bucket for processing
before being sent out. If enough tokens are available in the token bucket for sending these packets, the
packets are allowed to pass. If the number of tokens in the token bucket is not enough for sending these
packets, these packets are put into the FR class queue (the FRTS queue in FRTS implementation). Once
enough tokens are available in the token bucket, the packets are taken out of the FR class queue for
transmission. In this way, you can control the traffic of a certain class of packets. Tokens are in the unit
of bits.
The FR protocol-provisioned related parameters correspond to the FRTS parameters as such: CIR ALLOW
defines the number of tokens put into the token bucket per second.
Configuring FR QoS
FR QoS configuration task list
Complete the following tasks to configure FR QoS:
Task Remarks
Creating and configuring an FR class Required
Configuring FRTS Required
Creating and configuring an FR class

The system integrates QoS services on FR PVCs into FR classes to provide a flexible and complete solution
for FR traffic control and service quality. Before configuring QoS services such as FRTS, you must create
an FR class first, and then you can configure all the QoS parameters in the FR class. Then, you can
associate the FR class with an FR interface/subinterface or FR PVC to apply the set of QoS network
service parameters to all the PVCs of the FR interface/subinterface or the FR PVC.
You can associate an FR class with one or more FR interfaces/subinterfaces or PVCs.
An FR PVC providing QoS services searches the FR class in the following order:
The FR class associated with the FR PVC
The FR class of the FR interface/subinterface to which the FR PVC belongs
To configure and create an FR class:
67
Step Commands Remarks
1. Enter system
system-view N/A
view.
2. Create an FR
By default, no FR class
class and enter fr class class-name
is created.
FR class view.
3. Return to system
quit N/A
view.
(Approach I) Associate the FR class with an FR interface:
a. Enter FR interface view:
interface interface-type interface-number
b. Associate the FR class with the FR interface: Use either approach
4. Associate the FR fr-class class-name or all approaches.
class with an FR (Approach II) Associate the FR class with an FR PVC: By default, no FR class
interface or FR c. Enter FR interface view: is associated with an
PVC. interface interface-type interface-number FR PVC or an FR
d. Enter FR PVC view: interface.
fr dlci dlci
e. Associate the FR class with the FR PVC:
fr-class class-name
NOTE:
After using the fr class command to create an FR class, you can enter FR class view, where you can
configure parameters for FRTS. If you configure no parameters, the CIR is 56000 bps by default.
You can associate an FR class with an FR interface/subinterface or a DLCI. When an FR class is
associated with an FR main interface, it takes effect on all the DLCIs of the FR main interface, including
the DLCIs of the FR subinterfaces of the FR main interface. When an FR class is associated with an FR
subinterface, it takes effect on all the DLCIs of the FR subinterface. When an FR class is associated with
a DLCI, it takes effect on only the DLCI.
You can associate different FR classes with an FR main interface, its subinterfaces, and its DLCIs, and
these FR classes are in the ascending priority order.
To make the FR class configuration take effect, you must enable FRTS on the FR main interface.
Configuring FRTS
To configure FRTS:

2. Enter FR interface view. N/A
interface-number
3. Enable FRTS. fr traffic-shaping By default, FRTS is disabled.
4. Exit FR interface view. quit N/A
This step is required for FRTS to

5. Enter FR class view. fr class class-name
take effect.
6. Set the CIR ALLOW for FR cir allow [ inbound | outbound ] Optional.
PVCs. committed-information-rate The default setting is 56000 bps.
68
NOTE:
FRTS is applied to the interfaces sending FR packets and is usually applied to the DTE side of an FR
network.
You can configure FRTS on only an FR main interface. The FRTS configuration takes effect on the FR main
interface and all the DLCIs of the FR subinterfaces.
Displaying and maintaining FR QoS

Display the mapping relationship between display fr class-map { fr-class
FR classes and interfaces (including the class-name | interface interface-type
DLCIs of an interface, subinterfaces of an interface-number } [ | { begin | exclude
interface, and the DLCIs of subinterfaces). | include } regular-expression ]
display fr statistics [ interface

Display the statistics about data interface-type interface-number ] [ |
transmitted and received through FR. { begin | exclude | include }
FR QoS configuration example

FRTS configuration example
As shown in Figure 24, limit the average transmit rate of the router to 96 kbps.
# Create an FR class and configure FRTS parameters for the FR class.
[Router] fr class 96k
[Router-fr-class-96k] cir allow 96000
[Router-fr-class-96k] quit
# Configure Serial 2/1/6:0 as an FR interface and enable FRTS on it.

[Router] interface serial 2/1/6:0
[Router-Serial2/1/6:0] link-protocol fr
[Router-Serial2/1/6:0] ip address 1.1.1.1 255.255.255.0
[Router-Serial2/1/6:0] fr traffic-shaping
# Create an FR PVC and associate the FR PVC with FR class 96k.
69
[Router-Serial2/1/6:0] fr dlci 16
[Router-fr-dlci-Serial2/1/6:0-16] fr-class 96k
70
Configuring HQoS
HQoS overview
Introduction to HQoS
Quality of Service (QoS) is widely used in networks to ensure transmission quality and provide
differentiated service levels for various data flows.
In response to increased network users and service types, Ethernet devices are required not only to further
subdivide service traffic but also to uniformly manage and hierarchically schedule traffic by user in
addition to service. This is beyond the capability of traditional QoS.
Hierarchical Quality of Service (QoS) uniformly manages traffic and hierarchically schedules traffic by
user, network service, and application. It provides more granular traffic control and quality assurance
services than traditional QoS.
HQoS-capable devices can hierarchically classify and schedule traffic, for example, by both user and
application, and control internal resources based on policies at different levels. HQoS guarantees QoS
for advanced users and saves the overall networking costs.
How HQoS works

To achieve hierarchical scheduling, Hierarchical Quality of Service (HQoS) was developed. It organizes
a scheduler policy into a hierarchical tree that consists of a root node, branches nodes, and leaf nodes,
where:
The root node is the convergence point for all traffic and corresponds to a scheduler.
A branch node is located in the middle of the hierarchy and corresponds to a scheduler.
A leaf node is at the bottom layer and corresponds to a scheduling queue.
A scheduler can schedule multiple scheduling queues or schedulers. Each node is configured with match
criteria and control parameters. The match criteria determine the traffic direction and the control
parameters define control actions for traffic traversing this node.
Parent nodes and nested child nodes also exist in the hierarchical tree. A parent node is the convergence
point for the traffic of its child nodes. Traffic that has been classified and regulated at a child node will
be re-classified and regulated together with other traffic streams at the parent node. By configuring
match criteria and actions oriented to different levels (user-level, service level, and traffic type level, for
example) on the child and parent nodes, you can achieve hierarchical traffic management.
Figure 25 shows how HQoS works. The QoS-local-ID range next to a node is the match criteria of the
node. Strict priority, weighted round robin (WRR), or generic traffic shaping (GTS) in the arrow pointing
to an upstream node is the control parameter of the current node. With the topmost scheduler policy
applied to an interface, you can classify and manage the inbound traffic of the interface multiple times.
71
Figure 25 How HQoS works
sp
s
gt
wrr
gt
s
2
Different from traditional single-layer QoS, HQoS manages traffic in scheduling queues at multiple levels
including physical level, logical level, and application level or service level. For example, at the physical
level, you can manage the total bandwidth of physical interfaces; at the logical level, you can manage
the per-user bandwidth of the interface; at the service level, you can manage per-application bandwidth
for a user. Through multi-level traffic management, HQoS helps service providers implement multi-service,
multi-user service management.
Terminology
Forwarding class
A forwarding class is a scheduling entity (a leaf node) in the scheduler policy tree. A forwarding
class corresponds to a scheduling queue. Packets are assigned to different scheduling queues
according to the specified mapping rules. The parameters associated with a forwarding class
determine the behavior of the scheduling queue.
As shown in Table 6, the system pre-defines four forwarding classes: BE, AF, EF, and NC, in the
descending order of priority.
Table 6 Predefined forwarding classes
Forwarding Forwarding class Forwarding class

Service type
class name name expansion type
Highest-priority forwarding services, such
NC Network Control
as network control packet transmission
High-priority services
Delay/jitter-sensitive services, such as
EF Expedited Forwarding
voice and video traffic transmission
Services guaranteeing transmission Services

AF Assured Forwarding quality, such as VPN and data packet guaranteeing
transmission transmission quality
Best-effort services, such as common

BE Best Effort Best-effort services
network browsing services
72
Forwarding group
A forwarding group is a scheduling entity (a branch node) in the scheduler policy tree. Multiple
forwarding groups or forwarding classes can be nested in a forwarding group. A forwarding
group corresponds to a scheduler. The parameters associated with a forwarding group determine
the scheduling priority and bandwidth resources assigned to the forwarding group.
Forwarding profile
Forwarding profiles are scheduling rules configured for the scheduling entities in a scheduler
policy. A forwarding profile contains the scheduling priority, scheduling weight, shaping
parameters, and drop parameters. It determines the actions to take on the traffic passing the
forwarding class or forwarding group associated with the forwarding profile.
Drop profile
Drop profiles are drop rules defined for queues. As dropping packets is a traffic management
behavior, you must nest a drop profile within a forwarding profile for the drop profile to take
effect.
Scheduler policy
Scheduler policies are sets of scheduling entities. From an scheduler policy, a hierarchical tree of
schedule entities stretches out with forwarding groups at the second layer and forwarding classes
or other forwarding groups under the second-layer forwarding groups.
Scheduling layer
A scheduling layer indicates the nesting layer of a scheduling entity in the scheduler policy. A
forwarding group must match certain criteria at the corresponding layer.
Instantiation
Instantiation is a special match operation. A scheduling entity matches criteria in the instantiation
process. An instantiation entity is the result of instantiating a forwarding group. A forwarding
group can have multiple instances, with each using a distinct scheduler. The difference between
the instances of a forwarding group lies in only the instantiation rules.
Instantiation can be performed in one of the following modes:
{ Match modeYou must explicitly specify instantiation criteria for a forwarding group to be
instantiated.
{ Group modeYou do not need to specify instantiation criteria explicitly for a forwarding group
to be instantiated, but you must do that for the child forwarding groups in the forwarding group
to be instantiated.
HQoS configuration task list

Configuring HQoS is to create a scheduler policy tree. You must create nodes (scheduling entities) first,
associate these insular nodes and specify traffic actions for each node then, and at last, configure match
criteria for each branch nodes of the tree to determine the path of the traffic in the tree.
73
Figure 26 HQoS configuration structure
As shown in Figure 26, the HQoS configuration procedure goes through the following phases:
1. Create scheduling entities and configure forwarding profiles for them. More specifically, create
nodes forwarding group A, forwarding group A1, forwarding group A2, forwarding group B,
forwarding group B1, and forwarding group B2 and configure traffic actions forwarding profile A,
forwarding profile A1, forwarding profile A2, forwarding profile B, forwarding profile B1,
forwarding profile B2.
2. Associate the scheduling entities with the forwarding profiles. More specifically, nest these nodes
(such as nesting forwarding group A1 and forwarding group A2 in forwarding group A, nest BE,
AF, EF, and NC in forwarding group A1) and then associate each node with its forwarding profile
(such as associating forwarding group A with forwarding profile A). In this phase, the nodes are
organized into a tree.
3. Instantiate forwarding groups. More specifically, configure match criteria for each node (for
example, assign packets of QoS-local-ID 11 through QoS-local-ID 20 to forwarding group A).
4. Apply the organized scheduler policy to an interface.
Complete the following tasks to configure HQoS:
Task Remarks
Configuring an forwarding class Optional
Configuring a drop profile Optional
Configuring an forwarding profile Required
HQoS basic configuration Configuring an forwarding group Required
Configuring an scheduler policy Required
Instantiating an forwarding group Required
Applying an scheduler policy to an interface Required
Copying an forwarding group Optional

Copying an forwarding
group or scheduler policy
Copying an scheduler policy Optional
74
HQoS basic configuration
Configuring an forwarding class
In HQoS, a packet that arrives at a port is classified and mapped to a forwarding class before it can be
assigned to a scheduling queue.
Map traffic to forwarding classes in one the following methods:
Using a QoS policy to classify traffic into classes, configure the action of marking forwarding
classes in a traffic behavior, associate each traffic class with the traffic behavior in a QoS policy,
and then apply the QoS policy to an interface. Traffic classes are mapped to forwarding classes.
With this method, you can classify packets based on attributes such as packet priority, IP address,
MAC address, VLAN, and protocol type.
Using a user precedence-to-forwarding class (UP-to-forwarding class) mapping table to map
packets with certain user precedence to the forwarding class.
NOTE:
For how to configure QoS policies and UP-to-forwarding class mapping tables, see the chapters
Configuring a QoS policy and Configuring priority mapping.
To mark forwarding classes for packets:
Step Command
traffic behavior behaviorname
behavior view.
3. Configure the action of marking forwarding
remark forwarding-class { id fc-id | name fc-name }
classes.
Configuring a drop profile

Packet dropping can be used for congestion avoidance. A router can assign drop levels for received
packets and color the received packets. Packets of different colors can be assigned to different queues.
You can configure drop parameters (queue length threshold for example) for packets of different colors.
When the queue length reaches a certain threshold, the drop action is performed. An HQoS drop profile
supports two drop algorithms:
Tail dropPacket drop is determined by the specified drop threshold. When the queue length
reaches the upper threshold, all newly arriving packets are dropped.
WREDDrop levels are taken into account for packet dropping in each queue. When the queue
length of packets in a color (red, yellow, or green) exceeds the lower threshold, the system begins
to drop packets at a certain drop probability before the queue length reaches the upper threshold.
When the queue length exceeds the upper threshold, all newly arriving packets are dropped.
The system creates a pre-defined drop profile automatically. The pre-defined drop profile is named
default and numbered 0. The contents of the pre-defined drop profile cannot be modified.
Configuring a drop profile includes:
Creating a user-defined drop profile
75
Modifying the parameters of the user-defined drop profile
Creating a user-defined drop profile

To create a user-defined drop profile:

This command can either create a

2. Create a user-defined drop qos drop-profile dp-name [ id user-defined drop profile or enter
profile. dp-id ] the view of an existing drop profile
(user-defined or pre-defined).
NOTE:
The default contents of a newly created drop profile are the same as those of the pre-defined drop profile.
Modifying the parameters of the user-defined drop profile

To modify the contents of the user-defined drop profile:

2. Enter user-defined drop profile qos drop-profile dp-name [ id

N/A
view. dp-id ]
red low-limit low-limit high-limit

3. Configure drop parameters
high-limit discard-probability Optional.
for red packets.
discard-prob
yellow low-limit low-limit high-limit

for yellow packets.
discard-prob
green low-limit low-limit high-limit

for green packets.
discard-prob
6. Set the exponent for average
weighting-constant exponent Optional.
queue length calculation.
Configuring an forwarding profile

In a scheduler policy tree, each node (forwarding group or forwarding class) must be configured with a
forwarding profile. A forwarding profile contains a set of actions to be taken on traffic passing the node
for traffic policing and traffic control.
Creating forwarding profiles is required in scheduler policy configuration. The system creates a
pre-defined forwarding profile automatically. The pre-defined forwarding profile is named default and
numbered 0. The contents of the pre-defined forwarding profile cannot be modified.
Configuring a forwarding profile includes:
Creating a user-defined forwarding profile
Modifying the contents of the user-defined forwarding profile
76
Creating a user-defined forwarding profile
To create a user-defined forwarding profile:


user-defined forwarding profile or
2. Create a user-defined qos forwarding-profile fp-name [ id
enter the view of an existing
forwarding profile. fp-id ]
forwarding profile (user-defined or
pre-defined).
Modifying the user-defined forwarding profile

A forwarding profile includes a set of WFQ weight parameters, a set of traffic shaping parameters,
minimum guaranteed bandwidth, and an existing drop profile to be referenced. For more information
about drop profile configuration, see Configuring a drop profile.
To modify the user-defined forwarding profile:

2. Enter user-defined forwarding qos forwarding-profile fp-name [ id

N/A
profile view. fp-id ]
3. Configure the WFQ weight Optional.

wfq [ weight weight-value ]
parameters. The WFQ weight defaults to 1.
Optional.
4. Configure the GTS By default, no GTS parameter is

gts cir cir-value [ cbs cbs-value ] configured for a forwarding
parameters.
profile, and traffic rate is not
limited.
Optional.
By default, no minimum
5. Configure the minimum guaranteed bandwidth is
bandwidth bandwidth-value
guaranteed bandwidth. configured in a forwarding profile.
On the SR8800, this command
only applies to EF queues.
Optional.
6. Reference a drop profile. drop-profile dp-name By default, a forwarding profile

does not reference any drop
profile, and tail-drop is adopted.
77
NOTE:
A forwarding profile with GTS parameters configured takes effect at only the forwarding group-1 layer
and the forwarding group-2 layer for an Ethernet interface or POS interface, and only the forwarding
group-1 layer for other interfaces.
A forwarding profile with the minimum guaranteed bandwidth takes effect at only the forwarding
group-2 layer for an Ethernet interface or POS interface, and only the forwarding group-1 layer for other
interfaces.
A forwarding profile with WFQ weight parameters takes effect at only the forwarding group-1 layer and
the forwarding class layer for an Ethernet interface or POS interface, and only the forwarding class layer
for other interfaces.
A forwarding profile with a drop profile configured takes effect at only the forwarding class layer.
Modifying a forwarding profile that has been applied to an interface may fail due to insufficient
hardware resources.
Configuring an forwarding group

As forwarding groups are basic scheduling entities and instantiation objects in a scheduler policy tree,
creating forwarding groups is required in scheduler policy configuration.
The system creates a pre-defined forwarding group automatically. The pre-defined forwarding group is
named default and numbered 0. The contents of the pre-defined forwarding group cannot be modified.
Configuring a forwarding group includes:
Creating a user-defined forwarding group
Nesting forwarding classes in the forwarding group
Nesting forwarding groups in the forwarding group
Creating a user-defined forwarding group

To create a user-defined forwarding group:


user-defined forwarding group or
2. Create a user-defined qos forwarding-group fg-name [ id
enter the view of an existing
forwarding group. fg-id ]
forwarding group (user-defined or
pre-defined).
Nesting an forwarding class in the forwarding group and associate the forwarding class with an
forwarding profile
When nesting a forwarding class in a forwarding group, you must associate the forwarding class with a
forwarding profile.
This forwarding profile defines the action that should be taken on the traffic assigned to the scheduling
queue of the forwarding class.
You can nest multiple forwarding classes in a forwarding group. A forwarding class can be nested in
multiple forwarding groups and associated with a distinct forwarding profile in each forwarding group.
78
To nest a forwarding class in the user-defined forwarding group:
Step Command
2. Enter user-defined forwarding group view. qos forwarding-group fg-name [ id fg-id ]

3. Associate an forwarding class with an
forwarding-class fc-name profile fp-name
forwarding profile.
NOTE:
Each time you try to associate a forwarding class with a forwarding profile, the system checks the
contents of the forwarding profile. If the forwarding profile conflicts with the forwarding class, your
association attempt will fail.
In addition to nesting a new forwarding class in a forwarding group and associating a forwarding
profile with the newly nested forwarding class, the forwarding-class fc-name profile fp-name command
allows you to associate an existing forwarding class in a forwarding group with a new forwarding
profile.
You cannot nest a forwarding class in a forwarding group with nested forwarding groups.
Nesting a child forwarding group in the forwarding group and associate the child forwarding group
with an forwarding profile
When nesting a child forwarding group in another forwarding group, you must associate the child
forwarding group with a forwarding profile.
This forwarding profile defines the scheduling action that should be taken on the traffic of the child
forwarding group.
You can nest multiple forwarding groups in a forwarding group. A forwarding group can be nested in
multiple forwarding groups and associated with a distinct forwarding profile in each parent forwarding
group.
To nest a child forwarding group in the forwarding group:
Step Command
2. Enter user-defined forwarding group view. qos forwarding-group fg-name [ id fg-id ]

3. Associate a child forwarding group with an
forwarding-group sub-fg-name profile fp-name
forwarding profile.
79
NOTE:
Each time you try to associate a forwarding group with a forwarding profile, the system checks the
contents of the forwarding profile. If the forwarding profile conflicts with the forwarding group, your
In addition to nesting a new forwarding group in a forwarding group and associating a forwarding
profile with the newly nested forwarding group, the forwarding-group sub-fg-name profile fp-name
command allows you to associate an existing child forwarding group in a forwarding group with a new
forwarding profile.
You cannot nest a child forwarding group in a forwarding group with nested forwarding classes.
A forwarding group with child forwarding groups nested cannot be nested in another forwarding
group.
A forwarding group cannot nest itself.
Configuring an scheduler policy

NOTE:
The scheduler policy configuration conflicts with the port QoS configuration (including queue-based GTS,
port WRED, and hardware queue scheduling). For more information about port QoS, see the chapters
Configuring traffic shaping and line rate, Configuring congestion avoidance, and Configuring
hardware congestion management.
A scheduler policy is a set of hierarchical scheduling entities. By applying a scheduler policy in the
outbound or inbound direction of an interface, you can perform hierarchical QoS for the outgoing or
incoming traffic of the interface.
You must create a scheduler policy before organizing forwarding groups and forwarding classes into a
scheduler policy tree.
Configuring a scheduler policy includes:
Creating an scheduler policy
Nesting forwarding groups in the scheduler policy
Creating an scheduler policy

To create a scheduler policy:


qos scheduler-policy sp-name [ id
2. Create an scheduler policy. scheduler policy or enter the view
sp-id ]
of an existing scheduler policy.
Nesting an forwarding group in the scheduler policy

Similar to nesting child forwarding groups in a parent forwarding group, you can nest a forwarding
group in a scheduler policy by associating the forwarding group with a forwarding profile in scheduler
policy view.
You can nest multiple forwarding groups in a scheduler policy. A forwarding group can be nested in
multiple scheduler policies and associated with a different forwarding profile in each scheduler policy.
80
To nest a forwarding group in the user-defined scheduler policy:
Step Command
2. Enter scheduler policy view. qos scheduler-policy sp-name [ id sp-id ]

3. Associate an forwarding group with an
forwarding-group fg-name profile fp-name
forwarding profile.
NOTE:
Each time you try to associate a forwarding group with a forwarding profile, the system checks the
contents of the forwarding profile. If the forwarding profile conflicts with the forwarding group, your
In addition to nesting a new forwarding group in a scheduler policy and associating a forwarding
profile with the newly nested forwarding group, the forwarding-group sub-fg-name profile fp-name
command allows you to associate an existing forwarding group in a scheduler policy with a new
forwarding profile. Associating an instantiated forwarding group with a new forwarding profile can
cause all the instances of the forwarding group to replace the current forwarding profile with the new
forwarding profile.
The number of forwarding groups (including instances of forwarding groups) that can be nested at a
layer in the scheduler policy tree is limited. Once the limit is reached, your nesting attempt will fail.
Because forwarding group nodes on a scheduler policy tree must be unique, you cannot nest the same
forwarding group in the scheduler policy more than once. Forwarding group instances are not
considered here.
Instantiating an forwarding group

Why instantiation
The most significant feature of HQoS is that it can perform multi-level, multi-service control and
scheduling for traffic. For this purpose, the system must classify traffic of forwarding group nodes by user
and service.
Instantiation can:
Specify the layer of an forwarding group node in the scheduler policy tree
Differentiate traffic by user or service
A forwarding group can be instantiated into multiple forwarding group instances. These forwarding
group instances can be considered as special forwarding group entities. They derive all the features from
the source forwarding group, including the associated forwarding profile, the nested forwarding classes
or forwarding groups, and the forwarding profiles associated with these nested forwarding classes or
forwarding groups. The difference between an instance and its source forwarding group is that the
instance is configured with an instantiation rule (or a match criterion) for traffic classification by service
or user type.
81
Figure 27 Instantiated forwarding groups in an scheduler policy
(User 1) FC-A
2-A
QoS-local-ID 10
FC-B
1- A 2-B

FC
(User 2) FC-A
QoS-local-ID 20 2-A
FC-B
1-A 2-B

0
FC
1-B 2-C
2- B
PORT layer Layer 1 Layer 2 FC layer
Figure 27 shows the results of a sample instantiation: forwarding group A at Layer 1 is instantiated by
QoS-local-ID into two instances with the same internal structure.
Instantiation mode
Instantiation can be performed in one of the following modes:
Match modeInstances created from the same forwarding group in this mode are differentiated by
their match criteria. Traffic satisfying the match criteria configured for a forwarding group enters the
scheduler of the forwarding group. Match criteria can be QoS-local IDs. You can mark a packet
with a QoS-local ID as needed, for example, based on its source IP address. Packets from different
IP address segments can be marked with different QoS-local IDs.
Group modeAn instance created in this mode is only a set of child forwarding groups nested in
the source forwarding group. No match criteria are configured for the source forwarding group.
However, the child forwarding groups nested in the source forwarding group must be configured
with match criteria.
Because forwarding classes cannot be instantiated, you cannot instantiate a forwarding group with
nested forwarding classes in the group mode.
Instantiating an forwarding group

When instantiating a forwarding group, you must specify the scheduler policy layer of the forwarding
group. The forwarding groups nested in a scheduler policy are at Layer 1, and the forwarding groups
nested in a forwarding group at Layer 1 are at Layer 2. Instantiation of a forwarding group must be
performed in the corresponding layer view in the specified scheduler policy.
To instantiate a forwarding group:
82
2. Enter scheduler policy view. qos scheduler-policy sp-name [ id sp-id ] N/A
3. Enter scheduler policy layer view. layer { 1 | 2 } N/A

In match mode:
forwarding-group fg-name match [ extended ]
4. Instantiate a user-defined qos-local-id { local-id-list | local-id1 to Use either
forwarding group. local-id2 } command.
In group mode:
forwarding-group fg-name group
NOTE:
When performing forwarding group instantiation, instantiate a parent forwarding group before
instantiating its child forwarding groups. Before removing instances of a parent forwarding group, you
must remove all instances of the child forwarding groups first.
To instantiate a parent forwarding group and its child forwarding groups in the match mode, the
instantiation rule of the parent node must be the sum of the instantiation rules of the child forwarding
groups, and the instantiation rules of child forwarding groups cannot overlap.
You can instantiate a forwarding group multiple times, but the instantiation rules must not overlap.
The pre-defined forwarding group nested in a scheduler policy has been instantiated in the group
mode. You cannot modify or remove the instantiation rule of the pre-defined forwarding group.
You can change the QoS-local ID of a packet by marking the QoS-local ID.
To set the QoS-local ID marking action for a traffic behavior:
Step Command
2. Create a behavior and enter behavior
traffic behavior behavior-name
view.
3. Configure the QoS-local ID marking
remark qos-local-id local-id-value
action for the traffic behavior.
4. Exit behavior view. quit
Applying an scheduler policy to an interface

A scheduler policy can be applied only in the outbound direction of an interface. After being applied,
the scheduler policy can control and manage traffic.
Before applying a scheduler policy to an interface, complete the following tasks:
Configure child nodes for all forwarding group nodes nested in the scheduler policy
Nest forwarding classes in a forwarding group with nested forwarding classes. Forwarding class
nesting of a forwarding group node is considered complete only when all the pre-defined
forwarding classes are nested.
Instantiate all forwarding group nodes in the scheduler policy tree. A forwarding group node that
has not been instantiated cannot appear in a scheduler policy tree.
83
Applying an scheduler policy to an interface
To apply a scheduler policy to an interface:

Enter Ethernet interface

view, ATM interface view,
Use either command.
MP-group interface view, or
POS interface view: Configured in interface view, the
2. Enter interface view or port setting takes effect on the current
group view. interface only. Configured in port
interface-number
group view, the setting takes effect
on all ports in the port group.
port-group manual
group-name
3. Apply an scheduler policy to the qos apply scheduler-policy

N/A
interface or port group. sp-name outbound
NOTE:
Only one scheduler policy can be applied to an interface at a time.
You cannot change the structure of a scheduler policy tree that has been applied to an interface.
However, you can associate a forwarding group or forwarding class with a new forwarding profile or
modify the contents of associated forwarding profiles in the scheduler policy tree. To change the
structure of the scheduler policy tree, for example, to add/remove forwarding class or forwarding group
nodes or perform instantiation, you must remove the scheduler policy from the interface first.
An HQoS scheduler policy is mutually exclusive with class-based queuing (CBQ) on an interface.
Copying an forwarding group or scheduler policy

You can copy forwarding groups and scheduler policies to simplify the configuration procedure.
Copying an forwarding group

You can copy a forwarding group to generate multiple destination forwarding groups at a time. They are
numbered by the system automatically.
Except their names and numbers, these destination forwarding groups are the same.
The number of forwarding groups allowed to be created is limited. When the limit is reached, the
copying process stops and no more destination forwarding groups can be created.
To copy a forwarding group:
Step Command
2. Copy an forwarding group to multiple qos copy forwarding-group fg-source to

destination forwarding groups. fg-dest&<1-8>
84
Copying an scheduler policy
By copying a scheduler policy, only one destination scheduler policy can be generated. The number of
the destination scheduler policy is automatically assigned by the system.
Except the name and number, the destination scheduler policy is the same as the source scheduler policy,
including in instantiation rules.
To copy a scheduler policy:
Step Command
2. Copy an scheduler policy. qos copy scheduler-policy sp-source to sp-dest
Displaying and maintaining HQoS

display qos forwarding-class
Display forwarding class
[ fc-name ] [ | { begin | exclude | Available in any view
information.
display qos forwarding-group

Display forwarding group
[ fg-name ] [ | { begin | exclude | Available in any view
information.
display qos drop-profile

Display drop profile information. [ dp-name ] [ | { begin | exclude | Available in any view
display qos forwarding-profile

Display forwarding profile
[ fp-name ] [ | { begin | exclude | Available in any view
information.
display qos scheduler-policy name

Display scheduler policy
[ sp-name ] [ | { begin | exclude | Available in any view
information.
display qos scheduler-policy

Display the scheduler policy interface [ interface-type
information and traffic statistics for interface-number [ outbound ] ] [ | Available in any view
a specified port or all ports. { begin | exclude | include }
display qos scheduler-policy

diagnosis interface [ interface-type
Display the diagnosis information
interface-number [ outbound ] ] [ | Available in any view
of a specified port or all ports.
{ begin | exclude | include }
HQoS configuration examples
85
NOTE:
HQoS configuration example I and HQoS configuration example II are both applicable to Ethernet
interfaces and POS interfaces.
Only HQoS configuration example II is applicable to ATM interfaces, serial interfaces, and MP-group
interfaces.
HQoS configuration example I

QoS-local-ID mode identifies services by QoS-local ID. Traffic accessing a backbone router fall into four
types: VoIP, VoD, VPN, and Internet. You can assign different IP segment to carry different services, and
then perform rate limiting and bandwidth management for each type of service. For a service type, you
can further differentiate its users.
Assume that the rate limit for the outgoing interface is 1000 Mbps.
Table 7 and Table 8 present the overall requirements for each service and the requirements for the user
groups of each service respectively.
Table 7 Requirements for the services
Requirements (right)
IP precedence Queue scheduling priority Rate limit
Service type (below)
VoIP 6, 7 Strict priority 100 Mbps
VoD 4, 5 High (bandwidth assured) 450 Mbps
VPN 2, 3 Medium (bandwidth assured) 300 Mbps
Using the surplus

Internet 0, 1 Low
bandwidth
Table 8 Requirements for the user groups of each service
Number of groups Bandwidth assignment IP assignment
VoIP service 2 Bandwidth sharing 10.1.1.X, 10.1.2.X
Bandwidth assignment at 20.1.1.X, 20.1.2.X,

VoD service 3
the ratio of 2:2:1 20.1.3.X
Given less than three
user groups, 100
Mbps for each user 30.1.1.X, 30.1.2.X,
VPN Created as needed group 30.1.3.X, 30.1.4.X,
Given three or more 30.1.5.X
user groups,
bandwidth sharing
86
Number of groups Bandwidth assignment IP assignment
Bandwidth sharing
Total bandwidth not
restricted, but 36
Mbps of the
maximum bandwidth
for each user group
40.1.1.X, 40.1.2.X,
Internet 5 (As all the other services 40.1.3.X, 40.1.4.X,
are rate limited, the 40.1.5.X
guaranteed bandwidth
for Internet traffic is 150
Mbps, providing a
minimum of 30 Mbps
bandwidth for each user
group.)
Configuration considerations
Map VoIP traffic with IP precedence 6 or 7 to the pre-defined forwarding class NC, VoD traffic with
IP precedence 4 or 5 to the pre-defined forwarding class EF, VPN traffic with IP precedence 2 or 3
to the pre-defined forwarding class AF, and Internet traffic with IP precedence 0 or 1 to the
pre-defined forwarding class BE.
Mark VoIP traffic, VoD traffic, VPN traffic, and Internet traffic with a QoS-local ID by source IP
address, and then map VoIP traffic, VoD traffic, VPN traffic, and Internet traffic each to a forwarding
group by QoS-local ID.
The user groups of the VoIP, VoD, VPN, and Internet services are each assigned to a distinct
forwarding group by instantiation.
1. Map different classes of traffic to forwarding classes.
87
As all traffic is differentiated by IP precedence, you can use the default UP-to-forwarding class
mapping table for mapping different classes of traffic to the pre-defined forwarding classes. To this
end, you must use the qos trust auto command on the incoming ports to specify the trusted priority
type.
2. Create forwarding profiles for the Layer-1 forwarding groups.
[Router] qos forwarding-profile voip
[Router-fp-voip] gts cir 100000
[Router-fp-voip] quit
[Router] qos forwarding-profile vod
[Router-fp-vod] gts cir 450000
[Router-fp-vod] quit
[Router] qos forwarding-profile vpn
[Router-fp-vpn] gts cir 300000
[Router-fp-vpn] quit
3. Create forwarding profiles for the Layer-2 forwarding groups.
[Router] qos forwarding-profile vpn-fg2
[Router-fp-vpn-fg2] gts cir 100000
[Router-fp-vpn-fg2] quit
[Router] qos forwarding-profile internet-fg2
[Router-fp-internet-fg2] gts cir 36000
[Router-fp-internet-fg2] quit
[Router] qos forwarding-profile empty
[Router-fp-empty] quit
4. Create forwarding profiles for the forwarding classes.
[Router] qos forwarding-profile vod-fc-1
[Router-fp-vod-fc-1] wfq weight 2
[Router-fp-vod-fc-1] quit
5. Nests the forwarding classes in the Layer-2 forwarding groups.
88
[Router] qos copy forwarding-group default to internet-fg2 voip-fg2 vod-fg2-1
vod-fg2-2 vod-fg2-3 vpn-fg2
[Router] qos forwarding-group vod-fg2-1
[Router-fg-vod-fg2-1] forwarding-class EF profile vod-fc-1
[Router-fg-vod-fg2-1] quit
6. Nest the Layer-2 forwarding groups in the Layer-1 forwarding groups.
[Router] qos forwarding-group voip
[Router-fg-voip] forwarding-group voip-fg2 profile empty
[Router-fg-voip] quit
[Router] qos forwarding-group vod
[Router-fg-vod] forwarding-group vod-fg2-1 profile empty
[Router-fg-vod] quit
[Router] qos forwarding-group vpn
[Router-fg-vpn] forwarding-group vpn-fg2 profile vpn-fg2
[Router-fg-vpn] quit
[Router] qos forwarding-group internet
[Router-fg-internet] forwarding-group internet-fg2 profile internet-fg2
[Router-fg-internet] quit
7. Mark traffic with a QoS-local ID based on the source IP address.
[Router] acl number 2001
[Router-acl-basic-2001] rule permit source 10.1.1.0 0.0.0.255
[Router-acl-basic-2001] acl number 2002
89
[Router-acl-basic-2305] quit
[Router] traffic classifier 1
[Router-classifier-1] if-match acl 2001
[Router-classifier-1] traffic classifier 2
[Router-classifier-305] quit
[Router] traffic behavior 1
[Router-behavior-1] remark qos-local-id 1
[Router-behavior-1] traffic behavior 2
90
[Router-behavior-305] quit
[Router] qos policy localid
[Router-qospolicy-localid] classifier 1 behavior 1
[Router-qospolicy-localid] quit
8. Create a scheduler policy and instantiate the forwarding groups.
[Router] qos scheduler-policy SP
[Router-sp-SP] forwarding-group voip profile voip
[Router-sp-SP] forwarding-group vod profile vod
[Router-sp-SP] forwarding-group vpn profile vpn
[Router-sp-SP] forwarding-group internet profile empty
[Router-sp-SP] layer 1
91
[Router-sp-SP-layer1] forwarding-group voip group
[Router-sp-SP-layer1] forwarding-group vod group
[Router-sp-SP-layer1] forwarding-group vpn group
[Router-sp-SP-layer1] forwarding-group internet group
[Router-sp-SP-layer1] layer 2
[Router-sp-SP-layer2] forwarding-group voip-fg2 match extended qos-local-id 1 2
[Router-sp-SP-layer2] forwarding-group vod-fg2-1 match qos-local-id 101
[Router-sp-SP-layer2] forwarding-group vpn-fg2 match extended qos-local-id 201 to 205
[Router-sp-SP-layer2] forwarding-group internet-fg2 match extended qos-local-id 301
to 305
[Router-sp-SP-layer2] quit
[Router-sp-SP] quit
9. Configure GTS on GigabitEthernet 3/1/1.
[Router-GigabitEthernet3/1/1] qos gts any cir 1000000
10. Apply the scheduler policy SP and the QoS policy localid in the outbound direction of
GigabitEthernet 3/1/1.
[Router-GigabitEthernet3/1/1] qos apply scheduler-policy SP outbound
[Router-GigabitEthernet3/1/1] qos apply policy localid outbound
HQoS configuration example II

QoS-local-ID mode identifies services by QoS-local ID. Traffic accessing a backbone router fall into four
types: VoIP, VoD, VPN, and Internet. You can assign different IP segment to carry different services, and
then perform rate limiting and bandwidth management for each type of service. For a service type, you
can further differentiate its users.
Assume that the rate limit for the outgoing interface is 16 Mbps.
Table 9 and Table 10 present the overall requirements for each service and the requirements for the user
groups of each service respectively.
Table 9 Requirements for the services
IP precedence Queue scheduling priority Rate limit
VoIP 6, 7 Strict priority 2 Mbps
VoD 4, 5 High (bandwidth assured) 3 Mbps
VPN 2, 3 Medium (bandwidth assured) 4 Mbps
Using the surplus

Internet 0, 1 Low
bandwidth
92
Table 10 Requirements for the user groups of each service
Number of groups IP assignment
VoIP service 2 10.1.1.X, 10.1.2.X
VoD service 3 20.1.1.X, 20.1.2.X, 20.1.3.X
30.1.1.X, 30.1.2.X, 30.1.3.X, 30.1.4.X,

VPN 5
30.1.5.X
40.1.1.X, 40.1.2.X, 40.1.3.X, 40.1.4.X,

Internet 5
40.1.5.X

qos-localid Switch
301 to 305
Internet
qos-localid Switch
201 to 205
GE
VPN 3/ 1 Router
/3
30 Mbps 16Mbps
WAN
20 Mbps /4 Mp-group 2/1/1
3/1
qos- local- id Switch GE
101 to 103
VoD
qos- local- id Switch

1 to 2
VoIP
Configuration considerations
Map VoIP traffic with IP precedence 6 or 7 to the pre-defined forwarding class NC, VoD traffic with
IP precedence 4 or 5 to the pre-defined forwarding class EF, VPN traffic with IP precedence 2 or 3
to the pre-defined forwarding class AF, and Internet traffic with IP precedence 0 or 1 to the
pre-defined forwarding class BE.
Mark VoIP traffic, VoD traffic, VPN traffic, and Internet traffic with a QoS-local ID by source IP
address, and then map VoIP traffic, VoD traffic, VPN traffic, and Internet traffic each to a forwarding
group by QoS-local ID.
The user groups of the VoIP, VoD, VPN, and Internet services are each assigned to a distinct
forwarding group by instantiation.
1. Map different classes of traffic to forwarding classes.
As all traffic is differentiated by IP precedence, you can use the default UP-to-forwarding class
mapping table for mapping different classes of traffic to the pre-defined forwarding classes. To this
end, you must use the qos trust auto command on the incoming ports to specify the trusted priority
type.
93
2. Create the forwarding profiles for Layer-1 forwarding groups.
[Router] qos forwarding-profile voip
[Router-fp-voip] gts cir 2000
[Router-fp-voip] quit
[Router] qos forwarding-profile vod
[Router-fp-vod] gts cir 3000
[Router-fp-vod] quit
[Router] qos forwarding-profile vpn
[Router-fp-vpn] gts cir 4000
[Router-fp-vpn] quit
3. Create a forwarding profile for the forwarding class.
[Router] qos forwarding-profile empty
4. Nest forwarding classes in Layer-1 forwarding groups.
[Router] qos forwarding-group voip
[Router-hqos-fg-voip] forwarding-class BE profile empty
[Router-hqos-fg-voip] forwarding-class AF profile empty
[Router-hqos-fg-voip] forwarding-class EF profile empty
[Router-hqos-fg-voip] forwarding-class NC profile empty
[Router-fg-voip] quit
[Router] qos forwarding-group vod
[Router-fg-vod] forwarding-class BE profile empty
[Router-fg-vod] forwarding-class AF profile empty
[Router-fg-vod] forwarding-class EF profile empty
[Router-fg-vod] forwarding-class NC profile empty
[Router-fg-vod] quit
[Router] qos forwarding-group vpn
[Router-fg-vpn] forwarding-class BE profile empty
[Router-fg-vpn] forwarding-class AF profile empty
[Router-fg-vpn] forwarding-class EF profile empty
[Router-fg-vpn] forwarding-class NC profile empty
[Router-fg-vpn] quit
[Router] qos forwarding-group internet
[Router-fg-internet] forwarding-class BE profile empty
[Router-fg-internet] forwarding-class AF profile empty
[Router-fg-internet] forwarding-class EF profile empty
94
[Router-fg-internet] forwarding-class NC profile empty
[Router-fg-internet] quit
5. Mark traffic with a QoS-local ID based on the source IP address.
[Router] acl number 2001
[Router-acl-basic-2305] quit
[Router] traffic classifier 1
95
[Router-classifier-305] quit
[Router] traffic behavior 1
[Router-behavior-305] quit
96
[Router] qos policy localid
[Router-qospolicy-localid] quit
6. Create a scheduler policy and instantiate the forwarding groups.
[Router] qos scheduler-policy SP
[Router-sp-SP] forwarding-group voip profile voip
[Router-sp-SP] forwarding-group vod profile vod
[Router-sp-SP] forwarding-group vpn profile vpn
[Router-sp-SP] forwarding-group internet profile empty
[Router-sp-SP] layer 1
[Router-sp-SP-layer1] forwarding-group voip match qos-local-id 1 2
[Router-sp-SP-layer1] forwarding-group vod match qos-local-id 101 to 103
[Router-sp-SP-layer1] forwarding-group vpn match qos-local-id 201 to 205
[Router-sp-SP-layer1] forwarding-group internet match qos-local-id 301 to 305
[Router-sp-SP] quit
7. Configure GTS on interface Mp-group 2/1/1.
[Router] interface Mp-group 2/1/1
[Router-Mp-group2/1/1] qos gts any cir 16000
8. Apply the scheduler policy SP and the QoS policy localid in the outbound direction of interface
Mp-group2/1/1.
[Router-Mp-group2/1/1] qos apply scheduler-policy SP outbound
[Router-Mp-group2/1/1] qos apply policy localid outbound
97
Index
ACDFHILMNOPQRTW
A H
ACL configuration examples,14 HQoS basic configuration,75
ACL configuration task list,5 HQoS configuration examples,85
ACL overview,1 HQoS configuration task list,73
Aggregation CAR overview,59 HQoS overview,71
C I
Changing the port priority of a port,51 Introduction to QoS,19
Configuring a priority mapping table,49 Introduction to queue scheduling profile,61
Configuring a queue scheduling profile,61 Introduction to WRED configuration,56
Configuring an ACL,5 L
Configuring and applying a WRED table on an
Line rate configuration,27
interface,57
Configuring CBQ,41 M
Configuring FR QoS,67 Major traffic management technologies,21
Configuring the port to trust packet priority for priority
N
mapping,52
Configuring traffic accounting,64 Networks without QoS guarantee,19
Configuring WFQ queuing,40 O
Congestion avoidance overview,55
Overview,66
Congestion management overview,38
P
Congestion: causes, impacts, and
countermeasures,20 Per-port queue-based accounting overview,64
Copying an forwarding group or scheduler policy,84 Priority mapping configuration example,53
D Priority mapping overview,48
Displaying and maintaining ACLs,13 Q

Displaying and maintaining aggregation CAR,60 QoS policy configuration example,36
Displaying and maintaining FR QoS,69 QoS policy configuration procedure,32
Displaying and maintaining HQoS,85 QoS policy overview,29
Displaying and maintaining priority mapping,52 QoS requirements of new applications,19
Displaying and maintaining QoS policies,37 QoS traffic accounting overview,64
Displaying and maintaining queue scheduling Queue scheduling profile configuration example,63
profiles,62
R
Displaying and maintaining traffic accounting and
per-port queue-based accounting,64 Referencing aggregation CAR in a traffic behavior,59
Displaying and maintaining WRED,57 T
F Traffic classification overview,29
FR QoS configuration example,69 Traffic evaluation and token bucket,22
98
Traffic shaping configuration,25 W
Traffic shaping overview,22 WRED configuration example,58
99

ACL and QoS Configuration Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACL and QoS Configuration Guide

Uploaded by

Copyright:

Available Formats

H3C SR8800 10G Core Routers

ACL and QoS Configuration Guide

Hangzhou H3C Technologies Co., Ltd.

Software version: SR8800-CMW520-R3347

All rights reserved

H3C, , Aolynk, , H3Care, , TOP G, , IRF, NetPilot, Neocean, NeoVTL,

# A line that starts with a pound (#) sign is comments.

IMPORTANT An alert that calls attention to essential information.

NOTE An alert that contains additional or supplementary information.

TIP An alert that provides helpful information.

Network topology icons

Represents a generic network device, such as a router, switch, or firewall.

Represents a routing-capable device, such as a router or Layer 3 switch.

Port numbering in examples

About the H3C SR8800 documentation set

Card datasheets Describe card specifications, features, and standards.

Compliance and safety Provides regulatory information and the safety

Provides a complete guide to hardware installation

H3C N68 Cabinet

H3C High-End Network Describes the hot-swappable modules available for

Describe software features and configuration

Command references Provide a quick reference to all available commands.

Provide information about the product release,

Configuring traffic shaping and line rate 22

Configuring hardware congestion management 38

Configuring priority mapping 48

Configuring congestion avoidance 55

Configuring a queue scheduling profile 61

Configuring QoS traffic accounting 64

Source IPv4 address, destination IPv4 address,

Layer 2 header fields, such as source and

User-defined User specified matching patterns in protocol (for

ACL numbering and naming

Table 1 Sort ACL rules in depth-first order

ACL category Sequence of tie breakers

ACL rule numbering

Automatic rule numbering and renumbering

Implementing time-based ACL rules

IPv4 fragments filtering with ACLs

Yes Process the

ACL configuration task list

Configuring a basic ACL

Step Command Remarks

Configuring a basic ACL

Step Command Remarks

By default, no ACL exists.

4. Set the rule numbering Optional.

By default, an IPv4 basic ACL does not

Configuring an IPv6 basic ACL

Step Command Remarks

By default, no ACL exists.

By default, an IPv6 basic ACL does

Step Command Remarks

By default, no ACL exists.

rule [ rule-id ] { deny | permit }

Configuring an IPv6 advanced ACL

Step Command Remarks

By default, no ACL exists.

3. Configure a description Optional.

4. Set the rule numbering Optional.

rule [ rule-id ] { deny | permit } protocol

7. Enable rule match Optional.

Configuring an Ethernet frame header ACL

Step Command Remarks