Table Of Contents

Configuring PFC QoS

Understanding How PFC QoS Works

Port Types Supported by PFC QoS

Overview

Component Overview

Ingress LAN Port PFC QoS Features

PFC and DFC QoS Features

PFC QoS Egress Port Features

Understanding Classification and Marking

Classification and Marking at Trusted and Untrusted Ingress Ports

Classification and Marking at Ingress OSM Ports

Classification and Marking on the PFC Using Service Policies and Policy Maps

Classification and Marking on the MSFC

Policers

Overview of Policers

Aggregate Policers

Microflow Policers

Understanding Port-Based Queue Types

Ingress and Egress Buffers and Layer 2 CoS-Based Queues

Ingress Queue Types

Egress Queue Types

Module to Queue Type Mappings

PFC QoS Default Configuration

PFC QoS Global Settings

Default Values With PFC QoS Enabled

Receive-Queue Limits

Transmit-Queue Limit s

Bandwidth Allocation Ratios

Default Drop-Threshold Percentages and CoS Value Mappings

Default Values With PFC QoS Disabled

PFC QoS Configuration Guidelines and Restrictions

General Guidelines

PFC3 Guidelines

PFC2 Guidelines

Class Map Command Restrictions

Policy Map Command Restrictions

Policy Map Class Command Restrictions

Supported Granularity for CIR and PIR Rate Values

Supported Granularity for CIR and PIR Token Bucket Sizes

IP Precedence and DSCP Values

Configuring PFC QoS

Enabling PFC QoS Globally

Enabling Ignore Port Trust

Configuring DSCP Transparency

Enabling Queueing-Only Mode

Enabling Microflow Policing of Bridged Traffic

Enabling VLAN-Based PFC QoS on Layer 2 LAN Ports

Enabling Egress ACL Support for Remarked DSCP

Creating Named Aggregate Policers

Configuring a PFC QoS Policy

PFC QoS Policy Configuration Overview

Configuring MAC ACLs

Configuring ARP ACLs for QoS Filtering

Configuring a Class Map

Verifying Class Map Configuration

Configuring a Policy Map

Verifying Policy Map Configuration

Attaching a Policy Map to an Interface

Configuring Egress DSCP Mutation on a PFC3

Configuring Named DSCP Mutation Maps

Attaching an Egress DSCP Mutation Map to an Interface

Configuring Ingress CoS Mutation on IEEE 802.1Q Tunnel Ports

Ingress CoS Mutation Configuration Guidelines and Restrictions

Configuring Ingress CoS Mutation Maps

Applying Ingress CoS Mutation Maps to IEEE 802.1Q Tunnel Ports

Configuring DSCP Value Maps

Mapping Received CoS Values to Internal DSCP Values

Mapping Received IP Precedence Values to Internal DSCP Values

Configuring DSCP Markdown Values

Mapping Internal DSCP Values to Egress CoS Values

Configuring the Trust State of Ethernet LAN and OSM Ports

Configuring the Ingress LAN Port CoS Value

Configuring Standard-Queue Drop Threshold Percentages

Configuring a Tail-Drop Receive Queue

Configuring a WRED-Drop Transmit Queue

Configuring a WRED-Drop and Tail-Drop Receive Queue

Configuring a WRED-Drop and Tail-Drop Transmit Queue

Configuring 1q4t/2q2t Tail-Drop Threshold Percentages

Mapping QoS Labels to Queues and Drop Thresholds

Queue and Drop Threshold Mapping Guidelines and Restrictions

Configuring DSCP-Based Queue Mapping

Configuring CoS-Based Queue Mapping

Allocating Bandwidth Between Standard Transmit Queues

Setting the Receive-Queue Size Ratio

Configuring the Transmit-Queue Size Ratio

Common QoS Scenarios

Sample Network Design Overview

Classifying Traffic from PCs and IP Phones in the Access Layer

Accepting the Traffic Priority Value on Interswitch Links

Prioritizing Traffic on Interswitch Links

Using Policers to Limit the Amount of Traffic from a PC

PFC QoS Glossary

Configuring PFC QoS

---

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 Catalyst 6500 series switches.

---

Note•For complete syntax and usage information for the commands used in this chapter, refer to the Cisco IOS Master Command List, Release 12.2SX at this URL:

•http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html For information about QoS and MPLS, see Chapter 42, "Configuring PFC3BXL or PFC3B Mode MPLS QoS."

•QoS on the Catalyst 6500 series switches (PFC QoS) uses some Cisco IOS modular QoS CLI (MQC). Because PFC QoS is implemented in hardware, it supports only a subset of the MQC syntax.

•The PFC3 does not support Network-Based Application Recognition (NBAR).

•With a Supervisor Engine 2, PFC2, and MSFC2, you can configure NBAR on Layer 3 interfaces instead of PFC QoS:

–The PFC2 provides hardware support for input ACLs on ports where you configure NBAR.

–When PFC QoS is enabled, the traffic through ports where you configure NBAR passes through the ingress and egress queues and drop thresholds.

–When PFC QoS is enabled, the MSFC2 sets egress CoS equal to egress IP precedence in NBAR traffic.

–After passing through an ingress queue, all traffic is processed in software on the MSFC2 on interfaces where you configure NBAR.

–To configure NBAR, refer to this publication:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/dtnbarad.htm

---

This chapter contains these sections:

•Understanding How PFC QoS Works

•PFC QoS Default Configuration

•PFC QoS Configuration Guidelines and Restrictions

•Configuring PFC QoS

•Common QoS Scenarios

•PFC QoS Glossary

Understanding How PFC QoS Works

The term "PFC QoS" refers to QoS on the Catalyst 6500 series switch. PFC QoS is implemented on various switch components in addition to the PFC and any DFCs. These sections describe how PFC QoS works:

•Port Types Supported by PFC QoS

•Overview

•Component Overview

•Understanding Classification and Marking

•Understanding Port-Based Queue Types

Port Types Supported by PFC QoS

The PFC does not provide QoS for FlexWAN module ports. Refer to this publication for information about FlexWAN module QoS features:

http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/cfgnotes/flexport/combo/index.htm

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:

http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/cfgnotes/osm_inst/index.htm

Overview

Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.

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).

---

Note Catalyst 6500 series switches 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, Catalyst 6500 series switches do not support MQC-configured queuing.

---

Figure 41-1 shows an overview of QoS processing in a Catalyst 6500 series switch.

Figure 41-1 PFC QoS Feature Processing Overview

The PFC QoS features are applied in this order:

1. Ingress port PFC QoS features:

–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

–Layer 2 CoS-based and Layer 3 DSCP-based congestion avoidance. (Layer 3 DSCP-based queue mapping is available only on WS-X6708-10GE ports.)

These figures provide more detail about the relationship between QoS and the switch components:

•Figure 41-2, Traffic Flow and PFC QoS Features with PFC3

•Figure 41-3, Traffic Flow and PFC QoS Features with PFC2

•Figure 41-4, PFC QoS Features and Component Overview

Figure 41-2 shows traffic flow and PFC QoS features with a PFC3.

Figure 41-2 Traffic Flow and PFC QoS Features with PFC3

Figure 41-2 shows how traffic flows through the PFC QoS features with PFC3:

•Traffic can enter on any type of port and exit on any type of port.

•DFCs implement PFC QoS locally on switching modules.

•For FlexWAN module traffic:

–Ingress FlexWAN QoS features can be applied to FlexWAN ingress traffic.

–Ingress FlexWAN traffic can be Layer 3-switched by the PFC3 or routed in software by the MSFC.

–Egress PFC QoS is not applied to FlexWAN ingress traffic.

–Egress FlexWAN QoS can be applied to FlexWAN egress traffic.

•For LAN-port traffic:

–Ingress LAN-port QoS features can be applied to LAN-port ingress traffic.

–Ingress PFC QoS can be applied to LAN-port ingress traffic.

–Ingress LAN-port traffic can be Layer-2 or Layer-3 switched by the PFC3 or routed in software by the MSFC.

–Egress PFC QoS and egress LAN-port QoS can be applied to LAN-port egress traffic.

•For OSM traffic:

–Ingress OSM-port QoS features can be applied to OSM-port ingress traffic.

–Ingress PFC3 QoS can be applied to OSM-port ingress traffic.

–Ingress OSM-port traffic can be Layer-3 switched by the PFC3 or routed in software by the MSFC.

–Egress PFC3 QoS and egress OSM-port QoS can be applied to OSM-port egress traffic.

Figure 41-3 shows traffic flow and PFC QoS features with a PFC2.

Figure 41-3 Traffic Flow and PFC QoS Features with PFC2

Figure 41-3 shows how traffic flows through the PFC QoS features with PFC2:

•Traffic can enter on any type of port and exit on any type of port.

•DFCs implement PFC QoS locally on switching modules.

•For FlexWAN module traffic:

–Ingress FlexWAN QoS features can be applied to FlexWAN ingress traffic.

–Ingress FlexWAN traffic can be Layer 3-switched by the PFC2 or routed in software by the MSFC2.

–Egress FlexWAN QoS can be applied to FlexWAN egress traffic.

•For LAN-port traffic:

–Ingress LAN-port QoS features can be applied to LAN-port ingress traffic.

–Ingress LAN-port traffic can be Layer-2 or Layer-3 switched by the PFC2 or routed in software by the MSFC2.

–Egress LAN-port QoS can be applied to LAN-port egress traffic.

•For OSM traffic:

–OSM-port QoS features can be applied to OSM-port ingress traffic.

–Ingress PFC2 QoS can be applied to OSM-port ingress traffic.

–OSM-port ingress traffic can be Layer-3 switched by the PFC2 or routed in software by the MSFC2.

–Egress OSM-port QoS can be applied to OSM-port egress traffic.

Figure 41-4 PFC QoS Features and Component Overview

Component Overview

These sections provide more detail about the role of the following components in PFC QoS decisions and processes:

•Ingress LAN Port PFC QoS Features

•PFC and DFC QoS Features

•PFC QoS Egress Port Features

Ingress LAN Port PFC QoS Features

These sections provide an overview of the ingress port QoS features:

•Flowchart of Ingress LAN Port PFC QoS Features

•Port Trust

•Ingress Congestion Avoidance

Flowchart of Ingress LAN Port PFC QoS Features

Figure 41-5 shows how traffic flows through the ingress LAN port PFC QoS features.

Figure 41-5 Ingress LAN Port PFC QoS Features

---

Note•Ingress CoS mutation is supported only on 802.1Q tunnel ports.

•Release 12.2(18)SXF5 and later releases support the ignore port trust feature.

•DSCP-based queue mapping is supported only on WS-X6708-10GE ports.

---

Port Trust

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.

---

Note Not 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 for more information about ingress congestion avoidance.

PFC and DFC QoS Features

These sections describe PFCs and DFCs as they relate to QoS:

•Supported Policy Feature Cards

•Supported Distributed Forwarding Cards

•PFC and DFC QoS Feature List and Flowchart

•Internal DSCP Values

Supported Policy Feature Cards

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 Catalyst 6500 series switches:

•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 Catalyst 6500 series switches:

•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.

•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 41-1 lists the QoS features supported on the different versions of PFCs and DFCs.

Table 41-1 QoS Features Supported on PFCs and DFCs

Feature	PFC2/DFC	PFC3A/DFC3A	PFC3B/DFC3B	PFC3BXL/DFC3BXL
Support for DFCs	Yes	Yes	Yes	Yes
Flow granularity	Full flow	Source Destination	Source Destination	Source Destination
QoS ACLs	IP, IPX, MAC	IP, MAC	IP, MAC	IP, MAC
DSCP transparency Note Enabling DSCP transparency disables egress ToS rewrite.	No	Optional	Optional	Optional
Egress ToS rewrite	Mandatory	Optional	Optional	Optional
Policing:
Ingress aggregate policers	Yes	Yes	Yes	Yes
Egress aggregate policers	No	Yes	Yes	Yes
Number of aggregate policers	1022	1022	1022	1022
Microflow policers	64 rates	64 rates	64 rates	64 rates
Number of flows per Microflow policer	32,000	64,000	110,000	240,000
Unit of measure for policer statistics	Packets	Bytes	Bytes	Bytes
Basis of policer operation	Layer 3 length	Layer 2 length	Layer 2 length	Layer 2 length

Figure 41-6 shows how traffic flows through the QoS features on the PFC and DFCs.

Figure 41-6 QoS Features on the PFC and DFCs

---

Note The DSCP transparency feature makes writing the egress DSCP value into the Layer 3 ToS byte optional.

---

Internal DSCP Values

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:

•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.

---

Note For 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.

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.

Port-Based PFC QoS and VLAN-Based PFC QoS

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

These sections describe PFC QoS egress port features:

•Flowchart of PFC QoS Egress LAN Port Features

•Egress CoS Values

•Egress DSCP Mutation with a PFC3

•Egress ToS Byte

•Egress PFC QoS Interfaces

•Egress ACL Support for Remarked DSCP

•Marking on Egress OSM Ports

Flowchart of PFC QoS Egress LAN Port Features

Figure 41-7 shows how traffic flows through the QoS features on egress LAN ports.

Figure 41-7 Egress LAN Port Scheduling, Congestion Avoidance, and Marking

Egress CoS Values

For all egress traffic, PFC QoS uses a configurable map to derive a CoS value from the final internal DSCP value associated with the traffic. PFC QoS sends the derived CoS value to the egress LAN ports for use in classification and congestion avoidance and to be written into ISL and 802.1Q frames.

---

Note With Release 12.2(18)SXF5 and later releases, you can configure WS-X6708-10GE ports to use the final internal DSCP value for egress LAN port classification and congestion avoidance (see the "Configuring DSCP-Based Queue Mapping" section).

---

Egress DSCP Mutation with a PFC3

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).

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

---

Note Egress 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.

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.

---

Caution If the switch 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.

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 41-8).

Figure 41-8 Egress OSM Port Marking

Understanding Classification and Marking

The following sections describe where and how classification and marking occur on the Catalyst 6500 series switches:

•Classification and Marking at Trusted and Untrusted Ingress Ports

•Classification and Marking at Ingress OSM Ports

•Classification and Marking on the PFC Using Service Policies and Policy Maps

•Classification and Marking on the MSFC

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

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)

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

•Ingress Classification and Marking at Trusted Ports

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 switch, you can apply a different trust state to traffic with a policy map. For example, traffic can enter the switch 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

•Ingress Classification and Marking at Trust IP Precedence Ports

•Ingress Classification and Marking at Trust DSCP Ports

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 switch 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 switch 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 for more information about ingress queues and thresholds.

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).

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:

•Untrusted (default)

•Trust IP precedence

•Trust DSCP

•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 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.

---

Note A 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 conforming and nonconforming traffic.

Classification and Marking on the MSFC

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 41-9 Marking with PFC2 or PFC3 and MSFC2, MSFC2A, or MSFC3

---

Note Traffic that is Layer 3 switched on the PFC does not go through the MSFC and retains the CoS value assigned by the PFC.

---

Policers

These sections describe policers:

•Overview of Policers

•Aggregate Policers

•Microflow Policers

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:

http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/cfgnotes/index.htm

---

Note Policers 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:

•Mark traffic

•Limit bandwidth utilization and mark traffic

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.

•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.

Microflow Policers

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:

•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.

---

Note 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.

---

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.

---

Note To avoid inconsistent results, ensure that all traffic policed by the same aggregate policer has the same trust state.

---

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.

•