Configuring QoS on Catalyst 3750 Metro Switches

CH A P T E R 34
Configuring QoS
This chapter describes how to use different methods to configure quality of service (QoS) on the
Catalyst 3750 Metro switch. With QoS, you can provide preferential treatment to certain types of traffic
traffic at the expense of others. Without QoS, the switch offers best-effort service to each packet,
regardless of the packet contents or size. It sends the packets without any assurance of reliability, delay
bounds, or throughput.
You can use auto-QoS to identify ports connected to Cisco IP Phones and to devices running the Cisco
SoftPhone application. You also use the commands to identify ports that receive trusted voice over IP
(VoIP) traffic.
You can use standard QoS to classify, police, mark, queue, and schedule inbound traffic on any port as
well as queue and schedule outbound traffic. On ingress, standard QoS offers classification based on the
class of service (CoS), Differentiated Services Code Point (DSCP), or IP precedence value in the
inbound packet. You can perform the classification based on Layer 2 MAC, IP-standard, or IP-extended
access control lists (ACLs). Standard QoS also offers nonhierarchical single-level policy maps on
physical ports and hierarchical dual-level policy maps on switch virtual interfaces (SVIs). Drop policy
actions are passing through the packet without modification, marking down the assigned DSCP in the
packet, or dropping the packet. Standard QoS performs ingress queueing based on the weighted tail drop
(WTD) algorithm and ingress scheduling based on shaped round robin (SRR). On egress, standard QoS
offers queueing based on WTD and scheduling based on SRR shared or shaped weights. An egress
priority queue is also offered.
Note In the Catalyst 3750, 3560, and 2970 switch software documentation, single-level policy maps are
referred to as nonhierarchical policy maps. Dual-level policy maps are referred to as hierarchical policy
maps with two levels.
You can use hierarchical QoS to classify, police, mark, queue, and schedule inbound or outbound traffic
on an enhanced-services (ES) port or an EtherChannel of ES ports. Hierarchical QoS offers classification
based on the CoS, DSCP, IP precedence, or the multiprotocol label switching (MPLS) experimental
(EXP) bits in the packet. You also can classify a packet based on its VLAN. Hierarchical QoS offers
two-rate traffic policing. Drop policy actions are passing the packet through without modification;
marking down the CoS, DSCP, IP precedence, or the MPLS EXP bits in the packet; or dropping the
packet. Hierarchical QoS performs queueing based on tail drop or Weighted Random Early Detection
(WRED). The queue scheduling management feature is class-based weighted fair queueing (CBWFQ),
and the scheduling congestion-management feature is low-latency queueing (LLQ). You can use traffic
shaping to decrease the burstiness of traffic.
For information about MPLS, Ethernet over MPLS (EoMPLS), and QoS, see the “Configuring MPLS
and EoMPLS QoS” section on page 44-51.
Catalyst 3750 Metro Switch Software Configuration Guide

OL-9644-10 34-1
Chapter 34 Configuring QoS
QoS Overview
Note For complete syntax and usage information for the commands used in this chapter, see the command
reference this release.
This chapter consists of these sections:

• QoS Overview, page 34-2
• Basic QoS Model, page 34-4
• Understanding Standard QoS, page 34-9
• QoS Treatment for Performance-Monitoring Protocols, page 34-25
• Understanding Hierarchical QoS, page 34-30
• Configuring Auto-QoS, page 34-40
• Displaying Auto-QoS Information, page 34-49
• Configuring Standard QoS, page 34-50
• Configuring Marking and Queuing for CPU-Generated Traffic, page 34-98
• Displaying Standard QoS Information, page 34-102
• Configuring Hierarchical QoS, page 34-103
• Displaying Hierarchical QoS Information, page 34-131
QoS Overview
Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority
and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an
equal chance of being dropped.
When you configure the QoS feature, you can select specific network traffic, prioritize it according to
its relative importance, and use congestion-management and congestion-avoidance techniques to
provide preferential treatment. Implementing QoS in your network makes network performance more
predictable and bandwidth utilization more effective.
The QoS implementation is based on the Differentiated Services (Diff-Serv) architecture, an emerging
standard from the Internet Engineering Task Force (IETF). This architecture specifies that each packet
is classified upon entry into the network.
The classification is carried in the IP packet header, using 6 bits from the deprecated IP type of service
(ToS) field to carry the classification (class) information. Classification also can be carried in the
Layer 2 frame. These special bits in the Layer 2 frame or in the Layer 3 packet are described here and
shown in Figure 34-1:
• Prioritization bits in Layer 2 frames:
Layer 2 Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries an IEEE 802.1p
CoS value in the three least-significant bits. On ports configured as Layer 2 ISL trunks, all traffic is
in ISL frames.
Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the CoS value
in the three most-significant bits, which are called the User Priority bits. On ports configured as
Layer 2 802.1Q trunks, all traffic is in IEEE 802.1Q frames except for traffic in the native VLAN.
Other frame types cannot carry Layer 2 CoS values.

34-2 OL-9644-10
QoS Overview
Layer 2 CoS values range from 0 for low priority to 7 for high priority.
• Prioritization bits in Layer 3 packets:
Layer 3 IP packets can carry either an IP precedence value or a DSCP value. QoS supports the use
of either value because DSCP values are backward-compatible with IP precedence values.
IP precedence values range from 0 to 7.
DSCP values range from 0 to 63.
• Cisco IOS Release 12.2(52)SE and later supports IPv6 port-based trust with the dual IPv4 and IPv6
Switch Database Management (SDM) templates. You must reload the switch with the dual IPv4 and
IPv6 templates for switches running IPv6. For more information, see Chapter 6, “Configuring SDM
Templates.”
Figure 34-1 QoS Classification Layers in Frames and Packets
Encapsulated Packet
Layer 2
IP header Data
header
Layer 2 ISL Frame

ISL header Encapsulated frame 1... FCS
(26 bytes) (24.5 KB) (4 bytes)
3 bits used for CoS
Layer 2 802.1Q and 802.1p Frame

Start frame
Preamble DA SA Tag PT Data FCS
delimiter
3 bits used for CoS (user priority)
Layer 3 IPv4 Packet

Version ToS
Len ID Offset TTL Proto FCS IP-SA IP-DA Data
length (1 byte)
IP precedence or DSCP
Layer 3 IPv6 Packet

Traffic class Flow Payload Next HOP Source Dest.
206582
Version
(1 byte) label length header limit address address
IP precedence or DSCP
Note Layer 3 IPv6 packets are treated as non-IP packets and are bridged by the switch.
All switches and routers that access the Internet rely on the class information to provide the same
forwarding treatment to packets with the same class information and different treatment to packets with
different class information. The class information in the packet can be assigned by end hosts or by
switches or routers along the way, based on a configured policy, detailed examination of the packet, or
both. Detailed examination of the packet is expected to happen closer to the edge of the network so that
the core switches and routers are not overloaded with this task.

OL-9644-10 34-3
Basic QoS Model
Switches and routers along the path can use the class information to limit the amount of resources
allocated per traffic class. The behavior of an individual device when handling traffic in the DiffServ
architecture is called per-hop behavior. If all devices along a path provide a consistent per-hop behavior,
you can construct an end-to-end QoS solution.
Implementing QoS in your network can be a simple or complex task and depends on the QoS features
offered by your internetworking devices, the traffic types and patterns in your network, and the degree
of control that you need over inbound and outbound traffic.
Basic QoS Model

Figure 34-2 shows the basic QoS model for traffic on all ports, including ES ports.

34-4 OL-9644-10
Basic QoS Model
Figure 34-2 Basic QoS Model
Hierarchical actions at ingress on an ES port
Traffic received In profile or

on an ES port out of profile Queueing and
Classification Policing Mark
scheduling
Inspect packet, Compare received Based on whether Based on the

and process the traffic rate with the the packet is in or hierarchical QoS
match configured policer out of profile and configuration,
commands. The and determine if the configured create queues for
hierarchical the packet is in parameters, classes, VLANs,
configuration profile or out of determine whether and physical
determines the profile. to pass through, interfaces. Place
number of queues mark down, or the packet into the
to create. drop the packet. queue and service
it according to the
configuration.
Actions at ingress Actions at egress

Traffic sent
Generate In profile or to a
QoS label out of profile Queueing and Queueing and standard port
Traffic scheduling scheduling
received
on any Inspect packet Compare the Based on whether Based on the QoS Based on the QoS
port and determine incoming traffic the packet is in or label, determine label, determine
the QoS label rate with the out of profile and into which of the into which queue-
based on ACLs configured policer the configured ingress queues to set to place the
or the and determine if parameters, place the packet. packet. Then
configuration. the packet is in determine whether Then service the service the queues
profile or out of to pass through, queues according according to the
profile. mark down, or to the configured configured
drop the packet. weights. weights.
Hierarchical actions at egress on an ES port
In profile or
out of profile Queueing and Traffic sent to an ES port
scheduling
Inspect packet, Compare received Based on whether Based on the

and process the traffic rate with the the packet is in or hierarchical QoS
match configured policer out of profile and configuration,
commands. The and determine if the configured create queues for
hierarchical the packet is in parameters, classes, VLANs,
configuration profile or out of determine whether and physical
determines the profile. to pass through, interfaces. Place
number of queues mark down, or the packet into the
to create. drop the packet. queue and service
122038
it according to the
configuration.
To implement QoS, the switch must distinguish (classify) packets or flows from one another, assign a
label to indicate the given quality of service as the packets move through the switch, make the packets
comply with the configured resource usage limits (police and mark), and provide different treatment
(queue and schedule) in all situations where resource contention exists. The switch also needs to ensure
that the traffic it sends meets a specific traffic profile (shape).

OL-9644-10 34-5
Basic QoS Model
These are the standard actions when traffic is received on any port:
• Classification is the process of generating a distinct path for a packet by associating it with a QoS
label. The switch maps the CoS or DSCP in the packet to a QoS label to distinguish one kind of
traffic from another. The QoS label that is generated identifies all future QoS actions to be
performed on this packet. For more information, see the “Ingress Classification” section on
page 34-9.
• Policing decides whether a packet is in or out of profile by comparing the rate of the inbound traffic
to the configured policer. The policer limits the bandwidth consumed by a flow of traffic. The result
is passed to the marker. For more information, see the “Ingress Policing and Marking” section on
page 34-13.
• Marking evaluates the policer configuration information for the action to take when a packet is out
of profile. Marking actions are to pass through a packet without modification, to mark down the QoS
label in the packet, or to drop the packet. For more information, see the “Ingress Policing and
Marking” section on page 34-13.
• Queueing evaluates the QoS label and the corresponding DSCP or CoS value to select into which of
the two ingress queues to place a packet. Queueing is enhanced with the WTD algorithm, a
congestion-avoidance mechanism. If the threshold is exceeded, the packet is dropped. For more
information, see the “Queueing and Scheduling Overview” section on page 34-17.
• Scheduling services the queues based on their configured (SRR) weights. One of the ingress queues
is the priority queue, and SRR services it for its configured share before servicing the other queue.
For more information, see the “SRR Shaping and Sharing” section on page 34-19.
These are the standard actions when traffic is received on or sent to a standard port:
• Queueing evaluates the QoS label and the corresponding DSCP or CoS value to select into which
queue-set (a set of four queues per port) to place a packet. Because congestion can occur when
multiple ingress ports simultaneously send data to an egress port, WTD is used to differentiate traffic
classes and to subject the packets to different thresholds based on the QoS label. If the threshold is
exceeded, the packet is dropped. For more information, see the “Queueing and Scheduling
Overview” section on page 34-17.
• Scheduling services the four egress queues based on their configured SRR shared or shaped weights.
One of the queues (queue 1) can be the priority queue. Before servicing the other queues, SRR
services the priority queue until it is empty.
These are the additional actions when traffic is received on or sent to an ES port:
• Classification is the process of generating a distinct path for a packet by matching the CoS, DSCP,
IP precedence, by matching the MPLS EXP bits in the header, or by matching a packet based on the
inner and the outer VLAN IDs or CoS values. The hierarchical configuration controls the number
of class-level, VLAN-level, and physical-interface-level queues to create. For information, see the
“Understanding Hierarchical QoS” section on page 34-30 and the “Hierarchical Levels” section on
page 34-30. For classification information, see the “Hierarchical Classification Based on Traffic
Classes and Traffic Policies” section on page 34-33.
• Policing decides whether a packet is in or out of profile by comparing the rate of the inbound or the
outbound traffic to the configured policer. The policer limits the bandwidth consumed by a flow of
traffic. The result is passed to the marker. For more information, see the “Hierarchical Policies and
Marking” section on page 34-34.
• Marking evaluates the policer and configuration information for the action to be taken when a packet
is out of profile and resolves what to do with the packet (pass it through without modification, mark
down the QoS label, or drop). For more information, see the “Hierarchical Policies and Marking”
section on page 34-34.

34-6 OL-9644-10
Basic QoS Model
• Queueing is accomplished through a hierarchical queueing framework, in which the switch assigns
each packet to a queue based on the packet class, VLAN, and physical interface. Tail drop or WRED
can be configured per queue as the congestion-avoidance mechanism. With tail drop, packets are
queued until the maximum threshold is exceeded, and then all the packets are dropped. WRED
reduces the chances of tail drop by selectively dropping packets when the port begins to show signs
of congestion. For more information, see the “Queueing and Scheduling of Hierarchical Queues”
• Scheduling is accomplished through Class-based weighted fair queueing (CBWFQ) or LLQ. CBWFQ
provides guaranteed bandwidth to a particular traffic class while still fairly serving all other traffic
in the network. LLQ is another scheduling mechanism, which ensures that delay-sensitive traffic is
queued and sent before the traffic in other queues. Scheduling services the queues through
average-rate shaping. For more information, see the “Queueing and Scheduling of Hierarchical
Queues” section on page 34-37.
Supported Policy Maps

Different types of policy-map formats are supported on different interface types. These types of
policy-map formats are supported:
• Single-level (nonhierarchical) policy-map: You can define actions only at the class level of the
policy-map.
• Up to two-level hierarchical policy-map: You can define actions in one or two levels in this order:
physical level, VLAN level, and class level. These policies are supported only on SVIs and act
against all traffic received on an SVI.
• Up to three-level hierarchical policy-map: You can define actions in up to three levels with the levels
defined in this order: physical level, VLAN level, and class level. These policies are supported only
on ES ports and ES EtherChannels.
Note Note: A two-level policy on an SVI is different than a hierarchical policy with two levels on ES ports.
Table 34-1 shows the types of policy maps supported on different interfaces.
Table 34-1 Policy Maps Supported on Different Interface Types
Dual Level Hierarchical

Single Level (Class/Physical) (Up to 3 levels)
Interface type Input Output Input Output Input Output
1
Standard port Yes No No No No No
Enhanced services port Yes Yes No No Yes Yes
Enhanced services No Yes No No Yes Yes
EtherChannel
SVI Yes No Yes No No No
1. Yes = supported. No = not supported.
If you add an action to an unsupported policy-map format or interface, you cannot attach the service
policy to the interface.
Note that different software releases also have different levels of support for policy maps:

OL-9644-10 34-7
Basic QoS Model
Software releases earlier than Cisco IOS Release 12.2(25)EY support:

• Nonhierarchical single-level input policy maps on standard and ES physical ports.
• Nonhierarchical single-level output policy maps on ES physical ports.
• Hierarchical (up to three-level) output policy maps on ES physical ports.
Cisco IOS Release 12.2(25)EY or later also supports:
• Hierarchical (up to three-level) input policy maps on ES physical ports
• Up to two-level hierarchical input policy maps on SVI.s
Cisco IOS Release 12.2(35)SE or later also supports:
• Nonhierarchical single-level output policy-maps on EtherChannels consisting of ES ports.
• Hierarchical (up to three-level) input and output policy maps on EtherChannels made of ES ports.
You can configure common hierarchical policies on ES ports and also ensure EtherChannel redundancy
and load balancing.
Cisco IOS Release 12.2(58)SE or later also supports:
• IPv6-related features with ES-port specific features, such as hierarchical QoS.
Supported Policing Configurations

Different interface types and policy formats support different types of policing configurations.
The switch supports various forms of input policing, based on whether the input policy maps are attached
to standard ports, SVIs, ES ports, or EtherChannels made of ES ports (Cisco IOS Release 12.2(35)SE or
later):
• Nonhierarchical single-level input policy maps on standard and ES ports support only one-rate,
two-color individual and aggregate policers, but not two-rate, three-color policers. If you need to
use one of the hierarchical options without an actual hierarchy, you can create a false hierarchy
(using only class-default). For more details about nonhierarchical policing, see the “Nonhierarchical
Single-Level Policing” section on page 34-13.
• Hierarchical input policy maps attached to SVIs can have actions in up to two levels and support
only one-rate, two-color individual policers. They do not support two-rate, three-color policers or
aggregate policers. You configure the policer only at the physical level of the hierarchy. For more
information about this policing configuration, see the “Hierarchical Dual-Level Policing on SVIs”
• Hierarchical input policy maps attached to ES ports (or, beginning with Cisco IOS Release
12.2(35)SE, EtherChannels consisting of ES ports) can have actions defined in up to three levels and
support one-rate, two-color and two-rate, three-color individual policers with configurable actions
for all colors. You can configure the policer at any one level of the hierarchy. These policy maps do
not support aggregate policers. For more information on hierarchical policy maps, see the
“Hierarchical Policies and Marking” section on page 34-34. For a list of differences between
hierarchical policy maps on ES ports and EtherChannels, see the “Hierarchical QoS on
EtherChannels” section on page 34-40.
Output policing is supported only on ES ports or EtherChannels made of ES ports (Cisco IOS Release
12.2(35)SE or later). Policing is supported in nonhierarchical and up to three-level hierarchical output
policy maps. Policing in up to three-level hierarchical policies is described in the “Hierarchical Policies
and Marking” section on page 34-34.

34-8 OL-9644-10
Understanding Standard QoS

Standard QoS involves standard ingress policies to classify, police, and mark traffic received on any port.
Ingress queues prevent congestion by storing packets before forwarding them into the switch fabric.
Egress queue-sets prevent congestion when multiple ingress ports simultaneously send packets to a port.
You configure the ingress queues and the egress queue-sets for queueing and scheduling activities.
This section includes these topics:
• Ingress Classification, page 34-9
• Ingress Policing and Marking, page 34-13
• Mapping Tables, page 34-17
• Queueing and Scheduling Overview, page 34-17
Ingress Classification
Ingress classification distinguishes one kind of traffic from another by examining the fields in the packet
upon receipt. Classification is enabled only if QoS is globally enabled on the switch. By default, QoS is
globally disabled, so no classification occurs.
During ingress classification, the switch performs a lookup and assigns a QoS label to the packet. The
QoS label identifies all QoS actions to be performed on the packet and from which queue the packet is
sent.
The QoS label is based on the DSCP or the CoS value in the packet and determines the queueing and
scheduling actions to perform on the packet. The label is mapped according to the trust setting and the
packet type as shown in Figure 34-3 on page 34-11.
You specify which fields in the frame or the packet that you want to use to classify inbound traffic. For
non-IP traffic, you have these ingress classification options, as shown in Figure 34-3:
• Trust the CoS value in the inbound frame (configure the port to trust CoS). Then use the configurable
CoS-to-DSCP map to generate a DSCP value for the packet. Layer 2 ISL frame headers carry the
CoS value in the three least-significant bits of the 1-byte User field. Layer 2 IEEE 802.1Q frame
headers carry the CoS value in the three most-significant bits of the Tag Control Information field.
CoS values range from 0 for low priority to 7 for high priority.
• Trust the DSCP or trust IP precedence value in the inbound frame. These configurations are
meaningless for non-IP traffic. If you configure a port with either of these options and non-IP traffic
is received, the switch assigns a CoS value and generates an internal DSCP value from the
CoS-to-DSCP map. The switch uses the internal DSCP value to generate a CoS value representing
the priority of the traffic.
• Perform the classification based on a configured Layer 2 MAC ACL, which can examine the MAC
source address, the MAC destination address, and other fields. If no ACL is configured, the packet
is assigned 0 for the DSCP and CoS values, which means best-effort traffic. Otherwise, the
policy-map action specifies a DSCP or a CoS value to assign to the inbound frame.

OL-9644-10 34-9
For IP traffic, you have these ingress classification options, as shown in Figure 34-3:
• Trust the DSCP value in the inbound packet (configure the port to trust DSCP), and assign the same
DSCP value to the packet. The IETF defines the six most-significant bits of the 1-byte ToS field as
the DSCP. The priority represented by a particular DSCP value is configurable. DSCP values range
from 0 to 63.
For ports that are on the boundary between two QoS administrative domains, you can modify the
DSCP to another value through the configurable DSCP-to-DSCP-mutation map.
• Trust the IP precedence value in the inbound packet (configure the port to trust IP precedence), and
generate a DSCP value for the packet through the configurable IP-precedence-to-DSCP map. The
IP Version 4 specification defines the three most-significant bits of the 1-byte ToS field as the IP
precedence. IP precedence values range from 0 for low priority to 7 for high priority.
• Trust the CoS value (if present) in the inbound packet, and generate a DSCP value for the packet through
the CoS-to-DSCP map. If the CoS value is not present, use the port CoS value.
• Perform the classification based on a configured IP standard or an extended ACL, which examines
various fields in the IP header. If no ACL is configured, the packet is assigned 0 as the DSCP and
CoS values, which means best-effort traffic. Otherwise, the policy-map action specifies a DSCP or
a CoS value to assign to the inbound frame.
For information on the maps described in this section, see the “Mapping Tables” section on page 34-17.
For configuration information on port trust states, see the “Configuring Ingress Classification by Using
Port Trust States” section on page 34-56.
You can configure classification through ACLs, traffic classes, and traffic policies. For more
information, see the “Ingress Classification Based on QoS ACLs” section on page 34-11 and the “Ingress
Classification Based on Traffic Classes and Traffic Policies” section on page 34-12.
After ingress classification, the packet is sent to the policing, marking, and the ingress queueing and
scheduling stages.

34-10 OL-9644-10
Figure 34-3 Ingress Classification Flowchart
Start
Trust CoS (IP and non-IP traffic).

Read ingress interface
configuration for classification. Trust DSCP (IP traffic).
IP and
non-IP Trust DSCP or Trust IP
traffic IP precedence precedence
(non-IP traffic). (IP traffic).
Assign DSCP identical
Check if packet came to DSCP in packet.
with CoS label (tag).
Yes No (Optional) Modify the

DSCP by using the
DSCP-to-DSCP-mutation
Use CoS Assign default
map. Use the DSCP
from frame. port CoS.
value to generate
the QoS label.
Generate the DSCP based on

Generate DSCP from
IP precedence in packet. Use
CoS-to-DSCP map.
the IP-precedence-to-DSCP
Use the DSCP value to
map. Use the DSCP value to
generate the QoS label.
generate the QoS label.
Done Done
No Check if packet came

Are there any (more) QoS ACLs with CoS label (tag).
configured for this interface?
Yes No
Yes
Use the CoS value to Assign the default port
Read next ACL. Is there No generate the QoS label. CoS and generate a
a match with a "permit" action? DSCP from the
CoS-to-DSCP map.
Yes
Assign the DSCP or CoS as specified Assign the default Generate the DSCP by using
by ACL action to generate the QoS label. DSCP (0). the CoS-to-DSCP map.
86834
Done Done
Ingress Classification Based on QoS ACLs

You can use IP standard, IP extended, or Layer 2 MAC ACLs to define a group of packets with the same
characteristics (class). In the QoS context, the permit and deny actions in the access control entries
(ACEs) have different meanings than with security ACLs:
• If a match with a permit action is encountered (first-match principle), the specified QoS-related
action is taken.

OL-9644-10 34-11
• If a match with a deny action is encountered, the ACL being processed is omitted, and the next ACL
is processed.
• If no match with a permit action is encountered and all the ACEs have been examined, no QoS
processing occurs on the packet, and the switch offers best-effort service to the packet.
• If multiple ACLs are configured on a port, the lookup stops after the packet matches the first ACL
with a permit action, and QoS processing begins.
Note When you create an access list, remember that the end of the access list contains an implicit deny
statement for everything if it did not find a match before reaching the end.
After a traffic class is defined with the ACL, you can attach a policy to it. A policy might contain multiple
classes with actions specified for each one of them. A policy might include commands to classify the
class as a particular aggregate (for example, assign a DSCP) or to rate-limit the class. This ingress policy
is then attached to a port.
You implement IP ACLs to classify IP traffic by using the access-list global configuration command;
you implement Layer 2 MAC ACLs to classify non-IP traffic by using the mac access-list extended
global configuration command. For configuration information, see the “Configuring an Ingress QoS
Policy” section on page 34-63.
Ingress Classification Based on Traffic Classes and Traffic Policies

You define a traffic class to classify traffic, use a traffic policy to decide how to treat the classified traffic,
and attach the ingress policy to a port to create a service policy.
You use the class map to define a specific traffic flow (or class) and to isolate it from all other traffic.
The class map defines the criteria used to match against a specific traffic flow to further classify it. The
criteria can include matching the access group defined by the ACL or matching a specific list of DSCP
or IP precedence values. If you have more than one type of traffic that you want to classify, you can
create another class map and use a different name.
You create a class map by using the class-map global configuration command. When you enter the
class-map command, the switch enters the class-map configuration mode. In this mode, you define the
match criterion for the traffic by using the match class-map configuration command. Inbound packets
are compared to the match criteria configured for a class map to determine if the packet belongs to that
class. If a packet matches the specified criteria, the packet is considered a member of the class and is
forwarded according to the QoS specifications set in the traffic policy. If a packet fails to meet any of
the matching criteria, it is classified as a member of the traffic class if one is configured.
You use the policy map to create the traffic policy, to specify the traffic class to act on, and to configure
the QoS features associated with the traffic class. Actions on ingress can include trusting the received
CoS, DSCP, or IP precedence values in the traffic class; setting a specific DSCP or IP precedence value
in the traffic class; or specifying the traffic bandwidth limitations and the action to take when the traffic
is out of profile.
You create and name a policy map by using the policy-map global configuration command. When you
enter this command, the switch enters the policy-map configuration mode. In this mode, you use the
class policy-map configuration command to name the traffic class associated with the traffic policy. If
you specify class as the class name in the class policy-map configuration command, packets that fail to
meet any of the matching criteria are classified as members of the traffic class. You can manipulate this
class (for example, police it and mark it) just like any traffic class, but you cannot delete it. After you
name the traffic class with the class command, the switch enters policy-map class configuration mode,
and you can specify the actions to take on this traffic class.

34-12 OL-9644-10
An ingress policy map can include police, police aggregate, trust, or set policy-map class configuration
commands. You attach the ingress policy map to a port by using the service-policy input interface
configuration command.
In software releases earlier than Cisco IOS Release 12.2(25)EY, you can apply a nonhierarchical
single-level policy map only to a physical port—in both directions of an ES port and in the input
direction of a standard port. Hierarchical (up to three-level) policy maps were supported only as output
policy maps on ES ports. Cisco IOS Release 12.2(25)EY or later also supports up to two-level policy
maps in the input direction of an SVI and up to three-level policy maps as input policy maps on ES ports.
However, a hierarchical dual-level policy map can only be applied to an SVI. The dual-level policy map
contains two levels. The first level, the VLAN level, specifies the actions to be taken against a traffic
flow on the SVI. The second level, the interface level, specifies the actions to be taken against the traffic
on the physical ports that belong to the SVI. The interface-level actions are specified in the
interface-level policy map. You can also use Cisco IOS Release 12.2(35)SE to apply single-level output
policy maps and hierarchical input and output maps to EtherChannels consisting of ES ports.
For more information, see the “Ingress Policing and Marking” section on page 34-13. For configuration
information, see the “Configuring an Ingress QoS Policy” section on page 34-63.
Ingress Policing and Marking

After a packet is classified and has a DSCP-based or CoS-based QoS label assigned to it, the traffic
policing and marking process can begin. Figure 34-4 on page 34-15 shows an ingress, single-rate traffic
policer. Figure 34-5 on page 34-16 shows the ingress policing and marking process.
Ingress traffic policing controls the maximum rate of traffic received on a port. The policer defines the
bandwidth limitations of the traffic and the action to take if the limits are exceeded. It is often configured
on ports at the edge of a network to limit traffic into or out of the network. In most policing
configurations, traffic that falls within the rate parameters is sent. Traffic that exceeds the parameters is
considered to be out of profile or nonconforming and is dropped or sent with a different priority.
Note All traffic, regardless of whether it is bridged or routed, is subjected to a configured policer. As a result,
bridged packets might be dropped or might have their DSCP or CoS fields modified when they are
policed and marked.
Note Input hierarchical service policies are applied to a traffic stream before any other services act on that
traffic. For example, an input hierarchical service policy applied to traffic could change the traffic rate
from above a storm-control threshold to below the threshold, preventing storm control from acting on
the traffic stream.
Nonhierarchical Single-Level Policing

In nonhierarchical single-level policy maps on physical ports, you can create these types of ingress
policers:
• Individual (single rate)
QoS applies the bandwidth limits specified in the policer separately to each matched traffic class.
You can configure a single-rate policer within a policy map by using the police policy-map class

OL-9644-10 34-13
• Aggregate
QoS applies the bandwidth limits specified in an aggregate policer cumulatively to all matched
traffic flows. You configure this type of policer by specifying the aggregate policer name within a
policy map by using the police aggregate policy-map class configuration command. You specify the
bandwidth limits of the policer by using the mls qos aggregate-policer global configuration
command. In this way, the aggregate policer is shared by multiple classes of traffic within a policy
map.
Note You can only configure only individual policers on SVIs and only with Cisco IOS Release
12.2(25)EY or later.
A single-rate traffic policer decides on a packet-by-packet basis whether the packet is in or out of profile
and specifies the actions on the packet. These actions, carried out by the marker, include passing through
the packet without modification, dropping the packet, or modifying (marking down) the assigned DSCP
of the packet and allowing the packet to pass through. The configurable policed-DSCP map provides the
packet with a new DSCP-based QoS label. For information on the policed-DSCP map, see the “Mapping
Tables” section on page 34-17. Marked-down packets use the same queues as the original QoS label to
prevent packets in a flow from getting out of order.
Single-level policing uses a token-bucket algorithm. As each frame is received by the switch, a token is
added to the bucket. The bucket has a hole in it and leaks at a rate that you specify as the average traffic
rate in bps. Each time a token is added to the bucket, the switch verifies that there is enough room in the
bucket. If there is not enough room, the packet is marked as nonconforming, and the specified policer
action is taken (dropped or marked down).
How quickly the bucket fills is a function of the bucket depth (burst-byte), the rate at which the tokens
are removed (rate-bps), and the duration of the burst above the average rate. The size of the bucket
imposes an upper limit on the burst length and limits the number of frames that can be sent back-to-back.
If the burst is short, the bucket does not overflow, and no action is taken against the traffic flow. However,
if a burst is long and at a higher rate, the bucket overflows, and the policing actions are taken against the
frames in that burst.
You configure the bucket depth (the maximum burst that is tolerated before the bucket overflows) by
using the burst-byte option of the police policy-map class configuration command or the mls qos
aggregate-policer global configuration command. You configure how fast (the average rate) that the
tokens are removed from the bucket by using the rate-bps option of the police policy-map class
configuration command or the mls qos aggregate-policer global configuration command.
After you configure the policy map and policing actions, attach the ingress policy to a port by using the
service-policy input interface configuration command. For configuration information, see the
“Classifying, Policing, and Marking Ingress Traffic by Using Nonhierarchical Single-Level Policy
Maps” section on page 34-69 and the “Classifying, Policing, and Marking Ingress Traffic by Using
Aggregate Policers” section on page 34-79.
Figure 34-4 shows the policing and marking process when these types of policy maps are configured:
• A nonhierarchical single-level policy map.
• The interface level of a hierarchical dual-level policy map attached to an SVI. The physical ports are
specified in this secondary policy map.

34-14 OL-9644-10
Figure 34-4 Ingress, Nonhierarchical Single-Level Policing and Marking Flowchart
Start
Get the clasification

result for the packet.
Is a policer configured No
for this packet?
Yes
Check if the packet is in No

profile by querying the policer.
Yes
Pass
through Check out-of-profile action Drop
Drop packet.
configured for this policer.
Mark
Modify DSCP according to the

policed-DSCP map. Generate
a new QoS label.
86835
Done
Hierarchical Dual-Level Policing on SVIs

Before configuring a hierarchical dual-level policy map with individual policers on an SVI, you must
enable VLAN-based QoS on the physical ports that belong to the SVI. Though a policy map is attached
to the SVI, the individual policers only affect traffic on the physical ports specified in the secondary
interface level of the dual-level policy map.
A dual-level policy map has two levels. The first level, the VLAN level, specifies the actions to be taken
against a traffic flow on an SVI. The second level, the interface level, specifies the actions to be taken
against the traffic on the physical ports that belong to the SVI and are specified in the interface-level
policy map.
When configuring policing on an SVI, you can create and configure a hierarchical policy map with these
two levels:
• VLAN level—Create this primary level by configuring class maps and classes that specify the port
trust state or set a new DSCP or IP precedence value in the packet. The VLAN-level policy map
applies only to the VLAN in an SVI and does not support policers.
Note The VLAN level in a dual-level policy map is different than the VLAN level in a hierarchical
policy map that is applied on an ES port.

OL-9644-10 34-15
• Interface level—Create this secondary level by configuring class maps and classes that specify the
individual policers on physical ports the belong to the SVI. The interface-level policy map only
supports individual policers and does not support aggregate policers.
Note You cannot include ES ports in interface level class-map configuration for a policy attached to an SVI.
If you try to attach this type of service policy to an SVI, the command is rejected with an error message.
To configure enhanced per-port, per-VLAN policing for an ES port, you can attach a hierarchical policy
map to the port.
See the “Classifying, Policing, and Marking Traffic by Using Hierarchical Dual-Level Policy Maps”
section on page 34-73 for an example of a dual-level policy map.
Figure 34-5 shows the policing and marking process when hierarchical dual-level policy maps are
attached to an SVI.
Figure 34-5 Ingress Hierarchical Dual-Level Policing and Marking Flowchart on SVIs
Start
Get the VLAN and

interface-level classification
results for the packet.
Is an interface-level policer No
configured for this packet?
Yes
Verify if the packet is in the No

profile by querying the policer.
Yes
Pass
through Verify the out-of-profile action Drop
Drop packet.
configured for this policer.
Mark
Modify DSCP according to the

policed-DSCP map. Generate
a new QoS label.
92355
Done

34-16 OL-9644-10
Mapping Tables
During QoS ingress processing, the switch represents the priority of all traffic (including non-IP traffic)
with a QoS label based on the DSCP or CoS value from the classification stage:
• During ingress classification, QoS uses configurable mapping tables to derive a corresponding
DSCP or CoS value from a received CoS, DSCP, or IP precedence value. These maps include the
CoS-to-DSCP map and the IP-precedence-to-DSCP map. You configure these maps by using the mls
qos map cos-dscp and the mls qos map ip-prec-dscp global configuration commands.
On an ingress port configured in the DSCP-trusted state, if the DSCP values are different between
the QoS domains, you can apply the configurable DSCP-to-DSCP-mutation map to the port that is
on the boundary between the two QoS domains. You configure this map by using the mls qos map
dscp-mutation global configuration command.
• During ingress policing, QoS can assign another DSCP value to an IP or a non-IP packet (if the
packet is out of profile and the policer specifies a marked-down value). This configurable map is
called the policed-DSCP map. You configure this map by using the mls qos map policed-dscp
global configuration command.
• Before the traffic reaches the scheduling stage, QoS stores the packet in an ingress and an egress
queue according to the QoS label. The QoS label is based on the DSCP or the CoS value in the
inbound packet. The QoS label selects an ingress queue and an egress queue from the queue-set
through the DSCP input and output queue threshold maps or through the CoS input and output queue
threshold maps. In addition to an ingress or an egress queue, the QOS label also identifies the WTD
threshold value. You configure these maps by using the mls qos srr-queue {input | output}
dscp-map and the mls qos srr-queue {input | output} cos-map global configuration commands.
• When marking and queueing CPU-generated traffic:
– If you explicitly configure the output queue by entering the mls qos srr-queue output cpu-
queue global configuration command, the CPU traffic is sent to that queue, and the threshold
value applies to that queue.
– If you do not explicitly configure the output queue for CPU-generated traffic, the cpu marking
values and the dscp-map or cos-map values determine the output queue and the threshold for
the CPU-generated traffic.
The CoS-to-DSCP, DSCP-to-CoS, and the IP-precedence-to-DSCP maps have values that might or might
not be appropriate for your network.
The DSCP-to-DSCP-mutation map and the policed-DSCP map are null maps; they map an inbound
DSCP value to the same DSCP value. The DSCP-to-DSCP-mutation map is the only map that you apply
to a specific port. All other maps apply to the entire switch.
For configuration information, see the “Configuring DSCP Maps” section on page 34-80.
For information about the DSCP and CoS input queue threshold maps, see the “Queueing and
Scheduling of Ingress Queues” section on page 34-20. For information about the DSCP and CoS output
queue threshold maps, see the “Queueing and Scheduling of Egress Queue-Sets” section on page 34-22.
Queueing and Scheduling Overview

The switch has queues at specific points to help prevent congestion, as shown in Figure 34-6.
Figure 34-6 shows the ingress and egress queues for traffic on all ports, including ES ports.

OL-9644-10 34-17
Figure 34-6 Ingress and Egress Queue Locations
Traffic received
on an enhanced
services port Classify, Class-level CBWFQ, VLAN-level Physical-
police, queues LLQ, queues CBWFQ interface-
and mark or both level queue
Internal Egress
ring queue-set
Ingress
queues
Traffic sent to
Classify, a standard port
police, SRR SRR
Traffic received and mark
on a standard port
Traffic sent to
an enhanced
Classify, Class-level CBWFQ, VLAN-level Physical- services port
police, queues LLQ, queues CBWFQ interface-
and mark or both level queue
122039
Because the total ingress bandwidth of all ports can exceed the bandwidth of the internal ring, ingress
queues are located after the packet is classified, policed, and marked and before packets are forwarded
into the switch fabric. Because multiple ingress ports can simultaneously send packets to an egress port
and cause congestion, egress queue-sets are located after the internal ring.
Each port belongs to an egress queue-set, which defines all the characteristics of the four queues per port.
The ES ports also use a hierarchical queueing model in which each packet is assigned to a hierarchical
queue based on the physical interface, VLAN, or class. Traffic received from or destined for an ES port
passes through the queue-set. If congestion occurs in the hierarchical queues and backs up to the
queue-sets, the queue-set configuration controls how traffic is dropped.
Ingress queues use WTD for congestion management. The egress queue-sets also use WTD. For more
information, see the next section.
Ingress queues support SRR in shared mode for scheduling. The egress queue-sets also support SRR in
shared or shaped mode for scheduling. For more information, see the “SRR Shaping and Sharing”
For information about ingress queueing and scheduling, see the “Queueing and Scheduling of Ingress
Queues” section on page 34-20. For information about egress queue-set queueing and scheduling, see
the “Queueing and Scheduling of Egress Queue-Sets” section on page 34-22.
The hierarchical queues for ES ports use tail drop or WRED for congestion management. These ports
also use CBWFQ or LLQ for scheduling. For more information, see the “Queueing and Scheduling of
Hierarchical Queues” section on page 34-37.

34-18 OL-9644-10
Weighted Tail Drop

The ingress queues and the egress queue-sets use an enhanced version of the tail-drop
congestion-avoidance mechanism called Weighted Tail Drop (WTD). WTD manages the queue lengths
and provides drop precedences for different traffic classifications.
As a frame is sent to a particular queue, WTD uses the assigned QoS label of the frame to subject it to
different thresholds. If the threshold is exceeded for that QoS label (the space available in the destination
queue is less than the size of the frame), the switch drops the frame.
Each queue has three threshold values. The QOS label is determines which of the three threshold values
is subjected to the frame. Of the three thresholds, two are configurable (explicit) and one is not (implicit).
Figure 34-7 shows an example of WTD operating on a queue whose size is 1000 frames. Three drop
percentages are configured: 40, 60, and 100 percent. These percentages mean that up to 400 frames can
be queued at the 40-percent threshold, up to 600 frames at the 60-percent threshold, and up to 1000
frames at the 100-percent threshold.
In this example, CoS values 6 and 7 have a greater importance than the other CoS values, and they are
assigned to the 100-percent drop threshold (queue-full state). CoS values 4 and 5 are assigned to the
60-percent threshold, and CoS values 0 to 3 are assigned to the 40-percent threshold.
Suppose the queue is already filled with 600 frames, and a new frame arrives. It contains CoS values 4
and 5 and is subjected to the 60-percent threshold. If this frame is added to the queue, the threshold will
be exceeded, so the switch drops it.
Figure 34-7 WTD and Queue Operation
CoS 6-7
100% 1000
CoS 4-5
60% 600
CoS 0-3
40% 400
86692
For more information, see the “Mapping DSCP or CoS Values to an Ingress Queue and Setting WTD
Thresholds” section on page 34-87, the “Allocating Buffer Space to and Setting WTD Thresholds for an
Egress Queue-Set” section on page 34-91, and the “Mapping DSCP or CoS Values to an Egress
Queue-Set and to a Threshold ID” section on page 34-93.
SRR Shaping and Sharing

The ingress queues and egress queue-sets are serviced by SRR, which controls the rate at which packets
are sent. On the ingress queues, SRR sends packets to the internal ring. On the egress queue-sets, SRR
sends packets to a standard port.
You can configure SRR on the egress queue-sets for sharing or for shaping. However, for ingress queues,
sharing is the mode and is the only mode supported.
In shaped mode, the queues are guaranteed a percentage of the bandwidth, and they are rate-limited to
that amount. Shaped traffic does not use more than the allocated bandwidth even if the link is idle.
Shaping provides a more even flow of traffic over time and reduces the peaks and valleys of bursty
traffic. With shaping, the absolute value of each weight is used to compute the bandwidth available for
the queues.

OL-9644-10 34-19
In shared mode, the queues share the bandwidth among them according to the configured weights. The
bandwidth is guaranteed at this level but not limited to it. For example, if a queue is empty and no longer
requires a share of the link, the remaining queues can expand into the unused bandwidth and share it
among them. With sharing, the ratio of the weights controls the frequency of dequeuing; the absolute
values are meaningless. Shaping and sharing is configured per interface. Each interface can be uniquely
configured.
For more information, see the “Allocating Bandwidth Between the Ingress Queues” section on
page 34-89, the “Configuring SRR Shaped Weights on an Egress Queue-Set” section on page 34-95, and
the “Configuring SRR Shared Weights on an Egress Queue-Set” section on page 34-96.
Queueing and Scheduling of Ingress Queues

Figure 34-8 shows the ingress queueing and scheduling flowchart.
Figure 34-8 Ingress Queueing and Scheduling Flowchart
Start
Read QoS label

(DSCP or CoS value).
Determine ingress queue

number, buffer allocation,
and WTD thresholds.
Are thresholds Yes

being exceeded?
No Drop packet.
Queue the packet. Service
the queue according to
the SRR weights.
Send packet to
the internal ring.
90564
Note SRR services the priority queue for its configured share before servicing the other queue.

34-20 OL-9644-10
The switch supports two configurable ingress queues, which are serviced by SRR in shared mode only.
Table 34-2 describes the queues.
Table 34-2 Ingress Queue Types
Queue Type1 Function

Normal User traffic that is considered to be normal priority. You can configure three different thresholds to
differentiate among the flows. You can use the mls qos srr-queue input threshold, the mls qos srr-queue
input dscp-map, and the mls qos srr-queue input cos-map global configuration commands.
Expedite High-priority user traffic such as differentiated services expedited forwarding or voice traffic. You can
configure the bandwidth required for this traffic as a percentage of the total traffic by using the mls qos
srr-queue input priority-queue global configuration command. The expedite queue has guaranteed bandwidth.
1. The switch uses two nonconfigurable queues for traffic that is essential for proper network operation.
You assign each packet that flows through the switch to a queue and to a threshold. Specifically, you map
DSCP or CoS values to an ingress queue and map DSCP or CoS values to a threshold ID. You use the
mls qos srr-queue input dscp-map queue queue-id {dscp1...dscp8 | threshold threshold-id
dscp1...dscp8} or the mls qos srr-queue input cos-map queue queue-id {cos1...cos8 | threshold
threshold-id cos1...cos8} global configuration command. You can display the DSCP input queue
threshold map and the CoS input queue threshold map by using the show mls qos maps privileged EXEC
command. To specify the queue and threshold values for CPU-generated traffic, you use the mls qos
srr-queue output cpu queue id threshold id global configuration command.
WTD Thresholds
The queues use WTD to support distinct drop percentages for different traffic classes. Each queue has
three drop thresholds: two configurable (explicit) WTD thresholds and one nonconfigurable (implicit)
threshold preset to the queue-full state. You assign the two explicit WTD threshold percentages for
threshold ID 1 and ID 2 to the ingress queues by using the mls qos srr-queue input threshold queue-id
threshold-percentage1 threshold-percentage2 global configuration command. Each threshold value is a
percentage of the total number of allocated buffers for the queue. The drop threshold for threshold ID 3
is preset to the queue-full state, and you cannot modify it. For more information about how WTD works,
see the “Weighted Tail Drop” section on page 34-19.
Buffer and Bandwidth Allocation
You define the ratio (allocate the amount of space) with which to divide the ingress buffers between the
two queues by using the mls qos srr-queue input buffers percentage1 percentage2 global configuration
command. The buffer allocation together with the bandwidth allocation control how much data can be
buffered and sent before packets are dropped. You allocate bandwidth as a percentage by using the mls
qos srr-queue input bandwidth weight1 weight2 global configuration command. The ratio of the
weights is the ratio of the frequency in which the SRR scheduler sends packets from each queue to the
internal ring.

OL-9644-10 34-21
Priority Queueing
You can configure one ingress queue as the priority queue by using the mls qos srr-queue input
priority-queue queue-id bandwidth weight global configuration command. The priority queue should
be used for traffic (such as voice) that requires guaranteed delivery because this queue is guaranteed part
of the bandwidth regardless of the load on the internal ring.
SRR services the priority queue for its configured weight as specified by the bandwidth keyword in the
mls qos srr-queue input priority-queue queue-id bandwidth weight global configuration command.
Then, SRR shares the remaining bandwidth with both ingress queues and services them as specified by
the weights configured with the mls qos srr-queue input bandwidth weight1 weight2 global
You can combine the commands described in this section to prioritize traffic by placing packets with
particular DSCP or CoS values into certain queues, by allocating a large queue size or by servicing the
queue more frequently, and by adjusting queue thresholds so that packets with lower priorities are
dropped. For configuration information, see the “Configuring Ingress Queue Characteristics” section on
page 34-86.
Queueing and Scheduling of Egress Queue-Sets

Figure 34-9 shows the egress queue-set queueing and scheduling flowchart.

34-22 OL-9644-10
Figure 34-9 Egress Queue-Set Queueing and Scheduling Flowchart
Start
Receive packet from

the internal ring.
Read QoS label

(DSCP or CoS value).
Determine egress queue

number and threshold
based on the label.
Are thresholds Yes

being exceeded?
No
Drop packet.
Queue the packet. Service
the queue according to
the SRR weights.
Rewrite DSCP,
CoS, or both values,
as appropriate.
Send the packet out the

standard port, to the
input of the hierarchical
egress queueing and
scheduling, or both.
98884
Done
Note If the egress priority queue is enabled on a port, SRR services it until it is empty. Then SRR services the
other queues.
Each port supports four egress queues, one (queue 1) of which can be the egress priority queue. These
queues are assigned to a queue-set. All traffic exiting the switch on a standard port flows through one of
these four queues and is subjected to a threshold based on the QoS label assigned to the packet. Traffic
destined for an ES port passes through the queue-set before reaching the hierarchical queues. If
congestion occurs in the hierarchical queues that backs up to the queue-sets, the queue-set configuration
controls how traffic is dropped.

OL-9644-10 34-23
Figure 34-10 shows the egress queue-set buffer. The buffer space is divided between the common pool
and the reserved pool. The switch uses a buffer allocation scheme to reserve a minimum amount of
buffers for each egress queue, to prevent any queue or port from consuming all the buffers and depriving
other queues, and to control whether to grant buffer space to a requesting queue. The switch detects
whether or not the target queue has consumed more buffers than its reserved amount (under-limit),
whether it has consumed all of its maximum buffers (over limit), and whether the common pool is empty
(no free buffers) or not empty (free buffers). If the queue is not over-limit, the switch can allocate buffer
space from the reserved pool or from the common pool (if it is not empty). If there are no free buffers in
the common pool or if the queue is over-limit, the switch drops the frame.
Figure 34-10 Egress Queue-Set Buffer Allocation
Common pool
Port 1 queue 1
Port 1 queue 2
Port 1 queue 3
Port 1 queue 4
Port 2 queue 1
Port 2 queue 2
Reserved pool
86695
Buffer and Memory Allocation
You guarantee the availability of buffers, set drop thresholds, and configure the maximum memory
allocation for a queue-set by using the mls qos queue-set output qset-id threshold queue-id
drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold global configuration command.
Each threshold value is a percentage of the queue’s allocated memory, which you specify by using the
mls qos queue-set output qset-id buffers allocation1 ... allocation4 global configuration command.
The sum of all the allocated buffers represents the reserved pool, and the remaining buffers are part of
the common pool.
Through buffer allocation, you can ensure that high-priority traffic is buffered. For example, if the buffer
space is 400, you can allocate 70 percent of it to queue 1 and 10 percent to queues 2 through 4. Queue
1 then has 280 buffers allocated to it, and queues 2 through 4 each have 40 buffers allocated to them.
You can guarantee that the allocated buffers are reserved for a specific queue in a queue-set. For
example, if there are 100 buffers for a queue, you can reserve 50 percent (50 buffers). The switch returns
the remaining 50 buffers to the common pool. You also can enable a queue in the full condition to obtain
more buffers than are reserved for it by setting a maximum threshold. The switch can allocate the needed
buffers from the common pool if the common pool is not empty.
WTD Thresholds
You can assign each packet that flows through the switch to a queue and to a threshold. Specifically, you
map DSCP or CoS values to an egress queue-set and map DSCP or CoS values to a threshold ID. You
use the mls qos srr-queue output dscp-map queue queue-id {dscp1...dscp8 | threshold threshold-id
dscp1...dscp8} or the mls qos srr-queue output cos-map queue queue-id {cos1...cos8 | threshold
threshold-id cos1...cos8} global configuration command. You can display the DSCP output queue

34-24 OL-9644-10
QoS Treatment for Performance-Monitoring Protocols
threshold map and the CoS output queue threshold map by using the show mls qos maps privileged
EXEC command. To specify the queue and threshold values for CPU-generated traffic, you use the mls
qos srr-queue output cpu queue id threshold id global configuration command.
The queue-set uses WTD to support distinct drop percentages for different traffic classes. Each queue
has three drop thresholds: two configurable (explicit) WTD thresholds and one nonconfigurable
(implicit) threshold preset to the queue-full state. You assign the two WTD threshold percentages for
threshold ID 1 and ID 2. The drop threshold for threshold ID 3 is preset to the queue-full state, and you
cannot modify it. For more information about how WTD works, see the “Weighted Tail Drop” section
on page 34-19.
Shaped or Shared Mode
SRR services each queue-set in shared or shaped mode.You map a port to a queue-set by using the
queue-set qset-id interface configuration command. You assign shared or shaped weights to a standard
port by using the srr-queue bandwidth share weight1 weight2 weight3 weight4 or the srr-queue
bandwidth shape weight1 weight2 weight3 weight4 interface configuration command. You can assign
only shared weights to an ES port. For an explanation of the differences between shaping and sharing,
see the “SRR Shaping and Sharing” section on page 34-19.
The buffer allocation together with the SRR weight ratios control how much data can be buffered and
sent before packets are dropped. The weight ratio is the ratio of the frequency in which the SRR
scheduler sends packets from each queue.
All four queues participate in the SRR unless the egress priority queue is enabled, in which case the first
bandwidth weight is ignored and is not used in the ratio calculation. Before servicing the other queues,
SRR services the priority queue until it is empty. You enable the priority queue by using the
priority-queue out interface configuration command.
You can combine the commands described in this section to prioritize traffic by placing packets with
particular DSCP or CoS values into certain queues, by allocating a large queue size or by servicing the
queue more frequently, and by adjusting queue thresholds so that packets with lower priorities are
dropped. For configuration information, see the “Configuring Egress Queue-Set Characteristics” section
on page 34-91.
Note The egress queue-set settings are suitable for most situations. You should change them only when you
have a thorough understanding of the queues and only if these settings do not meet your QoS solution.

• Cisco IP-SLAs, page 34-26
• Two-Way Active Measurement Protocol, page 34-26
• QoS Treatment for IP-SLA and TWAMP Probes, page 34-26
• QoS Marking for CPU-Generated Traffic, page 34-27
• QoS Queuing for CPU-Generated Traffic, page 34-28
• Configuration Guidelines, page 34-29

OL-9644-10 34-25
Cisco IP-SLAs
For information about Cisco IP service level agreements (IP SLAs), see the “Understanding Cisco IOS
IP SLAs” section on page 41-1.
Two-Way Active Measurement Protocol

For information about the Two-Way Active Measurement Protocol (TWAMP), see:
• “Understanding TWAMP” section on page 41-14
• “Configuring TWAMP” section on page 41-15
QoS Treatment for IP-SLA and TWAMP Probes

The QoS treatment for IP-SLA and TWAMP probes must exactly reflect the effects that occur to the
normal data traffic crossing the device.
The generating device should not change the probe markings. It should queue these probes based on the
configured queueing policies for normal traffic.
Marking
By default, the class of service (CoS) marking of CFM traffic (including IP SLAs using CFM probes) is
not changed. This feature cannot change this behavior.
By default, the class of service (CoS) marking of all other Layer 2 non-IP traffic is not changed. The
QoS marking feature can change this behavior.
By default, IP traffic marking (including IP SLA and TWAMP probes) is not changed. The QoS marking
feature can change this behavior.
Queuing
The CFM traffic (including IP SLAs using CFM probes) is queued according to its CoS value and the
output policy map configured on the egress port, similar to normal traffic. This feature cannot change
this behavior.
By default, all other Layer 2 non-IP traffic is statically mapped to a queue on the egress port. However,
this feature can change the queuing behavior. This traffic can be queued according to the CoS markings
specified in the cpu traffic qos global configuration command and the global CoS-to-queue mapping.
By default, all IP traffic (including IP SLA and TWAMP probes) is statically mapped to a queue on the
egress port. However, this feature can change the queuing behavior. All IP traffic can be queued
according to the CoS or DSCP or precedence markings specified in the cpu traffic qos global
configuration command and the corresponding global CoS- or DSCP- or precedence-to-queue mapping.
Note This feature enhances the MLS QoS marking and queuing capability for CPU traffic. It does not affect
the marking and queuing capability availability through output MQC QoS policy-maps configured on
enhanced services (ES) ports.

34-26 OL-9644-10
QoS Marking for CPU-Generated Traffic

Beginning with Cisco IOS Release 12.2(52)SE, you can use QoS marking to set or modify the attributes
of traffic from the CPU. The QoS marking action can cause the CoS, IP DSCP, or IP precedence bits in
the packet to be rewritten or left unchanged. QoS uses packet markings to identify certain traffic types
and how QoS treats them on the local switch and the network.
Note To configure QoS marking, you must first enable multilayer switch (MLS) QoS by using the mls qos
When MLS QoS is disabled, the default behavior applies for all CPU traffic; QoS marking commands
are accepted by the switch and become effective when MLS QoS is enabled.
You can specify and mark traffic CPU-generated traffic by using these global configuration commands:
• cpu traffic qos cos {cos_value | trust}
• cpu traffic qos dscp {dscp_value | trust | dscp-mutation mutation-map-name}
• cpu traffic qos precedence {precedence_value | trust | precedence-mutation
mutation-map-name}
For non-IP, non-CFM CPU traffic, you have these marking options:
• Use the cpu traffic qos cos global configuration command with the cos_value argument to configure
a CoS value.
• Use the cpu traffic qos cos global configuration command with the trust keyword to trust the CoS
value in the inbound frame and use the configurable CoS-to-DSCP map to generate a DSCP value
for the packet.
Note Configuring a DSCP or precedence value or trusting the DSCP or precedence value in the inbound frame
has no impact on non-IP traffic.
For IP CPU traffic, you have these marking options:

a CoS value.
value in the inbound frame and use the configurable CoS-to-DSCP map to generate a DSCP value
for the packet.
• Use the cpu traffic qos dscp global configuration command with the dscp_value argument to
configure the DSCP value.
• Use the cpu traffic qos dscp global configuration command with the trust keyword to trust the
DSCP value in the inbound frame and use the configurable DSCP-to-CoS map to generate a CoS
value for the packet.
• Use the cpu traffic qos dscp global configuration command with the dscp-mutation keyword and
mutation-map-name argument to change the DSCP value of the inbound frame and use the
configurable DSCP-to-CoS map to generate a CoS value for the packet.
• Use the cpu traffic qos precedence global configuration command with the precedence_value
argument to configure the precedence value.

OL-9644-10 34-27
• Use the cpu traffic qos precedence global configuration command with the trust keyword to trust
the precedence value in the inbound frame, use the configurable IP-precedence-to-DSCP map to
generate a DSCP value, and use the configurable DSCP-to-CoS map to generate a CoS value for the
packet.
• Use the cpu traffic qos precedence global configuration command with the precedence-mutation
keyword and the mutation-map-name argument to change the precedence value of the inbound
frame. Use the IP-precedence-to-DSCP map to generate a DSCP value from the precedence value,
and then use the configured DSCP mutation-map to generate the changed DSCP value. Use the
configurable DSCP-to-CoS map to generate a CoS value for the packet.
QoS Queuing for CPU-Generated Traffic

Both the QoS markings configured for the CPU-generated traffic by the cpu traffic qos global
configuration command and the global QoS marking-to-queue mapping identify the queue on the egress
port.
By default, CPU traffic is assigned to queue-2, threshold-1.
For CFM CPU traffic you have this queuing option:
value in the inbound frame, and use the configurable CoS-to-queue or CoS-to-threshold map to
select the queue or threshold for the packet.
For all non-CFM CPU traffic, you have this queuing option:
• Use the mls qos srr-queue output cpu-queue global configuration command to specify an egress
queue and a threshold value.
For non-IP, non-CFM CPU traffic, you have these queuing options:
a CoS value. Then use the configurable CoS-to-queue or CoS-to-threshold map to select the queue
or threshold for the packet.
value in the inbound frame, and use the configurable CoS-to- queue or CoS-to-threshold map to
Note The DSCP-to-queue map has no impact on non-IP traffic.
For IP CPU traffic, you have these queuing options:

a CoS value. Then use the configurable CoS-to-queue or CoS-to-threshold map to select the queue
or threshold for the packet.
value in the inbound frame, then use the configurable CoS-to-queue or CoS-to-threshold map to
• Use the cpu traffic qos dscp global configuration command with the dscp_value argument to
configure the DSCP value. Then use the configurable DSCP-to-queue or DSCP-to-threshold map to

34-28 OL-9644-10
• Use the cpu traffic qos dscp global configuration command with the trust keyword to trust the
DSCP value in the inbound frame. Then use the configurable DSCP-to-queue or DSCP-to-threshold
map to select the queue or threshold for the packet.
• Use the cpu traffic qos dscp global configuration command with the dscp-mutation keyword and
mutation-map-name argument to change the DSCP value of the inbound frame. Then use the
configurable DSCP-to-queue or DSCP-to-threshold map to select the queue or threshold for the
packet.
• Use the cpu traffic qos precedence global configuration command with the precedence_value
argument to configure the precedence value. Then use the configurable DSCP-to-queue or
DSCP-to-threshold map to select the queue or threshold for the packet.
• Use the cpu traffic qos precedence global configuration command with the trust keyword to trust
the precedence value in the inbound frame. Then use the configurable IP-precedence-to-DSCP map
to generate a DSCP value. Use the configurable DSCP-to-queue or DSCP-to-threshold map to select
the queue or threshold for the packet.
• Use the cpu traffic qos precedence global configuration command with the precedence-mutation
keyword and the mutation-map-name argument to change the precedence value of the inbound
frame. Use the IP-precedence-to-DSCP map to generate a DSCP value from the precedence value.
Then use the configured DSCP mutation-map to generate the changed DSCP value. Then use the
configurable DSCP-to-queue or DSCP-to-threshold map to select the queue or threshold for the
packet.
Configuration Guidelines
• This feature must be configured globally for a switch; it cannot be configured per-port or
per-protocol.
• Enter each cpu traffic qos marking action on a separate line.
• The trust keyword configures the switch to trust the incoming CoS, DSCP, or precedence value and
marks the packet according to the global map configuration.
• The mutation keyword configures the switch to change the incoming value according to the global
mutation-map configuration.
• When you configure the switch to trust CoS, the configuration applies to both IP and non-IP traffic.
• When you configure the switch to trust or change DSCP or precedence but not CoS, the
configuration applies only to IP traffic.
• When you configure the switch to trust CoS and trust or change DSCP or precedence, trust CoS
applies to non-IP traffic and trust or change DSCP or precedence applies to IP traffic.
• The cpu traffic qos cos global configuration command configures CoS marking for CPU-generated
traffic by either trusting CoS or specifying a CoS value, but not both. A new configuration
overwrites the existing configuration.
• The cpu traffic qos dscp global configuration command configures DSCP marking for
CPU-generated traffic by trusting DSCP, mutating DSCP, or specifying a DSCP value. A new
configuration overwrites the existing configuration.
• The cpu traffic qos precedence global configuration command configures precedence marking for
CPU-generated traffic by trusting precedence, mutating precedence, or specifying a precedence
value. A new configuration overwrites the existing configuration.
• The cpu traffic qos dscp and cpu traffic qos precedence global configuration commands are
mutually exclusive. A new configuration overwrites the existing configuration.

OL-9644-10 34-29
Understanding Hierarchical QoS
Note The mls qos srr-queue output cpu-queue global configuration command overrides all of the above
queue mapping configuration options.

The switch supports a hierarchical QoS configuration (traffic classification, CBWFQ, LLQ, shaping, and
two-rate three-color policing) that is applied to the input or to the output of an ES port. Beginning with
Cisco IOS Release 12.2(35)SE, it also supports input and output hierarchical QoS on an EtherChannel
made of ES ports.
Hierarchical QoS configuration is based on the concept of a bandwidth-limited stream of traffic, which
is a stream of packets that has its departure rate constrained in some manner. At each level of the
hierarchy, the switch must classify each packet to select into which traffic stream in that level the packet
belongs. When the stream is classified, if its arrival rate exceeds its departure rate, queueing can become
congested. To compensate for this, you can configure policies that contain policer drops, configure tail
drop or WRED, a congestion-avoidance technique, or to influence whether the packet is queued. You
also can implement scheduling policies (CBWFQ, LLQ, and shaping) to influence how quickly a packet
is sent out the port.
This section includes these topics:
• Hierarchical Levels, page 34-30
• Hierarchical Classification Based on Traffic Classes and Traffic Policies, page 34-33
• Hierarchical Policies and Marking, page 34-34
• Queueing and Scheduling of Hierarchical Queues, page 34-37
Hierarchical Levels
Hierarchical QoS configuration involves traffic classification, policing, queueing, and scheduling. You
can create a hierarchy by associating a class-level policy map with a VLAN-level policy map, by
associating that VLAN-level policy map with a physical-level policy map, and by attaching the
physical-level policy map to an ES port. You can omit hierarchical levels, but the order of the levels
(class level, VLAN level, and then the physical level) must be preserved.
You can configure these three QoS levels in the hierarchy:
• Class level—You configure this level of the hierarchy by matching CoS, DSCP, IP precedence, or
MPLS EXP bits in the outbound packet through the match {cos [inner] cos-list | dscp dscp-list | ip
precedence ip-precedence-list | mpls experimental exp-list} class-map configuration command. At
the class level, you can:
– Configure policer drops by using the police cir or police cir percent policy-map class
– Configure tail drop or WRED drop policies by using the queue-limit or the random-detect
policy-map class configuration command.
– Modify the traffic class by setting Layer 2 and Layer 3 QoS fields through the set {cos new-cos
| dscp new-dscp | precedence new-precedence | mpls experimental exp-number} policy-map
class configuration command.

34-30 OL-9644-10
– Configure CBWFQ or LLQ scheduling by using the bandwidth or the priority policy-map
– Configure traffic shaping by using the shape policy-map class configuration command.
The switch supports eight classes (including the class) per policy map at this level. The class is
reserved for packets that do not meet any of the matching criteria.
This is an example of a class-level classification and its naming convention:
Switch(config)# class-map match-any class-level-class-map-name
Switch(config-cmap)# match ip dscp 10 11 12
This is an example of a class-level policy map and its naming convention:

Switch(config)# policy-map class-level-policy-map-name
Switch(config-pmap)# class class-level-class-name
Switch(config-pmap-c)# bandwidth percent 20
Switch(config-pmap-c)# shape average 20000000
This is a class-level configuration example that combines a class-level classification and a

class-level policy map to create a service policy:
Switch(config)# class-map c1
Switch(config-cmap)# match ip precedence 4
Switch(config-cmap)# exit
Switch(config)# policy-map policy1
Switch(config-pmap)# class c1
Switch(config-pmap-c)# police cir 500000 bc 10000 pir 1000000 be 10000 conform-action
transmit exceed-action set-prec-transmit 2 violate-action drop
Switch(config-pmap-c)# exit
Switch(config-pmap)# exit
Switch(config)# interface gigabitethernet1/1/1
Switch(config-if)# service-policy output policy1
• VLAN level—You start configuration of per-VLAN QoS by entering the match vlan vlan-id
class-map configuration command on one or more VLANs or by entering the match vlan vlan-id
and the match vlan inner vlan-id class-map configuration command on one or more 802.1Q
tunnels. At this level, you can configure the VLANs or 802.1Q tunnels to police, to share the
available port bandwidth and to enable CBWFQ, and to shape the traffic. You configure these
features by using the police cir, police cir percent, bandwidth, and shape policy-map class
configuration commands.
For a finer level of control, you can associate a previously defined child policy at the class level with
a new service policy by using the service-policy policy-map class configuration command. In the
class-level child policy, you can configure tail drop or WRED drop policies, set Layer 2 and Layer
3 QoS fields, or enable the strict-priority queue. These features are available only at the class level.
By using a child policy, you apply a class-level policy only to traffic that matches the VLAN class.
You cannot mix VLAN-level and class-level matches within a class map.
You can attach up to 2045 user-created VLAN-level classes. This means that you can have 1022
unique classes and can associate them with the two ES ports (and have one left over), or you can add
more classes to one ES port and can subtract from the other one. You can shape every class that you
configure. You can create up to 4093 class maps.
This is an example of a VLAN-level classification and its naming convention:
Switch(config)# class-map match-all vlan-level-class-map-name
Switch(config-cmap)# match vlan 5
Switch(config-cmap)# match vlan inner 3 - 8
This is an example of a VLAN-level policy map and its naming convention:

OL-9644-10 34-31
Switch(config)# policy-map vlan-level-policy-map-name

Switch(config-pmap)# class vlan-level-class-name
This is an example of a VLAN-level policy map and its naming convention when a previously
defined child policy is associated at the class level:
Switch(config)# policy-map vlan-level-policy-map-name
Switch(config-pmap)# class vlan-level-class-name
Switch(config-pmap-c)# service-policy class-level-policy-map-name
This is a VLAN-level configuration example that combines a VLAN-level classification and a

VLAN-level policy map:
Switch(config)# class-map match-all vlan203
Switch(config)# policy-map vlan-policy
Switch(config-pmap)# class vlan203
This is an example of a VLAN-level policy map that combines a VLAN-level classification with a
VLAN-level policy map and associates a previously defined child policy at the class level:
Switch(config)# class-map cls-class
Switch(config-cmap)# match mpls experimental 2
Switch(config)# class-map log-class
Switch(config)# policy-map cls-policy
Switch(config-pmap)# class cls-class
Switch(config-pmap-c)# set mpls experimental 5
Switch(config)# policy-map log-policy
Switch(config-pmap)# class log-class
Switch(config-pmap-c)# service-policy cls-policy
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# service-policy output log-policy
• Physical level—You can shape or police only the class-default class at the physical level of the
hierarchy by using the shape, police cir, or police cir percent policy-map class configuration
command.
Within a policy map, the class-default applies to all traffic that is not explicitly matched within the
policy map but does match the parent policy. If no parent policy is configured, the parent policy
represents the physical port. In a physical-level policy map, class-default is the only class that you
can configure.
You use the service-policy {input | output} policy-map-name interface configuration command to
attach a hierarchical policy to an ES port.
This is an example of a physical-level configuration. All hierarchical levels exist, and the order is
preserved. The class level at the bottom, the VLAN level in the middle, and the physical level at the
top.

34-32 OL-9644-10
Switch(config)# class-map my-class

Switch(config)# class-map my-logical-class
Switch(config)# policy-map my-class-policy
Switch(config-pmap)# class my-class
Switch(config-pmap-c)# set precedence 2
Switch(config)# policy-map my-logical-policy
Switch(config-pmap)# class my-logical-class
Switch(config-pmap-c)# service-policy my-class-policy
Switch(config)# policy-map my-physical-policy
Switch(config-pmap)# class class-default
Switch(config-pmap-c)# service-policy my-logical-policy
Switch(config-if)# service-policy output my-physical-policy
Hierarchical Classification Based on Traffic Classes and Traffic Policies

Hierarchical classification distinguishes one kind of traffic from another on receipt or before sending.
The switch examines the fields in the packet, processes the match commands, and creates the queues.
The switch forwards the traffic according to the QoS specifications set in the hierarchical policy.
You use the class map to define a specific traffic flow (or class) and to isolate it from all other traffic.
The class map defines the criteria used to match against a specific traffic flow to further classify it. At
the class level, the criteria can include matching CoS, DSCP, IP precedence, or MPLS EXP bits in the
header. At the VLAN level, the criteria can include matching a packet based on the inner and the outer
VLAN IDs. If you have more than one type of traffic that you want to classify, you can create another
class map and use a different name.
You create a class map by using the class-map global configuration command. When you enter the
class-map command, the switch enters the class-map configuration mode. In this mode, you define the
match criterion for the traffic by using the match class-map configuration command. Packets are
compared to the match criteria configured for a class map. If a packet matches the specified criteria, the
packet is considered a member of the class, the switch creates a queue for it, and the packet is forwarded
according to the QoS specifications set in the traffic policy. If a packet fails to meet any of the matching
criteria, it is classified as a member of the traffic class if one is configured.
You use the policy map to create the traffic policy, to specify the traffic class to act on, and to configure
the QoS features associated with the traffic class. Actions can include trusting the received CoS, DSCP,
or IP precedence bits in the traffic class; setting specific CoS, DSCP, IP precedence, or MPLS EXP bits
in the traffic class; or specifying the traffic bandwidth limitations and the action to take when the traffic
is out of profile.
You create and name a policy map by using the policy-map global configuration command. When you
enter this command, the switch enters the policy-map configuration mode. In this mode, you use the
class policy-map configuration command to name the traffic class associated with the traffic policy. If

OL-9644-10 34-33
you specify class-default as the class name in the class policy-map configuration command, packets that
fail to meet any of the matching criteria are classified as members of the traffic class. You can manipulate
this class (for example, police it and mark it) just like any traffic class, but you cannot delete it.
Within a policy map, the class-default designates all traffic that is not explicitly matched within the
policy map but does match the policy map of the parent policy. If no parent policy is configured, the
parent policy represents the physical port. In the physical-level policy map, class-default is the only class
that can be configured.
After you name the traffic class with the class command, the switch enters policy-map class
configuration mode, and you can specify the actions to take on this traffic class.
You attach a hierarchical policy map to an ES port by using the service-policy [input | output]
policy-map-name interface configuration command. The policy map can include the bandwidth, police
cir, police cir percent, priority, queue-limit, random-detect, shape, or set policy-map class
configuration commands. If the policy map contains the class-default class, you can configure settings
only through the police cir, police cir percent, and shape commands.
For more information, see the “Hierarchical Policies and Marking” section on page 34-34 and the
“Queueing and Scheduling of Hierarchical Queues” section on page 34-37.
Hierarchical Policies and Marking

Hierarchical traffic policies control the maximum rate of traffic received or sent on an ES port. A policer
defines the bandwidth limitations of the traffic and the action to take if the limits are exceeded. It is often
configured on ports at the edge of a network to limit traffic into or out of the network. In most policing
configurations, traffic that falls within the rate parameters is sent. Traffic that exceeds the parameters is
considered to be out of profile or nonconforming and is dropped or sent with a different priority.
You can configure a two-rate traffic policer within a policy map at the class level, at the VLAN level,
and at the physical level by using the police cir or the police cir percent policy-map class configuration
command. At the physical level of the hierarchy, you can police only the class-default class in a policy
attached to an ES port.
You can configure a two-rate traffic policer to limit the transmission rate of a traffic class and mark
actions (conform, exceed, and violate) for each packet. Within the conform, exceed, and violate
categories, you decide packet treatments. In the most common configurations, you configure packets that
conform to be sent, packets that exceed to be sent with a decreased priority, and packets that violate to
be dropped. You can decrease the priority of the CoS, the DSCP, the IP precedence, or the MPLS EXP
bits in the packet.
The two-rate policer manages the maximum rate of traffic through a token-bucket algorithm. The
algorithm uses the configured committed information rate (CIR) and the peak information rate (PIR) rate
values to control the maximum rate of traffic allowed on a port at a given moment in time. The algorithm
is affected by all traffic leaving the port, and it manages network bandwidth when several large packets
are sent in the same traffic stream.
A token bucket is provided for the CIR and the PIR as shown in Figure 34-11.

34-34 OL-9644-10
Figure 34-11 Two-Rate Policing and Marking Flowchart
PIR CIR
Peak burst Conform burst

size (Be) size (Bc)
Is packet Is packet
size of B larger No size of B larger No
than number of tokens than number of tokens
Packet of size B available in PIR available in CIR
bucket? bucket?
Yes Yes
Violate Exceed Conform
98723
Action Action Action
You configure the CIR and PIR rates in bps (or as a percentage of the bandwidth available on an ES port),
and these rates control how fast the bucket fills (is updated) with tokens. The conform burst size (bc) and
the peak burst size (be) represent the depth of the CIR and PIR buckets in bytes. This depth limits the
number of tokens that the bucket can accumulate. If the bucket fills to capacity, newly arriving tokens
are discarded.
Each token is permission for the source to send a certain number of bits into the network. To send a
packet, the number of tokens equal to the packet size must be drained from the bucket. If there are
enough tokens in the bucket, the packet conforms and can pass to the next stage. Otherwise, the exceed
action associated with the bucket is applied to the packet. The packet might be dropped, or its priority
value might be marked down.
In this token-bucket example, if the CIR rate is 2 kb/s, 2000 tokens are added to the bucket every second
(for this example, consider each token to represent a single bit of information). If a 1500-byte packet
arrives, 12000 tokens (1500 bytes x 8 bits per byte) must be in the bucket for the packet to pass to the
next state without triggering the exceed action. If enough tokens are in the bucket, they are drained, and
the packet conforms and passes to the next stage. If there are less than 12000 tokens in the bucket, the
exceed action is applied to the packet. The deeper the bucket, the more data can burst through at a rate
greater than the rate at which the bucket is filling. For example, if the CIR bucket holds 6000 tokens, 750
bytes of traffic can instantaneously burst without draining the bucket (and without triggering an exceed
action), even though the instantaneous burst is at a greater rate than the CIR rate of 2000 bps.
If the burst sizes approach the system maximum transmission unit (MTU), the policer strictly enforces the
CIR and PIR. Normal traffic jitter can cause some percentage of inbound traffic to be flagged as
nonconforming even if the average inbound rate appears to conform. If the burst size is very large, on the other
hand, large traffic bursts at nonconforming data rates can be passed through the policer and flagged as
conforming. Setting the burst sizes too low can result in less traffic than expected and setting them too
high can result in more traffic than expected.

OL-9644-10 34-35
For packet marking actions, if the CIR is 100 kb/s, the PIR is 200 kb/s, and a data stream with a rate of
250 kb/s arrives at the two-rate policer:
• 100 kb/s is marked as conforming to the rate.
• 100 kb/s is marked as exceeding the rate.
• 50 kb/s is marked as violating the rate.
If you set the CIR equal to the PIR, a traffic rate that is less than the CIR or that meets the CIR is in the
conform range. Traffic that exceeds the CIR rate is in the violate range.
If you set the PIR greater than the CIR, a traffic rate less than the CIR is in the conform range. A traffic
rate that exceeds the CIR but is less than or equal to the PIR is in the exceed range. A traffic rate that
exceeds the PIR is in the violate range.
After you configure the policy map and policing actions, attach the policy to an ES port by using the
service-policy {input | output} policy-map-name interface configuration command. For configuration
information, see the “Configuring Hierarchical QoS” section on page 34-103.
An input hierarchical service policy can contain the same configuration options as an output hierarchical
service policy (policing, shaping, CBWFQ), but cannot include configurations such as ACLs or
aggregate policers. Access group matches are allowed on ES ports if the policy is non-hierarchical.
Violating this rule prevents the policy from being attached to an interface.

34-36 OL-9644-10
Queueing and Scheduling of Hierarchical Queues

Figure 34-12 shows the queueing and scheduling flowchart for a hierarchical queue.
Figure 34-12 Queueing and Scheduling Flowchart for a Hierarchical Queue
Start
Receive packet from

an ES port or from
egress queue-set
and scheduling.
Read QoS label (DSCP,

CoS, IP precedence,
or MPLS EXP bits).
Determine ingress and

egress queue and
thresholds based on the
label, VLAN ID, or both.
Are thresholds Yes

being exceeded?
No
Drop packet.
Queue the packet.
Service the queue
according to the
CBWFQ, LLQ, or both.
Rewrite any or all DSCP,

IP precedence,
MPLS EXP, and
CoS bits as appropriate.
Continue ingress
processing or send
packet out the ES port.
122040
Done

OL-9644-10 34-37
Hierarchical Queues
The switch uses a hierarchical queueing model for traffic received on or sent from an ES port. Each
packet is assigned a queue based on its physical interface, VLAN, or class:
• At the class level, a packet is queued to one of four queues according to its CoS, DSCP, IP
precedence, or MPLS EXP classification. Packets can be classified by any combination of these
values, but if a packet matches more than one, the classification occurs in the order listed. The last
queue in each set of four queues is reserved as the default queue. Packets that are not classified into
one of the other three queues are assigned to the default queue. You can configure traffic in the queue
with congestion-avoidance features and scheduling congestion-management features as described in
the “Queueing and Scheduling of Hierarchical Queues” section on page 34-37.
• At the VLAN level, the switch supports 2045 VLAN classes divided between the two ES ports. One
queue is reserved as the default queue. Packets that are not classified into one of the other VLAN
queues are assigned to the default queue. You can configure traffic in the default queue with
congestion-avoidance features and scheduling congestion-management features as described in the
“Queueing and Scheduling of Hierarchical Queues” section on page 34-37.
• At the physical level, the switch reserves one queue per port.
The switch creates the queue and uses it to send all traffic when a service policy is not attached to an ES
port. User traffic on a physical port without an attached service policy bypasses the QoS classification
and is queued to the default queue. The minimum and maximum bandwidth for the default queue is the
same as the port bandwidth.
Under congested conditions, the switch discards packets for all classes configured for the same sending
queue with equal probability. To achieve the full queueing capacity, there must be an equal division of
traffic among the classes for each sending queue.
Congestion-Management and Congestion-Avoidance Features

You use congestion-management features to control congestion and to control the order in which packets
are received on or are sent from an ES port based on the priorities assigned to those packets. You manage
congestion by creating queues, by assigning packets based on the packet classification, and by
scheduling the packets to be sent from the queue.
During periods with light traffic (when no congestion exists), the switch sends packets as soon as they
arrive. During periods of congestion at the inbound or at the outbound port, packets arrive faster than the
port can send them. If you use congestion-management features, the switch queues accumulating packets
at a port until it is free to send them. They are then scheduled for transmission according to their assigned
priorities and the queueing mechanism for the port.
You can configure either tail drop or WRED. You cannot configure both tail drop and WRED in the same
class policy, but they can be used in two different class policies in the same policy map.
You can configure CBWFQ as a queue scheduling management feature, LLQ as a scheduling
congestion-management feature, and traffic shaping to decrease the burstiness of traffic.
Tail Drop
With tail drop, packets are queued for the class until the maximum threshold is exceeded, and then all
the packets destined for the class queue are dropped. You enable tail drop at the class level by using the
queue-limit policy-map class configuration command. For configuration information, see the
“Configuring a Hierarchical QoS Policy” section on page 34-107.

34-38 OL-9644-10
WRED
Cisco Systems implements a version of Random Early Detection (RED), called WRED, differently from
other congestion-avoidance techniques. WRED attempts to anticipate and avoid congestion, rather than
controlling congestion when it occurs. WRED takes advantage of the TCP congestion control to try to
control the average queue size by signaling end hosts when they should temporarily stop sending
packets. By randomly dropping packets before periods of high congestion, it tells the packet source to
decrease its sending rate. Assuming the packet source is using TCP, WRED tells it to decrease its sending
rate until all the packets reach their destination, meaning that the congestion is cleared. By dropping
some packets early rather than waiting until the queue is full, WRED avoids dropping large numbers of
packets at once.
When a packet arrives and WRED is enabled, these events occur:
• The average queue size is calculated based on the previous average and the current size of the queue.
The average queue-size calculation is affected by the exponential weight constant setting in the
random-detect exponential-weight-constant policy-map class configuration command.
• If the average queue size is less than the minimum queue threshold, the arriving packet is queued.
The minimum queue threshold is configured through the min-threshold option in the random-detect
{dscp | precedence} policy-map class configuration command.
• If the average queue size is between the minimum queue threshold and the maximum queue
threshold, the packet is either dropped or queued, depending on the packet-drop probability. The
packet-drop probability is based on the minimum threshold, the maximum threshold, and the
mark-probability denominator. The maximum queue threshold is configured through the
max-threshold option, and the mark-probability denominator is configured through the
mark-prob-denominator option in the random-detect dscp {dscp | precedence} policy-map class
• If the average queue size is greater than the maximum queue threshold, the packet is automatically
dropped.
You enable WRED by using the random-detect policy-map class configuration command at the class
level. This command allows for preferential drop treatment among packets with different IP precedence
or DSCP values. The WRED algorithm discards or marks packets destined for a queue when that queue
is congested. It discards packets fairly and before the queue is full. Packets with high IP-precedence
values are preferred over packets with low IP-precedence values. For configuration information, see the
“Configuring a Hierarchical QoS Policy” section on page 34-107.
CBWFQ
CBWFQ provides guaranteed bandwidth to particular traffic classes, such as voice, that are delay
sensitive, while still fairly serving all other traffic in the network. You define traffic classes based on
match criteria. Packets satisfying the match criteria for a class constitute the traffic for that class. A
queue is reserved for each class, and traffic belonging to a class is directed to the queue for that class.
The bandwidth assigned to a class is the minimum bandwidth that is delivered to the class during
congestion. CBWFQ uses the bandwidth weight to ensure that the queue for the class is serviced fairly.
You enable CBWFQ and specify the minimum bandwidth as a rate in kb/s or as a percentage of the
available bandwidth by using the bandwidth policy-map class configuration command at the class level
or at the VLAN level. During periods of congestion, the classes are serviced in proportion to their
configured bandwidth. The amount of bandwidth available to a class is dependent on the amount of
bandwidth reserved by the parent class. For configuration information, see the “Configuring a
Hierarchical QoS Policy” section on page 34-107.

OL-9644-10 34-39
Configuring Auto-QoS
LLQ
LLQ provides strict-priority queueing for a traffic class. It enables delay-sensitive data, such as voice,
to be sent before packets in other queues are sent. The priority queue is serviced first until it is empty.
Only one traffic stream can be destined for the priority queue per class-level policy. The priority queue
restricts all traffic streams in the same hierarchy, and you should use care when configuring this feature.
You enable the priority queue for a traffic class by using the priority policy-map class configuration
command at the class level. For configuration information, see the “Configuring a Hierarchical QoS
Policy” section on page 34-107.
With Cisco IOS Release 12.1(14)AX2, you can use LLQ and the egress priority queue (enabled with the
priority-queue out interface configuration command) to give priority to a class of traffic and to avoid a
loss of traffic when the switch is congested. In previous releases (before the egress priority queue was
supported), you could put a traffic class into the strict-priority queue, but congestion at the egress
queue-sets could result in the dropping of that priority traffic. You can use the priority-queue out
interface configuration command to prioritize the same traffic class at the egress queue-sets, ensuring
that priority traffic reaches the hierarchical queues and is processed with priority.
Shaping
Shaping provides a process for delaying out-of-profile packets in queues so that they conform to a
specified profile. Shaping is distinct from policing. Policing drops packets that exceed a configured
threshold, but shaping buffers packets so that traffic remains within a threshold. Shaping offers greater
smoothness in handling traffic than policing. You enable average-rate traffic shaping on a traffic class
by using the shape policy-map class configuration command at the class level or at the VLAN level. At
the physical level of the hierarchy, you can shape only the class-default class by using the shape
policy-map class configuration command in a policy attached to an ES port. For configuration
information, see the “Configuring a Hierarchical QoS Policy” section on page 34-107.
Hierarchical QoS on EtherChannels

Beginning with Cisco IOS Release 12.2(35)SE, you can configure three-level hierarchical QoS on
EtherChannels with no ports or with one or both ES ports. If you configure hierarchical QoS on an
EtherChannel with no ports and add a standard port to the EtherChannel, the hierarchical policy map is
removed from the EtherChannel. Hierarchical policies are not supported on a non-ES port.
For a list of differences between hierarchical QoS over EtherChannels and hierarchical QoS over ES
ports, see the “Hierarchical QoS Configuration Guidelines” section on page 34-104.
You can use the auto-QoS feature to simplify the deployment of existing QoS features. Auto-QoS makes
assumptions about the network design, and as a result, the switch can prioritize different traffic flows
and appropriately use the ingress and egress queues instead of using the QoS behavior. The default is
that QoS is disabled. The switch then offers best-effort service to each packet, regardless of the packet
contents or size, and sends it from a single queue.)
When you enable auto-QoS, it automatically classifies traffic based on the traffic type and ingress packet
label. The switch uses the resulting classification to choose the appropriate egress queue.

34-40 OL-9644-10
You use auto-QoS commands to identify ports connected to Cisco IP Phones and to devices running the
Cisco SoftPhone application. You also use the commands to identify ports that receive trusted traffic
through an uplink. Auto-QoS then performs these functions:
• Detects the presence or absence of IP phones
• Configures QoS classification
• Configures egress queues
These sections describe how to configure auto-QoS on your switch:
• Generated Auto-QoS Configuration, page 34-41
• Effects of Auto-QoS on the Configuration, page 34-45
• Auto-QoS Configuration Guidelines, page 34-45
• Upgrading from a Previous Software Release, page 34-46
• Enabling Auto-QoS for VoIP, page 34-46
• Auto-QoS Configuration Example, page 34-48
Generated Auto-QoS Configuration

By default, auto-QoS is disabled on all ports.
When auto-QoS is enabled, it uses the ingress packet label to categorize traffic, to assign packet labels,
and to configure the ingress queues and egress queue-sets as shown in Table 34-3.
Table 34-3 Traffic Types, Packet Labels, and Queues
VoIP1 Data VoIP Control Routing Protocol STP BPDU Real-Time

Traffic Traffic Traffic Traffic Video Traffic All Other Traffic
DSCP 46 24, 26 48 56 34 –
CoS 5 3 6 7 4 –
CoS-to-Ingress 2, 3, 4, 5, 6, 7 (queue 2) 0, 1 (queue 1)
Queue Map
CoS-to-Egress 5 (queue 1) 3, 6, 7 (queue 2) 4 (queue 3) 2 (queue 3) 0, 1
Queue Map (queue 4)
1. VoIP = voice over IP.
Table 34-4 shows the generated auto-QoS configuration for the ingress queues.
Table 34-4 Auto-QoS Configuration for the Ingress Queues
Queue Weight Queue (Buffer)

Ingress Queue Queue Number CoS-to-Queue Map (Bandwidth) Size
SRR shared 1 0, 1 81 percent 67 percent
Priority 2 2, 3, 4, 5, 6, 7 19 percent 33 percent

OL-9644-10 34-41
Table 34-5 shows the generated auto-QoS configuration for the egress queue-set.
Table 34-5 Auto-QoS Configuration for the Egress Queue-Set
Queue Number
in the Queue Weight Queue (Buffer)
Egress Queue Queue-Set CoS-to-Queue Map (Bandwidth) Size
Priority (shaped) 1 5 10 percent 10 percent
SRR shared 2 3, 6, 7 10 percent 10 percent
Note You must enable QoS by entering the mls qos global configuration command before configuring the QoS
parameters for CPU-generated traffic. Otherwise, the CPU traffic QoS command configurations are not
applied. To configure the QoS parameters, use the cpu traffic qos global configuration command.
When you enable the auto-QoS feature on the first port, these automatic actions occur:
• QoS is globally enabled (mls qos global configuration command), and other global configuration
commands are added.
• When you enter the auto qos voip cisco-phone interface configuration command on a port at the
edge of the network that is connected to a Cisco IP phone, the switch enables the trusted boundary
feature. The switch uses the Cisco Discovery Protocol (CDP) to detect the presence or absence of a
Cisco IP Phone. When a Cisco IP Phone is detected, the ingress classification on the port is set to
trust the QoS label received in the packet. When a Cisco IP Phone is absent, the ingress classification
is set to not trust the QoS label in the packet. The switch configures ingress queues and the egress
queue-set on the port according to the settings in Table 34-4 and Table 34-5.
• When you enter the auto qos voip cisco-softphone interface configuration command on a port at
the edge of the network that is connected to a device running the Cisco SoftPhone, the switch uses
policing to determine whether a packet is in or out of profile and to specify the action on the packet.
If the packet does not have a DSCP value of 24, 26, or 46 or is out of profile, the switch changes the
DSCP value to 0. The switch configures ingress and egress queues on the port according to the
settings in Table 34-4 and Table 34-5.
• When you enter the auto qos voip trust interface configuration command on a port connected to the
interior of the network, the switch trusts the CoS value for nonrouted ports or the DSCP value for
routed ports in ingress packets (the assumption is that traffic has already been classified by other
edge devices). The switch configures the ingress queues and the egress queue-set on the port
according to the settings in Table 34-4 and Table 34-5.
For information about the trusted boundary feature, see the “Configuring a Trusted Boundary to
Ensure Port Security” section on page 34-60.
When you enable auto-QoS by using the auto qos voip cisco-phone, the auto qos voip cisco-softphone,
or the auto qos voip trust interface configuration command, the switch automatically generates a QoS
configuration based on the traffic type and the ingress packet label and applies the commands listed in
Table 34-6 to the port.
Note On an ES port, the srr-queue bandwidth shape interface configuration command is not part of the
generated auto qos voip command list.

34-42 OL-9644-10
Table 34-6 Generated Auto-QoS Configuration
Description Automatically Generated Command

The switch automatically enables standard QoS and configures Switch(config)# mls qos
the CoS-to-DSCP map (maps CoS values in inbound packets to Switch(config)# mls qos map cos-dscp 0 8 16 26 32 46
48 56
a DSCP value).
The switch automatically maps CoS values to an ingress queue Switch(config)# no mls qos srr-queue input cos-map
and to a threshold ID. Switch(config)# mls qos srr-queue input cos-map
queue 1 threshold 3 0
Switch(config)# mls qos srr-queue input cos-map
queue 2 threshold 2 4 6 7
queue 2 threshold 3 3 5
The switch automatically maps CoS values to an egress queue Switch(config)# no mls qos srr-queue output cos-map
in the queue-set and to a threshold ID. Switch(config)# mls qos srr-queue output cos-map
Switch(config)# mls qos srr-queue output cos-map
queue 2 threshold 3 3 6 7
queue 3 threshold 3 2 4
The switch automatically maps DSCP values to an ingress Switch(config)# no mls qos srr-queue input dscp-map
queue and to a threshold ID. Switch(config)# mls qos srr-queue input dscp-map
queue 1 threshold 2 9 10 11 12 13 14 15
Switch(config)# mls qos srr-queue input dscp-map
queue 1 threshold 3 0 1 2 3 4 5 6 7
queue 2 threshold 1 16 17 18 19 20 21 22 23
queue 2 threshold 2 33 34 35 36 37 38 39 48
queue 2 threshold 2 49 50 51 52 53 54 55 56
queue 2 threshold 2 57 58 59 60 61 62 63
queue 2 threshold 3 24 25 26 27 28 29 30 31
queue 2 threshold 3 40 41 42 43 44 45 46 47

OL-9644-10 34-43
Table 34-6 Generated Auto-QoS Configuration (continued)

The switch automatically maps DSCP values to an egress Switch(config)# no mls qos srr-queue output dscp-map
queue in the queue-set and to a threshold ID. Switch(config)# mls qos srr-queue output dscp-map
queue 1 threshold 3 40 41 42 43 44 45 46 47
Switch(config)# mls qos srr-queue output dscp-map
queue 2 threshold 3 24 25 26 27 28 29 30 31
queue 2 threshold 3 48 49 50 51 52 53 54 55
queue 2 threshold 3 56 57 58 59 60 61 62 63
queue 3 threshold 3 16 17 18 19 20 21 22 23
queue 3 threshold 3 32 33 34 35 36 37 38 39
queue 4 threshold 2 9 10 11 12 13 14 15
queue 4 threshold 3 0 1 2 3 4 5 6 7
The switch automatically sets up the ingress queues, with Switch(config)# no mls qos srr-queue input
queue 2 as the priority queue and queue 1 in shared mode. The priority-queue 1
Switch(config)# no mls qos srr-queue input
switch also configures the bandwidth and buffer size for the priority-queue 2
ingress queues. Switch(config)# mls qos srr-queue input bandwidth 90
10
Switch(config)# mls qos srr-queue input threshold 1
8 16
Switch(config)# mls qos srr-queue input threshold 2
34 66
Switch(config)# mls qos srr-queue input buffers 67
33
The switch automatically configures the egress queue-set Switch(config)# mls qos queue-set output 1 buffers
buffer sizes. It configures the bandwidth and the SRR mode 10 10 26 54
Switch(config-if)# srr-queue bandwidth shape 10 0 0
(shaped or shared). 0
Switch(config-if)# srr-queue bandwidth share 10 10
60 20
The switch automatically sets the ingress classification to trust Switch(config-if)# mls qos trust cos
the CoS value received in the packet on a nonrouted port or to Switch(config-if)# mls qos trust dscp
trust the DSCP value received in the packet on a routed port.
If you entered the auto qos voip cisco-phone command, the Switch(config-if)# mls qos trust device cisco-phone
switch automatically enables the trusted boundary feature,
which uses the CDP to detect the presence or absence of a
Cisco IP Phone.

34-44 OL-9644-10
Table 34-6 Generated Auto-QoS Configuration (continued)

If you entered the auto qos voip cisco-softphone command, Switch(config)# mls qos map policed-dscp 24 26 46 to
the switch automatically creates class maps and policy maps. 0
Switch(config)# class-map match-all
AutoQoS-VoIP-RTP-Trust
Switch(config-cmap)# match ip dscp ef
Switch(config)# class-map match-all
AutoQoS-VoIP-Control-Trust
Switch(config-cmap)# match ip dscp cs3 af31
Switch(config)# policy-map AutoQoS-Police-SoftPhone
Switch(config-pmap)# class AutoQoS-VoIP-RTP-Trust
Switch(config-pmap-c)# set dscp ef
Switch(config-pmap-c)# police 320000 8000
exceed-action policed-dscp-transmit
Switch(config-pmap)# class
AutoQoS-VoIP-Control-Trust
Switch(config-pmap-c)# set dscp cs3
Switch(config-pmap-c)# police 32000 8000
exceed-action policed-dscp-transmit
After creating the class maps and policy maps, the switch Switch(config-if)# service-policy input
automatically applies the policy map called AutoQoS-Police-SoftPhone
AutoQoS-Police-SoftPhone to an ingress interface on which
auto-QoS with the Cisco SoftPhone feature is enabled.
Effects of Auto-QoS on the Configuration

When auto-QoS is enabled, the switch adds the auto qos voip interface configuration command and the
generated configuration to the running configuration.
The switch applies the auto-QoS-generated commands as if the commands were entered from the CLI.
An existing user configuration can cause the application of the generated commands to fail, or the user
configuration might be overridden by the generated commands. These actions occur without warning. If
all the generated commands are successfully applied, any user-entered configuration that was not
overridden remains in the running configuration. Any user-entered configuration that was overridden can
be retrieved by reloading the switch without saving the current configuration to memory. If the generated
commands are not applied, the previous running configuration is restored.
Auto-QoS Configuration Guidelines

Before configuring auto-QoS, you should be aware of this information:
• In releases earlier than Cisco IOS Release 12.2(25)EY, auto-QoS configures VOIP only on switch
ports with Cisco IP Phones.
• In Cisco IOS Release 12.2(25)EY or later, auto-QoS configures the switch for VoIP with Cisco IP
Phones on nonrouted and routed ports. Auto-QoS also configures the switch for VoIP with devices
running the Cisco SoftPhone application.
Note When a device running Cisco SoftPhone is connected to a nonrouted or routed port, the
switch supports only one Cisco SoftPhone application per port.

OL-9644-10 34-45
• To take advantage of the auto-QoS s, you should enable auto-QoS before you configure other QoS
commands. If necessary, you can fine-tune the QoS configuration, but we recommend that you do
so only after the auto-QoS configuration is completed. For more information, see the “Effects of
Auto-QoS on the Configuration” section on page 34-45.
• After auto-QoS is enabled, do not modify a policy map or aggregate policer that includes AutoQoS
in its name. If you need to modify the policy map or aggregate policer, make a copy of it, and change
the copied policy map or policer. To use this new policy map instead of the generated one, remove
the generated policy map from the interface, and apply the new policy map to the interface.
• You can enable auto-QoS on static, dynamic-access, voice VLAN access, and trunk ports.
• By default, the CDP is enabled on all ports. For auto-QoS to function properly, do not disable the
CDP.
• When enabling auto-QoS with a Cisco IP Phone on a routed port, you must assign a static IP address
to the IP phone.
• This release supports only Cisco IP SoftPhone Version 1.3(3) or later.
• Connected devices must use Cisco Call Manager Version 4 or later.
• You can manually enable policing, as described in the “Configuring an Ingress QoS Policy” section
on page 34-63.
Upgrading from a Previous Software Release

In Cisco IOS Release 12.2(25)EY, the implementation for auto-QoS changed from the previous release.
The generated auto-QoS configuration was changed, support for the Cisco SoftPhone feature was added,
and support for Cisco IP Phones on routed ports was added.
If auto-QoS is configured on the switch, your switch is running a release earlier than Cisco IOS
Release 12.2(25)EY, and you upgrade to Cisco IOS Release 12.2(25)EY or later, the configuration file
will not contain the new configuration, and auto-QoS will not operate. Follow these steps to update the
auto-QoS settings in your configuration file:
1. Upgrade your switch to Cisco IOS Release 12.2(25)EY or later.
2. Disable auto-QoS on all ports on which auto-QoS was enabled.
3. Return all the global auto-QoS settings to their values by using the no commands.
4. Re-enable auto-QoS on the ports on which auto-QoS was disabled in Step 2. Configure the ports
with the same auto-QoS settings as the previous ones.
Enabling Auto-QoS for VoIP

Beginning in privileged EXEC mode, follow these steps to enable auto-QoS for VoIP within a QoS
domain:
Command Purpose
Step 1 configure terminal Enter global configuration mode.
Step 2 interface interface-id Specify the port that is connected to a Cisco IP Phone or the uplink
port that is connected to another switch or router in the interior of the
network, and enter interface configuration mode.

34-46 OL-9644-10
Command Purpose
Step 3 auto qos voip {cisco-phone | Enable auto-QoS.
cisco-softphone | trust}
The keywords have these meanings:
• cisco-phone—If the port is connected to a Cisco IP Phone, the
QoS labels of inbound packets are trusted only when the
telephone is detected.
• cisco-softphone—The port is connected to device running the
Cisco SoftPhone feature.
• trust—The uplink port is connected to a trusted switch or router,
and the VoIP traffic classification in the ingress packet is trusted.
Step 4 end Return to privileged EXEC mode.
Step 5 show auto qos interface interface-id Verify your entries.
This command displays the initial auto-QoS configuration that was
applied; it does not display any user changes to the configuration that
might be in effect. You can use the show running-config privileged
EXEC command to display the auto-QoS configuration and the user
modifications.
To display the QoS commands that are automatically generated when auto-QoS is enabled or disabled,
enter the debug autoqos privileged EXEC command before enabling auto-QoS. For more information,
see the “debug autoqos” command in the command reference for this release.
To disable auto-QoS on a port, use the no auto qos voip interface configuration command. Only the
auto-QoS-generated interface configuration commands for this port are removed. If this is the last port
on which auto-QoS is enabled and you enter the no auto qos voip command, auto-QoS is considered
disabled even though the auto-QoS-generated global configuration commands remain (to avoid
disrupting traffic on other ports affected by the global configuration). You can use the no mls qos global
configuration command to disable the auto-QoS-generated global configuration commands. With QoS
disabled, there is no concept of trusted or untrusted ports because the packets are not modified (the CoS,
DSCP, and IP precedence values in the packet are not changed). Traffic is switched in pass-through mode
(packets are switched without any rewrites and classified as best effort without any policing).
This example shows how to enable auto-QoS on a port and to trust the QoS labels received in inbound
packets when the switch or router connected to a port is a trusted device:
Switch(config-if)# auto qos voip trust

OL-9644-10 34-47
Auto-QoS Configuration Example

This section describes how you could implement auto-QoS in a network, as shown in Figure 34-13.
Figure 34-13 Auto-QoS Configuration Example Network
Cisco router
To Internet
Trunk Trunk
link link Video server
172.20.10.16
End stations
Identify this interface Identify this interface

as connected to a as connected to a
trusted switch or router trusted switch or router
IP IP
Identify these Identify these

interfaces as interfaces as
IP connected to connected to IP
IP phones IP phones
101234
Cisco IP phones Cisco IP phones
Figure 34-13 shows a network in which the VoIP traffic is prioritized over all other traffic. Auto-QoS is
enabled on the switches in the wiring closets at the edge of the QoS domains.
Note You should not configure any standard QoS commands before entering the auto-QoS commands. You
can fine-tune the QoS configuration, but we recommend that you do so only after the auto-QoS
configuration is completed.

34-48 OL-9644-10
Displaying Auto-QoS Information
Beginning in privileged EXEC mode, follow these steps to configure the switch at the edge of the QoS
domain to prioritize the VoIP traffic over all other traffic:
Command Purpose
Step 1 debug auto qos Enable debugging for auto-QoS. When debugging is enabled, the
switch displays the QoS configuration that is automatically
generated when auto-QoS is enabled.
Step 3 cdp enable Enable CDP globally. By default, it is enabled.
Step 4 interface interface-id Specify the switch port connected to the Cisco IP Phone, and enter
interface configuration mode.
Step 5 auto qos voip cisco-phone Enable auto-QoS on the port, and specify that the port is connected
to a Cisco IP Phone.
The QoS labels of inbound packets are trusted only when the Cisco
IP Phone is detected.
Step 6 exit Return to global configuration mode.
Step 7 Repeat Steps 4 to 6 for as many ports as are connected to the Cisco
IP Phone.
Step 8 auto qos voip cisco-phone Enable auto-QoS on the port, and specify that the port is connected
to a Cisco IP Phone.
Step 10 interface interface-id Specify the port identified as connected to a trusted switch or
router. See Figure 34-13. Enter interface configuration mode.
Step 11 auto qos voip trust Enable auto-QoS on the port, and specify that the port is connected
to a trusted router or switch.
Step 13 show auto qos Verify your entries.
This command displays the auto-QoS configuration that is initially
applied; it does not display any user changes to the configuration
that might be in effect.
For information about the QoS configuration that might be
affected by auto-QoS, see the “Displaying Auto-QoS Information”
Step 14 copy running-config Save the auto qos voip interface configuration commands and the
startup-config generated auto-QoS configuration in the configuration file.
Displaying Auto-QoS Information

To display the initial auto-QoS configuration, use the show auto qos [interface [interface-id]]
privileged EXEC command. To display any user changes to that configuration, use the show
running-config privileged EXEC command. You can compare the show auto qos and the show
running-config command displays to identify the user-defined QoS settings.

OL-9644-10 34-49
Configuring Standard QoS
To display information about the QoS configuration that might be affected by auto-QoS, use one of these
commands:
• show cpu traffic qos
• show mls qos
• show mls qos maps cos-dscp
• show mls qos interface [interface-id] [buffers | queueing]
• show mls qos maps [cos-dscp | cos-input-q | cos-output-q | dscp-cos | dscp-input-q |
dscp-output-q]
• show mls qos input-queue
• show running-config
For more information about these commands, see the command reference for this release.

Before configuring standard QoS, you must have a thorough understanding of these items:
• The types of applications used and the traffic patterns on your network.
• Traffic characteristics and needs of your network. Is the traffic bursty? Do you need to reserve
bandwidth for voice and video streams?
• Bandwidth requirements and speed of the network.
• Location of congestion points in the network.
These sections describe how to configure standard QoS on your switch:
• Standard QoS Configuration, page 34-50
• Standard QoS Configuration Guidelines, page 34-53
• Packet Modification, page 34-55
• Enabling QoS Globally, page 34-56 (required)
• Configuring Ingress Classification by Using Port Trust States, page 34-56 (required
• Configuring an Ingress QoS Policy, page 34-63 (required)
• Configuring DSCP Maps, page 34-80 (optional, unless you need to use the
DSCP-to-DSCP-mutation map or the policed-DSCP map)
• Configuring Ingress Queue Characteristics, page 34-86 (optional)
• Configuring Egress Queue-Set Characteristics, page 34-91 (optional)
If you need to configure outbound traffic on an ES port, see the “Configuring Hierarchical QoS” section
on page 34-103.
Standard QoS Configuration

QoS is disabled. There is no concept of trusted or untrusted ports because the packets are not modified
(the CoS, DSCP, and IP precedence values in the packet are not changed). Traffic is switched in
pass-through mode (packets are switched without any rewrites and classified as best effort without any
policing).

34-50 OL-9644-10
When QoS is enabled with the mls qos global configuration command and all other QoS settings are at
their s, traffic is classified as best effort (the DSCP and CoS value is set to 0) without any policing. No
policy maps are configured. The port trust state on all ports is untrusted. The ingress queues and egress
queue-set settings are described in the “Ingress Queue Configuration” section on page 34-51 and the
“Egress Queue-Set Configuration” section on page 34-52. For traffic on an ES port, see the “Hierarchical
QoS Configuration” section on page 34-103.
Ingress Queue Configuration

Single-level input policy maps are supported on standard ports, ES ports, and SVIs. Table 34-7 shows
the ingress queue configuration when QoS is enabled.
Table 34-7 Ingress Queue Configuration
Feature Queue 1 Queue 2

Buffer allocation 90 percent 10 percent
1
Bandwidth allocation 4 4
2
Priority queue bandwidth 0 10
WTD drop threshold 1 100 percent 100 percent
WTD drop threshold 2 100 percent 100 percent
1. The bandwidth is equally shared between the queues. SRR sends packets in shared mode only.
2. Queue 2 is the priority queue. SRR services the priority queue for its configured share before servicing the
other queue.
Table 34-8 shows the CoS input queue threshold map when QoS is enabled.
Table 34-8 CoS Input Queue Threshold Map
CoS Value Queue ID–Threshold ID

0–4 1–1
5 2–1
6, 7 1–1
Table 34-9 shows the DSCP input queue threshold map when QoS is enabled.
Table 34-9 DSCP Input Queue Threshold Map
DSCP Value Queue ID–Threshold ID

0–39 1–1
40–47 2–1
48–63 1–1

OL-9644-10 34-51
Egress Queue-Set Configuration

Single-level output policy maps are supported on SVIs and ES ports. Table 34-10 shows the default
egress queue-set configuration when QoS is enabled. All ports are mapped to queue-set 1. The port
bandwidth limit is set to 100 percent, and the rate is unlimited.
Table 34-10 Egress Queue-Set Configuration
Feature Queue 1 Queue 2 Queue 3 Queue 4

Buffer allocation 25 percent 25 percent 25 percent 25 percent
WTD drop threshold 1 100 percent 200 percent 100 percent 100 percent
WTD drop threshold 2 100 percent 200 percent 100 percent 100 percent
Reserved threshold 50 percent 50 percent 50 percent 50 percent
Maximum threshold 400 percent 400 percent 400 percent 400 percent
SRR shaped weights 25 0 0 0
(absolute) 1
SRR shared weights 2 25 25 25 25
1. A shaped weight of zero means that this queue is operating in shared mode.
2. One quarter of the bandwidth is allocated to each queue.
Table 34-11 shows the CoS output queue threshold map when QoS is enabled.
Table 34-11 CoS Output Queue Threshold Map
CoS Value Queue ID–Threshold ID

0, 1 2–1
2, 3 3–1
4 4–1
5 1–1
6, 7 4–1
Table 34-12 shows the DSCP output queue threshold map when QoS is enabled.
Table 34-12 DSCP Output Queue Threshold Map
DSCP Value Queue ID–Threshold ID

0–15 2–1
16–31 3–1
32–39 4–1
40–47 1–1
48–63 4–1

34-52 OL-9644-10
Mapping Table Configuration

The CoS-to-DSCP map is shown in Table 34-13 on page 34-81.
The IP-precedence-to-DSCP map is shown in Table 34-14 on page 34-82.
The DSCP-to-CoS map is shown in Table 34-15 on page 34-84.
The DSCP-to-DSCP-mutation map is a null map, which maps an inbound DSCP value to the same DSCP
value.
The policed-DSCP map is a null map, which maps an inbound DSCP value to the same DSCP value (no
markdown).
Standard QoS Configuration Guidelines

Before beginning the QoS configuration, you should be aware of this information:
• It is not possible to match IP fragments against configured IP extended ACLs to enforce QoS. IP
fragments are sent as best-effort. IP fragments are denoted by fields in the IP header.
• Only one ACL can be configured per class map. The ACL can have multiple ACEs, which match
fields against the contents of the packet. Class maps that contain ACLs are supported only in an
ingress nonhierarchical single-level policy attached to a standard port or an SVI. You can only use
the match access-group acl-index-or-name class-map configuration command in a nonhierarchical
policy map attached to a standard port, an SVI, or an ES port. For information on hierarchical service
policies attached to the ES ports, see the “Configuring Hierarchical QoS” section on page 34-103.
• Only one policy map per port is supported. You can attach one ingress nonhierarchical service policy
per standard physical port or per SVI. You can also attach one ingress hierarchical service policy per
SVI.
• Inbound traffic is classified, policed, and marked down (if configured) regardless of whether the
traffic is bridged, routed, or sent to the CPU. Bridged frames can be dropped or have their DSCP
and CoS values modified.
• Only one ingress policer is applied to a packet on a port. Only the average-rate and committed-burst
parameters are configurable.
• You can create an aggregate policer that is shared by multiple traffic classes within the same policy
map. However, you cannot use the aggregate policer across different policy maps.
• For standard ports and ES ports, the port ASIC device supports a total of 256 policers on the switch.
Of these, 255 are user-configurable; one is reserved for internal use. The maximum number of
policers that can be configured per port is 63. For example, you could configure 32 policers on a
Gigabit Ethernet port and 8 policers on a Fast Ethernet port, or you could configure 63 policers on
a Gigabit Ethernet port and 5 policers on a Fast Ethernet port. Policers are allocated on demand by
the software and are constrained by the hardware and ASIC boundaries. You cannot reserve policers
per port; there is no guarantee that a port will be assigned to any policer. These limitations do not
apply to policers configured in a hierarchical policy attached to an ES port.
• On a port configured for QoS, all traffic received through the port is classified, policed, and marked
according to the policy map attached to the port. On a trunk port configured for QoS, traffic in all
VLANs received through the port is classified, policed, and marked according to the policy map
attached to the port.
• On releases earlier than Cisco IOS Release 12.2(35)SE, the switch does not support attaching a
standard (one-level) service policy to a logical interface (such as an EtherChannel). If you have
EtherChannel ports configured on your switch, you must configure QoS classification, policing,

OL-9644-10 34-53
mapping, and queueing on the individual physical ports that comprise the EtherChannel. Beginning
with Cisco IOS Release 12.2(35)SE, the switch supports EtherChannels made of ES ports for
single-level output policy maps and hierarchical policy maps in both directions.
• Control traffic (such as spanning-tree bridge protocol data units [BPDUs] and routing update
packets) received by the switch are subject to all ingress QoS processing.
• You are likely to lose data when you change queue settings; therefore, try to make changes when
traffic is at a minimum.
• Follow these guidelines when the egress priority queue is enabled on a port; otherwise, the egress
queues are serviced based on their SRR weights:
– If the egress priority queue is enabled, it overrides the SRR shaped and shared weights for
queue 1.
– If the egress priority queue is disabled and the SRR shaped and shared weights are configured,
the shaped mode overrides the shared mode for queue 1, and SRR services this queue in shaped
mode.
– If the egress priority queue is disabled and the SRR shaped weights are not configured, SRR
services this queue in shared mode.
• In Cisco IOS Release 12.2(44)SE or later, if the mls qos global configuration command is disabled
and you do not explicitly configure the cpu traffic qos global configuration command, the switch
uses the default behavior. The default is no marking for CPU-generated traffic and all packets
queued to queue 1.
• In Cisco IOS Release 12.2(25)EY or later, follow these guidelines when configuring policy maps on
physical ports or SVIs:
– You cannot apply the same policy map to a physical port and to an SVI.
– If VLAN-based QoS is configured on a physical port, the switch removes all the port-based
policy maps on the port. The traffic on this physical port is now affected by the policy map
attached to the SVI to which the physical port belongs.
– In a dual-level policy map attached to an SVI, you can only configure an individual policer at
the interface level on a physical port to specify the bandwidth limits for the traffic on the port.
The ingress port must be configured as a trunk or as a static-access port. You cannot configure
policers at the VLAN level of the dual-level policy map.
– The switch does not support aggregate policers in dual-level policy maps.
– After the dual-level policy map is attached to an SVI, the interface-level policy map cannot be
modified or removed from the dual-level policy map. A new interface-level policy map also
cannot be added to the dual-level policy map. You also cannot add or remove a class map
specified in the dual-level policy map. If you want these changes to occur, the hierarchical
policy map must first be removed from the SVI.
For outbound traffic on an ES port, see the “Hierarchical QoS Configuration Guidelines” section on
page 34-104.

34-54 OL-9644-10
Packet Modification
A packet is classified, policed, and queued to provide QoS. Packet modifications can occur during this
process:
• For IP and non-IP packets, ingress classification involves assigning a QoS label to a packet based
on the DSCP or CoS of the received packet. However, the packet is not modified at this stage; only
an indication of the assigned DSCP or CoS value is carried along. The reason for this is that QoS
classification and forwarding lookups occur in parallel, and it is possible that the packet is forwarded
with its original DSCP to the CPU where it is again processed through software.
When the ES ports classify traffic at egress, this classification can be used for queuing or for
marking the CoS, DSCP, IP precedence, or MPLS EXP bits. Any packet modifications that result
from ingress classification are applied before the packet reaches the egress classification stage. For
example, if the switch receives traffic with a CoS value of 2 and an ingress action resets the CoS to
4, the packet will have a CoS of 4 (instead of a CoS of 2 and an indicator that the CoS should be set
to 4) when it moves to the egress classification stage.
• During ingress policing, IP and non-IP packets can have another DSCP assigned to them (if they are
out of profile and the policer specifies a markdown DSCP). Once again, the DSCP in the packet is
not modified, but an indication of the marked-down value is carried along. For IP packets, the packet
modification occurs at a later stage; for non-IP packets the DSCP is converted to CoS and used for
queueing and scheduling decisions.
During egress policing on the ES ports, marking actions can set the CoS, DSCP, IP precedence, or
the MPLS EXP bits. Any markings performed by an ingress policer are applied before the packet
reaches the egress classification stage.
• Depending on the QoS label assigned to a frame and the mutation chosen, the DSCP and CoS values
of the frame are rewritten. If you do not configure the mutation map and if you configure the port to
trust the DSCP of the inbound frame, the DSCP value in the frame is not changed, but the CoS is
rewritten according to the DSCP-to-CoS map. If you configure the port to trust the CoS of the
inbound frame and it is an IP packet, the CoS value in the frame is not changed, but the DSCP might
be changed according to the CoS-to-DSCP map.
The input mutation causes the DSCP to be rewritten depending on the new value of DSCP chosen.
The set action in a policy map also causes the DSCP to be rewritten.
This information applies to both standard and ES ports. On the ES ports, the switch also applies trust
policies to IEEE 802.1Q tunneling frames at egress.
• If you apply an ingress hierarchical policy to an ES port, packets can be queued, dropped, and
changed because of the marking process that occurs before the standard ingress actions.

OL-9644-10 34-55
Enabling QoS Globally

By default, QoS is disabled on the switch.
Beginning in privileged EXEC mode, follow these steps to enable QoS. This procedure is required.
Command Purpose
Step 2 mls qos Enable QoS globally.
QoS runs from the settings described in the “Standard QoS
Configuration” section on page 34-50 and the “Hierarchical
QoS Configuration” section on page 34-103.
Step 4 show mls qos Verify your entries.
Step 5 copy running-config startup-config (Optional) Save your entries in the configuration file.
To disable QoS, use the no mls qos global configuration command.
Configuring Ingress Classification by Using Port Trust States

These sections describe how to classify inbound traffic through port trust states. Depending on your
network configuration, you must perform one or more of these tasks or one or more of the tasks in the
“Configuring an Ingress QoS Policy” section on page 34-63:
• Configuring the Trust State on Ports Within the QoS Domain, page 34-56
• Configuring the CoS Value for an Interface, page 34-59
• Configuring a Trusted Boundary to Ensure Port Security, page 34-60
• Enabling DSCP Transparency Mode, page 34-61
• Configuring the DSCP Trust State on a Port Bordering Another QoS Domain, page 34-61
Configuring the Trust State on Ports Within the QoS Domain

Packets entering a QoS domain are classified at the edge of the QoS domain. The switch port within the
QoS domain can then be configured to one of the trusted states because there is no need to classify the
packets at every switch within the domain. Figure 34-14 shows a sample network topology.

34-56 OL-9644-10
Figure 34-14 Port Trusted States Within the QoS Domain
Trusted interface
Trunk
Traffic classification
performed here
P3 P1
101236
IP
Trusted boundary
Beginning in privileged EXEC mode, follow these steps to configure the port to trust the classification
of the traffic that it receives:
Command Purpose
Step 2 interface interface-id Specify the port to be trusted, and enter interface configuration mode.
Valid interfaces include physical ports.

OL-9644-10 34-57
Command Purpose
Step 3 mls qos trust [cos | dscp | Configure the port trust state.
ip-precedence]
By default, the port is not trusted. If no keyword is specified, the default is dscp.
For 802.1Q tunnels, the switch processes inbound traffic on a standard port
according to the trusted setting applied to this port. The switch configures the
inner and outer tags for packets sent over the ES trunk port.
• cos—Classifies an ingress packet by using the packet CoS value. For an
untagged packet, the port CoS value is used. The port CoS value is 0.
For IEEE 802.1Q tunnels, the switch copies the inner CoS value to the
outer CoS value and sends the packet out an ES port.
• dscp—Classifies an ingress packet by using the packet DSCP value if the
packet is an IP packet. For a non-IP packet, the packet CoS value is used if
the packet is tagged; for an untagged packet, the port CoS is used.
Internally, the switch maps the CoS value to a DSCP value by using the
CoS-to-DSCP map.
For IEEE 802.1Q tunnels, for a non-IP packet that is untagged, the switch
configures the outer CoS value from the DSCP-to-CoS map, does not
modify the inner CoS value, and sends the packet out an ES port. For an IP
packet, the switch modifies the DSCP value in the packet if there is a
DSCP-to-DSCP mutation map configured on the standard port. The switch
uses the mutated DSCP value to configure the outer CoS value from the
DSCP-to-CoS map and sends the packet out an ES port.
• ip-precedence—Classifies an ingress packet by using the packet
IP-precedence value. For a non-IP packet, the packet CoS value is used if
the packet is tagged; for an untagged packet, the port CoS is used.
Internally, the switch maps the CoS value to a DSCP value through the
CoS-to-DSCP map.
For 802.1Q tunnels, the switch converts the generated DSCP value from the
DSCP-to-CoS map and uses it as the outer CoS value in the packet. The
switch does not modify the inner CoS value in the packet and sends the
packet out an ES port.
Note When port trust policies are used with IEEE 802.1Q tunneling, all ports
sharing the same tunnel VLAN must be configured with the same trust
policy, and the ports involved must use the same DSCP-to-DSCP
mutation map. For more information, see the “Configuring the
DSCP-to-DSCP-Mutation Map” section on page 34-85.
Step 5 show mls qos interface Verify your entries.
Step 6 copy running-config (Optional) Save your entries in the configuration file.
startup-config
To return a port to its untrusted state, use the no mls qos trust interface configuration command.
For information on how to change the CoS value, see the “Configuring the CoS Value for an Interface”
section on page 34-59. For information on how to configure the CoS-to-DSCP map, see the “Configuring
the CoS-to-DSCP Map” section on page 34-81.

34-58 OL-9644-10
Configuring the CoS Value for an Interface

QoS assigns the CoS value specified with the mls qos cos interface configuration command to untagged
frames received on trusted and untrusted ports.
Beginning in privileged EXEC mode, follow these steps to define the CoS value of a port or to assign
the CoS to all inbound packets on the port:
Command Purpose
Step 2 interface interface-id Specify the port to be configured, and enter interface configuration mode.
Step 3 mls qos cos {-cos | override} Configure the default CoS value for the port.
For IEEE 802.1Q tunnels, the switch processes inbound traffic on a standard
port according to the trusted setting applied to this port. The switch
configures the inner and outer tags for packets sent over the ES trunk port.
• For -cos, specify a CoS value to be assigned to a port. If the packet is
untagged, the CoS value becomes the packet CoS value. The CoS range
is 0 to 7. The default is 0.
• Use the override keyword to override the previously configured trust
state of the inbound packet and to apply the port CoS value to the port
on all inbound packets. By default, CoS override is disabled.
Use the override keyword when all inbound packets on specified ports
deserve higher or lower priority than packets entering from other ports.
Even if a port was previously set to trust DSCP, CoS, or IP precedence,
this command overrides the previously configured trust state, and all
the inbound CoS values are assigned the CoS value configured with this
command. If an inbound packet is tagged, the CoS value of the packet
is modified with the default CoS of the port at the ingress port.
When an incoming packet is received on an interface acting as an IEEE
802.1Q tunnel and is sent out an ES port, the switch modifies the outer
CoS value and does not modify the inner CoS value.
To return to the default setting, use the no mls qos cos {-cos | override} interface configuration
command.

OL-9644-10 34-59
Configuring a Trusted Boundary to Ensure Port Security

In a typical network, you connect a Cisco IP Phone to a switch port, as shown in Figure 34-14 on
page 34-57, and cascade devices that generate data packets from the back of the telephone. The Cisco IP
Phone guarantees the voice quality through a shared data link by marking the CoS level of the voice
packets as high priority (CoS = 5) and by marking the data packets as low priority (CoS = 0). Traffic sent
from the telephone to the switch is typically marked with a tag that uses the 802.1Q header. The header
contains the VLAN information and the CoS 3-bit field, which is the priority of the packet.
For most Cisco IP Phone configurations, the traffic sent from the telephone to the switch should be
trusted to ensure that voice traffic is properly prioritized over other types of traffic in the network. By
using the mls qos trust cos interface configuration command, you configure the switch port to which
the telephone is connected to trust the CoS labels of all traffic received on that port.
With the trusted setting, you also can use the trusted boundary feature to prevent misuse of a
high-priority queue if a user bypasses the telephone and connects the PC directly to the switch. Without
trusted boundary, the CoS labels generated by the PC are trusted by the switch (because of the trusted
CoS setting). By contrast, trusted boundary uses CDP to detect the presence of a Cisco IP Phone (such
as the Cisco IP Phone 7910, 7935, 7940, and 7960) on a switch port. If the telephone is not detected, the
trusted boundary feature disables the trusted setting on the switch port and prevents misuse of a
high-priority queue. Note that the trusted boundary feature is not effective if the PC and Cisco IP Phone
are connected to a hub that is connected to the switch.
In some situations, you can prevent a PC connected to the IP phone from taking advantage of a
high-priority data queue. You can use the switchport priority extend cos interface configuration
command to configure the telephone through the switch CLI to override the priority of the traffic
received from the PC.
Beginning in privileged EXEC mode, follow these steps to enable trusted boundary on a port:
Command Purpose
Step 2 cdp run Enable CDP globally. By default, CDP is enabled.
Step 3 interface interface-id Specify the port connected to the IP phone, and enter interface configuration
mode.
Step 4 cdp enable Enable CDP on the port. By default, CDP is enabled.
Step 5 mls qos trust cos Configure the port to trust the CoS value in traffic received from the Cisco
IP Phone. By default, the port is not trusted.
Step 6 mls qos trust device cisco-phone Specify that the Cisco IP Phone is a trusted device.
You cannot enable both trusted boundary and auto-QoS (auto qos voip
interface configuration command) at the same time; they are mutually
exclusive.
To disable the trusted boundary feature, use the no mls qos trust device interface configuration
command.

34-60 OL-9644-10
Enabling DSCP Transparency Mode

In software releases earlier than Cisco IOS Release 12.1(14)AX2, if QoS is disabled, the DSCP value of
the incoming IP packet is not modified. If QoS is enabled and you configure the interface to trust DSCP,
the switch does not modify the DSCP value. If you configure the interface to trust CoS, the switch
modifies the DSCP value according to the CoS-to-DSCP map.
In Cisco IOS Release 12.1(14)AX2 or later, the switch supports the DSCP transparency feature. It affects
only the DSCP field of a packet at egress. By default, DSCP transparency is disabled. The switch
modifies the DSCP field in an incoming packet, and the DSCP field in the outgoing packet is based on
the quality of service (QoS) configuration, including the port trust setting, policing and marking, and the
DSCP-to-DSCP mutation map.
If DSCP transparency is enabled by using the no mls qos rewrite ip dscp command, the switch does not
modify the DSCP field in the incoming packet, and the DSCP field in the outgoing packet is the same as
that in the incoming packet.
Regardless of the DSCP transparency configuration, the switch modifies the internal DSCP value of the
packet, which the switch uses to generate a class of service (CoS) value that represents the priority of
the traffic. The switch also uses the internal DSCP value to select an egress queue and threshold.
On an ES port, if an action in an egress policy map modifies the DSCP value of the packet and the policy
map is applied to the ES port, the switch modifies the DSCP value regardless of the DSCP transparency
configuration.
Beginning in privileged EXEC mode, follow these steps to enable DSCP transparency on a switch:
Command Purpose
Step 2 mls qos Enable QoS globally.
Step 3 no mls qos rewrite ip dscp Enable DSCP transparency. The switch is configured to not modify the
DSCP field of the IP packet.
Step 5 show mls qos interface [interface-id] Verify your entries.
To configure the switch to modify the DSCP value based on the trust setting or on an ACL by disabling
DSCP transparency, use the mls qos rewrite ip dscp global configuration command.
If you disable QoS by using the no mls qos global configuration command, the CoS and DSCP values
are not changed (the default QoS setting).
If you enter the no mls qos rewrite ip dscp global configuration command to enable DSCP transparency
and then enter the mls qos trust [cos | dscp] interface configuration command, DSCP transparency is
still enabled.
Configuring the DSCP Trust State on a Port Bordering Another QoS Domain
If you are administering two separate QoS domains between which you want to implement QoS features
for IP traffic, you can configure the switch ports bordering the domains to a DSCP-trusted state as shown
in Figure 34-15. Then the receiving port accepts the DSCP-trusted value and avoids the classification

OL-9644-10 34-61
stage of QoS. If the two domains use different DSCP values, you can configure the
DSCP-to-DSCP-mutation map to translate a set of DSCP values to match the definition in the other
domain.
Figure 34-15 DSCP-Trusted State on a Port Bordering Another QoS Domain
QoS Domain 1 QoS Domain 2
IP traffic
101235
Set interface to the DSCP-trusted state.
Configure the DSCP-to-DSCP-mutation map.
Beginning in privileged EXEC mode, follow these steps to configure the DSCP-trusted state on a port
and modify the DSCP-to-DSCP-mutation map. To ensure a consistent mapping strategy across both QoS
domains, you must perform this procedure on the ports in both domains:
Command Purpose
Step 2 mls qos map dscp-mutation Modify the DSCP-to-DSCP-mutation map.
dscp-mutation-name in-dscp to out-dscp
The DSCP-to-DSCP-mutation map is a null map, which maps an
inbound DSCP value to the same DSCP value.
• For dscp-mutation-name, enter the mutation map name. You can
create more than one map by specifying a new name.
• For in-dscp, enter up to eight DSCP values separated by spaces.
Then enter the to keyword.
• For out-dscp, enter a single DSCP value.
The DSCP range is 0 to 63.
Step 3 interface interface-id Specify the port to be trusted, and enter interface configuration mode.
Step 4 mls qos trust dscp Configure the ingress port as a DSCP-trusted port. By default, the port
is not trusted.
Step 5 mls qos dscp-mutation Apply the map to the specified ingress DSCP-trusted port.
dscp-mutation-name
For dscp-mutation-name, specify the mutation map name created in
Step 2.
You can configure multiple DSCP-to-DSCP-mutation maps on an
ingress port.

34-62 OL-9644-10
Command Purpose
Step 7 show mls qos maps dscp-mutation Verify your entries.
To return a port to its nontrusted state, use the no mls qos trust interface configuration command. To
return to the default DSCP-to-DSCP-mutation map values, use the no mls qos map dscp-mutation
dscp-mutation-name global configuration command.
This example shows how to configure a port to the DSCP-trusted state and to modify the
DSCP-to-DSCP-mutation map (named gi1/1/1-mutation) so that inbound DSCP values 10 to 13 are
mapped to DSCP 30:
Switch(config)# mls qos map dscp-mutation gi1/1/1-mutation 10 11 12 13 to 30
Switch(config-if)# mls qos trust dscp
Switch(config-if)# mls qos dscp-mutation gi1/1/1-mutation
Switch(config-if)# end
Configuring an Ingress QoS Policy

Configuring an ingress QoS policy typically requires classifying traffic into classes, configuring policies
applied to those traffic classes, and attaching the policies to a port.
For background information, see the “Ingress Classification” section on page 34-9 and the “Ingress
Policing and Marking” section on page 34-13. For configuration guidelines, see the “Standard QoS
Configuration Guidelines” section on page 34-53.
These sections describe how to classify, police, and mark inbound traffic. Depending on your network
configuration, you must perform one or more of these tasks:
• Classifying Ingress Traffic by Using ACLs, page 34-63
• Classifying Ingress Traffic by Using Class Maps, page 34-67
• Classifying, Policing, and Marking Ingress Traffic by Using Nonhierarchical Single-Level Policy
Maps, page 34-69
• Classifying, Policing, and Marking Ingress Traffic by Using Aggregate Policers, page 34-79
For information on configuring policies for the ES ports, see the “Configuring a Hierarchical QoS
Policy” section on page 34-107. This section describes how to classify traffic by using class maps, how
to configure a two-rate traffic policer, how to configure class-based packet marking in a traffic policy,
how to configure CBWFQ, tail drop, DSCP-based WRED, and IP precedence-based WRED, how to
enable LLQ, and how to configure shaping.
Classifying Ingress Traffic by Using ACLs

You can classify ingress IP traffic by using IP standard or IP extended ACLs. You also can classify
ingress non-IP traffic by using Layer 2 MAC ACLs.

OL-9644-10 34-63
Beginning in privileged EXEC mode, follow these steps to create an IP standard ACL for inbound IP
traffic:
Command Purpose
Step 2 access-list access-list-number {deny | Create an IP standard ACL, repeating the command as many times as
permit} source [source-wildcard] necessary.
• For access-list-number, enter the access list number. The range is
1 to 99 and 1300 to 1999.
• Use the permit keyword to permit a certain type of traffic if the
conditions are matched. Use the deny keyword to deny a certain
type of traffic if conditions are matched.
• For source, enter the network or host from which the packet is
being sent. You can use the any keyword as an abbreviation for
0.0.0.0 255.255.255.255.
• (Optional) For source-wildcard, enter the wildcard bits in dotted
decimal notation to be applied to the source. Place ones in the bit
positions that you want to ignore.
Note When creating an access list, remember that, by default, the end
of the access list contains an implicit deny statement for
everything if it did not find a match before reaching the end.
Step 4 show access-lists Verify your entries.
To delete an access list, use the no access-list access-list-number global configuration command.
This example shows how to allow access for only those hosts on the three specified networks. The
wildcard bits apply to the host portions of the network addresses. Any host with a source address that
does not match the access list statements is rejected.
Switch(config)# access-list 1 permit 192.5.255.0 0.0.0.255
! (Note: all other access implicitly denied)

34-64 OL-9644-10
Beginning in privileged EXEC mode, follow these steps to create an IP extended ACL for inbound IP
traffic:
Command Purpose
Step 2 access-list access-list-number {deny | Create an IP extended ACL, repeating the command as many times as
permit} protocol source source-wildcard necessary.
destination destination-wildcard
• For access-list-number, enter the access list number. The range is
100 to 199 and 2000 to 2699.
• Use the permit keyword to permit a certain type of traffic if the
conditions are matched. Use the deny keyword to deny a certain
type of traffic if conditions are matched.
• For protocol, enter the name or number of an IP protocol. Use the
question mark (?) to see a list of available protocol keywords.
• For source, enter the network or host from which the packet is
being sent. You specify this by using dotted decimal notation, by
using the any keyword as an abbreviation for source 0.0.0.0
source-wildcard 255.255.255.255, or by using the host keyword
for source 0.0.0.0.
• For source-wildcard, enter the wildcard bits by placing ones in the
bit positions that you want to ignore. You specify the wildcard by
using dotted decimal notation, by using the any keyword as an
abbreviation for source 0.0.0.0 source-wildcard 255.255.255.255,
or by using the host keyword for source 0.0.0.0.
• For destination, enter the network or host to which the packet is
being sent. You have the same options for specifying the
destination and destination-wildcard as those described by source
and source-wildcard.
Note When creating an access list, remember that, by default, the end
of the access list contains an implicit deny statement for
To delete an access list, use the no access-list access-list-number global configuration command.
This example shows how to create an ACL that permits IP traffic from any source to any destination that
has the DSCP value set to 32:
Switch(config)# access-list 100 permit ip any any dscp 32
This example shows how to create an ACL that permits IP traffic from a source host at 10.1.1.1 to a
destination host at 10.1.1.2 with a precedence value of 5:
Switch(config)# access-list 100 permit ip host 10.1.1.1 host 10.1.1.2 precedence 5

OL-9644-10 34-65
This example shows how to create an ACL that permits PIM traffic from any source to a destination
group address of 224.0.0.2 with a DSCP set to 32:
Switch(config)# access-list 102 permit pim any 224.0.0.2 dscp 32
Beginning in privileged EXEC mode, follow these steps to create a Layer 2 MAC ACL for inbound
non-IP traffic:
Command Purpose
Step 2 mac access-list extended name Create a Layer 2 MAC ACL by specifying the name of the list. When you
enter this command, the mode changes to extended MAC ACL configuration.
Step 3 {permit | deny} {host Specify the type of traffic to permit or deny if the conditions are matched,
src-MAC-addr mask | any | host entering the command as many times as necessary.
dst-MAC-addr | dst-MAC-addr
• For src-MAC-addr, enter the MAC address of the host from which the
mask} [type mask]
packet is being sent. You specify this by using the hexadecimal format
(H.H.H), by using the any keyword as an abbreviation for source 0.0.0,
source-wildcard ffff.ffff.ffff, or by using the host keyword for source
0.0.0.
• For mask, enter the wildcard bits by placing ones in the bit positions that
you want to ignore.
• For dst-MAC-addr, enter the MAC address of the host to which the packet
is being sent. You specify this by using the hexadecimal format (H.H.H),
by using the any keyword as an abbreviation for source 0.0.0, source-
wildcard ffff.ffff.ffff, or by using the host keyword for source 0.0.0.
• (Optional) For type mask, specify the Ethertype number of a packet with
Ethernet II or SNAP encapsulation to identify the protocol of the packet.
For type, the range is from 0 to 65535, typically specified in hexadecimal.
For mask, enter the don’t care bits applied to the Ethertype before testing
for a match.
Note When creating an access list, remember that, by default, the end of the
access list contains an implicit deny statement for everything if it did
not find a match before reaching the end.
[access-list-number |
access-list-name]
Step 6 copy running-config (Optional) Save your entries in the configuration file.
startup-config
To delete an access list, use the no mac access-list extended access-list-name global configuration
command.
This example shows how to create a Layer 2 MAC ACL with two permit statements. The first statement
allows traffic from the host with MAC address 0001.0000.0001 to the host with MAC
address 0002.0000.0001. The second statement allows only Ethertype XNS-IDP traffic from the host
with MAC address 0001.0000.0002 to the host with MAC address 0002.0000.0002.
Switch(config)# mac access-list extended maclist1
Switch(config-ext-macl)# permit 0001.0000.0001 0.0.0 0002.0000.0001 0.0.0
Switch(config-ext-macl)# permit 0001.0000.0002 0.0.0 0002.0000.0002 0.0.0 xns-idp
! (Note: all other access implicitly denied)

34-66 OL-9644-10
Classifying Ingress Traffic by Using Class Maps

You use the class-map global configuration command to create a class map for matching packets to the
class whose name you specify. The class map isolates a specific ingress traffic flow (class) from all other
traffic by defining the criteria to use to match against a specific flow. A match criterion is defined with
a match statement entered within the class-map configuration mode. Packets are compared to the match
criteria configured for a class map. If a packet matches the specified criteria, the packet is considered a
member of the class and is forwarded according to the QoS specifications set in the traffic policy.
For information on how to classify traffic on an ES port, see the “Classifying Traffic by Using
Hierarchical Class Maps” section on page 34-108.
Beginning in privileged EXEC mode, follow these steps to create a class map and to define the match
criterion to classify inbound traffic:
Command Purpose
Step 2 access-list access-list-number {deny | Create an IP standard or extended ACL for IP traffic or a Layer 2 MAC
permit} source [source-wildcard] ACL for non-IP traffic, repeating the command as many times as
necessary.
or
For more information, see the “Classifying Ingress Traffic by Using
access-list access-list-number {deny |
ACLs” section on page 34-63.
permit} protocol source [source-wildcard]
destination [destination-wildcard] Note When creating an access list, remember that, by default, the
or end of the access list contains an implicit deny statement for
mac access-list extended name
{permit | deny} {host src-MAC-addr mask
| any | host dst-MAC-addr | dst-MAC-addr
mask} [type mask]
Step 3 class-map [match-all | match-any] Create a class map, and enter class-map configuration mode.
class-map-name
By default, no class maps are defined.
• (Optional) Use the match-all keyword to perform a logical-AND
of all matching statements under this class map. All criteria in the
class map must be matched.
• (Optional) Use the match-any keyword to perform a logical-OR
of all matching statements under this class map. One or more
criteria must be matched.
• For class-map-name, specify the name of the class map.
If neither the match-all nor the match-any keyword is specified, the
default is match-all.
Note Because only one match command per class map is supported,
the match-all and match-any keywords function the same.

OL-9644-10 34-67
Command Purpose
Step 4 match {access-group acl-index-or-name | Define the match criterion to classify traffic.
ip dscp dscp-list | ip precedence
By default, no match criterion is defined.
ip-precedence-list}
Only one ACL per class map is supported.
• For access-group acl-index-or-name, specify the number or name
of the ACL created in Step 2.
• For ip dscp dscp-list, enter a list of up to eight IP DSCP values to
match against inbound packets. Separate each value with a space.
The range is 0 to 63.
• For ip precedence ip-precedence-list, enter a list of up to eight
IP-precedence values to match against inbound packets. Separate
each value with a space. The range is 0 to 7.
Step 6 show class-map Verify your entries.
To delete an existing class map, use the no class-map [match-all | match-any] class-map-name global
configuration command. To remove a match criterion, use the no match {access-group
acl-index-or-name | ip dscp | ip precedence} class-map configuration command.
This example shows how to configure the class map called class1. The class1 has one match criterion,
which is access list 103. It permits traffic from any host to any destination that matches a DSCP value
of 10.
Switch(config)# access-list 103 permit ip any any dscp 10
Switch(config)# class-map class1
Switch(config-cmap)# match access-group 103
This example shows how to create a class map called class2, which matches inbound traffic with DSCP
values of 10, 11, and 12:
Switch(config-cmap)# match ip dscp 10 11 12
This example shows how to create a class map called class3, which matches inbound traffic with
IP-precedence values of 5, 6, and 7:
Switch(config-cmap)# match ip precedence 5 6 7
Marking and Queuing CPU-Generated Traffic

You can mark and queue the control plane traffic that the CPU generates by entering the cpu traffic qos [cos
value | dscp value | precedence value] and mls qos srr-queue output cpu queue id threshold id global
configuration commands. You can use these commands to mark a CPU-generated control plane packet with
a value and to map the traffic to any of the four egress queues.
Use the cpu traffic qos global configuration command to mark the control plane traffic with a CoS,
DSCP, or IP precendence value. When you configure the cpu traffic qos marking for Ethernet or IP
traffic, the control plane traffic that the CPU generates is marked with the values that you specify. All

34-68 OL-9644-10
control-plane traffic is marked with these values except for Connectivity Fault Management (CFM) traffic.
Cisco IOS IP Service Level Agreements (SLAs) traffic that uses the CFM layer for transacting the messages
is not affected. However, IP SLAs traffic that uses UDP or other networking layer protocols is affected by this
feature.
To use the cpu traffic qos feature, you must globally enable the mls qos global configuration command
on the switch. You can also mark native VLAN traffic and tag it by entering the vlan dot1q tag native
Use the mls qos srr-queue output cpu-queue global configuration command to specify an egress queue
and a threshold value for CPU-generated traffic. The default egress queue value is 2. You can assign each
packet that flows through the switch to a queue and to a threshold. Specifically, you map DSCP or CoS
values to an egress queue-set and map DSCP or CoS values to a threshold ID. You use the mls qos
srr-queue output dscp-map queue queue-id {dscp1...dscp8 | threshold threshold-iddscp1...dscp8} or
the mls qos srr-queue output cos-map queue queue-id {cos1...cos8 | thresholdthreshold-id
cos1...cos8} global configuration command.
Classifying, Policing, and Marking Ingress Traffic by Using Nonhierarchical Single-Level Policy
Maps
On a physical port, a nonhierarchical single-level policy map specifies which inbound traffic class to act
on. You can specify which CoS, DSCP, or IP precedence values in the traffic class to trust. You can
specify which DSCP or IP precedence values in the traffic class to set. You can specify the traffic
bandwidth limitations for each matched traffic class (policer) and the action to take when the traffic is
out of profile (marking).
A policy map also has these characteristics:
• A policy map can contain multiple class statements, each with different match criteria and policers.
• A policy map can contain a predefined default traffic class explicitly placed at the end of the map.
• A separate policy-map class can exist for each type of traffic received through a port.
• A policy-map trust state and a port trust state are mutually exclusive. The last one configured takes
effect.
Follow these guidelines when configuring single-level policy maps:
• You can attach only one policy map per ingress port.
• If you configure the IP-precedence-to-DSCP map by using the mls qos map ip-prec-dscp
dscp1...dscp8 global configuration command, the settings only affect packets on ingress interfaces
that are configured to trust the IP precedence value. In a policy map, if you set the packet IP
precedence value to a new value by using the set precedence new-precedence policy-map class
configuration command, the egress DSCP value is not affected by the IP-precedence-to-DSCP map.
If you want the egress DSCP value to be different than the ingress value, use the set dscp new-dscp
• When you configure a default traffic class by using the class class-default policy-map configuration
command, unclassified traffic (traffic that does not meet the match criteria specified in the traffic
classes) is treated as the default traffic class (class-default).
Before beginning this procedure, make sure that you have created the class map to isolate traffic. For
more information, see the “Classifying Ingress Traffic by Using ACLs” section on page 34-63 and the
“Classifying Ingress Traffic by Using Class Maps” section on page 34-67.
For information about configuring a policy map for an ES port, see the “Configuring a Hierarchical
Two-Rate Traffic Policer” section on page 34-110 and the “Configuring Class-Based Packet Marking in
a Hierarchical Traffic Policy” section on page 34-114.

OL-9644-10 34-69
Beginning in privileged EXEC mode, follow these steps to create an ingress single-level policy map:
Command Purpose
Step 2 policy-map policy-map-name Create a policy map by entering the policy-map name, and enter
policy-map configuration mode.
By default, no policy maps are defined.
The behavior of a policy map is to set the DSCP to 0 if the packet is an
IP packet and to set the CoS to 0 if the packet is tagged. No policing is
performed.
Step 3 class [class-map-name | class-default] Defines a traffic classification, and enter policy-map class
configuration mode.
By default, no policy map class-maps are defined.
If a traffic class has already been defined by using the class-map global
configuration command, specify its name for class-map-name in this
command.
A class-default traffic class is pre-defined and can be added to any
policy. It is always placed at the end of a policy map. With an implied
match any included in the class-default class, all packets that have not
already matched the other traffic classes will match class-default.
Step 4 trust [cos | dscp | ip-precedence] Configure the trust state, which QoS uses to generate a CoS-based or
DSCP-based QoS label.
By default, the port is not trusted. If no keyword is specified when the
command is entered, the default is dscp.
• cos—QoS derives the DSCP value by using the received or port
CoS value and the CoS-to-DSCP map.
• dscp—QoS derives the DSCP value by using the DSCP value from
the ingress packet. For non-IP packets that are tagged, QoS derives
the DSCP value by using the received CoS value; for non-IP
packets that are untagged, QoS derives the DSCP value by using
the port CoS value. In either case, the DSCP value is derived from
the CoS-to-DSCP map.
• ip-precedence—QoS derives the DSCP value by using the IP
precedence value from the ingress packet and the
IP-precedence-to-DSCP map. For non-IP packets that are tagged,
QoS derives the DSCP value by using the received CoS value; for
non-IP packets that are untagged, QoS derives the DSCP value by
using the port CoS value. In either case, the DSCP value is derived
from the CoS-to-DSCP map.
For more information, see the “Configuring the CoS-to-DSCP Map”

34-70 OL-9644-10
Command Purpose
Step 5 set {dscp new-dscp | precedence Mark IP traffic by setting a new value in the packet:
new-precedence}
• For dscp new-dscp, enter a new DSCP value to be assigned to the
classified traffic. The range is 0 to 63.
• For precedence new-precedence, enter a new IP-precedence value
to be assigned to the classified traffic. The range is 0 to 7.
Note The set dscp new-dscp and the set precedence new-precedence
commands are the same as the set ip dscp new-dscp and the set
ip precedence new-precedence commands.
Step 6 police rate-bps burst-byte [exceed-action Define a policer for the classified traffic.
{drop | policed-dscp-transmit}]
By default, no policer is defined. For information on the number of
policers supported, see the “Standard QoS Configuration Guidelines”
• For rate-bps, specify average traffic rate in bps. The range is 8000
to 1000000000.
• For burst-byte, specify the normal burst size in bytes. The range is
8000 to 1000000.
• (Optional) Specify the action to take when the rates are exceeded.
Use the exceed-action drop keywords to drop the packet. Use the
exceed-action policed-dscp-transmit keywords to mark down the
DSCP value (through the policed-DSCP map) and send the packet.
For more information, see the “Configuring the Policed-DSCP
Map” section on page 34-83.
Step 7 exit Return to policy-map configuration mode.
Step 9 interface interface-id Specify the port to attach to the policy map, and enter interface
configuration mode.
Step 10 service-policy input policy-map-name Specify the ingress policy-map name, and apply it to a port.
Step 12 show policy-map [policy-map-name [class Verify your entries.
class-map-name]]
To delete an existing policy map, use the no policy-map policy-map-name global configuration
command. To delete an existing class, use the no class class-name policy-map configuration command.
To return to the default untrusted state, use the no trust policy-map class configuration command. To
remove an assigned DSCP or IP precedence value, use the no set {dscp new-dscp | precedence
new-precedence} policy-map class configuration command. To remove an existing policer, use the no
police rate-bps burst-byte [exceed-action {drop | policed-dscp-transmit}] policy-map class
configuration command. To remove the policy map and interface association, use the no service-policy
input policy-map-name interface configuration command.

OL-9644-10 34-71
This example shows how to create an ingress policy map and attach it to a port. In the configuration, the
IP standard ACL permits traffic from network 10.1.0.0. For traffic matching this classification, the DSCP
value in the inbound packet is trusted. If the matched traffic exceeds an average traffic rate of 48000 bps
and a normal burst size of 8000 bytes, its DSCP is marked down (based on the policed-DSCP map) and
sent.
Switch(config)# class-map ipclass1
Switch(config)# policy-map flow1t
Switch(config-pmap)# class ipclass1
Switch(config-pmap-c)# trust dscp
Switch(config-pmap-c)# police 48000 8000 exceed-action policed-dscp-transmit
Switch(config-if)# service-policy input flow1t
This example shows how to create a Layer 2 MAC ACL with two permit statements and attach it to a
port. The first permit statement allows traffic from the host with MAC address 0001.0000.0001 destined
for the host with MAC address 0002.0000.0001. The second permit statement allows only Ethertype
XNS-IDP traffic from the host with MAC address 0001.0000.0002 destined for the host with MAC
address 0002.0000.0002.
Switch(config-ext-mac)# permit 0001.0000.0001 0.0.0 0002.0000.0001 0.0.0
Switch(config-ext-mac)# permit 0001.0000.0002 0.0.0 0002.0000.0002 0.0.0 xns-idp
Switch(config-ext-mac)# exit
Switch(config-ext-mac)# permit 0001.0000.0003 0.0.0 0002.0000.0003 0.0.0
Switch(config-ext-mac)# permit 0001.0000.0004 0.0.0 0002.0000.0004 0.0.0 aarp
Switch(config-ext-mac)# exit
Switch(config)# class-map macclass1
Switch(config-cmap)# match access-group maclist1
Switch(config)# policy-map macpolicy1
Switch(config-pmap)# class macclass1
Switch(config-pmap-c)# set dscp 63
Switch(config-pmap)# class macclass2 maclist2
Switch(config-if)# mls qos trust cos
Switch(config-if)# service-policy input macpolicy1
This example shows how to create a class map that applies to both IPv4 and IPv6 traffic with the default
class applied to unclassified traffic:
Switch(config)# ip access-list 101 permit ip any any
Switch(config)# ipv6 access-list ipv6-any permit ip any any
Switch(config)# class-map cm-1
Switch(config)# class-map cm-2
Switch(config-cmap)# match access-group name ipv6-any
Switch(config)# policy-map pm1
Switch(config-pmap)# class cm-1

34-72 OL-9644-10

Switch(config)# interface G0/1
Switch(config-if)# switch mode access
Switch(config-if)# service-policy input pm1
Classifying, Policing, and Marking Traffic by Using Hierarchical Dual-Level Policy Maps
In Cisco IOS Release 12.2(25)EY or later, you can configure hierarchical dual-level policy maps on
SVIs, but not on other types of interfaces. Dual-level policing combines the VLAN- and interface-level
policy maps to create a single policy map. For more information, see the “Hierarchical Dual-Level
Policing on SVIs” section on page 34-15.
On an SVI, the VLAN-level policy map specifies which traffic class to act on. Actions can include
trusting the CoS, DSCP, or IP precedence values or setting a specific DSCP or IP precedence value in
the traffic class. Use the interface-level policy map to specify the physical ports that are affected by
individual policers.
Follow these guidelines when configuring hierarchical dual-level policy maps:
• Before configuring a dual-level policy map, you must enable VLAN-based QoS on the physical
ports that are to be specified at the interface level of the policy map.
• You can attach only one policy map per ingress port or SVI.
• A policy map can contain multiple class statements, each with different match criteria and actions.
• A separate policy-map class can exist for each type of traffic received on the SVI.
• A policy map can contain a predefined default traffic class explicitly placed at the end of the map.
• A policy-map trust state and a port trust state are mutually exclusive, and whichever is configured
last takes effect.
• If you configure the IP-precedence-to-DSCP map by using the mls qos map ip-prec-dscp
dscp1...dscp8 global configuration command, the settings only affect packets on ingress interfaces
that are configured to trust the IP precedence value. In a policy map, if you set the packet IP
precedence value to a new value by using the set precedence new-precedence policy-map class
configuration command, the egress DSCP value is not affected by the IP-precedence-to-DSCP map.
If you want the egress DSCP value to be different from the ingress value, use the set dscp new-dscp
• If VLAN-based QoS is enabled, the dual-level policy map supersedes the previously configured
port-based policy map.
• The dual-level policy map is attached to the SVI and affects all traffic belonging to the VLAN. The
individual policer in the interface-level traffic classification only affects the traffic on the physical
ports specified in that classification. The actions specified in the VLAN-level policy map affects the
traffic belonging to the SVI.
• When configuring a dual-level policy map on trunk ports, the VLAN ranges must not overlap. If the
ranges overlap, the actions specified in the policy map affect the incoming and outgoing traffic on
the overlapped VLANs, and the policy map is not applied properly at ingress and egress.
• Aggregate policers are not supported in dual-level policy maps.

OL-9644-10 34-73
• When VLAN-based QoS is enabled, the switch supports VLAN-based features, such as the VLAN
map.
• You can configure a dual-level policy map only on the primary VLAN of a private VLAN.
Beginning in privileged EXEC mode, follow these steps to create a hierarchical dual-level policy map:
Command Purpose
Step 2 class-map [match-all | match-any] Create a VLAN-level class map, and enter class-map configuration
class-map-name mode. For information about creating a class map, see the “Classifying
Ingress Traffic by Using Class Maps” section on page 34-67.
of all matching statements under this class map. All match criteria
in the class map must be matched.
• (Optional) Use the match-any keyword to perform a logical-OR of
all matching statements under this class map. One or more match
If neither the match-all or match-any keyword is specified, the default
is match-all.
Step 3 match {access-group acl-index-or-name | Define the match criterion to classify traffic.
ip dscp dscp-list | ip precedence
By default, no match criterion is defined.
ip-precedence-list}
Only one match criterion per class map is supported, and only one ACL
per class map is supported.
• For access-group acl-index-or-name, specify the number or name
of the ACL.
• For ip dscp dscp-list, enter a list of up to eight IP DSCP values to
match against incoming packets. Separate each value with a space.
• For ip precedence ip-precedence-list, enter a list of up to eight
IP-precedence values to match against incoming packets. Separate
Step 4 exit Return to class-map configuration mode.

34-74 OL-9644-10
Command Purpose
Step 6 class-map [match-all | match-any] Create an interface-level class map, and enter class-map configuration
class-map-name mode.
of all matching statements under this class map. All match criteria
in the class map must be matched.
• (Optional) Use the match-any keyword to perform a logical-OR of
all matching statements under this class map. One or more match
If neither the match-all or match-any keyword is specified, the default
is match-all.
Step 7 match input-interface interface-id-list Specify the physical ports on which the interface-level class map acts.
You can specify up to six ports as follows:
• A single port (counts as one entry)
• A list of ports separated by a space (each port counts as an entry)
• A range of ports separated by a hyphen (counts as two entries)
This command can only be used in the child-level policy map and must
be the only match condition in the child-level policy map.
Step 8 exit Return to class-map configuration mode.
Step 10 policy-map policy-map-name Create an interface-level policy map by entering the policy-map name,
and enter policy-map configuration mode.
By default, no policy maps are defined, and no policing is performed.
Step 11 class [class-map-name | class-default] Defines a traffic classification, and enter policy-map class
configuration mode.
By default, no policy map class-maps are defined.
command.
A class-default traffic class is pre-defined and can be added to any
policy. It is always placed at the end of a policy map. With an implied
match any included in the class-default class, all packets that have not
already matched the other traffic classes will match class-default.

OL-9644-10 34-75
Command Purpose
Step 12 police rate-bps burst-byte [exceed-action Define an individual policer for the classified traffic.
{drop | policed-dscp-transmit}]
By default, no policer is defined. For information on the number of
policers supported, see the “Standard QoS Configuration Guidelines”
• For rate-bps, specify average traffic rate in bits per second (bps).
The range is 8000 to 1000000000.
• For burst-byte, specify the normal burst size in bytes. The range is
8000 to 1000000.
• (Optional) Specify the action to take when the rates are exceeded.
Use the exceed-action drop keywords to drop the packet. Use the
exceed-action policed-dscp-transmit keywords to mark down the
DSCP value (by using the policed-DSCP map) and send the packet.
For more information, see the “Configuring the Policed-DSCP
Map” section on page 34-83.
Step 15 policy-map policy-map-name Create a VLAN-level policy map by entering the policy-map name, and
enter policy-map configuration mode.
The behavior of a policy map is to set the DSCP to 0 if the packet is an
IP packet and to set the CoS to 0 if the packet is tagged. No policing is
performed.
Step 16 class class-map-name Define a VLAN-level traffic classification, and enter policy-map class
configuration mode.
By default, no policy-map class-maps are defined.
command.

34-76 OL-9644-10
Command Purpose
Step 17 trust [cos | dscp | ip-precedence] Configure the trust state, which QoS uses to generate a CoS-based or
DSCP-based QoS label.
Note This command is mutually exclusive with the set command
within the same policy map. If you enter the trust command,
omit Step 18.
By default, the port is not trusted. If no keyword is specified when the

command is entered, the default is dscp.
• cos—QoS derives the DSCP value by using the received or default
port CoS value and the CoS-to-DSCP map.
• dscp—QoS derives the DSCP value by using the DSCP value from
the ingress packet. For non-IP packets that are tagged, QoS derives
the DSCP value by using the received CoS value; for non-IP
packets that are untagged, QoS derives the DSCP value by using
the port CoS value. In either case, the DSCP value is derived from
the CoS-to-DSCP map.
• ip-precedence—QoS derives the DSCP value by using the IP
precedence value from the ingress packet and the
IP-precedence-to-DSCP map. For non-IP packets that are tagged,
QoS derives the DSCP value by using the received CoS value; for
non-IP packets that are untagged, QoS derives the DSCP value by
using the port CoS value. In either case, the DSCP value is derived
from the CoS-to-DSCP map.
For more information, see the “Configuring the CoS-to-DSCP Map”
Step 18 set {dscp new-dscp | precedence Classify IP traffic by setting a new value in the packet.
new-precedence}
• For dscp new-dscp, enter a new DSCP value to be assigned to the
• For precedence new-precedence, enter a new IP-precedence value
to be assigned to the classified traffic. The range is 0 to 7.
Step 19 service-policy policy-map-name Specify the interface-level policy-map name (from Step 10), and
associate it with the VLAN-level policy map.
If the VLAN-level policy map specifies more than one class, all classes
must include the same service-policy policy-map-name command.
Step 22 interface interface-id Specify the SVI to which to attach the dual-level policy map, and enter

OL-9644-10 34-77
Command Purpose
Step 23 service-policy input policy-map-name Specify the VLAN-level policy-map name, and apply it to the SVI.
Repeat the previous step and this command to apply the policy map to
other SVIs.
If the dual-level VLAN-level policy map has more than one
interface-level policy map, all class maps must be configured to the
same VLAN-level policy map specified in the service-policy
policy-map-name command.
class-map-name]]
or
show mls qos vlan-based
command. To delete an existing class map, use the no class class-map-name policy-map configuration
command.
To return to the default untrusted state in a policy map, use the no trust policy-map configuration
command. To remove an assigned DSCP or IP precedence value, use the no set {dscp new-dscp | ip
precedence new-precedence} policy-map configuration command.
To remove an existing policer in an interface-level policy map, use the no police rate-bps burst-byte
[exceed-action {drop | policed-dscp-transmit}] policy-map configuration command. To remove the
dual-level policy map and port associations, use the no service-policy input policy-map-name interface
This example shows how to create a hierarchical dual-level policy map and attach it to an SVI:
Switch(config)# access-list 101 permit ip any any
Switch(config)# class-map match-all cm-1
Switch(config)# exit
Switch(config)# class-map match-all cm-interface-1
Switch(config-cmap)# match input-interface gigabitethernet1/0/1 gigabitethernet1/0/2
Switch(config)# exit
Switch(config)# policy-map port-plcmap
Switch(config-pmap)# class cm-interface-1
Switch(config-pmap-c)# police 9000000 9000 exceed-action policed-dscp-transmit
Switch(config)# policy-map vlan-plcmap
Switch(config-pmap-c)# service-policy port-plcmap
Switch(config)# interface vlan 10
Switch(config-if)# service-policy input vlan-plcmap

34-78 OL-9644-10
Classifying, Policing, and Marking Ingress Traffic by Using Aggregate Policers

By using an aggregate policer, you can create a policer that is shared by multiple traffic classes within
the same policy map. However, you cannot use the aggregate policer across different policy maps or
ports.
You can configure aggregate policers only in nonhierarchical single-level policy maps.
more information, see the “Classifying Ingress Traffic by Using ACLs” section on page 34-63 and the
“Classifying Ingress Traffic by Using Class Maps” section on page 34-67.
Beginning in privileged EXEC mode, follow these steps to create an aggregate policer for inbound
traffic:
Command Purpose
Step 2 mls qos aggregate-policer Define the policer parameters that can be applied to multiple traffic
aggregate-policer-name rate-bps burst-byte classes within the same policy map.
exceed-action {drop |
By default, no aggregate policer is defined. For information on the
policed-dscp-transmit}
number of policers supported, see the “Standard QoS Configuration
Guidelines” section on page 34-53
• For aggregate-policer-name, specify the name of the aggregate
policer.
• For rate-bps, specify average traffic rate in bps. The range is
8000 to 1000000000.
• For burst-byte, specify the normal burst size in bytes. The range
is 8000 to 1000000.
• Specify the action to take when the rates are exceeded. Use the
exceed-action drop keywords to drop the packet. Use the
exceed-action policed-dscp-transmit keywords to mark down
the DSCP value (through the policed-DSCP map) and send the
packet. For more information, see the “Configuring the
Policed-DSCP Map” section on page 34-83.
For more information, see the “Classifying, Policing, and Marking
Ingress Traffic by Using Nonhierarchical Single-Level Policy
Maps” section on page 34-69.
Step 4 class class-name Specify the name of the class whose traffic policy you want to create
or change, and enter policy-map class configuration mode.
By default, no traffic classes are defined.
Step 5 police aggregate aggregate-policer-name Apply an aggregate policer to multiple classes in the same policy
map.
For aggregate-policer-name, enter the name specified in Step 2.
Step 7 interface interface-id Specify the port to attach to the policy map, and enter interface
configuration mode.

OL-9644-10 34-79
Command Purpose
Step 8 service-policy input policy-map-name Specify the ingress policy-map name, and apply it to a port.
Step 10 show mls qos aggregate-policer Verify your entries.
[aggregate-policer-name]
To remove the specified aggregate policer from a policy map, use the no police aggregate
aggregate-policer-name policy-map class configuration command. To delete an aggregate policer and its
parameters, use the no mls qos aggregate-policer aggregate-policer-name global configuration
command.
This example shows how to create an aggregate policer and attach it to multiple classes within a policy
map. In the configuration, the IP ACLs permit traffic from network 10.1.0.0 and from host 11.3.1.1. For
traffic coming from network 10.1.0.0, the DSCP in the inbound packets is trusted. For traffic coming
from host 11.3.1.1, the DSCP in the packet is changed to 56. The traffic rate from the 10.1.0.0 network
and from host 11.3.1.1 is policed. If the traffic exceeds an average rate of 48000 bps and a normal burst
size of 8000 bytes, its DSCP is marked down (based on the policed-DSCP map) and sent. The ingress
policy map is attached to a port.
Switch(config)# access-list 2 permit 11.3.1.1
Switch(config)# mls qos aggregate-police transmit1 48000 8000 exceed-action
policed-dscp-transmit
Switch(config)# policy-map aggflow1
Switch(config-pmap-c)# trust dscp
Switch(config-pmap-c)# police aggregate transmit1
Switch(config-pmap-c)# police aggregate transmit1
Switch(config-if)# service-policy input aggflow1
Switch(config-if)# exit
Configuring DSCP Maps

These sections describe how to configure the DSCP maps:
• Configuring the CoS-to-DSCP Map, page 34-81 (optional)
• Configuring the IP-Precedence-to-DSCP Map, page 34-82 (optional)
• Configuring the Policed-DSCP Map, page 34-83 (optional, unless the null settings in the map are
not appropriate)

34-80 OL-9644-10
• Configuring the DSCP-to-CoS Map, page 34-84 (optional)

• Configuring the DSCP-to-DSCP-Mutation Map, page 34-85 (optional, unless the null settings in the
map are not appropriate)
All the maps, except the DSCP-to-DSCP-mutation map, are globally defined and are applied to all ports.
Configuring the CoS-to-DSCP Map

You use the CoS-to-DSCP map to map CoS values in inbound packets to a DSCP value that QoS uses
internally to represent the priority of the traffic.
Table 34-13 shows the CoS-to-DSCP map.
Table 34-13 CoS-to-DSCP Map
CoS Value DSCP Value

0 0
1 8
2 16
3 24
4 32
5 40
6 48
7 56
If these values are not appropriate for your network, you need to modify them.
Beginning in privileged EXEC mode, follow these steps to modify the CoS-to-DSCP map. This
procedure is optional.
Command Purpose
Step 2 mls qos map cos-dscp dscp1...dscp8 Modify the CoS-to-DSCP map.
For dscp1...dscp8, enter eight DSCP values that correspond to CoS values
0 to 7. Separate each DSCP value with a space.
Step 4 show mls qos maps cos-dscp Verify your entries.
To return to the default map, use the no mls qos cos-dscp global configuration command.

OL-9644-10 34-81
This example shows how to modify and display the CoS-to-DSCP map:
Switch(config)# mls qos map cos-dscp 10 15 20 25 30 35 40 45
Switch(config)# end
Switch# show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 10 15 20 25 30 35 40 45
Configuring the IP-Precedence-to-DSCP Map

You use the IP-precedence-to-DSCP map to map IP precedence values in inbound packets to a DSCP
value that QoS uses internally to represent the priority of the traffic.
Table 34-14 shows the IP-precedence-to-DSCP map:
Table 34-14 IP-Precedence-to-DSCP Map
IP Precedence Value DSCP Value

0 0
1 8
2 16
3 24
4 32
5 40
6 48
7 56
Beginning in privileged EXEC mode, follow these steps to modify the IP-precedence-to-DSCP map.
This procedure is optional.
Command Purpose
Step 2 mls qos map ip-prec-dscp Modify the IP-precedence-to-DSCP map.
dscp1...dscp8
For dscp1...dscp8, enter eight DSCP values that correspond to the IP
precedence values 0 to 7. Separate each DSCP value with a space.
Step 4 show mls qos maps ip-prec-dscp Verify your entries.
To return to the default map, use the no mls qos ip-prec-dscp global configuration command.

34-82 OL-9644-10
This example shows how to modify and display the IP-precedence-to-DSCP map:
Switch(config)# mls qos map ip-prec-dscp 10 15 20 25 30 35 40 45
Switch(config)# end
Switch# show mls qos maps ip-prec-dscp
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 10 15 20 25 30 35 40 45
Configuring the Policed-DSCP Map

You use the policed-DSCP map to mark down a DSCP value to a new value as the result of an ingress
policing and marking action.
The policed-DSCP map is a null map, which maps an inbound DSCP value to the same DSCP value.
Beginning in privileged EXEC mode, follow these steps to modify the policed-DSCP map. This
Command Purpose
Step 2 mls qos map policed-dscp dscp-list to Modify the policed-DSCP map.
mark-down-dscp
• For dscp-list, enter up to eight DSCP values separated by spaces.
• For mark-down-dscp, enter the corresponding policed (marked down)
DSCP value.
Step 4 show mls qos maps policed-dscp Verify your entries.
To return to the default map, use the no mls qos policed-dscp global configuration command.
This example shows how to map DSCP 50 to 57 to a marked-down DSCP value of 0:
Switch(config)# mls qos map policed-dscp 50 51 52 53 54 55 56 57 to 0
Switch(config)# end
Switch# show mls qos maps policed-dscp
Policed-dscp map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 01 02 03 04 05 06 07 08 09
1 : 10 11 12 13 14 15 16 17 18 19
2 : 20 21 22 23 24 25 26 27 28 29
3 : 30 31 32 33 34 35 36 37 38 39
4 : 40 41 42 43 44 45 46 47 48 49
5 : 00 00 00 00 00 00 00 00 58 59
6 : 60 61 62 63

OL-9644-10 34-83
Note In this policed-DSCP map, the marked-down DSCP values are shown in the body of the matrix. The d1
column specifies the most-significant digit of the original DSCP; the d2 row specifies the
least-significant digit of the original DSCP. The intersection of the d1 and d2 values provides the
marked-down value. For example, an original DSCP value of 53 corresponds to a marked-down DSCP
value of 0.
Configuring the DSCP-to-CoS Map

You use the DSCP-to-CoS map to generate a CoS value, which is used to select one of the four queues
in the egress queue-set.
Table 34-15 shows the DSCP-to-CoS map.
Table 34-15 DSCP-to-CoS Map
DSCP Value CoS Value

0–7 0
8–15 1
16–23 2
24–31 3
32–39 4
40–47 5
48–55 6
56–63 7
Beginning in privileged EXEC mode, follow these steps to modify the DSCP-to-CoS map. This
Command Purpose
Step 2 mls qos map dscp-cos dscp-list to cos Modify the DSCP-to-CoS map.
• For dscp-list, enter up to eight DSCP values separated by spaces.
• For cos, enter the CoS value to which the DSCP values correspond.
The DSCP range is 0 to 63; the CoS range is 0 to 7.
Step 4 show mls qos maps dscp-to-cos Verify your entries.
To return to the default map, use the no mls qos dscp-cos global configuration command.

34-84 OL-9644-10
This example shows how to map DSCP values 0, 8, 16, 24, 32, 40, 48, and 50 to CoS value 0 and to
display the map:
Switch(config)# mls qos map dscp-cos 0 8 16 24 32 40 48 50 to 0
Switch(config)# end
Switch# show mls qos maps dscp-cos
Dscp-cos map:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 00 01
1 : 01 01 01 01 01 01 00 02 02 02
2 : 02 02 02 02 00 03 03 03 03 03
3 : 03 03 00 04 04 04 04 04 04 04
4 : 00 05 05 05 05 05 05 05 00 06
5 : 00 06 06 06 06 06 07 07 07 07
6 : 07 07 07 07
Note In the above DSCP-to-CoS map, the CoS values are shown in the body of the matrix. The d1 column
specifies the most-significant digit of the DSCP; the d2 row specifies the least-significant digit of the
DSCP. The intersection of the d1 and d2 values provides the CoS value. For example, in the
DSCP-to-CoS map, a DSCP value of 08 corresponds to a CoS value of 0.
Configuring the DSCP-to-DSCP-Mutation Map

If two QoS domains have different DSCP definitions, use the DSCP-to-DSCP-mutation map to translate
one set of DSCP values to match the definition of another domain. You apply the
DSCP-to-DSCP-mutation map to the receiving port (ingress mutation) at the boundary of a QoS
administrative domain.
With ingress mutation, the new DSCP value overwrites the one in the packet, and QoS treats the packet
with this new value. The switch sends the packet out with the new DSCP value.
You can configure multiple DSCP-to-DSCP-mutation maps and apply them to traffic received on a port.
The DSCP-to-DSCP-mutation map is a null map, which maps an inbound DSCP value to the same DSCP
value.
Beginning in privileged EXEC mode, follow these steps to modify the DSCP-to-DSCP-mutation map.
Command Purpose
Step 2 mls qos map dscp-mutation Modify the DSCP-to-DSCP-mutation map.
dscp-mutation-name in-dscp to out-dscp
• For dscp-mutation-name, enter the mutation map name. You can
create more than one map by specifying a new name.
• For in-dscp, enter up to eight DSCP values separated by spaces.
• For out-dscp, enter a single DSCP value.
Step 3 interface interface-id Specify the port to which to attach the map, and enter interface
configuration mode.

OL-9644-10 34-85
Command Purpose
Step 4 mls qos trust dscp Configure the ingress port as a DSCP-trusted port. By default, the port
is not trusted.
Step 5 mls qos dscp-mutation Apply the map to the specified ingress DSCP-trusted port.
dscp-mutation-name
For dscp-mutation-name, enter the mutation map name specified in
Step 2.
Step 7 show mls qos maps dscp-mutation Verify your entries.
To return to the default map, use the no mls qos dscp-mutation dscp-mutation-name global
This example shows how to define the DSCP-to-DSCP-mutation map. All the entries that are not
explicitly configured are not modified (remains as specified in the null map).
Switch(config)# mls qos map dscp-mutation mutation1 1 2 3 4 5 6 7 to 0
Switch(config)# mls qos map dscp-mutation mutation1 8 9 10 11 12 13 to 10
Switch(config)# mls qos map dscp-mutation mutation1 20 21 22 to 20
Switch(config)# mls qos map dscp-mutation mutation1 30 31 32 33 34 to 30
Switch(config-if)# mls qos trust dscp
Switch(config-if)# mls qos dscp-mutation mutation1
Switch# show mls qos maps dscp-mutation mutation1
Dscp-dscp mutation map:
mutation1:
d1 : d2 0 1 2 3 4 5 6 7 8 9
---------------------------------------
0 : 00 00 00 00 00 00 00 00 10 10
1 : 10 10 10 10 14 15 16 17 18 19
2 : 20 20 20 23 24 25 26 27 28 29
3 : 30 30 30 30 30 35 36 37 38 39
4 : 40 41 42 43 44 45 46 47 48 49
5 : 50 51 52 53 54 55 56 57 58 59
6 : 60 61 62 63
Note In the above DSCP-to-DSCP-mutation map, the mutated values are shown in the body of the matrix. The
d1 column specifies the most-significant digit of the original DSCP; the d2 row specifies the
least-significant digit of the original DSCP. The intersection of the d1 and d2 values provides the mutated
value. For example, a DSCP value of 12 corresponds to a mutated value of 10.
Configuring Ingress Queue Characteristics

Single-level input policy maps are supported only on SVIs and standard physical ports. Depending on
the complexity of your network and your QoS solution, you might need to perform all of the tasks in the
next sections. You will need to make decisions about these characteristics:
• Which packets are assigned (by DSCP or CoS value) to each queue?
• What drop percentage thresholds apply to each queue, and which CoS or DSCP values map to each
threshold?
• How much of the available buffer space is allocated between the queues?

34-86 OL-9644-10
• How much of the available bandwidth is allocated between the queues?

• Is there traffic (such as voice) that should be given high priority?
These sections describe how to configure ingress queue characteristics:
• Mapping DSCP or CoS Values to an Ingress Queue and Setting WTD Thresholds, page 34-87
(optional)
• Allocating Buffer Space Between the Ingress Queues, page 34-88 (optional)
• Allocating Bandwidth Between the Ingress Queues, page 34-89 (optional)
• Configuring the Ingress Priority Queue, page 34-90 (optional)
Mapping DSCP or CoS Values to an Ingress Queue and Setting WTD Thresholds
You can prioritize inbound traffic by placing packets with particular DSCP or CoS values into certain
queues and by adjusting the queue thresholds so that packets with lower priorities are dropped.
Beginning in privileged EXEC mode, follow these steps to map DSCP or CoS values to an ingress queue
and to set WTD thresholds. This procedure is optional.
Command Purpose
Step 2 mls qos srr-queue input dscp-map Map DSCP or CoS values to an ingress queue and to a threshold ID.
queue queue-id threshold threshold-id By default, DSCP values 0–39 and 48–63 are mapped to queue 1 and
dscp1...dscp8 threshold 1. DSCP values 40–47 are mapped to queue 2 and threshold 1.
or By default, CoS values 0–4, 6, and 7 are mapped to queue 1 and threshold
mls qos srr-queue input cos-map 1. CoS value 5 is mapped to queue 2 and threshold 1.
queue queue-id threshold threshold-id
• For queue-id, the range is 1 to 2.
cos1...cos8
• For threshold-id, the range is 1 to 3. The drop-threshold percentage
for threshold 3 is predefined. It is set to the queue-full state.
• For dscp1...dscp8, enter up to eight values, and separate each value
with a space. The range is 0 to 63.
• For cos1...cos8, enter up to eight values, and separate each value with
a space. The range is 0 to 7.
Step 3 mls qos srr-queue input threshold Assign the two WTD threshold percentages for (threshold 1 and 2) to an
queue-id threshold-percentage1 ingress queue. The default, both thresholds are set to 100 percent.
threshold-percentage2
• For threshold-percentage1 threshold-percentage2, the range is 1 to
100. Separate each value with a space.
Each threshold value is a percentage of the total number of queue
descriptors allocated for the queue.

OL-9644-10 34-87
Command Purpose
Step 5 show mls qos maps Verify your entries.
The DSCP input queue threshold map appears as a matrix. The d1 column
specifies the most-significant digit of the DSCP number; the d2 row
specifies the least-significant digit in the DSCP number. The intersection
of the d1 and the d2 values provides the queue ID and threshold ID; for
example, queue 2 and threshold 1 (02-01).
The CoS input queue threshold map shows the CoS value in the top row
and the corresponding queue ID and threshold ID in the second row; for
To return to the default CoS input queue threshold map or the DSCP input queue threshold map, use the
no mls qos srr-queue input cos-map or the no mls qos srr-queue input dscp-map global configuration
command. To return to the default WTD threshold percentages, use the no mls qos srr-queue input
threshold queue-id global configuration command.
This example shows how to map DSCP values 0 to 6 to ingress queue 1 and to threshold 1 with a drop
threshold of 50 percent. It maps DSCP values 20 to 26 to ingress queue 1 and to threshold 2 with a drop
threshold of 70 percent.
Switch(config)# mls qos srr-queue input dscp-map queue 1 threshold 1 0 1 2 3 4 5 6
Switch(config)# mls qos srr-queue input dscp-map queue 1 threshold 2 20 21 22 23 24 25 26
Switch(config)# mls qos srr-queue input threshold 1 50 70
In this example, the DSCP values (0 to 6) are assigned the WTD threshold of 50 percent and will be
dropped sooner than the DSCP values (20 to 26) assigned to the WTD threshold of 70 percent.
Allocating Buffer Space Between the Ingress Queues

You define the ratio (allocate the amount of space) with which to divide the ingress buffers between the
two queues. The buffer and the bandwidth allocation control how much data can be buffered before
packets are dropped.
Beginning in privileged EXEC mode, follow these steps to allocate the buffers between the ingress
queues. This procedure is optional.
Command Purpose
Step 2 mls qos srr-queue input buffers Allocate the buffers between the ingress queues
percentage1 percentage2
By default, 90 percent of the buffers are allocated to queue 1, and 10
percent of the buffers are allocated to queue 2.
For percentage1 percentage2, the range is 0 to 100. Separate each value
with a space.
You should allocate the buffers so that the queues can handle any inbound
bursty traffic.

34-88 OL-9644-10
Command Purpose
Step 4 show mls qos interface buffer Verify your entries.
or
show mls qos input-queue
To return to the default setting, use the no mls qos srr-queue input buffers global configuration
command.
This example shows how to allocate 60 percent of the buffer space to ingress queue 1 and 40 percent of
the buffer space to ingress queue 2:
Switch(config)# mls qos srr-queue input buffers 60 40
Allocating Bandwidth Between the Ingress Queues

You need to specify how much of the available bandwidth is allocated between the ingress queues. The
ratio of the weights is the ratio of the frequency in which the SRR scheduler sends packets from each
queue to the internal ring. The bandwidth and the buffer allocation control how much data can be
buffered before packets are dropped. On ingress queues, SRR operates only in shared mode.
Beginning in privileged EXEC mode, follow these steps to allocate bandwidth between the ingress
queues. This procedure is optional.
Command Purpose
Step 2 mls qos srr-queue input bandwidth Assign shared round robin weights to the ingress queues.
weight1 weight2
The default setting for weight1 and weight2 is 4 (1/2 of the bandwidth is
equally shared between the two queues).
For weight1 and weight2, the range is 1 to 100. Separate each value with
a space.
SRR services the priority queue for its configured weight as specified by
the bandwidth keyword in the mls qos srr-queue input priority-queue
queue-id bandwidth weight global configuration command. Then, SRR
shares the remaining bandwidth with both ingress queues and services
them as specified by the weights configured with the mls qos srr-queue
input bandwidth weight1 weight2 global configuration command. For
more information, see the “Configuring the Ingress Priority Queue”
Step 4 show mls qos interface queueing Verify your entries.
or
To return to the default setting, use the no mls qos srr-queue input bandwidth global configuration
command.

OL-9644-10 34-89
This example shows how to assign the ingress bandwidth to the queues. Priority queueing is disabled,
and the shared bandwidth ratio allocated to queue 1 is 25/(25+75) and to queue 2 is 75/(25+75).
Switch(config)# mls qos srr-queue input priority-queue 2 bandwidth 0
Switch(config)# mls qos srr-queue input bandwidth 25 75
Configuring the Ingress Priority Queue

You should use the ingress priority queue only for traffic that needs to be expedited (for example, voice
traffic, which needs minimum delay and jitter).
The priority queue is guaranteed part of the bandwidth to reduce the delay and jitter under heavy network
traffic on an oversubscribed ring (when there is more traffic than the backplane can carry, and the queues
are full and dropping frames).
SRR services the priority queue for its configured weight as specified by the bandwidth keyword in the
mls qos srr-queue input priority-queue queue-id bandwidth weight global configuration command.
Then, SRR shares the remaining bandwidth with both ingress queues and services them as specified by
the weights configured with the mls qos srr-queue input bandwidth weight1 weight2 global
Beginning in privileged EXEC mode, follow these steps to configure the ingress priority queue. This
Command Purpose
Step 2 mls qos srr-queue input Assign a queue as the priority queue and guarantee bandwidth on the
priority-queue queue-id bandwidth internal ring if the ring is congested.
weight
By default, the priority queue is queue 2, and 10 percent of the bandwidth
is allocated to it.
• For bandwidth weight, assign the bandwidth percentage of the
internal ring. The range is 0 to 40. The amount of bandwidth that can
be guaranteed is restricted because a large value affects the entire ring
and can degrade performance.
Step 4 show mls qos interface queueing Verify your entries.
or
To return to the default setting, use the no mls qos srr-queue input priority-queue queue-id global
configuration command. To disable priority queueing, set the bandwidth weight to 0, for example, mls
qos srr-queue input priority-queue queue-id bandwidth 0.

34-90 OL-9644-10
This example shows how to assign the ingress bandwidths to the queues. Queue 1 is the priority queue
with 10 percent of the bandwidth allocated to it. The bandwidth ratios allocated to queues 1 and 2 is
4/(4+4). SRR services queue 1 (the priority queue) first for its configured 10 percent bandwidth. Then
SRR equally shares the remaining 90 percent of the bandwidth between queues 1 and 2 by allocating 45
percent to each queue.
Switch(config)# mls qos srr-queue input priority-queue 1 bandwidth 10
Switch(config)# mls qos srr-queue input bandwidth 4 4
Configuring Egress Queue-Set Characteristics

Single-level output policy maps are supported only on SVIs and ES ports. Depending on the complexity
of your network and your QoS solution, you might need to perform all of the tasks in the next sections.
You will need to make decisions about these characteristics:
• Which packets are mapped by DSCP or CoS value to each queue and threshold ID?
• What drop percentage thresholds apply to the queue-set (four egress queues per port), and how much
reserved and maximum memory is needed for the traffic type?
• How much of the fixed buffer space is allocated to the queue-set?
• Does the bandwidth of the port need to be rate limited?
• Is there traffic (such as voice) that should be given high priority?
• How often should the egress queue-set be serviced and which technique (shaped, shared, or both)
should be used?
These sections describe how to configure egress queue-set characteristics:
• Allocating Buffer Space to and Setting WTD Thresholds for an Egress Queue-Set, page 34-91
(optional)
• Mapping DSCP or CoS Values to an Egress Queue-Set and to a Threshold ID, page 34-93 (optional)
• Configuring SRR Shaped Weights on an Egress Queue-Set, page 34-95 (optional)
• Configuring SRR Shared Weights on an Egress Queue-Set, page 34-96 (optional)
• Configuring the Egress Priority Queue, page 34-97 (optional)
• Limiting the Egress Bandwidth on a Queue-Set, page 34-97 (optional)
Allocating Buffer Space to and Setting WTD Thresholds for an Egress Queue-Set
You can guarantee the availability of buffers, set WTD thresholds, and configure the maximum memory
allocation for a queue-set by using the mls qos queue-set output qset-id threshold queue-id
drop-threshold1 drop-threshold2 reserved-threshold maximum-threshold global configuration command.
Each threshold value is a percentage of the queue’s allocated buffers, which you specify by using the mls
qos queue-set output qset-id buffers allocation1 ... allocation4 global configuration command. The
queues use WTD to support distinct drop percentages for different traffic classes.

OL-9644-10 34-91
Beginning in privileged EXEC mode, follow these steps to configure the memory allocation and drop
thresholds for a queue-set. This procedure is optional.
Command Purpose
Step 2 mls qos queue-set output qset-id Allocate buffers to a queue-set.
buffers allocation1 ... allocation4
By, all allocation values are equally mapped among the four queues (25,
25, 25, 25). Each queue has 1/4 of the buffer space.
• For qset-id, enter the ID of the queue-set. The range is 1 to 2. Each
port belongs to a queue-set, which defines all the characteristics of the
four egress queues per port.
• For allocation1, allocation3, and allocation4, the range is 0 to 99. For
allocation2, the range is 1 to 100 (including the CPU buffer).
Allocate buffers according to the importance of the traffic. For example,
give a larger percentage of the buffer to the queue with the highest-priority
traffic.
Step 3 mls qos queue-set output qset-id Configure the WTD thresholds, guarantee the availability of buffers, and
threshold queue-id drop-threshold1 configure the maximum memory allocation for the queue-set (four egress
drop-threshold2 reserved-threshold queues per port).
maximum-threshold
By default, the WTD thresholds for queues 1, 3, and 4 are set to 100
percent. The thresholds for queue 2 are set to 200 percent. The reserved
thresholds for queues 1, 2, 3, and 4 are set to 50 percent. The maximum
thresholds for all queues are set to 400 percent.
• For qset-id, enter the ID of the queue-set specified in Step 2. The
range is 1 to 2.
• For queue-id, enter the specific queue in the queue-set on which the
command is performed. The range is 1 to 4.
• For drop-threshold1 drop-threshold2, specify the two WTD
thresholds expressed as a percentage of the allocated queue memory.
The range is 1 to 3200 percent.
• For reserved-threshold, enter the amount of memory to be guaranteed
(reserved) for the queue expressed as a percentage of the allocated
memory. The range is 1 to 100 percent.
• For maximum-threshold, enable a full queue to obtain more buffers
than are reserved for it. This is the maximum memory the queue can
have before the packets are dropped if the common pool is not empty.
The range is 1 to 3200 percent.
Step 4 interface interface-id Specify the port, and enter interface configuration mode.
Step 5 queue-set qset-id Map the port to a queue-set.
For qset-id, enter the ID of the queue-set specified in Step 2. The range is
1 to 2. The default is 1.

34-92 OL-9644-10
Command Purpose
buffers
To return to the default setting, use the no mls qos queue-set output qset-id buffers global configuration
command. To return to the default WTD threshold percentages, use the no mls qos queue-set output
qset-id threshold [queue-id] global configuration command.
This example shows how to map a port to queue-set 2. It allocates 40 percent of the buffer space to egress
queue 1 and 20 percent each to egress queues 2, 3, and 4. It configures the drop thresholds for queue 2
to 40 and 60 percent of the allocated memory, guarantees (reserves) 100 percent of the allocated memory,
and configures 200 percent as the maximum memory that this queue can have before packets are
dropped.
Switch(config)# mls qos queue-set output 2 buffers 40 20 20 20
Switch(config)# mls qos queue-set output 2 threshold 2 40 60 100 200
Switch(config)# interface fastethernet1/0/1
Switch(config-if)# queue-set 2
Mapping DSCP or CoS Values to an Egress Queue-Set and to a Threshold ID

You can prioritize traffic by placing packets with particular DSCP or CoS values into certain queues and
by adjusting the queue thresholds so that packets with lower priorities are dropped.

OL-9644-10 34-93
Beginning in privileged EXEC mode, follow these steps to map DSCP or CoS values to an egress queue
and to a threshold ID. This procedure is optional.
Command Purpose
Step 2 mls qos srr-queue output dscp-map Map DSCP or CoS values to an egress queue and to a threshold ID for a
queue queue-id threshold threshold-id port.
dscp1...dscp8 By default, DSCP values 0–15 are mapped to queue 2 and threshold 1.
or DSCP values 16–31 are mapped to queue 3 and threshold 1. DSCP values
32–39 and 48–63 are mapped to queue 4 and threshold 1. DSCP values
mls qos srr-queue output cos-map
40–47 are mapped to queue 1 and threshold 1.
queue queue-id threshold threshold-id
cos1...cos8 By default, CoS values 0 and 1 are mapped to queue 2 and threshold 1.
CoS values 2 and 3 are mapped to queue 3 and threshold 1. CoS values 4,
6, and 7 are mapped to queue 4 and threshold 1. CoS value 5 is mapped to
queue 1 and threshold 1.
• For threshold-id, the range is 1 to 3. The drop-threshold percentage
for threshold 3 is predefined. It is set to the queue-full state.
• For dscp1...dscp8, enter up to eight values, and separate each value
with a space. The range is 0 to 63.
• For cos1...cos8, enter up to eight values, and separate each value with
a space. The range is 0 to 7.
Step 4 show mls qos maps Verify your entries.
The DSCP output queue threshold map appears as a matrix. The d1
column specifies the most-significant digit of the DSCP number; the d2
row specifies the least-significant digit in the DSCP number. The
intersection of the d1 and the d2 values provides the queue ID and
threshold ID; for example, queue 2 and threshold 1 (02-01).
The CoS output queue threshold map shows the CoS value in the top row
and the corresponding queue ID and threshold ID in the second row; for
To return to the default DSCP output queue threshold map or the CoS output queue threshold map, use
the no mls qos srr-queue output dscp-map or the no mls qos srr-queue output cos-map global
This example shows how to map DSCP values 10 and 11 to egress queue 1 and to threshold 2:
Switch(config)# mls qos srr-queue output dscp-map queue 1 threshold 2 10 11

34-94 OL-9644-10
Configuring SRR Shaped Weights on an Egress Queue-Set

You can specify how much of the available bandwidth is allocated to each queue in the queue-set. The
ratio of the weights is the ratio of frequency in which the SRR scheduler sends packets from a standard
port.
Note SRR shaping is not supported on the ES ports; however, you can configure average-rate shaping. For
more information, see the “Configuring Shaping” section on page 34-129.
You can configure the egress queues for shaped weights, shared weights, or both. Use shaping to smooth
bursty traffic or to provide a smoother output over time. For conceptual information, see the “SRR
Shaping and Sharing” section on page 34-19. For configuration information, see the “Configuring SRR
Shared Weights on an Egress Queue-Set” section on page 34-96.
Beginning in privileged EXEC mode, follow these steps to assign the shaped weights and to enable
bandwidth shaping on a standard port mapped to the four egress queues. This procedure is optional.
Command Purpose
Step 2 interface interface-id Specify a standard port, and enter interface configuration mode.
Step 3 srr-queue bandwidth shape weight1 Assign SRR weights to the egress queues. This command is not supported
weight2 weight3 weight4 on an ES port.
By default, weight1 is set to 25; weight2, weight3, and weight4 are set to 0,
and these queues are in shared mode.
For weight1 weight2 weight3 weight4, enter the weights to control the
percentage of the port that is shaped. The inverse ratio (1/weight) controls
the shaping bandwidth for this queue. Separate each value with a space.
If you configure a weight of 0, the corresponding queue operates in shared
mode. The weight specified with the srr-queue bandwidth shape
command is ignored, and the weights specified with the srr-queue
bandwidth share interface configuration command for a queue come into
effect. When configuring queues in the same queue-set for both shaping
and sharing, make sure that you configure the lowest number queue for
shaping.
The shaped mode overrides the shared mode.
Step 5 show mls qos interface interface-id Verify your entries.
queueing
To return to the default setting, use the no srr-queue bandwidth shape interface configuration
command.

OL-9644-10 34-95
This example shows how to configure bandwidth shaping on queue 1. Because the weight ratios for
queues 2, 3, and 4 are set to 0, these queues operate in shared mode. The bandwidth weight for queue 1
is 1/8, which is 12.5 percent.
Switch(config-if)# srr-queue bandwidth shape 8 0 0 0
Configuring SRR Shared Weights on an Egress Queue-Set

In shared mode, the queues in the queue-set share the bandwidth among them according to the
configured weights. The bandwidth is guaranteed at this level but not limited to it. For example, if a
queue empties and does not require a share of the link, the remaining queues can expand into the unused
bandwidth and share it among them. With sharing, the ratio of the weights controls the frequency of
dequeuing; the absolute values are meaningless.
Beginning in privileged EXEC mode, follow these steps to assign the shared weights and to enable
bandwidth sharing on a port mapped to the four egress queues. This procedure is optional.
Command Purpose
Step 2 interface interface-id Specify a port, and enter interface configuration mode.
Step 3 srr-queue bandwidth share weight1 Assign SRR weights to the egress queues.
weight2 weight3 weight4
By default, all four weights are 25 (1/4 of the bandwidth is allocated to
each queue).
For weight1 weight2 weight3 weight4, enter the weights to control the
ratio of the frequency in which the SRR scheduler sends packets. Separate
Step 5 show mls qos interface interface-id Verify your entries.
queueing
To return to the default setting, use the no srr-queue bandwidth share interface configuration
command.
This example shows how to configure the weight ratio of the SRR scheduler running on an egress port.
Four queues are used, and the bandwidth ratio allocated for each queue in shared mode is 1/(1+2+3+4),
2/(1+2+3+4), 3/(1+2+3+4), and 4/(1+2+3+4), which is 10 percent, 20 percent, 30 percent, and 40
percent for queues 1, 2, 3, and 4. This means that queue 4 has four times the bandwidth of queue 1, twice
the bandwidth of queue 2, and one-and-a-third times the bandwidth of queue 3.
Switch(config-if)# srr-queue bandwidth share 1 2 3 4

34-96 OL-9644-10
Configuring the Egress Priority Queue

Beginning in Cisco IOS Release 12.1(14)AX2, you can ensure that certain packets have priority over all
others by queuing them in the egress priority queue on a port. SRR services this queue until it is empty
and before servicing the other queues.
If you expect that the traffic classes mapped to the egress priority queue will pass through an ES port,
you also might want to map those classes for strict-priority queuing as described in the “Enabling LLQ”
Beginning in privileged EXEC mode, follow these steps to enable the egress priority queue. This
Command3 Purpose
Step 2 interface interface-id Specify a port, and enter interface configuration mode.
Step 3 priority-queue out Enable the egress priority queue, which is disabled by default.
When you configure this command, the SRR weight and queue size ratios
are affected because there is one fewer queue participating in SRR. This
means that weight1 in the srr-queue bandwidth shape or the srr-queue
bandwidth share command is not used in the ratio calculation.
Step 5 show running-config Verify your entries.
To disable the egress priority queue, use the no priority-queue out interface configuration command.
This example shows how to enable the egress priority queue when the SRR weights are configured. The
egress expedite queue overrides the configured SRR weights.
Switch(config-if)# srr-queue bandwidth shape 25 0 0 0
Switch(config-if)# srr-queue bandwidth share 30 20 25 25
Switch(config-if)# priority-queue out
Limiting the Egress Bandwidth on a Queue-Set

You can limit the egress bandwidth on a standard port mapped to a queue-set. For example, if a customer
pays only for a small percentage of a high-speed link, you can limit the bandwidth to that amount.

OL-9644-10 34-97
Configuring Marking and Queuing for CPU-Generated Traffic
Beginning in privileged EXEC mode, follow these steps to limit the egress bandwidth on a standard port.
Command Purpose
Step 2 interface interface-id Specify a standard port to be rate-limited, and enter interface
configuration mode.
Step 3 srr-queue bandwidth limit weight1 Specify the percentage of the port speed to which the port should be
limited. The range is 10 to 90. This command is not supported on an ES
port.
By default, the port is not rate limited and is set to 100 percent.
queueing
To return to the default setting, use the no srr-queue bandwidth limit interface configuration command.
This example shows how to limit the bandwidth on a standard port to 80 percent:
Switch(config-if)# srr-queue bandwidth limit 80
When you configure this command to 80 percent, the port is idle 20 percent of the time. The line rate
drops to 80 percent of the connected speed, which is 800 Mb/s. These values are not exact because the
hardware adjusts the line rate in increments of six.

Beginning in privileged EXEC mode, follow these steps to configure marking and queuing of
CPU-generated traffic. This procedure is optional.
Command Purpose
Step 2 Configure CoS-to-DSCP, DSCP-to-CoS, Refer to the “Configuring DSCP Maps” section on page 34-80.
IP-precedence-to-DSCP, and
DSCP-mutation global maps
Step 3 cpu traffic qos cos {cos-value | trust} Mark the CoS value of CPU traffic.
• Use cos-value to enter a new CoS value. The range is from 0 to 7. If
no value is configured, the protocol-specific value for each packet
applies.
• Use the trust keyword to trust the incoming CoS value.

34-98 OL-9644-10
Command Purpose
Step 4 cpu traffic qos dscp {dscp_value | trust Mark the DSCP value of CPU traffic.
| dscp-mutation mutation-map-name}
• Use dscp_value to enter a new DSCP value. The range is from 0 to
63. If no value is configured, the protocol-specific value for each
packet applies.
• Use the trust keyword to trust the incoming DSCP value.
• Use the dscp-mutation keyword to mutate the incoming DSCP value
based on the configured mutation-map.
Step 5 cpu traffic qos precedence Mark the precedence value of CPU traffic.
{precedence_value | trust |
• Use precedence_value to enter a new IP-precedence value as a
precedence-mutation
number from 0 to 7 or by name: routine (0), priority (1), immediate
mutation-map-name}
(2), flash (3), flash-override (4), critical (5), internet (6), network
(7).
• If no value is configured, the protocol-specific value for each packet
applies.
• Use the trust keyword to trust the incoming precedence value.
• Use the precedence-mutation keyword to mutate the incoming
precedence value based on the configured mutation-map.
Step 7 Configure global maps to map QoS Refer to the“Mapping DSCP or CoS Values to an Egress Queue-Set and
markings to queue and threshold to a Threshold ID” section on page 34-93.
numbers.
Step 9 show running-config Display the configured global maps and CPU traffic QoS settings.
Step 10 show cpu traffic qos Display the QoS marking values for CPU-generated traffic.
Step 11 show mls qos maps Display information for all global maps.
To disable any command, use the no form of the command.
Example 1
This example shows how to mark the CoS of CPU-generated IP traffic (including IP-SLA and TWAMP)
based on the packet DSCP value and to configure egress queuing based on the DSCP value.
The example has these results:
• All CPU-generated IP traffic queues on the egress port based on the IP-DSCP value.
• All IP traffic with the DSCP value ef (46), which simulates voice traffic, is assigned the CoS value 5.
• All IP traffic with the DSCP values af41 (34), af42 (36) and af43 (38) is assigned the CoS value 4.
• All Internet Control Protocol traffic with the DSCP values 48 and 56 are assigned the CoS value 7.
• The rest of the IP and non-IP traffic is processed according to the default configuration.
• Queue the DSCP value 46 to queue 1 threshold 1.
• Queue the DSCP values 34 36 38 to queue 2 threshold 3.
• Queue the DSCP values 48 56 to queue 4 threshold 2.
• All other CPU traffic egresses through the default queue 2 and threshold 1.

OL-9644-10 34-99
Maps:
Switch(config)# mls qos

Switch(config)# mls qos map dscp-cos 46 to 5
Switch(config)# mls qos map dscp-cos 34 36 38 to 4
Switch(config)# mls qos map dscp-cos 48 56 to 7
CPU QoS:
Switch(config)# cpu traffic qos dscp trust
Queuing:
Switch(config)# mls qos srr-queue output dscp-map queue 1 threshold 1 46

Switch(config)# mls qos srr-queue output dscp-map queue 2 threshold 3 34 36 38
Example 2
This example shows how to mark the DSCP of CPU-generated IP traffic (including IP-SLA and
TWAMP) based on the DSCP value in the packet.
• All IP traffic with the DSCP value 0 is assigned DSCP value 30.
• All IP traffic with the DSCP values af41 (34), af42 (36) and af43 (38) are assigned DSCP value 48.
• All other IP and non-IP traffic is processed by the default configuration.
Maps:

Switch(config)# mls qos map dscp-mutation mapname 0 to 30
Switch(config)# mls qos map dscp-mutation mapname 34 36 38 to 48
CPU QoS:
Switch(config)# cpu traffic qos dscp dscp-mutation mapname
Example 3
This example shows how to mark the precedence of CPU-generated IP traffic (including IP-SLA and
TWAMP) based on the precedence value in the packet.
• All CPU generated IP traffic with the precedence value 0 is assigned precedence value 3.
• All CPU generated IP traffic with the precedence values 2, 3 and 4 is assigned precedence value 6.
Maps:

Switch(config)# mls qos map dscp-mutation mapname 0 to 24
Switch(config)# mls qos map dscp-mutation mapname 16 24 32 to 48
CPU QoS:

34-100 OL-9644-10
Switch(config)# cpu traffic qos precedence precedence-mutation mapname
Note IP-DSCP and IP-precedence are related. To mark the precedence value of an IP packet based on the
incoming packet precedence value, an equivalent DSCP-mutation map needs to be configured and used
with the cpu traffic qos precedence precedence-mutation command. Queuing is based on the IP-DSCP
value of the packet.
Example 4
This example shows how to mark the DSCP of CPU-generated IP traffic (including IP-SLA and
TWAMP) based on the CoS value in the packet and to configure egress queuing based on the CoS value.
• All CPU-generated IP traffic is queued on the egress port based on the CoS value.
• All IP traffic with the CoS value 0 is assigned DSCP value 30.
• All IP traffic with the CoS values 6 and 7 is assigned DSCP value 56.
• Queues the CoS value 0 to queue 1 threshold 1.
• Queues the CoS values 6 and 7 to queue 2 threshold 3.
Maps:

Switch(config)# mls qos map cos-dscp 0 to 30
Switch(config)# mls qos map cos-dscp 6 7 to 56
CPU QoS:
Switch(config)# cpu traffic qos cos trust
Queuing:
Switch(config)# mls qos srr-queue output cos-map queue 1 threshold 1 0

Switch(config)# mls qos srr-queue output cos-map queue 2 threshold 3 6 7
Example 5
This example shows how to mark the CoS of CPU-generated IP traffic (including IP-SLA and TWAMP)
based on the precedence value in the packet and to configure egress queuing based on the DSCP value.
• All CPU-generated IP traffic is queued on the egress port based on the IP-DSCP value.
• All IP traffic with the precedence value 3, which simulates voice traffic, is assigned CoS value 5.
• All IP traffic with the precedence values 4 and 5 are assigned CoS value 7.
• Queues the DSCP value 24 (equivalent to precedence value 3) to queue 1 threshold 1.
• Queues the DSCP values 32 and 40 (equivalent to precedence values 4 and 5) to queue 2 threshold 3.

OL-9644-10 34-101
Displaying Standard QoS Information
Maps:

Switch(config)# mls qos map dscp-cos 24 to 5
Switch(config)# mls qos map dscp-cos 32 40 to 7
CPU QoS:
Switch(config)# cpu traffic qos precedence trust
Queuing:
Switch(config)# mls qos srr-queue output dscp-map queue 1 threshold 1 24

Displaying Standard QoS Information

To display standard QoS information, use one or more of the privileged EXEC commands in
Table 34-16:
Table 34-16 Commands for Displaying Standard QoS Information
Command Purpose
show class-map [class-map-name] Display QoS class maps, which define the match criteria to
classify traffic.
show cpu traffic qos Display QoS parameters for control plane traffic.
show mls qos Display global QoS configuration information.
show mls qos aggregate-policer Display the aggregate policer configuration.
[aggregate-policer-name]
show mls qos input-queue Display QoS settings for the ingress queues.
show mls qos interface [interface-id] [buffers | policers | Display QoS information at the port level, including the buffer
queueing | statistics] allocation, which ports have policers, the queueing strategy, and
the ingress and egress statistics.
show mls qos maps [cos-dscp | cos-input-q | Display QoS mapping information.
cos-output-q | dscp-cos | dscp-input-q | dscp-mutation
dscp-mutation-name | dscp-output-q | ip-prec-dscp |
policed-dscp]
show mls qos queue-set [qset-id] Display the egress queue-set settings.

34-102 OL-9644-10
Configuring Hierarchical QoS
Table 34-16 Commands for Displaying Standard QoS Information (continued)
Command Purpose
show mls qos vlan vlan-id Display the policy maps attached to an SVI.
show policy-map [policy-map-name [class Display QoS policy maps, which define the traffic policy for a
class-map-name]] traffic class.
show policy-map interface interface-id [input] Display the ingress policy-map name applied to the specified
port.
Note The show policy-map interface command displays data
for hierarchical policy-maps attached to the ES
interfaces. This command does not show counters for
non-hierarchical policies on the ES interfaces, or any
policies attached to non-ES interfaces.

You can configure hierarchical QoS (traffic classification, CBWFQ, LLQ, shaping, and two-rate,
three-color policing) and apply it to inbound or outbound traffic on an ES port or on an EtherChannel
consisting of ES ports.
Before configuring hierarchical QoS, you must know the requirements for your network:
• The types of applications used and the traffic patterns on your network.
• Traffic characteristics and needs of your network. Is the traffic bursty? Do you need to reserve
bandwidth for voice and video streams?
• Bandwidth requirements and speed of the network.
• Location of congestion points in the network.
These sections describe how to configure hierarchical QoS on your switch. Read these sections if traffic
is flowing from a standard or an ES port to an Etherchannel ES port:
• Hierarchical QoS Configuration, page 34-103
• Hierarchical QoS Configuration Guidelines, page 34-104
• Hierarchical QoS Over EtherChannel Configuration Guidelines, page 34-106
• Configuring a Hierarchical QoS Policy, page 34-107 (required)
Hierarchical QoS Configuration

QoS is disabled.
No traffic classes, class maps, policy maps, or policers are defined.
LLQ is disabled.
CBWFQ is disabled.
Tail drop is enabled.
WRED is disabled.
Average-rate traffic shaping is disabled.

OL-9644-10 34-103
Hierarchical QoS Configuration Guidelines

These hierarchical QoS configuration guidelines apply to ingress and egress service-policies on an ES
port or an ES EtherChannel (an EtherChannel consisting of ES ports)
• QoS must be enabled with the mls qos global configuration command for any hierarchical
configuration to take effect. When enabled, QoS uses the default settings described in the “Standard
QoS Configuration” section on page 34-50 and the “Hierarchical QoS Configuration” section on
page 34-103. For detailed steps, see the “Enabling QoS Globally” section on page 34-56.
• Beginning with Cisco IOS Release 12.2(35)SE, you can attach a hierarchical service policy to an
EtherChannel of ES ports. You can use the policy to configure hierarchical policies on ES ports
without configuring QoS classification, policing, mapping, and queueing on the individual ES ports
in the EtherChannel. If you configure a hierarchical policy on an EtherChannel that has no ports and
then add a standard port to the EtherChannel, the policy is removed from the EtherChannel. See the
“Hierarchical QoS Over EtherChannel Configuration Guidelines” section on page 34-106 for more
information about this feature.
• Class maps that contain ACLs are not supported in either an egress policy or in a hierarchical ingress
policy attached to an ES port or EtherChannel. You cannot configure the match access-group
acl-index-or-name class-map configuration command in a hierarchical policy map.
• To configure a class map that matches an IEEE 802.1Q tunneling pair (instead of matching a single
VLAN), you must configure the class-map global configuration command with the match-all
keyword. You must enter the match vlan command before the match vlan inner command.
• You cannot have the match vlan {vlan-id | inner vlan-id} and match {cos [inner] cos-list | ip dscp
dscp-list | ip precedence ip-precedence-list | mpls experimental exp-list} class-map configuration
commands in the same class map.
• You cannot mix VLAN-level and class-level matches within a class map.
• When port trust policies are used with IEEE 802.1Q tunneling, all ports sharing the same tunnel
VLAN must be configured with the same trust policy.
• Only one policy map per port is supported. You can attach one input hierarchical service policy and
one output service policy per ES port or EtherChannel.
• You cannot apply an output policy map with only one level to an ingress ES port or EtherChannel.
• When a trust policy and a hierarchical ingress policy are both configured on an ES port or
EtherChannel, the actions specified in the service policy are processed before the trust policy is
applied.
• If an ingress hierarchical policy map includes the set policy-map class configuration command, the
switch automatically applies the port trust state to the ES port or EtherChannel. The switch applies
the port trust state to all inbound traffic on the port or EtherChannel, including traffic that does not
match the traffic class. For example, if you enter the set cos new-cos command, the switch
automatically configures the interface to trust CoS.
• If an input hierarchical policy map sets QoS values by using explicit set actions or policing actions,
the ES port or EtherChannel must also have the appropriate trust policy configured. For example, if
the policy modifies CoS, then the ES port or EtherChannel must trust CoS; if the policy modifies
DSCP, the ES port must trust DSCP. If the ingress policy contains a mix of Layer 2 and Layer 3 QoS
modifications, the policy cannot be attached.
• If an egress hierarchical policy map includes the set policy-map class configuration command, the
port trust state is not affected. For example, setting the CoS to 2 only affects the CoS value of the
packet, and the DSCP value of the packet is not modified based on the CoS-to-DSCP map.

34-104 OL-9644-10
• In an ingress policy map, you cannot combine Layer 2 and Layer 3 set actions because the port can
trust only one value in the inbound packet. For example, the switch does not support this policy map:
policy-map p1
class cos1
police cir per 10 conform-action set-cos-transmit 3
set dscp af22
• On an ES port or EtherChannel, the only limit to the number of policers configured in a hierarchical
service-policy is the finite number of classes that can be configured. For more information, see the
“Hierarchical Levels” section on page 34-30.
• If you configure the conform-action, exceed-action, violate-action in a two-rate ingress policer
and set the CoS, DSCP, or IP precedence values of the packet by using the set-cos-transmit new-cos,
set-dscp-transmit new-dscp, or the set-prec-transmit new-prec options, the switch automatically
applies the port trust state to all traffic received on the ES port or EtherChannel, including traffic
that does not match the traffic class with the two-rate policer.
• You cannot combine Layer 2 (set-cos-transmit new-cos) and Layer 3 (set-dscp-transmit new-dscp,
or the set-prec-transmit new-prec) actions in a two-rate ingress policer because the port can trust
only one value in the inbound packet (CoS, DSCP, or IP precedence). For example, you cannot
configure the police cir percent 10 conform-action set-cos-transmit 3 exceed-action set
dscp-transmit af22 command. The conform-action sets the CoS value to 3, but the exceed-action
sets the DSCP value to af22.
• Use the configuration procedures in this section to configure hierarchical multiple-level policies on
ES ports or EtherChannels. Many of the configuration options are not supported in single-level
policy maps attached to ES ports.
• If you want to use a hierarchical ingress single-level service-policy (for example, a two-rate ingress
policer on an ES port or EtherChannel), you must create a second level in the hierarchy with only
the class-default in the policy map. For example, in the policy map, specify class-default as the class
name in the class policy-map configuration command.
• You can define a class policy to use either tail drop through the queue-limit policy-map class
configuration command or to use WRED packet drop through the random-detect policy-map class
configuration command. You cannot use the queue-limit and random-detect commands in the same
class policy, but they can be used in two class policies in the same policy map.
• You cannot use bandwidth, queue-limit, random-detect, and shape policy-map class
configuration commands with the priority policy-map class configuration command in the same
class within the same policy map. However, you can use these commands in different classes in the
same policy map. Within a policy map, you can give priority status to only one class.
• You must configure the bandwidth or the shape policy-map class configuration command before
you configure either the queue-limit or the random-detect policy-map class configuration
command in a class policy. You must configure the bandwidth or the shape command in the same
policy map as the queue-limit or the random-detect command if the policy is not using the traffic
class. If the policy is using the traffic class, you do not need to specify the bandwidth and shape
commands in the policy map.
• A policy map can have all the class bandwidths specified in either kb/s or in percentages, but not a
mix of both. You cannot specify bandwidth in kb/s in a child policy (configured through the
service-policy policy-map class configuration command) and then specify bandwidth as a
percentage in the parent policy.
• In a child policy map, the minimum bandwidth of each class map must be more than 0.01 percent
of the total bandwidth of the parent policy map. When class-default class is not configured in the
child policy map, this minimum bandwidth map is reserved for the class-default class.

OL-9644-10 34-105
• The total bandwidth configured in a child policy map cannot exceed the total bandwidth of the parent
policy map.
Hierarchical QoS Over EtherChannel Configuration Guidelines

Beginning with Cisco IOS Release 12.2(35)E, hierarchical QoS is supported on EtherChannels
consisting of Catalyst 3750 Metro ES ports. When you configure an EtherChannel with both ES ports
and apply a hierarchical policy to it, hierarchical QoS is applied to traffic flowing through both ports.
After all hierarchical QoS rules (including policing, shaping, bandwidth, and priority) are applied,
packets are sent from the correct physical interface. Hierarchical QoS rules apply to the entire
EtherChannel. Standard EtherChannel redundancy and load balancing also occurs based on the type of
configuration. Because EtherChannels are logical interfaces, there are some differences in hierarchical
QoS over EtherChannels compared to hierarchical QoS over ES ports.
This section lists guidelines and features of hierarchical QoS over EtherChannel, including differences
in behavior compared to ES ports. Cisco IOS Release 12.2(35)SE does not change hierarchical QoS on
ES ports.
• Hierarchical QoS is supported for ingress and egress traffic for EtherChannels.
• Hierarchical policies are supported only on EtherChannels made of ES ports. They are not supported
on EtherChannels consisting of standard ports.
• You can attach a hierarchical policy to an EtherChannel consisting of ES ports only if no other
policies are attached to the individual ES ports.
• You can attach a hierarchical policy to an EtherChannel that contains no ports. However, the policy
is not effective until you add oan ES port to the EtherChannel.
• If an EtherChannel has only one active ES port, an attached hierarchical policy the EtherChannel
acts exactly like a hierarchical policy on the individual ES port.
• If you add a standard port to an empty EtherChannel that has a hierarchical policy attached to it, the
port is added to the EtherChannel, but the hierarchical policy is removed. Hierarchical policies are
supported only on EtherChannels with ES ports.
• Hierarchical QoS on an EtherChannel does not affect the EtherChannel load balancing. If both ES
ports in an EtherChannel are active, traffic for the ports is queued for hierarchical QoS and then sent
to the original target interface.
• Parameters for actions (such as bandwidth and policing) must be configured as either absolute
values or as percentages across all classes of the hierarchical policy map. The configuration
determines whether the policy is a load-balancing or a redundancy application.
– When you configure all hierarchical QoS parameters as absolute values, the total configurable
bandwidth is limited to the bandwidth of one of the links (990,000,000 bits per second), which
results in redundancy.
– When you configure all hierarchical parameters as percentage values, you can configure
100 percent of the bandwidth. When both links are up, the bandwidth is approximately 2
Gigabits (two times 990,000,000 bits per second). If one link goes down, the bandwidth
becomes 1 Gigabit, and all policies are scaled down. The percentages remain the same, which
results in load balancing. The switch does not support percentage shaping for load balancing.
• For policing policies configured in percentages, an internal limitation sets the maximum policing
parameter to 990,000,000 bits per second. If a link state change causes the policing value to be
greater than this value, the policy is detached. Therefore, when you configure the percentage for an

34-106 OL-9644-10
EtherChannel with both ES links, you should limit each policer to a maximum of 49 percent.
However, you can configure multiple policers in the same policy or across parent and child policies
with each configured to 49 percent maximum.
• When ES link states change hierarchical QoS parameters configured as absolute values or
percentages:
– If you configure parameters in absolute values, the total guaranteed bandwidth cannot be more
than 990,000,000 bits per second. If one link in the EtherChannel goes down, all traffic goes in
or out of the other physical interface instead of being distributed between the two ES ports. No
values are recalculated, and there are no changes to hierarchical QoS parameters or policy
enforcement.
– If you configure parameters in percentages and one link in the EtherChannel goes down, all
absolute parameters are reduced by half, although the configured percentage remains the same.
For bandwidth percentage configuration, all traffic is sent or received with the reduced
bandwidth parameters distributed fairly. For policing percentage configuration, packets are
dropped according to the reduced parameters so that other traffic is not affected.
• The switch does not support shaping percentages for hierarchical QoS for ES ports or
EtherChannels. Therefore, you cannot configure policing or bandwidth in percentages with any type
of shaping for policies applied to an EtherChannel.
• If you simultaneously attach both egress and ingress EtherChannel hierarchical policies, you must
configure both policies in either absolute values or in percentages. You cannot configure an ingress
policy with percentages and an egress policy with an absolute value or the reverse.
Configuring a Hierarchical QoS Policy

These sections describe how to configure a hierarchical QoS policy to create a service policy that is
attached to an ES port or to an EtherChannel made of ES ports.
For more information, see the “Hierarchical Levels” section on page 34-30, the “Hierarchical
Classification Based on Traffic Classes and Traffic Policies” section on page 34-33, the “Hierarchical
Policies and Marking” section on page 34-34, and the “Queueing and Scheduling of Hierarchical
Queues” section on page 34-37. For configuration guidelines, see the “Hierarchical QoS Configuration
Guidelines” section on page 34-104.
Depending on your network configuration and QoS solution, you must perform some of these tasks if
you want classify, policy, mark, queue, or schedule traffic:
• Classifying Traffic by Using Hierarchical Class Maps, page 34-108 (required)
• Configuring a Hierarchical Two-Rate Traffic Policer, page 34-110 (optional)
• Configuring Class-Based Packet Marking in a Hierarchical Traffic Policy, page 34-114 (optional)
• Configuring CBWFQ and Tail Drop, page 34-116 (optional)
• Configuring CBWFQ and DSCP-Based WRED, page 34-119 (optional)
• Configuring CBWFQ and IP Precedence-Based WRED, page 34-123 (optional)
• Enabling LLQ, page 34-127 (optional)
• Configuring Shaping, page 34-129 (optional)

OL-9644-10 34-107
Classifying Traffic by Using Hierarchical Class Maps

You use the class-map global configuration command to create a class map for matching packets to the
class whose name you specify. The class map isolates a specific traffic flow (class) from all other traffic
by defining the criteria to use to match against a specific flow. The match criterion is defined with a
match statement entered within the class-map configuration mode. Packets are compared to the match
criteria configured for a class map. If a packet matches the specified criteria, the packet is considered a
member of the class and is forwarded according to the QoS specifications set in the traffic policy.
Beginning in privileged EXEC mode, follow these steps to create a class-level class-map and to define
the match criterion to classify traffic. This procedure is required. The examples that follow the procedure
show how to create a class-level and a VLAN-level class-map.
Command Purpose
Step 2 class-map [match-all | match-any] Create a class map, and enter class-map configuration mode.
class-map-name
of all matching statements under this class map. All criteria in the
class map must be matched.
• (Optional) Use the match-any keyword to perform a logical-OR
of all matching statements under this class map. One or more
If neither the match-all nor the match-any keyword is specified, the
default is match-all. You must use the match-all keyword if you are
matching an IEEE 802.1Q tunneling pair (instead of matching a single
VLAN).

34-108 OL-9644-10
Command Purpose
Step 3 match {cos [inner] cos-list | ip dscp Define the match criterion to classify traffic.
dscp-list | ip precedence ip-precedence-list By default, no match criterion is defined.
| mpls experimental exp-list | vlan {vlan-id
| inner vlan-id}} • For cos [inner] cos-list, specify up to four Layer 2 CoS values to
match against the packet. Separate each value with a space. The
range is 0 to 7. Use the inner keyword to match the inner CoS
value in 802.1Q tunneling traffic (instead of matching the outer
CoS value).
• For ip dscp dscp-list |, specify up to eight IP DSCP values to match
against the packet. Separate each value with a space. The range is
0 to 63.
• For ip precedence ip-precedence-list, specify up to eight
IP-precedence values to match against the packet. Separate each
value with a space. The range is 0 to 7.
• For mpls experimental exp-list, specify up to eight MPLS EXP
values to match against the packet. Separate each value with a
space. The range is 0 to 7.
• For vlan {vlan-id | inner vlan-id}, specify packet match based on
the VLAN ID.
– For vlan vlan-id, match a packet based on the VLAN ID, or
match a packet based on the outer VLAN ID if an
IEEE 802.1Q tunnel is configured. You can specify a single
VLAN identified by a VLAN number or a range of VLANs
separated by a hyphen. The range is 1 to 4094.
– For vlan inner vlan-id, match a packet based on the inner
VLAN ID of an IEEE 802.1Q tunnel.You can specify a single
VLAN identified by a VLAN number or a range of VLANs
separated by a hyphen. The range is 1 to 4094.
When matching an IEEE 802.1Q tunneling pair (instead of
matching a single VLAN), you must enter the match vlan
command before the match vlan inner command.
Note You cannot mix VLAN-level and class-level matches within a
class map.
Step 5 show class-map Verify your entries.
To delete an existing class map, use the no class-map [match-all | match-any] class-map-name global
configuration command. To remove a match criterion, use the no match {cos [inner] cos-list | ip dscp
dscp-list | ip precedence ip-precedence-list | mpls experimental exp-list | vlan {vlan-id | inner
vlan-id}} class-map configuration command.
This example shows how to create a class-level class-map called class3, which matches traffic with
IP-precedence values of 5, 6, and 7:

OL-9644-10 34-109
This example shows how to create a VLAN-level class-map for IEEE 802.1Q tunneling called dot1q,
which matches all traffic with an outer VLAN ID of 5 and an inner VLAN ID of 3 to 8:
Switch(config)# class-map match-all dot1q
Switch(config-cmap)# match vlan inner 3 - 8
This example shows how to create a VLAN-level class-map called vlan203, which matches traffic in
VLAN 203:
Configuring a Hierarchical Two-Rate Traffic Policer

You can configure a two-rate traffic policer within a policy map at the class level, at the VLAN level,
and at the physical level by using the police cir or the police cir percent policy-map class configuration
command. At the physical level of the hierarchy, you can police only the class-default class in a policy
attached to an ES port or EtherChannel.
The policer limits the transmission rate of a traffic class and marks actions (conform, exceed, and
violate) for each packet. Within the conform, exceed, and violate categories, you decide packet
treatments. In the most common configurations, you configure packets that conform to be sent, packets
that exceed to be sent with a decreased priority, and packets that violate to be dropped. You can decrease
the priority of the CoS, the DSCP, the IP precedence, or the MPLS EXP bits in the packet. You configure
the policer by using the police cir policy-map class configuration command.
You can also use the police cir percent policy-map class configuration command to configure a traffic
policer that uses two rates, the CIR and the PIR. The switch calculates the CIR and PIR based on a
percentage of the maximum amount of bandwidth assigned to the parent class. The maximum bandwidth
is controlled by the shape policy-map class configuration command if it is configured. Otherwise, the
maximum bandwidth is the physical port bandwidth (1 Gb/s). For more information about the interaction
between the police cir percent command and the shape command, see the police cir percent command
in the command reference for this release.
more information, see the “Classifying Traffic by Using Hierarchical Class Maps” section on
page 34-108.
Beginning in privileged EXEC mode, follow these steps to configure a class-level, two-rate traffic
policer in a service policy. This procedure is optional. The examples that follow the procedure show how
to configure a class-level, a VLAN-level, and a physical-level policer.
Command Purpose

34-110 OL-9644-10
Command Purpose
Step 4 police cir cir [bc conform-burst] pir pir Configure a traffic policer that uses two rates, the CIR and the peak
[be peak-burst] [conform-action action information rate PIR. By default, no policer is defined.
[exceed-action action [violate-action
• For cir cir, specify the CIR at which the first token bucket is
action]]]
updated. The range is 64000 to 990000000 b/s.
or
• (Optional) For bc conform-burst, specify the conform burst size
police cir percent percent [bc used by the first token bucket for policing. The range is 1536 to
conform-burst ms] | pir percent percent 16776960 bytes. The default is 8192.
[be peak-burst ms] [conform-action
• For pir pir, specify the PIR at which the second token bucket for
action [exceed-action action
policing is updated. The range is 64000 to 990000000 b/s.
[violate-action action]]]
• (Optional) For be peak-burst, specify the peak burst size used by
Note For the syntax description of the the second token bucket. The range is 1536 to 16776960 bytes. The
police cir percent command, see default is 8192.
the command reference for this
release. • (Optional) For conform-action, specify the action to perform on
packets that conform to the CIR and PIR.
• (Optional) For exceed-action, specify the action to perform on
packets that conform to the PIR but not the CIR.
• (Optional) For violate-action, specify the action to perform on
packets that exceed the PIR.
Note If you do not specify an action, the default conform-action is
transmit, the exceed-action is drop, and the default
violate-action is drop.
• (Optional) For action, specify the action to perform on packets:

– drop—drop the packet.
– set-cos-transmit new-cos—set the CoS value to a new value,
and send the packet. The range is 0 to 7.
– set-dscp-transmit new-dscp—set the IP DSCP value to a new
value, and send the packet. The range is 0 to 63. You also can
enter a mnemonic name for a commonly used value.
– set-mpls-exp-transmit new-exp—set the MPLS EXP bits,
and send the packet. The range is 0 to 7.
– set-prec-transmit new-prec—set the IP precedence value to a
new value, and send the packet. The range is 0 to 7.
– transmit—send the packet without altering it.
If you set the CIR equal to the PIR, a traffic rate that is less than the
CIR or that meets the CIR is in the conform range. Traffic that exceeds
the CIR rate is in the violate range.
If you set the PIR greater than the CIR, a traffic rate that is less than
the CIR is in the conform range. A traffic rate that exceeds the CIR but
is less than or equal to the PIR is in the exceed range. A traffic rate that
exceeds the PIR is in the violate range.
Setting the burst sizes too low can result in less traffic than expected,
and setting them too high can result in more traffic than expected.

OL-9644-10 34-111
Command Purpose
Step 7 interface interface-id Specify an ES port or an EtherChannel port channel, and enter
Step 8 service-policy {input | output} Specify the policy-map name, and apply it to the ES port or
policy-map-name EtherChannel.
Step 10 show policy-map policy-map-name Verify your entries.
or
show policy-map interface interface-id
To remove the two-rate policer, use the no police cir cir [bc conform-burst] pir pir [be peak-burst]
[conform-action action [exceed-action action [violate-action action]]] policy-map class configuration
command. To remove the policy map and interface association, use the no service-policy output
policy-map-name interface configuration command.
Note If you apply the policy map to an EtherChannel with no ports and then add a standard port to the
EtherChannel, the policy is removed from the EtherChannel because standard ports do not support
hierarchical QoS.
This example shows how to configure a class-level, two-rate traffic policer to limit outbound traffic to
an average committed rate of 500 kb/s and a peak rate of 1 Mb/s. Traffic marked as conforming to the
average committed rate (500 kb/s) is sent as is. Traffic marked as exceeding 500 kb/s, but not exceeding
1 Mb/s, is marked with IP precedence 2 and then sent. All traffic marked as exceeding 1 Mb/s is dropped.
The burst parameters are set to 10000 bytes.
This example shows how to configure a class-level, two-rate traffic policer that uses a CIR and a PIR
based on a percentage of bandwidth. A CIR of 20 percent and a PIR of 40 percent are specified. The
optional bc and be values (300 ms and 400 ms, respectively) are specified.
Switch(config-pmap)# class class1
Switch(config-pmap-c)# police cir percent 20 bc 300 ms pir percent 40 be 400 ms

34-112 OL-9644-10

This example shows how to configure a VLAN-level, two-rate traffic policer to limit outbound traffic to
an average committed rate of 500 kb/s and a peak rate of 1 Mb/s. Traffic marked as conforming to the
average committed rate (500 kb/s) is sent as is. Traffic marked as exceeding 500 kb/s, but not exceeding
1 Mb/s, is marked with IP precedence 2 and then sent. All traffic marked as exceeding 1 Mb/s is dropped.
The burst parameters are set to 10000 bytes.
Switch(config-cmap)# match vlan inner 206
Switch(config-if)# service-policy output vlan-policy
This example shows how to create a hierarchical service-policy in which all levels are present. This
configuration associates a class-level policy map with a VLAN-level policy map, associates the
VLAN-level policy map with a physical-level policy map, and attaches the physical-level policy map to
a physical port.
Within a policy map, the class-default applies to all traffic that is not explicitly matched within the policy
map but does match the parent policy. If no parent policy is configured, the parent policy represents the
physical port. In a physical-level policy map, class-default is the only class that can be configured.
Switch(config)# service-policy input my-physical-policy

OL-9644-10 34-113
This example shows how to configure a class-level, two-rate traffic policer that uses a CIR based on a
percentage of bandwidth. A CIR of 5 percent is specified. The switch sets the DSCP value to 16 in
packets that conform to the CIR. The port trust state is automatically set to trust CoS.
Switch(config-cmap)# match 1p dscp 8 9 10 11
Switch(config-pmap-c)# police cir percent 5 conform action set-dscp-transmit 16
Configuring Class-Based Packet Marking in a Hierarchical Traffic Policy

You can perform class-based packet marking in a hierarchical traffic policy by configuring the set {cos
new-cos | dscp new-dscp | precedence new-precedence | mpls experimental exp-number} policy-map
class configuration command in an policy map attached to an ES port or EtherChannel.
more information, see the “Classifying Traffic by Using Hierarchical Class Maps” section on
page 34-108.
Beginning in privileged EXEC mode, follow these steps to configure class-level, class-based packet
marking in a service policy. This procedure is optional. The examples that follow the procedure show
how to configure class-level and VLAN-level class-based packet marking.
Command Purpose
Step 4 set {cos new-cos | dscp new-dscp | set Designate the value to set in the traffic class if the packets match the
precedence new-precedence | mpls criteria.
experimental exp-number}
• For cos new-cos, enter the new CoS value assigned to the
• For dscp new-dscp, enter the new DSCP value assigned to the
classified traffic. The range is 0 to 63. The specified value sets the
ToS byte in the packet header.
• For precedence new-precedence, enter the new IP-precedence
value assigned to the classified traffic. The range is 0 to 7. The
specified value sets the precedence bit in the IP header.
• For mpls experimental exp-number, enter the new MPLS EXP
value assigned to the classified traffic. The range is 0 to 7. The
specified value sets the MPLS EXP 3-bit field in the packet
header.

34-114 OL-9644-10
Command Purpose
class-map-name]]
or
To remove an assigned value, use the no set {cos new-cos | dscp new-dscp | precedence new-precedence
| mpls experimental exp-number} policy-map class configuration command. To remove the policy map
and interface association, use the no service-policy output policy-map-name interface configuration
command.
hierarchical QoS.
This example shows how to create a class-level policy map called out_pmap. When it is attached to the
ES port, it matches packets with MPLS EXP field 2 and resets this field to 3.
Switch(config)# class-map mpls_2
Switch(config)# policy-map out-pmap
Switch(config-pmap)# class mpls_2
Switch(config-if)# service-policy output out-pmap
This example shows how to create a VLAN-level policy map called log-policy. It matches packets with
VLAN 203 and associates a class-level child policy called cls-policy. The child policy matches packets
with MPLS EXP 2 and resets them to 5.

OL-9644-10 34-115
Switch(config-if)# service-policy input log-policy
This example shows how to create a class-level policy map called p-set. When it is attached to the ES
port, it matches packets with CoS field 4 and resets this field to 3. The port trust state is automatically
set to trust CoS.
Switch(config-cmap)# match cos inner 4
Switch(config)# policy-map p-set
Switch(config-pmap-c)# set cos 3
Switch(config-if)# service-policy output p-set
Configuring CBWFQ and Tail Drop

CBWFQ creates a queue for every class for which a class map is defined. Packets satisfying the match
criteria for a class accumulate in the queue reserved for the class until they are sent, which occurs when
the queue is serviced by the fair queue process. When the maximum packet threshold that you defined
for the class is reached, any more packets destined for the class queue are dropped according to the tail
drop or WRED mechanism.
You configure tail drop by using the queue-limit policy-map class configuration command in a policy
map attached to an ES port or EtherChannel. This command configures the maximum threshold for tail
drop. Packets are queued until the maximum threshold is exceeded, and then all the packets are dropped.
Before beginning this procedure, make sure that you have reviewed the configuration guidelines and
have created the class map to isolate traffic. For more information, see the “Hierarchical QoS
Configuration Guidelines” section on page 34-104 and the “Classifying Traffic by Using Hierarchical
Class Maps” section on page 34-108. For information on how to configure WRED, see the “Configuring
CBWFQ and DSCP-Based WRED” section on page 34-119.
Beginning in privileged EXEC mode, follow these steps to configure class-level CBWFQ and tail drop
in a hierarchical service policy. This procedure is optional. The examples that follow the procedure show
how to configure class-level and VLAN-level CBWFQ and tail drop.
Command Purpose

34-116 OL-9644-10
Command Purpose
Step 4 bandwidth {bandwidth-kbps | percent Specify the minimum bandwidth provided to a class belonging to the
percent} policy map when there is traffic congestion in the switch. If the switch
is not congested, the class receives more bandwidth than you specify
with the bandwidth command.
CBWFQ derives the weight for packets belonging to the class from the
bandwidth allocated to the class. CBWFQ then uses the weight to
ensure that the queue for the class is serviced fairly.
By default, no bandwidth is specified.
You can specify the bandwidth in kb/s or as a percentage:
• For bandwidth-kbps, specify the bandwidth amount in kb/s
assigned to the class. The range is 200 to 2000000. Allocate the
bandwidth in 100-kb/s increments; otherwise, the software rounds
down the bandwidth to the nearest 100-kb/s increment.
• For percent percent, specify the percentage of available
bandwidth assigned to the class. The range is 1 to 100. The sum of
the class bandwidth percentages within a single policy map cannot
exceed 99 percent. Percentage calculations are based on the
bandwidth available at the parent class (or the physical level if it
is the parent).
Specify all the class bandwidths in either kb/s or in percentages, but
not a mix of both. The amount of bandwidth configured should be large
enough to accommodate Layer 2 overhead.
Step 5 queue-limit limit Configure the maximum threshold for tail drop.
For limit, the range is 1 to 32768 packets. The default is 128 packets.
class-map-name]]
or

OL-9644-10 34-117
To return to the default bandwidth, use the no bandwidth policy-map class configuration command. To
return to the default maximum threshold, use the no queue-limit policy-map class configuration
command.
hierarchical QoS.
This example shows how to create a class-level policy map called policy11 for three classes called prec1,
prec2, and prec3. In the policy for these classes, 30 percent of the available bandwidth is assigned to the
queue for the first class, 20 percent is assigned to the queue for the second class, and 10 percent is
assigned to the queue for the third class. Tail drop is enabled on each class queue, packets are queued
until the maximum threshold of 2000 packets is exceeded, and then all the packets are dropped.
Switch(config)# class-map prec1
Switch(config-pmap)# class prec1
Switch(config-pmap-c)# queue-limit 2000
This example shows how to create a VLAN-level policy map called vlan-policy for two classes called
vlan203 and vlan202. In the policy for these classes, the minimum bandwidth is set to 2000 kb/s.
Switch(config-pmap-c)# bandwidth 2000

34-118 OL-9644-10
This example shows how to create a VLAN-level policy map called log-policy. It matches packets with
VLAN 203 and associates a class-level child policy called cls-policy. The child policy matches packets
with a CoS value of 2, sets 50 percent as the available bandwidth for this class, and sets 2000 packets as
the maximum threshold for tail drop. Packets are queued until the maximum threshold is exceeded, and
then all the packets are dropped. Note that when you configure the bandwidth command in a class
policy, you also must configure the bandwidth or shape policy-map class configuration command in the
parent VLAN-level policy.
Switch(config-cmap)# match cos 2
Switch(config-cmalp)# match vlan 203
Switch(config-if)# service-policy output log-policy
Configuring CBWFQ and DSCP-Based WRED

the queue is serviced by the fair queue process. When the maximum packet threshold that you defined
for the class is reached, any more packets destined for the class queue are dropped according to the tail
drop or the WRED mechanism.
WRED reduces the chances of tail drop by selectively dropping packets when the port begins to show
signs of congestion. By dropping some packets early rather than waiting until the queue is full, WRED
avoids dropping large numbers of packets at once.
When a packet arrives and WRED is enabled, these events occur:
• The average queue size is calculate based on the previous average and the current size of the queue.
The average queue-size calculation is affected by the exponential weight constant setting in the
random-detect exponential-weight-constant policy-map class configuration command.
• If the average queue size is less than the minimum queue threshold, the arriving packet is queued.
The minimum queue threshold is configured through the min-threshold option in the random-detect
dscp policy-map class configuration command.

OL-9644-10 34-119
• If the average queue size is between the minimum queue threshold and the maximum queue
threshold, the packet is either dropped or queued, depending on the packet-drop probability. The
packet-drop probability is based on the minimum threshold, the maximum threshold, and the
mark-probability denominator. The maximum queue threshold is configured through the
max-threshold option, and the mark-probability denominator is configured through the
mark-prob-denominator option in the random-detect dscp policy-map class configuration
command.
• If the average queue size is greater than the maximum queue threshold, the packet is automatically
dropped.
You enable DSCP-based WRED by using the random-detect dscp-based policy-map class
configuration command in a policy map attached to an ES port or EtherChannel. This command allows
for preferential drop treatment among packets with different DSCP values. The WRED algorithm
discards or marks packets destined for a queue when that queue is congested. It discards packets fairly
and before the queue is full. If you want to enable IP precedence-based WRED instead of DSCP-based
WRED, see the “Configuring CBWFQ and IP Precedence-Based WRED” section on page 34-123.
Class Maps” section on page 34-108. For information on how to configure tail drop, see the
“Configuring CBWFQ and Tail Drop” section on page 34-116.
Beginning in privileged EXEC mode, follow these steps to configure class-level CBWFQ and
DSCP-based WRED in a hierarchical service policy. This procedure is optional. The examples that
follow the procedure show how to configure class-level and VLAN-level CBWFQ and DSCP-based
WRED.
Command Purpose

34-120 OL-9644-10
Command Purpose
is the parent).
Step 5 random-detect dscp-based Enable DSCP-based WRED as a drop policy. By default, WRED is
disabled.
Step 6 random-detect dscp dscp min-threshold Specify packet threshold and mark-probability values for a specific
max-threshold mark-prob-denominator DSCP value:
• For dscp, enter a DSCP value. The range is 0 to 63. You also can
enter a mnemonic name for a commonly used value.
• For min-threshold, enter the minimum threshold in packets. The
range is 1 to 32768. When the average queue size reaches the
minimum threshold, WRED randomly drops some packets with
the specified DSCP value.
• For max-threshold, enter the maximum threshold in packets. The
range is 1 to 32768. The default is 128. When the average queue
size exceeds the maximum threshold, WRED drops all packets
with the specified DSCP value.
• For mark-prob-denominator, enter the denominator for the
fraction of packets dropped when the average queue size is at the
maximum threshold. The range is 1 to 65535. The default is 10.
For example, if the denominator is 512, one out of every 512
packets is dropped when the queue is at the maximum threshold.
For a list of the default settings for a specified DSCP value, see the
command reference for this release.

OL-9644-10 34-121
Command Purpose
Step 7 random-detect (Optional) Configure the exponential weight factor for the average
exponential-weighting-constant weight queue-size calculation for WRED. The range is 1 to 16. The default
is 9.
class-map-name]]
or
disable DSCP-based WRED, use the no random-detect dscp-based policy-map class configuration
command. To return to the default WRED settings, use the no random-detect dscp dscp policy-map
hierarchical QoS.
This example shows how to configure a class-level policy called policy10. Class c1 has these
characteristics: a minimum of 2000 kb/s of bandwidth is expected to be delivered to this class in the event
of congestion, and a weight factor of 10 is used to calculate the average queue size. To avoid congestion,
DSCP-based WRED packet drop is used instead of tail drop. The minimum threshold for DSCP value 8
is 24, the maximum threshold is 40, and the mark-probability denominator is 512.
Switch(config-cmap)# match ip dscp 8
Switch(config-pmap-c)# random-detect dscp-based
Switch(config-pmap-c)# random-detect exponential-weighting-constant 10
Switch(config-pmap-c)# random-detect dscp 8 24 40 512

34-122 OL-9644-10
This example shows how to configure a VLAN-level policy called parent. It matches packets with VLAN
101 and associates a class-level child policy called policy1. The child policy matches two DSCP values
in two classes. Thirty percentage of the available bandwidth is assigned to the gold class, 20 percent is
assigned to the silver class, and 20 percent is assigned to vlan101. DSCP-based WRED is used as the
drop policy. For the af11 value in the gold class, WRED randomly drops packets with this DSCP when
the minimum threshold reaches 30. When the average queue size exceeds the maximum threshold of 40,
WRED drops all packets with DSCP af11. The mark-probability denominator is set to 10, which means
that one out of every 10 packets is dropped when the average queue is at the maximum threshold. The
configuration has similar settings for af12 in the gold class and for af21 and af22 in the silver class. Note
that when you configure the bandwidth command in a class policy, you also must configure the
bandwidth or shape policy-map class configuration command in the parent VLAN-level policy.
Switch(config)# class-map gold
Switch(config-cmap)# match ip dscp af11 af12
Switch(config)# class-map silver
Switch(config)# class-map vlan101
Switch(config-pmap)# class gold
Switch(config-pmap-c)# random-detect dscp af11 30 40 10
Switch(config-pmap)# class silver
Switch(config)# policy-map parent
Switch(config-pmap-c)# service-policy policy1
Switch(config-if)# service-policy output parent
Configuring CBWFQ and IP Precedence-Based WRED

the queue is serviced by the fair queue process. When the maximum packet threshold you defined for the
class is reached, any more packets destined for the class queue are dropped according to the tail drop or
the WRED mechanism.
WRED reduces the chances of tail drop by selectively dropping packets when the port begins to show
signs of congestion. By dropping some packets early rather than waiting until the queue is full, WRED
avoids dropping large numbers of packets at once.
You enable IP precedence-based WRED by using the random-detect precedence-based policy-map
class configuration command in a policy map attached to an ES port or EtherChannel. This command
allows for preferential drop treatment among packets with different IP precedence values. The WRED

OL-9644-10 34-123
algorithm discards or marks packets destined for a queue when that queue is congested. It discards
packets fairly and before the queue is full. Packets with high IP-precedence values are preferred over
packets with low IP-precedence values. If you want to enable DSCP-based WRED instead of IP
precedence-based WRED, see the “Configuring CBWFQ and DSCP-Based WRED” section on
page 34-119
Class Maps” section on page 34-108. For information on how to configure tail drop, see the
“Configuring CBWFQ and Tail Drop” section on page 34-116.
Beginning in privileged EXEC mode, follow these steps to configure class-level CBWFQ and IP
precedence-based WRED in a hierarchical service policy. This procedure is optional. The examples that
follow the procedure show how to configure class-level and VLAN-level CBWFQ and IP
precedence-based WRED.
Command Purpose
is the parent).

34-124 OL-9644-10
Command Purpose
Step 5 random-detect precedence-based Enable IP precedence-based WRED as a drop policy. By default,
WRED is disabled.
Step 6 random-detect precedence ip-precedence Specify packet threshold and mark-probability values for a specific IP
min-threshold max-threshold precedence value:
mark-prob-denominator
• For ip-precedence, specify an IP precedence value. The range is 0
to 7.
• For min-threshold, specify the minimum threshold in packets. The
range is 1 to 32768. When the average queue size reaches the
minimum threshold, WRED randomly drops some packets with
the specified precedence value.
• For max-threshold, specify the maximum threshold in packets.
The range is 1 to 32768. The default is 128. When the average
queue size exceeds the maximum threshold, WRED drops all
packets with the specified precedence value.
• For mark-prob-denominator, specify the denominator for the
fraction of packets dropped when the average queue size is at the
maximum threshold. The range is 1 to 65535. The default is 10.
For example, if the denominator is 512, one out of every 512
packets is dropped when the queue is at the maximum threshold.
For a list of the default settings for a specified IP precedence value, see
the command reference for this release.
Step 7 random-detect (Optional) Configure the exponential weight factor for the average
exponential-weighting-constant weight queue-size calculation for WRED. The range is 1 to 16. The default
is 9.
class-map-name]]
or
disable IP precedence-based WRED, use the no random-detect precedence-based policy-map class
configuration command. To return to the default WRED settings, use the no random-detect precedence
ip-precedence policy-map class configuration command.

OL-9644-10 34-125
hierarchical QoS.
This example shows how to configure a class-level policy called policy10. Class c1 has these
characteristics: a minimum of 2000 kb/s of bandwidth is expected to be delivered to this class in the event
of congestion, and a weight factor of 10 is used to calculate the average queue size. To avoid congestion,
WRED packet drop is used instead of tail drop. IP precedence is reset for levels 0 to 2. The minimum
threshold for IP precedence value 0 is 32, the maximum threshold is 256, and the mark-probability
denominator is 100. IP precedence values 1 and 2 have similar thresholds and probability denominators.
Switch(config-pmap-c)# random-detect precedence-based
Switch(config-pmap-c)# random-detect exponential-weighting-constant 10
Switch(config-pmap-c)# random-detect precedence 0 32 256 100
101 and associates a class-level child policy called policy1. The child policy matches two IP precedence
values in two classes. Thirty percentage of the available bandwidth is assigned to the gold class, 20
percent is assigned to the silver class, and 30 percent is assigned to vlan101. IP precedence-based WRED
is used as the drop policy. For the IP precedence 0 in the gold class, WRED randomly drops packets with
this IP precedence when the minimum threshold reaches 30. When the average queue size exceeds the
maximum threshold of 40, WRED drops all packets with IP precedence 0. The mark-probability
denominator is set to 10, which means that one out of every 10 packets is dropped when the average
queue is at the maximum threshold. The configuration has similar settings for IP precedence 3 in the
silver class. Note that when you configure the bandwidth command in a class policy, you also must
configure the bandwidth or shape policy-map class configuration command in the parent VLAN-level
policy.

34-126 OL-9644-10

Enabling LLQ
LLQ provides strict-priority queueing for a traffic class. It enables delay-sensitive data, such as voice,
to be sent before packets in other queues are sent. The priority queue is serviced first until it is empty.
Only one traffic stream can be destined for the priority queue per class-level policy. The priority queue
restricts all traffic streams in the same hierarchy, and you should use care when configuring this feature.
You enable the priority queue for a traffic class by using the priority policy-map class configuration
command in a policy map attached to an ES port or EtherChannel.
Note To avoid losing priority traffic on an ES port when the switch is congested, you can use both
strict-priority queueing and egress priority queueing. Note that when you map certain traffic classes to
the egress priority queue, they are not automatically placed into the strict-priority queue. You must enter
both the priority policy-map class configuration and the priority-queue out interface configuration
commands. For more information, see the “Configuring the Egress Priority Queue” section on
page 34-97.
Class Maps” section on page 34-108.
Beginning in privileged EXEC mode, follow these steps to enable class-level priority queueing in a
hierarchical service policy. This procedure is optional. The examples that follow the procedure show
how to enable class-level and VLAN-level priority queueing.
Command Purpose
Step 4 priority Enable the strict-priority queue, and give priority to a class of traffic.
By default, strict-priority queueing is disabled.

OL-9644-10 34-127
Command Purpose
class-map-name]]
or
To disable the priority queue, use the no priority policy-map class configuration command.
This example shows how to configure a class-level policy called policy1 that has two classes. Class 1 has
10 percent of the available bandwidth. Class 2 is configured as the priority queue, which is serviced first
until it is empty.
Switch(config-cmap)# match mpls experimental 2 3 4
Switch(config-pmap-c)# priority
101 and associates a class-level child policy called policy1. The gold class is configured as the priority
queue, whereas the silver class and vlan101 class each have 20 percent of the available bandwidth
assigned to them. DSCP-based WRED is used as the drop policy. For the af21 value in the silver class,
WRED randomly drops packets with this DSCP when the minimum threshold reaches 28. When the
average queue size exceeds the maximum threshold of 35, WRED drops all packets with DSCP af21.
The mark-probability denominator is set to 10, which means that one out of every 10 packets is dropped
when the average queue is at the maximum threshold. The configuration has similar settings for af22 in
the silver class.

34-128 OL-9644-10

Switch(config-pmap-c)# priority
Configuring Shaping
Shaping provides a process for delaying out-of-profile packets in queues so that they conform to a
specified profile. Shaping is distinct from policing. Policing drops packets that exceed a configured
threshold, but shaping buffers packets so that traffic remains within a threshold. Shaping offers greater
smoothness in handling traffic than policing. You can configure average-rate traffic shaping on a traffic
class within a policy map at the class level, at the VLAN level, and at the physical level by using the
shape policy-map class configuration command. At the physical level of the hierarchy, you can shape
only the class-default class in a policy attached to an ES port or EtherChannel.
Class Maps” section on page 34-108.
Beginning in privileged EXEC mode, follow these steps to configure class-level shaping in a hierarchical
service policy. This procedure is optional. The examples that follow the procedure show how to
configure class-level, VLAN-level, and physical-level shaping.
Command Purpose

OL-9644-10 34-129
Command Purpose
Step 4 shape average cir-bps Enable average-rate traffic shaping. Specify the committed
information rate, the bit rate that traffic is shaped to, in b/s. This is the
access bit rate that you have contracted for with your service provider
or the service levels that you intend to maintain. The range is 64000 to
2000000000 b/s.
Allocate the shaped rate in 100-kb/s increments; otherwise, the
software rounds down the bandwidth to the nearest 100-kb/s
increment.
By default, average-rate traffic shaping is disabled.
class-map-name]]
or
To disable the average-rate traffic shaping, use the no shape average policy-map class configuration
command.
This example shows how to configure class-level, average-rate shaping. It limits traffic class class1 to a
data transmission rate of 256 kb/s.
Switch(config-cmap)# match cos 0 1 2 3
This example shows how to configure VLAN-level, average-rate shaping. It limits each traffic class,
vlan101 and vlan102, to a data transmission rate of 400 Mb/s.

34-130 OL-9644-10
Displaying Hierarchical QoS Information

This example shows how to shape the class. This configuration associates a class-level policy map with
a VLAN-level policy map and then associates the VLAN-level policy map with a physical-level policy
map.

To display hierarchical QoS information, use one or more of the privileged EXEC commands in
Table 34-17:
Table 34-17 Commands for Displaying Hierarchical QoS Information
Command Purpose
show class-map [class-map-name] Display QoS class maps, which define the match criteria to
classify traffic.
show mls qos Display global QoS configuration information.
show policy-map [policy-map-name [class Display QoS policy maps, which define the traffic policy for a
class-map-name]] traffic class.
show policy-map interface interface-id output [class Display QoS policy-map information for the specified ES port,
class-name]] and display statistics for an individual class.

OL-9644-10 34-131

34-132 OL-9644-10

Configuring QoS on Catalyst 3750 Metro Switches

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuring QoS on Catalyst 3750 Metro Switches

Uploaded by

Copyright:

Available Formats

CH A P T E R 34

Catalyst 3750 Metro Switch Software Configuration Guide

This chapter consists of these sections:

Catalyst 3750 Metro Switch Software Configuration Guide

Figure 34-1 QoS Classification Layers in Frames and Packets

Layer 2 ISL Frame

3 bits used for CoS

Layer 2 802.1Q and 802.1p Frame

3 bits used for CoS (user priority)

Layer 3 IPv4 Packet

Layer 3 IPv6 Packet

Catalyst 3750 Metro Switch Software Configuration Guide

Basic QoS Model

Catalyst 3750 Metro Switch Software Configuration Guide

Figure 34-2 Basic QoS Model

Hierarchical actions at ingress on an ES port

Traffic received In profile or

Inspect packet, Compare received Based on whether Based on the

Actions at ingress Actions at egress

Hierarchical actions at egress on an ES port

Inspect packet, Compare received Based on whether Based on the

Catalyst 3750 Metro Switch Software Configuration Guide

Catalyst 3750 Metro Switch Software Configuration Guide

Supported Policy Maps

Table 34-1 Policy Maps Supported on Different Interface Types

Dual Level Hierarchical

Catalyst 3750 Metro Switch Software Configuration Guide

Software releases earlier than Cisco IOS Release 12.2(25)EY support:

Supported Policing Configurations

Catalyst 3750 Metro Switch Software Configuration Guide

Understanding Standard QoS

Catalyst 3750 Metro Switch Software Configuration Guide

Catalyst 3750 Metro Switch Software Configuration Guide

Figure 34-3 Ingress Classification Flowchart

Trust CoS (IP and non-IP traffic).

Yes No (Optional) Modify the

Generate the DSCP based on

No Check if packet came

Ingress Classification Based on QoS ACLs

Catalyst 3750 Metro Switch Software Configuration Guide

Ingress Classification Based on Traffic Classes and Traffic Policies

Catalyst 3750 Metro Switch Software Configuration Guide

Ingress Policing and Marking

Nonhierarchical Single-Level Policing

Catalyst 3750 Metro Switch Software Configuration Guide

Catalyst 3750 Metro Switch Software Configuration Guide

Figure 34-4 Ingress, Nonhierarchical Single-Level Policing and Marking Flowchart

Get the clasification

Check if the packet is in No

Modify DSCP according to the

Hierarchical Dual-Level Policing on SVIs

Catalyst 3750 Metro Switch Software Configuration Guide

Get the VLAN and

Verify if the packet is in the No

Modify DSCP according to the

Catalyst 3750 Metro Switch Software Configuration Guide

Queueing and Scheduling Overview

Catalyst 3750 Metro Switch Software Configuration Guide

Figure 34-6 Ingress and Egress Queue Locations

Catalyst 3750 Metro Switch Software Configuration Guide

Weighted Tail Drop

Figure 34-7 WTD and Queue Operation