Catalyst 6500 Series Software Configuration Guide, 8.7 - Configuring QoS [Cisco Catalyst 6500 Series Switches]

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, MSFC2, or MSFC3)

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

PFC3 Policing Decisions

Attaching ACLs

PFC3 Egress DSCP Mutation

Final Layer 3 Switching Engine CoS and ToS Values

Classification and Marking on a Supervisor Engine 1 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

QoS Configuration Guidelines and Restrictions

Configuring QoS on the Switch

Enabling QoS

Enabling DSCP Rewrite

Disabling DSCP Rewrite

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 ACLs

Creating or Modifying the Named IPX ACLs

Creating or Modifying the Named MAC ACLs

Creating or Modifying the Default IPX and MAC ACLs

Deleting a Named ACL

Reverting to the Default Values in the Default ACLs

Discarding an Uncommitted ACL

Committing an ACL

Attaching an ACL to an Interface

Detaching an ACL from an Interface

Configuring PFC3 Egress DSCP Mutation

Configuring a DSCP Mutation Map

Clearing a Configured DSCP Mutation Map

Applying a DSCP Mutation Map to a VLAN

Clearing a DSCP Mutation Map from a VLAN

Configuring CoS-to-CoS Maps on 802.1Q Tunnel Ports

Defining a CoS-to CoS Map

Enabling a CoS-to CoS Map on a Port

Clearing a CoS-to-CoS Map

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 the Standard Receive-Queue Tail-Drop Thresholds

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

Configuring the Standard Queue WRED-Drop Thresholds

Allocating Bandwidth Between the Standard Transmit Queues

Configuring the Receive-Queue Size Ratio

Configuring the Transmit-Queue Size Ratio

Mapping the CoS Values to the Drop Thresholds

Associating the 1q4t/2q2t Ports

Associating the 1q8t, 1q2t/1p2q2t, and 1p1q4t/1p2q2t Ports

Associating the 1p1q0t/1p3q1t Ports

Associating the 1p1q8t/1p2q1t, 1p3q8t, and 1p7q8t Ports

Reverting to the CoS Map Default

Configuring the DSCP Value Maps

Mapping the Received CoS Values to the Internal DSCP Values

Mapping the Received IP Precedence Values to the Internal DSCP Values

Mapping the Internal DSCP Values to the Egress CoS Values

Mapping the DSCP Markdown Values

Displaying QoS Information

Displaying the QoS Statistics

Reverting to the QoS Defaults

Disabling QoS

Configuring COPS Support

Port ASICs

Understanding QoS Policy

Selecting COPS as the QoS Policy Source

Selecting the Locally Configured QoS Policy

Enabling Use of the Locally Configured QoS Policy

Assigning a Port Role

Removing a Role from the Port ASICs

Deleting a Role

Configuring the 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 the Participation in the DSBM Election

Disabling the Participation in the DSBM Election

Configuring the Policy Decision Point Servers

Deleting the PDP Server Configuration

Configuring the RSVP Policy Timeout

Configuring the 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 the QoS Statistics

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 that are used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.

•For information on using automatic QoS, see Chapter 53, "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 publications, the term QoS refers to the QoS feature as implemented on the Catalyst 6500 series switch.

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 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. QoS makes network performance more predictable and bandwidth utilization more effective.

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

With PFC3, you can configure QoS for both the ingress and egress traffic. You can configure QoS per-port or per-VLAN for the ingress traffic. You can configure QoS only per VLAN for the egress traffic.

With other hardware, you can configure QoS per port or per VLAN for the ingress traffic.

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 on a Supervisor Engine 1 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. The Layer 2 frames carry the Layer 3 packets.

•Labels are prioritization values that are carried in the packets and the frames:

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

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

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

The other frame types cannot carry the CoS values.

Note On the ports that are configured as ISL trunks, all traffic is in ISL frames. On the ports that are configured as 802.1Q trunks, all traffic is in the 802.1Q frames except for the 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 the IP precedence. The 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) defines the six most significant bits of the 1-byte ToS field as the DSCP. The priority that is represented by a particular DSCP value is configurable. The DSCP values range between 0 and 63 (for more information, see the "Configuring the DSCP Value Maps" section).

Note The 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 the IP precedence values.

•Classification is the selection of traffic.

•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 the Layer 2 CoS values.

•Scheduling is the assignment of traffic to a queue. QoS assigns the traffic that is based on the CoS values.

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

•Shaped round robin (SRR) is a dequeuing 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 52-1 shows how traffic flows through the QoS features; Figure 52-2 through Figure 52-9 show more details of the traffic flow through QoS features.

Figure 52-1 Traffic Flow Through QoS Features with PFC3

Note PFC3 can provide Layer 3 switching for the WAN traffic. PFC3 can provide QoS for the ingress WAN traffic that is forwarded in the software by MSFC3. PFC3 can provide QoS for the egress WAN traffic that entered the switch through a LAN port or that was forwarded in the software by MSFC3.

Figure 52-2 Traffic Flow Through QoS Features with PFC and PFC2

Note•PFC or PFC2 can provide Layer 3 switching for the ingress WAN traffic.

•PFC or PFC2 does not provide QoS for the WAN traffic. With PFC or PFC2, PFC QoS does not change the ToS byte in the 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 52-3 Ethernet ingress Port Classification, Marking, Scheduling, and Congestion Avoidance

Figure 52-4 PFC3 Classification, Marking, and Policing

Figure 52-5 PFC and PFC2 Classification, Marking, and Policing

Figure 52-6 Layer 2 Switching Engine Classification and Marking

Figure 52-7 Multilayer Switch Feature Card Marking (MSFC and MSFC2)

Figure 52-8 Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking

Figure 52-9 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 32 (WS-SUP32-GE-3B) with Policy Feature Card 3B (PFC3B/PFC3BXL)

•Supervisor Engine 720 (WS-SUP720) with PFC3A/PFC3B/PFC3BXL

•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 (WS-F6K-PFC2) support similar feature sets. The two Layer 2 switching engines support the same QoS feature set.

In addition to the features that are supported by the other two Layer 3 switching engines, PFC3A supports these features:

•Egress QoS

•Egress DSCP mutation

•Optional egress DSCP rewrite

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, MSFC2, or MSFC3)

Ethernet Ingress Port Features

With any switching engine, QoS supports classification, marking, scheduling, and congestion avoidance using the Layer 2 CoS values at the Ethernet ingress ports. Classification, marking, scheduling, and congestion avoidance at the Ethernet ingress ports do not use or set the Layer 3 IP precedence or DSCP values. With a Layer 3 switching engine, you can configure the Ethernet ingress port trust states that can be used by the switching engine to set the 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 PFC3A/PFC3B/PFC3BXL, PFC2, or PFC, QoS supports classification, marking, and policing using the access control lists (ACLs).

PFC3A/PFC3B/PFC3BXL provides QoS for the ingress and egress traffic. PFC2 and PFC provide QoS only for the ingress traffic.

With PFC3, QoS supports map-based egress DSCP mutation, which allows you to remark the egress traffic after it has been subjected to a policing rule, and the option to preserve the received DSCP in the egress traffic.

The ACLs contain the access control entries (ACEs) that specify the 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 the received or configured Layer 2 or Layer 3 values. Policing uses bandwidth limits to either drop or mark the 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 the Layer 2 destination MAC addresses, VLANs, and marking using the Layer 2 CoS values. Classification and marking with a Layer 2 Switching Engine do not use or set the Layer 3 IP precedence or DSCP values. For more information, see the "Classification and Marking on a Supervisor Engine 1 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 the Layer 2 CoS values. Ethernet egress port marking sets the Layer 2 CoS values and, with a Layer 3 switching engine, the 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 that is received from it. With a Layer 3 switching engine, QoS can mark the IP traffic that is transmitted to a single-port ATM OC-12 switching module with the Layer 3 DSCP values.

Multilayer Switch Feature Card (MSFC, MSFC2, or MSFC3)

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

Note The 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 the 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 the 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 On 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates the receive queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to the traffic. You must configure the 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 that are listed above, with a Layer 3 switching engine, QoS uses the trust-ipprec, trust-dscp, and trust-cos ACE keywords. Do not confuse the ACE keywords with the port keywords.

The ports that are configured with the untrusted keyword are called "untrusted ports." The 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 the ports that are configured with the trust-cos keyword.

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

Marking at Untrusted Ports

QoS marks all frames that are received through the untrusted ports with the port CoS value (the default is zero). QoS does not implement ingress port congestion avoidance on the 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 the 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 the ports that are configured with the untrusted, trust-ipprec, or trust-dscp keywords. The traffic goes directly to the switching engine.

QoS uses the CoS-value-based receive-queue drop thresholds to avoid congestion in the traffic that is 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-(1q8t) indicates one standard queue with eight configurable tail-drop thresholds.

•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 the 1p1q8t ports, the standard queue also has one nonconfigurable tail-drop threshold).

Strict-priority queues are serviced in preference to other queues. QoS services the traffic in a strict-priority queue before servicing the standard queue. When QoS services the standard queue, after receiving a packet, it checks for the traffic in the strict-priority queue. If QoS detects the traffic in the strict-priority queue, it suspends its service of the standard queue and completes the service of all traffic in the strict-priority queue before returning to the standard queue.

Ingress Scheduling

QoS schedules the traffic through the receive queues based on the CoS values. In the default configuration, PFC QoS assigns all traffic with CoS 5 to the strict-priority queue (if present); PFC QoS assigns all other traffic to the standard queue. In the absence of a strict-priority queue, PFC QoS assigns all traffic to the standard queues.

Ingress Congestion Avoidance

If a port is configured with the trust-cos keyword, QoS implements CoS-value-based receive-queue drop thresholds to avoid congestion in the received traffic. See the "QoS Default Configuration" section for the default CoS-to-threshold mapping.

Note For 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 the traffic carrying the CoS values that are mapped only to the queue. The switch uses the WRED-drop thresholds for the traffic carrying the CoS values that are mapped to the queue and a threshold. For more information, see the "1p1q8t Receive Queues" section.

Figure 52-10 shows the drop thresholds for a 1q4t port. The drop thresholds in the other configurations function similarly.

Figure 52-10 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 the 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 the 1q4t ports except Gigabit Ethernet. On the 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates the receive-queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to the traffic. You must configure the trust-cos ACL that matches the ingress traffic to apply the trust-cos trust state.

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

To mark the 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 52-1 lists the per-port classifications and the marking rules that they invoke.

Table 52-1 Marking Based on Per-Port Classification

Port Keyword

ACE Keyword

Marking Rule

untrusted

dscp

Set the internal and egress DSCP as specified in the ACE.

trust-ipprec

dscp

For the IP traffic, set the internal and egress DSCP from the received Layer 3 IP precedence value. For the other traffic, set the 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 the 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 the IP traffic, set the internal and egress DSCP from the received Layer 3 DSCP value. For other traffic, set the internal and egress DSCP from the received or port Layer 2 CoS value.

trust-cos

dscp

Set the internal and egress DSCP from the received or port Layer 2 CoS value.

QoS uses the configurable mapping tables to set the internal and egress DSCP, which is a 6-bit value, from the CoS and IP precedence, which are 3-bit values (for more information, see the "Internal DSCP Values" section and the "Configuring the 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

•PFC3 Policing Decisions

•Attaching ACLs

•PFC3 Egress DSCP Mutation

•Final Layer 3 Switching Engine CoS and ToS Values

Note Classification with a Layer 3 switching engine uses the Layer 2, 3, and 4 values. Marking with a Layer 3 switching engine uses the Layer 2 CoS values and the 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 the trust-cos traffic, from the received or port Layer 2 CoS values (the traffic from an untrusted port has the port CoS value and if the traffic from an untrusted port matches a trust-cos ACL, QoS derives the internal DSCP value from the port CoS value)

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

•For the trust-dscp traffic, from the received DSCP values

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

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

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

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

Egress DSCP and CoS Sources

For the 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 the IP packets. For the 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 the traffic (see the "Mapping the Internal DSCP Values to the Egress CoS Values" section). QoS sends the CoS value to the Ethernet egress ports for use in scheduling and to be written into the ISL and 802.1Q frames.

ACLs

QoS uses the ACLs that contain the ACEs. The ACEs specify the classification criteria, a marking rule, and the policers. QoS compares the received traffic to the ACEs in the 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 the traffic of each type (IP, IPX, and MAC) only to the corresponding ACL type (see Table 52-2).

Table 52-2 Supported EtherType Field Values

ACL Type

EtherType Field Value

Protocol

IP

0x0800

IP

IPX ¹

0x8137 and 0x8138

IPX

MAC²

0x0600 and 0x0601

XNS

0x0BAD and 0x0BAF

Banyan VINES

0x6000-0x6009 and 0x8038-0x8042

DECnet

0x809b and 0x80f3

AppleTalk

¹The PFC3 does not provide QoS for the IPX traffic.

²The QoS MAC ACLs that do not include an EtherType parameter match the 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 the user-created named ACLs, each containing an ordered list of ACEs, and the 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 the IP ACEs that match the traffic with the 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 The 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 the IP ACEs that match the 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 The 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 the Transmission Control Protocol (TCP) ACEs that match the traffic for the specific TCP ports by including the TCP source and/or destination port parameters (for more information, see the "IP ACEs for TCP Traffic" section).

You can specify the 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 The 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 the User Datagram Protocol (UDP) ACEs that match the traffic for specific UDP source and/or destination ports by including the UDP port parameters. For more information, see the "IP ACEs for UDP Traffic" section.

You can specify the 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 The 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 the Internet Control Management Protocol (ICMP) ACEs that match the traffic containing specific ICMP messages by including the ICMP types and optionally, the ICMP codes. For more information, see the "IP ACEs for ICMP Traffic" section.

You can specify the 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-address¹

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-problem¹

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

3

—

¹Matches all code values

Note The ICMP ACEs with only a Layer 4 ICMP type parameter match all code values for that type value. The ICMP ACEs that do not include any Layer 4 ICMP type and code parameters match all ICMP traffic.

IP ACE Layer 4 IGMP Classification Criteria

You can create the IGMP ACEs that match the traffic containing the specific IGMP messages by including an IGMP type parameter (for more information, see the "IP ACEs for IGMP Traffic" section). You can specify the IGMP type numerically (0-255) or with these keywords: host-query (1), host-report (2), dvmrp (3), pim (4), or trace (5).

Note•QoS supports multicast traffic when IGMP snooping is enabled.

•QoS does not support the IGMP traffic when IGMP snooping is enabled.

•QoS supports IGMP classification using version 1 four-bit Type fields.

•The IGMP ACEs that do not include a Layer 4 IGMP type parameter match all IGMP traffic.

IPX ACE Classification Criteria

Note PFC3 does not provide QoS for the IPX traffic. See the "MAC ACE Layer 2 Classification Criteria" section for information about how to use MAC ACLs to filter IPX traffic.

You can create the IPX ACEs that match the specific IPX traffic by including these parameters (for more information, see the "Creating or Modifying the Named IPX ACLs" section):

•IPX source network (-1 matches any network number)

•Protocol, which can be specified numerically (0-255) or with these keywords: any, ncp (17), netbios (20), rip (1), sap (4), spx (5)

•IPX ACEs support the following optional parameters:

–IPX destination network (-1 matches any network number)

–If you specify an IPX destination network, the IPX ACEs support the following optional parameters: an IPX destination network mask (-1 matches any network number), an IPX destination node, and an IPX destination node mask

MAC ACE Layer 2 Classification Criteria

You can create the MAC ACEs that match the specific Ethernet traffic by including these Layer 2 parameters (for more information, see the "Creating or Modifying the Named MAC ACLs" section):

•Ethernet source and destination addresses and masks, entered as specific values or with the any keyword or with the host keyword and a host Ethernet address

•Optionally, an EtherType parameter from this list:

–0x809B (or ethertalk)

–0x80F3 (or aarp)

–0x6001 (or dec-mop-dump)

–0x6002 (or dec-mop-remote-console)

–0x6003 (or dec-phase-iv)

–0x6004 (or dec-lat)

–0x6005 (or dec-diagnostic-protocol)

–0x6007 (or dec-lavc-sca)

–0x6008 (or dec-amber)

–0x6009 (or dec-mumps)

–0x8038 (or dec-lanbridge)

–0x8039 (or dec-dsm)

–0x8040 (or dec-netbios)

–0x8041 (or dec-msdos)

–0x8042 (no keyword)

–0x0BAD (no keyword)

–0x0baf (or banyan-vines-echo)

–0x0600 (or xerox-ns-idp)

•Optionally with PFC3A, an EtherType parameter from this list:

–0x8137 (or ipx-arpa)

–0xffff for non-ARPA IPX

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

Default ACLs

There are three default ACLs, one each for IP, and with a Layer 3 switching engine, IPX and MAC traffic. Each ACL has a single ACE that has a configurable marking rule and configurable policers. The default ACLs have nonconfigurable classification criteria that matches all traffic. QoS compares any traffic with a supported EtherType field value that does not match a named ACL to the default ACLs. The unmatched IP traffic matches the default IP ACL. The unmatched IPX traffic matches the default IPX ACL. The unmatched Ethernet traffic matches the default MAC ACL.

Note All traffic matches an ACE in an ACL, either an ACE in a named ACL or one of the default ACLs, because the default ACLs match all traffic.

Marking Rules

Note PFC2 cannot not mark IPX or MAC traffic. PFC3 does not provide QoS for IPX traffic.

The marking rules specify how QoS marks the traffic when the traffic matches the filtering parameters in an ACE (see the "ACE Name, Marking Rule, Policing, and Filtering Syntax" section). QoS supports four marking rules that are specified with the following four ACE keywords: trust-dscp, trust-ipprec, trust-cos, and dscp. Each ACE contains one of the keywords.

The marking rules are as follows:

•trust-dscp (IP ACLs only)—Instructs QoS to set the internal and egress DSCP from the received DSCP values (see the "Internal DSCP Values" section).

•trust-ipprec (IP ACLs only)—Instructs QoS to set the internal and egress DSCP from the received IP precedence values.

Note With the trust-ipprec port keyword, QoS uses only the IP precedence bits. If the 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-cos (all ACLs except IPX and MAC with PFC2 and IPX with PFC3)—Instructs QoS to set the internal and egress DSCP from the received or port CoS values. In the traffic from the ports that are configured with the trust-cos keyword, QoS uses the CoS value that is received in the ISL and 802.1Q frames; in all other cases, QoS uses the CoS value that is configured on the port (default is zero).

•dscp (all ACLs except IPX and MAC with PFC2 and IPX with PFC3)—Instructs QoS to mark the traffic as indicated by the port trust keywords:

–In the IP traffic from the ingress ports that are configured with the trust-dscp port keyword, the dscp ACE keyword instructs QoS to set the internal and egress DSCP values from the received DSCP values. In the non-IP traffic, QoS sets the DSCP from the received or port CoS value.

–In the IP traffic from the ingress ports that are configured with the trust-ipprec port keyword, the dscp ACE keyword instructs QoS to set the internal and egress DSCP values from the received IP precedence values. In the non-IP traffic, QoS sets the DSCP value from the received or port CoS value.

–In the traffic from the ingress ports that are configured with the trust-cos port keyword, the dscp ACE keyword instructs QoS to set the internal and egress DSCP values from the received or port CoS values.

–In the traffic from the ingress ports that are configured with the untrusted port keyword, the dscp ACE keyword instructs QoS to set the internal and egress DSCP values from the DSCP value in the ACE.

Note The default configuration of the ACEs in the default ACLs contains the dscp ACE keyword, which supports the per-port classification of the traffic. With the default values, the ACEs in the default ACLs apply DSCP zero to the traffic from the ingress ports that are configured with the untrusted port keyword.

QoS uses the configurable mapping tables to set the DSCP value, which is 6 bits, from the CoS and IP precedence, which are 3-bit values (for more information, see the "Mapping the Received CoS Values to the Internal DSCP Values" section and the "Mapping the Received IP Precedence Values to the Internal DSCP Values" section).

Policers

You can create the named policers that specify the bandwidth utilization limits, which you can apply to the traffic by including the policer name in an ACE (for more information, see the "Creating Policers" section).

Policing uses a token bucket scheme. As the packets arrive, the packet size in bytes is added to the bucket level. Every 0.25 ms, a value equal to the token rate is subtracted from the bucket level.

You specify the bandwidth utilization limits as an average rate and a maximum burst size. The packets that exceed these limits are "out of profile." The traffic is in profile as long as it flows in at an average rate and never bursts beyond the burst size.

With PFC and PFC2, the policing rates use the Layer 3 packet size. With PFC3, the policing rates use the Layer 2 frame size.

In each policer, you specify if the 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 the out-of-profile packets do not retain their original priority, they are not counted as part of the bandwidth that is consumed by the in-profile packets.

For all policers, QoS uses a configurable table that maps the received DSCP values to the marked-down DSCP values (for more information, see the "Mapping the DSCP Markdown Values" section). When the markdown occurs, QoS gets the marked-down DSCP value from the table. You cannot specify a marked-down DSCP value in the individual policers.

Note By default, the markdown table is configured so that no markdown occurs; the marked-down DSCP values are equal to the received DSCP values. To enable the markdown, configure the table appropriately for your network.

You give each policer a unique name when you create it and then use the name to include the policer in an ACE. The same policer can be used in multiple ACEs.

You can create these policers:

•Microflow—QoS applies the bandwidth limit that is specified in a microflow policer separately to each flow that matches any ACEs that use that particular microflow policer. You can create up to 63 microflow policers.

•Aggregate—QoS applies the bandwidth limits that are specified in an aggregate policer cumulatively to all flows that match any ACEs that use that particular aggregate policer. You can create up to 1023 aggregate policers.

•With PFC2 and PFC3A, you can specify a dual rate aggregate policer with a normal rate and an excess rate:

–Normal rate—The packets exceeding this rate are marked down.

–Excess rate—The packets exceeding this rate are either marked down or dropped as specified by the drop indication flag.

Note The drop indication flag applies to the excess rate policer and cannot be set for the normal rate policer. To achieve the effect of a drop indication flag for the normal rate aggregate policer, set the excess rate equal to the normal rate and set the drop indication flag. Alternatively, you can set the normal rate without specifying an excess rate, which automatically sets the excess rate to the normal rate when the drop indicator flag is on.

You can include both a microflow policer and an aggregate policer in each ACE to police a flow that is based on both its own bandwidth utilization and on its bandwidth utilization combined with that of the other flows.

For example, you could create a microflow policer named "group_individual" with the bandwidth limits that are suitable for the flows of the individuals in a group, and you could create an aggregate policer named "group_all" with the bandwidth limits that are suitable for the group as a whole. You could include both policers in the ACEs that match the group's traffic. The combination would affect the individuals separately and the group cumulatively.

For the ACEs that include both a microflow policer and an aggregate policer, 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, QoS applies a new DSCP value.

Follow these guidelines when creating policers:

•You can include a microflow policer in the IP ACEs. You cannot include a microflow policer in the IPX or MAC ACEs. The IPX and MAC ACEs support only the aggregate policers.

•By default, the microflow policers do not affect the bridged traffic. To enable microflow policing of the bridged traffic, enter the set qos bridged-microflow-policing command (for more information, see the "Enabling or Disabling Microflow Policing of Bridged Traffic" section).

•With a Layer 3 Switching Engine II, to do any microflow policing, you must enable microflow policing of the bridged traffic.

•With an MSFC, QoS does not apply the microflow policers to the Multilayer Switching (MLS) candidate frames (MSFC2 does not use candidate and enabler frames).

•To avoid inconsistent results, all ACEs that include the same aggregate policer must use the same ACE keyword: trust-dscp, trust-ipprec, trust-cos, or dscp. If the ACE uses the dscp keyword, all traffic that matches the ACE must come through the ports that are configured with the same port keyword: trust-dscp, trust-ipprec, trust-cos, or untrusted. If the ACL is attached to a VLAN, you must configure all ports in the VLAN with the same port keyword.

PFC2 Policing Decisions

With PFC2, the policing decision consists of two levels:

•Normal Police Level—Set if either the microflow policer or the aggregate normal rate policer returns an out-of-profile decision.

•Excess Police Level—Set if the aggregate excess rate policer returns an out-of-profile decision.

The packets are dropped if the excess rate aggregate policer returns an out-of-profile decision and the drop indication flag is set or if the microflow policer returns an out-of-profile decision and the drop indication flag is set.

If an excess police level is set, the excess DSCP mapping is used to replace the original DSCP value with a marked-down value. If only a normal police level is set, the normal DSCP mapping is used. The excess police level has precedence for selecting the mapping rules when both police levels are set because the excess police level represents the worst out-of-profile transgression.

PFC3 Policing Decisions

In addition to PFC2 policing decisions, PFC3 supports egress QoS. These sections describe the PFC3 policing decisions:

•Policing Hardware-Forwarded LAN Traffic

•Policing Software-Forwarded LAN Traffic

•Policing Software-Forwarded WAN Traffic

Policing Hardware-Forwarded LAN Traffic

The hardware-forwarded LAN traffic (traffic that is forwarded by PFC3) can be subject to both an ingress and an egress policing rule. When the LAN traffic is subject to both an ingress and an egress policing rule, QoS evaluates both the rules simultaneously and applies the most severe rule. Because the policing rules are evaluated simultaneously, the markdown from an ingress policing rule is never used as the basis for the egress policing markdown.

Policing Software-Forwarded LAN Traffic

The software-forwarded LAN traffic (LAN traffic that is forwarded in the software by the MSFC) can be subject to both an ingress and an egress policing rule. When the software-forwarded traffic is subject to both an ingress and an egress policing rule, QoS evaluates the rules sequentially. The markdown from an ingress policing rule can be the basis for the egress policing markdown.

Policing Software-Forwarded WAN Traffic

PFC3 can provide egress QoS for the software-forwarded WAN traffic. The software-forwarded WAN traffic is subject only to an egress policing rule.

Attaching ACLs

You can configure each port for either port-based QoS (default) or VLAN-based QoS (see the "Enabling Port-Based or VLAN-Based QoS" section) and attach the ACLs to the selected interface (see the "Attaching an ACL to an Interface" section). You can attach up to three named ACLs, one of each type (IP, IPX, and Ethernet) to each port and VLAN.

On the ports that are configured for VLAN-based QoS, you can attach the named ACLs to the port's VLAN. For a trunk, you can attach the named ACLs to any VLANs that are allowed on the trunk as follows:

•On a port that is configured for VLAN-based QoS, the traffic that is received through the port is compared to any named ACLs that are attached to the port's VLAN. If you do not attach any named ACLs to the port's VLAN, or if the traffic does not match an ACE in a named ACL, QoS compares the traffic that is received through the port to the default ACLs.

•On a trunk that is configured for VLAN-based QoS, the traffic that is received through the port is compared to any named ACLs that are attached to the traffic's VLAN. For the traffic in the VLANs that have no named ACLs attached, or if the traffic does not match an ACE in a named ACL, QoS compares the traffic to the default ACLs.

On the ports that are configured for port-based QoS, you can attach the named ACLs to the port as follows:

•On a port that is configured for the port-based QoS, the traffic that is received through the port is compared to any named ACLs that are attached to the port. If you do not attach any named ACLs to the port, or if the traffic does not match an ACE in a named ACL, QoS compares the traffic that is received through the port to the default ACLs.

•On a trunk that is configured for port-based QoS, the traffic in all VLANs that are received through the port is compared to any named ACLs that are attached to the port. If you do not attach any named ACLs to the port, or if the traffic does not match an ACE in a named ACL, QoS compares the traffic that is received through the port to the default ACLs.

With PFC3, you can configure the ingress and egress QoS. To configure the ingress QoS, you attach the QoS ACLs to the ports and to the VLANs with the input keyword. To configure the egress QoS, you attach the QoS ACLs to the VLANs with the output keyword. The egress QoS does not use the port-based QoS (default) or VLAN-based QoS setting.

PFC3 Egress DSCP Mutation

PFC3 supports map-based egress DSCP mutation. You can configure up to 15 DSCP-to-DSCP mutation maps and apply the maps to the VLANs. QoS remarks the internal DSCP value in the egress traffic in the VLANs.

Final Layer 3 Switching Engine CoS and ToS Values

With a Layer 3 switching engine, QoS associates the CoS and ToS values with the traffic as specified by the marking rules and policers in the ACE that the traffic matches (see the "Internal DSCP Values" section). The associated CoS and ToS are used at the Ethernet egress port (see the "Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking" section).

With PFC3A, you can configure QoS to use the received DSCP value in the egress ToS byte, instead of the DSCP that is created by marking and policing.

Classification and Marking on a Supervisor Engine 1 with a Layer 2 Switching Engine

On a Supervisor Engine 1 with a Layer 2 Switching Engine, QoS can classify the traffic that is addressed to the specified MAC address/VLAN pairs to be marked with a configured CoS value (for more information, see the "QoS Terminology" section and the "Mapping a CoS Value to a Host Destination MAC Address/VLAN Pair" section).

Note Classification and marking on a Supervisor Engine 1 with a Layer 2 Switching Engine uses the Layer 2 CoS values. Classification and marking on a Supervisor Engine 1 with a Layer 2 Switching Engine does not use or set the Layer 3 IP precedence or DSCP values.

Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking

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

•Overview

•Transmit Queues

•Scheduling and Congestion Avoidance

•Marking

Overview

QoS schedules the traffic through the transmit queues based on the CoS values and uses the CoS-value-based transmit-queue drop thresholds to avoid congestion in the traffic that is transmitted from the Ethernet ports.

Note Ethernet egress port scheduling and congestion avoidance uses the Layer 2 CoS values. Ethernet egress port marking writes the Layer 2 CoS values, and for the IP traffic, the Layer 3 ToS byte.

Transmit Queues

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

•tx-(2q2t) indicates two standard queues, each with two configurable tail-drop thresholds.

•tx-(1p2q1t) indicates one strict-priority queue and two standard queues, each with one configurable WRED-drop threshold (on the 1p2q1t ports, each standard queue also has one nonconfigurable tail-drop threshold).

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

•tx-(1p3q1t) indicates one strict-priority queue and three standard queues, each with one configurable WRED-drop threshold (on the 1p3q1t ports, each standard queue also has one nonconfigurable tail-drop threshold).

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

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

For the port types with a strict-priority queue, the switch services the traffic in the strict-priority transmit queue before servicing the standard queues. When the switch is servicing a standard queue, after transmitting a packet, it checks for the traffic in the strict-priority queue. If the switch detects the traffic in the strict-priority queue, it suspends its service of the standard queue and completes the service of all the traffic in the strict-priority queue before returning to the standard queue.

Scheduling and Congestion Avoidance

QoS implements the CoS-value-based transmit-queue drop thresholds to avoid congestion in the transmitted traffic. See the "QoS Default Configuration" section for the default CoS-to-threshold mapping.

For some port types, you can configure each standard transmit queue to use both a nonconfigurable 100-percent tail-drop threshold and a configurable WRED-drop threshold (see the "1p3q1t Transmit Queues" section and the "1p2q1t, 1p3q8t, and 1p7q8t Transmit Queues" section). The switch uses the tail-drop thresholds for the traffic carrying the CoS values that are mapped only to a queue. The switch uses the WRED-drop thresholds for the traffic carrying the CoS values that are mapped to a queue and a threshold.

Marking

When the traffic is transmitted from the switch, QoS writes the ToS byte into the IP traffic (Layer 3 switching engine only) and the CoS value that was used for scheduling and congestion avoidance into the ISL or 802.1Q traffic (for more information, see the "Final Layer 3 Switching Engine CoS and ToS Values" section).

QoS Statistics Data Export

QoS statistics data export generates per-port and per-aggregate policer utilization information and forwards this information in the UDP packets to traffic monitoring, planning, or accounting applications. You can enable QoS statistics data export per port or per aggregate policer. The statistics data that is generated per port consists of the counts of the input and output packets and bytes. The aggregate policer statistics consists of the counts of the allowed packets and the counts of the packets exceeding the policed rate.

The QoS statistics data collection occurs periodically at a fixed interval, but the interval at which the data is exported is configurable. QoS statistics collection is enabled by default, and data export is disabled by default for all the ports and all the aggregate policers that are configured on the Catalyst 6500 series switch.

Note•Per-port counter information and utilization statistics are not available for the ATM ports.

•QoS statistics data export is completely separate from TopN and NetFlow Data Export and does not interact with either of these features.

For information on configuring QoS statistics data export, see the "Configuring QoS Statistics Data Export" section.

QoS Default Configuration

Table 52-3 shows the QoS default configuration.

Table 52-3 QoS Default Configuration

Feature

Default Value

QoS enable state

Disabled

Note—With QoS enabled and all other QoS parameters at the default values, QoS sets Layer 3 DSCP to zero and Layer 2 CoS to zero in all traffic that is transmitted from the switch.

DSCP Rewrite

Enabled

Egress DSCP Mutation

Disabled

Port CoS value

0

IntraVLAN microflow policing

Disabled

CoS to internal DSCP map
(internal DSCP set from 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

IP precedence to internal DSCP map
(internal DSCP set from 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

Internal DSCP to egress CoS map
(egress CoS set from 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

Named ACLs

None

Default ACLs

Supports per-port classification and marking, sets DSCP to 0 in traffic from the untrusted ports, no policing

COPS¹ support

Disabled

RSVP support

Disabled

QoS statistics data export

Disabled

With QoS enabled

Runtime—Port based or VLAN based

Port based

Config—Port based or VLAN based

Port based

Port trust state

Untrusted

2q2t transmit-queue size percentages

•Low priority: 80%

•High priority: 20%

1p1q0t receive-queue size percentages

•Standard: 80%

•Strict priority: 20%

1p2q2t transmit-queue size percentages

•Low priority: 70%

•High priority: 15%

•Strict priority: 15%

1p2q1t transmit-queue size percentages

•Low priority: 70%

•High priority: 15%

•Strict priority: 15%

1p3q8t transmit-queue size percentages

•Low priority: 65%

•Medium priority: 15%

•High priority: 15%

•Strict priority: 5%

1p7q8t transmit-queue size percentages

•Standard queue 1 (lowest priority): 25%

•Standard queue 2: 15%

•Standard queue 3: 15%

•Standard queue 4: 10%

•Standard queue 5: 10%

•Standard queue 6: 10%

•Standard queue 7 (highest priority): 10%

•Strict priority: 5%

1p3q8t standard transmit-queue low:medium:high priority bandwidth allocation ratio

20:100:200

1p7q8t standard transmit-queue lowest-to-highest priority bandwidth allocation ratio

10:20:30:40:40:70:70

1p2q1t standard transmit-queue low:high priority bandwidth allocation ratio

100:255

2q2t, 1p2q2t, and 1p2q1t standard transmit-queue low:high priority bandwidth allocation ratio

5:255

1p3q1t standard transmit-queue low:medium:high-priority bandwidth allocation ratio

100:150:200

1q4t/2q2t receive and transmit-queue CoS value/drop-threshold mapping

•Receive queue 1/drop threshold 1 (50%) and
transmit queue 1/drop threshold 1 (80%): CoS 0 and 1

•Receive queue 1/drop threshold 2 (60%) and
transmit queue 1/drop threshold 2 (100%): CoS 2 and 3

•Receive queue 1/drop threshold 3 (80%) and
transmit queue 2/drop threshold 1 (80%): CoS 4 and 5

•Receive queue 1/drop threshold 4 (100%) and
transmit queue 2/drop threshold 2 (100%): CoS 6 and 7

1q2t port receive-queue CoS value/drop-threshold mapping and threshold percentages

•Receive queue 1/drop threshold 1:

–CoS 0, 1, 2, 3, and 4

–Drop threshold: 80%

•Receive queue 1/drop threshold 2:

–CoS 5, 6, and 7

–Drop threshold: 100% (not configurable)

Note 1p2q2t transmit queues same as 1p1q4t/1p2q2t.

1p1q4t/1p2q2t port receive and transmit-queue CoS value/drop-threshold mapping and threshold percentages

•Strict-priority receive queue 1 and
strict-priority transmit queue 1: CoS 5

•Receive queue 1/drop threshold 1 and
transmit queue 1/drop threshold 1:

–CoS 0 and 1

–Transmit queue low and high WRED-drop thresholds: 40% and 70%

•Receive queue 1/drop threshold 2 and
transmit queue 1/drop threshold 2:

–CoS 2 and 3

–Transmit queue low and high WRED-drop thresholds: 70% and 100%

•Receive queue 1/drop threshold 3 and
transmit queue 2/drop threshold 1:

–CoS 4

–Transmit queue low and high WRED-drop thresholds: 40% and 70%

•Receive queue 1/drop threshold 4 and
transmit queue 2/drop threshold 2:

–CoS 6 and 7

–Transmit queue low and high WRED-drop thresholds: 70% and 100%

1p1q0t receive-queue CoS value mapping

•Receive queue 1 (standard) nonconfigurable 100% tail-drop threshold:
CoS 0, 1, 2, 3, 4, 6, and 7

•Receive queue 2 (strict priority): CoS 5

1q8t receive-queue CoS value/drop-threshold mapping

•Threshold 1: 50% (CoS 0)

•Threshold 2: 50%

•Threshold 3: 60% (CoS 1, 2, 3, 4)

•Threshold 4: 60%

•Threshold 5: 80% (CoS 6 and 7)

•Threshold 6: 80%

•Threshold 7: 100% (CoS 5)

•Threshold 8: 100%

1p3q8t transmit-queue CoS value/drop-threshold mapping

•Standard transmit queue 1 (low priority) low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 0)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 2 (medium priority) low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 1 and 2)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 3 (high priority) low and high WRED-drop thresholds:

–Thresholds 1 and 2—40% and 70%

–Thresholds 3 and 4—50% and 80%

–Threshold 5—60% and 90% (CoS 3 and 4)

–Threshold 6—60% and 90%

–Threshold 7—70% and 100% (CoS 6 and 7)

–Threshold 8—70% and 100%

•Strict transmit queue 4: CoS 5

1p7q8t transmit-queue CoS value/drop-threshold mapping

•Standard transmit queue 1 (lowest priority) low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 0)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 2 low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 1)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 3 low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 2)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 4 low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 3)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 5 low and high WRED-drop thresholds:

–Threshold 1—70% and 100% (CoS 4)

–Thresholds 2 through 8—100% and 100%

•Standard transmit queue 6 low and high WRED-drop thresholds:

–Threshold 1—100% and 100%

–Threshold 2—70% and 100% (CoS 6)

–Thresholds 3 through 8—100% and 100%

•Standard transmit queue 7 low and high WRED-drop thresholds:

–Threshold 1—100% and 100%

–Threshold 2—70% and 100% (CoS 7)

–Thresholds 3 through 8—100% and 100%

•Strict transmit queue 8: CoS 5

1p3q1t transmit-queue CoS value/drop-threshold mapping

•Standard transmit queue 1 (low priority) tail-drop threshold:

–CoS 0 and 1

–Low and high WRED-drop threshold: 70% and 100%

•Standard transmit queue 2 (medium priority) tail-drop threshold:

–CoS 2, 3, and 4

–Low and high WRED-drop threshold: 70% and 100%

•Standard transmit queue 3 (high priority) tail-drop threshold:

–CoS 6 and 7

–Low and high WRED-drop threshold: 70% and 100%

•Standard transmit queue 4 (strict priority): CoS 5

1p1q8t receive-queue port CoS value/drop-threshold mapping

•Receive queue 1 (standard) WRED-drop threshold:
CoS 0, 1, 2, 3, 4, 6, and 7:

–Drop threshold 1: CoS 0
Low WRED threshold: 40%
High WRED-drop threshold: 70%

–Drop threshold 2: CoS 1
Low WRED threshold: 40%
High WRED-drop threshold: 70%

–Drop threshold 3: CoS 2
Low WRED threshold: 50%
High WRED-drop threshold: 80%

–Drop threshold 4: CoS 3
Low WRED threshold: 50%
High WRED-drop threshold: 80%

–Drop threshold 5: CoS 4
Low WRED threshold: 60%
High WRED-drop threshold: 90%

–Drop threshold 6: CoS 6
Low WRED threshold: 60%
High WRED-drop threshold: 90%

–Drop threshold 6: CoS 7
Low WRED threshold: 70%
High WRED-drop threshold: 100%

•Receive queue 2 (strict priority): CoS 5

1p2q1t transmit-queue port CoS value/drop-threshold mapping

•Standard transmit queue 1 (low priority) WRED-drop threshold:

–CoS 0, 1, 2, and 3

–Low WRED threshold: 70%

–High WRED-drop threshold: 100%

•Standard transmit queue 2 (high priority) WRED-drop threshold:

–CoS 4, 6, or 7

–Low WRED threshold: 70%

–High WRED-drop threshold: 100%

•Strict transmit queue 3: CoS 5

With QoS disabled

Runtime—Port based or VLAN based

VLAN based

Config—Port based or VLAN based

Port based

Port trust state

trust-cos (Layer 2 switching engine)
trust-dscp (Layer 3 switching engine)

Receive-queue drop-threshold percentages

All thresholds set to 100%

Transmit-queue drop-threshold percentages

All thresholds set to 100%

Transmit-queue low-priority/high-priority bandwidth allocation ratio

255:1

Transmit-queue size ratio

•Low priority: 100%

•High priority: Not used

CoS value/drop-threshold mapping

Receive-drop threshold 1 and transmit-queue 1/drop threshold 1: CoS 0-7

¹COPS = Common Open Policy Service

QoS Configuration Guidelines and Restrictions

QoS has the following hardware granularity for the committed information rate (CIR) and the peak information rate (PIR) values:

CIR and PIR Rate Value Range

Granularity

         1 to    2097152   (2 Mbs)

    65536 (64 Kb)

   2097153 to    4194304   (4 Mbs)

   131072 (128 Kb)

   4194305 to    8388608   (8 Mbs)

   262144 (256 Kb)

   8388609 to   16777216 (16 Mbs)

   524288 (512 Kb)

  16777217 to   33554432 (32 Mbs)

  1048576   (1 Mb)

  33554433 to   67108864 (64 Mbs)

  2097152   (2 Mb)

  67108865 to 134217728 (128 Mbs)

  4194304   (4 Mb)

134217729 to 268435456 (256 Mbs)

  8388608   (8 Mb)

268435457 to 536870912 (512 Mbs)

16777216 (16 Mb)

536870913 to 1073741824   (1 Gps)

33554432 (32 Mb)

1073741825 to 2147483648   (2 Gps)

67108864 (64 Mb)

2147483649 to 4294967296   (4 Gps)

134217728 (128 Mb)

4294967297 to 8000000000   (8 Gps)

268435456 (256 Mb)

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

QoS has the following hardware granularity for the 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)

    8192   (8 KB)

   262145 to    524288 (512 KB)

   16384 (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)

Configuring QoS on the Switch

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

•Enabling QoS

•Enabling DSCP Rewrite

•Disabling DSCP Rewrite

•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

•Attaching an ACL to an Interface

•Detaching an ACL from an Interface

•Configuring PFC3 Egress DSCP Mutation

•Configuring CoS-to-CoS Maps on 802.1Q Tunnel Ports

•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 the Standard Receive-Queue Tail-Drop Thresholds

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

•Configuring the Standard Queue WRED-Drop Thresholds

•Allocating Bandwidth Between the Standard Transmit Queues

•Configuring the Receive-Queue Size Ratio

•Configuring the Transmit-Queue Size Ratio

•Mapping the CoS Values to the Drop Thresholds

•Configuring the DSCP Value Maps

•Displaying QoS Information

•Displaying the QoS Statistics

•Reverting to the QoS Defaults

•Disabling QoS

•Configuring COPS Support

•Configuring RSVP Support

•Configuring QoS Statistics Data Export

Note Some QoS show commands support the config and runtime keywords. Use the runtime keyword to display the QoS values that are currently programmed into the hardware. When you disable QoS, the display with the runtime keyword is "QoS is disabled." Use the config keyword to display the values from the commands that have been entered but which may not currently be programmed into the hardware (for example, the locally configured QoS values that are currently not used because COPS has been selected as the QoS policy source or the QoS values that are configured when QoS is disabled).

Enabling QoS

To enable QoS, perform this task in privileged mode:

Task

Command

Enable QoS on the switch.

set qos {enable | disable}

This example shows how to enable QoS:
Console> (enable) set qos enable
QoS is enabled.
Console> (enable) 
Enabling DSCP Rewrite

Note Only PFC3 supports the configuration commands in this section.

To enable DSCP rewrite, which uses the DSCP value from marking and policing as the egress DSCP value, perform this task in privileged mode:

Task

Command

Enable DSCP rewrite on the switch.

set qos dscp-rewrite enable

This example shows how to enable DSCP rewrite:
Console> (enable) set qos dscp-rewrite enable
DSCP rewrite has been globally enabled.
Console> (enable) 
Disabling DSCP Rewrite

Note Only PFC3 supports the configuration commands in this section.

To disable DSCP rewrite, which uses the received DSCP value as the egress DSCP value, perform this task in privileged mode:

Task

Command

Disable DSCP rewrite on the switch.

set qos dscp-rewrite disable

This example shows how to disable DSCP rewrite:
Console> (enable) set qos dscp-rewrite disable
DSCP rewrite has been globally disabled.
Console> (enable) 
Enabling Port-Based or VLAN-Based QoS

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

By default, QoS uses the ACLs that are attached to the ports. On a per-port basis, you can configure QoS to use the ACLs that are attached to a VLAN. To enable VLAN-based QoS on a port, perform this task in privileged mode:

Task

Command

Step 1

Enable VLAN-based QoS on a port.

set port qos mod/port {port-based | vlan-based}

Step 2

Verify the configuration.

show port qos mod/port

For more information, see the "Attaching ACLs" section.

This example shows how to enable the VLAN-based QoS on a port:
Console> (enable) set port qos 1/1-2 vlan-based
Hardware programming in progress...
QoS interface is set to vlan-based for ports 1/1-2.
Console> (enable) 
Changing a port from port-based to VLAN-based QoS detaches all ACLs from the port. Any ACLs that are attached to the VLAN apply to the port immediately (for more information, see the "Attaching an ACL to an Interface" section).

Configuring the Trust State of a Port

This command configures the trust state of a port (for more information, see the "Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification" section). By default, all ports are untrusted.

To configure the trust state of a port, perform this task in privileged mode:

Task

Command

Step 1

Configure the trust state of a port.

set port qos trust {untrusted | trust-cos | trust-ipprec | trust-dscp}

Step 2

Verify the configuration.

show port qos

Note the following syntax guidelines when configuring the trust state of a port:

•The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine.

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

This example shows how to configure port 1/1 with the trust-cos keyword:
Console> (enable) set port qos 1/1 trust trust-cos
Port 1/1 qos set to trust-cos
Console> (enable) 
Note Only the ISL or 802.1Q frames carry the CoS values. Configure the ports with the trust-cos keyword only when the received traffic is ISL or 802.1Q frames carrying the CoS values that you know to be consistent with the network policy.

Configuring the CoS Value for a Port

Note Whether or not QoS uses the CoS value that is applied with the set port qos ...cos command depends on the trust state of the port and the trust state of the traffic that is received through the port. The set port qos ... cos command does not configure the trust state of the port or the trust state of the traffic that is received through the port. To use the CoS value that is applied with the set port qos ... cos command, configure a trust-CoS ACL that matches the ingress traffic; or for a port that receives no tagged traffic, configure the port to trust CoS.

The unmarked frames from the ports that are configured as trusted and all frames from the ports that are configured as untrusted are assigned the CoS value that is specified with this command.

To configure the CoS value for a port, perform this task in privileged mode:

Task

Command

Step 1

Configure the CoS value for a port.

set port qos cos cos_value

Step 2

Verify the configuration.

show port qos

This example shows how to configure the port CoS value to 3 for port 1/1:
Console> (enable) set port qos 1/1 cos 3 
Port 1/1 qos cos set to 3
Console> (enable) 
To revert to the default CoS value for a port, perform this task in privileged mode:

Task

Command

Step 1

Revert to the default CoS value for a port.

clear port qos cos

Step 2

Verify the configuration.

show port qos

This example shows how to revert to the default CoS value for port 1/1:
Console> (enable) clear port qos 1/1 cos
Port 1/1 qos cos setting cleared.
Console> (enable) 
Creating Policers

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

To create a policer, perform this task in privileged mode:

Task

Command

Step 1

Create a policer.

set qos policer microflow microflow_name {rate rate} {burst burst_value} {drop | policed-dscp}

With PFC or PFC2:
set qos policer aggregate aggregate_name {rate rate} {burst burst_value} {drop | policed-dscp}

With PFC2 or PFC3A:
set qos policer aggregate aggregate_name {rate rate} policed-dscp {erate erate_value} {drop | policed-dscp} burst burst_value [eburst eburst_value]

Step 2

Verify the configuration.

show qos policer {config | runtime} {microflow | aggregate | all}

For more information, see the "Policers" section and the "PFC2 Policing Decisions" section.

The policer_name parameter can be up to 31 characters, is case sensitive, and may include a-z, A-Z, 0-9, the dash character (-), the underscore character (_), and the period character (.).The policer names must start with an alphabetic character (not a digit) and must be unique across all microflow and aggregate policers. You cannot use the keywords from any command as a policer name.

The valid values for the rate and erate parameters are 32 Kbps (entered as 32) to 32 Gbps (entered as 32000000). To classify all traffic as out of profile, set the rate parameter to zero (0). Set the erate parameter to a higher value than the rate parameter. PFC1 and PFC2 have the following hardware granularity for rate values:

Rate Value Range

Granularity

Rate Value Range

Granularity

1 to 1000 (1 Mbs)

32768 (32 K)

64001 to 128000 (128 Mbs)

4194304 (4 M)

1001 to 2000 (2 Mbs)

65536 (64 K)

128001 to 256000 (256 Mbs)

8388608 (8 M)

2001 to 4000 (4 Mbs)

131072 (128 K)

256001 to 512000 (512 Mbs)

16777216 (16 M)

4001 to 8000 (8 Mbs)

262144 (256 K)

512001 to 1024000 (1 Gps)

33554432 (32 M)

8001 to 16000 (16 Mbs)

524288 (512 K)

1024001 to 2048000 (2 Gps)

67108864 (64 M)

16001 to 32000 (32 Mbs)

1048576 (1 M)

2048001 to 4096000 (4 Gps)

134217728 (128 M)

32001 to 64000 (64 Mbs)

2097152 (2 M)

4096001 to 8192000 (8 Gps)

268435456 (256 M)

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

The valid values for the burst and eburst parameters are 1 Kb (entered as 1) to 256 Mb (entered as 256000). When configuring the burst and eburst parameters, note the following:

•The burst keyword, the burst_value parameter, the optional eburst keyword, and the eburst_value parameter set the token bucket sizes.

•The token bucket size defines the maximum number of the in-profile bytes that can be transmitted every 0.25 millisecond.

•To sustain a specific rate, set the token bucket size to be at least the rate divided by 4000, because the tokens are removed from the bucket every 1/4000th of a second (0.25 millisecond) and the bucket needs to be at least as large as the burst size to sustain the specified rate.

•If you do not enter the eburst keyword and the eburst_value parameter, QoS sets both token buckets to the size that is configured with the burst keyword and the burst_value parameter.

•Because any packet larger than the burst size is considered an out-of-profile packet, make sure that the burst size is greater than or equal to the largest packet size being policed.

•QoS programs the hardware with the values that are multiples of 32K (32,768), not with the specific value entered.

Enter either the drop keyword to cause all out-of-profile packets to be dropped or the policed-dscp keyword to cause all out-of-profile packets with the normal rate to be marked down as specified in the normal markdown DSCP map (for more information, see the "Mapping the DSCP Markdown Values" section).

This example shows how to create a microflow policer with a 1-Mbps rate limit and a 10-Mb burst limit that marks down out-of-profile traffic:
Console> (enable) set qos policer microflow my-micro rate 1000 burst 10000 policed-dscp
Hardware programming in progress...
QoS policer for microflow my-micro created successfully.
Console> (enable)
For PFC2 or PFC3A, this example shows how to create an aggregate excess rate policer with a 64-Kbps rate limit and a 128-Kb burst limit that drops the traffic exceeding these values:
Console> (enable) set qos policer aggregate test rate 64 burst 128 drop
QoS policer for aggregate test created successfully.
Console> (enable) show qos policer config aggregate test
QoS aggregate policers:
QoS aggregate policers:
Aggregate name                Normal rate (kbps) Burst size (kb) Normal action
----------------------------- ------------------ --------------- -------------
test                                          64          128    policed-dscp
                              Excess rate (kbps) Burst size (kb) Excess action
                              ------------------ --------------- ------------- 
                                              64          128    drop
                              ACL attached
                              ------------------------------------
Console> (enable)
For PFC2 or PFC3A, this example shows how to create an aggregate excess rate policer with a 64-Kbps rate limit and a 100-Kb burst limit that will cause all out-of-profile packets to be marked down as specified in the normal markdown DSCP map:
Console> (enable) set qos policer aggregate test2 rate 64 burst 100 policed-dscp
QoS policer for aggregate test2 created successfully.
Console> (enable) show qos policer config aggregate test2
QoS aggregate policers:
Aggregate name                Normal rate (kbps)  Burst size (kb) Normal action
----------------------------- ------------------  --------------- -------------
test2                                         64             100  policed-dscp
                              Excess rate (kbps)  Burst size (kb) Excess action
                              ------------------  --------------  ---------------
                                         8000000             100  policed-dscp
                              ACL attached
                              ------------------------------------
Console> (enable)
For PFC2 or PFC3A, this example shows how to create an aggregate excess rate policer with a 64-Kbps rate limit and a 128-Kb burst limit that will cause the traffic that exceeds the normal rate of 64 Kbps and a burst size of 96 Kb to be marked down as specified in the normal markdown DSCP map, and the traffic that exceeds 128 Kbps and a burst size of 96 Kb to be dropped:
Console> (enable) set qos policer aggregate test3 rate 64 policed-dscp erate 128 drop 
burst 96
QoS policer for aggregate test3 created successfully.
Console> (enable) show qos policer config aggregate test3
QoS aggregate policers:
Aggregate name                Normal rate (kbps)  Burst size (kb) Normal action
----------------------------- ------------------  --------------- -------------
test3                                         64               96 policed-dscp
                              Excess rate (kbps)  Burst size (kb) Excess action
                              ------------------  --------------- ---------------
                                             128               96 drop
                              ACL attached
                              ------------------------------------
Console> (enable)
Deleting Policers

Note You can delete the policers only if they are not attached to any interfaces (for more information, see the "Detaching an ACL from an Interface" section).

To delete one or all policers, perform this task in privileged mode:

Task

Command

Step 1

Delete one or all policers.

clear qos policer {microflow | aggregate} {policer_name | all}

Step 2

Verify the configuration.

show qos policer {config | runtime} {microflow | aggregate | all}

This example shows how to delete the microflow policer named my_micro:
Console> (enable) clear qos policer microflow my_micro 
my_micro QoS microflow policer cleared.
Console> (enable) 
Creating or Modifying ACLs

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

These sections describe how to create and modify the ACLs:

•ACL Names

•ACE Name, Marking Rule, Policing, and Filtering Syntax

•Named IP ACLs

•Modifying the Default IP ACLs

•Creating or Modifying the Named IPX ACLs

•Creating or Modifying the Named MAC ACLs

•Creating or Modifying the Default IPX and MAC ACLs

•Deleting a Named ACL

•Reverting to the Default Values in the Default ACLs

•Discarding an Uncommitted ACL

•Committing an ACL

ACL Names

The ACL names can be up to 31 characters, are case sensitive, and may include a-z, A-Z, 0-9, the dash character (-), the underscore character (_), and the period character (.). The ACL names must start with an alphabetic character and must be unique across all QoS ACLs of all types. You cannot use the keywords from any command as an ACL name.

ACE Name, Marking Rule, Policing, and Filtering Syntax

The ACE command syntax is organized as follows:
ACL_command ACL_type_and_name marking_rule policing_rule filtering

For example, in an IP ACE, the command syntax is as follows:

set qos acl ip acl_name {dscp dscp_value | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] src_ip_spec [precedence precedence | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

•set qos acl ip acl_name—Creates a named ACL of the specified type or adds the ACE to the ACL if it already exists. See the "ACL Names" section.

•{dscp dscp_value | trust-cos | trust-ipprec | trust-dscp}—Selects a marking rule. See the "Marking Rules" section.

•[microflow microflow_name] [aggregate aggregate_name]—Optionally configures policing in the ACE. See the "Policers" section.

•src_ip_spec [precedence precedence | dscp-field dscp]—The rest of the parameters, except the editbuffer keywords, configure filtering.

Named IP ACLs

These sections describe how to create or modify the IP ACLs:

•Source and Destination IP Addresses and Masks

•Port Operator Parameters

•Precedence Parameter Options

•IP ACEs for TCP Traffic

•IP ACEs for UDP Traffic

•IP ACEs for ICMP Traffic

•IP ACEs for IGMP Traffic

•IP ACLs for Other Layer 4 Protocols

•IP ACEs for Any IP Traffic

Source and Destination IP Addresses and Masks

In the IP ACEs, specify the source and destination IP addresses and masks (represented by the src_ip_spec and dest_ip_spec parameters in the following sections) in the form ip_address mask. The mask is mandatory. Use one bits, which need not be contiguous, where you want the wildcards.

Use any of the following formats for the address and mask:

•Four-part dotted-decimal 32-bit values

•The keyword any as an abbreviation for a wildcard address and wildcard mask of 0.0.0.0 255.255.255.255

•The abbreviation host ip_address for an address and wildcard mask of ip_address 0.0.0.0

Port Operator Parameters

In the IP ACEs, the operator parameter can be one of the following:

•lt (less than)

•gt (greater than)

•eq (equal)

•neq (not equal)

•range (with a pair of port parameters)

See the "Layer 4 Operations Configuration Guidelines" section on page 15-23 for restrictions that apply to the QoS ACLs.

Precedence Parameter Options

For the precedence parameter keyword options in the IP ACEs, see the "IP ACE Layer 3 Classification Criteria" section.

IP ACEs for TCP Traffic

To create or modify an IP ACE for the TCP traffic, perform this task in privileged mode:

Task

Command

Step 1

Create or modify an IP ACE for the TCP traffic.

set qos acl ip {acl_name} {{dscp dscp_value} | trust-cos | trust-ipprec | trust-dscp}
[microflow microflow_name] [aggregate aggregate_name] tcp {src_ip_spec} [{operator}
{port} [port]] {dest_ip_spec} [{operator} {port} [port]] [established] [precedence precedence_value | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

For the port parameter keyword options, see the "IP ACE Layer 4 TCP Classification Criteria" section.

The established keyword matches the traffic with the ACK or RST bits set.

This example shows how to create an IP ACE for the TCP traffic:
Console> (enable) set qos acl ip my_IPacl trust-ipprec microflow my-micro aggregate my-agg 
tcp any any
my_IPacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
IP ACEs for UDP Traffic

To create or modify an IP ACE for the UDP traffic, perform this task in privileged mode:

Task

Command

Step 1

Create or modify an IP ACE for the UDP traffic.

set qos acl ip {acl_name} {{dscp dscp_value} | trust-cos | trust-ipprec | trust-dscp}
[microflow microflow_name] [aggregate aggregate_name] udp {src_ip_spec} [{operator}
{port} [port]] {dest_ip_spec} [{operator} {port} [port]] [precedence precedence_value | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

For the port parameter keyword options, see the "IP ACE Layer 4 UDP Classification Criteria" section.

This example shows how to create an IP ACE for the UDP traffic:
Console> (enable) set qos acl ip my_IPacl trust-ipprec microflow my-micro aggregate my-agg 
udp any any
my_IPacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
IP ACEs for ICMP Traffic

To create or modify an IP ACE for the ICMP traffic, perform this task in privileged mode:

Task

Command

Step 1

Create or modify an IP ACE for the ICMP traffic.

set qos acl ip acl_name {dscp dscp | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] icmp src_ip_spec dest_ip_spec [icmp_type [icmp_code] | icmp_message] [precedence precedence | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

For the icmp_code and icmp_type parameter keyword options, see the "IP ACE Layer 4 ICMP Classification Criteria" section.

This example shows how to create an IP ACE for ICMP echo traffic:
Console> (enable) set qos acl ip my_IPacl trust-ipprec microflow my-micro aggregate my-agg 
icmp any any echo
my_IPacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
IP ACEs for IGMP Traffic

Note QoS does not support the IGMP traffic when IGMP snooping is enabled.

To create or modify an IP ACE for the IGMP traffic, perform this task in privileged mode:

Task

Command

Step 1

Create or modify an IP ACE for the IGMP traffic.

set qos acl ip acl_name {dscp dscp_value | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] igmp src_ip_spec dest_ip_spec [igmp_type] [precedence precedence_value | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

For the igmp_type parameter keyword options, see the "IP ACE Layer 4 IGMP Classification Criteria" section.

This example shows how to create an IP ACE for the IGMP Protocol Independent Multicast (PIM) traffic:
Console> (enable) set qos acl ip my_IPacl trust-ipprec microflow my-micro aggregate my-agg 
igmp any any pim
my_IPacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
IP ACLs for Other Layer 4 Protocols

To create or modify a named IP ACL with additional parameters that match all Layer 4 protocols, perform this task in privileged mode:

Task

Command

Step 1

Create or modify an IP ACE.

set qos acl ip acl_name {dscp dscp_value | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] protocol src_ip_spec dest_ip_spec [precedence precedence_value | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

Note With software Release 8.3(1) and later, the ACLs with the output keyword applied also support the trust-cos and trust-ipprec keywords.

For the protocol parameter keyword options, see the "IP ACE Layer 4 Protocol Classification Criteria" section.

This example shows how to create an IP ACE for the IPINIP traffic:
Console> (enable) set qos acl ip my_IPacl trust-ipprec microflow my-micro aggregate my-agg 
ipinip any any
my_IPacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
IP ACEs for Any IP Traffic

To create or modify an IP ACE that matches all IP traffic, perform this task in privileged mode:

Task

Command

Step 1

Create or modify an IP ACE.

set qos acl ip acl_name {dscp dscp | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] src_ip_spec [precedence precedence | dscp-field dscp] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

This example shows how to create an IP ACE:
Console> (enable) set qos acl ip my_IPacl trust-ipprec microflow my-micro aggregate my-agg 
any
my_IPacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
Modifying the Default IP ACLs

These sections describe how to modify the default IP ACLs:

•Modifying the Default IP Ingress ACL

•Modifying the Default IP Egress ACL

Modifying the Default IP Ingress ACL

To modify the default IP ingress ACL, perform this task in privileged mode:

Task

Command

Step 1

Modify the default IP ACL.

set qos acl default-action ip {dscp dscp | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] [input]

Step 2

Verify the configuration.

show qos acl info default-action {ip | ipx | mac | all}

Note Only PFC3 supports the input keyword.

For more information, see the "Default ACLs" section.

This example shows how to modify the default IP ACL:
Console> (enable) set qos acl default-action ip dscp 5 microflow my-micro aggregate my-agg 
QoS default-action for IP ACL is set successfully.
Console> (enable)
Modifying the Default IP Egress ACL

Note Only PFC3 supports the configuration commands in this section.

To modify the default IP egress ACL, perform this task in privileged mode:

Task

Command

Step 1

Modify the default IP ACL.

set qos acl default-action ip {dscp dscp | trust-dscp} [aggregate aggregate_name] output

Step 2

Verify the configuration.

show qos acl info default-action ip

Note In the default egress ACL, the trust-dscp keywords cause the ACL to trust the internal DSCP value, not a received DSCP value (see the "Internal DSCP Values" section).

For more information, see the "Default ACLs" section.

This example shows how to modify the default IP ACL:
Console> (enable) set qos acl default-action ip dscp 5 microflow my-micro aggregate my-agg 
QoS default-action for IP ACL is set successfully.
Console> (enable)
Creating or Modifying the Named IPX ACLs

Note PFC3 does not provide QoS for the IPX traffic. See the "MAC ACE Layer 2 Classification Criteria" section for information about how to use the MAC ACLs to filter the IPX traffic.

To create or modify a named IPX ACL, perform this task in privileged mode:

Task

Command

Step 1

Create or modify a named IPX ACL.

With a PFC:
set qos acl ipx acl_name {dscp dscp_value | trust-cos} [aggregate aggregate_name] protocol src_net [dest_net[.dest_node] [[dest_net_mask]
.dest_node_mask]] [before editbuffer_index | modify editbuffer_index]

With PFC2:
set qos acl ipx acl_name aggregate aggregate_name protocol src_net [dest_net[.dest_node] [[dest_net_mask]
.dest_node_mask]] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

The protocol parameter can be specified numerically (0-255) or with these keywords: any, ncp (17), netbios (20), rip (1), sap (4), or spx (5).

The src_net and dest_net parameters are IPX network numbers, entered as up to 8 hexadecimal digits in the range 1 to FFFFFFFE (-1 matches any network number). You do not need to enter leading zeros.

If you specify an IPX destination network, the IPX ACEs support the following optional parameters:

•An IPX destination network mask, entered as up to 8 hexadecimal digits in the range 1 to FFFFFFFE (-1 matches any network number). Use one bits, which need not be contiguous, where you want the wildcards.

•An IPX destination node, entered as 12 hexadecimal digits (48 bits), formatted as a dotted triplet of four-digit hexadecimal digits each (xxxx.xxxx.xxxx).

•If you specify an IPX destination node, the IPX ACEs support an IPX destination node mask, entered as 12 hexadecimal digits (48 bits), formatted as a dotted triplet of four-digit hexadecimal digits each (xxxx.xxxx.xxxx). Use one bits, which need not be contiguous, where you want the wildcards.

This example shows how to create an IPX ACE:
Console> (enable) set qos acl ipx my_IPXacl trust-cos aggregate my-agg -1
my_IPXacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
Creating or Modifying the Named MAC ACLs

To create or modify a named MAC ACL, perform this task in privileged mode:

Task

Command

Step 1

Create or modify a named MAC ACL.

With a PFC, PFC2, or PFC3:
set qos acl mac acl_name {dscp dscp_value | trust-cos} [aggregate aggregate_name] src_mac_spec dest_mac_spec [ethertype] [before editbuffer_index | modify editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all} editbuffer [editbuffer_index]

Enter the src_mac_spec and dest_mac_spec parameters as a MAC address and a mask. Each parameter is 12 hexadecimal digits (48 bits), formatted as dash-separated pairs. Use one bits, which need not be contiguous, where you want the wildcards. Use the any keyword for a MAC address and mask of 0-0-0-0-0-0 ff-ff-ff-ff-ff-ff. Use the host keyword with a MAC address to specify an all-zero mask (mac_address 0-0-0-0-0-0).

Enter the ethertype parameter as 4 hexadecimal digits (16 bits) prefaced with 0x (for example, 0x0600) or as a keyword (see the "MAC ACE Layer 2 Classification Criteria" section).

This example shows how to create a MAC ACE:
Console> (enable) set qos acl mac my_MACacl trust-cos aggregate my-agg any any
my_MACacl editbuffer modified. Use `commit' command to apply changes.
Console> (enable)
Note The QoS MAC ACLs that do not include an EtherType parameter match the traffic with any value in the EtherType field, which allows the MAC-level QoS to be applied to any traffic except IP and IPX.

Creating or Modifying the Default IPX and MAC ACLs

Note PFC3 does not provide QoS for IPX traffic.

To create or modify the default IPX or MAC ACL, perform this task in privileged mode:

Task

Command

Step 1

Create or modify the default IPX or MAC ACL.

With a PFC:
set qos acl default-action {ipx | mac} {dscp dscp | trust-cos} [aggregate aggregate_name]

With PFC2:
set qos acl default-action {ipx | mac} aggregate aggregate_name

With PFC3:
set qos acl default-action mac aggregate aggregate_name

Step 2

Verify the configuration.

show qos acl info default-action {ip | ipx | mac | all}

For more information, see the "Default ACLs" section.

This example shows how to modify the default IPX ACL:
Console> (enable) set qos acl default-action ipx dscp 5 aggregate my-agg 
QoS default-action for IPX ACL is set successfully.
Console> (enable)
Note The IPX and MAC ACLs do not support the microflow policers.

Deleting a Named ACL

To delete a named ACL, perform this task in privileged mode:

Task

Command

Step 1

Delete a named ACL.

clear qos acl acl_name [editbuffer_index]

Step 2

Verify the configuration.

show qos acl info {acl_name | all}

This example shows how to delete the ACL named icmp_acl:
Console> (enable) clear qos acl icmp_acl 1
ACL icmp_acl ACE# 1 is deleted.
icmp_acl editbuffer modified. Use `commit' command to apply changes.
Console> (enable) 
Reverting to the Default Values in the Default ACLs

To revert to the default values for a default ACL, perform this task in privileged mode:

Task

Command

Step 1

Revert to the default values for a default ACL.

clear qos acl default-action {ip | ipx | mac} [tx]

Step 2

Verify the configuration.

show qos acl info default-action {ip | ipx | mac | all}

This example shows how to revert to the default values for the default IP ACL:
Console> (enable) clear qos acl default-action ip
Hardware programming in progress...
QoS default-action for IP ACL is restored to default setting.
Console> (enable) 
Discarding an Uncommitted ACL

To discard an uncommitted new ACL or uncommitted changes to an existing ACL, perform this task in privileged mode:

Task

Command

Step 1

Discard an uncommitted ACL.

rollback qos acl {acl_name | all}

Step 2

If you discarded changes to an existing ACL, verify the configuration.

show qos acl info {acl_name | all}

This example shows how to discard an uncommitted ACL named my_acl:
Console> (enable) rollback qos acl my_acl
Rollback for QoS ACL my_acl is successful.
Console> (enable) 
Note The changes to the default ACLs take effect immediately and cannot be discarded.

Committing an ACL

When you create, change, or delete a named ACL, the changes exist temporarily in an edit buffer in memory. To commit the ACL so that it can be used, perform this task in privileged mode:

Task

Command

Step 1

Commit an ACL.

commit qos acl acl_name

Step 2

Verify the configuration.

show config qos acl {acl_name | all}

This example shows how to commit an ACL named my_acl:
Console> (enable) commit qos acl my_acl
Hardware programming in progress...
ACL my_acl is committed to hardware.
Console> (enable) 
Note When you commit an ACL that has already been attached to an interface, the new values go into effect immediately. The changes to the default ACLs do not need to be committed.

See the "Configuring and Storing VACLs and QoS ACLs in Flash Memory" section on page 15-64 for information about where the QoS ACLs are stored.

Attaching an ACL to an Interface

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

You can do the following:

•For the ingress traffic, attach one ACL of each type (IP, IPX, MAC Layer) to each VLAN.

•For the ingress traffic, attach one ACL of each type (IP, IPX, MAC Layer) to each port that is configured for port-based QoS. You cannot attach the ACLs to a port that is configured for VLAN-based QoS (for more information, see the "Enabling Port-Based or VLAN-Based QoS" section).

•With PFC3, for the egress traffic, attach an IP ACL to each VLAN.

When an ACL of a particular type (IP, IPX, or MAC Layer) is already attached to an interface, attaching a different ACL of the same type detaches the previous ACL.

To attach an ACL to a port or a VLAN, perform this task in privileged mode:

Task

Command

Step 1

Attach an ACL to an interface.

set qos acl map acl_name {mod/port [input] | vlan [input | output]}

Step 2

Verify the configuration.

show qos acl map {config | runtime} {acl_name | mod/port | vlan | all}

Note Only PFC3 supports the input and output keywords.

Note With software release 8.3(1) and later, the ACLs that are attached to a VLAN with the output keyword also support the trust-cos and trust-ipprec keywords.

This example shows how to attach an ACL named test to VLAN 1 to filter the ingress traffic:
Console> (enable) set qos acl map test 1
ACL test is successfully mapped to vlan 1 on input side.
Console> (enable) 
This example shows how to attach an ACL named test2 to VLAN 1 to filter the egress traffic:
Console> (enable) set qos acl map test2 1 output
ACL test2 is successfully mapped to vlan 1 on output side.
Console> (enable) 
Note The default ACLs do not need to be attached to any interfaces.

Detaching an ACL from an Interface

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

To detach an ACL from a port or a VLAN, perform this task in privileged mode:

Task

Command

Step 1

Detach an ACL from an interface.

clear qos acl map acl_name {mod/port [input] | vlan [input | output] | all}

Step 2

Verify the configuration.

show qos acl map {config | runtime} {acl_name | mod/port | vlan | all}

Note Only PFC3 supports the input and output keywords.

This example shows how to detach an ACL named my_acl from port 2/1:
Console> (enable) clear qos acl map my_acl 2/1
Hardware programming in progress...
ACL my_acl is detached from port 2/1.
Console> (enable) 
This example shows how to detach an ACL named my_acl from VLAN 4:
Console> (enable) clear qos acl map my_acl 4
Hardware programming in progress...
ACL my_acl is detached from vlan 4.
Console> (enable) 
Note The default ACLs cannot be detached from any interfaces.

Configuring PFC3 Egress DSCP Mutation

These sections describe how to configure PFC3 egress DSCP mutation:

•Configuring a DSCP Mutation Map

•Clearing a Configured DSCP Mutation Map

•Applying a DSCP Mutation Map to a VLAN

•Clearing a DSCP Mutation Map from a VLAN

Configuring a DSCP Mutation Map

PFC3 supports 16 DSCP mutation maps. QoS uses one mutation map for the default mapping. You can configure 15 mutation maps. The mutation maps define the internal DSCP-to-egress DSCP relationships.

To configure a DSCP mutation map, perform this task in privileged mode:

Task

Command

Step 1

Configure a DSCP mutation map.

set qos dscp-mutation-map map_id internal_dscp_list:mutated_dscp...

Step 2

Verify the configuration.

show qos maps {config | runtime} dscp-mutation-map map_id

This example shows how to configure DSCP mutation map 1:
Console> (enable) set qos dscp-mutation-map 1 30:2 
QoS dscp-mutation-map with mutation-table-id 1 has been set correctly.
Console> (enable) 
This example shows how to verify DSCP mutation map 1:
Console> (enable) show qos maps config dscp-mutation-map 1
VLAN ID map:
Map ID  VLANS
------  ----------------------------------------
     1  1,78-1005,1025-4094      
DSCP mutation map 1:
DSCP                              Policed DSCP
--------------------------------------------
0                                     0
1                                     1
2                                     1
3                                     1
4                                     1
5                                     1
6                                     1
7                                     1
8                                     1
9                                     9
10                                    1
11                                    1
12                                   12
13                                   13
14                                   14
15                                   15
59                                   59
60                                   60
61                                   61
62                                   62
63                                   63
Console> (enable) 
Clearing a Configured DSCP Mutation Map

To clear a configured DSCP mutation map, perform this task in privileged mode:

Task

Command

Step 1

Clear a configured DSCP mutation map.

clear qos dscp-mutation-map vlan_mapped_id | all

Step 2

Verify the configuration.

show qos maps {config | runtime} dscp-mutation-map map_id

This example shows how to clear DSCP mutation map 3:
Console> (enable) clear qos dscp-mutation-map 3 
QoS dscp-mutation-map for mutation-table-id 3 is restored to default.
Console> (enable) 
Applying a DSCP Mutation Map to a VLAN

To apply a DSCP mutation map to a VLAN, perform this task in privileged mode:

Task

Command

Step 1

Apply a DSCP mutation map to a VLAN.

set qos dscp-mutation-table-map map_id vlan_list

Step 2

Verify the configuration.

show qos maps {config | runtime} mutation-table-id map_id

This example shows how to apply DSCP mutation map 1 to VLANs 3 and 20 through 30:
Console> (enable) set qos dscp-mutation-table-map 1 3,20-30 
VLAN(s) 3,20-30 are mapped to mutation-table-id 1.
Console> (enable) 
This example shows how to verify the VLAN-to-mutation map mapping:
Console> (enable) show qos maps config mutation-table-id 1
VLAN ID map:
Map ID VLANs
------ -------
1      1,20-30
Clearing a DSCP Mutation Map from a VLAN

To clear a DSCP mutation map from a VLAN, perform this task in privileged mode:

Task

Command

Step 1

Clear a DSCP mutation map from a VLAN.

clear qos dscp-mutation-table-map {map_id | vlan_id | all}

Step 2

Verify the configuration.

show qos maps {config | runtime} dscp-mutation-map map_id

This example shows how to clear the association of any VLANs with DSCP mutation map 2:
Console> (enable) clear qos dscp-mutation-table-map 2 
All VLANS in mutation-table-id 2 are cleared.
This example shows how to clear the association of VLANs 3-33 with any DSCP mutation maps:
Console> (enable) clear qos dscp-mutation-table-map 3-33 
VLAN(s) 3-33 are removed from mutation-table-ids.
This example shows how to clear the association of all VLANs with all DSCP mutation maps:
Console> (enable) clear qos dscp-mutation-table-map all 
All VLANs are removed from mutation-table-ids. 
Configuring CoS-to-CoS Maps on 802.1Q Tunnel Ports

Ingress Cos-to-CoS mapping is supported on 802.1Q tunnel ports on the WS-X6704-10GE, WS-X6724-SFP, and WS-X6748-GE-TX switching modules. CoS-to-CoS mapping is disabled on the ports that are not configured as 802.1Q tunnel ports.

Defining a CoS-to CoS Map

To define a CoS-to-CoS map, perform this task in privileged mode:

Task

Command

Step 1

Define the CoS-to-CoS mapping.

set qos cos-cos-map CoS_value

Step 2

Verify the configuration.

show qos maps cos-cos-map [mod/port]

This example shows how to define the CoS-to-CoS map:
Console> (enable) set qos cos-cos-map 3 2 1 4 5 6 7 4
QoS cos-cos-map set successfully.
Console> (enable) 
Enabling a CoS-to CoS Map on a Port

To enable a CoS-to-CoS map on a port, perform this task in privileged mode:

Task

Command

Step 1

Enable the CoS-to-CoS map on an 802.1Q tunnel port.

set port qos mod/port trust trust-cos

Step 2

Verify the port QoS trust configuration.

show port qos mod/port
Console> (enable) set port qos 1/1 trust trust-cos
Port 1/1 qos set to trust-cos
Console> (enable)

Note The CoS-to-CoS map is automatically disabled when the port trust is not trust-cos for the 802.1Q tunnel ports.

Clearing a CoS-to-CoS Map

To clear a CoS-to-CoS map, perform this task in privileged mode:

Task

Command

Step 1

Clear the CoS-to-CoS map on an 802.1Q tunnel port.

clear qos cos-cos-map

Step 2

Verify the port QoS configuration.

show qos maps cos-cos-map [mod/port]

This example shows how to clear the CoS-to-CoS mapping:
Console> (enable) clear qos cos-cos-map
QoS cos-cos-map setting restored to default.
Console> (enable) 
Mapping a CoS Value to a Host Destination MAC Address/VLAN Pair

Note QoS supports this command only with a Layer 2 Switching Engine.

To map a CoS value to all frames that are destined for a particular host destination MAC address and VLAN number value pair, perform this task in privileged mode:

Task

Command

Step 1

Map a CoS value to a host destination MAC address/VLAN pair.

set qos mac-cos dest_mac VLAN cos_value

Step 2

Verify the configuration.

show qos mac-cos {dest_mac [vlan] | all}

This example shows how to map CoS 2 to a destination MAC address and VLAN 525:
Console> (enable) set qos mac-cos 00-40-0b-30-03-48 525 2
CoS 2 is assigned to 00-40-0b-30-03-48 vlan 525.
Console> (enable) 
Deleting a CoS Value to a Host Destination MAC Address/VLAN Pair

Note QoS supports this command only with a Layer 2 Switching Engine.

To delete a host destination MAC address and VLAN number value pair CoS assignment, perform this task in privileged mode:

Task

Command

Step 1

Delete a host destination MAC address and VLAN number value pair CoS assignment.

clear qos mac-cos {dest_mac [vlan] | all}

Step 2

Verify the configuration.

show qos mac-cos {dest_mac [vlan] | all}

This example shows how to delete all CoS assignments to the destination MAC addresses and VLANs:
Console> (enable) clear qos mac-cos all
All CoS to Mac/Vlan entries are cleared.
Console> (enable) 
Enabling or Disabling Microflow Policing of Bridged Traffic

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

By default, the microflow policers affect only the Layer 3-switched traffic. To enable or disable microflow policing of the bridged traffic on the switch or on specified VLANs, perform one of these tasks in privileged mode:

Task

Command

Enable microflow policing of the bridged traffic on the switch or on the specified VLANs.

set qos bridged-microflow-policing {enable | disable} vlan

Disable microflow policing of the bridged traffic on the switch or on the specified VLANs.

set qos bridged-microflow-policing {enable | disable} vlan

Verify the configuration.

show qos bridged-microflow-policing runtime {config | runtime} vlan

Note With Layer 3 Switching Engine II, to do any microflow policing, you must enable microflow policing of the bridged traffic.

For more information, see the "Policers" section.

This example shows how to enable microflow policing of the traffic in VLANs 1-20:
Console> (enable) set qos bridged-microflow-policing enable 1-20
QoS microflow policing is enabled for bridged packets on vlans 1-20.
Console> (enable) 
Configuring the Standard Receive-Queue Tail-Drop Thresholds

To configure the standard receive-queue tail-drop thresholds on the switch, perform this task in privileged mode:

Task

Command

Configure the standard receive-queue tail-drop thresholds.

set qos drop-threshold port_type rx queue 1 thr1 thr2 thr3 thr4

For more information, see the "Receive Queues" section.

QoS maintains separate configurations for the 1q2t, 1q4t, and 1p1q4t ports. This command configures the standard queue. Specify queue 1 (the threshold in the strict-priority queue, when present, is not separately configurable; it uses threshold 4 as specified for queue 1).

The thresholds are all specified as percentages ranging from 1-100. A value of 10 indicates a threshold when the buffer is 10 percent full.

This example shows how to configure the standard receive-queue tail-drop thresholds:
Console> (enable) set qos drop-threshold 1q4t rx queue 1 20 40 75 100
Receive drop thresholds for queue 1 set at 20% 40% 75% 100%
Console> (enable) 
Note You cannot configure a drop threshold in a 1p1q0t receive queue.

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

To configure the standard transmit-queue tail-drop thresholds on all 2q2t ports, perform this task in privileged mode:

Task

Command

Configure the standard transmit-queue tail-drop thresholds on all 2q2t ports.

set qos drop-threshold port_type tx queue q# thr1 thr2

Queue number 1 is the low-priority transmit queue, and queue number 2 is high priority. In each queue, the low-priority threshold number is 1 and the high-priority threshold number is 2.

The thresholds are all specified as percentages ranging from 1-100. A value of 10 indicates a threshold when the buffer is 10 percent full.

This example shows how to configure the low-priority transmit-queue tail-drop thresholds:
Console> (enable) set qos drop-threshold 2q2t tx queue 1 40 100
Transmit drop thresholds for queue 1 set at 40%  100%
Console> (enable) 
Note You cannot configure the tail-drop thresholds in 1p3q1t transmit queues.

Configuring the Standard Queue WRED-Drop Thresholds

The 1p1q8t ports have weighted random early detection (WRED)-drop thresholds in their standard receive queue.

The 1p2q2t, 1p3q1t, 1p2q1t, 1p3q8t, and 1p7q8t ports have WRED-drop thresholds in their standard transmit queues.

Note The 1p7q8t (transmit), 1p3q1t (transmit), 1p2q1t (transmit), and 1p1q8t (receive) ports also have nonconfigurable tail-drop thresholds.

To configure the standard queue WRED-drop thresholds on all ports of each type, perform this task in privileged mode:

Task

Command

Configure the standard queue WRED-drop thresholds on all ports of a given type.

set qos wred 1p1q8t rx queue q# [thr1Lo:]thr1Hi [thr2Lo:]thr2Hi [thr_n_Lo:]thr_n_Hi... [thr8Lo:]thr8Hi

set qos wred 1p7q8t tx queue q# [thr1Lo:]thr1Hi [thr2Lo:]thr2Hi [thr_n_Lo:]thr_n_Hi... [thr8Lo:]thr8Hi

set qos wred 1p3q8t tx queue q# [thr1Lo:]thr1Hi [thr2Lo:]thr2Hi [thr_n_Lo:]thr_n_Hi... [thr8Lo:]thr8Hi

set qos wred 1p2q2t tx queue q# [thr1Lo:]thr1Hi [thr2Lo:]thr2Hi

set qos wred 1p3q1t tx queue q# [thr1Lo:]thr1Hi

set qos wred 1p2q1t tx queue q# [thr1Lo:]thr1Hi

When configuring the 1p1q8t ports, note the following:

•Queue 1 is the single standard receive queue.

•When you configure the single standard receive queue, note the following:

–The first percentage that you enter sets the lowest-priority threshold.

–The second percentage that you enter sets the next highest-priority threshold.

–The eighth percentage that you enter sets the highest-priority threshold.

When configuring the 1p7q8t ports, note the following:

•Queue 1 is the lowest-priority standard transmit queue.

•Queue 7 is the highest-priority standard transmit queue.

•When configuring each standard transmit queue, note the following:

–The first percentage that you enter sets the lowest-priority threshold.

–The second percentage that you enter sets the next highest-priority threshold.

–The eighth percentage that you enter sets the highest-priority threshold.

When configuring the 1p3q8t ports, note the following:

•Queue 1 is the low-priority standard transmit queue.

•Queue 2 is the medium-priority standard transmit queue.

•Queue 3 is the high-priority standard transmit queue.

•When configuring each standard transmit queue, note the following:

–The first percentage that you enter sets the lowest-priority threshold.

–The second percentage that you enter sets the next highest-priority threshold.

–The eighth percentage that you enter sets the highest-priority threshold.

When configuring the 1p2q2t ports, note the following:

•Queue 1 is the low-priority standard transmit queue.

•Queue 2 is the high-priority standard transmit queue.

•When configuring each standard transmit queue, note the following:

–The first percentage that you enter sets the low-priority threshold.

–The second percentage that you enter sets the high-priority threshold.

When configuring the 1p3q1t ports, note the following:

•Queue 1 is the low-priority standard transmit queue.

•Queue 2 is the medium-priority standard transmit queue.

•Queue 3 is the high-priority standard transmit queue.

•When you configure each standard transmit queue, the single percentage that you enter sets the threshold.

When configuring the 1p2q1t ports, note the following:

•Queue 1 is the low-priority standard transmit queue.

•Queue 2 is the high-priority standard transmit queue.

•When you configure each standard transmit queue, the single percentage that you enter sets the threshold.

When configuring thresholds, note the following:

•The thresholds are all specified as percentages ranging from 0-100. A value of 10 indicates a threshold when the buffer is 10 percent full.

•You can configure both the low WRED threshold and the high WRED threshold. You must set the low threshold to a lower percentage than the high threshold.

•The low WRED threshold is the traffic level under which no traffic is dropped. The high WRED threshold is the traffic level above which all traffic is dropped. The traffic in the queue between the low and high WRED thresholds has an increasing chance of being dropped as the queue fills. The default low WRED threshold is zero (all traffic has some chance of being dropped).

This example shows how to configure the low-priority transmit-queue WRED-drop thresholds:
Console> (enable) set qos wred 1p2q2t queue 1 40:70 70:100 
WRED thresholds for queue 1 set to 40:70 and 70:100 on all WRED-capable 1p2q2t ports.
Console> (enable)
Note The threshold in the strict-priority queue is not configurable.

Allocating Bandwidth Between the Standard Transmit Queues

The switch transmits frames from one standard queue at a time using one of these dequeuing algorithms, which use weights to allocate relative bandwidth to each queue as it is serviced in a round-robin fashion:

•Shaped round robin (SRR)—Supported as an option on Supervisor Engine 32 1p3q8t ports. If you do not enable SRR, DWRR is used. SRR only allows a queue to use the specific amount of bandwidth that the weight allocates.

•Deficit weighted round robin (DWRR)—Supported on 1p3q1t, 1p2q1t, 1p3q8t, and 1p7q8t ports. DWRR keeps track of any low-priority queue under-transmission and compensates in the next round.

•Weighted round robin (WRR)—Supported on all other ports. WRR allows a queue to use more than the allocated bandwidth if the other queues are not using any, up to the total bandwidth of the port.

The higher the weight that is assigned to a queue, the more transmit bandwidth is allocated to it. The ratio of the weights divides the total bandwidth of the queue. For example, for three queues on a Gigabit Ethernet port, weights of 25:25:50 provide this division:

•Queue 1—250 Mbps

•Queue 2—250 Mbps

•Queue 3—500 Mbps

Note The actual bandwidth division depends on the granularity that the port hardware applies to the configured weights.

To allocate the bandwidth between the standard transmit queues, perform this task in privileged mode:

Task

Command

Allocate the bandwidth between the standard transmit queues.

set qos wrr port_type queue1-weight queue2-weight [queue3-weight] [srr]

The valid values for the port_type parameter are 2q2t, 1p2q2t, 1p3q1t, 1p2q1t, 1p3q8t, and 1p7q8t.

QoS maintains separate configurations for each port type. This command configures only the standard queues; the strict-priority queue requires no configuration. The valid values for weight range from 1-255.

This example shows how to allocate the bandwidth for the 2q2t ports:
Console> (enable) set qos wrr 2q2t 30 70
QoS wrr ratio is set successfully.
Console> (enable) 
Configuring the Receive-Queue Size Ratio

For the 1p1q0t and 1p1q8t ports, estimate the mix of standard-priority and strict-priority traffic on your network (for example, 85 percent standard-priority traffic and 15 percent strict-priority traffic). Specify the queue ratios with the estimated percentages, which must range from 1- 99 and together add up to 100.

To configure the receive-queue size ratio, perform this task in privileged mode:

Task

Command

Configure the receive-queue size ratio between receive queue 1 (standard priority) and receive queue 2 (strict priority).

set qos rxq-ratio {1p1q0t | 1p1q8t} queue1-val queue2-val

This example shows how to configure the receive-queue size ratio:
Console> (enable) set qos rxq-ratio 1p1q0t 80 20
QoS rxq-ratio is set successfully.
Console> (enable) 
Configuring the Transmit-Queue Size Ratio

For the 2q2t, 1p2q2t, 1p2q1t, 1p3q8t, and 1p7q8t ports, estimate the mix of the traffic of various priorities on your network (for example, 75 percent low-priority traffic, 15 percent high-priority traffic, and 10 percent strict-priority traffic). Specify the queue ratios with the estimated percentages, which must range from 1- 99 and together add up to 100.

To configure the transmit-queue size ratio for each port type, perform this task in privileged mode:

Task

Command

Configure the transmit-queue size ratio.

set qos txq-ratio {2q2t | 1p2q2t | 1p2q1t | 1p3q8t | 1p7q8t} queue1-val queue2-val [queue3-val [queue4-val]]

This example shows how to configure the transmit-queue size ratio:
Console> (enable) set qos txq-ratio 2q2t 80 20
QoS txq-ratio is set successfully.
Console> (enable) 
Mapping the CoS Values to the Drop Thresholds

This command associates the CoS values with the receive- and transmit-queue drop thresholds. QoS maintains separate configurations for each port type.

These sections describe how to map the CoS values to the drop thresholds:

•Associating the 1q4t/2q2t Ports

•Associating the 1q8t, 1q2t/1p2q2t, and 1p1q4t/1p2q2t Ports

•Associating the 1p1q0t/1p3q1t Ports

•Associating the 1p1q8t/1p2q1t, 1p3q8t, and 1p7q8t Ports

•Reverting to the CoS Map Default

Associating the 1q4t/2q2t Ports

On the 1q4t/2q2t ports, you configure the receive queues and the transmit queues with the same command.

To associate the CoS values to the drop thresholds on the 1q4t/2q2t ports, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a drop threshold.

set qos map 2q2t tx q# thr# cos coslist

Step 2

Verify the configuration.

show qos info config {1q4t rx | 2q2t tx}

The receive- and transmit-drop thresholds have this relationship:

•Receive queue 1 (standard) threshold 1 = transmit queue 1 (standard low priority) threshold 1

•Receive queue 1 (standard) threshold 2 = transmit queue 1 (standard low priority) threshold 2

•Receive queue 1 (standard) threshold 3 = transmit queue 2 (standard high priority) threshold 1

•Receive queue 1 (standard) threshold 4 = transmit queue 2 (standard high priority) threshold 2

Use the transmit queue and transmit-queue drop-threshold values in this command. This example shows how to associate the CoS values 0 and 1 to both the standard receive-queue 1/threshold 1 and the standard transmit-queue 1/threshold 1:
Console> (enable) set qos map 2q2t tx 1 1 cos 0,1
Qos tx priority queue and threshold mapped to cos successfully.
Console> (enable) 
Associating the 1q8t, 1q2t/1p2q2t, and 1p1q4t/1p2q2t Ports

On the 1q8t, 1q2t/1p2q2t and 1p1q4t/1p2q2t ports, you configure the receive queues and the transmit queues separately.

1q8t Receive Queues

To associate the CoS values to the 1q8t receive-queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a receive-queue drop threshold.

set qos map 1q8t rx 1 thr# cos coslist

Step 2

Verify the configuration.

show qos info config 1q2t rx

Threshold 1 is the lowest-priority threshold. The priority increases with the threshold number.

This example shows how to associate the CoS value 3 to threshold 2:
Console> (enable) set qos map 1q8t rx 1 2 cos 3
QoS rx priority queue and threshold mapped to cos successfully.
Console> (enable) 
1q2t Receive Queues

To associate the CoS values to the 1q2t receive-queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a receive-queue drop threshold.

set qos map 1q2t rx 1 1 cos coslist

Step 2

Verify the configuration.

show qos info config 1q2t rx

Threshold 1 is the low-priority threshold. Threshold 2, which is the high-priority threshold, is not configurable.

This example shows how to associate the CoS value 3 to threshold 1:
Console> (enable) set qos map 1q2t rx 1 1 cos 3
QoS rx priority queue and threshold mapped to cos successfully.
Console> (enable) 
1p1q4t Receive Queues

To associate the CoS values to the 1p1q4t receive-queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a receive-queue drop threshold.

set qos map 1p1q4t rx q# thr# cos coslist

Step 2

Verify the configuration.

show qos info config 1p1q4t rx

Queue 1 is the standard queue. Queue 2 is the strict-priority queue.

The threshold numbers range from 1 for low priority to 4 for high priority.

This example shows how to associate the CoS value 5 to the strict-priority receive-queue 2/threshold 1:
Console> (enable) set qos map 1p1q4t rx 2 1 cos 5
Qos rx strict queue and threshold mapped to cos successfully.
Console> (enable) 
1p2q2t Transmit Queues

To associate the CoS values to the 1p2q2t transmit-queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a transmit-queue drop threshold.

set qos map 1p2q2t tx q# thr# cos coslist

Step 2

Verify the configuration.

show qos info config 1p2q2t tx

Queue 1 is standard low priority, queue 2 is high priority, and queue 3 is strict priority.

Threshold 1 is low priority, and threshold 2 is high priority.

This example shows how to associate the CoS value 5 to the strict-priority transmit-queue 3/drop threshold 1:
Console> (enable) set qos map 1p2q2t tx 3 1 cos 5
Qos tx strict queue and threshold mapped to cos successfully.
Console> (enable) 
Associating the 1p1q0t/1p3q1t Ports

On the 1p1q0t/1p3q1t ports, you configure the receive queues and the transmit queues separately.

1p1q0t Receive Queues

To associate the CoS values to the 1p1q0t receive queues, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a receive queue.

set qos map 1p1q0t rx q# cos coslist

Step 2

Verify the configuration.

show qos info config 1p1q0t rx

Queue 1 is the standard queue, and queue 2 is the strict-priority queue.

This example shows how to associate the CoS value 5 to the strict-priority receive-queue 2:
Console> (enable) set qos map 1p1q0t rx 2 cos 5
QoS queue mapped to cos successfully.
Console> (enable) 
1p3q1t Transmit Queues

With the 1p3q1t transmit queues, you can associate a CoS value with either the nonconfigurable tail-drop threshold or the configurable WRED-drop threshold as follows:

•To associate the CoS value with the tail-drop threshold, map the CoS value to the queue.

•To associate the CoS value with the WRED-drop threshold, map the CoS value to the queue and threshold.

To associate the CoS values to the 1p3q1t transmit-queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a transmit-queue drop threshold.

set qos map 1p3q1t tx q# [thr#] cos coslist

Step 2

Verify the configuration.

show qos info config 1p3q1t tx

Queue 1 is the standard low priority, queue 2 is medium priority, queue 3 is high priority, and queue 4 is strict priority.

To map the CoS values to the tail-drop threshold, omit the threshold number or enter 0.

The WRED-drop threshold number is 1.

This example shows how to associate the CoS value 0 to the transmit-queue 1/drop threshold 1:
Console> (enable) set qos map 1p3q1t tx 1 1 cos 0
Qos tx strict queue and threshold mapped to cos successfully.
Console> (enable) 
Associating the 1p1q8t/1p2q1t, 1p3q8t, and 1p7q8t Ports

When you configure the 1p1q8t/1p2q1t and 1p3q8t ports, note the following:

•You configure the receive queues and the transmit queues separately.

•You can associate a CoS value with either the nonconfigurable tail-drop threshold or the configurable WRED-drop threshold:

–To associate a CoS value with the tail-drop threshold, map the CoS value to the queue.

–To associate a CoS value with the WRED-drop threshold, map the CoS value to the queue and threshold.

1p1q8t Receive Queues

To associate the CoS values to the 1p1q8t receive queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a receive queue.

set qos map 1p1q8t rx q# [thr#] cos coslist

Step 2

Verify the configuration.

show qos info config 1p1q8t rx

On the 1p1q8t ports, queue 1 is the standard receive queue, and queue 2 is the strict-priority receive queue.

To map the CoS values to a tail-drop threshold, omit the threshold number or enter 0.

This example shows how to associate the CoS value 5 to the strict-priority receive-queue 2:
Console> (enable) set qos map 1p1q8t rx 2 cos 5
QoS queue mapped to cos successfully.
Console> (enable) 
1p2q1t, 1p3q8t, and 1p7q8t Transmit Queues

To associate the CoS values to the 1p2q1t, 1p3q8t, or 1p7q8t transmit-queue drop thresholds, perform this task in privileged mode:

Task

Command

Step 1

Associate the CoS value to a transmit-queue drop threshold.

set qos map [1p2q1t | 1p3q8t | 1p7q8t] tx q# [thr#] cos coslist

Step 2

Verify the configuration.

show qos info config 1p2q1t tx

On the 1p2q1t ports, queue 1 is the low-priority standard transmit queue, queue 2 is the high-priority standard transmit queue, and queue 3 is the strict-priority transmit queue.

On the 1p3q8t ports, queue 1 is the low-priority standard transmit queue, queue 2 is the medium-priority standard transmit queue, queue 3 is the high-priority standard transmit queue, and queue 4 is the strict-priority transmit queue.

On the 1p7q8t ports, queue 1 is the lowest-priority standard transmit queue, queue 7 is the highest-priority standard transmit queue, and queue 8 is the strict-priority transmit queue.

To map the CoS values to the tail-drop threshold, omit the threshold number or enter 0.

This example shows how to associate the CoS value 0 to the transmit-queue 1/drop threshold 1:
Console> (enable) set qos map 1p2q1t tx 1 1 cos 0
Qos tx strict queue and threshold mapped to cos successfully.
Console> (enable) 
Reverting to the CoS Map Default

To revert to the default CoS value/drop threshold mapping, perform this task in privileged mode:

Task

Command

Step 1

Revert to the QoS map defaults.

clear qos map {1p1q4t rx | 1p1q0t rx | 1p2q2t tx | 2q2t tx | 1p3q1t tx | 1q8t rx | 1p3q8t tx | 1p7q8t tx}

Step 2

Verify the configuration.

show qos info config {1q4t rx | 1p1q4t rx | 1p1q0t rx | 1p1q8t rx | 1p2q2t tx | 2q2t tx | 1p3q1t tx | 1p2q1t tx | 1q8t rx | 1p3q8t tx | 1p7q8t tx}

This example shows how to revert to the QoS map defaults:
Console> (enable) clear qos map 1p3q1t tx
Qos map setting cleared.
Console> (enable) 
Configuring the DSCP Value Maps

Note Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

These sections describe how the DSCP values are mapped to other values:

•Mapping the Received CoS Values to the Internal DSCP Values

•Mapping the Received IP Precedence Values to the Internal DSCP Values

•Mapping the Internal DSCP Values to the Egress CoS Values

•Mapping the DSCP Markdown Values

Mapping the Received CoS Values to the Internal DSCP Values

To map the received CoS values to the internal DSCP value (see the "Internal DSCP Values" section), perform this task in privileged mode:

Task

Command

Step 1

Map the received CoS values to the internal DSCP values.

set qos cos-dscp-map dscp1 dscp2 dscp3 dscp4 dscp5 dscp6 dscp7 dscp8

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

Enter 8 DSCP values to which the QoS maps received CoS values 0-7. This example shows how to map the received CoS values to the internal DSCP values:
Console> (enable) set qos cos-dscp-map 20 30 1 43 63 12 13 8
QoS cos-dscp-map set successfully.
Console> (enable) 
To revert to the default CoS to DSCP value mapping, perform this task in privileged mode:

Task

Command

Step 1

Revert to the CoS value/DSCP value map defaults.

clear qos cos-dscp-map

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to the CoS-DSCP map defaults:
Console> (enable) clear qos cos-dscp-map
QoS cos-dscp-map setting restored to default.
Console> (enable) 
Mapping the Received IP Precedence Values to the Internal DSCP Values

To map the received IP precedence values to the internal DSCP value (see the "Internal DSCP Values" section), perform this task in privileged mode:

Task

Command

Step 1

Map the received IP precedence values to the internal DSCP values.

set qos ipprec-dscp-map dscp1 dscp2 dscp3 dscp4 dscp5 dscp6 dscp7 dscp8

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

Enter 8 internal DSCP values to which QoS maps received IP precedence values 0-7. This example shows how to map the received IP precedence values to the internal DSCP values:
Console> (enable) set qos ipprec-dscp-map 20 30 1 43 63 12 13 8
QoS ipprec-dscp-map set successfully.
Console> (enable) 
To revert to the default IP precedence-to-DSCP value mapping, perform this task in privileged mode:

Task

Command

Step 1

Revert to the default IP precedence-to-DSCP value mapping.

clear qos ipprec-dscp-map

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to the QoS map defaults:
Console> (enable) clear qos ipprec-dscp-map
QoS ipprec-dscp-map setting restored to default.
Console> (enable) 
Mapping the Internal DSCP Values to the Egress CoS Values

To map the internal DSCP values to the egress CoS values that are used for egress port scheduling and congestion avoidance, perform this task in privileged mode:

Task

Command

Step 1

Map the internal DSCP values to the egress CoS values.

set qos dscp-cos-map dscp_list:cos ...

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

For more information, see the "Internal DSCP Values" section and the "Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking" section.

Enter up to 64 internal DSCP value list/egress CoS value pairs. This example shows how to map the internal DSCP values to the egress CoS values:
Console> (enable) set qos dscp-cos-map 20-25:7 33-38:3
QoS dscp-cos-map set successfully.
Console> (enable) 
To revert to the default CoS-to-DSCP value mapping, perform this task in privileged mode:

Task

Command

Step 1

Revert to the DSCP value/CoS value map defaults.

clear qos dscp-cos-map

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to the CoS-to-DSCP map defaults:
Console> (enable) clear qos dscp-cos-map
QoS dscp-cos-map setting restored to default.
Console> (enable) 
Mapping the DSCP Markdown Values

To map the DSCP markdown values that are used by the policers, perform this task in privileged mode:

Task

Command

Step 1

Map the DSCP values to mark down the DSCP values.

set qos policed-dscp-map dscp_list:markdown_dscp ...

Step 2

With PFC2, map the DSCP values to the markdown DSCP values.

set qos policed-dscp-map [normal | excess]
in_profile_dscp_list:policed_dscp ...

Step 3

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

For more information, see the "Policers" section.

Enter up to 64 DSCP-value-list/DSCP-value pairs.

This example shows how to map the DSCP markdown values:
Console> (enable) set qos policed-dscp-map 20-25:7 33-38:3
QoS dscp-dscp-map set successfully.
Console> (enable) 
This example shows how to map the DSCP markdown values for the packets exceeding the excess rate:
Console> (enable) set qos policed-dscp-map 33:30
QoS normal-rate policed-dscp-map set successfully.
Console> (enable) set qos policed-dscp-map excess-rate 33:30
QoS excess-rate policed-dscp-map set successfully.
Console> (enable) 
Note Configure the marked-down DSCP values that map to the CoS values that are consistent with the markdown penalty (see the "Mapping the Internal DSCP Values to the Egress CoS Values" section).

To revert to the default DSCP markdown value mapping, perform this task in privileged mode:

Task

Command

Step 1

Revert to the DSCP markdown map defaults.

clear qos policed-dscp-map [normal-rate | excess-rate]

Step 2

Verify the configuration.

show qos maps {config | runtime} [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to the DSCP markdown map defaults:
Console> (enable) clear qos policed-dscp-map
QoS dscp-cos-map setting restored to default.
Console> (enable) 
Note Without the normal-rate or the excess-rate keywords, the clear qos policed-dscp-map command clears only the normal policed-dscp map.

Displaying QoS Information

To display the QoS information, perform this task:

Task

Command

Display the QoS information.

show qos info [runtime | config]

This example shows how to display the QoS runtime information for port 2/1:
Console> show qos info config 2/1
QoS setting in NVRAM:
QoS is enabled
Port 2/1 has 2 transmit queue with 2 drop thresholds (2q2t).
Port 2/1 has 1 receive queue with 4 drop thresholds (1q4t).
Interface type:vlan-based
ACL attached:
The qos trust type is set to untrusted.
Default CoS = 0
Queue and Threshold Mapping:
Queue Threshold CoS
----- --------- ---------------
1     1         0 1
1     2         2 3
2     1         4 5
2     2         6 7
Rx drop thresholds:
Rx drop thresholds are disabled for untrusted ports.
Queue #  Thresholds - percentage (abs values )
-------  -------------------------------------
1        50% 60% 80% 100%
Tx drop thresholds:
Queue #  Thresholds - percentage (abs values )
-------  -------------------------------------
1        40% 100%
2        40% 100%
Tx WRED thresholds:
WRED feature is not supported for this port_type.
Queue Sizes:
Queue #  Sizes - percentage (abs values )
-------  -------------------------------------
1        80%
2        20%
WRR Configuration of ports with speed 1000Mbps:
Queue #  Ratios (abs values )
-------  -------------------------------------
1        100
2        255
Console> (enable)
Displaying the QoS Statistics

To display the QoS statistics, perform this task:

Task

Command

Display the QoS statistics.

show qos statistics {mod[/port] | l3stats | aggregate-policer [policer_name]}

This example shows how to display the QoS statistics for port 2/1:
Console> (enable) show qos statistics 5/1
Tx port type of port 5/1 : 2q2t
Q#   Threshold#      Packets            Average Packet      Peak Packet
                     dropped (pkts)     drop rate (pps)     drop rate (pps)
--   ----------      --------------     ---------------     ---------------
1         1           963646               2052                 4369
1         2                0                  0                    0
2         1                0                  0                    0
2         2                0                  0                    0
Rx port type of port 5/1 : 1q4t
For untrusted ports all the packets are sent to the same queue,
Rx thresholds are disabled, tail drops are reported instead.
Q#   Threshold#      Packets            Average Packet      Peak Packet
                     dropped (pkts)     drop rate (pps)     drop rate (pps)
--   ----------      --------------     ---------------     ---------------
1    1                           0                   0                   0
1    2                           0                   0                   0
1    3                           0                   0                   0
1    4                           0                   0                   0
This example shows how to display the QoS Layer 3 statistics:
Console> (enable) show qos statistics l3stats 
                                       Total packets Average      Peak Rate
                                                     Rage(pps)   (pps)
                                  ---------------   ----------    --------
Packets dropped due to policing:       621085       1289          3618
IP packets with ToS changed:           4495508      9937         18507
IP packets with CoS changed:           4495508      9937         18507
Non-IP packets with CoS changed:             0         0             0
Console> (enable)
This example shows how to display the QoS aggregate policer statistics:
Console> (enable) show qos statistics aggregate-policer ag1
QoS aggregate-policer statistics:
Aggregate policer              Allowed packet Packets exceed
                                   count          excess rate
--------------------             --------------- ------------
ag1                                2171253          411450
QoS aggregate-policer average rate statistics over 5 minutes:
Aggregate policer              Allowed packet   Traffic exceeding
                                   count          excess rate
--------------------             --------------- --------------
ag1                                5399          1024
QoS aggregate-policer peak rate statistics over 5 minutes:
(collected every 30 seconds)
Aggregate policer        Peak Allowed
                         rate (pps)
---------------       --------------
ag1                      20802
For PFC3B- or PFC3BXL-based switches, the peak allowed packet count rate will not be displayed. The peak byte count rate will be displayed as shown here:
Console> (enable) show qos statistics aggregate-policer ag1
QoS aggregate-policer statistics:
Aggregate policer              Allowed byte    Bytes exceed
                                   count         excess rate
--------------------           --------------   ------------
ag1                            9992929900        2819929466
QoS aggregate-policer average rate statistics over 5 minutes:
Aggregate policer               Allowed rate              Traffic exceeding
                                  (kbps)                 excess rate (kbps)
------------------------------- ----------------    ------------------------
ag1                               152080                         42911
QoS aggregate-policer peak rate statistics over 5 minutes:
(collected every 30 seconds)
Aggregate policer        Peak Allowed
                         rate (pps)
---------------       --------------
ag1                        218912
Reverting to the QoS Defaults

Note Reverting to the defaults disables QoS, because QoS is disabled by default.

To revert to the QoS defaults, perform this task in privileged mode:

Task

Command

Revert to the QoS defaults.

clear qos config

This example shows how to revert to the QoS defaults:
Console> (enable) clear qos config
This command will disable QoS and take values back to factory default.
Do you want to continue (y/n) [n]? y
QoS config cleared.
Console> (enable) 
Disabling QoS

To disable QoS, perform this task in privileged mode:

Task

Command

Disable QoS on the switch.

set qos {enable | disable}

This example shows how to disable QoS:
Console> (enable) set qos disable
QoS is disabled.
Console> (enable) 
Configuring COPS Support

Note•Supervisor Engine 1 with a Layer 2 Switching Engine does not support the commands in this section.

•COPS can configure QoS only for the IP traffic. Use the CLI or SNMP to configure QoS for all the other traffic.

•Throughout this publication and all Catalyst 6500 series publications, the term COPS refers to COPS support as implemented on the Catalyst 6500 series switches.

These sections describe configuring COPS support:

•Port ASICs

•Understanding QoS Policy

•Selecting COPS as the QoS Policy Source

•Selecting the Locally Configured QoS Policy

•Enabling Use of the Locally Configured QoS Policy

•Assigning a Port Role

•Removing a Role from the Port ASICs

•Deleting a Role

•Configuring the Policy Decision Point Servers

•Deleting the PDP Server Configuration

•Configuring the COPS Domain Name

•Deleting the COPS Domain Name

•Configuring the COPS Communications Parameters

Port ASICs

Some COPS support features affect all ports that are controlled by a port ASIC. The following sections use the term per-ASIC to identify the features that configure all ports on the same port ASIC:

•The port ASICs on the Gigabit Ethernet switching modules control up to 4 ports each: 1-4, 5-8, 9-12, and 13-16.

•A port ASIC on the 10-Mbps, 10/100-Mbps, and 100-Mbps Ethernet switching modules controls all ports.

•On the 10-Mbps, 10/100-Mbps, and 100-Mbps Ethernet switching modules, another set of port ASICs control 12 ports each (1-12, 13-24, 25-36, and 37-48), but COPS cannot configure them.

•Changes to an EtherChannel port apply to all ports in the EtherChannel and to all ports that are controlled by the ASIC (or ASICs) that control the EtherChannel ports.

Understanding QoS Policy

The term QoS policy refers to the QoS values in effect, such as port trust state and which ACLs are applied to the ports and the VLANs.

Selecting COPS as the QoS Policy Source

QoS uses the locally configured QoS values as the default QoS policy source. To select COPS as the QoS policy source, perform this task in privileged mode:

Task

Command

Step 1

Select COPS as the QoS policy source.

set qos policy-source {local | cops}

Step 2

Verify the QoS policy source.

show qos policy-source

This example shows how to select COPS as the QoS policy source:
Console> (enable) set qos policy-source cops 
QoS policy source for the switch set to COPS.
Console> (enable) show qos policy-source
QoS policy source for the switch set to COPS.
Console> (enable) 
Selecting COPS as the QoS policy source switches the following values from the locally configured values to the received COPS values:

•All DSCP maps

•Named and default ACL definitions

•Microflow and aggregate policers

•CoS-to-queue assignments

•Threshold configuration

•WRR weight and buffer configuration

•Default port CoS and ACL-to-interface attachments

Selecting the Locally Configured QoS Policy

To select the locally configured QoS policy, perform this task in privileged mode:

Task

Command

Step 1

Select the locally configured QoS policy.

set qos policy-source {local | cops}

Step 2

Verify the QoS policy source.

show qos policy-source

This example shows how to select the locally configured QoS policy:
Console> (enable) set qos policy-source local 
QoS policy source for the switch set to local.
Console> (enable) show qos policy-source
QoS policy source for the switch set to local.
Console> (enable) 
Enabling Use of the Locally Configured QoS Policy

When enabled, COPS is the default QoS policy source for all ports. You can use a locally configured QoS policy on a per-ASIC basis. To enable use of the locally configured QoS policy on a port ASIC, perform this task in privileged mode:

Task

Command

Step 1

Enable use of the locally configured QoS policy on a port.

set port qos policy-source {local | cops}

Step 2

Verify the QoS policy source for the port.

show port qos

This example shows how to enable use of the locally configured QoS policy:
Console> (enable) set port qos 1/1 policy-source local
QoS policy source set to local on port(s) 1/1-2.
Console> (enable) 
Assigning a Port Role

COPS does not configure the ports using the slot number and port number parameters. COPS uses roles that you create and assign to the port ASICs.

A role is a name that describes the capability of the ports (for example, access or mod2_1-4). QoS supports 64 roles per switch. You can assign more than one role to a port ASIC (for example, mod2ports1-12 and access), with the limitation that the combined length of the role names that are assigned to a port ASIC cannot exceed 255 characters.

The role name can be up to 31 characters, is not case sensitive but may include uppercase and lowercase characters, and may consist of a-z, A-Z, 0-9, the dash character (-), the underscore character (_), and the period character (.). The role names cannot start with the underscore character.

The first assignment of a new role to a port creates the role.

To assign the roles to a port ASIC, perform this task in privileged mode:

Task

Command

Step 1

Assign the roles to a port ASIC.

set port cops {mod/port} roles role1 [role2] ...

Step 2

Verify the roles for the port.

show port cops [mod[/port]]

This example shows how to assign two new roles to the ASIC controlling port 2/1:
Console> (enable) set port cops 2/1 roles mod2ports1-12 access
New role `mod2ports1-12' created.
New role `access' created.
Roles added for port 2/1-12.
Console> (enable)
Removing a Role from the Port ASICs

To remove a role from a port ASIC, perform this task in privileged mode:

Task

Command

Step 1

Remove a role from a port ASIC.

clear port cops {mod/port} {all-roles | roles role1 [role2] ...}

Step 2

Verify the roles for the port.

show port cops [mod[/port]]

This example shows how to remove a role from a port ASIC:
Console> (enable) clear port cops 3/1 roles backbone_port main_port
Roles cleared for port(s) 3/1-4.
Console> (enable) 
Deleting a Role

To delete a role (which removes it from all ports), perform this task in privileged mode:

Task

Command

Step 1

Delete a role.

clear cops {all-roles | roles role1 [role2] ...}

Step 2

Verify the roles for the port.

show port cops [mod[/port]]

This example shows how to delete a role:
Console> (enable) clear cops roles backbone_port main_port
Roles cleared.
Console> (enable) 
Configuring the Policy Decision Point Servers

Note COPS and RSVP can use the same policy decision point (PDP) server.

COPS obtains the QoS policy from a PDP server. Configure a primary PDP server and optionally, a backup PDP server.

To configure a PDP server, perform this task in privileged mode:

Task

Command

Step 1

Configure a PDP server.

set cops server ip_address [port] [primary] [diff-serv | rsvp]

Step 2

Verify the PDP server configuration.

show cops info

The ip_address parameter can be the IP address or the name of the server.

The port variable is the PDP server TCP port number.

Use the diff-serv keyword to set the address only for COPS.

This example shows how to configure a PDP server:
Console> (enable) set cops server my_server1 primary
my_server1 added to the COPS diff-serv server table as primary server.
my_server1 added to the COPS rsvp server table as primary server.
Console> (enable)
Deleting the PDP Server Configuration

To delete the PDP server configuration, perform this task in privileged mode: