Catalyst 6500 Series Cisco IOS Software Configuration Guide, 12.1E - Configuring PFC QoS [Cisco Catalyst 6500 Series Switches]

Table Of Contents

Configuring PFC QoS

Understanding How PFC QoS Works

Hardware Supported by PFC QoS

QoS Terminology

PFC QoS Feature Flowcharts

PFC QoS Feature Summary

Ingress LAN Port Features

Ingress OSM Port Features

PFC QoS Features

Egress LAN Port Features

Egress OSM Port Features

MSFC Features

Ingress LAN Port Features

Ingress LAN Port Trust States

Marking at Untrusted Ingress LAN Ports

Marking at Trusted Ingress LAN Ports

Ingress LAN Port Scheduling and Congestion Avoidance

PFC Marking and Policing

Internal DSCP Values

Policy Maps

Policers

Attaching Policy Maps

Egress CoS and ToS Values

LAN Egress Port Features

Transmit Queues

Scheduling and Congestion Avoidance

Marking

PFC QoS Statistics Data Export

PFC QoS Default Configuration

PFC QoS Configuration Guidelines and Restrictions

Guidelines:

Restrictions

Configuring PFC QoS

Enabling PFC QoS Globally

Enabling Queueing-Only Mode

Creating Named Aggregate Policers

Configuring a PFC QoS Policy

PFC QoS Policy Configuration Overview

Configuring MAC-Layer Named Access Lists (Optional)

Configuring a Class Map (Optional)

Verifying Class Map Configuration

Configuring a Policy Map

Verifying Policy Map Configuration

Attaching a Policy Map to an Interface

Enabling or Disabling Microflow Policing

Enabling Microflow Policing of Bridged Traffic

Enabling or Disabling PFC Features on an Interface

Enabling VLAN-Based PFC QoS on Layer 2 LAN Ports

Configuring the Trust State of Ethernet LAN and OSM Ingress 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 Transmit Queue

Configuring 1q4t/2q2t Tail-Drop Threshold Percentages

Mapping CoS Values to Drop Thresholds

Mapping CoS Values to Standard Receive-Queue Thresholds

Mapping CoS Values to Standard Transmit-Queue Thresholds

Mapping CoS Values to Strict-Priority Queues

Mapping CoS Values to Tail-Drop Thresholds on 1q4t/2q2t LAN Ports

Allocating Bandwidth Between LAN-Port Transmit Queues

Setting the Receive-Queue Size Ratio on a 1p1q0t or 1p1q8t Ingress LAN Ports

Setting the LAN-Port Transmit-Queue Size Ratio

Configuring DSCP Value Maps

Mapping Received CoS Values to Internal DSCP Values

Mapping Received IP Precedence Values to Internal DSCP Values

Mapping Internal DSCP Values to Egress CoS Values

Configuring DSCP Markdown Values

Configuring PFC QoS Statistics Data Export

Enabling PFC QoS Statistics Data Export Globally

Enabling PFC QoS Statistics Data Export for a Port

Enabling PFC QoS Statistics Data Export for a Named Aggregate Policer

Enabling PFC QoS Statistics Data Export for a Class Map

Setting the PFC QoS Statistics Data Export Time Interval

Configuring PFC QoS Statistics Data Export Destination Host and UDP Port

Setting the PFC QoS Statistics Data Export Field Delimiter

Configuring PFC QoS

This chapter describes how to configure quality of service (QoS) as implemented on the policy feature card (PFC) on the Catalyst 6500 series switches.

Note For complete syntax and usage information for the commands used in this publication, refer to the Catalyst 6500 Series Switch Cisco IOS Command Reference publication.

This chapter contains these sections:

•Understanding How PFC QoS Works

•PFC QoS Default Configuration

•PFC QoS Configuration Guidelines and Restrictions

•Configuring PFC QoS

Note•With Release 12.1(13)E and later releases and with an MSFC2, you can configure Network-Based Application Recognition (NBAR) on Layer 3 interfaces instead of using PFC QoS.

•All ingress and egress traffic on an interface that is configured with NBAR is processed in software on the MSFC2.

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

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

•To configure NBAR, refer to this publication:

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

Understanding How PFC QoS Works

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 selects network traffic (both unicast and multicast), prioritizes it according to its relative importance, and uses congestion avoidance to provide priority-indexed treatment; QoS can also limit the bandwidth used by network traffic. QoS makes network performance more predictable and bandwidth utilization more effective.

Note On the Catalyst 6500 series switches, queue architecture and QoS queueing features such as Weighted-Round Robin (WRR) and Weighted Random Early Detection (WRED) are implemented with a fixed configuration in Application Specific Integrated Circuits (ASICs). The queueing architecture cannot be reconfigured. For more information, see the "Receive Queues" section and the "Transmit Queues" section.

These sections describe PFC QoS:

•Hardware Supported by PFC QoS

•QoS Terminology

•PFC QoS Feature Flowcharts

•PFC QoS Feature Summary

•Ingress LAN Port Features

•PFC Marking and Policing

•LAN Egress Port Features

•PFC QoS Statistics Data Export

Hardware Supported by PFC QoS

With Release 12.1(11a)E and later, PFC QoS supports both LAN ports and optical services module (OSM) ports:

•LAN ports are Ethernet ports on Ethernet switching modules, except for the 4-port Gigabit Ethernet WAN (GBIC) module (OSM-4GE-WAN). Except for the OSM-4GE-WAN module, OSMs have four Ethernet LAN ports in addition to WAN ports. With earlier releases, PFC QoS supports only LAN ports.

•OSM ports are the WAN ports on OSMs. The PFC provides ingress QoS for traffic from OSM ports. For more information, see the following sections:

–"Ingress OSM Port Features" section

–"Egress OSM Port Features" section

–"PFC Marking and Policing" section

–"Attaching Policy Maps" section

–"Configuring the Trust State of Ethernet LAN and OSM Ingress Ports" section

•Refer to the following publication for information about additional OSM QoS features:

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

•The PFC does not provide QoS for FlexWAN module ports. Refer to the following publications for information about FlexWAN module QoS features:

–Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.1:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/index.htm

–Cisco IOS Quality of Service Solutions Command Reference, Release 12.1:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/index.htm

–Class-Based Marking:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/cbpmark2.htm

–Traffic Policing:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtpoli.htm

–Distributed Class-Based Weighted Fair Queueing and Distributed Weighted Random Early Detection:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtcbwred.htm

–Distributed Low Latency Queueing:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtllqvip.htm

–Configuring Burst Size in Low Latency Queueing:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtcfgbst.htm

–Distributed Traffic Shaping:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtdts.htm

–MPLS QoS:

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

QoS Terminology

This section defines some QoS terminology:

•Packets carry traffic at Layer 3.

•Frames carry traffic at Layer 2. Layer 2 frames carry Layer 3 packets.

•Labels are prioritization values carried in Layer 3 packets and Layer 2 frames:

–Layer 2 class of service (CoS) values, which range between zero for low priority and seven for high priority:

Layer 2 Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries an IEEE 802.1p CoS value in the three least significant bits.

Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most significant bits, which are called the User Priority bits.

Other frame types cannot carry Layer 2 CoS values.

Note On LAN ports configured as Layer 2 ISL trunks, all traffic is in ISL frames. On LAN ports configured as Layer 2 802.1Q trunks, all traffic is in 802.1Q frames except for traffic in the native VLAN.

–Layer 3 IP precedence values—The IP version 4 specification defines the three most significant bits of the 1-byte Type of Service (ToS) field as IP precedence. IP precedence values range between zero for low priority and seven for high priority.

–Layer 3 differentiated services code point (DSCP) values—The Internet Engineering Task Force (IETF) has defined the six most significant bits of the 1-byte IP ToS field as the DSCP. The per-hop behavior represented by a particular DSCP value is configurable. DSCP values range between 0 and 63 (see the "Configuring DSCP Value Maps" section).

Note Layer 3 IP packets can carry either an IP precedence value or a DSCP value. PFC QoS supports the use of either value, since DSCP values are backwards compatible with IP precedence values (see Table 32-1).

Table 32-1 IP Precedence and DSCP Values

3-bit IP
Precedence

6 MSb¹ 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

¹MSb = most significant bit

•Classification is the selection of traffic to be marked.

•Marking, according to RFC 2475, is the process of setting a Layer 3 DSCP value in a packet; in this publication, the definition of marking is extended to include setting Layer 2 CoS values.

•Scheduling is the assignment of Layer 2 frames to a queue. PFC QoS assigns frames to a queue based on Layer 2 CoS values.

•Congestion avoidance is the process by which PFC QoS reserves ingress and egress LAN port capacity for Layer 2 frames with high-priority Layer 2 CoS values. PFC QoS implements congestion avoidance with Layer 2 CoS value-based drop thresholds. A drop threshold is the percentage of queue buffer utilization above which frames with a specified Layer 2 CoS value is dropped, leaving the buffer available for frames with higher-priority Layer 2 CoS values.

•Policing is limiting bandwidth used by a flow of traffic. Policing is done on the Policy Feature Card (PFC) or on the Policy Feature Card 2 (PFC2) and distributed forwarding cards (DFCs). Policing can mark or drop traffic.

PFC QoS Feature Flowcharts

Figure 32-1 show how traffic flows through the components that support PFC QoS features.

Figure 32-1 Traffic Flow Through PFC QoS Features with PFC2

Note PFC QoS supports traffic from OSMs with Release 12.1(11a)E and later.

Figure 32-2 Traffic Flow Through PFC QoS Features with PFC

Note•The PFC can provide Layer 3 switching for FlexWAN traffic but does not provide PFC QoS for FlexWAN traffic.

•PFC QoS does not change the ToS byte in FlexWAN ingress traffic.

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

Figure 32-3 through Figure 32-8 show how the PFC QoS features are implemented on the switch components.

Figure 32-3 Ingress LAN Port Layer 2 PFC QoS Features

Figure 32-4 PFC Classification, Marking, and Policing

Figure 32-5 Marking with PFC2 and Multilayer Switch Feature Card 2

Figure 32-6 Marking with PFC1 and Multilayer Switch Feature Card 1 or 2

Figure 32-7 Egress WAN Port Marking

Figure 32-8 Egress LAN Port Scheduling, Congestion Avoidance, and Marking

PFC QoS Feature Summary

These sections summarize the PFC QoS features:

•Ingress LAN Port Features

•Ingress OSM Port Features

•PFC QoS Features

•Egress LAN Port Features

•Egress OSM Port Features

•MSFC Features

Ingress LAN Port Features

PFC QoS supports classification, marking, scheduling, and congestion avoidance using Layer 2 CoS values at ingress LAN ports. Classification, marking, scheduling, and congestion avoidance at ingress LAN ports do not use or set Layer 3 IP precedence or DSCP values. You can configure ingress LAN port trust states that can be used by the PFC to set Layer 3 IP precedence or DSCP values and the Layer 2 CoS value. See Figure 32-3 and the "Ingress LAN Port Features" section.

Ingress OSM Port Features

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 Layer 3 IP precedence or DSCP values and the Layer 2 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 because the default port CoS is not configurable on OSM ports.)

PFC QoS Features

On the PFC, PFC QoS supports ingress classification, marking, and policing using policy maps. You can attach one policy map to an ingress port. Each policy map can contain multiple policy-map classes. You can configure a separate policy-map class for each type of traffic received through the ingress port. See the "PFC Marking and Policing" section.

Note•You can globally disable marking and policing with the mls qos queueing-only command (see the Enabling Queueing-Only Mode).

•You can disable marking and policing on a per-interface basis with the no mls qos interface command (see the "Enabling or Disabling PFC Features on an Interface" section.

Egress LAN Port Features

PFC QoS supports egress LAN port scheduling and congestion avoidance using Layer 2 CoS values. Egress LAN port marking sets Layer 2 CoS values and Layer 3 DSCP values. See the "LAN Egress Port Features" section.

Egress OSM Port Features

Ingress PFC QoS sets Layer 3 DSCP values that can be used by the OSM egress QoS features.

MSFC Features

PFC QoS marks IP traffic transmitted to the MSFC with rewritten Layer 3 DSCP values. With PFC2, CoS is equal to IP precedence in all traffic sent from the MSFC2 to egress ports; with PFC1, CoS is zero.

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

Ingress LAN Port Features

These sections describe ingress LAN port PFC QoS features:

•Ingress LAN Port Trust States

•Marking at Untrusted Ingress LAN Ports

•Marking at Trusted Ingress LAN Ports

•Ingress LAN Port Scheduling and Congestion Avoidance

Ingress LAN Port Trust States

The trust state of an ingress LAN port determines how the port marks, schedules, and classifies received Layer 2 frames, and whether or not congestion avoidance is implemented. You can configure the trust state of each ingress LAN port as follows:

•Untrusted (default)

•Trust IP precedence (not supported on 1q4t LAN ports except Gigabit Ethernet)

•Trust DSCP (not supported on 1q4t LAN ports except Gigabit Ethernet)

•Trust CoS (not supported on 1q4t LAN ports except Gigabit Ethernet)

See the "Configuring the Trust State of Ethernet LAN and OSM Ingress Ports" section. PFC QoS implements ingress LAN port congestion avoidance only on LAN ports configured to trust CoS.

Note Ingress LAN port marking, scheduling, and congestion avoidance use Layer 2 CoS values and does not use or set Layer 3 IP precedence or DSCP values.

Marking at Untrusted Ingress LAN Ports

PFC QoS marks all frames received through untrusted ingress LAN ports with the ingress port CoS value (the default is zero). PFC QoS does not implement ingress port congestion avoidance on untrusted ingress LAN ports.

Note•To use the ingress port CoS value applied to untrusted traffic as the basis of egress DSCP, configure a trust-CoS policy map that matches the ingress traffic.

•The ingress port CoS value is configurable for each ingress LAN port (see the "Configuring the Ingress LAN Port CoS Value" section).

Marking at Trusted Ingress LAN Ports

When an ISL frame enters the Catalyst 6500 series 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 marks all traffic received in untagged frames with the ingress port CoS value.

Note•PFC QoS uses the received CoS value in trusted tagged traffic as the basis of egress DSCP, unless there is a policy map that changes the trust state of the traffic.

•PFC QoS uses the ingress port CoS value applied to trusted untagged traffic as the basis of egress DSCP, unless there is a policy map that changes the trust state of the traffic.

•The ingress port CoS value is configurable for each ingress LAN port (see the "Configuring the Ingress LAN Port CoS Value" section).

Ingress LAN Port Scheduling and Congestion Avoidance

On ingress LAN ports configured to trust CoS, PFC QoS uses Layer 2 CoS-value based receive-queue drop thresholds to avoid congestion (see the "Configuring the Trust State of Ethernet LAN and OSM Ingress Ports" section).

Receive Queues

Enter the show queueing interface {ethernet | fastethernet | gigabitethernet | tengigabitethernet} slot/port | include type command to see the queue structure of a LAN port.

•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 (usable only on Gigabit Ethernet ports).

•1p1q4t indicates one strict-priority queue and one standard queue with four configurable tail-drop thresholds.

•1p1q0t indicates one strict-priority queue and one standard queue with no configurable threshold (effectively a tail-drop threshold at 100 percent).

•1p1q8t indicates one strict-priority queue and one standard queue with eight thresholds, each configurable as either WRED-drop or tail-drop, and one non-configurable (100 percent) tail-drop threshold.

Strict-priority queues are queues that are serviced in preference to other queues. PFC QoS services traffic in a strict-priority queue before servicing the standard queue. When PFC QoS services the standard queue, after receiving a packet, it checks for traffic in the strict-priority queue. If PFC QoS 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.

Scheduling

PFC QoS schedules traffic through the receive queues based on Layer 2 CoS values. In the 1p1q4t, 1p1q0t and 1p1q8t default configurations, PFC QoS assigns all traffic with CoS 5 to the strict-priority queue; PFC QoS assigns all other traffic to the standard queue. In the 1q4t default configuration, PFC QoS assigns all traffic to the standard queue.

Congestion Avoidance

If an ingress LAN port is configured to trust CoS, PFC QoS implements Layer 2 CoS-value-based receive-queue drop thresholds to avoid congestion in received traffic.

1q2t ingress LAN ports have this default drop-threshold configuration:

•Frames with CoS 0, 1, 2, 3, or 4 go to tail-drop threshold 1, where the switch drops incoming frames when the standard receive-queue buffer is 80 percent full.

•Frames with CoS 5, 6, or 7 go to tail-drop threshold 2, where the switch drops incoming frames when the standard receive-queue buffer is 100 percent full.

1q4t ingress LAN ports have this default drop-threshold configuration:

•Using receive-queue tail-drop threshold 1, the switch drops incoming frames with CoS 0 or 1 when the receive-queue buffer is 50 percent or more full.

•Using receive-queue tail-drop threshold 2, the switch drops incoming frames with CoS 2 or 3 when the receive-queue buffer is 60 percent or more full.

•Using receive-queue tail-drop threshold 3, the switch drops incoming frames with CoS 4 or 5 when the receive-queue buffer is 80 percent or more full.

•Using receive-queue tail-drop threshold 4, the switch drops incoming frames with CoS 6 or 7 when the receive-queue buffer is 100 percent full.

1p1q4t ingress LAN ports have this default drop-threshold configuration:

•Frames with CoS 5 go to the strict-priority receive queue (queue 2), where the switch drops incoming frames only when the strict-priority receive-queue buffer is 100 percent full.

•Frames with CoS 0, 1, 2, 3, 4, 6, or 7 go to the standard receive queue.

–Using standard receive-queue tail-drop threshold 1, the switch drops incoming frames with CoS 0 or 1 when the receive-queue buffer is 50 percent or more full.

–Using standard receive-queue tail-drop threshold 2, the switch drops incoming frames with CoS 2 or 3 when the receive-queue buffer is 60 percent or more full.

–Using standard receive-queue tail-drop threshold 3, the switch drops incoming frames with CoS 4 when the receive-queue buffer is 80 percent or more full.

–Using standard receive-queue tail-drop threshold 4, the switch drops incoming frames with CoS 6 or 7 when the receive-queue buffer is 100 percent full.

1p1q0t ingress LAN ports have this default drop-threshold configuration:

•Frames with CoS 5 go to the strict-priority receive queue (queue 2), where the switch drops incoming frames only when the strict-priority receive-queue buffer is 100 percent full.

•Frames with CoS 0, 1, 2, 3, 4, 6, or 7 go to the standard receive queue. The switch drops incoming frames when the receive-queue buffer is 100 percent full.

1p1q8t ports have this default drop-threshold configuration:

•Frames with CoS 5 go to the strict-priority receive queue (queue 2), where the switch drops incoming frames only when the strict-priority receive-queue buffer is 100 percent full.

•Frames with CoS 0, 1, 2, 3, 4, 6, or 7 go to the standard receive queue, which uses WRED-drop thresholds:

–Using standard receive-queue WRED-drop threshold 1 for incoming frames with CoS 0, the switch starts to drop frames when the receive-queue buffer is 40 percent full and drops all frames with CoS 0 when the receive-queue buffer is 70 percent or more full.

–Using standard receive-queue WRED-drop threshold 2 for incoming frames with CoS 1, the switch starts to drop frames when the receive-queue buffer is 40 percent full and drops all frames with CoS 1 when the receive-queue buffer is 70 percent or more full.

–Using standard receive-queue WRED-drop threshold 3 for incoming frames with CoS 2, the switch starts to drop frames when the receive-queue buffer is 50 percent full and drops all frames with CoS 2 when the receive-queue buffer is 80 percent or more full.

–Using standard receive-queue WRED-drop threshold 4 for incoming frames with CoS 3, the switch starts to drop frames when the receive-queue buffer is 50 percent full and drops all frames with CoS 3 when the receive-queue buffer is 80 percent or more full.

–Using standard receive-queue WRED-drop threshold 5 for incoming frames with CoS 4, the switch starts to drop frames when the receive-queue buffer is 60 percent full and drops all frames with CoS 4 when the receive-queue buffer is 90 percent or more full.

–Using standard receive-queue WRED-drop threshold 6 for incoming frames with CoS 6, the switch starts to drop frames when the receive-queue buffer is 60 percent full and drops all frames with CoS 6 when the receive-queue buffer is 90 percent or more full.

–Using standard receive-queue WRED-drop threshold 7 for incoming frames with CoS 7, the switch starts to drop frames when the receive-queue buffer is 70 percent full and drops all frames with CoS 7 when the receive-queue buffer is 100 percent or more full.

Note 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. See the "Configuring Standard-Queue Drop Threshold Percentages" section.

Note The explanations in this section use default values. You can configure many of the parameters (see the "Configuring PFC QoS" section). All LAN ports of the same type use the same drop-threshold configuration.

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

Figure 32-9 Receive Queue Drop Thresholds

PFC Marking and Policing

Note•To mark untrusted traffic without policing in Release 12.1(12c)E1 and later releases, use the set ip dscp or set ip precedence policy map class commands (see the "Configuring Policy Map Class Actions" section).

•To mark untrusted traffic without policing in earlier releases, create a policer that only marks and does not police.

These sections describe PFC marking and policing:

•Internal DSCP Values

•Policy Maps

•Policers

•Attaching Policy Maps

•Egress CoS and ToS Values

Note Filtering for PFC QoS can use Layer 2, 3, and 4 values. Marking uses Layer 2 CoS values and Layer 3 IP precedence or DSCP values.

Internal DSCP Values

These sections describe the internal DSCP values:

•Internal DSCP Sources

•Egress DSCP and CoS Sources

Internal DSCP Sources

During processing, PFC QoS represents the priority of all traffic (including non-IP traffic) with an internal DSCP value. PFC QoS derives the internal DSCP value from the following:

•For trust-cos traffic, from received or ingress port Layer 2 CoS values

Note Traffic from an untrusted ingress LAN port has the ingress port CoS value and if traffic from an untrusted ingress Ethernet port matches a trust-cos policer, PFC QoS derives the internal DSCP value from the ingress port CoS value.

•For trust-ipprec traffic, from received IP precedence values

•For trust-dscp traffic, from received DSCP values

•For untrusted traffic, from ingress port CoS or configured DSCP values

The trust state of traffic is the trust state of the ingress LAN port unless set otherwise by a matching ACE.

Note A trust-cos policer cannot restore received CoS in traffic from untrusted ingress LAN ports. Traffic from untrusted ingress LAN ports always has the ingress port CoS value.

PFC QoS uses configurable mapping tables to derive the internal 6-bit DSCP value from CoS or IP precedence, which are 3-bit values (see the"Mapping Received CoS Values to Internal DSCP Values" section or the "Mapping Received IP Precedence Values to Internal DSCP Values" section).

Egress DSCP and CoS Sources

For egress IP traffic, PFC QoS creates a ToS byte from the internal 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 2 least-significant bits from the received ToS byte.

Note The internal DSCP value can mimic an IP precedence value (see Table 32-1).

For all egress traffic, PFC QoS uses a configurable mapping table to derive a CoS value from the internal DSCP value associated with traffic (see the "Mapping Internal DSCP Values to Egress CoS Values" section). PFC QoS sends the CoS value to the egress LAN ports for use in scheduling and to be written into ISL and 802.1Q frames.

Policy Maps

Note•You can globally disable marking and policing with the mls qos queueing-only command (see the Enabling Queueing-Only Mode).

•You can disable marking and policing on a per-interface basis with the no mls qos interface command (see the "Enabling or Disabling PFC Features on an Interface" section.

The PFC supports filtering, marking, and policing using policy maps (see the "Configuring a Policy Map" section). Each policy map can contain multiple policy-map classes. You can configure a separate policy-map class for each type of received traffic.

Policy-map classes specify filtering with the following:

•Cisco IOS access control lists (optional for IP, required for IPX and MAC-Layer filtering)

•Class-map match commands for Layer 3 IP precedence and DSCP values

Policy-map classes specify actions with the following:

•(Optional) Policy-map class trust commands. If specified, PFC QoS applies the policy-map class trust state to matched traffic. Policy-map class trust states supersede ingress LAN port trust states.

Note If traffic matches a policy-map class that does not contain a trust command, the trust state remains as set on the ingress LAN port.

•(Optional) Aggregate and microflow policers, which can use bandwidth limits to either mark or drop both conforming and nonconforming traffic. See the "PFC Marking and Policing" section.

The PFC uses the trust state (set by the ingress LAN port configuration or by a trust policy-map class command) to select the Layer 2 and Layer 3 PFC QoS labels that the egress port writes into the packets and frames before it is transmitted:

•Trust IP precedence—Sets the internal DSCP value to a mapped value based on received IP precedence (see the "Mapping Received IP Precedence Values to Internal DSCP Values" section).

•Trust DSCP—Sets the internal DSCP value to the received DSCP value.

Trust CoS—Sets the internal DSCP value to a mapped value based on received or port CoS. With trust CoS, note the following:

–Received CoS is overwritten with port CoS in traffic received through ports not configured to trust CoS.

–Received CoS is preserved only in traffic received through ports configured to trust CoS.

–Port CoS is applied to all traffic received in untagged frames, regardless of the port trust state.

–For information about mapping, see the "Mapping Received CoS Values to Internal DSCP Values" section.

•Untrusted—Sets the internal DSCP value to a configured DSCP value.

Note With the default values, PFC QoS applies DSCP zero to traffic from ingress LAN ports configured as untrusted.

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 (see the "Configuring the Policy Map Class Trust State" section).

You can create policers that do the following:

•Mark traffic

•Limit bandwidth utilization and mark traffic

For more information, see the "Creating Named Aggregate Policers" section and the "Configuring Policy Map Class Actions" section.

Policing rates are based on the Layer 3 packet size. You specify the bandwidth utilization limit as a committed information rate (CIR). With a PFC2, 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.

With a PFC2, 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 (see the "Configuring DSCP Markdown Values" section). 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 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.

You can create two kinds of policers: aggregate and microflow:

•PFC QoS applies the bandwidth limits specified in an aggregate policer cumulatively to all flows in matched traffic. You can create up to 1023 aggregate policers. You can create two types of aggregate policer: named and per port. Both types can be attached to more than one port:

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

Note Aggregate policing works independently on each DFC-equipped switching module and independently on the PFC2, 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 PFC2 and any non-DFC-equipped switching modules supported by the PFC2.

•PFC QoS applies the bandwidth limit specified in a microflow policer separately to each flow in matched traffic 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.

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

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

–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 (see the "Enabling Microflow Policing of Bridged Traffic" section).

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

Attaching Policy Maps

You can configure each ingress LAN port for either physical port-based PFC QoS (default) or VLAN-based PFC QoS (see the "Enabling VLAN-Based PFC QoS on Layer 2 LAN Ports" section) and attach a policy map to the selected port (see the "Attaching a Policy Map to an Interface" section).

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 classified, marked, and policed according 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 classified, marked, and policed according 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 classified, marked, and policed according 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 classified, marked, and policed according to the policy map attached to the traffic's VLAN.

You can attach policy maps to OSM ports.

Egress CoS and ToS Values

PFC QoS associates CoS and ToS values with traffic as specified by the trust state and policers in the policy map (see the "Internal DSCP Values" section). The associated CoS and ToS are used at the egress port (see the "LAN Egress Port Features" section).

LAN Egress Port Features

These sections describe how PFC QoS schedules traffic through the transmit queues based on CoS values and uses CoS-value-based transmit-queue drop thresholds to avoid congestion in traffic transmitted from egress LAN ports:

•Transmit Queues

•Scheduling and Congestion Avoidance

•Marking

Note Egress LAN port scheduling and congestion avoidance uses Layer 2 CoS values. Egress LAN port marking writes Layer 2 CoS values into trunk traffic and the Layer 3 ToS byte into all IP traffic.

Transmit Queues

Enter the show queueing interface {ethernet | fastethernet | gigabitethernet | tengigabitethernet} slot/port | include type command to see the queue structure of an egress LAN port.

The command displays one of the following:

•2q2t indicates two standard queues, each with two configurable tail-drop thresholds

•1p2q2t indicates one strict-priority queue and two standard queues, each with two configurable WRED-drop thresholds.

•1p3q1t indicates one strict-priority queue and three standard queues, each with one threshold configurable as either WRED-drop or tail-drop, and one nonconfigurable tail-drop threshold.

•1p2q1t indicates one strict-priority queue and two standard queues, each with one configurable WRED-drop threshold and one nonconfigurable tail-drop threshold.

All port types have a low-priority and a high-priority standard transmit queue. 1p3q1t ports have a medium-priority standard transmit queue. 1p2q2t, 1p3q1t and 1p2q1t ports have a strict-priority transmit queue in addition to the standard queues.

On 2q2t ports, the default PFC QoS configuration allocates a minimum of 80 percent of the total transmit queue size to the low-priority standard queue and a minimum of 20 percent to the high-priority standard queue.

On 1p2q2t, 1p3q1t, and 1p2q1t ports, the switch services traffic in the strict-priority queue before servicing the standard queues. When the switch is servicing a standard queue, after transmitting a packet, it 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.

On 1p2q2t ports, the default PFC QoS configuration allocates a minimum of 70 percent of the total transmit queue size to the low-priority standard queue, a minimum of 15 percent to the high-priority standard queue, and a minimum of 15 percent to the strict-priority queue.

On 1p3q1t ports, the transmit queue size is not configurable and is allocated equally among all queues.

On 1p2q1t ports, the default PFC QoS configuration allocates a minimum of 50 percent of the total transmit queue size to the low-priority standard queue, a minimum of 30 percent to the high-priority standard queue, and a minimum of 20 percent to the strict-priority queue.

Note Transmit-queue size is limited to the configured value (see the "Setting the Receive-Queue Size Ratio on a 1p1q0t or 1p1q8t Ingress LAN Ports" section), but any queue can use all available bandwidth (bandwidth is only available when there is no traffic in the other queues).

Scheduling and Congestion Avoidance

These sections describe scheduling and congestion avoidance:

•2q2t Ports

•1p2q2t Ports

•1p3q1t Ports

•1p2q1t Ports

Note The explanations in these sections use default values. You can configure many of the parameters (for more information, see the "Configuring PFC QoS" section). All ports of the same type use the same drop-threshold configuration.

2q2t Ports

For 2q2t ports, each transmit queue has two tail-drop thresholds that function as follows:

•Frames with CoS 0, 1, 2, or 3 go to the low-priority transmit queue (queue 1):

–Using transmit queue 1, tail-drop threshold 1, the switch drops frames with CoS 0 or 1 when the low-priority transmit-queue buffer is 80 percent full.

–Using transmit queue 1, tail-drop threshold 2, the switch drops frames with CoS 2 or 3 when the low-priority transmit-queue buffer is 100 percent full.

•Frames with CoS 4, 5, 6, or 7 go to the high-priority transmit queue (queue 2):

–Using transmit queue 2, tail-drop threshold 1, the switch drops frames with CoS 4 or 5 when the high-priority transmit-queue buffer is 80 percent full.

–Using transmit queue 2, tail-drop threshold 2, the switch drops frames with CoS 6 or 7 when the high-priority transmit-queue buffer is 100 percent full.

1p2q2t Ports

1p2q2t ports have a strict-priority queue and two standard transmit queues. The two standard transmit queues each have two WRED-drop thresholds.

•Frames with CoS 5 go to the strict-priority transmit queue (queue 3), where the switch drops frames only when the buffer is 100 percent full.

•Frames with CoS 0, 1, 2, or 3 go to the low-priority standard transmit queue (queue 1):

–Using standard transmit queue 1, WRED-drop threshold 1, the switch drops frames with CoS 0 or 1 when the low-priority transmit-queue buffer is 80 percent full.

–Using standard transmit queue 1, WRED-drop threshold 2, the switch drops frames with CoS 2 or 3 when the low-priority transmit-queue buffer is 100 percent full.

•Frames with CoS 4, 6, or 7 go to the high-priority standard transmit queue (queue 2):

–Using standard transmit queue 2, WRED-drop threshold 1, the switch drops frames with CoS 4 when the high-priority transmit-queue buffer is 80 percent full.

–Using standard transmit queue 2, WRED-drop threshold 2, the switch drops frames with CoS 6 or 7 when the high-priority transmit-queue buffer is 100 percent full.

1p3q1t Ports

1p3q1t ports have a strict-priority queue and three standard transmit queues. The standard transmit queues each have one WRED-drop threshold and one nonconfigurable tail-drop threshold.

•Frames with CoS 5 go to the strict-priority transmit queue (queue 4), where the switch drops frames only when the buffer is 100 percent full.

•Frames with CoS 0 and 1 go to the low-priority standard transmit queue (queue 1).

•Frames with CoS 2, 3, or 4 go to the medium-priority standard tr