Table Of Contents

Configuring QoS

Understanding How QoS Works

QoS Terminology

Flowcharts

QoS Feature Set Summary

Ethernet Ingress Port Features

Layer 3 Switching Engine Features

Layer 2 Switching Engine Features

Ethernet Egress Port Features

Single-Port ATM OC-12 Switching Module Features

Multilayer Switch Feature Card (MSFC or MSFC2)

Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification

Overview

Marking at Untrusted Ports

Marking at Trusted Ports

Ethernet Ingress Port Scheduling and Congestion Avoidance

Receive Queues

Ingress Scheduling

Ingress Congestion Avoidance

Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine

Classification, Marking, and Policing with a Layer 3 Switching Engine

Internal DSCP Values

ACLs

Named ACLs

Default ACLs

Marking Rules

Policers

PFC2 Policing Decisions

Attaching ACLs

Final Layer 3 Switching Engine CoS and ToS Values

Classification and Marking with a Layer 2 Switching Engine

Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking

Overview

Transmit Queues

Scheduling and Congestion Avoidance

Marking

QoS Statistics Data Export

QoS Default Configuration

Configuring QoS on the Switch

Enabling QoS

Enabling Port-Based or VLAN-Based QoS

Configuring the Trust State of a Port

Configuring the CoS Value for a Port

Creating Policers

Deleting Policers

Creating or Modifying ACLs

ACL Names

ACE Name, Marking Rule, Policing, and Filtering Syntax

Named IP ACLs

Modifying the Default IP ACL

Creating or Modifying Named IPX ACLs

Creating or Modifying Named MAC ACLs

Creating or Modifying the Default IPX and MAC ACLs

Deleting Named ACLs

Reverting to Default Values in Default ACLs

Discarding Uncommitted ACLs

Committing ACLs

Attaching ACLs to Interfaces

Detaching ACLs from Interfaces

Mapping a CoS Value to a Host Destination MAC Address/VLAN Pair

Deleting a CoS Value to a Host Destination MAC Address/VLAN Pair

Enabling or Disabling Microflow Policing of Bridged Traffic

Configuring Standard Receive-Queue Tail-Drop Thresholds

Configuring 2q2t Port Standard Transmit-Queue Tail-Drop Thresholds

Configuring Standard Queue WRED-Drop Thresholds

Allocating Bandwidth Between Standard Transmit Queues

Configuring the Receive-Queue Size Ratio

Configuring the Transmit-Queue Size Ratio

Mapping CoS Values to Drop Thresholds

Associating 1q4t/2q2t Ports

Associating 1q2t/1p2q2t and 1p1q4t/1p2q2t Ports

Associating 1p1q0t/1p3q1t Ports

Associating 1p1q8t/1p2q1t Ports

Reverting to CoS Map Defaults

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

Mapping DSCP Markdown Values

Displaying QoS Information

Displaying QoS Statistics

Reverting to QoS Defaults

Disabling QoS

Configuring COPS Support

Port ASICs

Understanding QoS Policy

Selecting COPS as the QoS Policy Source

Selecting Locally Configured QoS Policy

Enabling Use of Locally Configured QoS Policy

Assigning Port Roles

Removing Roles from Port ASICs

Deleting Roles

Configuring Policy Decision Point Servers

Deleting the PDP Server Configuration

Configuring the COPS Domain Name

Deleting the COPS Domain Name

Configuring the COPS Communications Parameters

Configuring RSVP Support

Enabling RSVP Support

Disabling RSVP Support

Enabling Participation in the DSBM Election

Disabling Participation in the DSBM Election

Configuring Policy Decision Point Servers

Deleting the PDP Server Configuration

Configuring RSVP Policy Timeout

Configuring RSVP Use of Local Policy

Configuring QoS Statistics Data Export

Enabling QoS Statistics Data Export Globally

Enabling Per-Port QoS Statistics Data Export

Enabling Per-Aggregate Policer QoS Statistics Data Export

Clearing the Aggregate Policer QoS Statistics

Setting the QoS Statistics Data Export Time Interval

Configuring the QoS Statistics Data Export Destination Host and UDP Port

Displaying QoS Statistics Information

Configuring QoS

---

This chapter describes how to configure quality of service (QoS) on the Catalyst 6500 series switches and includes the configuration information that is required to support Common Open Policy Service (COPS) and Resource ReSerVation Protocol (RSVP).

---

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

•For information on using automatic QoS, see "Using Automatic QoS."

---

You can configure QoS using one of the following:

•SNMP

•COPS protocol

•RSVP null service template and receiver proxy functionality

•Command-line interface (CLI)

This chapter consists of these sections:

•Understanding How QoS Works

•QoS Default Configuration

•Configuring QoS on the Switch

Understanding How QoS Works

---

Note•Throughout this publication and all Catalyst 6500 series documents, the term "QoS" refers to the QoS feature as implemented on the Catalyst 6500 series.

•Supervisor Engine 1 and Supervisor Engine 2 provide policing only for ingress traffic.

---

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.

The QoS feature on the Catalyst 6500 series switches selects network traffic, prioritizes it according to its relative importance, and provides priority-indexed treatment through congestion avoidance techniques. Implementing QoS in your network makes network performance more predictable and bandwidth utilization more effective.

QoS sets Layer 2 and Layer 3 values in network traffic to a configured value or to a value based on received Layer 2 or Layer 3 values. IP traffic retains the Layer 3 value when it leaves the switch.

These sections describe QoS:

•QoS Terminology

•Flowcharts

•QoS Feature Set Summary

•Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification

•Classification, Marking, and Policing with a Layer 3 Switching Engine

•Classification and Marking with a Layer 2 Switching Engine

•Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking

•QoS Statistics Data Export

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 that are carried in packets and frames:

–Layer 2 class of service (CoS) values 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 CoS values.

---

Note On ports that are configured as ISL trunks, all traffic is in ISL frames. On ports that are configured as 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 0 for low priority and 7 for high priority.

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

---

Note Layer 3 IP packets can carry either an IP precedence value or a DSCP value. QoS supports the use of either value, because DSCP values can be set equal to IP precedence values.

---

•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 traffic to a queue. QoS assigns traffic based on CoS values.

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

•Policing is the process by which the switch limits the bandwidth that is consumed by a flow of traffic. Policing can mark or drop traffic.

•Except where specifically differentiated, Layer 3 switching engine refers to either of the following:

–Supervisor Engine 2 with Layer 3 Switching Engine II (Policy Feature Card 2 or PFC2)

–Supervisor Engine 1 with Layer 3 Switching Engine WS-F6K-PFC (Policy Feature Card or PFC)

•Random early detection (RED) is a drop threshold algorithm.

•Weighted random early detection (WRED) is a drop threshold algorithm.

•Weighted round robin (WRR) is a dequeuing algorithm.

•Deficit weighted round robin (DWRR) is a dequeuing algorithm.

Flowcharts

Figure 43-1 shows how traffic flows through the QoS features; Figure 43-2 through Figure 43-7 show more details of the traffic flow through QoS features.

Figure 43-1 Traffic Flow Through QoS Features

---

Note•The PFC can provide Layer 3 switching for ingress WAN traffic. The PFC does not provide QoS for ingress WAN traffic. PFC QoS does not change the ToS byte in WAN traffic.

•Ingress LAN traffic that is Layer 3 switched does not go through the Multilayer Switch Feature Card (MSFC or MSFC2) and retains the CoS value that is assigned by the Layer 3 switching engine.

•Enter the show port capabilities command to see the queue structure of a port (for more information, see the "Receive Queues" section and the "Transmit Queues" section).

---

Figure 43-2 Ethernet ingress Port Classification, Marking, Scheduling, and Congestion Avoidance

Figure 43-3 Layer 3 Switching Engine Classification, Marking, and Policing

Figure 43-4 Layer 2 Switching Engine Classification and Marking

Figure 43-5 Multilayer Switch Feature Card Marking (MSFC and MSFC2)

Figure 43-6 Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking

Figure 43-7 Single-Port ATM OC-12 Switching Module Marking

QoS Feature Set Summary

The QoS feature set on your switch is determined by the switching engine on the supervisor engine. Enter the show module command for the supervisor engine to display your switching engine configuration. The display shows the "Sub-Type" to be one of the following:

•Supervisor Engine 2 (WS-X6K-SUP2-2GE) with Layer 3 Switching Engine II (WS-F6K-PFC2—Policy Feature Card 2 or PFC2)

•Supervisor Engine 1 (WS-X6K-SUP1A-2GE or WS-X6K-SUP1-2GE) with one of the following:

–Layer 3 Switching Engine (WS-F6K-PFC—Policy Feature Card or PFC)

–Layer 2 Switching Engine II (WS-F6020A)

–Layer 2 Switching Engine I (WS-F6020)

The Layer 3 Switching Engine WS-F6K-PFC and Layer 3 Switching Engine II support similar feature sets. The two Layer 2 switching engines support the same QoS feature set.

These sections describe the QoS feature sets:

•Ethernet Ingress Port Features

•Layer 3 Switching Engine Features

•Layer 2 Switching Engine Features

•Ethernet Egress Port Features

•Single-Port ATM OC-12 Switching Module Features

•Multilayer Switch Feature Card (MSFC or MSFC2)

Ethernet Ingress Port Features

With any switching engine, QoS supports classification, marking, scheduling, and congestion avoidance using Layer 2 CoS values at Ethernet ingress ports. Classification, marking, scheduling, and congestion avoidance at Ethernet ingress ports do not use or set Layer 3 IP precedence or DSCP values. With a Layer 3 switching engine, you can configure Ethernet ingress port trust states that can be used by the switching engine to set Layer 3 IP precedence or DSCP values and the Layer 2 CoS value. For more information, see the "Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification" section.

Layer 3 Switching Engine Features

With a Layer 3 switching engine, QoS supports classification, marking, and policing using IP, IPX, and Media Access Control (MAC) access control lists (ACLs). ACLs contain access control entries (ACEs) that specify Layer 2, 3, and 4 classification criteria, a marking rule, and policers. Marking sets the Layer 3 IP precedence or DSCP values and the Layer 2 CoS value to either received or configured Layer 2 or Layer 3 values. Policing uses bandwidth limits to either drop or mark nonconforming traffic. For more information, see the "Classification, Marking, and Policing with a Layer 3 Switching Engine" section.

During processing, a Layer 3 switching engine associates a DSCP value with all traffic, including non-IP traffic (for more information, see the "Internal DSCP Values" section).

Layer 2 Switching Engine Features

With a Layer 2 Switching Engine, QoS can classify traffic using Layer 2 destination MAC addresses, VLANs, and marking using Layer 2 CoS values. Classification and marking with a Layer 2 Switching Engine do not use or set Layer 3 IP precedence or DSCP values. For more information, see the "Classification and Marking with a Layer 2 Switching Engine" section.

Ethernet Egress Port Features

With any switching engine, QoS supports Ethernet egress port scheduling and congestion avoidance using Layer 2 CoS values. Ethernet egress port marking sets Layer 2 CoS values and, with a Layer 3 switching engine, Layer 3 DSCP values. For more information, see the "Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking" section.

Single-Port ATM OC-12 Switching Module Features

The ingress interface from a single-port ATM OC-12 switching module is untrusted, and QoS sets CoS to zero in all traffic received from it. With a Layer 3 switching engine, QoS can mark IP traffic that is transmitted to a single-port ATM OC-12 switching module with Layer 3 DSCP values.

Multilayer Switch Feature Card (MSFC or MSFC2)

QoS marks IP traffic that is transmitted to an MSFC with Layer 3 DSCP values. CoS is zero in all traffic that is sent from an MSFC to egress ports.

---

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

---

Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification

These sections describe Ethernet ingress port marking, scheduling, congestion avoidance, and classification:

•Overview

•Marking at Untrusted Ports

•Marking at Trusted Ports

•Ethernet Ingress Port Scheduling and Congestion Avoidance

•Receive Queues

•Ingress Scheduling

•Ingress Congestion Avoidance

•Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine

Overview

The trust state of an Ethernet port determines how it marks, schedules, and classifies received traffic, and whether or not congestion avoidance is implemented. You can configure the trust state of each port with one of these keywords:

•untrusted (default)

•trust-ipprec (Layer 3 switching engine only—not supported on 1q4t ports except Gigabit Ethernet)

•trust-dscp (Layer 3 switching engine only—not supported on 1q4t ports except Gigabit Ethernet)

•trust-cos

---

Note•1q4t ports (except Gigabit Ethernet) do not support the trust-ipprec and trust-dscp port keywords. You must configure a trust-ipprec or trust-dscp ACL that matches the ingress traffic to apply the trust-ipprec or trust-dscp trust state.

•On 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates receive queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to traffic. You must configure a trust-cos ACL that matches the ingress traffic to apply the trust-cos trust state.

---

For more information, see the "Configuring the Trust State of a Port" section.

In addition to the port configuration keywords listed above, with a Layer 3 switching engine, QoS uses trust-ipprec, trust-dscp, and trust-cos ACE keywords. Do not confuse the ACE keywords with the port keywords.

Ports that are configured with the untrusted keyword are called untrusted ports. Ports that are configured with the trust-ipprec, trust-dscp, or trust-cos keywords are called trusted ports. QoS implements ingress port congestion avoidance only on ports that are configured with the trust-cos keyword.

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

Marking at Untrusted Ports

QoS marks all frames that are received through untrusted ports with the port CoS value (the default is zero). QoS does not implement ingress port congestion avoidance on untrusted ports: the traffic goes directly to the switching engine.

Marking at Trusted Ports

When an ISL frame enters the switch through a trusted port, 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 port, QoS accepts the User Priority bits as a CoS value. QoS marks all traffic that is received in other frame types with the port CoS value.

The port CoS value is configurable for each Ethernet port (for more information, see the "Configuring the CoS Value for a Port" section).

Ethernet Ingress Port Scheduling and Congestion Avoidance

QoS does not implement ingress port congestion avoidance on ports that are configured with the untrusted, trust-ipprec, or trust-dscp keywords: the traffic goes directly to the switching engine.

QoS uses CoS-value-based receive-queue drop thresholds to avoid congestion in traffic entering the switch through a port that is configured with the trust-cos keyword (for more information, see the "Configuring the Trust State of a Port" section).

Receive Queues

Enter the show port capabilities command to see the queue structure of a port. The command displays one of the following:

•rx-(1q2t) indicates one standard queue with one configurable tail-drop threshold and one nonconfigurable tail-drop threshold.

•rx-(1q4t) indicates one standard queue with four configurable tail-drop thresholds.

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

•rx-(1p1q0t) indicates one strict-priority queue and one standard queue with a nonconfigurable threshold.

•rx-(1p1q8t) indicates one strict-priority queue and one standard queue with eight configurable WRED-drop thresholds (on 1p1q8t ports, the standard queue also has one nonconfigurable tail-drop threshold).

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

Ingress Scheduling

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

Ingress Congestion Avoidance

---

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

---

If a port is configured with the trust-cos keyword, QoS implements CoS-value-based receive-queue drop thresholds to avoid congestion in received traffic.

1q2t 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 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 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 as follows:

–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 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 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 a nonconfigurable tail-drop threshold that drops incoming frames when the standard 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 as follows:

–Using standard receive-queue 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 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 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 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 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 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 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 the CoS values that are mapped only to the queue. The switch uses WRED-drop thresholds for traffic carrying the CoS values that are mapped to the queue and a threshold. See the "1p1q8t Receive Queues" section.

---

Figure 43-8 shows the drop thresholds for a 1q4t port. Drop thresholds in other configurations function similarly.

Figure 43-8 Receive-Queue Drop Thresholds

Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine

You can use the untrusted, trust-ipprec, trust-dscp, and trust-cos port keywords to classify traffic on a per-port basis for a Layer 3 switching engine to mark.

The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine and are not supported on 1q4t ports except Gigabit Ethernet. On 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates receive-queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to traffic. You must configure the trust-cos ACL that matches the ingress traffic to apply the trust-cos trust state.

In addition to per-port classification, you can create ACEs that classify traffic on a per-packet basis (for IP and IPX traffic, see the "Named IP ACLs" section and the "Creating or Modifying Named IPX ACLs" section) or on a per-frame basis (for other traffic, see the "Creating or Modifying Named MAC ACLs" section), regardless of the port configuration (see the "Marking Rules" section).

To mark traffic in response to per-port classification, the traffic must match an ACE that contains the dscp ACE keyword (see the "Marking Rules" section). In their default configuration, the ACEs in the default ACLs contain the dscp ACE keyword. Table 43-1 lists the per-port classifications and the marking rules that they invoke.

Table 43-1 Marking Based on Per-Port Classification

Port Keyword	ACE Keyword	Marking Rule
untrusted	dscp	Set internal and egress DSCP as specified in the ACE.
trust-ipprec	dscp	For IP traffic, set internal and egress DSCP from the received Layer 3 IP precedence value. For other traffic, set internal and egress DSCP from the received or port Layer 2 CoS value. Note—With the trust-ipprec port keyword, QoS uses only the IP precedence bits. If traffic with a DSCP value enters the switch through a port that is configured with the trust-ipprec port keyword, the three most significant bits of the DSCP value are interpreted as an IP precedence value; QoS ignores the rest of the DSCP value.
trust-dscp	dscp	For IP traffic, set internal and egress DSCP from the received Layer 3 DSCP value. For other traffic, set internal and egress DSCP from the received or port Layer 2 CoS value.
trust-cos	dscp	Set internal and egress DSCP from the received or port Layer 2 CoS value.

QoS uses configurable mapping tables to set internal and egress DSCP, which is a 6-bit value, from CoS and IP precedence, which are 3-bit values (for more information, see the "Internal DSCP Values" section and the "Configuring DSCP Value Maps" section).

Classification, Marking, and Policing with a Layer 3 Switching Engine

---

Note With a Layer 3 switching engine, the Catalyst 6500 series switches provide QoS only for the following frame types: Ethernet_II, Ethernet_802.3, Ethernet_802.2, and Ethernet_SNAP.

---

These sections describe classification, marking, and policing with a Layer 3 switching engine:

•Internal DSCP Values

•ACLs

•Named ACLs

•Default ACLs

•Marking Rules

•Policers

•PFC2 Policing Decisions

•Attaching ACLs

•Final Layer 3 Switching Engine CoS and ToS Values

---

Note Classification with a Layer 3 switching engine uses Layer 2, 3, and 4 values. Marking with a Layer 3 switching engine 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, the priority of all traffic (including non-IP traffic) is represented with an internal DSCP value. QoS derives the internal DSCP value from the following:

•For trust-cos traffic, from received or port Layer 2 CoS values (traffic from an untrusted port has the port CoS value and if traffic from an untrusted port matches a trust-cos ACL, QoS derives the internal DSCP value from the port CoS value)

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

•For trust-dscp traffic, from received DSCP values

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

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

---

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

---

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, QoS creates a ToS byte from the internal DSCP value (which you can set equal to an IP precedence 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.

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

ACLs

QoS uses ACLs that contain ACEs. The ACEs specify classification criteria, a marking rule, and policers. QoS compares received traffic to the ACEs in ACLs until a match occurs. When the traffic matches the classification criteria in an ACE, QoS marks and polices the packet as specified in the ACE and makes no further comparisons.

There are three ACL types: IP, and with a Layer 3 switching engine, IPX and MAC. QoS compares traffic of each type (IP, IPX, and MAC) only to the corresponding ACL type (see Table 43-2).

Table 43-2 Supported Ethertype Field Values

ACL Type	Ethertype Field Value	Protocol
IP	0x0800	IP
IPX	0x8137 and 0x8138	IPX
MAC1	0x0600 and 0x0601	XNS
	0x0BAD and 0x0BAF	Banyan VINES
	0x6000-0x6009 and 0x8038-0x8042	DECnet
	0x809b and 0x80f3	AppleTalk

1 QoS MAC ACLs that do not include an ethertype parameter match traffic with any value in the ethertype field, which allows MAC-level QoS to be applied to any traffic except IP and IPX.

QoS supports user-created named ACLs, each containing an ordered list of ACEs, and user-configurable default ACLs, each containing a single ACE.

Named ACLs

You create a named ACL when you enter an ACE with a new ACL name. You add an ACE to an existing ACL when you enter an ACE with the name of the existing ACL.

You can specify the classification criteria for each ACE in a named ACL. The classification criteria can be specific values or wildcards (for more information, see the "Creating or Modifying ACLs" section).

These sections describe the classification criteria that can be specified in a named ACL:

•IP ACE Layer 3 Classification Criteria

•IP ACE Layer 4 Protocol Classification Criteria

•IP ACE Layer 4 TCP Classification Criteria

•IP ACE Layer 4 UDP Classification Criteria

•IP ACE Layer 4 ICMP Classification Criteria

•IP ACE Layer 4 IGMP Classification Criteria

•IPX ACE Classification Criteria

•MAC ACE Layer 2 Classification Criteria

IP ACE Layer 3 Classification Criteria

You can create IP ACEs that match traffic with specific Layer 3 values by including these Layer 3 parameters (see the "Named IP ACLs" section):

•IP source address and mask, entered as specific values or with the any keyword or with the host keyword and a host address.

•IP destination address and mask, entered as specific values or with the any keyword or with the host keyword and a host address.

•DSCP value (0-63) or IP precedence that is specified with a numeric value (0-7) or these keywords:

–Network (IP precedence 7)

–Internet (IP precedence 6)

–Critical (IP precedence 5)

–Flash-override (IP precedence 4)

–Flash (IP precedence 3)

–Immediate (IP precedence 2)

–Priority (IP precedence 1)

–Routine (IP precedence 0)

---

Note IP ACEs that do not include a DSCP or IP precedence value parameter match all DSCP or IP precedence values.

---

IP ACE Layer 4 Protocol Classification Criteria

You can create IP ACEs that match specific Layer 4 protocol traffic by including a Layer 4 protocol parameter (see the "IP ACLs for Other Layer 4 Protocols" section). You can specify the protocol numerically (0-255) or with these keywords: ahp (51), eigrp (88), esp (50), gre (47), igrp (9), icmp (1), igmp (2), igrp (9), ip (0), ipinip (4), nos (94), ospf (89), pcp (108), pim (103), tcp (6), or udp (17).

---

Note IP ACEs that do not include a Layer 4 protocol parameter or that include the ip keyword match all IP traffic.

---

IP ACE Layer 4 TCP Classification Criteria

You can create Transmission Control Protocol (TCP) ACEs that match traffic for specific TCP ports by including TCP source and/or destination port parameters (for more information, see the "IP ACEs for TCP Traffic" section). You can specify TCP port parameters numerically (0-65535) or with these keywords:

Keyword	Port		Keyword	Port		Keyword	Port		Keyword	Port
bgp	179		ftp	21		lpd	515		telnet	23
chargen	19		ftp-data	20		nntp	119		time	37
daytime	13		gopher	70		pop2	109		uucp	540
discard	9		hostname	101		pop3	110		whois	43
domain	53		irc	194		smtp	25		www	80
echo	7		klogin	543		sunrpc	111
finger	79		kshell	544		tacacs	49

---

Note TCP ACEs that do not include a Layer 4 TCP port parameter match all TCP traffic.

---

IP ACE Layer 4 UDP Classification Criteria

You can create User Datagram Protocol (UDP) ACEs that match traffic for specific UDP source and/or destination ports by including UDP port parameters (for more information, see the "IP ACEs for UDP Traffic" section). You can specify UDP port parameters numerically (0-65535) or with these keywords:

Keyword	Port		Keyword	Port		Keyword	Port		Keyword	Port
biff	512		echo	7		rip	520		talk	517
bootpc	68		mobile-ip	434		snmp	161		tftp	69
bootps	67		nameserver	42		snmptrap	162		time	37
discard	9		netbios-dgm	138		sunrpc	111		who	513
dns	53		netbios-ns	137		syslog	514		xdmcp	177
dnsix	195		ntp	123		tacacs	49

---

Note UDP ACEs that do not include a Layer 4 UDP port parameter match all UDP traffic.

---

IP ACE Layer 4 ICMP Classification Criteria

You can create Internet Control Management Protocol (ICMP) ACEs that match traffic containing specific ICMP messages by including ICMP types and optionally, ICMP codes (for more information, see the "IP ACEs for ICMP Traffic" section). You can specify ICMP types and codes numerically (0-255) or with these keywords:

Keyword	Type	Code	Keyword	Type	Code
administratively-prohibited	3	13	net-tos-unreachable	3	11
alternate-address1	6	—	net-unreachable	3	0
conversion-error	31	0	network-unknown	3	6
dod-host-prohibited	3	10	no-room-for-option	12	2
dod-net-prohibited	3	9	option-missing	12	1
echo	8	0	packet-too-big	3	4
echo-reply	0	0	parameter-problem	12	0
general-parameter-problem1	12	—	port-unreachable	3	3
host-isolated	3	8	precedence-unreachable	3	15
host-precedence-unreachable	3	14	protocol-unreachable	3	2
host-redirect	5	1	reassembly-timeout	11	1
host-tos-redirect	5	3	redirect1	5	—
host-tos-unreachable	3	12	router-advertisement	9	0
host-unknown	3	7	router-solicitation	10	0
host-unreachable	3	1	source-quench	4	0
information-reply	16	0	source-route-failed	3	5
information-request	15	0	time-exceeded1	11	—
mask-reply	18	0	timestamp-reply	14	0
mask-request	17	0	timestamp-request	13	0
mobile-redirect	32	0	traceroute	30	0
net-redirect	5	0	ttl-exceeded	11	0
net-tos-redirect	5	2	unreachable1