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.
Applications on the switch ······································································································································ 1
ACL categories ························································································································································· 1
Numbering and naming ACLs ································································································································ 1
Match order ······························································································································································ 2
Rule comments and rule range remarks ················································································································· 2
Rule numbering ························································································································································· 3
Implementing time-based ACL rules ························································································································ 3
Fragments filtering with ACLs ·································································································································· 3
Configuration task list ······················································································································································· 4
Configuring a time range ················································································································································· 4
Configuring a basic ACL ·················································································································································· 4
Configuring an IPv4 basic ACL ······························································································································ 4
Configuring an IPv6 basic ACL ······························································································································ 5
Configuring an advanced ACL ········································································································································ 6
Configuring an IPv4 advanced ACL······················································································································· 6
Configuring an IPv6 advanced ACL······················································································································· 7
Configuring an Ethernet frame header ACL ··················································································································· 8
Copying an ACL ······························································································································································· 9
Copying an IPv4 basic, IPv4 advanced, or Ethernet frame header ACL ··························································· 9
Copying an IPv6 basic or IPv6 advanced ACL ·································································································· 10
Configuring packet filtering with ACLs ························································································································ 10
Applying an IPv4 basic, IPv4 advanced, or Ethernet frame header ACL for packet filtering ······················· 10
Applying an IPv6 basic or IPv6 advanced ACL for packet filtering ································································ 11
Displaying and maintaining ACLs ································································································································ 11
ACL configuration examples ········································································································································· 11
IPv4 packet filtering configuration example ······································································································· 12
IPv6 packet filtering configuration example ······································································································· 12
QoS service models ······················································································································································· 14
Best-effort service model ······································································································································· 14
IntServ model ························································································································································· 14
DiffServ model ······················································································································································· 14
QoS techniques ······························································································································································ 15
Non-MQC approach ············································································································································ 16
Configuring a QoS policy ············································································································································· 16
Defining a class ····················································································································································· 17
Defining a traffic behavior ··································································································································· 19
Defining a policy ··················································································································································· 19
Applying the QoS policy ······································································································································ 20
Displaying and maintaining QoS policies ·········································································································· 21
Types of priorities ·················································································································································· 22
Priority trust mode on a port ································································································································· 23
Priority mapping procedure ································································································································· 23
Priority mapping configuration task list ······················································································································· 24
Configuring a priority mapping table ·························································································································· 24
Configuring the priority trust mode ······························································································································ 24
Changing the port priority of an interface ·················································································································· 25
Displaying and maintaining priority mapping ············································································································ 25
Priority mapping configuration examples ···················································································································· 25
Priority trust mode configuration example ·········································································································· 25
Priority mapping table and priority marking configuration example ······························································ 26
Configuring traffic policing, traffic shaping, and rate limit ···················································································· 30
Appendix A Default priority mapping tables ·············································································································· 62
Appendix B Introduction to packet precedences ········································································································ 63
IP precedence and DSCP values ·························································································································· 63
Support and other resources ····································································································································· 66
Contacting HP ································································································································································ 66
Subscription service ·············································································································································· 66
Related information ························································································································································ 66
Index ··········································································································································································· 69
iii
Configuring ACLs
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.
Overview
ACLs are primarily used for packet filtering. "Configuring packet filtering with ACLs" provides an
example. You can use ACLs in Quality of Service (QoS), routing, and other feature modules for
identifying traffic. The packet drop or forwarding decisions varies with the modules that use ACLs.
Applications on the switch
An ACL is implemented in hardware or software, depending on the module that uses it. If the module is
implemented in hardware (for example, the packet filter or QoS module), the ACL is applied to hardware
to process traffic. If the module is implemented in software (for example, the routing or user interface
access control module such as Telnet, SNMP, or web), the ACL is applied to software to process traffic.
The user interface access control module denies packets that do not match any ACL. Some modules (QoS,
for example), ignore the permit or deny action in ACL rules and do not base their drop or forwarding
decisions on the action set in ACL rules. See the specified module for information about ACL application.
ACL categories
Category ACL number IP version
Basic ACLs 2000 to 2999
Advanced ACLs 3000 to 3999
Ethernet frame
header ACLs
4000 to 4999 IPv4 and IPv6
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.
Match criteria
Source IPv4 address, destination IPv4 address,
packet priority, protocols over IPv4, and other
Layer 3 and Layer 4 header fields
Source IPv6 address, destination IPv6 address,
packet priority, protocols over IPv6, 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
For an IPv4 basic or advanced ACLs, its ACL number and name must be unique in IPv4, and for an IPv6
basic or advanced ACL, its ACL number and name must be unique in IPv6.
1
Match order
gory
The rules in an ACL are sorted in a specific order. When a packet matches a rule, the device stops the
matching process and performs the action defined in the rule. If an ACL contains overlapping or
conflicting rules, the matching result and action to take depend on the rule order.
The following ACL match orders are available:
•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, carefully check the rules and their order.
•auto—Sorts ACL rules in depth-first order. Depth-first ordering makes sure that any subset of a rule
is always matched before the rule. Table 1 lists the
uses to sort rules for each type of ACL.
Table 1 Sorting ACL rules in depth-first order
sequence of tie breakers that depth-first ordering
ACL cate
IPv4 basic ACL
IPv4 advanced ACL
IPv6 basic ACL
IPv6 advanced ACL
Ethernet frame header ACL
Sequence of tie breakers
1. VPN instance
2. More 0s in the source IP address wildcard (more 0s means a narrower IP
address range)
3. Rule configured earlier
4. VPN instance
5. Specific protocol type rather than IP (IP represents any protocol over IP)
6. More 0s in the source IP address wildcard mask
7. More 0s in the destination IP address wildcard
8. Narrower TCP/UDP service port number range
9. Rule configured earlier
10. VPN instance
11. Longer prefix for the source IP address (a longer prefix means a narrower IP
address range)
12. Rule configured earlier
13. VPN instance
14. Specific protocol type rather than IP (IP represents any protocol over IPv6)
15. Longer prefix for the source IPv6 address
16. Longer prefix for the destination IPv6 address
17. Narrower TCP/UDP service port number range
18. Rule configured earlier
19. More 1s in the source MAC address mask (more 1s means a smaller MAC
address)
20. More 1s in the destination MAC address mask
21. Rule configured earlier
A wildcard mask, also called an inverse mask, is a 32-bit binary and represented in dotted decimal
notation. In contrast to a network mask, the 0 bits in a wildcard mask represent "do care" bits, and the
1 bits represent "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 comments and rule range remarks
Add a comment about an ACL rule to make it easy to understand. The rule comment appears below the
rule statement.
2
In addition, add a rule range remark to indicate the start or end of a range of rules created for the same
purpose.
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
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 rules, 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.
Implementing time-based ACL rules
You can implement ACL rules based on the time of day by applying a time range to them. A time-based
ACL rule only takes effect in any time periods specified by the time range.
The following basic types of time range are available:
• Periodic time range—Recurs periodically on a day or days of the week.
• Absolute time range—Represents only a period of time and does not recur.
You can specify a time range in ACL rules before or after you create it. However, the rules using the time
range take effect only after you define the time range.
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 following:
• Filters all fragments by default, including non-first fragments.
• Allows for matching criteria modification, for example, filters only non-first fragments.
3
Configuration task list
Task Remarks
Configuring a time range
Configuring a basic ACL
Configuring an advanced ACL
Configuring an Ethernet frame header ACL
Copying an ACL
Configuring packet filtering with ACLs
Configuring a time range
You can create a maximum of 256 time ranges, each having a maximum of 32 periodic statements and
12 absolute statements. If a time range has multiple statements, its active period is calculated as follows:
1. Combining all periodic statements.
2. Combining all absolute statements.
3. Taking the intersection of the two statement sets as the active period of the time range.
Optional.
Applicable to IPv4 and IPv6.
Required.
Configure at least one task.
Applicable to IPv4 and IPv6.
Optional.
Applicable to IPv4 and IPv6.
Optional.
Applicable to IPv4 and IPv6.
To configure a time range:
Step Command
1. Enter system view. system-view N/A
time-range time-range-name
2. Configure a time
range.
{ start-timetoend-timedays [ from
time1 date1 ] [ to time2 date2 ] |
from time1 date1 [ to time2 date2 ]
| to time2 date2 }
Configuring a basic ACL
This section describes how to configure an IPv4 basic ACL and an IPv6 basic ACL.
Configuring an IPv4 basic ACL
IPv4 basic ACLs match packets based only on source IP addresses.
To configure an IPv4 basic ACL:
Remarks
By default, no time range exists.
Repeat this command with the same time
range name to create multiple statements for
a time range.
By default, an IPv6 basic ACL has no ACL
description.
Optional.
The default setting is 5.
By default, an IPv6 basic ACL does not contain
any rules.
• If the ACL is for QoS traffic classification, do
not specify the fragment, routing, or
vpn-instance keyword. Also, the logging and
counting keywords (even if specified) do not
take effect.
• If the ACL is for packet filtering, do not specify
the fragment, routing, or vpn-instance
keyword.
Optional.
By default, no rule comments are configured.
Optional.
By default, no rule range remarks are configured.
Optional.
By default, this feature is disabled.
When the ACL is referenced by a QoS policy, this
command does not take effect.
Configuring an advanced ACL
This section describes how to configure an IPv4 advanced ACL and an IPv6 advanced ACL.
Configuring an IPv4 advanced ACL
IPv4 advanced ACLs match packets based on source IP addresses, destination IP addresses, packet
priorities, protocols over IP, and other protocol header information, such as TCP/UDP source and
destination port numbers, TCP flags, ICMP message types, and ICMP message codes.
Compared to IPv4 basic ACLs, IPv4 advanced ACLs allow more flexible and accurate filtering.
To configure an IPv4 advanced ACL:
Step Command Remarks
1. Enter system view.
2. Create an IPv4
advanced ACL and
enter its view.
system-view N/A
acl number acl-number [ name
acl-name ] [ match-order { auto |
config } ]
By default, no ACL exists.
IPv4 advanced ACLs are numbered in the
range of 3000 to 3999.
You can use the acl name acl-name
command to enter the view of a named ACL.
6
Step Command Remarks
3. Configure a
description for the
IPv4 advanced ACL.
4. Set the rule
numbering step.
5. Create or edit a rule.
description text
step step-value
rule [ rule-id ] { deny | permit }
protocol [ { { ack ack-value | fin
fin-value | psh psh-value | rst
rst-value | syn syn-value | urg
urg-value } * | established } |
port1 [ port2 ] | time-range
time-range-name | tos tos | vpn-instance v
*
pn-instance-name ]
Optional.
By default, an IPv4 advanced ACL has no
ACL description.
Optional.
The default setting is 5.
By default, an IPv4 advanced ACL does not
contain any rules.
If an IPv4 advanced ACL is for QoS traffic
classification or packet filtering:
• Do not specify the vpn-instance keyword
or specify neq for the operator argument.
• The logging and counting keywords
(even if specified) do not take effect for
QoS traffic classification.
6. Add or edit a rule
comment.
7. Add or edit a rule
range remark.
8. Enable counting ACL
rule matches
performed in
hardware.
rule rule-id comment text
rule [ rule-id ]remark text
hardware-count enable
Configuring an IPv6 advanced ACL
IPv6 advanced ACLs match packets based on the source IPv6 addresses, destination IPv6 addresses,
packet priorities, protocols carried over IPv6, and other protocol header fields such as the TCP/UDP
source port number, TCP/UDP destination port number, ICMPv6 message type, and ICMPv6 message
code.
Compared to IPv6 basic ACLs, IPv6 advanced ACLs allow more flexible and accurate filtering.
To configure an IPv6 advanced ACL:
Optional.
By default, no rule comments are
configured.
Optional.
By default, no rule range remarks are
configured.
Optional.
By default, this feature is disabled.
When the ACL is referenced by a QoS
policy, this command does not take effect.
Step Command Remarks
1. Enter system view. system-view N/A
7
Step Command Remarks
By default, no ACL exists.
2. Create an IPv6
advanced ACL
and enter its view.
3. Configure a
description for the
IPv6 advanced
ACL.
4. Set the rule
numbering step.
acl ipv6 number acl6-number [ name acl6-name ] [ match-order { auto |
config } ]
description text
step step-value
IPv6 advanced ACLs are numbered in the
range of 3000 to 3999.
You can use the acl ipv6 name acl6-name
command to enter the view of a named
ACL.
Optional.
By default, an IPv6 advanced ACL has no
ACL description.
Optional.
The default setting is 5.
5. Create or edit a
rule.
6. Add or edit a rule
comment.
7. Add or edit a rule
range remark.
rule [ rule-id ] { deny | permit } protocol
[ { { ack ack-value | fin fin-value | psh
psh-value | rst rst-value | syn syn-value
By default, an IPv6 advanced ACL does not
contain any rules.
When the protocol argument takes 43, 44,
51, or 60, the ACL cannot function for the
outbound QoS application.
If an IPv6 advanced ACL is for QoS traffic
classification or packet filtering:
•Do not specify the fragment, routing, or
vpn-instance keyword or specify neq
for the operator argument.
• Do not specify the flow-label keyword if
the ACL is for outbound QoS traffic
classification or outbound packet
filtering.
• The logging and counting keywords
(even if specified) do not take effect for
QoS traffic classification.
Optional.
By default, no rule comments are
configured.
Optional.
By default, no rule range remarks are
configured.
8. Enable counting
ACL rule matches
performed in
hardware.
hardware-count enable
Optional.
By default, this feature is disabled.
When the ACL is referenced by a QoS
policy, this command does not take effect.
Configuring an Ethernet frame header ACL
Ethernet frame header ACLs, also called "Layer 2 ACLs," match packets based on Layer 2 protocol
header fields, such as source MAC address, destination MAC address, 802.1p priority (VLAN priority),
and link layer protocol type.
To configure an Ethernet frame header ACL:
8
Step Command Remarks
1. Enter system view. system-view N/A
2. Create an
Ethernet frame
header ACL and
enter its view.
3. Configure a
description for the
Ethernet frame
header ACL.
4. Set the rule
numbering step.
5. Create or edit a
rule.
acl numberacl-number
[ name acl-name ]
[ match-order { auto |
Ethernet frame header ACLs are numbered in the
range of 4000 to 4999.
You can use the aclnameacl-name command to enter
the view of a named Ethernet frame header ACL.
Optional.
By default, an Ethernet frame header ACL has no ACL
description.
Optional.
The default setting is 5.
By default
contain any rules.
If the ACL is for QoS traffic classification or packet
filtering, to use the lsap keyword, the lsap-type
argument must be AAAA, and the lasp-type-mask
argument must be FFFF. Otherwise, the ACL cannot
function normally.
,
an Ethernet frame header ACL does not
6. Add or edit a rule
comment.
7. Add or edit a rule
range remark.
8. Enable rule match
counting for the
Ethernet frame
header ACL.
rule rule-id comment text
rule [ rule-id ]remark text
hardware-count enable
Optional.
By default, no rule comments are configured.
Optional.
By default, no rule range remarks are configured.
Optional.
By default, rule match counting is disabled for an
Ethernet frame header ACL.
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 that:
• The destination ACL number is from the same category as the source ACL number.
• The source ACL already exists, but the destination ACL does not.
Copying an IPv4 basic, IPv4 advanced, or Ethernet frame
header ACL
9
Step Command
t
g
1. Enter system view. system-view
2. Copy an existing IPv4
basic, IPv4 advanced,
or Ethernet frame
header ACL to create a
new ACL.
acl copy { source-acl-number | name source-acl-name } to { dest-acl-number |
name dest-acl-name }
Copying an IPv6 basic or IPv6 advanced ACL
Step Command
1. Enter system view.
2. Co py a n existing I P v 6 basic or
IPv6 advanced ACL to create
a new ACL.
system-view
acl ipv6 copy { source-acl6-number | name source-acl6-name } to
{ dest-acl6-number | name dest-acl6-name }
Configuring packet filtering with ACLs
You can use an ACL to filter incoming or outgoing IPv4 or IPv6 packets.
ACLs on VLAN interfaces filter only packets forwarded at Layer 3.
When you configure packet filtering with ACLs on a port, you can use IPv4 ACLs, IPv6 ACLs, or Ethernet
frame header ACLs. In a direction of a port, you can use only one ACL of a type.
NOTE:
Bridge mode (Layer 2) Ethernet ports, route mode (Layer 3) Ethernet ports, and VLAN interfaces suppor
configuring packet filtering with ACLs. The term "interface" in this section collectively refers to these types
of ports. You can use the portlink-mode command to set an Ethernet port to operate in brid
mode (see
Layer 2—LAN Switching Configuration Guide
).
e or route
Applying an IPv4 basic, IPv4 advanced, or Ethernet frame
header ACL for packet filtering
Step Command
1. Enter system view.
2. Enter interface view.
3. Apply an IPv4 basic, IPv4
advanced, or Ethernet frame
header ACL to the interface to
filter packets.
display time-range { time-range-name | all } [ | { begin | exclude | include }
regular-expression ]
resetaclcounter { acl-number | all | name
acl-name }
reset acl ipv6 counter { acl6-number | all |
name acl6-name }
Available in any view.
Available in any view.
Available in any view.
Available in any view.
Available in user view.
Available in user view.
ACL configuration examples
This section provides ACL configuration examples.
11
IPv4 packet filtering configuration example
Network requirements
As shown in Figure 1, apply an ACL to the inbound direction of interface GigabitEthernet 1/0/1 on
Device A so that every day, from 8:00 to 18:00, the interface allows only packets sourced from Host A
to pass.
Figure 1 Network diagram
Configuration procedure
# Create a time range from 08:00 to 18:00 every day.
<DeviceA> system-view
[DeviceA] time-range study 8:00 to 18:00 daily
# Create IPv4 basic ACL 2009, and configure two rules in the ACL. One rule permits packets sourced
from Host A and the other denies packets sourced from any other host during the time range study.
[DeviceA] acl number 2009
[DeviceA-acl-basic-2009] rule permit source 192.168.1.2 0 time-range study
[DeviceA-acl-basic-2009] rule deny source any time-range study
[DeviceA-acl-basic-2009] quit
# Configure the device to output informational log messages to the console.
As shown in Figure 2, apply an ACL to the incoming traffic of GigabitEthernet 1/0/1 on Device A so that
every day, from 8:00 to 18:00, the interface allows only packets from Host A to pass through. Configure
12
Figure 2 Network diagram
Configuration procedure
# Create a time range from 08:00 to 18:00 every day.
<DeviceA> system-view
[DeviceA] time-range study 8:0 to 18:0 daily
# Create IPv6 basic ACL 2009, and configure two rules for the ACL. One permits packets sourced from
Host A and the other denies packets sourced from any other host during the time range study.
[DeviceA] acl ipv6 number 2009
[DeviceA-acl6-basic-2009] rule permit source 1001::2 128 time-range study
[DeviceA-acl6-basic-2009] rule deny source any time-range study
[DeviceA-acl6-basic-2009] quit
# Configure the device to output informational log messages to the console.
In data communications, Quality of Service (QoS) is a network's ability to provide differentiated service
guarantees for diversified traffic in terms of bandwidth, delay, jitter, and drop rate.
Network resources are scarce. The contention for resources requires that QoS prioritize important traffic
flows over trivial ones. For example, when bandwidth is fixed, more bandwidth for one traffic flow means
less bandwidth for the other traffic flows. When making a QoS scheme, consider the characteristics of
various applications to balance the interests of diversified users and to utilize network resources.
The following section describes some typical QoS service models and widely used, mature QoS
techniques.
QoS service models
This section describes the QoS service models.
Best-effort service model
The best-effort model is a single-service model and is also the simplest service model. In this service
model, the network does its best to deliver packets, but does not guarantee delivery or reliability.
The best-effort service model is the default model in 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 because it identifies
and guarantees 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 Resource Reservation Protocol (RSVP). All nodes receiving the request
reserve resources as requested and maintain state information for the application flow.
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.
All QoS techniques in this document are based on the DiffServ model.
14
QoS techniques
The QoS techniques include traffic classification, traffic policing, traffic shaping, rate limit, congestion
management, and congestion avoidance. The following section briefly introduces these QoS techniques.
Figure 3 Position of the QoS techniques in a network
As shown in Figure 3, traffic classification, traffic shaping, traffic policing, congestion management, and
congestion avoidance mainly implement the following functions:
• Traffic classification uses certain match criteria to assign packets with the same characteristics to a
class. You can provide differentiated services based on classes.
• Traffic policing polices flows entering or leaving a device, and imposes penalties on traffic flows
that exceed the preset threshold to prevent aggressive use of network resources. You can apply
traffic policing to both incoming and outgoing traffic of a port.
• To eliminate packet drops, traffic shaping proactively adapts the output rate of traffic to the network
resources available on the downstream device. 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 and is usually applied to the outgoing
traffic of a port. When congestion worsens, congestion avoidance reduces the queue length by
dropping packets.
15
QoS configuration approaches
This chapter describes the QoS configuration approaches.
Overview
You can configure QoS in the following approaches:
• MQC approach
• Non-MQC approach
ome features support both approaches, but some support only one.
S
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 class is a set of match criteria for identifying traffic, and it uses the AND or OR operator:
• AND—A packet must match all criteria to match the class.
• OR—A packet matches the class if it matches any of the criteria in the 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 class in a QoS policy, you apply the specific set of QoS actions
to the class of traffic.
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.
Configuring a QoS policy
Figure 4 shows how to configure a QoS policy.
16
Figure 4 QoS policy configuration procedure
Defining a class
This section describes how to define a class.
Configuration guidelines
If a class that uses the AND operator has multiple if-match acl, if-match acl ipv6, if-match
customer-vlan-id or if-match service-vlan-id clauses, a packet that matches any of the clauses matches
the class.
To successfully execute the traffic behavior associated with a traffic class that uses the AND operator,
define only one if-match clause for any of the following match criteria, and enter only one value for any
of the following list arguments (for example, the 8021p-list argument):
• customer-dot1p 8021p-list
• destination-mac mac-address
• dscp dscp-list
• ip-precedence ip-precedence-list
• service-dot1p 8021p-list
• source-mac mac-address
To create multiple if-match clauses for these match criteria or specify multiple values for the list arguments,
specify the operator of the class as OR and use the if-match command multiple times.
Configuration procedure
To define a class:
17
Loading...
+ 49 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.