No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
i
Contents
Legal and notice information ·········································································································································i
Verifying the configuration ··································································································································· 16
QoS service models ······················································································································································· 17
Best-effort service model ······································································································································· 17
IntServ model ························································································································································· 17
DiffServ model ······················································································································································· 17
QoS techniques overview ············································································································································· 17
Deploying QoS in a network ······························································································································· 18
QoS processing flow in a device ························································································································ 19
Configuring a QoS policy ········································································································································· 20
Non-MQC approach ····················································································································································· 20
MQC approach ····························································································································································· 20
Configuration procedure diagram ······························································································································· 20
Defining a traffic class ··················································································································································· 21
Defining a traffic behavior ············································································································································ 21
Defining a QoS policy ··················································································································································· 22
Configuring a parent policy ································································································································· 22
Configuring a child policy ···································································································································· 22
Applying the QoS policy ··············································································································································· 23
Applying the QoS policy to an interface or PVC ······························································································· 23
i
Applying the QoS policy to the control plane···································································································· 24
Applying the QoS policy to the management interface control plane ···························································· 25
Configuring the QoS policy-based traffic rate statistics collection period for an interface ···································· 25
Displaying and maintaining QoS policies ·················································································································· 26
Introduction to priorities ········································································································································ 28
Priority maps ·························································································································································· 28
Priority mapping configuration tasks ··························································································································· 29
Configuring an uncolored priority map ······················································································································· 29
Configuring a port to trust packet priority for priority mapping ··············································································· 30
Changing the port priority of an interface ·················································································································· 30
Displaying and maintaining priority mapping ············································································································ 30
Port priority configuration example ······························································································································ 31
Configuring traffic policing by using the MQC approach ··············································································· 38
Configuring traffic policing by using the non-MQC approach ········································································ 39
Configuring GTS ···························································································································································· 40
Configuring GTS by using the MQC approach ································································································· 40
Configuring GTS by using the non-MQC approach ························································································· 41
Configuring the rate limit ·············································································································································· 42
Displaying and maintaining traffic policing, GTS, and rate limit ············································································· 42
Traffic policing and GTS configuration example ········································································································ 43
Predefined classes, traffic behaviors, and policies ···························································································· 52
Defining a class ····················································································································································· 53
Defining a traffic behavior ··································································································································· 53
2
Defining a QoS policy ·········································································································································· 56
Applying the QoS policy ······································································································································ 56
Configuring the maximum available interface bandwidth ··············································································· 57
Setting the maximum reserved bandwidth as a percentage of available bandwidth ··································· 58
Displaying and maintaining CBQ ······················································································································· 58
CBQ configuration example ································································································································ 59
Configuring packet information pre-extraction ··········································································································· 60
Configuration example ········································································································································· 60
Tail drop ································································································································································· 62
RED and WRED ····················································································································································· 62
Relationship between WRED and queuing mechanisms ··················································································· 63
Configuration example ········································································································································· 64
Displaying and maintaining WRED ····························································································································· 65
Configuring a routing policy ································································································································ 76
Enabling QPPB on the route receiving interface ································································································ 77
Configuring a QoS policy ···································································································································· 77
Applying the QoS policy to an interface ············································································································ 77
QPPB configuration examples ······································································································································ 77
QPPB configuration example in an IPv4 network ······························································································ 77
QPPB configuration example in an MPLS L3VPN ······························································································ 80
QPPB configuration example in an IPv6 network ······························································································ 88
Appendix A Acronym ···················································································································································· 92
Appendix B Default uncolored priority maps ·············································································································· 93
Appendix C Introduction to packet precedences ······································································································· 94
IP precedence and DSCP values ·························································································································· 94
Configuring time ranges ········································································································································· 100
Configuration procedure ············································································································································· 100
Displaying and maintaining time ranges··················································································································· 100
Time range configuration example ···························································································································· 100
Support and other resources ·································································································································· 102
Contacting HP ······························································································································································ 102
Subscription service ············································································································································ 102
Related information ······················································································································································ 102
Index ········································································································································································ 105
4
Configuring ACLs
In this chapter, "MSR1000" refers to MSR1002-4. "MSR2000" refers to MSR2003, MSR2004-24,
MSR2004-48. "MSR3000" collectively refers to MSR3012, MSR3024, MSR3044, MSR3064.
"MSR4000" collectively refers to MSR4060 and MSR4080.
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. "Configuring packet filtering with ACLs" provides an
example. You can use ACLs in QoS, security, routing, and other feature modules for identifying traffic.
The packet drop or forwarding decisions varies with the modules that use ACLs.
ACL categories
Category ACL number IP version
Basic ACLs 2000 to 2999
Advanced ACLs 3000 to 3999
Ethernet frame
header ACLs
4000 to 4999 N/A
IPv4 Source IPv4 address.
IPv6 Source IPv6 address.
IPv4
IPv6
Numbering and naming ACLs
Each ACL category has a unique range of ACL numbers. When creating an ACL, you must assign it a
number. In addition, you can assign the ACL a name for ease of identification. After creating an ACL with
a name, you cannot rename it or delete its name.
For an IPv4 basic or advanced ACLs, its ACL number and name must be unique in IPv4. For an IPv6 basic
or advanced ACL, its ACL number and name must be unique in IPv6.
Match criteria
Source IPv4 address, destination IPv4 address,
packet priority, protocol number, and other
Layer 3 and Layer 4 header fields.
Source IPv6 address, destination IPv6 address,
packet priority, protocol number, and other
Layer 3 and Layer 4 header fields.
Layer 2 header fields, such as source and
destination MAC addresses, 802.1p priority,
and link layer protocol type.
Match order
The rules in an ACL are sorted in a specific 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.
5
The following ACL match orders are available:
gory
Seq
•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 method, check the rules and their order carefully.
•auto—Sorts ACL rules in depth-first order. Depth-first ordering makes sure 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.
Table 1 Sort ACL rules in depth-first order
ACL cate
IPv4 basic ACL
IPv4 advanced ACL
IPv6 basic ACL
IPv6 advanced ACL
Ethernet frame
header ACL
uence of tie breakers
1. VPN instance.
2. More 0s in the source IPv4 address wildcard (more 0s means a
narrower IPv4 address range).
3. Rule configured earlier.
1. VPN instance.
2. Specific protocol number.
3. More 0s in the source IPv4 address wildcard mask.
4. More 0s in the destination IPv4 address wildcard.
5. Narrower TCP/UDP service port number range.
6. Rule configured earlier.
1. VPN instance.
2. Longer prefix for the source IPv6 address (a longer prefix means a
narrower IPv6 address range).
3. Rule configured earlier.
1. VPN instance.
2. Specific protocol number.
3. Longer prefix for the source IPv6 address.
4. Longer prefix for the destination IPv6 address.
5. Narrower TCP/UDP service port number range.
6. Rule configured earlier.
1. More 1s in the source MAC address mask (more 1s means a smaller
MAC address).
2. More 1s in the destination MAC address mask.
3. Rule configured earlier.
A wildcard mask, also called an inverse mask, is a 32-bit binary number 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 "don't 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 "don't 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.
Rule numbering
ACL rules can be manually numbered or automatically numbered. This section describes how automatic
ACL rule numbering works.
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
6
default ACL rule numbering step is 5. If you do not assign IDs to rules you are creating, they are
automatically 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 is numbered 15. If the ACL does not contain any rule, the first rule is
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.
Fragments filtering with ACLs
Traditional packet filtering matches only first fragments of packets, and allows all subsequent non-first
fragments to pass through. Attackers can fabricate non-first fragments to attack networks.
To avoid the risks, the HP ACL implementation does the follows:
• Filters all fragments by default, including non-first fragments.
• Allows for matching criteria modification, for example, filters non-first fragments only.
Configuration task list
Tasks at a glance
(Required.) Perform at least one of the following tasks:
• Configuring a basic ACL
{ Configuring an IPv4 basic ACL
{ Configuring an IPv6 basic ACL
• Configuring an advanced ACL
{ Configuring an IPv4 advanced ACL
{ Configuring an IPv6 advanced ACL
• Configuring an Ethernet frame header ACL
(Optional.) Copying an ACL
(Optional.) Configuring packet filtering with ACLs
Configuring a basic ACL
This section describes procedures for configuring IPv4 and IPv6 basic ACLs.
7
Configuring an IPv4 basic ACL
IPv4 basic ACLs match packets based only on source IP addresses.
To configure an IPv4 basic ACL:
Step Command Remarks
1. Enter system view.
2. Create an IPv4 basic ACL and
enter its view.
3. (Optional.) Configure a
description for the IPv4 basic
ACL.
4. (Optional.) Set the rule
numbering step.
system-view N/A
acl number acl-number [ name
acl-name ] [ match-order { auto |
config } ]
description text
step step-valueThe default setting is 5.
By default, no ACL exists.
IPv4 basic ACLs are numbered in
the range of 2000 to 2999.
You can use the acl name acl-name
command to enter the view of a
named ACL.
By default, an IPv4 basic ACL has
no ACL description.
By default, an Ethernet frame
header ACL has no ACL
description.
By default
header ACL does not contain any
rule.
,
an Ethernet frame
6. (Optional.) Add or edit a rule
comment.
Copying an ACL
You can create an ACL by copying an existing ACL (source ACL). The new ACL (destination 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:
• 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.
To copy an ACL:
Step Command
1. Enter system view.
2. Copy an existing ACL to create a new ACL.
rule rule-id comment text
system-view
acl [ ipv6 ] copy { source-acl-number | name
source-acl-name } to { dest-acl-number | name
dest-acl-name }
By default, no rule comments are
configured.
Configuring packet filtering with ACLs
Th is section descri bes procedures for applyi ng an ACL to fil ter incoming or ou tgoing IP v4 or IP v6 packets
on the specified interface.
Applying an ACL to an interface for packet filtering
Step Command
1. Enter system view.
2. Enter interface view.
system-view N/A
interface interface-type
interface-number
12
Remarks
N/A
Step Command
Remarks
By default, an interface does not
filter packets.
You can apply up to 32 ACLs to the
same direction of an interface.
packet-filter [ ipv6 ] { acl-number |
name acl-name }
Remarks
N/A
By default, an interzone does not
filter packets.
You can apply up to 32 ACLs to the
same interzone instance.
Setting the interval for generating and outputting packet
filtering logs
After you set the interval, the device periodically generates and outputs the packet filtering logs to the
information center, including the number of matching packets and the matched ACL rules. For more
information about information center, see Network Management and Monitoring Configuration Guide.
To set the interval for generating and outputting packet filtering logs:
Step Command
1. Enter system view.
2. Set the interval for generating
and outputting packet filtering
logs.
system-view N/A
acl [ ipv6 ] logging interval interval
Setting the packet filtering default action
Step Command
1. Enter system view.
2. Set the packet filtering default
action to deny.
system-view N/A
packet-filter default deny
Remarks
The default setting is 0 minutes,
which mean that no packet filtering
logs are generated.
Remarks
By default, the packet filter permits
packets that do not match any ACL
rule to pass.
13
Displaying and maintaining ACLs
Execute display commands in any view and reset commands in user view.
Task Command
Display ACL configuration and match statistics.
Display ACL application information for packet
filtering (MSR1000/MSR2000/MSR3000).
Display ACL application information for packet
filtering (MSR4000).
Display match statistics and default action statistics for
packet filtering ACLs.
Display the accumulated statistics for packet filtering
ACLs.
Display detailed ACL packet filtering information
(MSR1000/MSR2000/MSR3000).
display acl [ ipv6 ] { acl-number | all | name
acl-name }
A company interconnects its departments through Router A. Configure an ACL to:
• Permit access from the President's office at any time to the financial database server.
• Permit access from the Financial department to the database server only during working hours (from
8:00 to 18:00) on working days.
• Deny access from any other department to the database server.
Figure 1 Network diagram
Configuration procedure
# Create a periodic time range from 8:00 to 18:00 on working days.
<RouterA> system-view
[RouterA] time-range work 08:0 to 18:00 working-day
# Create an IPv4 advanced ACL numbered 3000 and configure three rules in the ACL. One rule permits
access from the President's office to the financial database server, one rule permits access from the
Financial department to the database server during working hours, and one rule denies access from any
other department to the database server.
[RouterA] acl number 3000
[RouterA-acl-adv-3000] rule permit ip source 192.168.1.0 0.0.0.255 destination
192.168.0.100 0
[RouterA-acl-adv-3000] rule permit ip source 192.168.2.0 0.0.0.255 destination
192.168.0.100 0 time-range work
[RouterA-acl-adv-3000] rule deny ip source any destination 192.168.0.100 0
[RouterA-acl-adv-3000] quit
# Apply IPv4 advanced ACL 3000 to filter outgoing packets on interface GigabitEthernet 2/1/0.
# Ping the database server from a PC in the Financial department during the working hours. (All PCs in
this example use Windows XP).
C:\> ping 192.168.0.100
Pinging 192.168.0.100 with 32 bytes of data:
Reply from 192.168.0.100: bytes=32 time=1ms TTL=255
Reply from 192.168.0.100: bytes=32 time<1ms TTL=255
Reply from 192.168.0.100: bytes=32 time<1ms TTL=255
Reply from 192.168.0.100: bytes=32 time<1ms TTL=255
Ping statistics for 192.168.0.100:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
The output shows that the database server can be pinged.
# Ping the database server from a PC in the Marketing department during the working hours.
Ping statistics for 192.168.0.100:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
The output shows the database server cannot be pinged.
# Display configuration and match statistics for IPv4 advanced ACL 3000 on Device A during the
working hours.
[RouterA] display acl 3000
Advanced ACL 3000, named -none-, 3 rules,
ACL's step is 5
rule 0 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.0.100 0
rule 5 permit ip source 192.168.2.0 0.0.0.255 destination 192.168.0.100 0 time-range work
(4 times matched) (Active)
rule 10 deny ip destination 192.168.0.100 0 (4 times matched)
The output shows that rule 5 is active. Rule 5 and rule 10 have been matched four times as the result of
the ping operations.
16
QoS overview
In data communications, Quality of Service (QoS) provides differentiated service guarantees for
diversified traffic in terms of bandwidth, delay, jitter, and drop rate, all of which can affect QoS.
QoS manages network resources and prioritizes traffic to balance system resources.
The following section describes typical QoS service models and widely used QoS techniques.
QoS service models
This section describes several typical QoS service models.
Best-effort service model
The best-effort model is a single-service model. The best-effort model is not as reliable as other models
and does not guarantee delay-free delivery.
The best-effort service model is the default model for the Internet and applies to most network
applications. It uses the First In First Out (FIFO) queuing mechanism.
IntServ model
The integrated service (IntServ) model is a multiple-service model that can accommodate diverse QoS
requirements. This service model provides the most granularly differentiated QoS by identifying and
guaranteeing definite QoS for each data flow.
In the IntServ model, an application must request service from the network before it sends data. IntServ
signals the service request with the RSVP. All nodes receiving the request reserve resources as requested
and maintain state information for the application flow. For more information about RSVP, see MPLS Configuration Guide.
The IntServ model demands high storage and processing capabilities because it requires all nodes along
the transmission path to maintain resource state information for each flow. This model is suitable for
small-sized or edge networks, but not large-sized networks, for example, the core layer of the Internet,
where billions of flows are present.
DiffServ model
The differentiated service (DiffServ) model is a multiple-service model that can meet diverse QoS
requirements. It is easy to implement and extend. DiffServ does not signal the network to reserve
resources before sending data, as IntServ does.
QoS techniques overview
The QoS techniques include the following functions:
17
• Traffic classification.
• Traffic policing.
• Traffic shaping.
• Rate limit.
• Congestion management.
• Congestion avoidance.
The following section briefly introduces these QoS techniques.
All QoS techniques in this document are based on the DiffServ model.
Deploying QoS in a network
Figure 2 Position of the QoS techniques in a network
As shown in Figure 2, traffic classification, traffic shaping, traffic policing, congestion management, and
congestion avoidance mainly implement the following functions:
•Traffic classification—Uses match criteria to assign packets with the same characteristics to a traffic
class. Based on traffic classes, you can provide differentiated services.
•Traffic policing—Polices flows and imposes penalties to prevent aggressive use of network resources.
You can apply traffic policing to both incoming and outgoing traffic of a port.
•Traffic shaping—Adapts the output rate of traffic to the network resources available on the
downstream device to eliminate packet drops. Traffic shaping usually applies to the outgoing traffic
of a port.
•Congestion management—Provides a resource scheduling policy to determine the packet
forwarding sequence when congestion occurs. Congestion management usually applies to the
outgoing traffic of a port.
•Congestion avoidance—Monitors the network resource usage. It is usually applied to the outgoing
traffic of a port. When congestion worsens, congestion avoidance reduces the queue length by
dropping packets.
18
QoS processing flow in a device
Figure 3 briefly describes how the QoS module processes traffic:
1. Traffic classifier identifies and classifies traffic for subsequent QoS actions.
2. The QoS module takes various QoS actions on classified traffic as configured, depending on the
traffic processing phase and network status. For example, you can configure the QoS module to
perform the following:
{ Traffic policing for incoming traffic.
{ Traffic shaping for outgoing traffic.
{ Congestion avoidance before congestion occurs.
{ Congestion management when congestion occurs.
Figure 3QoS processing flow
...
19
Configuring a QoS policy
In this chapter, "MSR1000" refers to MSR1002-4. "MSR2000" refers to MSR2003, MSR2004-24,
MSR2004-48. "MSR3000" collectively refers to MSR3012, MSR3024, MSR3044, MSR3064.
"MSR4000" collectively refers to MSR4060 and MSR4080.
You can configure QoS by using the MQC approach or non-MQC approach. Some features support
both approaches, but some support only one.
Non-MQC approach
In the non-MQC approach, you configure QoS service parameters without using a QoS policy. For
example, you can use the rate limit feature to set a rate limit on an interface without using a QoS policy.
MQC approach
In the modular QoS configuration (MQC) approach, you configure QoS service parameters by using
QoS policies. A QoS policy defines the shaping, policing, or other QoS actions to take on different
classes of traffic. It is a set of class-behavior associations.
A traffic class is a set of match criteria for identifying traffic, and it uses the AND or OR operator:
• If the operator is AND, a packet must match all the criteria to match the traffic class.
• If the operator is OR, a packet matches the traffic class if it matches any of the criteria in the traffic
class.
A traffic behavior defines a set of QoS actions to take on packets, such as priority marking and redirect.
By associating a traffic behavior with a traffic class in a QoS policy, you apply the specific set of QoS
actions to the traffic class.
Configuration procedure diagram
Figure 4 shows how to configure a QoS policy.
20
Figure 4 QoS policy configuration procedure
Defining a traffic class
Step Command
1. Enter system view.
2. Create a traffic class and
enter traffic class view.
3. Configure match criteria.
system-view N/A
traffic classifier classifier-name[ operator { and | or } ]
if-match [ not ] match-criteria
Defining a traffic behavior
A traffic behavior is a set of QoS actions (such as traffic filtering, shaping, policing, and priority marking)
to perform on a traffic class.
To define a traffic behavior:
Step Command
1. Enter system view.
2. Create a traffic behavior and
enter traffic behavior view.
system-view N/A
traffic behavior behavior-name
Remarks
By default, no traffic class is
configured.
By default, no match criterion is
configured.
For more information, see the
if-match command in ACL and
QoS Command Reference.
Remarks
By default, no traffic behavior is
configured.
See the subsequent chapters,
3. Configure actions in the traffic
behavior.
depending on the purpose of the
traffic behavior: traffic policing,
traffic filtering, priority marking,
and so on.
21
By default, no action is configured
for a traffic behavior.
Defining a QoS policy
Configuring a parent policy
You associate a traffic behavior with a traffic class in a QoS policy to perform the actions defined in the
traffic behavior for the traffic class of packets.
To associate a traffic class with a traffic behavior in a QoS policy:
Step Command
1. Enter system view.
2. Create a QoS policy and
enter QoS policy view.
3. Associate a traffic class with a
traffic behavior to create a
class-behavior association in
the QoS policy.
system-view N/A
qos policy policy-name
classifier classifier-name behavior
behavior-name
Configuring a child policy
You can nest a QoS policy in a traffic behavior to reclassify the traffic class associated with the behavior.
Then the actions that are defined in the QoS policy are taken on the reclassified traffic. The QoS policy
nested in the traffic behavior is called a child policy. The QoS policy that nests the behavior is called a
parent policy.
To nest QoS policies successfully, follow these guidelines:
• If class-based queuing (CBQ) is configured in a child policy, GTS must be configured in the parent
policy, and the CIR specified in GTS must be greater than or equal to CBQ bandwidth.
• If the CIR in GTS is specified as a percentage for a parent policy, the CBQ bandwidth must be
configured as a percentage for the child policy. If the CIR in GTS is specified as a value in kbps for
a parent policy, the CBQ bandwidth can be configured as a percentage or a value in kbps for the
child policy.
Remarks
By default, no QoS policy is
configured.
By default, a traffic class is not
associated with a traffic behavior.
Repeat this step to create more
class-behavior associations.
• GTS cannot be configured in the child policy.
To nest a child QoS policy in a parent QoS policy:
Step Command
1. Enter system view.
2. Create a class for the
parent policy and enter
class view.
3. Configure match criteria.
system-view N/A
traffic classifier classifier-name[ operator { and | or } ]
if-match [ not ] match-criteria
22
Remarks
By default, no class is configured.
By default, no match criterion is
configured.
For more information about configuring
match criteria, see ACL and QoS Command Reference.
Step Command
4. Return to system view.
5. Create a behavior for the
parent policy and enter
behavior view.
6. Nest the child QoS
policy.
7. Return to system view.
8. Create the parent policy
and enter parent policy
view.
9. Associate the class with
the behavior in the
parent policy.
quit N/A
traffic behavior behavior-name By default, no behavior is created.
traffic-policy policy-nameBy default, policy nesting is not configured.
quit N/A
qos policy policy-nameBy default, no policy is created.
classifier classifier-name
behavior behavior-name
Applying the QoS policy
You can apply a QoS policy to the following destinations:
•Interface or PVC—The Q oS p olic y take s effect on th e tra ffic sent or re ceived on t he i nter face or P VC .
Remarks
By default, a class is not associated with a
behavior.
• Control plane—The QoS policy takes effect on the traffic received on the control plane.
• Management interface control plane—The QoS policy takes effect on the traffic sent from the
management interface to the control plane.
You can modify traffic classes, traffic behaviors, and class-behavior associations in a QoS policy even
after it is applied. If a traffic class references an ACL for traffic classification, you can delete or modify the
ACL.
Applying the QoS policy to an interface or PVC
A QoS policy can be applied to multiple interfaces or PVCs, but only one QoS policy can be applied to
one direction (inbound or outbound) of an interface or PVC.
The QoS policy applied to the outgoing traffic on an interface or PVC does not regulate local packets,
which are critical protocol packets sent by the local system for operation maintenance. The most common
local packets include link maintenance, routing, LDP, RSVP, and SSH packets.
To apply the QoS policy to an interface or PVC:
Step Command
1. Enter system view.
system-view N/A
• Enter interface view:
interface interface-type
2. Enter interface or PVC
view.
interface-number
• Enter PVC view:
a. interface atm interface-number
b. pvc vpi/vci
Remarks
Settings in interface view take
effect on the current interface.
Settings in PVC view take
effect on the current PVC.
A device provides the data plane and the control plane:
•Data plane—The units at the data plane are responsible for receiving, transmitting, and switching
(forwarding) packets, such as various dedicated forwarding chips. They deliver super processing
speeds and throughput.
•Control plane—The units at the control plane are processing units running most routing and
switching protocols. They are responsible for protocol packet resolution and calculation, such as
CPUs. Compared with data plane units, the control plane units 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, 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, apply a QoS policy to the control plane to take QoS actions, such as traffic
filtering or rate limiting, on inbound traffic. This makes sure the control plane can correctly receive,
transmit, and process packets.
By default, no QoS policy is
applied to an interface or
PVC.
The router is enabled with predefined control plane QoS policies by default. A predefined control plane
QoS policy uses the protocol type or protocol group type to identif y the t yp e of packets s ent to the control
plane. You can reference protocol types or protocol group types in if-match commands in traffic class
view for traffic classification. Then you can reconfigure traffic behaviors for these traffic classes as
required. You can use the display qos policy control-planepre-defined command to display predefined
control plane QoS policies.
If the hardware resources of an interface card are insufficient, applying a QoS policy to the control plane
might fail on the interface card. The system does not automatically roll back the QoS policy already
applied to the MPU or other interface cards. To ensure consistency, you must use the undo qos apply
policy command to manually remove the QoS policy configuration applied to them.
Configuration procedure
To apply the QoS policy to the control plane:
Step Command
1. Enter system view.
2. Enter control plane view.
3. Apply the QoS policy to
the control plane.
Remarks
system-view N/A
• MSR1000/MSR2000/MSR3000:
control-plane
• MSR4000:
control-plane slot slot-number
qos apply policy policy-name inbound
N/A
By default, no QoS policy is
applied to a control plane.
24
y
Applying the QoS policy to the management interface control
plane
The following matrix shows the feature and hardware compatibility:
Hardware Feature compatibilit
MSR1000 No
MSR2000 No
MSR3000 No
MSR4000 Yes
If the transmission rate of the packets sent from the management interface to the control plane exceeds
the processing capability of the control plane, the control plane will fail to handle the packets correctly
or timely. As a result, protocol performance is affected.
To address this problem, apply a rate-limiting QoS policy to the packets sent from the management
interface to the control plane. This makes sure the control plane can correctly receive, transmit, and
process packets from the management interface.
By default, the management interface is enabled with predefined rate-limiting QoS policies by default. A
predefined rate-limiting QoS policy uses the protocol type or protocol group type to identify the type of
packets sent to the management interface. You can reference protocol types or protocol group types in
if-match commands in traffic class view for traffic classification and then reconfigure traffic behaviors for
these traffic classes as required. You can use the display qos policy control-plane management pre-defined command to display the traffic behaviors.
To apply the QoS policy to the management interface control plane:
Step Command
1. Enter system view.
2. Enter management
interface control plane
view.
3. Apply the QoS policy to
the management
interface control plane.
system-view N/A
control-plane management N/A
qos apply policy policy-name inbound
Remarks
By default, no QoS policy is
applied to the management
interface control plane.
Configuring the QoS policy-based traffic rate
statistics collection period for an interface
You can enable collection of per-class traffic statistics over a period of time, including the average
forwarding rate and drop rate. For example, if you set the statistics collection period to n minutes, the
system collects traffic statistics for the most recent n minutes and refreshes the statistics every 10/n minutes.
You can use the display qos policy interface command to view the collected traffic rate statistics.
To configure the QoS policy-based traffic rate statistics collection period for an interface:
25
Step Command
1. Enter system view.
2. Enter interface view.
3. Configure the traffic rate
statistics collection period
for the interface.
system-view N/A
interface interface-type interface-numberN/A
qos flow-interval interval
Remarks
The default setting is 5 minutes.
A subinterface uses the statistics
collection period configured on
the main interface.
A PVC uses the statistics
collection period configured on
the ATM main interface.
Displaying and maintaining QoS policies
Execute display commands in any view and reset commands in user view.
Task Command
Display traffic class configuration
(MSR1000/MSR2000/MSR3000).
Clear the statistics for the QoS policy
applied to a control plane (MSR4000).
Clear the statistics for the QoS policy
applied to the management interface
control plane (MSR4000).
reset qos policy control-plane slot slot-number
reset qos policy control-plane management
Configuring priority mapping
Overview
When a packet arrives, a device assigns a set of QoS priority parameters to the packet based on either
a priority field carried in the packet or the port priority of the incoming port. This process is called
"priority mapping." During this process, the device can modify the priority of the packet according to the
priority mapping rules. The set of QoS priority parameters decides the scheduling priority and
forwarding priority of the packet.
Priority mapping is implemented with priority maps and involves the following priorities:
• 802.1p priority.
• DSCP.
• EXP.
• IP precedence.
• Local precedence.
Introduction to priorities
Priorities include the following types: priorities carried in packets, and priorities locally assigned for
scheduling only.
Packet-carried priorities include 802.1p priority, DSCP precedence, IP precedence, and EXP. These
priorities have global significance and affect the forwarding priority of packets across the network. For
more information about these priorities, see "Appendixes."
Locally assigned priorities only have local significance. They are assigned by the device only for
scheduling. These priorities include the local precedence, drop priority, and user priority, as follows:
•Local precedence—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.
•User priority—Precedence that the device automatically extracts from a priority field of the packet
according to its forwarding path. It is a parameter for determining the scheduling priority and
forwarding priority of the packet. The user priority represents:
{ The 802.1p priority for Layer 2 packets.
{ The IP precedence for Layer 3 packets.
{ The EXP for MPLS packets.
Priority maps
The device provides various types of priority maps. By looking through a priority map, the device decides
which priority value to assign to a packet for subsequent packet processing.
28
Loading...
+ 78 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.