Академический Документы
Профессиональный Документы
Культура Документы
Copyright 2009-2010, 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,
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 S7500E documentation set includes 12 configuration guides, which describe the software
features for the H3C S7500E Series Ethernet Switches 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 fundamentals and configuration of ACL and QoS. It
describes how to create IPv4 ACL and IPv6 ACL, use QoS polices to control traffic, and configure
common QoS techniques such as traffic policing, traffic shaping, congestion management, and
congestion avoidance.
This preface includes:
z
Audience
Document Organization
Conventions
Obtaining Documentation
Documentation Feedback
Audience
This documentation is intended for:
z
Network planners
Document Organization
The ACL and QoS Configuration Guide comprises these parts:
ACL Configuration
QoS Overview
QoS Configuration
Approaches
Priority Mapping
Configuration
Congestion Management
Configuration
Congestion Avoidance
Traffic Filtering
Configuration
Priority Marking
Configuration
Traffic Redirecting
Configuration
Aggregation CAR
Configuration
Class-Based Accounting
Configuration
Appendix A Default
Priority Mapping Tables
Appendix B Introduction
to Packet Precedences
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.
[]
{ x | y | ... }
[ x | y | ... ]
{ x | y | ... } *
[ x | y | ... ] *
&<1-n>
The argument or keyword and argument combination before the ampersand (&)
sign can be entered 1 to n times.
GUI conventions
Convention
Description
<>
Button names are inside angle brackets. For example, click <OK>.
[]
Window names, menu items, data table and field names are inside square
brackets. For example, pop up the [New User] window.
Symbols
Convention
Description
Means reader be careful. Improper operation may cause data loss or damage to
equipment.
Means an action or information that needs special attention to ensure
successful configuration or good performance.
Means a complementary description.
Documents
Purposes
Marketing brochures
Card datasheets
Installation guide
Configuration guides
Command references
Configuration examples
Release notes
Hardware installation
Software configuration
Operations and
maintenance
Category
Power configuration
Documents
Purposes
H3C
PSR320-A[PSR320-D]
Power Module User
Manual
H3C
PSR650-A[PSR650-D]
Power Module User
Manual
H3C
PSR1400-A[PSR1400-D]
Power Module User
Manual
H3C PSR2800-ACV
Power Module User
Manual
H3C PSR6000-ACV
Power Module User
Manual
Optional cards
Card manuals
z
z
z
z
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, 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.
Documentation Feedback
You can e-mail your comments about product documentation to info@h3c.com.
We appreciate your comments.
Table of Contents
1 ACL Configuration1-1
ACL Overview 1-1
Introduction to ACL1-1
Application of ACLs on the Switch 1-2
ACL Classification 1-2
ACL Numbering and Naming 1-3
Match Order1-3
ACL Rule Numbering Step 1-4
Implementing Time-Based ACL Rules 1-5
IPv4 Fragments Filtering with ACLs 1-5
ACL Configuration Task List 1-5
Configuring an ACL1-6
Creating a Time Range 1-6
Configuring a Basic ACL 1-7
Configuring an Advanced ACL 1-9
Configuring an Ethernet Frame Header ACL 1-12
Copying an ACL 1-14
Displaying and Maintaining ACLs 1-15
ACL Configuration Examples1-15
IPv4 ACL Configuration Example1-15
IPv6 ACL Configuration Example1-17
2 QoS Overview 2-1
Introduction to QoS 2-1
Introduction to QoS Service Models 2-1
Best-Effort Service Model2-1
IntServ Service Model 2-2
DiffServ Service Model 2-2
QoS Techniques Overview 2-2
Positions of the QoS Techniques in a Network2-3
3 QoS Configuration Approaches3-1
QoS Configuration Approach Overview 3-1
Non Policy-Based Configuration 3-1
Policy-Based Configuration 3-1
Configuring a QoS Policy3-1
Defining a Class 3-2
Defining a Traffic Behavior 3-5
Defining a Policy3-5
Applying the QoS Policy3-6
Displaying and Maintaining QoS Policies3-10
iv
ACL Configuration
This chapter includes these sections:
z
ACL Overview
Configuring an ACL
Copying an ACL
Unless otherwise stated, ACLs refer to both IPv4 and IPv6 ACLs throughout this document.
The S7500E Series Ethernet Switches are distributed devices supporting Intelligent Resilient
Framework (IRF). Two S7500E series can be connected together to form a distributed IRF device.
If an S7500E series is not in any IRF, it operates as a distributed device; if the S7500E series is in
an IRF, it operates as a distributed IRF device. For introduction of IRF, see IRF Configuration
Guide.
ACL Overview
This section covers these topics:
z
Introduction to ACL
ACL Classification
Match Order
Introduction to ACL
As network scale and network traffic are increasingly growing, network security and bandwidth
allocation become more and more critical to network management. Packet filtering can be used to
1-1
efficiently prevent illegal users from accessing networks and to control network traffic and save
network resources. Access control lists (ACL) are often used to filter packets with configured matching
rules.
ACLs are sets of rules (or sets of permit or deny statements) that decide what packets can pass and
what should be rejected based on matching criteria such as source MAC address, destination MAC
address, source IP address, destination IP address, and port number.
When an ACL is assigned to a piece of hardware and referenced by a QoS policy for traffic
classification, the switch does not take action according to the traffic behavior definition on a
packet that does not match the ACL.
When an ACL is referenced by a piece of software to control Telnet, SNMP, and Web login users,
the switch denies all packets that do not match the ACL.
ACL Classification
ACLs fall into three categories, as shown in Table 1-1.
Table 1-1 ACL categories
Category
Basic ACLs
ACL number
IP version
Match criteria
IPv4
IPv6
2000 to 2999
3000 to 3999
IPv4
1-2
Category
ACL number
IP version
Match criteria
Source/destination IPv6 address, protocols
over IPv6, and other Layer 3 and Layer 4
IPv6
header fields
Ethernet frame
header ACLs
Match Order
The rules in an ACL are sorted in a 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.
Two ACL match orders are available:
z
config: Sorts 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 rules and their order carefully.
auto: Sorts ACL rules in depth-first order, as described in Table 1-2. The depth-first order varies
with ACL categories.
2)
A rule with more 0s in the source IP address wildcard mask takes precedence.
More 0s means a narrower IP address range.
3)
1-3
ACL category
2)
A rule configured with a specific protocol is prior to a rule with the protocol type set
to IP. IP represents any protocol over IP.
3)
A rule with more 0s in the source IP address wildcard mask takes precedence.
More 0s means a narrower IP address range.
5)
A rule with a narrower TCP/UDP service port number range takes precedence.
6)
1)
A rule configured with a longer prefix for the source IP address takes precedence.
A longer prefix means a narrower IP address range.
1)
A rule configured with a specific protocol is prior to a rule with the protocol type set
to IP. IP represents any protocol over IPv6.
2)
A rule configured with a longer prefix for the source IPv6 address has a higher
priority.
3)
A rule configured with a longer prefix for the destination IPv6 address takes
precedence.
4)
A rule with a narrower TCP/UDP service port number range takes precedence.
5)
1)
A rule with more 1s in the source MAC address mask takes precedence. More 1s
means a smaller MAC address.
Ethernet frame
header ACL
2)
A rule with more 1s in the destination MAC address mask takes precedence.
3)
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, while the
1 bits represent 'dont care bits'. If the 'do care' bits in an IP address 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. With
wildcard masks, you can create more granular match criteria than network masks.
example, the default ACL rule numbering step is 5. If you do 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.
Periodic time range, which recurs periodically on a day or days of the week.
Absolute time range, which represents 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.
1-5
Task
Remarks
Optional
Optional
Remarks
Optional
Optional
Configuring an ACL
Creating a Time Range
Follow these steps to create a time range:
To do
Enter system view
Remarks
time-range time-range-name
{ start-time to end-time days
Create a time range
Required
You may create time ranges identified with the same name. They are regarded as one time range
whose active period is the result of ORing periodic ones, ORing absolute ones, and ANDing periodic
and absolute ones.
You may create a maximum of 256 uniquely named time ranges, each with 32 periodic time ranges at
most and 12 absolute time ranges at most.
1-6
Remarks
Required
By default, no ACL exists.
config } ]
description text
step step-value
5 by default.
Required
By default, an IPv4 basic ACL
time-range time-range-name |
vpn-instance
vpn-instance-name ]*
Note that:
z
You can only modify the existing rules of an ACL that uses the match order of config. When
modifying a rule of such an ACL, you may choose to change just some of the settings, in which
case the other settings remain the same.
1-7
You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an
existing rule in the ACL.
When the ACL match order is auto, a newly created rule will be inserted among the existing rules
in the depth-first match order. Note that the IDs of the rules still remain the same.
You can modify the match order of an ACL with the acl number acl-number [ name acl-name ]
match-order { auto | config } command but only when it does not contain any rules.
Remarks
Required
By default, no ACL exists.
description text
step step-value
5 by default
Required
By default, an IPv6 basic ACL
does not contain any rule.
rule [ rule-id ] { deny | permit }
[ fragment | logging | source
{ ipv6-address prefix-length |
ipv6-address/prefix-length | any } |
time-range time-range-name ]*
1-8
To do
Remarks
Optional
Note that:
z
You can only modify the existing rules of an ACL that uses the match order of config. When
modifying a rule of such an ACL, you may choose to change just some of the settings, in which
case the other settings remain the same.
You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an
existing rule in the ACL.
When the ACL match order is auto, a newly created rule will be inserted among the existing rules
in the depth-first match order. Note that the IDs of the rules still remain the same.
You can modify the match order of an IPv6 ACL with the acl ipv6 number acl6-number [ name
acl6-name ] match-order { auto | config } command but only when it does not contain any rules.
1-9
Remarks
To do
Remarks
Required
By default, no ACL exists.
IPv4 advanced ACLs are
3999.
config } ]
description text
step step-value
5 by default.
rule [ rule-id ] { deny | permit }
protocol [ { established | { ack
Required
destination { dest-addr
dest-wildcard | any } |
icmp-message } | logging |
precedence precedence |
inbound traffic,
Optional
Configure or edit a rule description
Note that:
1-10
You can only modify the existing rules of an ACL that uses the match order of config. When
modifying a rule of such an ACL, you may choose to change just some of the settings, in which
case the other settings remain the same.
You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an
existing rule in the ACL.
When the ACL match order is auto, a newly created rule will be inserted among the existing rules
in the depth-first match order. Note that the IDs of the rules still remain the same.
You can modify the match order of an ACL with the acl number acl-number [ name acl-name ]
match-order { auto | config } command but only when it does not contain any rules.
Remarks
system-view
Required
By default, no ACL exists.
IPv6 advanced ACLs are
Create an IPv6 advanced ACL
and enter its view
3999.
config } ]
description text
step step-value
5 by default.
1-11
To do
Remarks
Required
dest/dest-prefix | any } |
{ icmpv6-type icmpv6-code |
{ source source-prefix |
source/source-prefix | any } |
inbound traffic,
Optional
Configure or edit a rule
description
Note that:
z
You can only modify the existing rules of an ACL that uses the match order of config. When
modifying a rule of such an ACL, you may choose to change just some of the settings, in which
case the other settings remain the same.
You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an
existing rule in the ACL.
When the ACL match order is auto, a newly created rule will be inserted among the existing rules
in the depth-first match order. Note that the IDs of the rules still remain the same.
You can modify the match order of an IPv6 ACL with the acl ipv6 number acl6-number [ name
acl6-name ] match-order { auto | config } command but only when it does not contain any rules.
Remarks
Required
By default, no ACL exists.
Ethernet frame header ACLs are
4999..
config } ]
description text
step step-value
5 by default.
Required
rule.
lsap-code lsap-wildcard |
source-mac sour-addr
source-mask | time-range
time-range-name | type type-code
type-wildcard ]*
Note that:
z
You can only modify the existing rules of an ACL that uses the match order of config. When
modifying a rule of such an ACL, you may choose to change just some of the settings, in which
case the other settings remain the same.
You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an
existing rule in the ACL.
1-13
When the ACL match order is auto, a newly created rule will be inserted among the existing rules
in the depth-first match order. Note that the IDs of the rules still remain the same.
You can modify the match order of an ACL with the acl number acl-number [ name acl-name ]
match-order { auto | config } command but only when it does not contain any rules.
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 except the ACL number and name.
To copy an IPv4 or IPv6 ACL successfully, ensure that:
z
The destination ACL number is from the same category as the source ACL number.
The source IPv4 or IPv6 ACL already exits but the destination IPv4 or IPv6 ACL does not.
Remarks
name source-acl-name } to
{ dest-acl-number | name
Required
dest-acl-name }
Remarks
{ source-acl6-number | name
source-acl6-name } to
category
{ dest-acl6-number | name
dest-acl6-name }
The generated ACL does not take the name of the source ACL.
1-14
Required
slot-number ]
all }
ACLs
name acl-name }
| name acl6-name }
Remarks
1-15
Network Diagram
Figure 1-1 Network diagram for IPv4 ACL configuration
Presidents Office
192.168.1.0/24
Salary server
192.168.4.1
GE2/0/1
GE2/0/4
GE2/0/2
GE2/0/3
Switch
R&D department
192.168.2.0/24
Marketing department
192.168.3.0/24
Configuration Procedure
Create a time range for office hours
# Create a periodic time range spanning 8:00 to 18:00 in working days.
<Switch> system-view
[Switch] time-range trname 8:00 to 18:00 working-day
# Configure a rule to control access of the Marketing Department to the salary query server.
[Switch] acl number 3001
[Switch-acl-adv-3001] rule deny ip source 192.168.3.0 0.0.0.255 destination 192.168.4.1
0.0.0.0 time-range trname
[Switch-acl-adv-3001] quit
1-16
# Configure QoS policy p_rd to use traffic behavior b_rd for class c_rd.
[Switch] qos policy p_rd
[Switch-qospolicy-p_rd] classifier c_rd behavior b_rd
[Switch-qospolicy-p_rd] quit
# Configure QoS policy p_market to use traffic behavior b_market for class c_market.
[Switch] qos policy p_market
[Switch-qospolicy-p_market] classifier c_market behavior b_market
[Switch-qospolicy-p_market] quit
Network Diagram
Figure 1-2 Network diagram for IPv6 ACL configuration
Configuration Procedure
# Create an IPv6 ACL 2000.
<Switch> system-view
[Switch] acl ipv6 number 2000
[Switch-acl6-basic-2000] rule deny source 4050::9000/120
[Switch-acl6-basic-2000] quit
1-17
# Configure QoS policy p_rd to use traffic behavior b_rd for class c_rd.
[Switch] qos policy p_rd
[Switch-qospolicy-p_rd] classifier c_rd behavior b_rd
[Switch-qospolicy-p_rd] quit
1-18
QoS Overview
The S7500E Series Ethernet Switches are distributed devices supporting Intelligent Resilient
Framework (IRF). Two S7500E series can be connected together to form a distributed IRF device. If
an S7500E series is not in any IRF, it operates as a distributed device; if the S7500E series is in an
IRF, it operates as a distributed IRF device. For introduction of IRF, see IRF Configuration Guide.
Introduction to QoS
Introduction to QoS
In data communications, Quality of Service (QoS) is the ability of a network to provide differentiated
service guarantees for diversified traffic regarding bandwidth, delay, jitter, and drop rate.
The network resources are always scarce. Wherever there is contention for resources, there is the
demand for QoS to prioritize important traffic flows over trivial traffic flows. When making a QoS
scheme, a network administrator must plan network resources carefully considering the characteristics
of various applications to balance the interests of diversified users and fully utilize network resources.
The following part introduces the QoS service models, and some mature QoS techniques in wide use.
Appropriately using these techniques in specific environments, you can improve QoS effectively.
Best-effort service
2-1
For more information about RSVP, see MPLS TE Configuration in the MPLS Configuration Guide.
2-2
As shown in Figure 2-1, traffic classification, traffic shaping, traffic policing, congestion management,
and congestion avoidance mainly implement the following functions:
z
Traffic classification uses certain match criteria to assign packets with the same characteristics to
a class. Based on classes, differentiated services can be provided. Traffic classification uses
certain match criteria to organize packets with different characteristics into different classes.
Traffic classification is the basis for providing differentiated services.
Traffic policing polices flows entering or leaving a device and can be applied in both inbound and
outbound directions 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 and delay. Traffic shaping is usually applied in
the outbound direction 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 amount of
traffic by dropping packets.
2-3
Policy-Based Configuration
In the policy-based approach, QoS service parameters are configured through configuring QoS
policies. A QoS policy defines what QoS actions to take on what class of traffic for purposes such as
traffic shaping or traffic policing.
Before configuring a QoS policy, be familiar with these concepts: class, traffic behavior, and policy.
Class
Classes are used to identify traffic.
A class is identified by a class name and contains match criteria for traffic identification. The
relationship between the criteria is AND or OR.
z
AND: A packet is considered as belonging to a class only when the packet matches all the criteria
in the class.
OR: A packet is considered as belonging to a class if it matches any of the criteria in the class.
Traffic behavior
A traffic behavior defines a set of QoS actions to take on packets, such as priority marking and traffic
redirecting.
Policy
A policy associates a class with a traffic behavior to define what actions to take on which class of
traffic.
You can configure multiple class-behavior associations in a policy.
Defining a Class
To define a class, you need to specify a name for it and then configure match criteria in class view.
Follow these steps to define a class:
To do
system-view
view
[ operator { and | or } ]
Remarks
Required
By default, the relationship
between match criteria is AND.
if-match match-criteria
Required
Description
Specifies to match an IPv4 ACL specified by its
number or name. The access-list-number argument
3-2
Description
Specifies to match an IPv6 ACL specified by its
number or name. The access-list-number argument
any
SC cards).
Matches the 802.1p priority of the customer network.
The 8021p-list argument is a list of up to eight 802.1p
customer-dot1p 8021p-list
customer-vlan-id vlan-id-list
destination-mac mac-address
dscp dscp-list
ip-precedence ip-precedence-list
protocol protocol-name
IPv6.
Matches a local QoS ID, which is in the range of 1 to
4095. The local QoS IDs supported on the S7500E
qos-local-id local-id-value
service-dot1p 8021p-list
3-3
Description
Specifies to match the packets of the VLANs of the
operators network. The vlan-id-list argument is a list
of VLAN IDs, in the form of vlan-id to vlan-id or
multiple discontinuous VLAN IDs (separated by
service-vlan-id vlan-id-list
source-mac mac-address
system-index index-value-list
Suppose the logical relationship between classification rules is and. Note the following when using the
if-match command to define matching rules.
z
If multiple matching rules with the acl or acl ipv6 keyword specified are defined in a class, the
actual logical relationship between these rules is or when the policy is applied.
If multiple matching rules with the customer-vlan-id or service-vlan-id keyword specified are
defined in a class, the actual logical relationship between these rules is or.
3-4
The matching criteria listed below must be unique in a traffic class with the operator being AND.
Therefore, even though you can define multiple if-match clauses for these matching criteria or input
multiple values for a list argument (such as the 8021p-list argument) listed below in a traffic class,
avoid doing that. Otherwise, the QoS policy referencing the class cannot be applied to interfaces
successfully.
z
customer-dot1p 8021p-list
destination-mac mac-address
dscp dscp-list
ip-precedence ip-precedence-list
service-dot1p 8021p-list
source-mac mac-address
system-index index-value-list
To create multiple if-match clauses or specify multiple values for a list argument for any of the
matching criteria listed above, ensure that the operator of the class is OR.
Remarks
system-view
Required
Defining a Policy
In a policy, you can define multiple class-behavior associations. A behavior is performed for the
associated class of packets. In this way, various QoS features can be implemented.
Follow these steps to associate a class with a behavior in a policy:
To do
Enter system view
3-5
Remarks
To do
Create a policy and enter policy
view
Remarks
Required
Required
Associate a class with a behavior
in the policy
Specify the
behavior-name [ mode
dot1q-tag-manipulation keyword
dot1q-tag-manipulation ]
If an ACL is referenced by a QoS policy for defining traffic match criteria, packets matching the
ACL are organized as a class and the behavior defined in the QoS policy applies to the class
regardless of whether the match mode of the if-match clause is deny or permit.
Applied to an interface, the policy takes effect on the traffic sent or received on the interface.
Applied to a user profile, the policy takes effect on the traffic sent or received by the online users
of the user profile.
Applied to a VLAN, the policy takes effect on the traffic sent or received on all ports in the VLAN.
Applied globally, the policy takes effect on the traffic sent or received on all ports.
Applied to the control plane, the policy takes effect on the traffic sent or received on the control
plane.
3-6
You can modify classes, behaviors, and class-behavior associations in a QoS policy even after it
is applied.
The QoS policies applied to ports, VLANs, and the system globally have descending priorities. For
example, if a port and a VLAN carried on the port have both referenced a QoS policy for incoming
traffic, the one on the port is used to match traffic prior to the one for the VLAN.
interface
interface
view
system-view
interface interface-type
Enter port
group view
interface-number
view or port
group view
Remarks
interface/port group
{ inbound | outbound }
Required
The QoS policy applied to the outgoing traffic of a port does not regulate local packets, which are
critical protocol packets sent by the card that hosts the interface for maintaining the normal operation
of the device. The most common local packets include link maintenance packets, STP, LDP, and
RSVP packets.
Remarks
system-view
3-7
To do
Remarks
Required
The configuration made in user
profile view takes effect when the
user-profile is activated and there
user-profile profile-name
{ inbound | outbound }
quit
Required
Inactive by default
If a user profile is active, the QoS policy, except ACLs referenced in the QoS policy, applied to it
cannot be configured or removed. If the user profile is being used by online users, the referenced
ACLs cannot be modified either.
The QoS policies applied in user profile view support only the remark, car, and filter actions.
Do not apply an empty policy in user profile view because a user profile with an empty policy
applied cannot be activated.
3-8
Remarks
Required
QoS policies cannot be applied to dynamic VLANs, for example, VLANs created by GVRP.
system-view
qos apply policy policy-name
Remarks
Required
A QoS policy containing any of the nest, remark customer-vlan-id, and remark service-vlan-id
Actions cannot be applied globally.
At the data plane are units responsible for receiving, transmitting, and switching (that is,
forwarding) packets, such as various dedicated forwarding chips. They deliver super processing
speeds and throughput.
At the control plane are processing units running most routing and switching protocols and
responsible for protocol packet resolution and calculation, such as CPUs. Compared with data
plane units, they allow for great packet processing flexibility but have lower throughput.
When the data plane receives packets that it cannot recognize or process, it transmits them to the
control plane. If the transmission rate exceeds the processing capability of the control plane, which
very likely occurs at times of DoS attacks, the control plane will be busy handling undesired packets
and fail to handle legitimate packets correctly or timely. As a result, protocol performance is affected.
To address this problem, you can apply a QoS policy to the control plane to take QoS actions such as
traffic filtering or rate limiting on inbound traffic, thus ensuring that the control plane can receive,
transmit, and process packets normally.
Follow these steps to apply the QoS policy to the control plane:
To do
Enter system view
Enter control plane view (on a
distributed device)
Remarks
system-view
Required
3-9
To do
Remarks
slot-number
control plane
outbound }
Required
Required
The QoS policy applied to the control plane for a specific slot takes effect only on the slot.
In case a global QoS policy conflicts with a control plane QoS policy, the control plane QoS policy
takes effect on the control plane.
By default, devices are configured with pre-defined control plane policies, which take effect on the
control planes by default. A pre-defined control plane QoS policy uses the system-index to identify
the type of packets sent to the control plane. You can reference system-indexes in if-match
commands in class view for traffic classification and then re-configure traffic behaviors for these
classes as required. You can use the display qos policy control-plane pre-defined command
to display them.
In a QoS policy for control planes, if a system index classifier is configured, the associated traffic
behavior can contain only the CAR or accounting action. In addition, if the CAR action is
configured, only its CIR setting can be applied.
configuration information
user-defined [ behavior-name ]
Remarks
tcl-name ] ]
display qos policy interface
[ interface-type interface-number ]
[ inbound | outbound ]
display qos vlan-policy { name
policy-name | vlan vlan-id } [ slot
slot-number ] [ inbound |
outbound ]
3-10
To do
Remarks
device
slot-number ] [ inbound |
outbound ]
Display information about QoS
slot-number ] [ inbound |
distributed device
outbound ]
control-plane pre-defined
[ slot slot-number ]
pre-defined [ chassis
applied globally
[ inbound | outbound ]
a distributed device
outbound ]
outbound ]
outbound ]
outbound ]
reset qos policy control-plane
[ chassis chassis-number slot
slot-number ] [ inbound |
outbound ]
3-11
3-12
Local precedence is used for queuing. A local precedence value corresponds to an output queue.
A packet with higher local precedence is assigned to a higher priority output queue to be
preferentially scheduled.
Drop precedence is used for making packet drop decisions. Packets with the highest drop
precedence are dropped preferentially.
When a packet enters the device from a port, the device assigns a set of QoS priority parameters to
the packet based on a certain priority and sometimes may modify its priority, according to certain rules
depending on device status. This process is called priority mapping. The priority based on which
priority mapping is performed depends on the priority trust mode configured on the port . The set of
QoS priority parameters decides the scheduling priority and forwarding priority of the packet.
dot1p-exp: 802.1p-to-EXP priority mapping table. (Available only on the EB and SD cards)
exp-dot1p: EXP-to-802.1p priority mapping table. (Available only on the EB and SD cards)
The default priority mapping tables (as shown in Appendix A Default Priority Mapping Tables) are
available for priority mapping. Generally, they are sufficient for priority mapping. If a default priority
mapping table cannot meet your requirements, you can modify the priority mapping table as required.
dot1p: Uses the 802.1p priority carried in packets for priority mapping.
In addition, port priority was introduced for 802.1q untagged packets. Thus, when a port configured
with the 802.1p trust mode receives an 802.1q untagged packet, the priority of the port is used as the
802.1p priority of the packet for priority mapping table lookup.
The priority mapping procedure varies with the priority modes, as described in the next section Priority
Mapping Procedure.
4-2
Which priority is
trusted on the
port?
DSCP in packets
802.1p in
packets
Look up the
dscp-dp, dscpdot1p, and dscpdscp tables
Is the packet
802.1q tagged?
Look up the
dot1p-dp and
dot1p-lp tables
Look up the
dot1p-dp and
dot1p-lp tables
Look up the
dot1p-lp table
For an MPLS packet, the priority mapping procedure as shown in Figure 4-2 is adopted:
4-3
Look up the
exp-dp table
Look up the
exp-dot1p table
Look up the
dot1p-lp table
The priority mapping procedure presented above applies in the absence of priority marking. If priority
marking is configured, the device performs priority marking before priority mapping, and then uses the
re-marked packet-carried priority for priority mapping or directly uses the re-marked scheduling priority
for traffic scheduling depending on your configuration. In this case, neither priority trust mode
configuration on the port nor port priority configuration takes effect.
Remarks
Optional
Optional
Optional
4-4
system-view
Remarks
dot1p-exp | dot1p-lp |
dscp-dot1p | dscp-dp |
Required
table
export-value
Optional
| dscp-dot1p | dscp-dp |
The 802.1p-to-EXP priority mapping table (dot1p-exp) and the EXP-to-802.1p priority mapping table
(exp-dot1p) are available only for the EB and SD cards.
interface
interface
view
system-view
interface interface-type
Enter port
group view
Configure
the priority
trust mode
Trust the
DSCP
priority in
interface-number
view or port
group view
Remarks
packets
4-5
To do
Remarks
Trust the
802.1p
priority in
packets
Display the priority trust
mode configuration on the
port
Optional
[ interface-type interface-number ]
interface
interface
view
system-view
interface interface-type
interface-number
view or port
group view
Remarks
Enter port
port-group manual
group view
port-group-name
port group.
Required
Optional
[ interface-type interface-number ]
Remarks
configuration
| dscp-dot1p | dscp-dp |
type on a port
[ interface-type interface-number ]
4-6
Network requirements
As shown in Figure 4-3, the enterprise network of a company interconnects all departments through
Device. The network is described as follows:
z
The marketing department connects to GigabitEthernet 2/0/1 of Device, which sets the 802.1p
priority of traffic from the marketing department to 3.
The R&D department connects to GigabitEthernet 2/0/2 of Device, which sets the 802.1p priority
of traffic from the R&D department to 4.
The management department connects to GigabitEthernet 2/0/3 of Device, which sets the 802.1p
priority of traffic from the management department to 5.
Configure port priority, 802.1p-to-local priority mapping table, and priority marking to implement the
plan as described in Table 4-1.
Table 4-1 Configuration plan
Queuing plan
Traffic
destination
R&D department
R&D department > management
Public servers
Internet
through HTTP
Medium
Marketing department
Low
R&D department
Low
High
Medium
Marketing department
4-7
priority
Management
department
department
queue
High
Management
Queue
department
department
Output
Figure 4-3 Network diagram for priority mapping table and priority marking configuration
Internet
Host
Host
Server
Server
GE2/0/5
Management department
Data server
GE2/0/3
GE2/0/2
R&D department
GE2/0/4
Device
GE2/0/1
Host
Server
Mail server
Public servers
Marketing department
Configuration procedure
1)
2)
# Configure the 802.1p-to-local priority mapping table to map 802.1p priority values 3, 4, and 5 to local
precedence values 2, 6, and 4.
[Device] qos map-table dot1p-lp
[Device-maptbl-dot1p-lp] import 3 export 2
[Device-maptbl-dot1p-lp] import 4 export 6
[Device-maptbl-dot1p-lp] import 5 export 4
[Device-maptbl-dot1p-lp] quit
3)
4-8
# Mark the HTTP traffic of the management department, marketing department, and R&D department
to the Internet with 802.1p priorities 4, 5, and 3 respectively. Use the priority mapping table configured
above to map the 802.1p priorities to local precedence values 6, 4, and 2 respectively for differentiated
traffic treatment.
# Create ACL 3000 to match HTTP traffic.
[Device] acl number 3000
[Device-acl-adv-3000] rule permit tcp destination-port eq 80
[Device-acl-adv-3000] quit
# Configure a priority marking policy for the management department and apply the policy to the
incoming traffic of GigabitEthernet 2/0/3.
[Device] traffic behavior admin
[Device-behavior-admin] remark dot1p 4
[Device-behavior-admin] quit
[Device] qos policy admin
[Device-qospolicy-admin] classifier http behavior admin
[Device-qospolicy-admin] quit
[Device] interface gigabitethernet 2/0/3
[Device-GigabitEthernet2/0/3] qos apply policy admin inbound
# Configure a priority marking policy for the marketing department and apply the policy to the incoming
traffic of GigabitEthernet 2/0/1.
[Device] traffic behavior market
[Device-behavior-market] remark dot1p 5
[Device-behavior-market] quit
[Device] qos policy market
[Device-qospolicy-market] classifier http behavior market
[Device-qospolicy-market] quit
[Device] interface gigabitethernet 2/0/1
[Device-GigabitEthernet2/0/1] qos apply policy market inbound
# Configure a priority marking policy for the R&D department and apply the policy to the incoming
traffic of GigabitEthernet 2/0/2.
[Device] traffic behavior rd
[Device-behavior-rd] remark dot1p 3
[Device-behavior-rd] quit
[Device] qos policy rd
[Device-qospolicy-rd] classifier http behavior rd
[Device-qospolicy-rd] quit
[Device] interface gigabitethernet 2/0/2
[Device-GigabitEthernet2/0/2] qos apply policy rd inbound
4-9
Configuring GTS
Mean rate at which tokens are put into the bucket, namely, the permitted average rate of traffic. It
is usually set to the committed information rate (CIR).
Burst size or the capacity of the token bucket. It is the maximum traffic size that is permitted in
each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater
than the maximum packet size.
5-1
Evaluation is performed for each arriving packet. In each evaluation, if the number of tokens in the
bucket is enough, the traffic conforms to the specification and the corresponding tokens for forwarding
the packet are taken away; if the number of tokens in the bucket is not enough, it means that too many
tokens have been used and the traffic is excessive.
Complicated evaluation
You can set two token buckets, the C bucket and the E bucket, to evaluate traffic in a more
complicated environment and achieve more policing flexibility. For example, traffic policing uses four
parameters:
z
CIR: Rate at which tokens are put into the C bucket, that is, the average packet transmission or
forwarding rate allowed by the C bucket.
CBS: Size of the C bucket, that is, transient burst of traffic that the C bucket can forward.
Peak information rate (PIR): Rate at which tokens are put into the E bucket, that is, the average
packet transmission or forwarding rate allowed by the E bucket.
Excess burst size (EBS): Size of the E bucket, that is, transient burst of traffic that the E bucket
can forward.
CBS is implemented with the C bucket and EBS with the E bucket. In each evaluation, packets are
measured against the buckets:
z
If the C bucket does not have enough tokens but the E bucket has enough tokens, packets are
colored yellow.
If neither the C bucket nor the E bucket has sufficient tokens, packets are colored red.
Traffic Policing
Traffic policing supports policing traffic in the inbound direction and the outbound direction. Thereafter,
the outbound direction is taken for example.
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. In this way, the network
resources and the interests of the user are protected. 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.
5-2
Packets to be sent
through this interface
Packets sent
Packet
classification
Token
bucket
Queue
Packets dropped
Traffic policing is widely used in policing traffic entering the networks of internet service providers
(ISPs). It can classify the policed traffic and take pre-defined policing actions on each packet
depending on the evaluation result:
z
Modifying the DSCP priority of the conforming traffic and forwarding it.
Traffic Shaping
Traffic shaping provides measures to adjust the rate of outbound traffic actively. A typical traffic
shaping application is to limit the local traffic output rate according to the downstream traffic policing
parameters.
The difference between traffic policing and GTS is that packets to be dropped with traffic policing are
retained in a buffer or queue with GTS, as shown in Figure 5-2. When there are enough tokens in the
token bucket, the buffered packets are sent at an even rate. Traffic shaping may result in additional
delay while traffic policing does not.
5-3
Packets to be sent
through this interface
Packets sent
Packet
classification
Token
bucket
Queue
Packets dropped
For example, in Figure 5-3, Switch A sends packets to Switch B. Switch B performs traffic policing on
packets from Switch A and drops packets exceeding the limit.
Figure 5-3 GTS application
You can perform traffic shaping for the packets on the outgoing interface of Switch A to avoid
unnecessary packet loss. Packets exceeding the limit are cached in Switch A. Once resources are
released, traffic shaping takes out the cached packets and sends them out. In this way, all the traffic
sent to Switch B conforms to the traffic specification defined in Switch B.
Line Rate
The line rate of a physical interface specifies the maximum rate for forwarding packets (including
critical packets).
Line rate also uses token buckets for traffic control. With line rate configured on an interface, all
packets to be sent through the interface are firstly handled by the token bucket at line rate. If there are
enough tokens in the token bucket, packets can be forwarded; otherwise, packets are put into QoS
queues for congestion management. In this way, the traffic passing the physical interface is controlled.
5-4
In the token bucket approach to traffic control, bursty traffic can be transmitted so long as enough
tokens are available in the token bucket; if tokens are inadequate, packets cannot be transmitted until
the required number of tokens are generated in the token bucket. Thus, traffic rate is restricted to the
rate for generating tokens, thus limiting traffic rate and allowing bursty traffic.
Line rate can only limit the total traffic rate on a physical port, while traffic policing can limit the rate of a
flow on a port. To limit the rate of all the packets on a port, using line rate is easier.
Remarks
system-view
view
| or } ]
if-match match-criteria
quit
5-5
To do
Remarks
Required
committed-burst-size [ ebs
excess-burst-size ] ] [ pir
policing is 64 kbps.
Apply the
QoS
policy
quit
quit
To an interface
To online users
To a VLAN
Globally
To the control
plane
plane
Only SC, SD and EB cards support policing traffic in the outbound direction.
Configuration Example
Configure traffic policing on GigabitEthernet 2/0/1 to limit the rate of received HTTP traffic to 512 kbps
and drop the exceeding traffic.
# Enter system view.
<Sysname> system-view
5-6
[Sysname-acl-adv-3000] quit
# Create a class named http, and reference ACL 3000 in the class to match HTTP traffic.
[Sysname] traffic classifier http
[Sysname-classifier-http] if-match acl 3000
[Sysname-classifier-http] quit
# Configure a traffic policing QoS policy, and apply the QoS policy to the incoming packets of
GigabitEthernet 2/0/1.
[Sysname] traffic behavior http
[Sysname-behavior-http] car cir 512
[Sysname-behavior-http] quit
[Sysname] qos policy http
[Sysname-qospolicy-http] classifier http behavior http
[Sysname-qospolicy-http] quit
[Sysname] interface gigabitethernet 2/0/1
[Sysname-GigabitEthernet2/0/1] qos apply policy http inbound
Configuring GTS
Configuration Procedure
On the H3C S7500E series switches, traffic shaping is implemented as queue-based GTS, that is,
configuring GTS parameters for packets of a certain queue.
Follow these steps to configure queue-based GTS:
To do
Enter system view
Remarks
system-view
Enter
Enter
interface
interface
view
view or
port group
Enter port
view
group
view
Required
committed-burst-size ]
Display GTS
configuration
Optional
information on the
interface-number ]
interface/all interfaces
5-7
Configuration Example
Configure GTS on GigabitEthernet2/0/1, shaping the packets of queue 1 when the sending rate
exceeds 512 kbps.
# Enter system view.
<Sysname> system-view
system-view
Enter
Enter
interface
interface
view
Enter port
group view
view or port
group view
Remarks
committed-information-rate [ cbs
interface/port group
committed-burst-size ]
on the interface/all
interface-number ]
interfaces
Configuration Example
Limit the outbound line rate of GigabitEthernet 2/0/1 to 512 kbps.
# Enter system view.
<Sysname> system-view
5-8
On the S7500E series switches, you can configure traffic policing in policy-based approach. For
related displaying and maintaining commands, see Displaying and Maintaining QoS Policies.
To do
configuration information
[ interface-type interface-number ]
configuration information
[ interface-type interface-number ]
5-9
Remarks
10M
100M
10M
100M>10M
50M
100M+10M+50M>100M
1
6-1
SP queuing
SP queuing is specially designed for mission-critical applications, which require preferential service to
reduce the response delay when congestion occurs.
Figure 6-2 Schematic diagram for SP queuing
As shown in Figure 6-2, SP queuing classifies eight queues on a port into eight classes, numbered 7 to
0 in descending priority order.
SP queuing schedules the eight queues strictly according to the descending order of priority. It sends
packets in the queue with the highest priority first. When the queue with the highest priority is empty, it
sends packets in the queue with the second highest priority, and so on. Thus, you can assign
mission-critical packets to the high priority queue to ensure that they are always served first and
common service packets to the low priority queues and transmitted when the high priority queues are
empty.
The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if
there are packets in the higher priority queues. This may cause lower priority traffic to starve to death.
WRR queuing
WRR queuing schedules all the queues in turn to ensure that every queue can be served for a certain
time, as shown in Figure 6-3.
6-2
Queue 1 Weight 2
Sent packets
Interface
Packet
classification
Sending queue
Assume there are eight output queues on a port. WRR assigns each queue a weight value
(represented by w7, w6, w5, w4, w3, w2, w1, or w0) to decide the proportion of resources assigned to
the queue. On a 100 Mbps port, you can configure the weight values of WRR queuing to 5, 3, 1, 1, 5, 3,
1, and 1 (corresponding to w7, w6, w5, w4, w3, w2, w1, and w0 respectively). In this way, the queue
with the lowest priority is assured of 5 Mbps of bandwidth at least, thus avoiding the disadvantage of
SP queuing that packets in low-priority queues may fail to be served for a long time.
Another advantage of WRR queuing is that while the queues are scheduled in turn, the service time for
each queue is not fixed, that is, if a queue is empty, the next queue will be scheduled immediately. This
improves bandwidth resource use efficiency.
WFQ queuing
Figure 6-4 Schematic diagram for WFQ queuing
Queue 1 Band width 1
Sent packets
Interface
Packet
classification
Sending queue
WFQ is derived from fair queuing (FQ), which is designed for fairly sharing network resources,
reducing the delay and jitter of all traffic. FQ fully consider the interests of all queues to ensure that:
z
Different queues have fair dispatching opportunities, preventing a single queue from being
delayed for too long.
6-3
Short packets and long packets are fairly scheduled: if there are both long packets and short
packets in queues, statistically the short packets should be scheduled preferentially to reduce the
jitter between packets as a whole.
Compared with FQ, WFQ takes weights into account when determining the queue scheduling order.
Statistically, WFQ gives high priority traffic more scheduling opportunities than low priority traffic. WFQ
can automatically classify traffic according to the session information of traffic (protocol type, TCP or
UDP source/destination port numbers, source/destination IP addresses, IP precedence bits in the ToS
field, and so on), and try to provide as many queues as possible so that each traffic flow can be put into
these queues to balance the delay of every traffic flow as a whole. When dequeuing packets, WFQ
assigns the outgoing interface bandwidth to each traffic flow by precedence. The higher precedence
value a traffic flow has, the more bandwidth it gets.
Additionally, WFQ can work with the minimum guaranteed bandwidth mechanism. You can configure a
minimum guaranteed bandwidth for each WFQ queue to guarantee that each WFQ queue is
guaranteed of the bandwidth when congestion occurs. The assignable bandwidth (assignable
bandwidth = total bandwidth the sum of the minimum guaranteed bandwidth for each queue) is
allocated to queues based on queue priority.
For example, assume that the total bandwidth of a port is 10 Mbps, and there are five flows on the port
currently, with the precedence being 0, 1, 2, 3, and 4 and the minimum guaranteed bandwidth being
128 kbps, 128 kbps, 128 kbps, 64 kbps, and 64 kbps respectively.
z
The assignable bandwidth = 10 Mbps (128 kbps + 128 kbps + 128 kbps + 64 kbps + and 64
kbps) = 9.5 Mbps
The total assignable bandwidth quota is the sum of all the (precedence value + 1)s, that is, 1 + 2 +
3 + 4 + 5 = 15.
The bandwidth percentage assigned to each flow is (precedence value of the flow + 1)/total
assignable bandwidth quota. The bandwidth percentages for the flows are 1/15, 2/15, 3/15, 4/15,
and 5/15 respectively.
The bandwidth finally assigned to a queue = the minimum guaranteed bandwidth + the bandwidth
allocated to the queue from the assignable bandwidth
Because WFQ can balance delay and jitter among flows when congestion occurs, it is effectively
applied in some special occasions. For example, WFQ is used for the assured forwarding (AF)
services of the Resource Reservation Protocol (RSVP). In Generic Traffic Shaping (GTS), WFQ is
used to schedule buffered packets.
SP+WRR queuing
By assigning some queues on the port to the SP scheduling group and the others to the WRR
scheduling group (that is, group 1), you implement SP + WRR queue scheduling on the port. Packets
in the SP scheduling group are scheduled preferentially. When the SP scheduling group is empty,
packets in the WRR scheduling group are scheduled. Queues in the SP scheduling group are
scheduled with the SP queue scheduling algorithm. Queues in the WRR scheduling group are
scheduled with WRR.
6-4
Task
Remarks
Configuring SP Queuing
Optional
Optional
Optional
Optional
interface
interface
view
system-view
interface interface-type
interface-number
view or port
group view
Remarks
Enter port
port-group manual
group view
port-group-name
port group.
Optional
Configure SP queuing
qos sp
Display SP queuing
Optional
configuration
[ interface-type interface-number ]
Configuration example
1)
Network requirements
Configuration procedure
6-5
interface
interface
view
system-view
interface interface-type
Enter port
group view
interface-number
view or port
group view
Remarks
qos wrr
Required
Optional
configuration information
[ interface-type interface-number ]
Configuration example
1)
Network requirements
Assign queues 0 through 7 to the WRR group, with their weights being 1, 3, 3, 5, 8, 8, 10, and 15.
2)
Configuration procedure
To do
Enter system view
Enter
Enter
interface
interface
view
system-view
interface interface-type
Enter port
group view
interface-number
view or port
group view
Remarks
qos wfq
Required
bandwidth-value
64 kbps by default
Required
schedule-value
1 by default
Optional
configuration
[ interface-type interface-number ]
The support of different cards for the minimum guaranteed bandwidth and scheduling weight
configuration for WFQ queues varies as follows:
z
The SC, SD, and EB cards support both minimum guaranteed bandwidth and scheduling weight
configurations.
The EA cards support both configurations too, but the scheduling weight for each queue can only
be 1.
Configuration example
1)
Network requirements
Configure the queues on port GigabitEthernet2/0/1 as WFQ queues and sets the scheduling
weights of queues 1, 3, 4, 5, and 6 to 1, 5, 10, 15, and 10 respectively.
2)
Configuration procedure
Enter
Enter interface
interface interface-type
view
interface-number
Enter port
port-group manual
group view
port-group-name
interface
view or port
group view
Remarks
qos wrr
Configure SP queue
scheduling
Required
Required
schedule-value
Configuration Example
Network requirements
z
Configuration procedure
# Enter system view.
<Sysname> system-view
information
interface-number ]
information
interface-number ]
information
interface-number ]
6-9
Remarks
Congestion Avoidance
When configuring congestion avoidance, go to these sections for information you are interested in:
z
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 longer a queue is, the higher the drop probability is. However,
a maximum drop probability exists.
7-1
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.
The upper threshold and lower threshold: when the average queue size is smaller than the lower
threshold, no packet is dropped. When the average queue size is between the lower threshold
and the upper threshold, packets are dropped randomly. The longer a queue, the higher the drop
probability. When the average queue size exceeds the upper threshold, subsequent packets are
dropped.
Drop precedence: a 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.
Denominator for drop probability calculation: the bigger the denominator is, the smaller the
calculated drop probability is.
The S7500E series switches do not support the upper drop threshold.
In a WRED table, drop parameters are configured on a per queue basis, because WRED regulates
packets on a per queue basis.
A WRED table can be applied to multiple interfaces. For a WRED table already applied to an interface,
you can modify the values of the WRED table, but you cannot remove the WRED table.
Configuration Procedure
Follow these steps to configure WRED:
7-2
To do
Remarks
system-view
discard-prob ]
Optional
By default, the low-limit argument
is 100 and the discard-prob
argument is 10.
Enter
Enter
interface
interface
view
view or port
group view
Enter port
group view
Configuration Example
Network requirements
Apply a queue-based WRED table to port GigabitEthernet 2/0/1.
Configuration procedure
# Enter system view.
<Sysname> system-view
7-3
Remarks
Remarks
system-view
view
{ and | or } ]
if-match match-criteria
quit
Required
Configure the traffic filtering
action
quit
8-1
To do
Exit policy view
Apply the
QoS
policy
Remarks
quit
To an interface
To online users
To a VLAN
Globally
To the control
plane
plane
Optional
configuration
[ behavior-name ]
With filter deny configured for a traffic behavior, the other actions (except class-based accounting) in
the traffic behavior do not take effect.
For line card categories and their description, see the installation manual for the S7500E series
switches.
Table 8-1 Support of line cards for the traffic filtering action
Traffic direction (right)
Inbound
Outbound
Supported
Supported
SA
Supported
Not supported
EA
Supported
Not supported
EB
Supported
Supported
8-2
Outbound
Supported
Supported
Configuration procedure
# Create advanced ACL 3000, and configure a rule to match packets whose source port number is 21.
<DeviceA> system-view
[DeviceA] acl number 3000
[DeviceA-acl-basic-3000] rule 0 permit tcp source-port eq 21
[DeviceA-acl-basic-3000] quit
# Create a class named classifier_1, and reference ACL 3000 in the class.
[DeviceA] traffic classifier classifier_1
[DeviceA-classifier-classifier_1] if-match acl 3000
[DeviceA-classifier-classifier_1] quit
# Create a behavior named behavior_1, and configure the traffic filtering action for the behavior to
drop packets.
[DeviceA] traffic behavior behavior_1
[DeviceA-behavior-behavior_1] filter deny
[DeviceA-behavior-behavior_1] quit
# Create a policy named policy, and associate class classifier_1 with behavior behavior_1 in the
policy.
[DeviceA] qos policy policy
[DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1
[DeviceA-qospolicy-policy] quit
# Apply the policy named policy to the incoming traffic of GigabitEthernet 2/0/1.
[DeviceA] interface gigabitethernet 2/0/1
[DeviceA-GigabitEthernet2/0/1] qos apply policy policy inbound
8-3
Priority marking can be used together with priority mapping. For details, see Priority Mapping Table
and Priority Marking Configuration Example.
Priority marking sets the priority fields or flag bits of packets to modify the priority of traffic. For example,
you can use priority marking to set IP precedence or DSCP for a class of IP traffic to change its
transmission priority in the network.
To configure priority marking, you can associate a class with a behavior configured with the priority
marking action to set the priority fields or flag bits of the class of packets.
Remarks
system-view
view
| or } ]
if-match match-criteria
quit
Optional
9-1
To do
Remarks
customer-dot1p-trust }
Optional
copying function
Optional
Set the drop precedence for
remark drop-precedence
packets
drop-precedence-value
remark ip-precedence
packets
ip-precedence-value
remark local-precedence
packets
local-precedence
Optional
Optional
Optional
The QoS-local-ID is used for
identifying services and has
Set the QoS-local-ID for
packets
Apply the
QoS
policy
quit
quit
To an interface
To online users
To a VLAN
Globally
To the control
plane
plane
Optional
configuration
[ behavior-name ]
9-2
For line card categories and their description, see the installation manual for the S7500E series
switches.
category
SA
EA
(right)
Action
(below)
Inbound
Outbound
Inbound
Outbound
Inbound
Outbound
Remarking the
802.1p
precedence
Supported
Supported
Supported
Not supported
Supported
Not supported
Supported
Not supported
Supported
Not supported
for packets
Remarking the
drop
precedence
Supported
Not
supported
for packets
Remarking the
DSCP
precedence
Supported
Supported
Supported
Not supported
Supported
Not supported
Supported
Supported
Supported
Not supported
Supported
Not supported
Supported
Not supported
Supported
Not supported
for packets
Remarking the
IP precedence
for packets
Remarking the
local
precedence
Supported
Not
supported
for packets
9-3
Card
SC
category
SA
EA
(right)
Action
Inbound
(below)
Outbound
Inbound
Outbound
Inbound
Outbound
Remarking the
specified QoS
Not
Not
Not
local ID for
supported
supported
supported
Not supported
Not
supported
Not supported
packets.
category
EB
(right)
Action (below)
Inbound
SD
Outbound
Inbound
Outbound
Remarking the
802.1p precedence
Supported
Supported
Supported
Supported
Supported
Not supported
Supported
Not supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Not supported
Supported
Not supported
Supported
Not supported
Supported
Not supported
for packets
Remarking the drop
precedence for
packets
Remarking the
DSCP precedence
for packets
Remarking the IP
precedence for
packets
Remarking the
local precedence
for packets
Remarking the
specified QoS local
ID for packets.
9-4
The data server, mail server, and file server are connected to GigabitEthernet 2/0/2 of Device.
Destination
Processing priority
Host A, B
Data server
High
Host A, B
Mail server
Medium
Host A, B
File server
Low
Host A
192.168.0.1/24
GE2/0/1
GE2/0/2
Mail server
192.168.0.2/24
Host B
Device
File server
192.168.0.3/24
Configuration procedure
# Create advanced ACL 3000, and configure a rule to match packets with destination IP address
192.168.0.1.
<Device> system-view
[Device] acl number 3000
[Device-acl-adv-3000] rule permit ip destination 192.168.0.1 0
[Device-acl-adv-3000] quit
# Create advanced ACL 3001, and configure a rule to match packets with destination IP address
192.168.0.2.
[Device] acl number 3001
[Device-acl-adv-3001] rule permit ip destination 192.168.0.2 0
[Device-acl-adv-3001] quit
# Create advanced ACL 3002, and configure a rule to match packets with destination IP address
192.168.0.3.
[Device] acl number 3002
9-5
# Create a class named classifier_dbserver, and reference ACL 3000 in the class.
[Device] traffic classifier classifier_dbserver
[Device-classifier-classifier_dbserver] if-match acl 3000
[Device-classifier-classifier_dbserver] quit
# Create a class named classifier_mserver, and reference ACL 3001 in the class.
[Device] traffic classifier classifier_mserver
[Device-classifier-classifier_mserver] if-match acl 3001
[Device-classifier-classifier_mserver] quit
# Create a class named classifier_fserver, and reference ACL 3002 in the class.
[Device] traffic classifier classifier_fserver
[Device-classifier-classifier_fserver] if-match acl 3002
[Device-classifier-classifier_fserver] quit
# Create a behavior named behavior_dbserver, and configure the action of setting the local
precedence value to 4 for the behavior.
[Device] traffic behavior behavior_dbserver
[Device-behavior-behavior_dbserver] remark local-precedence 4
[Device-behavior-behavior_dbserver] quit
# Create a behavior named behavior_mserver, and configure the action of setting the local
precedence value to 3 for the behavior.
[Device] traffic behavior behavior_mserver
[Device-behavior-behavior_mserver] remark local-precedence 3
[Device-behavior-behavior_mserver] quit
# Create a behavior named behavior_fserver, and configure the action of setting the local
precedence value to 2 for the behavior.
[Device] traffic behavior behavior_fserver
[Device-behavior-behavior_fserver] remark local-precedence 2
[Device-behavior-behavior_fserver] quit
# Create a policy named policy_server, and associate classes with behaviors in the policy.
[Device] qos policy policy_server
[Device-qospolicy-policy_server] classifier classifier_dbserver behavior behavior_dbserver
[Device-qospolicy-policy_server] classifier classifier_mserver behavior behavior_mserver
[Device-qospolicy-policy_server] classifier classifier_fserver behavior behavior_fserver
[Device-qospolicy-policy_server] quit
# Apply the policy named policy_server to the incoming traffic of GigabitEthernet 2/0/1.
[Device] interface gigabitethernet 2/0/1
[Device-GigabitEthernet2/0/1] qos apply policy policy_server inbound
[Device-GigabitEthernet2/0/1] quit
9-6
With QoS local ID marking, however, traffic limit applies to the two classes as a whole, allowing the
switch to dynamically assign the bandwidth to the two classes depending on their traffic size.
To configure QoS-local-ID marking to limit the total rate of the two classes, you need to mark packets
of the two classes with the same QoS-local-ID; create a class to match the QoS local ID, and associate
this class with the traffic policing action. The configuration procedure is as follows:
# Create ACL 2000 to match packets with source IP address 1.1.1.1.
<Sysname> system-view
[Sysname] acl number 2000
[Sysname-acl-basic-2000] rule permit source 1.1.1.1 0
[Sysname-acl-basic-2000] quit
# Create a class class_a to match both packets with source MAC address 0001-0001-0001 and
packets with source IP 1.1.1.1.
<Sysname> system-view
[Sysname] traffic classifier class_a operator or
[Sysname-classifier-class_a] if-match source-mac 1-1-1
[Sysname-classifier-class_a] if-match acl 2000
[Sysname-classifier-class_a] quit
# Create a behavior behavior_a, and configure the action of marking packets with QoS-local-ID 100
for the behavior.
[Sysname] traffic behavior behavior_a
[Sysname-behavior-behavior_a] remark qos-local-id 100
[Sysname-behavior-behavior_a] quit
# Create a behavior behavior_b, and configure the action of limiting traffic rate to 128 kbps for the
behavior.
[Sysname] traffic behavior behavior_b
[Sysname-behavior-behavior_b] car cir 128
[Sysname-behavior-behavior_b] quit
# Create a QoS policy car_policy. In the QoS policy, associate class class_a with behavior
behavior_a, and associate class class_b with behavior behavior_b.
[Sysname] qos policy car_policy
[Sysname-qospolicy-car_policy] classifier class_a behavior behavior_a
[Sysname-qospolicy-car_policy] classifier class_b behavior behavior_b
Apply the QoS policy car_policy to the interface, and you can satisfy the network requirements.
9-7
10
When configuring traffic redirecting, go to these sections for information you are interested in:
z
Redirecting traffic to the CPU: redirects packets which require processing by CPU to the CPU.
Redirecting traffic to an interface: redirects packets which require processing by an interface to the
interface. Note that this action is applicable to only Layer 2 packets, and the target interface
should be a Layer 2 interface.
Redirecting traffic to the next hop: redirects packets which require processing by an interface to
the interface. This action is applicable to only Layer 3 packets.
Remarks
system-view
view
{ and | or } ]
if-match match-criteria
quit
Required
Optional
interface-number ] [ ipv6-add2
[ interface-type interface-number ] ] }
quit
10-1
To do
Associate the class with the
traffic behavior in the QoS
policy
Exit policy view
Apply the
QoS
Remarks
quit
To an interface
To a VLAN
Globally
To the control
plane
plane
policy
Generally, the action of redirecting traffic to the CPU, the action of redirecting traffic to an interface,
and the action of redirecting traffic to the next hop are mutually exclusive with each other in the
same traffic behavior.
You can use the display traffic behavior command to view the traffic redirecting configuration.
A QoS policy that contains a traffic redirecting action can be applied only to the incoming traffic.
To implement QoS policy routing successfully, ensure that the next hop address specified in the
redirect action exist and the outgoing interface is not a tunnel interface. If you fail to do that, the
matching traffic will be dropped.
For line card categories and their description, see the installation manual for the S7500E series
switches.
10-2
Table 10-1 Support of line cards for the traffic redirecting action
Direction(right)
Inbound
Outbound
Supported
Not Supported
SA LPU
Supported
Not Supported
EA LPU
Supported
Not Supported
EB LPU
Supported
Not Supported
SD LPU
Supported
Not Supported
10-3
11
Only the SD and EB cards support QoS policies that contain aggregation CAR actions.
You have determined the traffic behavior to reference the aggregation CAR.
Configuration procedure
Follow these steps to reference an aggregation CAR in a traffic behavior:
To do
Enter system view
Remarks
system-view
Required
qos car car-name aggregative cir
committed-information-rate [ cbs
z
Configure an aggregation
committed-burst-size [ ebs
CAR action
excess-burst-size ] ] [ pir
64 kbps.
class view
{ and | or } ]
if-match match-criteria
11-1
To do
Remarks
quit
Required
Required
quit
To an interface
To a VLAN
Globally
To the control
plane
plane
Apply the
QoS
policy
Remarks
Required
[ car-name ]
Required
reset qos car name [ car-name ]
Available in user view
Configuration example
Configure an aggregation CAR to rate-limit the traffic of VLAN 10 and VLAN 100 received on
GigabitEthernet 2/0/1 using these parameters: CIR is 256 kbps, CBS is 2000 bytes, and the action for
red packets is discard.
# Configure an aggregation CAR according to the rate limit requirements.
<Sysname> system-view
[Sysname] qos car aggcar-1 aggregative cir 256 cbs 2000 red discard
# Create class 1 to match traffic of VLAN 10; create behavior 1, and reference the aggregation CAR in
the behavior.
[Sysname] traffic classifier 1
[Sysname-classifier-1] if-match customer-vlan-id 10
[Sysname-classifier-1] quit
[Sysname] traffic behavior 1
[Sysname-behavior-1] car name aggcar-1
[Sysname-behavior-1] quit
# Create class 2 to match traffic of VLAN 100; create behavior 2, and reference the aggregation CAR
in the behavior.
[Sysname] traffic classifier 2
11-2
# Create QoS policy car, associate class 1 with behavior 1, and associate class 2 with behavior 2.
[Sysname] qos policy car
[Sysname-qospolicy-car] classifier 1 behavior 1
[Sysname-qospolicy-car] classifier 2 behavior 2
[Sysname-qospolicy-car] quit
11-3
12
When configuring class-based accounting, go to these sections for information you are interested in:
z
Remarks
system-view
view
{ and | or } ]
if-match match-criteria
quit
Required
Optional
accounting
Traffic is counted in packets.
quit
quit
12-1
To do
Apply the
QoS
Remarks
To an interface
To a VLAN
Globally
To the control
plane
plane
policy
Configuration procedure
# Create basic ACL 2000, and configure a rule to match packets with source IP address 1.1.1.1.
<DeviceA> system-view
[DeviceA] acl number 2000
[DeviceA-acl-basic-2000] rule permit source 1.1.1.1 0
[DeviceA-acl-basic-2000] quit
# Create a class named classifier_1, and reference ACL 2000 in the class.
[DeviceA] traffic classifier classifier_1
[DeviceA-classifier-classifier_1] if-match acl 2000
[DeviceA-classifier-classifier_1] quit
12-2
# Create a policy named policy, and associate class classifier_1 with behavior behavior_1 in the
policy.
[DeviceA] qos policy policy
[DeviceA-qospolicy-policy] classifier classifier_1 behavior behavior_1
[DeviceA-qospolicy-policy] quit
# Apply the policy named policy to the incoming traffic of GigabitEthernet 2/0/1.
[DeviceA] interface gigabitethernet 2/0/1
[DeviceA-GigabitEthernet2/0/1] qos apply policy policy inbound
[DeviceA-GigabitEthernet2/0/1] quit
Interface: GigabitEthernet2/0/1
Direction: Inbound
Policy: policy
Classifier: classifier_1
Operator: AND
Rule(s) : If-match acl 2000
Behavior: behavior_1
Accounting Enable:
16 (Packets)
12-3
13
When configuring QoS in an EPON system, go to these sections for information you are interested in:
z
Configuring traffic classification for an ONU: the ONU classifies the uplink traffic of a UNI and
marks CoS precedence values for the matching traffic, so that traffic can be put into different
queues.
Filtering the packets matching certain match criteria according to the configured QoS policy.
Configuring the ONU to perform traffic policing for uplink traffic of a UNI.
Configuring the UNI to tag the uplink 802.1q-untagged traffic with the default VLAN tag, and
adding the UNI priority to the Priority field as the 802.1p precedence (CoS precedence).
Configuring the ONU to distribute the uplink traffic to different output queues based on the
mapping between the CoS precedence and local precedence.
Configuring the ONU to perform congestion management for traffic from uplink ports, supporting
SP and WFQ queue scheduling algorithms (available to only H3C ONUs).
Processing on an OLT
z
By default, an OLT port trusts the 802.1p precedence of the packets. You can configure to trust
the DSCP precedence of the packets through the command line. Thus, the OLT will obtain the
CoS precedence based on the mapping between the DSCP precedence and CoS precedence
before mapping the CoS precedence to the corresponding output queue. This configuration
applies to all uplink traffic of ONUs.
Configuring congestion management for uplink ports (supporting SP, WRR, and SP+WRR queue
scheduling algorithms).
Configuring congestion avoidance on an OLT. When the port is congested, received packets are
dropped selectively.
Figure 13-1 shows the QoS model for uplink traffic in an EPON system.
13-4
Configuring the OLT to perform priority mapping for packets received from the uplink port
according to the CoS-to-local precedence mapping table and then assign packets to output
queues of the OLT port.
Configuring the OLT to perform congestion management for downlink traffic, supporting SP and
WRR queue scheduling algorithms.
Configuring the OLT to perform line rate and traffic shaping for downlink traffic.
Configuring the maximum downlink bandwidth that the OLT assigns to the ONU.
Configuring high-priority packet buffer for downlink traffic that the OLT sends to the specified
ONU.
Processing on an ONU
z
Filtering the packets matching certain match criteria according to the configured QoS policy.
Configuring the ONU to distribute the received downlink traffic to different output queues based on
the mapping between the CoS precedence and local precedence.
Configuring the ONU to perform traffic policing for downlink traffic of a UNI.
Some ONUs support configuring queue scheduling for traffic from a UNI. To perform such
configurations, you should log in to the ONU. For detailed configuration, see the ONU user manual.
Figure 13-2 shows the QoS model for downlink traffic in an EPON system.
Figure 13-2 QoS model for downlink traffic in an EPON system
13-5
QoS configurations in an EPON system are the same as those in Ethernet, and the corresponding
configuration commands in OLT port view and ONU port view are the same as those in Ethernet port
view too. For detailed configuration, see the corresponding chapters above.
Table 13-1 and Table 13-2 show how to configure QoS for downlink traffic and uplink traffic in an EPON
system.
Table 13-1 Configure QOS at the OLT side of an EPON system
Reference
OLT
port
a Port
traffic
Configuring SP Queuing
Configure congestion management
Configuring SP Queuing
Configure congestion management
OLT port
Configuring GTS
13-6
Reference
Reference
packets on UNIs
ONU
Mode on a Port
traffic of a UNI
Configuring SP Queuing
traffic
traffic of a UNI
Remarks
system-view
Optional
priority-queue-mapping { downstream |
13-7
Remarks
system-view
Required
The downlink packets
on an OLT port are
considered
high-priority only if
quit
Optional
reserves no
high-priority buffer for
an ONU.
13-8
High-priority packet buffering takes effect for downlink traffic only when downlink bandwidth allocation
policy is enabled (as shown in Configure traffic policing for downlink/uplink traffic of a UNI).
Configuring the ONU downlink bandwidth range, including the maximum bandwidth and the
maximum burst buffer.
Follow these steps to configure the ONU bandwidth allocation and related parameters:
To do
Enter system view
Remarks
system-view
interface interface-type
interface-number
Required
Enable the ONU downlink
bandwidth allocation policy
enable
packets
prioritized.
Optional
Configure the ONU downlink
bandwidth limit
bandwidth downstream
{ max-bandwidth value |
max-burstsize value } *
The configuration of high-priority packet buffering (as shown in Sending buffer size of the OLT port)
and that of the downlink bandwidth limit take effect only when the downlink bandwidth allocation
policy is enabled.
The configured downlink bandwidth limitation takes effect only on known unicasts, but not on
unknown unicasts, multicasts, or broadcasts.
The sum of the minimum uplink bandwidths configured for all the existing ONU ports under an
OLT port cannot exceed 921600 Kbps, namely, 900 Mbps.
13-9
Local precedence
Follow these steps to configure the mapping between CoS precedence values and local precedence
values:
To do...
Enter system view
Remarks
system-view
interface interface-type
interface-number
qos cos-local-precedence-map
cos0-map-local-prec
Configure the mapping
between CoS precedence
values and local precedence
values
cos1-map-local-prec
cos2-map-local-prec
Required
cos3-map-local-prec
cos4-map-local-prec
13-3.
cos5-map-local-prec
cos6-map-local-prec
cos7-map-local-prec
criteria, VLAN operation mode of the port, and VLAN tagging status of the received packets. For details,
see Table 13-4.
Table 13-4 Relationship between VLAN operation modes and priority remarking
VLAN operation
mode
tag
Packet processing
z
Transparent
mode
Tag mode
Without VLAN tag
Translation mode
Case 3: The VLAN ID in the tag does not match any VLAN
translation entry on the port. The packet is dropped.
13-11
VLAN operation
mode
tag
Packet processing
Follow these steps to configure uplink traffic classification and priority remarking for a UNI:
To do...
Remarks
system-view
UNI
&<1-4>
Currently, up to eight rules can be configured for each UNI port on an H3C ONU.
13-12
Required
Restrictions
z
In the case of source MAC addressbased priority remarking for a UNI port,
the ONU adds the source MAC address and the corresponding UNI port
statically into its MAC address table; In the case of destination MAC
addressbased priority remarking for a UNI port, the ONU adds the
destination MAC address and the PON port of the ONU statically into its
MAC address table.
When the VLAN operation mode is set to tag mode for a UNI and the CoS
value in the traffic classification rule is the same as the priority of the UNI, the
traffic classification rule will not take effect.
The configuration of VLAN IDbased priority remarking takes effect globally.
Namely, a VLAN IDbased traffic classification rule configured for a UNI port of
an ONU applies to incoming traffic from all the other UNI ports of the ONU.
z
If multiple rules are matched on the same UNI of an ONU, the match
sequence is L3 L4 L2; if the rules are for the same layer, the rule with
address/destination IP
The device does not support priority remarking for different UNIs of an ONU
based on the same Ethernet type, DSCP, IP protocol type, source IP
address/destination IP address, or source L4 port.
13-13
For VLAN operation mode introduction and configuration of a UNI, see UNI Port Configuration in the
Layer 2 - LAN Switching Configuration Guide.
Remarks
Optional
bucket-depth
bucket-depth-value |
uplink/downlink traffic
extra-burst-size
for a UNI.
ebs-value }* } | outbound
cir cir-value [ pir
pir-value ] }
Configure the VLAN operation mode as transparent for both UNI 1 and UNI 2.
Configure priority remarking for UNI 1: Remark tagged packets sourced from the MAC address of
000A-EB7F-AAAB with CoS 3 precedence.
Configure priority remarking for UNI 2: Remark tagged packets sourced from the MAC address of
001B-EB7F-21AC with CoS 1 precedence.
Network diagram
Figure 13-3 Network diagram for UNI priority remarking configuration
13-14
Configuration procedure
# Create ONU 3/0/1:1, and bind it to the ONU.
<Sysname> system-view
[Sysname] interface olt 3/0/1
[Sysname-Olt3/0/1] using onu 1
[Sysname-Olt3/0/1] quit
[Sysname] interface onu 3/0/1:1
[Sysname-Onu3/0/1:1] bind onuid 000f-e200-0104
# Set the uplink bandwidth of the ONU port to 50 Mbps (64 Kbps 800).
[Sysname-Onu3/0/1:1] upstream-sla minimum-bandwidth 800 maximum-bandwidth 800
# Configure the VLAN operation mode as transparent for UNI 1 and UNI 2.
[Sysname-Onu3/0/1:1] uni 1 vlan-mode transparent
[Sysname-Onu3/0/1:1] uni 2 vlan-mode transparent
For detailed information about ONU uplink bandwidth and VLAN operation mode of a UNI, see ONU
Remote Management Configuration and UNI Port Configuration in the Layer 2 - LAN Switching
Configuration Guide.
After the configuration above is complete, when two streams (each 50 Mbps) from two UNIs of the
ONU are being forwarded to the OLT, the packets sourced from the MAC address of 001B-EB7F-21AC
are dropped at forwarding congestion on the ONU port, because the queue precedence of these
packets is lower than that of the packets sourced from the MAC address of 000A-EB7F-AAAB.
13-15
14
For the default dot1p-exp, dscp-dscp, and exp-dot1p priority mapping tables, an input value yields a
target value that is equal to it.
Table 14-1 The default dot1p-lp and dot1p-dp priority mapping tables
Input priority value
dot1p-lp mapping
dot1p-dp mapping
Local precedence
802.1p priority (dot1p)
Table 14-2 The default dscp-dp and dscp-dot1p priority mapping tables
Input priority value
dscp-dp mapping
dscp-dot1p mapping
DSCP
0 to 7
8 to 15
16 to 23
24 to 31
32 to 39
14-1
dscp-dp mapping
dscp-dot1p mapping
DSCP
40 to 47
48 to 55
56 to 63
exp-dp mapping
EXP value
14-2
15
As shown in Figure 15-1, the ToS field of the IP header contains eight bits, and the first three bits (0 to
2) represent IP precedence from 0 to 7. According to RFC 2474, the ToS field of the IP header is
redefined as the differentiated services (DS) field, where a DSCP value is represented by the first six
bits (0 to 5) and is in the range 0 to 63. The remaining two bits (6 and 7) are reserved.
IP precedence (binary)
Description
000
Routine
001
priority
010
immediate
011
flash
100
flash-override
101
critical
110
internet
111
network
15-1
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
001000
cs1
16
010000
cs2
24
011000
cs3
32
100000
cs4
40
101000
cs5
48
110000
cs6
56
111000
cs7
000000
be (default)
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.
15-2
As shown in Figure 15-2, the 4-byte 802.1Q tag header consists of the tag protocol identifier (TPID,
two bytes in length), whose value is 0x8100, and the tag control information (TCI, two bytes in length).
Figure 15-3 presents the format of the 802.1Q tag header. The Priority field in the 802.1Q tag header is
called the 802.1p priority, because its use is defined in IEEE 802.1p. Table 15-3 presents the values for
802.1p priority.
Figure 15-3 802.1Q tag header
Byte 1
Byte 2
Byte 3
Byte 4
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 Priority
CFI
VLAN ID
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Description
000
best-effort
001
background
010
spare
011
excellent-effort
100
controlled-load
101
video
110
voice
111
network-management
EXP Values
The EXP field lies in MPLS labels and is used for QoS.
15-3
As shown in Figure 15-4, the EXP field is 3 bits long and ranges from 0 to 7.
15-4
16
Index
DiffServ Service Model
A
ACL Classification
2-2
1-2
3-10
Configuration
Congestion 6-1
4-1
12-2
Configuration prerequisites
2-2
11-1
1-15
4-5
1-12
Match Order
13-7
1-3
3-1
4-6
Policy-Based Configuration
3-1
4-5
Configuring WFQ Queuing
Network
6-6
2-3
4-2
1-6
Configuration Example
4-7
4-1
1-17
1-5
Example
13-14
Q
3-5
16-1
13-6
13-4
9-6
T
Traffic Evaluation and Token Buckets
5-1
16-2