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/en/US/docs/ios/12_4t/qos/configuration/guide/qsnbar1.html

---

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/en/US/docs/routers/7600/install_config/flexwan_config/flexwan-config-guide.html

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/en/US/docs/routers/7600/install_config/12.2SX_OSM_config/OSMConfigurationNote12.2SX.html

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. When ignore port trust is disabled, PFC QoS uses 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 these FlexWAN and OSM documents:

http://www.cisco.com/en/US/docs/routers/7600/install_config/flexwan_config/flexqos.html#wp1124151

http://www.cisco.com/en/US/docs/routers/7600/install_config/12.2SX_OSM_config/qos.html#Configuring_Class-Based_Traffic_Shaping

http://www.cisco.com/en/US/docs/routers/7600/install_config/12.2SX_OSM_config/qos.html#Configuring_Hierarchical_Traffic_Shaping

---

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.

•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 Catalyst 6500 series switch LAN modules:

•Ingress and Egress Buffers and Layer 2 CoS-Based Queues

•Ingress Queue Types

•Egress Queue Types

•Module to Queue Type Mappings

Ingress and Egress Buffers and Layer 2 CoS-Based Queues

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 Catalyst 6500 series switch LAN modules support the following types of queues:

•Standard queues

•Strict-priority queues

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

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

---

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

---

The combination of multiple queues and the scheduling algorithms associated with each queue allows the switch to provide congestion avoidance.

Figure 41-10 illustrates the drop thresholds for a 1q4t ingress LAN port. Drop thresholds in other configurations function similarly.

Figure 41-10 Receive Queue Drop Thresholds

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.

•1p1q4t indicates:

–One strict-priority queue

–One standard queue with four configurable tail-drop thresholds.

•1p1q0t indicates:

–One strict-priority queue

–One standard queue with no configurable threshold (effectively a tail-drop threshold at 100 percent).

•1p1q8t indicates the following:

–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

Egress Queue Types

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.

•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

—One nonconfigurable (100 percent) tail-drop threshold

•1p2q1t indicates the following:

–One strict-priority queue

–Two standard queues with these thresholds:

—One WRED-drop threshold

—One non-configurable (100 percent) tail-drop threshold

•1p3q8t indicates the following:

–One strict-priority queue

–Three standard queues, each with eight thresholds, each threshold configurable as either WRED-drop or tail-drop

•1p7q4t indicates the following:

–One strict-priority queue

–Seven standard queues, each with four thresholds, each threshold configurable as either WRED-drop or tail-drop

•1p7q8t indicates the following:

–One strict-priority queue

–Seven standard queues, each with eight thresholds, each threshold configurable as either WRED-drop or tail-drop

Module to Queue Type Mappings

The following tables show the module to queue structure mapping:

•Supervisor Engine Module QoS Queue Structures

•Ethernet and Fast Ethernet Module Queue Structures

•Gigabit and 10/100/1000 Ethernet Modules

•10 Gigabit Ethernet Modules

Table 41-2 Supervisor Engine Module QoS Queue Structures

Supervisor Engines	Ingress Queue and Drop Thresholds	Ingress Queue Scheduler	Egress Queue and Drop Thresholds	Egress Queue Scheduler	Total Buffer Size	Ingress Buffer Size	Egress Buffer Size
WS-SUP720	1p1q4t	—	1p2q2t	WRR	512 KB	73 KB	439 KB
WS-SUP720-3B
WS-SUP720-3BXL
WS-SUP32-10GE	2q8t	WRR	1p3q8t	DWRR SRR
10 Gigabit Ethernet ports					193 MB	105 MB	88 MB
Gigabit Ethernet port					17.7 MB	9.6 MB	8.1 MB
WS-SUP32-GE					17.7 MB	9.6 MB	8.1 MB
WS-X6K-S2U-MSFC2	1p1q4t	—	1p2q2t	WRR	512 KB	73 KB	439 KB
WS-X6K-S2-MSFC2
WS-X6K-S2-PFC2

Table 41-3 Ethernet and Fast Ethernet Module Queue Structures 

Modules	Ingress Queue and Drop Thresholds	Ingress Queue Scheduler	Egress Queue and Drop Thresholds	Egress Queue Scheduler	Total Buffer Size	Ingress Buffer Size	Egress Buffer Size
WS-X6524-100FX-MM	1p1q0t	—	1p3q1t	DWRR	1,116 KB	28 KB	1,088 KB
WS-X6548-RJ-21
WS-X6548-RJ-45
WS-X6324-100FX-MM	1q4t	—	2q2t	WRR	128 KB	16 KB	112 KB
WS-X6324-100FX-SM
WS-X6348-RJ-45
WS-X6348-RJ-45V
WS-X6348-RJ-21V
WS-X6224-100FX-MT					64 KB	8 KB	56 KB
WS-X6248-RJ-45
WS-X6248-TEL
WS-X6248A-TEL					128 KB	16 KB	112 KB
WS-X6148-RJ-45
WS-X6148-RJ-45V
WS-X6148-45AF
WS-X6148-RJ-21
WS-X6148-RJ-21V
WS-X6148-21AF
WS-X6148A-RJ45	1p1q4t	—	1p3q8t	DWRR	5.3 MB	60KB	5.3 MB
WS-X6148A-45AF
WS-X6148X2-RJ-45	1p1q0t	—	1p3q1t	DWRR	1,116 KB	28 KB	1,088 KB
WS-X6148X2-45AF
WS-X6196-RJ-21
WS-X6196-21AF
WS-X6024-10FL-MT	1q4t	—	2q2t	WRR	64 KB	8 KB	56 KB

Table 41-4 Gigabit and 10/100/1000 Ethernet Modules

Modules	Ingress Queue and Drop Thresholds	Ingress Queue Scheduler	Egress Queue and Drop Thresholds	Egress Queue Scheduler	Total Buffer Size	Ingress Buffer Size	Egress Buffer Size
WS-X6816-GBIC	1p1q4t	—	1p2q2t	WRR	512 KB	73 KB	439 KB
WS-X6748-GE-TX with DFC3	2q8t	WRR	1p3q8t	DWRR	1.3 MB	166 KB	1.2 MB
WS-X6748-GE-TX with CFC	1q8t	—
WS-X6748-SFP with DFC3	2q8t	WRR
WS-X6748-SFP with CFC	1q8t	—
WS-X6724-SFP with DFC3	2q8t	WRR
WS-X6724-SFP with CFC	1q8t	—
WS-X6548-GE-TX	1q2t	—	1p2q2t	WRR	1.4 MB	185 KB	1.2 MB
WS-X6548V-GE-TX
WS-X6548-GE-45AF
WS-X6516-GBIC	1p1q4t	—	1p2q2t	WRR	512 KB	73 KB	439 KB
WS-X6516A-GBIC				WRR	1 MB	135 KB	946 KB
WS-X6516-GE-TX				WRR	512 KB	73 KB	439 KB
WS-X6408-GBIC	1q4t	—	2q2t	WRR		80 KB	432 KB
WS-X6408A-GBIC	1p1q4t	—	1p2q2t	WRR		73 KB	439 KB
WS-X6416-GBIC
WS-X6416-GE-MT
WS-X6316-GE-TX
WS-X6148-GE-TX	1q2t	—			1.4 MB	185 KB	1.2 MB
WS-X6148V-GE-TX
WS-X6148-GE-45AF
WS-X6148A-GE-TX			1p3q8t	DWRR	5.5 MB	120 KB	5.4 MB
WS-X6148A-GE-45AF

Table 41-5 10 Gigabit Ethernet Modules

Modules	Ingress Queue and Drop Thresholds	Ingress Queue Scheduler	Egress Queue and Drop Thresholds	Egress Queue Scheduler	Total Buffer Size	Ingress Buffer Size	Egress Buffer Size
WS-X6708-10GE	8q4t	DWRR	1p7q4t	DWRR SRR	200 MB	108 MB	90 MB
WS-X6704-10GE with DFC3	8q8t	WRR	1p7q8t	DWRR	16 MB	2 MB	14 MB
WS-X6704-10GE with CFC	1q8t	—
WS-X6502-10GE	1p1q8t	—	1p2q1t	DWRR	64.2 MB	256 KB	64 MB
WS-X6501-10GEX4

PFC QoS Default Configuration

These sections describe the PFC QoS default configuration:

•PFC QoS Global Settings

•Default Values With PFC QoS Enabled

•Default Values With PFC QoS Disabled

PFC QoS Global Settings

The following global PFC QoS settings apply:

Feature	Default Value
PFC QoS global enable state	Disabled
PFC QoS port enable state	Enabled when PFC QoS is globally enabled
Port CoS value	0
Microflow policing	Enabled
IntraVLAN microflow policing	Disabled
Port-based or VLAN-based PFC QoS	Port-based
Received CoS to initial internal DSCP map (initial internal DSCP set from received CoS values)	CoS 0 = DSCP  0 CoS 1 = DSCP  8 CoS 2 = DSCP 16 CoS 3 = DSCP 24 CoS 4 = DSCP 32 CoS 5 = DSCP 40 CoS 6 = DSCP 48 CoS 7 = DSCP 56
Received IP precedence to initial internal DSCP map (initial internal DSCP set from received IP precedence values)	IP precedence 0 = DSCP  0 IP precedence 1 = DSCP  8 IP precedence 2 = DSCP 16 IP precedence 3 = DSCP 24 IP precedence 4 = DSCP 32 IP precedence 5 = DSCP 40 IP precedence 6 = DSCP 48 IP precedence 7 = DSCP 56
Final internal DSCP to egress CoS map (egress CoS set from final internal DSCP values)	DSCP  0-7  = CoS 0 DSCP  8-15 = CoS 1 DSCP 16-23 = CoS 2 DSCP 24-31 = CoS 3 DSCP 32-39 = CoS 4 DSCP 40-47 = CoS 5 DSCP 48-55 = CoS 6 DSCP 56-63 = CoS 7
Marked-down DSCP from DSCP map	Marked-down DSCP value equals original DSCP value (no markdown)
Policers	None
Policy maps	None
Protocol-independent MAC ACL filtering	Disabled
VLAN-based MAC ACL QoS filtering	Disabled

Default Values With PFC QoS Enabled

These sections list the default values that apply when PFC QoS is enabled:

•Receive-Queue Limits

•Transmit-Queue Limit s

•Bandwidth Allocation Ratios

•Default Drop-Threshold Percentages and CoS Value Mappings

---

Note The ingress LAN port trust state defaults to untrusted with QoS enabled.

---

Receive-Queue Limits

Feature	Default Value
2q8t	Low priority: 80%
	High priority: 20%
8q4t	Low priority: 80%
	Intermediate queues: 0%
	High priority: 20%
8q8t	Lowest priority: 80%
	Intermediate queues: 0%
	Highest priority: 20%

Transmit-Queue Limit s

Feature	Default Value
2q2t	Low priority: 80%
	High priority: 20%
1p2q2t	Low priority: 70%
	High priority: 15%
	Strict priority 15%
1p2q1t	Low priority: 70%
	High priority: 15%
	Strict priority 15%
1p3q8t	Low priority: 50%
	Medium priority: 20%
	High priority: 15%
	Strict priority 15%
1p7q4t	Standard queue 1 (lowest priority): 50%
	Standard queue 2: 20%
	Standard queue 3: 15%
	Standard queues 4 through 7: 0%
	Strict priority 15%
1p7q8t	Standard queue 1 (lowest priority): 50%
	Standard queue 2: 20%
	Standard queue 3: 15%
	Standard queues 4 through 7: 0%
	Strict priority 15%

Bandwidth Allocation Ratios

Feature	Default Value
2q8t	90:10
8q4t	90:0:0:0:0:0:0:10
8q8t	90:0:0:0:0:0:0:10
1p3q8t	100:150:200
1p7q4t	100:150:200:0:0:0:0:0
1p7q8t	100:150:200:0:0:0:0
1p2q1t	100:255
2q2t, 1p2q2t, and 1p2q1t	5:255
1p3q1t	100:150:255

Default Drop-Threshold Percentages and CoS Value Mappings

The following tables list the default drop-thresholds values and CoS mappings for different queue types:

•1q2t Receive Queues

•1q4t Receive Queues

•1p1q4t Receive Queues

•1p1q0t Receive Queues

•1p1q8t Receive Queues

•1q8t Receive Queues

•2q8t Receive Queues

•8q4t Receive Queues

•8q8t Receive Queues

•2q2t Transmit Queues

•1p2q2t Transmit Queues

•1p3q8t Transmit Queues

•1p7q4t Transmit Queues

•1p7q8t Transmit Queues

•1p3q1t Transmit Queues

•1p2q1t Transmit Queues

---

Note The receive queue values shown are the values in effect when the port is configured to trust CoS or DSCP. When the port is untrusted, the receive queue values are the same as when QoS is globally disabled.

---

1q2t Receive Queues

Feature			Default Value
Standard receive queue	Threshold 1	CoS	0, 1, 2, 3, and 4
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 2	CoS	5, 6, and 7
		Tail-drop	100% (not configurable)
		WRED-drop	Not supported

1q4t Receive Queues

Feature			Default Value
Standard receive queue	Threshold 1	CoS	0 and 1
		Tail-drop	50%
		WRED-drop	Not supported
	Threshold 2	CoS	2 and 3
		Tail-drop	60%
		WRED-drop	Not supported
	Threshold 3	CoS	4 and 5
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 4	CoS	6 and 7
		Tail-drop	100%
		WRED-drop	Not supported

1p1q4t Receive Queues

Feature			Default Value
Standard receive queue	Threshold 1	CoS	0 and 1
		Tail-drop	50%
		WRED-drop	Not supported
	Threshold 2	CoS	2 and 3
		Tail-drop	60%
		WRED-drop	Not supported
	Threshold 3	CoS	4
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 4	CoS	6 and 7
		Tail-drop	100%
		WRED-drop	Not supported
Strict-priority receive queue		CoS	5
		Tail-drop	100% (nonconfigurable)

1p1q0t Receive Queues

Feature		Default Value
Standard receive queue	CoS	0, 1, 2, 3, 4, 6, and 7
	Tail-drop	100% (nonconfigurable)
	WRED-drop	Not supported
Strict-priority receive queue	CoS	5
	Tail-drop	100% (nonconfigurable)

1p1q8t Receive Queues

Feature			Default Value
Standard receive queue	Threshold 1	CoS	0
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	1
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 3	CoS	2
		Tail-drop	Disabled; 80%
		WRED-drop	Enabled; 50% low, 80% high
	Threshold 4	CoS	3
		Tail-drop	Disabled; 80%
		WRED-drop	Enabled; 50% low, 80% high
	Threshold 5	CoS	4
		Tail-drop	Disabled; 90%
		WRED-drop	Enabled; 60% low, 90% high
	Threshold 6	CoS	6
		Tail-drop	Disabled; 90%
		WRED-drop	Enabled; 60% low, 90% high
	Threshold 7	CoS	7
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled;70% low, 100% high
Strict-priority receive queue		CoS	5
		Tail-drop	100% (nonconfigurable)

1q8t Receive Queues

Feature			Default Value
Standard receive queue	Threshold 1	CoS	0
		Tail-drop	50%
		WRED-drop	Not supported
	Threshold 2	CoS	None
		Tail-drop	50%
		WRED-drop	Not supported
	Threshold 3	CoS	1, 2, 3, 4
		Tail-drop	60%
		WRED-drop	Not supported
	Threshold 4	CoS	None
		Tail-drop	60%
		WRED-drop	Not supported
	Threshold 5	CoS	6 and 7
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 6	CoS	None
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 7	CoS	5
		Tail-drop	100%
		WRED-drop	Not supported
	Threshold 8	CoS	None
		Tail-drop	100%
		WRED-drop	Not supported

2q8t Receive Queues

Feature			Default Value
Standard receive queue 1 (low priority)	Threshold 1	CoS	0 and 1
		Tail-drop	70%
		WRED-drop	Not supported
	Threshold 2	CoS	2 and 3
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 3	CoS	4
		Tail-drop	90%
		WRED-drop	Not supported
	Threshold 4	CoS	6 and 7
		Tail-drop	100%
		WRED-drop	Not supported
	Thresholds 5-8	CoS	None
		Tail-drop	100%
		WRED-drop	Not supported
Standard receive queue 2 (high priority)	Threshold 1	CoS	5
		Tail-drop	100%
		WRED-drop	Not supported
	Thresholds 2-8	CoS	None
		Tail-drop	100%
		WRED-drop	Not supported

8q4t Receive Queues

Feature			Default Value
Standard receive queue 1 (lowest priority)	Threshold 1	CoS	0 and 1
		DSCP	0-9, 11, 13, 15-17, 19, 21, 23, 25, 27, 29, 31, 33, 39, 41-45, 47
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	2 and 3
		DSCP
		Tail-drop	Disabled; 80%
		WRED-drop	Enabled; 40% low, 80% high
	Threshold 3	CoS	4
		DSCP
		Tail-drop	Disabled; 90%
		WRED-drop	Enabled; 50% low, 90% high
	Threshold 4	CoS	6 and 7
		DSCP
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 50% low, 100% high
Standard receive queue 2 (intermediate priority)	Threshold 1	CoS	None
		DSCP	14
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	12
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	10
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 3 (intermediate priority)	Threshold 1	CoS	None
		DSCP	22
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	20
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	18
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 4 (intermediate priority)	Threshold 1	CoS	None
		DSCP	24 and 30
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	28
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	26
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 5 (intermediate priority)	Threshold 1	CoS	None
		DSCP	32, 34-38
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 6 (intermediate priority)	Threshold 1	CoS	None
		DSCP	48-63
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 7 (intermediate priority)	Threshold 1	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 8 (high priority)	Threshold 1	CoS	5
		DSCP	40 and 46
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high

8q8t Receive Queues

Feature			Default Value
Standard receive queue 1 (lowest priority)	Threshold 1	CoS	0 and 1
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	2 and 3
		Tail-drop	Disabled; 80%
		WRED-drop	Enabled; 40% low, 80% high
	Threshold 3	CoS	4
		Tail-drop	Disabled; 90%
		WRED-drop	Enabled; 50% low, 90% high
	Threshold 4	CoS	6 and 7
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 50% low, 100% high
	Thresholds 5-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 50% low, 100% high
Standard receive queues 2-7 (intermediate priorities)	Thresholds 1-8	CoS	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard receive queue 8 (highest priority)	Threshold 1	CoS	5
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Thresholds 2-8	CoS	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high

2q2t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (low priority)	Threshold 1	CoS	0 and 1
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 2	CoS	2 and 3
		Tail-drop	100%
		WRED-drop	Not supported
Standard transmit queue 2 (high priority)	Threshold 1	CoS	4 and 5
		Tail-drop	80%
		WRED-drop	Not supported
	Threshold 2	CoS	6 and 7
		Tail-drop	100%
		WRED-drop	Not supported

1p2q2t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (low priority)	Threshold 1	CoS	0 and 1
		Tail-drop	Not supported
		WRED-drop	40% low, 70% high
	Threshold 2	CoS	2 and 3
		Tail-drop	Not supported
		WRED-drop	70% low, 100% high
Standard transmit queue 2 (high priority)	Threshold 1	CoS	4 and 6
		Tail-drop	Not supported
		WRED-drop	40% low, 70% high
	Threshold 2	CoS	7
		Tail-drop	Not supported
		WRED-drop	70% low, 100% high
Strict-priority transmit queue		CoS	5
		Tail-drop	100% (nonconfigurable)

1p3q8t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (lowest priority)	Threshold 1	CoS	0
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	1
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 3	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 4	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Thresholds 5-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 50% low, 100% high
Standard transmit queue 2 (medium priority)	Threshold 1	CoS	2
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	3 and 4
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Thresholds 3-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 3 (high priority)	Threshold 1	CoS	6 and 7
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Thresholds 2-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Strict-priority transmit queue		CoS	5
		Tail-drop	100% (nonconfigurable)

1p7q4t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (lowest priority)	Threshold 1	CoS	0 and 1
		DSCP	0-9, 11, 13, 15-17, 19, 21, 23, 25, 27, 29, 31, 33, 39, 41-45, 47
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	2 and 3
		DSCP
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 3	CoS	4
		DSCP
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 4	CoS	6 and 7
		DSCP
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 2 (intermediate priority)	Threshold 1	CoS	None
		DSCP	14
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	None
		DSCP	12
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 3	CoS	None
		DSCP	10
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 3 (intermediate priority)	Threshold 1	CoS	None
		DSCP	22
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 2	CoS	None
		DSCP	20
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 3	CoS	None
		DSCP	18
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 4 (intermediate priority)	Threshold 1	CoS	None
		DSCP	24 and 30
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	28
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	26
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard transmit queue 5 (intermediate priority)	Threshold 1	CoS	None
		DSCP	32, 34-38
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard transmit queue 6 (intermediate priority)	Threshold 1	CoS	None
		DSCP	48-63
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Standard transmit queue 7 (intermediate priority)	Threshold 1	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 2	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 3	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
	Threshold 4	CoS	None
		DSCP	None
		Tail-drop	Enabled; 100%
		WRED-drop	Disabled; 100% low, 100% high
Strict-priority transmit queue		CoS	5
		DSCP	40 and 46
		Tail-drop	100% (nonconfigurable)

1p7q8t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (lowest priority)	Threshold 1	CoS	0
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	1
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Thresholds 3-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 2 (intermediate priority)	Threshold 1	CoS	2
		Tail-drop	Disabled; 70%
		WRED-drop	Enabled; 40% low, 70% high
	Threshold 2	CoS	3 and 4
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Thresholds 3-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 3 (intermediate priority)	Threshold 1	CoS	6 and 7
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
	Thresholds 2-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 100% low, 100% high
Standard transmit queues 4-7 (intermediate priorities)	Thresholds 1-8	CoS	None
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 100% low, 100% high
Strict-priority transmit queue		CoS	5
		Tail-drop	100% (nonconfigurable)

1p3q1t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (lowest priority)	Threshold 1	CoS	0 and 1
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 2 (medium priority)	Threshold 1	CoS	2, 3, and 4
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 3 (high priority)	Threshold 1	CoS	6 and 7
		Tail-drop	Disabled; 100%
		WRED-drop	Enabled; 70% low, 100% high
Strict-priority transmit queue		CoS	5
		Tail-drop	100% (nonconfigurable)

1p2q1t Transmit Queues

Feature			Default Value
Standard transmit queue 1 (lowest priority)	Threshold 1	CoS	0, 1, 2, and 3
		Tail-drop	Not supported
		WRED-drop	Enabled; 70% low, 100% high
Standard transmit queue 3 (high priority)	Threshold 1	CoS	4, 6, and 7
		Tail-drop	Not supported
		WRED-drop	Enabled; 70% low, 100% high
Strict-priority transmit queue		CoS	5
		Tail-drop	100% (nonconfigurable)

Default Values With PFC QoS Disabled

Feature	Default Value
Ingress LAN port trust state	trust DSCP.
Receive-queue drop-threshold percentages	All thresholds set to 100%.
Transmit-queue drop-threshold percentages	All thresholds set to 100%.
Transmit-queue bandwidth allocation ratio	255:1.
Transmit-queue size ratio	Low priority: 100% (other queues not used).
CoS value and drop threshold mapping	All QoS labels mapped to the low-priority queue.

PFC QoS Configuration Guidelines and Restrictions

When configuring PFC QoS, follow these 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

General Guidelines

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

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

•For these commands, PFC QoS applies identical configuration to all LAN ports controlled by the same application-specific integrated circuit (ASIC):

–rcv-queue random-detect

–rcv-queue queue-limit

–wrr-queue queue-limit

–wrr-queue bandwidth (except Gigabit Ethernet LAN ports)

–priority-queue cos-map

–rcv-queue cos-map

–wrr-queue cos-map

–wrr-queue threshold

–rcv-queue threshold

–wrr-queue random-detect

–wrr-queue random-detect min-threshold

–wrr-queue random-detect max-threshold

•Configure these commands only on physical ports. Do not configure these commands on logical interfaces:

–priority-queue cos-map

–wrr-queue cos-map

–wrr-queue random-detect

–wrr-queue random-detect max-threshold

–wrr-queue random-detect min-threshold

–wrr-queue threshold

–wrr-queue queue-limit

–wrr-queue bandwidth

–rcv-queue cos-map

–rcv-queue bandwidth

–rcv-queue random-detect

–rcv-queue random-detect max-threshold

–rcv-queue random-detect min-threshold

–rcv-queue queue-limit

–rcv-queue cos-map

–rcv-queue threshold

---

Note IP multicast switching using egress packet replication is not compatible with QoS. In some cases, egress replication can result in the incorrect COS or DSCP marking of packets. If you are using QoS and your switching modules are capable of egress replication, enter the mls ip multicast replication-mode ingress command to force ingress replication.

---

PFC3 Guidelines

•With Release 12.2(18)SXE and later releases, all versions of the PFC3 support QoS for IPv6 unicast and multicast traffic.

•To display information about IPv6 PFC QoS, enter the show mls qos ipv6 command.

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

–Network Address Translation (NAT)

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

•With a PFC3, PFC QoS does not rewrite the ToS byte in bridged multicast traffic.

•The PFC3 supports up to 1022 aggregate policers, but some PFC QoS commands other than the police command will be included in this count. By default, any policy using a set or trust command will be included in the aggregate policer count. You can disable the addition of the set or trust commands to the aggregate policer count by entering the no mls qos marking statistics command, but you will then be unable to collect statistics for the classmaps associated with these commands. You can view the aggregate policer count in the QoS Policer Resources section of the output of the show platform hardware capacity qos command.

PFC2 Guidelines

•The PFC2 supports 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:

http://www.cisco.com/en/US/docs/ios/12_4t/qos/configuration/guide/qsnbar1.html

•The PFC2 does not support these PFC QoS features:

–Egress policing

–Egress DSCP mutation

–DSCP Transparency

–VLAN-based QoS with DFCs installed

•The PFC2 does not support the modules that support ingress CoS mutation on IEEE 802.1Q tunnel ports.

Class Map Command Restrictions

•With Release 12.2(18)SXE and later releases, PFC QoS supports the match any class map command.

•PFC QoS supports class maps that contain a single match command.

•PFC QoS does not support these class map commands:

–match cos

–match classmap

–match destination-address

–match input-interface

–match qos-group

–match source-address

Policy Map Command Restrictions

PFC QoS does not support these policy map commands:

•class class_name destination-address

•class class_name input-interface

•class class_name protocol

•class class_name qos-group

•class class_name source-address

Policy Map Class Command Restrictions

PFC QoS does not support these policy map class commands:

•bandwidth

•priority

•queue-limit

•random-detect

•set qos-group

•service-policy

Supported Granularity for CIR and PIR Rate Values

PFC QoS has the following hardware granularity for CIR and PIR rate values:

CIR and PIR Rate Value Range	Granularity
32768 to 2097152 (2 Mbs)	32768 (32 Kb)
2097153 to 4194304 (4 Mbs)	65536 (64 Kb)
4194305 to 8388608 (8 Mbs)	131072 (128 Kb)
8388609 to 16777216 (16 Mbs)	262144 (256 Kb)
16777217 to 33554432 (32 Mbs)	524288 (512 Kb)
33554433 to 67108864 (64 Mbs)	1048576 (1 Mb)
67108865 to 134217728 (128 Mbs)	2097152 (2 Mb)
134217729 to 268435456 (256 Mbs)	4194304 (4 Mb)
268435457 to 536870912 (512 Mbs)	8388608 (8 Mb)
536870913 to 1073741824 (1 Gps)	16777216 (16 Mb)
1073741825 to 2147483648 (2 Gps)	33554432 (32 Mb)
2147483649 to 4294967296 (4 Gps)	67108864 (64 Mb)
4294967296 to 8589934592 (8 Gps)	134217728 (128 Mb)
8589934592 to 10000000000 (10 Gps)	268435456 (256 Mb)

Within each range, PFC QoS programs the PFC with rate values that are multiples of the granularity values.

Supported Granularity for CIR and PIR Token Bucket Sizes

PFC QoS has the following hardware granularity for CIR and PIR token bucket (burst) sizes:

CIR and PIR Token Bucket Size Range	Granularity
1 to 32768 (32 KB)	1024 (1 KB)
32769 to 65536 (64 KB)	2048 (2 KB)
65537 to 131072 (128 KB)	4096 (4 KB)
131073 to 262144 (256 KB)	8196 (8 KB)
262145 to 524288 (512 KB)	16392 (16 KB)
524289 to 1048576 (1 MB)	32768 (32 KB)
1048577 to 2097152 (2 MB)	65536 (64 KB)
2097153 to 4194304 (4 MB)	131072 (128 KB)
4194305 to 8388608 (8 MB)	262144 (256 KB)
8388609 to 16777216 (16 MB)	524288 (512 KB)
16777217 to 33554432 (32 MB)	1048576 (1 MB)

Within each range, PFC QoS programs the PFC with token bucket sizes that are multiples of the granularity values.

IP Precedence and DSCP Values

3-bit IP Precedence	6 MSb1 of ToS							6-bit DSCP		3-bit IP Precedence	6 MSb1 of ToS							6-bit DSCP
	8	7	6		5	4	3				8	7	6		5	4	3
0	0 0 0 0 0 0 0 0	0 0 0 0 0 0 0 0	0 0 0 0 0 0 0 0		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	0  1  2  3  4  5  6  7		4	1 1 1 1 1 1 1 1	0 0 0 0 0 0 0 0	0 0 0 0 0 0 0 0		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	32 33 34 35 36 37 38 39
1	0 0 0 0 0 0 0 0	0 0 0 0 0 0 0 0	1 1 1 1 1 1 1 1		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	8  9 10 11 12 13 14 15		5	1 1 1 1 1 1 1 1	0 0 0 0 0 0 0 0	1 1 1 1 1 1 1 1		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	40 41 42 43 44 45 46 47
2	0 0 0 0 0 0 0 0	1 1 1 1 1 1 1 1	0 0 0 0 0 0 0 0		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	16 17 18 19 20 21 22 23		6	1 1 1 1 1 1 1 1	1 1 1 1 1 1 1 1	0 0 0 0 0 0 0 0		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	48 49 50 51 52 53 54 55
3	0 0 0 0 0 0 0 0	1 1 1 1 1 1 1 1	1 1 1 1 1 1 1 1		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	24 25 26 27 28 29 30 31		7	1 1 1 1 1 1 1 1	1 1 1 1 1 1 1 1	1 1 1 1 1 1 1 1		0 0 0 0 1 1 1 1	0 0 1 1 0 0 1 1	0 1 0 1 0 1 0 1	56 57 58 59 60 61 62 63

1 MSb = most significant bit

Configuring PFC QoS

These sections describe how to configure PFC QoS on the Catalyst 6500 series switches:

•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

•Configuring Egress DSCP Mutation on a PFC3

•Configuring Ingress CoS Mutation on IEEE 802.1Q Tunnel Ports

•Configuring DSCP Value Maps

•Configuring the Trust State of Ethernet LAN and OSM Ports

•Configuring the Ingress LAN Port CoS Value

•Configuring Standard-Queue Drop Threshold Percentages

•Mapping QoS Labels to Queues and Drop Thresholds

•Allocating Bandwidth Between Standard Transmit Queues

•Setting the Receive-Queue Size Ratio

•Configuring the Transmit-Queue Size Ratio

---

Note PFC QoS processes both unicast and multicast traffic.

---

Enabling PFC QoS Globally

To enable PFC QoS globally, perform this task:

	Command	Purpose
Step 1	Router(config)# mls qos	Enables PFC QoS globally on the switch.
	Router(config)# no mls qos	Disables PFC QoS globally on the switch.
Step 2	Router(config)# end	Exits configuration mode.
Step 3	Router# show mls qos [ipv6]	Verifies the configuration.

This example shows how to enable PFC QoS globally:

Router# configure terminal 

Router(config)# mls qos 

Router(config)# end 

Router#

This example shows how to verify the configuration:

Router# show mls qos 

  QoS is enabled globally

  Microflow QoS is enabled globally

QoS global counters:

    Total packets: 544393

    IP shortcut packets: 1410

    Packets dropped by policing: 0

    IP packets with TOS changed by policing: 467

    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:

	Command	Purpose
Step 1	Router(config)# mls qos marking ignore port-trust	Enables ignore port trust globally on the switch.
	Router(config)# no mls qos marking ignore port-trust	Disables ignore port trust globally on the switch (default).
Step 2	Router(config)# end	Exits configuration mode.
Step 3	Router# show mls qos | include ignores	Verifies the configuration.

---

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

---

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 

  Policy marking ignores port_trust 

Router# 

Configuring DSCP Transparency

---

Note•In addition to support for other IP traffic, the PFC3B and PFC3BXL support the no mls qos rewrite ip dscp command for MPLS traffic, traffic in IP in IP tunnels, and traffic in GRE tunnels.

•The PFC3A supports the no mls qos rewrite ip dscp command for all IP traffic except MPLS traffic, traffic in IP in IP tunnels, and traffic in GRE tunnels.

---

To enable DSCP transparency, which preserves the received Layer 3 ToS byte, perform this task:

	Command	Purpose
Step 1	Router(config)# no mls qos rewrite ip dscp	Disables egress ToS-byte rewrite globally on the switch.
	Router(config)# mls qos rewrite ip dscp	Enables egress ToS-byte rewrite globally on the switch.
Step 2	Router(config)# end	Exits configuration mode.
Step 3	Router# show mls qos | include rewrite	Verifies the configuration.

When you preserve the received Layer 3 ToS byte, QoS uses the marked or marked-down CoS value for egress queueing and in egress tagged traffic.

This example shows how to preserve the received Layer 3 ToS byte and verify the configuration:

Router# configure terminal 

Router(config)# no mls qos rewrite ip dscp 

Router(config)# end 

Router# show mls qos | include rewrite

  QoS ip packet dscp rewrite disabled globally

Router#

Enabling Queueing-Only Mode

To enable queueing-only mode on the switch, perform this task:

	Command	Purpose
Step 1	Router(config)# mls qos queueing-only	Enables queueing-only mode on the switch.
	Router(config)# no mls qos queueing-only	Disables PFC QoS globally on the switch. Note You cannot disable queueing-only mode separately.
Step 2	Router(config)# end	Exits configuration mode.
Step 3	Router# show mls qos	Verifies the configuration.

When you enable queueing-only mode, the switch does the following:

•Disables marking and policing globally

•Configures all ports to trust Layer 2 CoS

---

Note The switch 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

---

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

	Command	Purpose
Step 1	Router(config)# interface {{vlan vlan_ID} | {type1  slot/port}}	Selects the interface to configure.
Step 2	Router(config-if)# mls qos bridged	Enables microflow policing of bridged traffic, including bridge groups, on the VLAN.
	Router(config-if)# no mls qos bridged	Disables microflow policing of bridged traffic.
Step 3	Router(config-if)# end	Exits configuration mode.
Step 4	Router# show mls qos	Verifies the configuration.

1 type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet

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#

Enabling VLAN-Based PFC QoS on Layer 2 LAN Ports

---

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:

	Command	Purpose
Step 1	Router(config)# interface {{type1  slot/port} | {port-channel number}}	Selects the interface to configure.
Step 2	Router(config-if)# mls qos vlan-based	Enables VLAN-based PFC QoS on a Layer 2 LAN port or a Layer 2 EtherChannel.
	Router(config-if)# no mls qos vlan-based	Disables VLAN-based PFC QoS.
Step 3	Router(config-if)# end	Exits configuration mode.
Step 4	Router# show mls qos	Verifies the configuration.

1 type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet

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

---

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

---

Enabling Egress ACL Support for Remarked DSCP

To enable egress ACL support for remarked DSCP on an ingress interface, perform this task:

	Command	Purpose
Step 1	Router(config)# interface {{vlan vlan_ID} | {type1  slot/port} | {port-channel number}}	Selects the ingress interface to configure.
Step 2	Router(config-if)# platform ip features sequential [access-group IP_acl_name_or_number]	Enables egress ACL support for remarked DSCP on the ingress interface.
	Router(config-if)# no platform ip features sequential [access-group IP_acl_name_or_number]	Disables egress ACL support for remarked DSCP on the ingress interface.
Step 3	Router(config-if)# end	Exits configuration mode.
Step 4	Router# show running-config interface ({type1 slot/port} | {port-channel number}}	Verifies the configuration.

1 type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet

When configuring egress ACL support for remarked DSCP on an ingress interface, note the following information:

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

Command	Purpose
Router(config)# mls qos aggregate-policer policer_name bits_per_second normal_burst_bytes [maximum_burst_bytes] [pir peak_rate_bps] [[[conform-action {drop | set-dscp-transmit1 dscp_value | set-prec-transmit1 ip_precedence_value | transmit}] exceed-action {drop | policed-dscp | transmit}] violate-action {drop | policed-dscp | transmit}]	Creates a named aggregate policer.
Router(config)# no mls qos aggregate-policer policer_name	Deletes a named aggregate policer.

1 The set-dscp-transmit and set-prec-transmit keywords are only supported for IP traffic.

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 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 512 megabytes, entered as 512000000.

–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 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, 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.

---

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

---

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

---

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

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

---

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

Router(config)# mls qos aggregate-policer aggr-1 1000000 10000000 conform-action transmit 
exceed-action policed-dscp-transmit 

Router(config)# end 

Router#

This example shows how to verify the configuration:

Router# show mls qos aggregate-policer aggr-1 

ag1 1000000 1000000 conform-action transmit exceed-action policed-dscp-transmit AgId=0 
[pol4]

Router#

The output displays the following:

•The AgId parameter displays the hardware policer ID.

•The policy maps that use the policer are listed in the square brackets ([]).

Configuring a PFC QoS Policy

These sections describe PFC QoS policy configuration:

•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

---

Note PFC QoS policies process both unicast and multicast traffic.

---

PFC QoS Policy Configuration Overview

---

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

Protocol	Numbered ACLs	Extended ACLs	Named ACLs
IPv4	Yes: 1 to   99 1300 to 1999	Yes: 100 to  199 2000 to 2699	Yes
IPv6	—	Yes (named)	Yes
IPX (Supported only with PFC2)	Yes: 800 to 899	Yes: 900 to 999	Yes
MAC Layer	No	No	Yes
ARP	No	No	Yes

–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:

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html

–See Chapter 33, "Configuring Network Security," for additional information about ACLs on the Catalyst 6500 series switches.

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

–Policy map class trust mode

–Aggregate policing and marking

–Microflow policing and marking

•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

•Enabling VLAN-Based MAC QoS Filtering

•Configuring MAC ACLs

---

Note You can use MAC ACLs with VLAN ACLs (VACLs). For more information, see Chapter 35, "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:

	Command	Purpose
Step 1	Router(config)# interface {{vlan vlan_ID} | {type1  slot/port[.subinterface]} | {port-channel number[.subinterface]}}	Selects the interface to configure.
Step 2	Router(config-if)# mac packet-classify	Enables protocol-independent MAC ACL filtering on the interface.
	Router(config-if)# no mac packet-classify	Disables protocol-independent MAC ACL filtering on the interface.

1 type = ethernet, fastethernet, gigabitethernet, or tengigabitethernet

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

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:

Command	Purpose
Router(config)# mac packet-classify use vlan	Enables VLAN-based QoS filtering in MAC ACLs.

To disable VLAN-based QoS filtering in MAC ACLs, perform this task:

Command	Purpose
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:

	Command	Purpose
Step 1	Router(config)# mac access-list extended list_name	Configures a MAC ACL.
	Router(config)# no mac access-list extended list_name	Deletes a MAC ACL.
Step 2	Router(config-ext-macl)# {permit | deny} {src_mac_mask | any} {dest_mac_mask | any} [{protocol_keyword | {ethertype_number ethertype_mask}} [vlan vlan_ID] [cos cos_value]]	Configures an access control entry (ACE) in a MAC ACL.
	Router(config-ext-macl)# no {permit | deny} {src_mac_mask | any} {dest_mac_mask | any} [{protocol_keyword | {ethertype_number ethertype_mask}} [vlan vlan_ID] [cos cos_value]]	Deletes an ACE from a MAC ACL.

When configuring an entry in a MAC-Layer ACL, note the following information:

•The PFC3 supports the ipx-arpa and ipx-non-arpa keywords.

•The PFC2 does not support the ipx-arpa and ipx-non-arpa keywords.

•The vlan and cos keywords are supported in PFC3BXL or PFC3B mode with Release 12.2(17b)SXA and later releases.

•The vlan and cos keywords are not supported in MAC ACLs used for VACL filtering.

•With Release 12.2(18)SXD and later releases, the vlan keyword for VLAN-based QoS filtering in MAC ACLs can be globally enabled or disabled and is disabled by default.

•You can enter MAC addresses as three 2-byte values in dotted hexadecimal format. For example, 0030.9629.9f84.

•You can enter MAC address masks as three 2-byte values in dotted hexadecimal format. Use 1 bits as wildcards. For example, to match an address exactly, use 0000.0000.0000 (can be entered as 0.0.0).

•You can enter an EtherType and an EtherType mask as hexadecimal values.

•Entries without a protocol parameter match any protocol.

•ACL entries are scanned in the order you enter them. The first matching entry is used. To improve performance, place the most commonly used entries near the beginning of the ACL.

•An implicit deny any any entry exists at the end of an ACL unless you include an explicit permit any any entry at the end of the list.

•All new entries to an existing list are placed at the end of the list. You cannot add entries to the middle of a list.

•This list shows the EtherType values and their corresponding protocol keywords:

–0x0600—xns-idp—Xerox XNS IDP

–0x0BAD—vines-ip—Banyan VINES IP

–0x0baf—vines-echo—Banyan VINES Echo

–0x6000—etype-6000—DEC unassigned, experimental

–0x6001—mop-dump—DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance

–0x6002—mop-console—DEC MOP Remote Console

–0x6003—decnet-iv—DEC DECnet Phase IV Route

–0x6004—lat—DEC Local Area Transport (LAT)

–0x6005—diagnostic—DEC DECnet Diagnostics

–0x6007—lavc-sca—DEC Local-Area VAX Cluster (LAVC), SCA

–0x6008—amber—DEC AMBER

–0x6009—mumps—DEC MUMPS

–0x0800—ip—Malformed, invalid, or deliberately corrupt IP frames

–0x8038—dec-spanning—DEC LANBridge Management

–0x8039—dsm—DEC DSM/DDP

–0x8040—netbios—DEC PATHWORKS DECnet NETBIOS Emulation

–0x8041—msdos—DEC Local Area System Transport

–0x8042—etype-8042—DEC unassigned

–0x809B—appletalk—Kinetics EtherTalk (AppleTalk over Ethernet)

–0x80F3—aarp—Kinetics AppleTalk Address Resolution Protocol (AARP)

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

---

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.

---

With a PFC3 and Release 12.2(18)SXD and later releases, you can configure named ACLs that filter ARP traffic (EtherType 0x0806) for QoS.

To configure an ARP ACL for QoS filtering, perform this task:

	Command	Purpose
Step 1	Router(config)# arp access-list list_name	Configures an ARP ACL for QoS filtering.
	Router(config)# no arp access-list list_name	Deletes an ARP ACL.
Step 2	Router(config-arp-nacl)# {permit | deny} {ip {any | host sender_ip | sender_ip sender_ip_wildcardmask} mac any	Configures an access control entry (ACE) in an ARP ACL for QoS filtering.
	Router(config-arp-nacl)# no {permit | deny} {ip {any | host sender_ip | sender_ip sender_ip_wildcardmask} mac any	Deletes an ACE from an ARP ACL.

When configuring an entry in an ARP ACL for QoS filtering, note the following information:

•This publication describes the ARP ACL syntax that is supported in hardware by the PFC3. Any other ARP ACL syntax displayed by the CLI help when you enter a question mark ("?") is not supported and cannot be used to filter ARP traffic for QoS.

•ACLs entries are scanned in the order you enter them. The first matching entry is used. To improve performance, place the most commonly used entries near the beginning of the ACL.

•An implicit deny ip any mac any entry exists at the end of an ACL unless you include an explicit permit ip any mac any entry at the end of the list.

•All new entries to an existing list are placed at the end of the list. You cannot add entries to the middle of a list.

This example shows how to create an ARP ACL named arp_filtering that only permits ARP traffic from IP address 1.1.1.1:

Router(config)# arp access-list arp_filtering 

Router(config-arp-nacl)# permit ip host 1.1.1.1 mac any 

Configuring a Class Map

These sections describe class map configuration:

•Creating a Class Map

•Class Map Filtering Guidelines and Restrictions

•Configuring Filtering in a Class Map

Creating a Class Map

To create a class map, perform this task:

Command	Purpose
Router(config)# class-map class_name	Creates a class map.
Router(config)# no class-map class_name	Deletes a class map.

Class Map Filtering Guidelines and Restrictions

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.

•When multiple match access-group ACLs are included in a match-any class map, and one ACL contains a deny entry, all match criteria after the deny entry (either in the same ACL or in different ACLs) will not be installed in the TCAM.

In the following example, ACLs acl4 and acl5 will not be installed because they follow acl3, which contains a deny ip any any entry:

ip access-list ext acl3

  deny ip any any

class-map cmap1

  match access-group acl1

  match access-group acl2

  match access-group acl3

  match access-group acl4

  match access-group acl5

You can use either of the following workarounds to avoid this issue:

–Move the deny entry to the end of the ACL and move that ACL to the end of the class map.

–Configure all ACLs that must follow the deny entry into different class maps.

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

•Release 12.2(18)SXE and later releases support the match any class map command.

•PFC QoS does not support the match cos, match classmap, match destination-address, match input-interface, match qos-group, and match source-address class map commands.

•Catalyst 6500 series switches do not detect the use of unsupported commands until you attach a policy map to an interface.

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

http://www.cisco.com/en/US/docs/ios/12_4t/qos/configuration/guide/qsnbar1.html

•Filtering based on IP precedence or DSCP for egress QoS uses the received IP precedence or DSCP. Egress QoS filtering is not based on any IP precedence or DSCP changes made by ingress QoS.

---

Note This chapter includes the following ACL documentation:

•Configuring MAC ACLs

•Configuring ARP ACLs for QoS Filtering

Other ACLs are not documented in this publication. See the references under access-list in the "PFC QoS Policy Configuration Overview" section.

---

Configuring Filtering in a Class Map

To configure filtering in a class map, perform one of these tasks:

Command	Purpose
Router(config-cmap)# match access-group name acl_index_or_name	(Optional) Configures the class map to filter using an ACL.
Router(config-cmap)# no match access-group name acl_index_or_name	Clears the ACL configuration from the class map.
Router (config-cmap)# match protocol ipv6	(Optional—for IPv6 traffic) Configures the class map to filter IPv6 traffic.
Router (config-cmap)# no match protocol ipv6	Clears IPv6 filtering.
Router (config-cmap)# match precedence ipp_value1 [ipp_value2 [ipp_valueN]]	(Optional—for IPv4 or IPv6 traffic) Configures the class map to filter based on up to eight IP precedence values. Note Does not support source-based or destination-based microflow policing.
Router (config-cmap)# no match precedence ipp_value1 [ipp_value2 [ipp_valueN]]	Clears configured IP precedence values from the class map.
Router (config-cmap)# match dscp dscp_value1 [dscp_value2 [dscp_valueN]]	(Optional—for IPv4 or IPv6 traffic only) Configures the class map to filter based on up to eight DSCP values. Note Does not support source-based or destination-based microflow policing.
Router (config-cmap)# no match dscp dscp_value1 [dscp_value2 [dscp_valueN]]	Clears configured DSCP values from the class map.
Router (config-cmap)# match ip precedence ipp_value1 [ipp_value2 [ipp_valueN]]	(Optional—for IPv4 traffic) Configures the class map to filter based on up to eight IP precedence values. Note Does not support source-based or destination-based microflow policing.
Router (config-cmap)# no match ip precedence ipp_value1 [ipp_value2 [ipp_valueN]]	Clears configured IP precedence values from the class map.
Router (config-cmap)# match ip dscp dscp_value1 [dscp_value2 [dscp_valueN]]	(Optional—for IPv4 traffic) Configures the class map to filter based on up to eight DSCP values. Note Does not support source-based or destination-based microflow policing.
Router (config-cmap)# no match ip dscp dscp_value1 [dscp_value2 [dscp_valueN]]	Clears configured DSCP values from the class map.

Verifying Class Map Configuration

To verify class map configuration, perform this task:

	Command	Purpose
Step 1	Router (config-cmap)# end	Exits configuration mode.
Step 2	Router# show class-map class_name	Verifies the configuration.

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

•Policy Map Class Configuration Guidelines and Restrictions

•Creating a Policy Map Class and Configuring Filtering

•Configuring Policy Map Class Actions

Creating a Policy Map

To create a policy map, perform this task:

Command	Purpose
Router(config)# policy-map policy_name	Creates a policy map.
Router(config)# no policy-map policy_name	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_name protocol 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:

http://www.cisco.com/en/US/docs/ios/12_4t/qos/configuration/guide/qsnbar1.html

•PFC QoS does not support the class class_name destination-address, class class_name input-interface, class class_name qos-group, and class class_name source-address policy map commands.

•With Release 12.2(18)SXE and later releases, PFC QoS supports the class default policy map command.

•PFC QoS does not detect the use of unsupported commands until you attach a policy map to an interface.

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:

Command	Purpose
Router(config-pmap)# class class_name	Creates a policy map class and configures it to filter with a class map. Note PFC QoS supports class maps that contain a single match command.
Router(config-pmap)# no class class_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.

•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

---

Note When configure policing, you can mark traffic with policing keywords.

---

These sections describe policy map class action configuration:

•Configuring Policy Map Class Marking

•Configuring the Policy Map Class Trust State

•Configuring Policy Map Class Policing

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:

Command	Purpose
Router(config-pmap-c)# 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.
Router(config-pmap-c)# no set {dscp dscp_value | precedence ip_precedence_value}	Clears the marking configuration.

---

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

---

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

Command	Purpose
Router(config-pmap-c)# trust {cos | dscp | ip-precedence}	Configures the policy map class trust state, which selects the value that PFC QoS uses as the source of the initial internal DSCP value.
Router(config-pmap-c)# no trust	Reverts to the default policy-map class trust state (untrusted).

When configuring the policy map class trust state, note the following information:

•Enter the no trust command to use the trust state configured on the ingress port (this is the default).

•With the cos keyword, PFC QoS sets the internal DSCP value from received or ingress port CoS.

•With the dscp keyword, PFC QoS uses received DSCP.

•With the ip-precedence keyword, PFC QoS sets DSCP from received IP precedence.

Configuring Policy Map Class Policing

When you configure policy map class policing, note the following information:

•PFC QoS does not support the set-qos-transmit policer keyword.

•PFC QoS does not support the set-dscp-transmit or set-prec-transmit keywords as arguments to the exceed-action keyword.

•PFC QoS does not detect the use of unsupported keywords until you attach a policy map to an interface.

These sections describe configuration of policy map class policing:

•Using a Named Aggregate Policer

•Configuring a Per-Interface Policer

---

Note Policing with the conform-action transmit keywords sets the port trust state of matched traffic to trust DSCP or to the trust state configured by a trust command in the policy map class.

---

Using a Named Aggregate Policer

To use a named aggregate policer, perform this task:

Command	Purpose
Router(config-pmap-c)# police aggregate aggregate_name	Configures the policy map class to use a previously defined named aggregate policer.
Router(config-pmap-c)# no police aggregate aggregate_name	Clears use of the named aggregate policer.

Configuring a Per-Interface Policer

To configure a per-interface policer, perform this task:

Command	Purpose
Router(config-pmap-c)# police [flow [mask {src-only | dest-only | full-flow}]] bits_per_second normal_burst_bytes [maximum_burst_bytes] [pir peak_rate_bps] [[[conform-action {drop | set-dscp-transmit dscp_value | set-prec-transmit ip_precedence_value | transmit}] exceed-acti