This chapter describes how to configure quality of service (QoS) as implemented on the Policy Feature
Card (PFC) and Distributed Forwarding Cards (DFCs) on the Cisco 7600 series routers.
Note• For complete syntax and usage information for the commands used in this chapter, refer to the
Cisco 7600 Series Router Cisco IOS Command Reference at this URL:
The term “PFC QoS” refers to QoS on the Cisco 7600 series router. PFC QoS is implemented on various
router components in addition to the PFC and any DFCs. These sections describe how PFC QoS works:
• Port Types Supported by PFC QoS, page 42-2
• Overview, page 42-2
• Component Overview, page 42-6
• Understanding Classification and Marking, page 42-16
In all releases, PFC QoS supports LAN ports. LAN ports are Ethernet ports on Ethernet switching
modules, except for the 4-port Gigabit Ethernet WAN (GBIC) modules (OSM-4GE-WAN and
OSM-2+4GE-WAN+). Some OSMs have four Ethernet LAN ports in addition to WAN ports.
With Release 12.2(17b)SXA and later releases, PFC QoS supports optical services module (OSM) ports.
OSM ports are the WAN ports on OSMs. Refer to the following publication for information about
additional OSM QoS features:
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.
QoS makes network performance more predictable and bandwidth utilization more effective. QoS
selects (classifies) network traffic, uses or assigns QoS labels to indicate priority, makes the packets
comply with the configured resource usage limits (polices the traffic and marks the traffic), and provides
congestion avoidance where resource contention exists.
PFC QoS classification, policing, marking, and congestion avoidance is implemented in hardware on the
PFC, DFCs, and in LAN switching module port Application Specific Integrated Circuits (ASICs).
NoteCisco 7600 series routers do not support all of the MQC features (for example, Committed Access Rate
(CAR)) for traffic that is Layer 3 switched or Layer 2 switched in hardware. Because queuing is
implemented in the port ASICs, Cisco 7600 series routers do not support MQC-configured queuing.
Figure 42-1 shows an overview of QoS processing in a Cisco 7600 series router.
Port trust state—In PFC QoS, trust means to accept as valid and use as the basis of the initial
internal DSCP value. Ports are untrusted by default, which sets the initial internal DSCP value
to zero. You can configure ports to trust received CoS, IP precedence, or DSCP.
–
Layer 2 CoS remarking—PFC QoS applies Layer 2 CoS remarking, which marks the incoming
frame with the port CoS value, in these situations:
—If the traffic is not in an ISL, 802.1Q, or 802.1p frame.
—If a port is configured as untrusted.
On OSM ATM and POS ports, PFC QoS always sets ingress CoS equal to zero.
–
Congestion avoidance—If you configure an Ethernet LAN port to trust CoS or DSCP, QoS
classifies the traffic on the basis of its Layer 2 CoS value or its Layer 3 DSCP value and assigns
it to an ingress queue to provide congestion avoidance. Layer 3 DSCP-based queue mapping is
available only on WS-X6708-10GE ports.
2. PFC and DFC QoS features:
–
Internal DSCP—On the PFC and DFCs, QoS associates an internal DSCP value with all traffic
to classify it for processing through the system. There is an initial internal DSCP based on the
traffic trust state and a final internal DSCP. The final internal DSCP can be the same as the
initial value or an MQC policy map can set it to a different value.
–
MQC policy maps—MQC policy maps can do one or more of these operations:
—Change the trust state of the traffic (bases the internal DSCP value on a different QoS label)
—Set the initial internal DSCP value (only for traffic from untrusted ports)
—Mark the traffic
—Police the traffic
3. Egress Ethernet LAN port QoS features:
–
Layer 3 DSCP marking with the final internal DSCP (always with PFC2, optionally with PFC3)
–
Layer 2 CoS marking mapped from the final internal DSCP
In PFC QoS, trust means to accept as valid and use as the basis of the initial internal DSCP value. You
can configure ports as untrusted or you can configure them to trust these QoS values:
• Layer 2 CoS
–
A port configured to trust CoS is called a trust CoS port.
–
Traffic received through a trust CoS port or configured by a policy map to trust CoS is called
trust CoS traffic.
NoteNot all traffic carries a CoS value. Only ISL, 802.1Q, and 802.1P traffic carries a CoS value.
PFC QoS applies the port CoS value to any traffic that does not carry a CoS value. On
untrusted ports, PFC QoS applies the port CoS value to all traffic, overwriting any received
CoS value.
• IP precedence
–
A port configured to trust IP precedence is called a trust IP precedence port.
–
Traffic received through a trust IP precedence port or configured by a policy map to trust
IP precedence is called trust IP precedence traffic.
• DSCP
–
A port configured to trust DSCP is called a trust DSCP port.
–
Traffic received through a trust DSCP port or configured by a policy map to trust DSCP is called
trust DSCP traffic.
Traffic received through an untrusted port is called untrusted traffic.
Ingress Congestion Avoidance
PFC QoS implements congestion avoidance on trust CoS ports. On a trust CoS port, QoS classifies the
traffic on the basis of its Layer 2 CoS value and assigns it to an ingress queue to provide congestion
avoidance. In Release 12.2(18)SXF5 and later releases, you can configure WS-X6708-10GE trust DSCP
ports to use received DSCP values for congestion avoidance. See the “Ingress Classification and
Marking at Trust CoS LAN Ports” section on page 42-17 for more information about ingress congestion
avoidance.
PFC and DFC QoS Features
These sections describe PFCs and DFCs as they relate to QoS:
The policy feature card (PFC) is a daughter card that resides on the supervisor engine. The PFC provides
QoS in addition to other functionality. The following PFCs are supported on the Cisco 7600 series
routers:
• PFC2 on the Supervisor Engine 2
• PFC3A on the Supervisor Engine 720
• PFC3B on the Supervisor Engine 720 and Supervisor Engine 32
• PFC3BXL on the Supervisor Engine 720
Supported Distributed Forwarding Cards
The PFC sends a copy of the QoS policies to the distributed forwarding card (DFC) to provide local
support for the QoS policies, which enables the DFCs to support the same QoS features that the PFC
supports.
The following DFCs are supported on the Cisco 7600 series routers:
• WS-F6K-DFC, for use on dCEF256 and CEF256 modules with a Supervisor Engine 2.
• WS-F6K-DFC3A, WS-F6K-DFC3B, WS-F6K-DFC3BXL, for use on dCEF256 and CEF256
modules with a Supervisor Engine 720.
Understanding How PFC QoS Works
• WS-F6700-DFC3A, WS-F6700-DFC3B, WS-F6700-DFC3BXL, for use on CEF720 modules with
a Supervisor Engine 720.
PFC and DFC QoS Feature List and Flowchart
Table 42-1 lists the QoS features supported on the different versions of PFCs and DFCs.
Table 42-1 QoS Features Supported on PFCs and DFCs
During processing, PFC QoS represents the priority of all traffic (including non-IP traffic) with an
internal DSCP value.
Initial Internal DSCP Value
On the PFC, before any marking or policing takes place, PFC QoS derives the initial internal DSCP value
as follows:
Understanding How PFC QoS Works
• For untrusted traffic, when ignore port trust is not enabled, PFC QoS sets the initial internal DSCP
value to zero for both tagged and untagged untrusted traffic.
• For untrusted traffic, when ignore port trust is enabled, PFC QoS does the following:
–
For IP traffic, PFC QoS uses the received DSCP value as the initial internal DSCP value.
–
For traffic without a recognizable ToS byte, PFC QoS maps the port CoS value to the initial
internal DSCP value.
• For trust CoS traffic, when ignore port trust is enabled, PFC QoS does the following:
–
For IP traffic, PFC QoS uses the received DSCP value as the initial internal DSCP value.
NoteFor trust CoS traffic, when ignore port trust is enabled, PFC QoS does not use the
received CoS value in tagged IP traffic.
–
For tagged traffic without a recognizable ToS byte, PFC QoS maps the received CoS value to
the initial internal DSCP value.
–
For untagged traffic without a recognizable ToS byte, PFC QoS maps the port CoS value to the
initial internal DSCP value.
• For trust IP precedence traffic, PFC QoS does the following:
–
For IP traffic, PFC QoS maps the received IP precedence value to the initial internal DSCP
value.
–
For tagged traffic without a recognizable ToS byte, PFC QoS maps the received CoS value to
the initial internal DSCP value.
–
For untagged traffic without a recognizable ToS byte, PFC QoS maps the port CoS value to the
initial internal DSCP value.
• For trust DSCP traffic, PFC QoS, PFC QoS does the following:
–
For IP traffic, PFC QoS uses the received DSCP value as the initial internal DSCP value.
–
For tagged traffic without a recognizable ToS byte, PFC QoS maps the received CoS value to
the initial internal DSCP value.
–
For untagged traffic without a recognizable ToS byte, PFC QoS maps the port CoS value to the
initial internal DSCP value.
For trust CoS traffic and trust IP precedence traffic, PFC QoS uses configurable maps to derive the initial
internal 6-bit DSCP value from CoS or IP precedence, which are 3-bit values.
OL-4266-08
Final Internal DSCP Value
Policy marking and policing on the PFC can change the initial internal DSCP value to a final internal
DSCP value, which is then used for all subsequently applied QoS features.
You can configure each ingress LAN port for either physical port-based PFC QoS (default) or
VLAN-based PFC QoS and attach a policy map to the selected interface.
On ports configured for port-based PFC QoS, you can attach a policy map to the ingress LAN port as
follows:
• On a nontrunk ingress LAN port configured for port-based PFC QoS, all traffic received through the
port is subject to the policy map attached to the port.
• On a trunking ingress LAN port configured for port-based PFC QoS, traffic in all VLANs received
through the port is subject to the policy map attached to the port.
On a nontrunk ingress LAN port configured for VLAN-based PFC QoS, traffic received through the port
is subject to the policy map attached to the port’s VLAN.
On a trunking ingress LAN port configured for VLAN-based PFC QoS, traffic received through the port
is subject to the policy map attached to the traffic’s VLAN.
PFC QoS Egress Port Features
Chapter 42 Configuring PFC QoS
These sections describe PFC QoS egress port features:
• Flowchart of PFC QoS Egress LAN Port Features, page 42-13
• Egress CoS Values, page 42-13
• Egress DSCP Mutation with a PFC3, page 42-14
• Egress ToS Byte, page 42-14
• Egress PFC QoS Interfaces, page 42-14
• Egress ACL Support for Remarked DSCP, page 42-14
With a PFC3, you can configure 15 egress DSCP mutation maps to mutate the internal DSCP value
before it is written in the egress ToS byte. You can attach egress DSCP mutation maps to any interface
that PFC QoS supports.
Note• If you configure egress DSCP mutation, PFC QoS does not derive the egress CoS value from the
mutated DSCP value.
• The PFC2 does not support egress DSCP mutation.
Egress ToS Byte
Except when DSCP transparency is enabled, PFC QoS creates a ToS byte for egress IP traffic from the
final internal or mutated DSCP value and sends it to the egress port to be written into IP packets. For
trust DSCP and untrusted IP traffic, the ToS byte includes the original two least-significant bits from the
received ToS byte.
The internal or mutated DSCP value can mimic an IP precedence value (see the “IP Precedence and
DSCP Values” section on page 42-55).
Chapter 42 Configuring PFC QoS
Egress PFC QoS Interfaces
You can attach an output policy map to a Layer 3 interface (either a LAN port configured as a Layer 3
interface or a VLAN interface) to apply a policy map to egress traffic.
Note• Output policies do not support microflow policing.
• With a PFC3, you cannot apply microflow policing to ARP traffic.
• You cannot set a trust state in an output policy.
Egress ACL Support for Remarked DSCP
NoteEgress ACL support for remarked DSCP is also known as packet recirculation.
With a PFC3, Release 12.2(18)SXE and later releases support egress ACL support for remarked DSCP,
which enables IP precedence-based or DSCP-based egress QoS filtering to use any IP precedence or
DSCP policing or marking changes made by ingress PFC QoS.
Without egress ACL support for remarked DSCP, egress QoS filtering uses received IP precedence or
DSCP values; it does not use any IP precedence or DSCP changes made by ingress PFC QoS as the result
of policing or marking.
42-14
The PFC3 provides egress PFC QoS only for Layer 3-switched and routed traffic on egress Layer 3
interfaces (either LAN ports configured as Layer 3 interfaces or VLAN interfaces).
You configure egress ACL support for remarked DSCP on ingress Layer 3 interfaces (either LAN ports
configured as Layer 3 interfaces or VLAN interfaces).
On interfaces where egress ACL support for remarked DSCP is configured, the PFC3 processes each
QoS-filtered IP packet twice: once to apply ingress PFC QoS and once to apply egress PFC QoS.
CautionIf the router is operating in PFC3A mode with egress ACL support for remarked DSCP configured, when
the PFC3 processes traffic to apply ingress PFC QoS, it applies ingress PFC QoS filtering and ingress
PFC QoS, and incorrectly applies any egress QoS filtering and egress PFC QoS configured on the
ingress interface, which results in unexpected behavior if QoS filtering is configured on an interface
where egress ACL support for remarked DSCP is enabled. This problem does not occur in other
PFC3 modes.
After packets have been processed by ingress PFC QoS and any policing or marking changes have been
made, the packets are processed again on the ingress interface by any configured Layer 2 features (for
example, VACLs) before being processed by egress PFC QoS.
On an interface where egress ACL support for remarked DSCP is configured, if a Layer 2 feature
matches the ingress-QoS-modified IP precedence or DSCP value, the Layer 2 feature might redirect or
drop the matched packets, which prevents them from being processed by egress QoS.
After packets have been processed by ingress PFC QoS and any policing or marking changes have been
made, the packets are processed on the ingress interface by any configured Layer 3 features (for example,
ingress Cisco IOS ACLs, policy based routing (PBR), etc.) before being processed by egress PFC QoS.
Understanding How PFC QoS Works
The Layer 3 features configured on an interface where egress ACL support for remarked DSCP is
configured might redirect or drop the packets that have been processed by ingress PFC QoS, which
would prevent them from being processed by egress PFC QoS.
Marking on Egress OSM Ports
Ingress PFC QoS sets DSCP values that can be used by the OSM egress QoS features (see Figure 42-8).
The following sections describe where and how classification and marking occur on the Cisco 7600
series routers:
• Classification and Marking at Trusted and Untrusted Ingress Ports, page 42-16
• Classification and Marking at Ingress OSM Ports, page 42-17
• Classification and Marking on the PFC Using Service Policies and Policy Maps, page 42-18
• Classification and Marking on the MSFC, page 42-19
Classification and Marking at Trusted and Untrusted Ingress Ports
The trust state of an ingress port determines how the port marks, schedules, and classifies received
Layer 2 frames, and whether or not congestion avoidance is implemented. These are the port trust states:
• Untrusted (default)
• Trust IP precedence
• Trust DSCP
• Trust CoS
Chapter 42 Configuring PFC QoS
In all releases, ingress LAN port classification, marking, and congestion avoidance can use Layer 2 CoS
values and do not set Layer 3 IP precedence or DSCP values.
In Release 12.2(18)SXF5 and later releases, you can configure WS-X6708-10GE ports to use received
DSCP values for ingress LAN port classification and congestion avoidance (see the “Configuring
DSCP-Based Queue Mapping” section on page 42-98)
In Releases earlier than Release 12.2(18)SXF5, ingress LAN port classification, marking, and
congestion avoidance use Layer 2 CoS values only.
The following sections describe classification and marking at trusted and untrusted ingress ports:
• Classification and Marking at Untrusted Ingress Ports, page 42-16
• Ingress Classification and Marking at Trusted Ports, page 42-16
Classification and Marking at Untrusted Ingress Ports
PFC QoS Layer 2 remarking marks all frames received through untrusted ports with the port CoS value
(the default is zero).
To map the port CoS value that was applied to untrusted ingress traffic to the initial internal DSCP value,
configure a trust CoS policy map that matches the ingress traffic.
Ingress Classification and Marking at Trusted Ports
You should configure ports to trust only if they receive traffic that carries valid QoS labels. QoS uses the
received QoS labels as the basis of initial internal DSCP value. After the traffic enters the router, you
can apply a different trust state to traffic with a policy map. For example, traffic can enter the router
through a trust CoS port, and then you can use a policy map to trust IP precedence or DSCP, which uses
the trusted value as the basis of the initial internal DSCP value, instead of the QoS label that was trusted
at the port.
These sections describe classification and marking at trusted ingress ports:
• Ingress Classification and Marking at Trust CoS LAN Ports, page 42-17
• Ingress Classification and Marking at Trust IP Precedence Ports, page 42-17
• Ingress Classification and Marking at Trust DSCP Ports, page 42-17
Ingress Classification and Marking at Trust CoS LAN Ports
You should configure LAN ports to trust CoS only if they receive traffic that carries valid Layer 2 CoS.
When an ISL frame enters the router through a trusted ingress LAN port, PFC QoS accepts the three least
significant bits in the User field as a CoS value. When an 802.1Q frame enters the router through a
trusted ingress LAN port, PFC QoS accepts the User Priority bits as a CoS value. PFC QoS Layer 2
remarking marks all traffic received in untagged frames with the ingress port CoS value.
On ports configured to trust CoS, PFC QoS does the following:
• PFC QoS maps the received CoS value in tagged trust CoS traffic to the initial internal DSCP value.
• PFC QoS maps the ingress port CoS value applied to untagged trusted traffic to the initial internal
DSCP value.
• PFC QoS enables the CoS-based ingress queues and thresholds to provide congestion avoidance.
See the “Understanding Port-Based Queue Types” section on page 42-22 for more information about
ingress queues and thresholds.
Understanding How PFC QoS Works
Ingress Classification and Marking at Trust IP Precedence Ports
You should configure ports to trust IP precedence only if they receive traffic that carries valid Layer 3
IP precedence. For traffic from trust IP precedence ports, PFC QoS maps the received IP precedence
value to the initial internal DSCP value. Because the ingress port queues and thresholds use Layer 2 CoS,
PFC QoS does not implement ingress port congestion avoidance on ports configured to trust IP
precedence. PFC does not mark any traffic on ingress ports configured to trust IP precedence.
Ingress Classification and Marking at Trust DSCP Ports
You should configure ports to trust DSCP only if they receive traffic that carries valid Layer 3 DSCP.
In Release 12.2(18)SXF5 and later releases, you can enable DSCP-based ingress queues and thresholds
on WS-X6708-10GE ports to provide congestion avoidance (see the “Configuring DSCP-Based Queue
Mapping” section on page 42-98).
In releases earlier than Release 12.2(18)SXF5, the ingress port queues and thresholds use only Layer 2
CoS, and PFC QoS does not implement ingress port congestion avoidance on ports configured to trust
DSCP.
For traffic from trust DSCP ports, PFC QoS uses the received DSCP value as the initial internal DSCP
value. PFC QoS does not mark any traffic on ingress ports configured to trust received DSCP.
Classification and Marking at Ingress OSM Ports
PFC QoS associates CoS zero with all traffic received through ingress OSM ports. You can configure
ingress OSM port trust states that can be used by the PFC to set IP precedence or DSCP values and the
CoS value. You can configure the trust state of each ingress OSM port as follows:
• Trust CoS (CoS is always zero for POS and ATM OSM ports because the port CoS value is not
configurable on POS and ATM OSM ports.)
Classification and Marking on the PFC Using Service Policies and Policy Maps
PFC QoS supports classification and marking with service policies that attach one policy map to these
interface types to apply ingress PFC QoS:
• Each ingress port (except FlexWAN interfaces)
• Each EtherChannel port-channel interface
• Each VLAN interface
With a PFC3, you can attach one policy map to each Layer 3 interface (except FlexWAN interfaces) to
apply egress PFC QoS.
Each policy map can contain multiple policy-map classes. You can configure a separate policy-map class
for each type of traffic handled by the interface. There are two ways to configure filtering in policy-map
classes:
• Access control lists (ACLs)
• Class-map match commands for IP precedence and DSCP values
Policy-map classes specify actions with the following optional commands:
• Policy-map set commands—For untrusted traffic or if ignore port trust is enabled, PFC QoS can use
configured IP precedence or DSCP values as the final internal DSCP value. The “IP Precedence and
DSCP Values” section on page 42-55 shows the bit values for IP precedence and DSCP.
• Policy-map class trust commands—PFC QoS applies the policy-map class trust state to matched
ingress traffic, which then uses the trusted value as the basis of its initial internal DSCP value,
instead of the QoS label that was trusted at the port (if any). In a policy map, you can trust CoS, IP
precedence, or DSCP.
NoteA trust CoS policy map cannot restore received CoS in traffic from untrusted ports. Traffic
from untrusted ports always has the port CoS value.
• Aggregate and microflow policers—PFC QoS can use policers to either mark or drop both
PFC QoS sends IP traffic to the MSFC with the final internal DSCP values. CoS is equal to
IP precedence in all traffic sent from the MSFC to egress ports.
Figure 42-9 Marking with PFC2 or PFC3 and MSFC2, MSFC2A, or MSFC3
From PFC
Multilayer Switch Feature Card (MSFC) marking
Understanding How PFC QoS Works
Policers
IP traffic
from PFC?
No
Route
traffic
To egress
port
NoteTraffic that is Layer 3 switched on the PFC does not go through the MSFC and retains the CoS value
Ye s
CoS =
all traffic
Write ToS
byte into
packet
144800
IP precedence for
(not configurable)
assigned by the PFC.
These sections describe policers:
• Overview of Policers, page 42-19
• Aggregate Policers, page 42-20
• Microflow Policers, page 42-21
Overview of Policers
Policing allows you to rate limit incoming and outgoing traffic so that it adheres to the traffic forwarding
rules defined by the QoS configuration. Sometimes these configured rules for how traffic should be
forwarded through the system are referred to as a contract. If the traffic does not adhere to this contract,
it is marked down to a lower DSCP value or dropped.
Policing does not buffer out-of-profile packets. As a result, policing does not affect transmission delay.
In contrast, traffic shaping works by buffering out-of-profile traffic, which moderates the traffic bursts.
(PFC QoS does not support shaping.)
The PFC2 supports only ingress PFC QoS, which includes ingress policing. The PFC3 supports both
ingress and egress PFC QoS, which includes ingress and egress policing. Traffic shaping is supported on
some WAN modules. For more information about traffic shaping on the OSM and FlexWAN modules,
refer to the OSM and FlexWAN documentation at this location:
NotePolicers can act on ingress traffic per-port or per-VLAN. With a PFC3, for egress traffic, the policers can
act per-VLAN only.
You can create policers to do the following:
Aggregate Policers
PFC QoS applies the bandwidth limits specified in an aggregate policer cumulatively to all flows in
matched traffic. For example, if you configure an aggregate policer to allow 1 Mbps for all TFTP traffic
flows on VLAN 1 and VLAN 3, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN
3 to 1 Mbps.
Chapter 42 Configuring PFC QoS
• Mark traffic
• Limit bandwidth utilization and mark traffic
• You define per-interface aggregate policers in a policy map class with the police command. If you
attach a per-interface aggregate policer to multiple ingress ports, it polices the matched traffic on
each ingress port separately.
• You create named aggregate policers with the mls qos aggregate-policer command. If you attach a
named aggregate policer to multiple ingress ports, it polices the matched traffic from all the ingress
ports to which it is attached.
• Aggregate policing works independently on each DFC-equipped switching module and
independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate
policing does not combine flow statistics from different DFC-equipped switching modules. You can
display aggregate policing statistics for each DFC-equipped switching module and for the PFC and
any non-DFC-equipped switching modules supported by the PFC.
• Each PFC or DFC polices independently, which might affect QoS features being applied to traffic
that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
–
Policers applied to a port channel interface.
–
Policers applied to a switched virtual interface.
–
Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs
egress policing decisions at the ingress interface, on the PFC or ingress DFC.
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent
policing rates.
PFC QoS applies the bandwidth limit specified in a microflow policer separately to each flow in matched
traffic. For example, if you configure a microflow policer to limit the TFTP traffic to 1 Mbps on VLAN
1 and VLAN 3, then 1 Mbps is allowed for each flow in VLAN 1 and 1 Mbps for each flow in VLAN 3.
In other words, if there are three flows in VLAN 1 and four flows in VLAN 3, the microflow policer
allows each of these flows 1 Mbps.
You can configure PFC QoS to apply the bandwidth limits in a microflow policer as follows:
Understanding How PFC QoS Works
• You can create microflow policers with up to 63 different rate and burst parameter combinations.
• You create microflow policers in a policy map class with the police flow command.
• You can configure a microflow policer to use only source addresses, which applies the microflow
policer to all traffic from a source address regardless of the destination addresses.
• You can configure a microflow policer to use only destination addresses, which applies the
microflow policer to all traffic to a destination address regardless of the source addresses.
• For MAC-Layer microflow policing, PFC QoS considers MAC-Layer traffic with the same protocol
and the same source and destination MAC-Layer addresses to be part of the same flow, including
traffic with different EtherTypes. With a PFC3, you can configure MAC ACLs to filter IPX traffic.
• With a PFC2, you can configure IPX ACLs to filter IPX traffic. For IPX microflow policing,
PFC QoS considers IPX traffic with the same source network, destination network, and destination
node to be part of the same flow, including traffic with different source nodes or source sockets.
• By default, microflow policers only affect traffic routed by the MSFC. To enable microflow policing
of other traffic, including traffic in bridge groups, enter the mls qos bridged command. With a
PFC2, you must enable bridged mircoflow policing for routed traffic as well.
• With a PFC3, you cannot apply microflow policing to ARP traffic.
• You cannot apply microflow policing to IPv6 multicast traffic.
You can include both an aggregate policer and a microflow policer in each policy map class to police a
flow based on both its own bandwidth utilization and on its bandwidth utilization combined with that of
other flows.
NoteIf traffic is both aggregate and microflow policed, then the aggregate and microflow policers must both
be in the same policy-map class and each must use the same conform-action and exceed-action
keyword option: drop, set-dscp-transmit, set-prec-transmit, or transmit.
For example, you could create a microflow policer with a bandwidth limit suitable for individuals in a
group, and you could create a named aggregate policer with bandwidth limits suitable for the group as a
whole. You could include both policers in policy map classes that match the group’s traffic. The
combination would affect individual flows separately and the group aggregately.
For policy map classes that include both an aggregate and a microflow policer, PFC QoS responds to an
out-of-profile status from either policer and, as specified by the policer, applies a new DSCP value or
drops the packet. If both policers return an out-of-profile status, then if either policer specifies that the
packet is to be dropped, it is dropped; otherwise, PFC QoS applies a marked-down DSCP value.
OL-4266-08
NoteTo avoid inconsistent results, ensure that all traffic policed by the same aggregate policer has the same
With a PFC3, policing uses the Layer 2 frame size. With a PFC2, policing uses the Layer 3 packet size.
You specify the bandwidth utilization limit as a committed information rate (CIR). You can also specify
a higher peak information rate (PIR). Packets that exceed a rate are “out of profile” or “nonconforming.”
In each policer, you specify if out-of-profile packets are to be dropped or to have a new DSCP value
applied to them (applying a new DSCP value is called “markdown”). Because out-of-profile packets do
not retain their original priority, they are not counted as part of the bandwidth consumed by in-profile
packets.
If you configure a PIR, the PIR out-of-profile action cannot be less severe than the CIR out-of-profile
action. For example, if the CIR out-of-profile action is to mark down the traffic, then the PIR
out-of-profile action cannot be to transmit the traffic.
For all policers, PFC QoS uses a configurable global table that maps the internal DSCP value to a
marked-down DSCP value. When markdown occurs, PFC QoS gets the marked-down DSCP value from
the table. You cannot specify marked-down DSCP values in individual policers.
Note• Policing with the conform-action transmit keywords supersedes the ingress LAN port trust state
of matched traffic with trust DSCP or with the trust state defined by a trust policy-map class
command.
Chapter 42 Configuring PFC QoS
• By default, the markdown table is configured so that no markdown occurs: the marked-down DSCP
values are equal to the original DSCP values. To enable markdown, configure the table appropriately
for your network.
• When you apply both ingress policing and egress policing to the same traffic, both the input policy
and the output policy must either mark down traffic or drop traffic. PFC QoS does not support
ingress markdown with egress drop or ingress drop with egress markdown.
Understanding Port-Based Queue Types
Port-based queue types are determined by the ASICs that control the ports. The following sections
describe the queue types, drop thresholds, and buffers that are supported on the Cisco 7600 series router
LAN modules:
• Ingress and Egress Buffers and Layer 2 CoS-Based Queues, page 42-22
• Ingress Queue Types, page 42-24
• Egress Queue Types, page 42-25
• Module to Queue Type Mappings, page 42-26
Ingress and Egress Buffers and Layer 2 CoS-Based Queues
42-22
The Ethernet LAN module port ASICs have buffers that are divided into a fixed number of queues. When
congestion avoidance is enabled, PFC QoS uses the traffic’s Layer 2 CoS value to assign traffic to the
queues. The buffers and queues store frames temporarily as they transit the switch. PFC QoS allocates
the port ASIC memory as buffers for each queue on each port.
The Cisco 7600 series router LAN modules support the following types of queues:
The Cisco 7600 series router LAN modules support the following types of scheduling algorithms
between queues:
• Shaped round robin (SRR)—SRR allows a queue to use only the allocated bandwidth.
• Deficit weighted round robin (DWRR)—DWRR keeps track of any lower-priority queue
under-transmission caused by traffic in a higher-priority queue and compensates in the next round.
• Weighted Round Robin (WRR)—WRR does not explicitly reserve bandwidth for the queues. Instead,
the amount of bandwidth assigned to each queue is user configurable. The percentage or weight allocated
to a queue defines the amount of bandwidth allocated to the queue.
• Strict-priority queueing—Strict priority queueing allows delay-sensitive data such as voice to be
dequeued and sent before packets in other queues are dequeued, giving delay-sensitive data preferential
treatment over other traffic. The router services traffic in the strict-priority transmit queue before
servicing the standard queues. After transmitting a packet from a standard queue, the switch checks
for traffic in the strict-priority queue. If the switch detects traffic in the strict-priority queue, it
suspends its service of the standard queue and completes service of all traffic in the strict-priority
queue before returning to the standard queue.
The Cisco 7600 series router LAN modules provides congestion avoidance with these types of
thresholds within a queue:
• Weighted Random Early Detection (WRED)—On ports with WRED drop thresholds, frames with a
given QoS label are admitted to the queue based on a random probability designed to avoid buffer
congestion. The probability of a frame with a given QoS label being admitted to the queue or
discarded depends on the weight and threshold assigned to that QoS label.
For example, if CoS 2 is assigned to queue 1, threshold 2, and the threshold 2 levels are 40 percent
(low) and 80 percent (high), then frames with CoS 2 will not be dropped until queue 1 is at least
40 percent full. As the queue depth approaches 80 percent, frames with CoS 2 have an increasingly
higher probability of being discarded rather than being admitted to the queue. Once the queue is over
80 percent full, all CoS 2 frames are dropped until the queue is less than 80 percent full. The frames
the switch discards when the queue level is between the low and high thresholds are picked out at
random, rather than on a per-flow basis or in a FIFO manner. This method works well with protocols
such as TCP that can adjust to periodic packet drops by backing off and adjusting their transmission
window size.
Understanding How PFC QoS Works
OL-4266-08
• Tail-drop thresholds—On ports with tail-drop thresholds, frames with a given QoS label are
admitted to the queue until the drop threshold associated with that QoS label is exceeded;
subsequent frames of that QoS label are discarded until the threshold is no longer exceeded. For
example, if CoS 1 is assigned to queue 1, threshold 2, and the threshold 2 watermark is 60 percent,
then frames with CoS 1 will not be dropped until queue 1 is 60 percent full. All subsequent CoS 1
frames will be dropped until the queue is less than 60 percent full. With some port types, you can
configure the standard receive queue to use both a tail-drop and a WRED-drop threshold by mapping
a CoS value to the queue or to the queue and a threshold. The switch uses the tail-drop threshold for
traffic carrying CoS values mapped only to the queue. The switch uses WRED-drop thresholds for
traffic carrying CoS values mapped to the queue and a threshold. All LAN ports of the same type
use the same drop-threshold configuration.
NoteIn Release 12.2(18)SXF5 and later releases, you can enable DSCP-based queues and thresholds on
WS-X6708-10GE ports (see the “Configuring DSCP-Based Queue Mapping” section on page 42-98).
The combination of multiple queues and the scheduling algorithms associated with each queue allows the
switch to provide congestion avoidance.
Figure 42-10 illustrates the drop thresholds for a 1q4t ingress LAN port. Drop thresholds in other
configurations function similarly.
Figure 42-10 Receive Queue Drop Thresholds
Reserved for
CoS 6 and 7
Reserved for
CoS 4 and higher
Reserved for
CoS 2 and higher
Available for
traffic with any
CoS value
Drop threshold 4: 100%
Drop threshold 3: 80%
Drop threshold 2: 60%
Drop threshold 1: 50%
Chapter 42 Configuring PFC QoS
C
o
S
6
a
n
C
o
S
4
a
C
o
S
C
o
S
0
a
n
d
n
d
2
a
n
d
3
1
d
7
5
Traffic is dropped
100% available for CoS 6 and 7
80% available for CoS 4 and 5
60% available for CoS 2 and 3
50% available for CoS 0 and 1
Ingress Queue Types
To see the queue structure of a LAN port, enter the show queueing interface {ethernet | fastethernet |
gigabitethernet | tengigabitethernet} slot/port | include type command. The command displays one of
the following architectures:
• 1q2t indicates one standard queue with one configurable tail-drop threshold and one
nonconfigurable tail-drop threshold.
• 1q4t indicates one standard queue with four configurable tail-drop thresholds.
• 1q8t indicates one standard queue with eight configurable tail-drop thresholds.
• 2q8t indicates two standard queues, each with eight configurable tail-drop thresholds.
• 8q4t indicates eight standard queues, each with four thresholds, each configurable as either
WRED-drop or tail-drop.
• 8q8t indicates eight standard queues, each with eight thresholds, each configurable as either
WRED-drop or tail-drop.
Receive queue
(Default values shown)
26249
42-24
• 1p1q4t indicates:
–
One strict-priority queue
–
One standard queue with four configurable tail-drop thresholds.
To see the queue structure of an egress LAN port, enter the show queueing interface {ethernet |
fastethernet | gigabitethernet | tengigabitethernet} slot/port | include type command.
The command displays one of the following architectures:
• 2q2t indicates two standard queues, each with two configurable tail-drop thresholds.
Understanding How PFC QoS Works
–
One strict-priority queue
–
One standard queue with no configurable threshold (effectively a tail-drop threshold at
100 percent).
–
One strict-priority queue
–
One standard queue with these thresholds:
—Eight thresholds, each configurable as either WRED-drop or tail-drop
—One non configurable (100 percent) tail-drop threshold
• 1p2q2t indicates the following:
–
One strict-priority queue
–
Two standard queues, each with two configurable WRED-drop thresholds
• 1p3q1t indicates the following:
–
One strict-priority queue
–
Three standard queues with these thresholds:
—One threshold configurable as either WRED-drop or tail-drop
• The match ip precedence and match ip dscp commands filter only IPv4 traffic.
• In Release 12.2(18)SXE and later releases, the match precedence and match dscp commands filter
IPv4 and IPv6 traffic.
• In Release 12.2(18)SXE and later releases, the set ip dscp and set ip precedence commands are
saved in the configuration file as set dscp and set precedence commands.
• In Release 12.2(18)SXE and later releases, PFC QoS supports the set dscp and set precedence
policy map class commands for IPv4 and IPv6 traffic.
• The flowmask requirements of QoS, NetFlow, and NetFlow data export (NDE) might conflict,
especially if you configure microflow policing.
• With egress ACL support for remarked DSCP and VACL capture both configured on an interface,
VACL capture might capture two copies of each packet, and the second copy might be corrupt.
• You cannot configure egress ACL support for remarked DSCP on tunnel interfaces.
• Egress ACL support for remarked DSCP supports IP unicast traffic.
• Egress ACL support for remarked DSCP is not relevant to multicast traffic. PFC QoS applies ingress
QoS changes to multicast traffic before applying egress QoS.
• NetFlow and NetFlow data export (NDE) do not support interfaces where egress ACL support for
remarked DSCP is configured.
Chapter 42 Configuring PFC QoS
• When egress ACL support for remarked DSCP is configured on any interface, you must configure
an interface-specific flowmask to enable NetFlow and NDE support on interfaces where egress ACL
support for remarked DSCP is not configured. Enter either the mls flow ip interface-destination-source or the mls flow ip interface-full global configuration mode
command.
• Interface counters are not accurate on interfaces where egress ACL support for remarked DSCP is
configured.
• You cannot apply microflow policing to IPv6 multicast traffic.
• You cannot apply microflow policing to traffic that has been permitted by egress ACL support for
remarked DSCP.
• Traffic that has been permitted by egress ACL support for remarked DSCP cannot be tagged as
MPLS traffic. (The traffic can be tagged as MPLS traffic on another network device.)
• When you apply both ingress policing and egress policing to the same traffic, both the input policy
and the output policy must either mark down traffic or drop traffic. PFC QoS does not support
ingress markdown with egress drop or ingress drop with egress markdown. (CSCea23571)
• If traffic is both aggregate and microflow policed, then the aggregate and microflow policers must
both be in the same policy-map class and each must use the same conform-action and
exceed-action keyword option: drop, set-dscp-transmit, set-prec-transmit, or transmit.
• You cannot configure PFC QoS features on tunnel interfaces.
• PFC QoS does not rewrite the payload ToS byte in tunnel traffic.
• PFC QoS filters only by ACLs, dscp values, or IP precedence values.
• The QoS features implemented in the port ASICs (queue architecture and dequeuing algorithms)
support IPv4 and IPv6 traffic.
• The PFC3 supports IPv6 named extended ACLs and named standard ACLs.
• In Release 12.2(18)SXE and later releases, the PFC3 supports the match protocol ipv6 command.
• Because of conflicting TCAM lookup flow key bit requirements, you cannot configure IPv6
DSCP-based filtering and IPv6 Layer 4 range-based filtering on the same interface. For example:
–
If you configure both a DSCP value and a Layer 4 “greater than” (gt) or “less than” (lt) operator
in an IPv6 ACE, you cannot use the ACL for PFC QoS filtering.
–
If you configure a DSCP value in one IPv6 ACL and a Layer 4 “greater than” (gt) or “less than”
(lt) operator in another IPv6 ACL, you cannot use both ACLs in different class maps on the same
interface for PFC QoS filtering.
• In Release 12.2(18)SXE and later releases, you can apply aggregate and microflow policers to IPv6
traffic, but you cannot apply microflow policing to IPv6 multicast traffic.
• With egress ACL support for remarked DSCP configured, the PFC3 does not provide
hardware-assistance for these features:
–
Cisco IOS reflexive ACLs
–
TCP intercept
–
Context-Based Access Control (CBAC)
Chapter 42 Configuring PFC QoS
• With a PFC3, you cannot apply microflow policing to ARP traffic.
• The PFC3 does not apply egress policing to traffic that is being bridged to the MSFC3.
• The PFC3 does not apply egress policing or egress DSCP mutation to multicast traffic from the
• With a PFC3, PFC QoS does not rewrite the ToS byte in bridged multicast traffic.
PFC2 Guidelines
• The PFC2 supports the match protocol class map command, which configures NBAR and sends all
• The PFC2 does not support these PFC QoS features:
• The PFC2 does not support the modules that support ingress CoS mutation on IEEE 802.1Q tunnel
–
Network Address Translation (NAT)
MSFC3.
traffic on the Layer 3 interface, both ingress and egress, to be processed in software on the MSFC2.
To configure NBAR, refer to this publication:
IP packets with COS changed by policing: 59998
Non-IP packets with COS changed by policing: 0
Router#
Enabling Ignore Port Trust
In Release 12.2(18)SXF5 and later releases, the ignore port trust feature allows an ingress policy to
apply a configured IP precedence or DSCP value to any traffic, rather than only to untrusted traffic.
To enable ignore port trust, perform this task:
CommandPurpose
Step 1
Step 2
Step 3
Router(config)# mls qos marking ignore port-trust
Router(config)# no mls qos marking ignore port-trust
Router(config)# end
Router# show mls qos | include ignores
Configuring PFC QoS
Enables ignore port trust globally on the router.
Disables ignore port trust globally on the router
(default).
Exits configuration mode.
Verifies the configuration.
NoteFor untrusted traffic, when ignore port trust is enabled, PFC QoS does the following:
• For IP traffic, PFC QoS uses the received DSCP value as the initial internal DSCP value.
• For traffic without a recognizable ToS byte, PFC QoS maps the port CoS value to the initial internal
DSCP value.
This example shows how to enable ignore port trust and verify the configuration:
Router# configure terminal
Router(config)# mls qos marking ignore port-trust
Router(config)# end
Router# show mls qos | include ignores
NoteThe router applies the port CoS value to untagged ingress traffic and to traffic that is received
through ports that cannot be configured to trust CoS.
This example shows how to enable queueing-only mode:
Router# configure terminal
Router(config)# mls qos queueing-only
Router(config)# end
Router#
Enabling Microflow Policing of Bridged Traffic
NoteWith a PFC2, to apply microflow policing to multicast traffic, you must enter the mls qos bridged
command on the Layer 3 multicast ingress interfaces.
By default, microflow policers affect only routed traffic. To enable microflow policing of bridged traffic
on specified VLANs, perform this task:
Configuring PFC QoS
Step 1
Step 2
Step 3
Step 4
CommandPurpose
Router(config)# interface {{vlanvlan_ID} |
1
{type
Router(config-if)# mls qos bridged
slot/port}}
Selects the interface to configure.
Enables microflow policing of bridged traffic, including
bridge groups, on the VLAN.
Router(config-if)# no mls qos bridged
Router(config-if)# end
Router# show mls qos
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Disables microflow policing of bridged traffic.
Exits configuration mode.
Verifies the configuration.
This example shows how to enable microflow policing of bridged traffic on VLANs 3 through 5:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface range vlan 3 - 5
Router(config-if)# mls qos bridged
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router# show mls qos | begin Bridged QoS
Bridged QoS is enabled on the following interfaces:
Vl3 Vl4 Vl5
<...output truncated...>
Router#
Note• With a PFC2, PFC QoS does not support VLAN-based QoS with DFCs installed.
• With a PFC3, PFC QoS supports VLAN-based QoS with DFC3s installed.
• With a PFC3, you can attach policy maps to Layer 3 interfaces for application of PFC QoS to egress
traffic. VLAN-based or port-based PFC QoS on Layer 2 ports is not relevant to application of
PFC QoS to egress traffic on Layer 3 interfaces.
By default, PFC QoS uses policy maps attached to LAN ports. For ports configured as Layer 2 LAN
ports with the switchport keyword, you can configure PFC QoS to use policy maps attached to a VLAN.
Ports not configured with the switchport keyword are not associated with a VLAN.
To enable VLAN-based PFC QoS on a Layer 2 LAN port, perform this task:
Enables VLAN-based PFC QoS on a Layer 2 LAN port or
a Layer 2 EtherChannel.
Router(config-if)# no mls qos vlan-based
Router(config-if)# end
Router# show mls qos
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Disables VLAN-based PFC QoS.
Exits configuration mode.
Verifies the configuration.
Chapter 42 Configuring PFC QoS
This example shows how to enable VLAN-based PFC QoS on Fast Ethernet port 5/42:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface fastethernet 5/42
Router(config-if)# mls qos vlan-based
Router(config-if)# end
This example shows how to verify the configuration:
Router# show mls qos | begin QoS is vlan-based
QoS is vlan-based on the following interfaces:
Fa5/42
<...Output Truncated...>
NoteConfiguring a Layer 2 LAN port for VLAN-based PFC QoS preserves the policy map port configuration.
The no mls qos vlan-based port command reenables any previously configured port commands.
To enable egress ACL support for remarked DSCP on an ingress interface, perform this task:
CommandPurpose
Step 1
Step 2
Step 3
Step 4
Router(config)# interface {{vlanvlan_ID} |
1
{type
Router(config-if)# platform ip features sequential [access-groupIP_acl_name_or_number]
Router(config-if)# no platform ip features sequential [access-groupIP_acl_name_or_number]
Router(config-if)# end
Router# show running-config interface
({type
slot/port} | {port-channelnumber}}
1
slot/port} | {port-channelnumber}}
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Selects the ingress interface to configure.
Enables egress ACL support for remarked DSCP on the
ingress interface.
Disables egress ACL support for remarked DSCP on the
ingress interface.
Exits configuration mode.
Verifies the configuration.
When configuring egress ACL support for remarked DSCP on an ingress interface, note the following
information:
Configuring PFC QoS
• To enable egress ACL support for remarked DSCP only for the traffic filtered by a specific standard,
extended named, or extended numbered IP ACL, enter the IP ACL name or number.
• If you do not enter an IP ACL name or number, egress ACL support for remarked DSCP is enabled
for all IP ingress IP traffic on the interface.
This example shows how to enable egress ACL support for remarked DSCP on Fast Ethernet port 5/36:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface fastethernet 5/36
Router(config-if)# platform ip features sequential
Router(config-if)# end
Creating Named Aggregate Policers
To create a named aggregate policer, perform this task:
When creating a named aggregate policer, note the following information:
• Aggregate policing works independently on each DFC-equipped switching module and
independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate
policing does not combine flow statistics from different DFC-equipped switching modules. You can
display aggregate policing statistics for each DFC-equipped switching module and for the PFC and
any non-DFC-equipped switching modules supported by the PFC.
• Each PFC or DFC polices independently, which might affect QoS features being applied to traffic
that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
–
Policers applied to a port channel interface.
–
Policers applied to a switched virtual interface.
–
Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs
egress policing decisions at the ingress interface, on the PFC or ingress DFC.
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent
policing rates.
• In Release 12.2(18)SXE and later releases, you can apply aggregate policers to IPv6 traffic.
• With a PFC3, policing uses the Layer 2 frame size.
• With a PFC2, policing uses the Layer 3 packet size.
• See the “PFC QoS Configuration Guidelines and Restrictions” section on page 42-49 for
information about rate and burst size granularity.
• The valid range of values for the CIR bits_per_second parameter is as follows:
–
Minimum—32 kilobits per second, entered as 32000
–
Maximum with Release 12.2(18)SXE and later releases:
10 gigabits per second, entered as 10000000000
–
Maximum with releases earlier than Release 12.2(18)SXE:
4 gigabits per second, entered as 4000000000
• The normal_burst_bytes parameter sets the CIR token bucket size.
• The maximum_burst_bytes parameter sets the PIR token bucket size.
• When configuring the size of a token bucket, note the following information:
–
The minimum token bucket size is 1 kilobyte, entered as 1000 (the maximum_burst_bytes
parameter must be set larger than the normal_burst_bytes parameter).
–
The maximum token bucket size is 32 megabytes, entered as 32000000.
–
To sustain a specific rate, set the token bucket size to be at least the rate value divided by 4000
because tokens are removed from the bucket every 1/4000th of a second (0.25 ms).
–
Because the token bucket must be large enough to hold at least one frame, set the parameter
larger than the maximum size of the traffic being policed.
–
For TCP traffic, configure the token bucket size as a multiple of the TCP window size, with a
minimum value at least twice as large as the maximum size of the traffic being policed.
• The valid range of values for the pirbits_per_second parameter is as follows:
• (Optional) You can specify a conform action for matched in-profile traffic as follows:
Configuring PFC QoS
–
Minimum—32 kilobits per second, entered as 32000 (the value cannot be smaller than the
CIR bits_per_second parameters)
–
Maximum with Release 12.2(18)SXE and later releases:
10 gigabits per second, entered as 10000000000
–
Maximum with releases earlier than Release 12.2(18)SXE:
4 gigabits per second, entered as 4000000000
–
The default conform action is transmit, which sets the policy map class trust state to trust
DSCP unless the policy map class contains a trust command.
–
To set PFC QoS labels in untrusted traffic, enter the set-dscp-transmit keyword to mark
matched untrusted traffic with a new DSCP value or enter the set-prec-transmit keyword to
mark matched untrusted traffic with a new IP precedence value. The set-dscp-transmit and
set-prec-transmit keywords are only supported for IP traffic. PFC QoS sets egress ToS and
CoS from the configured value.
–
Enter the drop keyword to drop all matched traffic.
NoteWhen you configure drop as the conform action, PFC QoS configures drop as the exceed
action and the violate action.
• (Optional) For traffic that exceeds the CIR, you can specify an exceed action as follows:
–
The default exceed action is drop, except with a maximum_burst_bytes parameter (drop is not
supported with a maximum_burst_bytes parameter).
NoteWhen the exceed action is drop, PFC QoS ignores any configured violate action.
–
Enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be
marked down as specified in the markdown map.
NoteWhen you create a policer that does not use the pir keyword and the maximum_burst_bytes
parameter is equal to the normal_burst_bytes parameter (which is the case if you do not enter
the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords
cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown
map.
• (Optional) For traffic that exceeds the PIR, you can specify a violate action as follows:
–
To mark traffic without policing, enter the transmit keyword to transmit all matched
out-of-profile traffic.
–
The default violate action is equal to the exceed action.
OL-4266-08
–
Enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be
marked down as specified in the markdown map.
–
For marking without policing, enter the transmit keyword to transmit all matched out-of-profile
traffic.
NoteWhen you apply both ingress policing and egress policing to the same traffic, both the input policy and
Chapter 42 Configuring PFC QoS
the output policy must either mark down traffic or drop traffic. PFC QoS does not support ingress
markdown with egress drop or ingress drop with egress markdown.
This example shows how to create a named aggregate policer with a 1-Mbps rate limit and a 10-MB burst
size that transmits conforming traffic and marks down out-of-profile traffic:
NoteTo mark traffic without limiting bandwidth utilization, create a policer that uses the transmit keywords
for both conforming and nonconforming traffic.
These commands configure traffic classes and the policies to be applied to those traffic classes and attach
the policies to ports:
• access-list (Optional for IP traffic. You can filter IP traffic with class-map commands.):
–
PFC QoS supports these ACL types:
ProtocolNumbered ACLsExtended ACLsNamed ACLs
IPv4Yes:
IPv6—Yes (named)Yes
IPX
(Supported only with PFC2)
MAC Layer NoNoYes
ARP NoNoYes
Configuring PFC QoS
1 to 99
1300 to 1999
Yes:
100 to 199
2000 to 2699
Yes
Yes: 800 to 899Yes: 900 to 999Yes
–
The PFC3 supports IPv6 named extended ACLs and named standard ACLs in Release
12.2(18)SXE and later releases.
–
The PFC3 supports ARP ACLs in Release 12.2(18)SXD and later releases.
Note—The PFC2 applies IP ACLs to ARP traffic.
—The PFC3 does not apply IP ACLs to ARP traffic.
—With a PFC3, you cannot apply microflow policing to ARP traffic.
–
The PFC3 does not support IPX ACLs. With the PFC3, you can configure MAC ACLs to filter
IPX traffic.
–
With a PFC2, PFC QoS supports IPX ACLs that contain a source-network parameter and the
optional destination-network and destination-node parameters. PFC QoS does not support IPX
ACLs that contain other parameters (for example, source-node, protocol, source-socket, destination-socket, or service-type).
–
With a PFC2 or PFC3, PFC QoS supports time-based Cisco IOS ACLs.
–
Except for MAC ACLs and ARP ACLs, refer to the Cisco IOS Security Configuration Guide,
Release 12.2, “Traffic Filtering and Firewalls,” at this URL:
• class-map (optional)—Enter the class-map command to define one or more traffic classes by
specifying the criteria by which traffic is classified.
• policy-map—Enter the policy-map command to define the following:
• service-policy—Enter the service-policy command to attach a policy map to an interface.
Configuring MAC ACLs
These sections describe MAC ACL configuration:
• Configuring Protocol-Independent MAC ACL Filtering, page 42-66
• Enabling VLAN-Based MAC QoS Filtering, page 42-67
• Configuring MAC ACLs, page 42-68
–
Policy map class trust mode
–
Aggregate policing and marking
–
Microflow policing and marking
Chapter 42 Configuring PFC QoS
NoteYou can use MAC ACLs with VLAN ACLs (VACLs). For more information, see Chapter 36,
“Configuring VLAN ACLs.”
Configuring Protocol-Independent MAC ACL Filtering
With Release 12.2(18)SXD and later releases, PFC3BXL and PFC3B modes support
protocol-independent MAC ACL filtering. Protocol-independent MAC ACL filtering applies MAC
ACLs to all ingress traffic types (for example, IPv4 traffic, IPv6 traffic, and MPLS traffic, in addition to
MAC-layer traffic).
You can configure these interface types for protocol-independent MAC ACL filtering:
• VLAN interfaces without IP addresses
• Physical LAN ports configured to support EoMPLS
• Logical LAN subinterfaces configured to support EoMPLS
Ingress traffic permitted or denied by a MAC ACL on an interface configured for protocol-independent
MAC ACL filtering is processed by egress interfaces as MAC-layer traffic. You cannot apply egress IP
ACLs to traffic that was permitted or denied by a MAC ACL on an interface configured for
protocol-independent MAC ACL filtering.
To configure protocol-independent MAC ACL filtering, perform this task:
CommandPurpose
Step 1
Step 2
Router(config)# interface {{vlanvlan_ID} |
1
{type
{port-channel number[.subinterface]}}
Router(config-if)# mac packet-classify
Router(config-if)# no mac packet-classify
slot/port[.subinterface]} |
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Selects the interface to configure.
Enables protocol-independent MAC ACL filtering on the
interface.
Disables protocol-independent MAC ACL filtering on the
interface.
When configuring protocol-independent MAC ACL filtering, note the following information:
• Do not configure protocol-independent MAC ACL filtering on VLAN interfaces where you have
configured an IP address.
• Do not configure protocol-independent MAC ACL filtering with microflow policing when the
permitted traffic would be bridged or Layer 3 switched in hardware by the PFC3BXL.
• Protocol-independent MAC ACL filtering supports microflow policing when the permitted traffic is
routed in software by the MSFC3.
This example shows how to configure VLAN interface 4018 for protocol-independent MAC ACL
filtering and how to verify the configuration:
Router(config)# interface vlan 4018
Router(config-if)# mac packet-classify
Router(config-if)# end
Router# show running-config interface vlan 4018 | begin 4018
interface Vlan4018
mtu 9216
ipv6 enable
mac packet-classify
end
Configuring PFC QoS
This example shows how to configure Gigabit Ethernet interface 6/1 for protocol-independent MAC
ACL filtering and how to verify the configuration:
Router(config)# interface gigabitethernet 6/1
Router(config-if)# mac packet-classify
Router(config-if)# end
Router# show running-config interface gigabitethernet 6/1 | begin 6/1
interface GigabitEthernet6/1
mtu 9216
no ip address
mac packet-classify
mpls l2transport route 4.4.4.4 4094
end
This example shows how to configure Gigabit Ethernet interface 3/24, subinterface 4000, for
protocol-independent MAC ACL filtering and how to verify the configuration:
Router(config)# interface gigabitethernet 3/24.4000
Router(config-if)# mac packet-classify
Router(config-if)# end
Router# show running-config interface gigabitethernet 3/24.4000 | begin 3/24.4000
interface GigabitEthernet3/24.4000
encapsulation dot1Q 4000
mac packet-classify
mpls l2transport route 4.4.4.4 4000
end
Enabling VLAN-Based MAC QoS Filtering
In Release 12.2(18)SXD and later releases in PFC3BXL or PFC3B mode, you can globally enable or
disable VLAN-based QoS filtering in MAC ACLs. VLAN-based QoS filtering in MAC ACLs is disabled
by default.
To enable VLAN-based QoS filtering in MAC ACLs, perform this task:
To disable VLAN-based QoS filtering in MAC ACLs, perform this task:
CommandPurpose
Router(config)# no mac packet-classify use vlan
Disables VLAN-based QoS filtering in MAC ACLs.
Configuring MAC ACLs
You can configure named ACLs that filter IPX, DECnet, AppleTalk, VINES, or XNS traffic based on
MAC addresses (IPX filtering with a MAC ACL is supported only with a PFC3).
In Release 12.2(17b)SXA and later releases in PFC3BXL or PFC3B mode, you can configure MAC
ACLs that do VLAN-based filtering or CoS-based filtering or both.
In Release 12.2(18)SXD and later releases, you can globally enable or disable VLAN-based QoS
filtering in MAC ACLs (disabled by default).
To configure a MAC ACL, perform this task:
CommandPurpose
Step 1
Step 2
Router(config)# mac access-list extendedlist_name
Router(config)# no mac access-list extendedlist_name
This example shows how to create a MAC-Layer ACL named mac_layer that denies dec-phase-iv traffic
with source address 0000.4700.0001 and destination address 0000.4700.0009, but permits all other
traffic:
Router(config)# mac access-list extended mac_layer
Router(config-ext-macl)# deny 0000.4700.0001 0.0.0 0000.4700.0009 0.0.0 dec-phase-iv
Router(config-ext-macl)# permit any any
Configuring ARP ACLs for QoS Filtering
OL-4266-08
Note• The PFC2 applies IP ACLs to ARP traffic.
• The PFC3 does not apply IP ACLs to ARP traffic.
• With a PFC3, you cannot apply microflow policing to ARP traffic.
When configuring class map filtering, follow these guidelines and restrictions:
• With Release 12.2(18)SXE and later releases, PFC QoS supports multiple match criteria in class
maps configured with the match-any keywords.
• With releases earlier than Release 12.2(18)SXE, PFC QoS supports class maps that contain a single
match command.
• With Release 12.2(18)SXE and later releases, the PFC3 supports the match protocol ipv6
command.
• Because of conflicting TCAM lookup flow key bit requirements, you cannot configure IPv6
DSCP-based filtering and IPv6 Layer 4 range-based filtering on the same interface. For example:
–
If configure both a DSCP value and a Layer 4 greater than (gt) or less than (lt) operator in an
IPv6 ACE, you cannot use the ACL for PFC QoS filtering.
–
If configure a DSCP value in one IPv6 ACL and a Layer 4 greater than (gt) or less than (lt)
operator in another IPv6 ACL, you cannot use both ACLs in different class maps on the same
interface for PFC QoS filtering.
• Release 12.2(18)SXE and later releases support the match protocol ip command for IPv4 traffic.
• PFC QoS does not support the match cos, match any, match classmap, match
destination-address, match input-interface, match qos-group, and match source-address class
map commands.
• Cisco 7600 series routers do not detect the use of unsupported commands until you attach a policy
map to an interface.
Configuring PFC QoS
• The PFC2 support the match protocol class map command, which configures NBAR and sends all
traffic on the Layer 3 interface, both ingress and egress, to be processed in software on the MSFC2.
To configure NBAR, refer to this publication:
(Optional—for IPv6 traffic) Configures the class map to filter
IPv6 traffic.
Router (config-cmap)# no match protocol ipv6
Router (config-cmap)# match precedenceipp_value1
[ipp_value2 [ipp_valueN]]
Router (config-cmap)# no match precedenceipp_value1
[ipp_value2 [ipp_valueN]]
Router (config-cmap)# match dscpdscp_value1
[dscp_value2 [dscp_valueN]]
Router (config-cmap)# no match dscpdscp_value1
[dscp_value2 [dscp_valueN]]
Router (config-cmap)# match ip precedenceipp_value1
[ipp_value2 [ipp_valueN]]
Router (config-cmap)# no match ip precedenceipp_value1 [ipp_value2 [ipp_valueN]]
Router (config-cmap)# match ip dscpdscp_value1
[dscp_value2 [dscp_valueN]]
Router (config-cmap)# no match ip dscpdscp_value1
[dscp_value2 [dscp_valueN]]
Clears IPv6 filtering.
(Optional—for IPv4 or IPv6 traffic) Configures the class map
to filter based on up to eight IP precedence values.
NoteDoes not support source-based or destination-based
Clears configured IP precedence values from the class map.
(Optional—for IPv4 or IPv6 traffic only) Configures the class
map to filter based on up to eight DSCP values.
NoteDoes not support source-based or destination-based
Clears configured DSCP values from the class map.
(Optional—for IPv4 traffic) Configures the class map to filter
based on up to eight IP precedence values.
NoteDoes not support source-based or destination-based
Clears configured IP precedence values from the class map.
(Optional—for IPv4 traffic) Configures the class map to filter
based on up to eight DSCP values.
NoteDoes not support source-based or destination-based
Clears configured DSCP values from the class map.
Chapter 42 Configuring PFC QoS
microflow policing.
microflow policing.
microflow policing.
microflow policing.
Verifying Class Map Configuration
To verify class map configuration, perform this task:
CommandPurpose
Step 1
Step 2
Router (config-cmap)# end
Router# show class-mapclass_name
This example shows how to create a class map named ipp5 and how to configure filtering to match traffic
with IP precedence 5:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# class-map ipp5
Router(config-cmap)# match ip precedence 5
Router(config-cmap)# end
This example shows how to verify the configuration:
Router# show class-map ipp5
Class Map match-all ipp5 (id 1)
Match ip precedence 5
Configuring a Policy Map
You can attach only one policy map to an interface. Policy maps can contain one or more policy map
classes, each with different policy map commands.
Configure a separate policy map class in the policy map for each type of traffic that an interface receives.
Put all commands for each type of traffic in the same policy map class. PFC QoS does not attempt to
apply commands from more than one policy map class to matched traffic.
These sections describe policy map configuration:
• Creating a Policy Map, page 42-73
• Policy Map Class Configuration Guidelines and Restrictions, page 42-73
• Creating a Policy Map Class and Configuring Filtering, page 42-74
• Configuring Policy Map Class Actions, page 42-74
Configuring PFC QoS
Creating a Policy Map
To create a policy map, perform this task:
CommandPurpose
Router(config)# policy-map policy_name
Router(config)# no policy-map policy_name
Creates a policy map.
Deletes the policy map.
Policy Map Class Configuration Guidelines and Restrictions
When you configuring policy map classes, follow the guidelines and restrictions:
• The PFC2 support the class class_nameprotocol policy map command, which configures NBAR
and sends all traffic on the Layer 3 interface, both ingress and egress, to be processed in software
on the MSFC2. To configure NBAR, refer to this publication:
Creating a Policy Map Class and Configuring Filtering
To create a policy map class and configure it to filter with a class map, perform this task:
CommandPurpose
Router(config-pmap)# classclass_name
Creates a policy map class and configures it to filter with a
class map.
NotePFC QoS supports class maps that contain a single
Router(config-pmap)# no classclass_name
Clears use of the class map.
Configuring Policy Map Class Actions
When configuring policy map class actions, note the following information:
• Policy maps can contain one or more policy map classes.
• Put all trust-state and policing commands for each type of traffic in the same policy map class.
• PFC QoS only applies commands from one policy map class to traffic. After traffic has matched the
filtering in one policy map class, QoS does apply the filtering configured in other policy map
classes.
• For hardware-switched traffic, PFC QoS does not support the bandwidth, priority, queue-limit, or
random-detect policy map class commands. You can configure these commands because they can
be used for software-switched traffic.
Chapter 42 Configuring PFC QoS
match command.
• PFC QoS does not support the set qos-group policy map class commands.
• PFC QoS supports the set ip dscp and set ip precedence policy map class commands for IPv4
traffic.
–
In Release 12.2(18)SXD and later releases and in Release 12.2(17d)SXB and later releases, you
can use the set ip dscp and set ip precedence commands on non-IP traffic to mark the internal
DSCP value, which is the basis of the egress Layer 2 CoS value.
–
In Release 12.2(18)SXE and later releases, the set ip dscp and set ip precedence commands
are saved in the configuration file as set dscp and set precedence commands.
• In Release 12.2(18)SXE and later releases, PFC QoS supports the set dscp and set precedence
policy map class commands for IPv4 and IPv6 traffic.
• You cannot do all three of the following in a policy map class:
–
Mark traffic with the set commands
–
Configure the trust state
–
Configure policing
In a policy map class, you can either mark traffic with the set commands or do one or both of the
following:
–
Configure the trust state
–
Configure policing
42-74
NoteWhen configure policing, you can mark traffic with policing keywords.
These sections describe policy map class action configuration:
• Configuring Policy Map Class Marking, page 42-75
• Configuring the Policy Map Class Trust State, page 42-75
• Configuring Policy Map Class Policing, page 42-76
Configuring Policy Map Class Marking
In Release 12.2(18)SXF5 and later releases, when the ignore port trust feature is enabled, PFC QoS
supports policy map class marking for all traffic with set policy map class commands.
In all releases, PFC QoS supports policy map class marking for untrusted traffic with set policy map
class commands.
To configure policy map class marking, perform this task:
CommandPurpose
Router(config-pmap-c)# set {dscp dscp_value |
precedence ip_precedence_value}
Router(config-pmap-c)# no set {dscp dscp_value |
precedence ip_precedence_value}
Configures the policy map class to mark matched untrusted
traffic with the configured DSCP or IP precedence value.
Clears the marking configuration.
Configuring PFC QoS
NoteReleases earlier than Release 12.2(18)SXE support the set ip dscp and set ip precedence policy map
class commands.
Configuring the Policy Map Class Trust State
NoteYou cannot attach a policy map that configures a trust state with the service-policy output command.
To configure the policy map class trust state, perform this task:
When configuring a per-interface policer, note the following information:
• Aggregate policing works independently on each DFC-equipped switching module and
independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate
policing does not combine flow statistics from different DFC-equipped switching modules. You can
display aggregate policing statistics for each DFC-equipped switching module and for the PFC and
any non-DFC-equipped switching modules supported by the PFC.
• Each PFC or DFC polices independently, which might affect QoS features being applied to traffic
that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent
policing rates.
• With a PFC3, when you apply both ingress policing and egress policing to the same traffic, both the
input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not
support ingress markdown with egress drop or ingress drop with egress markdown.
Configuring PFC QoS
–
Policers applied to a port channel interface.
–
Policers applied to a switched virtual interface.
–
Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs
egress policing decisions at the ingress interface, on the PFC or ingress DFC.
• With Release 12.2(18)SXE and later releases, you can apply aggregate and microflow policers to
IPv6 traffic.
• With a PFC3, policing uses the Layer 2 frame size.
• With a PFC2, policing uses the Layer 3 packet size.
• See the “PFC QoS Configuration Guidelines and Restrictions” section on page 42-49 for
information about rate and burst size granularity.
• You can enter the flow keyword to define a microflow policer (you cannot apply microflow policing
to ARP traffic). When configuring a microflow policer, note the following information:
–
With a PFC3, you can enter the mask src-only keywords to base flow identification only on
source addresses, which applies the microflow policer to all traffic from each source address.
Release 12.2(17d)SXB and later releases support the mask src-only keywords for both IP
traffic and MAC traffic. Releases earlier than Release 12.2(17d)SXB support the mask src-only
keywords only for IP traffic.
–
With a PFC3, you can enter the mask dest-only keywords to base flow identification only on
destination addresses, which applies the microflow policer to all traffic to each source address.
Release 12.2(17d)SXB and later releases support the mask dest-only keywords for both IP
traffic and MAC traffic. Releases earlier than Release 12.2(17d)SXB support the mask dest-only keywords only for IP traffic.
–
By default and with the mask full-flow keywords, PFC QoS bases IP flow identification on
source IP address, destination IP address, the Layer 3 protocol, and Layer 4 port numbers.
–
With a PFC2, PFC QoS considers IPX traffic with same source network, destination network,
and destination node to be part of the same flow, including traffic with different source nodes
or sockets.
–
PFC QoS considers MAC-Layer traffic with the same protocol and the same source and
destination MAC-Layer addresses to be part of the same flow, including traffic with different
EtherTypes.
–
Microflow policers do not support the maximum_burst_bytes parameter, the pir bits_per_second keyword and parameter, or the violate-action keyword.
NoteThe flowmask requirements of microflow policing, NetFlow, and NetFlow data export
(NDE) might conflict.
• The valid range of values for the CIR bits_per_second parameter is as follows:
–
Minimum—32 kilobits per second, entered as 32000
–
Maximum with Release 12.2(18)SXE and later releases:
10 gigabits per second, entered as 10000000000
–
Maximum with releases earlier than Release 12.2(18)SXE:
4 gigabits per second, entered as 4000000000
• The normal_burst_bytes parameter sets the CIR token bucket size.
• The maximum_burst_bytes parameter sets the PIR token bucket size (not supported with the flow
keyword)
• When configuring the size of a token bucket, note the following information:
–
The minimum token bucket size is 1 kilobyte, entered as 1000 (the maximum_burst_bytes
parameter must be set larger than the normal_burst_bytes parameter)
–
The maximum token bucket size is 32 megabytes, entered as 32000000
–
To sustain a specific rate, set the token bucket size to be at least the rate value divided by 4000,
because tokens are removed from the bucket every 1/4000th of a second (0.25 ms).
–
Because the token bucket must be large enough to hold at least one frame, set the parameter
larger than the maximum size of the traffic being policed.
–
For TCP traffic, configure the token bucket size as a multiple of the TCP window size, with a
minimum value at least twice as large as the maximum size of the traffic being policed.
• (Not supported with the flow keyword.) The valid range of values for the pir bits_per_second
parameter is as follows:
–
Minimum—32 kilobits per second, entered as 32000 (the value cannot be smaller than the CIR
bits_per_second parameters)
–
Maximum with Release 12.2(18)SXE and later releases:
10 gigabits per second, entered as 10000000000
–
Maximum with releases earlier than Release 12.2(18)SXE:
4 gigabits per second, entered as 4000000000
• (Optional) You can specify a conform action for matched in-profile traffic as follows:
–
The default conform action is transmit, which sets the policy map class trust state to trust
DSCP unless the policy map class contains a trust command.
–
To set PFC QoS labels in untrusted traffic, you can enter the set-dscp-transmit keyword to
mark matched untrusted traffic with a new DSCP value or enter the set-prec-transmit keyword
to mark matched untrusted traffic with a new IP precedence value. The set-dscp-transmit and
set-prec-transmit keywords are only supported for IP traffic. PFC QoS sets egress ToS and
CoS from the configured value.
–
You can enter the drop keyword to drop all matched traffic.
–
Ensure that aggregate and microflow policers that are applied to the same traffic each specify
the same conform-action behavior.
• (Optional) For traffic that exceeds the CIR, you can specify an exceed action as follows:
NoteWhen the exceed action is drop, PFC QoS ignores any configured violate action.
NoteWhen you create a policer that does not use the pir keyword and the maximum_burst_bytes
Configuring PFC QoS
–
For marking without policing, you can enter the transmit keyword to transmit all matched
out-of-profile traffic.
–
The default exceed action is drop, except with a maximum_burst_bytes parameter (drop is not
supported with a maximum_burst_bytes parameter).
–
You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to
be marked down as specified in the markdown map.
parameter is equal to the normal_burst_bytes parameter (which is the case if you do not enter
the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords
cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown
map.
• (Optional—Not supported with the flow keyword) for traffic that exceeds the PIR, you can specify
a violate action as follows:
–
For marking without policing, you can enter the transmit keyword to transmit all matched
out-of-profile traffic.
–
The default violate action is equal to the exceed action.
–
You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to
be marked down as specified in the markdown map.
This example shows how to create a policy map named max-pol-ipp5 that uses the class-map named
ipp5, which is configured to trust received IP precedence values and is configured with a
maximum-capacity aggregate policer and with a microflow policer:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# policy-map max-pol-ipp5
Router(config-pmap)# class ipp5
Router(config-pmap-c)# trust ip-precedence
Router(config-pmap-c)# police 2000000000 2000000 conform-action set-prec-transmit 6 exceed-action policed-dscp-transmit
Router(config-pmap-c)# police flow 10000000 10000 conform-action set-prec-transmit 6 exceed-action policed-dscp-transmit
Router(config-pmap-c)# end
Verifying Policy Map Configuration
To verify policy map configuration, perform this task:
Router(config-if)# no service-policy [input |
output] policy_map_name
Router(config-if)# end
Router# show policy-map interface {{vlanvlan_ID}
| {type
slot/port[.subinterface]} | {port-channel
1
slot/port} | {port-channelnumber}}
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Chapter 42 Configuring PFC QoS
Selects the interface to configure.
Attaches a policy map to the interface.
Removes the policy map from the interface.
Exits configuration mode.
Verifies the configuration.
42-80
When attaching a policy map to an interface, note the following information:
• Do not attach a service policy to a port that is a member of an EtherChannel.
• With DFCs installed, PFC2 does not support VLAN-based QoS: you cannot enter the mls qos
vlan-based command or attach service policies to VLAN interfaces.
• PFC QoS supports the output keyword only with a PFC3 and only on Layer 3 interfaces (either LAN
ports configured as Layer 3 interfaces or VLAN interfaces). With a PFC3, you can attach both an
input and an output policy map to a Layer 3 interface.
• VLAN-based or port-based PFC QoS on Layer 2 ports is not relevant to policies attached to Layer
3 interfaces with the output keyword.
• Policies attached with the output keyword do not support microflow policing.
• You cannot attach a policy map that configures a trust state with the service-policy output
command.
• Filtering based on IP precedence or DSCP in policies attached with the output keyword uses the
received IP precedence or DSCP values. Filtering based on IP precedence or DSCP in policies
attached with the output keyword is not based on any IP precedence or DSCP changes made by
ingress QoS.
• Aggregate policing works independently on each DFC-equipped switching module and
independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate
policing does not combine flow statistics from different DFC-equipped switching modules. You can
display aggregate policing statistics for each DFC-equipped switching module and for the PFC and
any non-DFC-equipped switching modules supported by the PFC.
• Each PFC or DFC polices independently, which might affect QoS features being applied to traffic
that is distributed across the PFC and any DFCs. Examples of these QoS feature are:
Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent
policing rates.
• With a PFC3, when you apply both ingress policing and egress policing to the same traffic, both the
input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not
support ingress markdown with egress drop or ingress drop with egress markdown.
This example shows how to attach the policy map named pmap1 to Fast Ethernet port 5/36:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface fastethernet 5/36
Router(config-if)# service-policy input pmap1
Router(config-if)# end
Configuring PFC QoS
–
Policers applied to a port channel interface.
–
Policers applied to a switched virtual interface.
–
Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs
egress policing decisions at the ingress interface, on the PFC or ingress DFC.
This example shows how to verify the configuration:
Router# show policy-map interface fastethernet 5/36
FastEthernet5/36
service-policy input: pmap1
class-map: cmap1 (match-all)
0 packets, 0 bytes
5 minute rate 0 bps
match: ip precedence 5
class cmap1
police 8000 8000 conform-action transmit exceed-action drop
class-map: cmap2 (match-any)
0 packets, 0 bytes
5 minute rate 0 bps
match: ip precedence 2
0 packets, 0 bytes
5 minute rate 0 bps
class cmap2
police 8000 10000 conform-action transmit exceed-action drop
Router#
Router(config)# no mls qos map dscp-mutationmap_name
Router(config)# end
Router# show mls qos maps
Configures a named DSCP mutation map.
Reverts to the default map.
Exits configuration mode.
Verifies the configuration.
Chapter 42 Configuring PFC QoS
When configuring a named DSCP mutation map, note the following information:
• You can enter up to 8 DSCP values that map to a mutated DSCP value.
• You can enter multiple commands to map additional DSCP values to a mutated DSCP value.
• You can enter a separate command for each mutated DSCP value.
This example shows how to map DSCP 30 to mutated DSCP value 8:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls qos map dscp-mutation mutmap1 30 to 8
Router(config)# end
Router#
This example shows how to verify the configuration:
NoteIn the DSCP mutation map displays, the marked-down DSCP values are shown in the body of the matrix;
the first digit of the original DSCP value is in the column labeled d1 and the second digit is in the top
row. In the example shown, DSCP 30 maps to DSCP 08.
Attaching an Egress DSCP Mutation Map to an Interface
To attach an egress DSCP mutation map to an interface, perform this task:
Router(config-if)# no mls qos dscp-mutationmutation_map_name
Router(config-if)# end
Router# show running-config interface {{vlan
vlan_ID} | {type
number}}
slot/port[.subinterface]} |
1
slot/port} | {port-channel
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Selects the interface to configure.
Attaches an egress DSCP mutation map to the interface.
Removes the egress DSCP mutation map from the
interface.
Exits configuration mode.
Verifies the configuration.
Configuring PFC QoS
This example shows how to attach the egress DSCP mutation map named mutmap1 to Fast Ethernet
port 5/36:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface fastethernet 5/36
Router(config-if)# mls qos dscp-mutation mutmap1
Router(config-if)# end
Configuring Ingress CoS Mutation on IEEE 802.1Q Tunnel Ports
NoteThe Supervisor Engine 2 does not support the switching modules that support ingress CoS mutation.
Release 12.2(17b)SXA and later releases support ingress CoS mutation on IEEE 802.1Q tunnel ports
configured to trust received CoS (see the “Ingress CoS Mutation Configuration Guidelines and
Restrictions” section on page 42-84 for the list of supported modules).
When you configure ingress CoS mutation on an IEEE 802.1Q tunnel port that you have configured to
trust received CoS, PFC QoS uses the mutated CoS value instead of the received CoS value in the ingress
drop thresholds and for any trust CoS marking and policing.
These sections describe how to configure ingress CoS mutation:
• Ingress CoS Mutation Configuration Guidelines and Restrictions, page 42-84
• Configuring Ingress CoS Mutation Maps, page 42-85
OL-4266-08
• Applying Ingress CoS Mutation Maps to IEEE 802.1Q Tunnel Ports, page 42-85
Ingress CoS Mutation Configuration Guidelines and Restrictions
When configuring ingress CoS mutation, follow these guidelines and restrictions:
• Release 12.2(17b)SXA and later releases support ingress CoS mutation on WS-X6704-10GE,
WS-X6748-SFP, WS-X6724-SFP, and WS-X6748-GE-TX switching modules.
• Ports that are not configured as IEEE 802.1Q tunnel ports do not support ingress CoS mutation.
• Ports that are not configured to trust received CoS do not support ingress CoS mutation.
• Ingress CoS mutation does not change the CoS value carried by the customer frames. When the
customer traffic exits the 802.1Q tunnel, the original CoS is intact.
• Ingress CoS mutation configuration applies to all ports in a port group. The port groups are:
–
WS-X6704-10GE—4 ports, 4 port groups, 1 port in each group
–
WS-X6748-SFP—48 ports, 4 port groups: ports 1–12, 13–24, 25–36, and 37–48
–
WS-X6724-SFP—24 ports, 2 port groups: ports 1–12 and 13–24
–
WS-X6748-GE-TX—48 ports, 4 port groups: ports 1–12, 13–24, 25–36, and 37–48
• To avoid ingress CoS mutation configuration failures, only create EtherChannels where all member
ports support ingress CoS mutation or where no member ports support ingress CoS mutation. Do not
create EtherChannels with mixed support for ingress CoS mutation.
• If you configure ingress CoS mutation on a port that is a member of an EtherChannel, the ingress
CoS mutation is applied to the port-channel interface.
• You can configure ingress CoS mutation on port-channel interfaces.
Chapter 42 Configuring PFC QoS
• With ingress CoS mutation configured on a port-channel interface, the following occurs:
–
The ingress CoS mutation configuration is applied to the port groups of all member ports of the
EtherChannel. If any member port cannot support ingress CoS mutation, the configuration fails.
–
If a port in the port group is a member of a second EtherChannel, the ingress CoS mutation
configuration is applied to the second port-channel interface and to the port groups of all
member ports of the second EtherChannel. If any member port of the second EtherChannel
cannot support ingress CoS mutation, the configuration fails on the first EtherChannel. If the
configuration originated on a nonmember port in a port group that has a member port of the first
EtherChannel, the configuration fails on the nonmember port.
–
The ingress CoS mutation configuration propagates without limit through port groups, member
ports, and port-channel interfaces, regardless of whether or not the ports are configured to trust
CoS or are configured as IEEE 802.1Q tunnel ports.
• An EtherChannel where you want to configure ingress CoS mutation must not have member ports
that are in port groups containing member ports of other EtherChannels that have member ports that
do not support ingress CoS mutation. (This restriction extends without limit through all
port-group-linked member ports and port-channel-interface-linked ports.)
• A port where you want to configure ingress CoS mutation must not be in a port group that has a
member port of an EtherChannel that has members that do not support ingress CoS mutation. (This
restriction extends without limit through all port-group-linked member ports and
port-channel-interface-linked ports.)
• There can be only be one ingress CoS mutation configuration applied to all port-group-linked
member ports and port-channel-interface-linked ports.
Router(config)# no mls qos map cos-mutationmap_name
Router(config)# end
Router# show mls qos maps cos-mutation
This example shows how to configure a CoS mutation map named testmap:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls qos map cos-mutation testmap 4 5 6 7 0 1 2 3
Router(config)# end
Router#
Configuring PFC QoS
Configures an ingress CoS mutation map. You must enter
8 mutated CoS values to which PFC QoS maps ingress
CoS values 0 through 7.
Deletes the named map.
Exits configuration mode.
Verifies the configuration.
This example shows how to verify the map configuration:
Router(config)# show mls qos maps cos-mutation
COS mutation map testmap
cos-in : 0 1 2 3 4 5 6 7
This example shows how to configure the received CoS to internal DSCP map:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls qos map cos-dscp 0 1 2 3 4 5 6 7
Router(config)# end
Router#
Configures the received CoS to internal DSCP map. You
must enter 8 DSCP values to which PFC QoS maps CoS
values 0 through 7.
Configures the received IP precedence to internal DSCP
map. You must enter 8 internal DSCP values to which
PFC QoS maps received IP precedence values 0
through 7.
Reverts to the default map.
Exits configuration mode.
Verifies the configuration.
Configuring PFC QoS
This example shows how to configure the received IP precedence to internal DSCP map:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls qos map ip-prec-dscp 0 1 2 3 4 5 6 7
Router(config)# end
Router#
This example shows how to verify the configuration:
Router# show mls qos maps | begin IpPrecedence-dscp map
IpPrecedence-dscp map:
ipprec: 0 1 2 3 4 5 6 7
When configuring a DSCP markdown map, note the following information:
• You can enter the normal-burst keyword to configure the markdown map used by the
exceed-action policed-dscp-transmit keywords.
• You can enter the max-burst keyword to configure the markdown map used by the violate-action
policed-dscp-transmit keywords.
NoteWhen you create a policer that does not use the pir keyword, and the maximum_burst_bytes
parameter is equal to the normal_burst_bytes parameter (which occurs if you do not enter
the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords
cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown
map.
• To avoid out-of-sequence packets, configure the markdown maps so that conforming and
nonconforming traffic uses the same queue.
• You can enter up to 8 DSCP values that map to a marked-down DSCP value.
• You can enter multiple commands to map additional DSCP values to a marked-down DSCP value.
• You can enter a separate command for each marked-down DSCP value.
NoteConfigure marked-down DSCP values that map to CoS values consistent with the markdown penalty.
This example shows how to map DSCP 1 to marked-down DSCP value 0:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls qos map policed-dscp normal-burst 1 to 0
Router(config)# end
Router#
This example shows how to verify the configuration:
NoteIn the Policed-dscp displays, the marked-down DSCP values are shown in the body of the matrix; the
first digit of the original DSCP value is in the column labeled d1 and the second digit is in the top row.
In the example shown, DSCP 41 maps to DSCP 41.
Mapping Internal DSCP Values to Egress CoS Values
To configure the mapping of the DSCP value that PFC QoS uses internally on the PFC to the CoS value
used for egress LAN port scheduling and congestion avoidance, perform this task:
When configuring the internal DSCP to egress CoS map, note the following information:
• You can enter up to 8 DSCP values that PFC QoS maps to a CoS value.
• You can enter multiple commands to map additional DSCP values to a CoS value.
• You can enter a separate command for each CoS value.
This example shows how to configure internal DSCP values 0, 8, 16, 24, 32, 40, 48, and 54 to be mapped
to egress CoS value 0:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# mls qos map dscp-cos 0 8 16 24 32 40 48 54 to 0
Router(config)# end
Router#
Router(config-if)# mls qos trust [dscp |
ip-precedence | cos
Router(config-if)# no mls qos trust
Router(config-if)# end
Router# show queueing interface type1 slot/port| include Trust state
1. type = ethernet, fastethernet, gigabitethernet, tengigabitethernet, ge-wan, pos, or atm.
2. Not supported for serial, pos or atm interface types.
2
]
Selects the interface to configure.
Configures the trust state of the port.
Reverts to the default trust state (untrusted).
Exits configuration mode.
Verifies the configuration.
When configuring the trust state of a port, note the following information:
• With no other keywords, the mls qos trust command is equivalent to mls qos trust dscp.
42-90
• With Release 12.2(18)SXF5 and later releases, you can use the mls qos trust dscp command to
enable DSCP-based receive-queue drop thresholds on WS-X6708-10GE ports (see the “Configuring
DSCP-Based Queue Mapping” section on page 42-98). To avoid dropping traffic because of
inconsistent DSCP values when DSCP-based queue mapping is enabled, configure ports with the
mls qos trust dscp command only when the received traffic carries DSCP values that you know to
be consistent with network policy.
• The mls qos trust cos command enables CoS-based receive-queue drop thresholds. To avoid
dropping traffic because of inconsistent CoS values, configure ports with the mls qos trust cos
command only when the received traffic is ISL or 802.1Q frames carrying CoS values that you know
to be consistent with network policy.
• With Release 12.2(17b)SXA and later releases, you can configure IEEE 8021.Q tunnel ports
configured with the mls qos trust cos command to use a mutated CoS value instead of the received
CoS value (“Configuring Ingress CoS Mutation on IEEE 802.1Q Tunnel Ports” section on
page 42-83).
• Use the no mls qos trust command to set the port state to untrusted.
This example shows how to configure Gigabit Ethernet port 1/1 with the trust cos keywords:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 1/1
Router(config-if)# mls qos trust cos
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router# show queueing interface gigabitethernet 1/1 | include trust
Trust state: trust COS
Router#
Configuring PFC QoS
Configuring the Ingress LAN Port CoS Value
NoteWhether or not PFC QoS uses the CoS value applied with the mls qos cos command depends on the trust
state of the port and the trust state of the traffic received through the port. The mls qos cos command
does not configure the trust state of the port or the trust state of the traffic received through the port.
To use the CoS value applied with the mls qos cos command as the basis of internal DSCP:
• On a port that receives only untagged ingress traffic, configure the ingress port as trusted or
configure a trust CoS policy map that matches the ingress traffic.
• On a port that receives tagged ingress traffic, configure a trust CoS policy map that matches the
ingress traffic.
You can configure the CoS value that PFC QoS assigns to untagged frames from ingress LAN ports
configured as trusted and to all frames from ingress LAN ports configured as untrusted.
Router# show queuing interface {ethernet |
fastethernet | gigabitethernet} slot/port
1. type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet
Chapter 42 Configuring PFC QoS
To configure the CoS value for an ingress LAN port, perform this task:
Selects the interface to configure.
Configures the ingress LAN port CoS value.
Reverts to the default port CoS value.
Exits configuration mode.
Verifies the configuration.
This example shows how to configure the CoS value 5 on Fast Ethernet port 5/24 and verify the
configuration:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface fastethernet 5/24
Router(config-if)# mls qos cos 5
Router(config-if)# end
Router# show queueing interface fastethernet 5/24 | include Default COS
Default COS is 5
Router#
Configuring Standard-Queue Drop Threshold Percentages
These sections describe configuring standard-queue drop threshold percentages:
• Configuring a Tail-Drop Receive Queue, page 42-93
• Configuring a WRED-Drop Transmit Queue, page 42-94
• Configuring a WRED-Drop and Tail-Drop Receive Queue, page 42-94
• Configuring a WRED-Drop and Tail-Drop Transmit Queue, page 42-95
Router(config-if)# no rcv-queue threshold
[queue_id]
Router(config-if)# end
Router# show queueing interface {fastethernet |
gigabitethernet} slot/port
Selects the interface to configure.
Configures the receive-queue tail-drop threshold
percentages.
Reverts to the default receive-queue tail-drop threshold
percentages.
Exits configuration mode.
Verifies the configuration.
OL-4266-08
This example shows how to configure the receive-queue drop thresholds for Gigabit Ethernet port 1/1:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 1/1
Router(config-if)# rcv-queue threshold 1 60 75 85 100
Router(config-if)# end
Router#
Router(config-if)# no wrr-queue random-detect
[queue_id]
Router(config-if)# end
Router# show queueing interfacetype1 slot/port
1. type = fastethernet, gigabitethernet, or tengigabitethernet
Chapter 42 Configuring PFC QoS
Configures the high WRED-drop thresholds.
Reverts to the default high WRED-drop thresholds.
Enables WRED-drop thresholds.
Enables tail-drop thresholds.
Exits configuration mode.
Verifies the configuration.
This example shows how to configure the low-priority transmit queue high-WRED-drop thresholds for
Gigabit Ethernet port 1/1:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 1/1
Router(config-if)# wrr-queue random-detect max-threshold 1 70 70
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router# show queueing interface gigabitethernet 1/1 | begin Transmit queues
Transmit queues [type = 1p2q2t]:
Queue Id Scheduling Num of thresholds
Router(config-if)# no wrr-queue threshold
[queue_id]
Router(config-if)# end
Router# show queueing interface {ethernet |
fastethernet | gigabitethernet} slot/port
When configuring the receive- and transmit-queue tail-drop thresholds, note the following information:
• You must use the transmit queue and threshold numbers.
• The queue_id is 1 for the standard low-priority queue and 2 for the standard high-priority queue.
Configuring PFC QoS
Selects the interface to configure.
Configures the receive- and transmit-queue tail-drop
thresholds.
Reverts to the default receive- and transmit-queue
tail-drop thresholds.
Exits configuration mode.
Verifies the configuration.
• The percentages range from 1 to 100. A value of 10 indicates a threshold when the buffer is
10-percent full.
• Always set threshold 2 to 100 percent.
• Ethernet and Fast Ethernet 1q4t ports do not support receive-queue tail-drop thresholds.
This example shows how to configure receive queue 1/threshold 1 and transmit queue 1/threshold 1 for
Gigabit Ethernet port 2/1:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface gigabitethernet 2/1
Router(config-if)# wrr-queue threshold 1 60 100
Router(config-if)# end
Router#
This example shows how to verify the configuration:
Router(config-if)# no mls qos queue-mode mode-dscp
Router(config-if)# end
Router# show queueing interface tengigabitethernetslot/port| include Queueing Mode
This example shows how to enable DSCP-based queue mapping on 10-Gigabit Ethernet port 6/1:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface tengigabitethernet 6/1
Router(config-if)# mls qos queue-mode mode-dscp
Router(config-if)# end
Configuring PFC QoS
Selects the interface to configure.
Enables DSCP-based queue mapping.
Reverts to CoS-based queue mapping.
Exits configuration mode.
Verifies the configuration.
This example shows how to verify the configuration:
Router# show queueing interface tengigabitethernet 6/1 | include Queueing Mode
Queueing Mode In Tx direction: mode-dscp
Queueing Mode In Rx direction: mode-dscp
Configuring Ingress DSCP-Based Queue Mapping
Ingress DSCP-to-queue mapping is supported only on ports configured to trust DSCP.
These sections describe how to configure ingress DSCP-based queue mapping:
• Enabling DSCP-Based Queue Mapping, page 42-99
• Mapping DSCP Values to Standard Receive-Queue Thresholds, page 42-100
Configuring the Port to Trust DSCP
To configure the port to trust DSCP perform this task:
This example shows how to verify the configuration:
Router# show queueing interface gigabitethernet 6/1 | include Trust state
Trust state: trust DSCP
Mapping DSCP Values to Standard Receive-Queue Thresholds
To map DSCP values to the standard receive-queue thresholds, perform this task:
Selects the interface to configure.
Maps DSCP values to the standard receive queue
thresholds.
Reverts to the default mapping.
Exits configuration mode.
Verifies the configuration.
When mapping DSCP values, note the following information:
• You can enter up to 8 DSCP values that map to a queue and threshold.
• You can enter multiple commands to map additional DSCP values to the queue and threshold.
• You must enter a separate command for each queue and threshold.
This example shows how to map the DSCP values 0 and 1 to threshold 1 in the standard receive queue
for 10-Gigabit Ethernet port 6/1 port 6/1:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface tengigabitethernet 6/1
Router(config-if)# rcv-queue dscp-map 1 1 0 1
Router(config-if)# end
Router#