cc/td/doc/product/lan/cat6000/sw_5_5
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring Quality of Service

Configuring Quality of Service

This chapter describes how to configure the quality of service (QoS) feature on the Catalyst 6000 family switches.


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

This chapter consists of these sections:


Note   You can configure QoS using SNMP, Common Open Policy Service for Differentiated Services (COPS-DS) protocol (and through COPS-DS, Resource ReSerVation Protocol [RSVP] null service template and receiver proxy functionality), and the command-line interface (CLI). This chapter describes QoS configuration using the CLI, including the configuration required to support COPS-DS (see the "Configuring COPS-DS Support" section) and RSVP (see the "Configuring RSVP Support" section). COPS-DS can configure QoS only for IP traffic. Use the CLI or SNMP to configure QoS for all other traffic.

Understanding How QoS Works


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

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

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

There are three ways to configure QoS on the Catalyst 6000 family switches:

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

These sections describe QoS:

Definitions

This section defines some QoS terminology.

Flowcharts

Figure 35-1 illustrates traffic flow through the QoS features; Figure 35-2 through Figure 35-7 show more details of the traffic flow through QoS features.


Figure 35-1: Traffic Flow Through QoS Features



Note   Traffic that is Layer 3 switched does not go through the Multilayer Switch Feature Card (MSFC) and retains the CoS value assigned by the Layer 3 switching engine.


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



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


Figure 35-3:
Layer 3 Switching Engine Classification, Marking, and Policing



Figure 35-4:
Layer 2 Switching Engine Classification and Marking



Figure 35-5:
Multilayer Switch Feature Card Marking



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



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


Figure 35-7:
Single-Port ATM OC-12 Switching Module Marking


QoS Feature Set Summary

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


Note   The two Layer 2 switching engines support the same QoS feature set.

Ethernet Ingress Port Features

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

Layer 3 Switching Engine Features

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


Note   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 supports classification using Layer 2 destination MAC addresses and VLANs and marking using Layer 2 CoS values. Classification and marking with a Layer 2 switching engine do not use or set Layer 3 IP precedence or DSCP values. For more information, see the "Classification and Marking with a Layer 2 Switching Engine" section.

Ethernet Egress Port Features

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

Single-Port ATM OC-12 Switching Module Features

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

Multilayer Switch Feature Card

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


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

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

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

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


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

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


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

Marking at Untrusted Ports

With either a Layer 2 switching engine or a Layer 3 switching engine, QoS marks all frames received through untrusted ports with the port CoS value (the default is zero). QoS does not implement ingress port congestion avoidance on untrusted ports: the traffic goes directly to the switching engine.

Marking at Trusted Ports

When an ISL frame enters the switch through a trusted port, QoS accepts the three least significant bits in the User field as a CoS value. When an 802.1Q frame enters the switch through a trusted port, QoS accepts the User Priority bits as a CoS value. QoS marks all traffic received in other frame types with the port CoS value.


Note   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


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

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

Receive Queues


Note   Ethernet ports have either single or dual receive queues. Enter a show port capabilities command to see the queue structure of a port. The command displays rx-(1q4t) for single-receive-queue ports (1q4t indicates one standard queue with four thresholds). The command displays rx-(1p1q4t) for dual-receive-queue ports (1p1q4t indicates one strict-priority queue and one standard queue with four thresholds).

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

Scheduling

QoS schedules traffic through the receive queues based on CoS values. In the dual-receive-queue default configuration, QoS assigns all traffic with CoS 5 to the strict priority queue; QoS assigns all other traffic to the standard queue. In the single-receive-queue default configuration, QoS assigns all traffic to the standard queue.

Congestion Avoidance

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

Ports with a single receive queue have this default drop threshold configuration:

Ports with dual receive queues have this default drop threshold configuration:


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

Figure 35-8 illustrates the drop thresholds for a port with a single receive queue. Drop thresholds in other configurations function similarly.


Figure 35-8: Receive Queue Drop Thresholds


Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine

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


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

For a Layer 3 switching engine to mark traffic in response to per-port classification, the traffic must match an ACE that contains the dscp ACE keyword (see the "Marking Rules" section). Table 35-1 lists the per-port classifications and the marking rules that they invoke.


Table 35-1: Marking Based on Per-Port Classification
Port Keyword ACE Keyword Marking Rule

untrusted

dscp

Set DSCP as specified in the ACE.

trust-ipprec

dscp

For IP traffic, set DSCP from the received Layer 3 IP precedence value.

For other traffic, set DSCP from the received or port Layer 2 CoS value.

trust-dscp

dscp

For IP traffic, set DSCP from the received Layer 3 DSCP value.

For other traffic, set DSCP from the received or port Layer 2 CoS value.

trust-cos

dscp

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

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

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


Note   With a Layer 3 switching engine, the Catalyst 6000 family switches provide QoS only for the Ethertype field values shown in Table 35-2 in 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:


Note   Classification with a Layer 3 switching engine uses Layer 2, 3, and 4 values. Marking with a Layer 3 switching engine uses Layer 2 CoS values and Layer 3 IP precedence or DSCP values.

Internal DSCP Values

During processing, a Layer 3 switching engine represents the priority of all traffic (including non-IP traffic) with a DSCP value. QoS uses configurable mapping tables to derive DSCP, which is a 6-bit value, from CoS or IP precedence, which are 3-bit values (for more information, see the "Mapping CoS Values to DSCP Values" section and the "Mapping IP Precedence Values to DSCP Values" section).

When traffic leaves a Layer 3 switching engine, QoS uses a configurable mapping table to derive a CoS value from the DSCP value associated with traffic (see the "Mapping DSCP Values to CoS Values" section). For IP traffic, QoS sends the internal DSCP value to Ethernet egress ports to be written into IP packets. QoS sends the CoS value to Ethernet egress ports and ATM modules for use in scheduling and to be written into ISL and 802.1Q frames.

For trust-dscp and trust-ipprec IP traffic, QoS creates a ToS byte from the 6-bit DSCP value (which may equal an IP precedence value) plus the original 2 least-significant bits from the received ToS byte and sends it to the egress port to be written into IP packets.

ACLs

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

A Layer 3 switching engine supports up to 250 ACLs and a combined total (all ACEs in all ACLs) of up to approximately 8,000 ACEs (other features configured on the switch may decrease the space available to store ACEs).

There are three ACL types: IP, IPX, and MAC. QoS compares traffic of each type (IP, IPX, and MAC) only to the corresponding ACL type (see Table 35-2).


Table 35-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

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

Named ACLs

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

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

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


Note   QoS does not support Internet Group Management Protocol (IGMP) traffic when IGMP snooping is enabled.

IP ACE Layer 3 Classification Criteria

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

IP ACE Layer 4 Protocol Classification Criteria

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


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

IP ACE Layer 4 TCP Classification Criteria

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

Keyword
Port
 
Keyword
Port
 
Keyword
Port
 
Keyword
Port

bgp

179

ftp

21

lpd

515

telnet

23

chargen

19

ftp-data

20

nntp

119

time

37

daytime

13

gopher

70

pop2

109

uucp

540

discard

9

hostname

101

pop3

110

whois

43

domain

53

irc

194

smtp

25

www

80

echo

7

klogin

543

sunrpc

111

finger

79

kshell

544

tacacs

49


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

IP ACE Layer 4 UDP Classification Criteria

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

Keyword
Port
 
Keyword
Port
 
Keyword
Port
 
Keyword
Port

biff

512

echo

7

rip

520

talk

517

bootpc

68

mobile-ip

434

snmp

161

tftp

69

bootps

67

nameserver

42

snmptrap

162

time

37

discard

9

netbios-dgm

138

sunrpc

111

who

513

dns

53

netbios-ns

137

syslog

514

xdmcp

177

dnsix

195

ntp

123

tacacs

49


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

IP ACE Layer 4 ICMP Classification Criteria

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

Keyword
Type
Code
Keyword
Type
Code

administratively-prohibited

3

13

net-tos-unreachable

3

11

alternate-address1

6

net-unreachable

3

0

conversion-error

31

0

network-unknown

3

6

dod-host-prohibited

3

10

no-room-for-option

12

2

dod-net-prohibited

3

9

option-missing

12

1

echo

8

0

packet-too-big

3

4

echo-reply

0

0

parameter-problem

12

0

general-parameter-problem1

12

port-unreachable

3

3

host-isolated

3

8

precedence-unreachable

3

15

host-precedence-unreachable

3

14

protocol-unreachable

3

2

host-redirect

5

1

reassembly-timeout

11

1

host-tos-redirect

5

3

redirect1

5

host-tos-unreachable

3

12

router-advertisement

9

0

host-unknown

3

7

router-solicitation

10

0

host-unreachable

3

1

source-quench

4

0

information-reply

16

0

source-route-failed

3

5

information-request

15

0

time-exceeded1

11

mask-reply

18

0

timestamp-reply

14

0

mask-request

17

0

timestamp-request

13

0

mobile-redirect

32

0

traceroute

30

0

net-redirect

5

0

ttl-exceeded

11

0

net-tos-redirect

5

2

unreachable1

3

1Matches all code values


Note   ICMP ACEs with only a Layer 4 ICMP type parameter match all code values for that type value. 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 IGMP ACEs that match traffic containing 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   IGMP ACEs that do not include a Layer 4 IGMP type parameter match all IGMP traffic.

IPX ACE Classification Criteria

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

MAC ACE Layer 2 Classification Criteria

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

Default ACLs

There are three default ACLs, one each for IP, IPX, and MAC traffic. Each ACL has a single ACE that has a configurable marking rule and configurable policing rules. 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. Unmatched IP traffic matches the default IP ACL. Unmatched IPX traffic matches the default IPX ACL. Unmatched Ethernet traffic matches the default MAC ACL.


Note   All traffic with a supported Ethertype field value 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

Marking rules specify how QoS marks 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, 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:

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

Policing Rules

You can create named policing rules that specify bandwidth utilization limits, which you can apply to traffic by including the policing rule name in an ACE (for more information, see the "Creating Policing Rules" section). You specify the bandwidth utilization limits as an average rate and a maximum burst size. Packets that exceed these limits are "out of profile."

In each policing rule, you specify if out-of-profile packets are to be dropped or to have a new DSCP value applied to them (applying a new DSCP value is called "markdown"). Since out-of-profile packets do not retain their original priority, they are not counted as part of the bandwidth consumed by in-profile packets.

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


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

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

You can create two kinds of policing rules:

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

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


Note   You can include a microflow policing rule only in IP ACEs. You cannot include a microflow policing rule in IPX or MAC ACEs. IPX and MAC ACEs support only aggregate policing rules.

By default, microflow policing rules only affect routed traffic. To enable microflow policing of nonrouted traffic, enter the set qos bridged-packet-microflow-policing command (for more information, see the "Enabling Microflow Policing of Nonrouted Traffic" section).


Note   QoS does not apply microflow policing rules to Multilayer Switching (MLS) candidate frames.

To avoid inconsistent results, all ACEs that include the same aggregate policing rule 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 ports configured with the same port keyword: trust-dscp, trust-ipprec, trust-cos, or untrusted. If the ACL is attached to a VLAN, all ports in the VLAN must be configured with the same port keyword.

For ACEs that include both a microflow policing rule and an aggregate policing rule, QoS responds to an out-of-profile status from either policing rule and, as specified by the policing rule, applies a new DSCP value or drops the packet. If both policing rules return an out-of-profile status, then if either policing rule specifies that the packet is to be dropped, it is dropped; otherwise QoS applies a new DSCP value.

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 ACLs to the selected interface (see the "Attaching ACLs to Interfaces" section). You can attach up to three named ACLs, one of each type (IP, IPX, and Ethernet) to each port and VLAN.

On ports configured for VLAN-based QoS, you can attach named ACLs to the port's VLAN; or for a trunk, you can attach named ACLs to any VLANs allowed on the trunk.

On ports configured for port-based QoS, you can attach named ACLs to the port.

Final Layer 3 Switching Engine CoS and ToS Values

With a Layer 3 switching engine, QoS associates CoS and ToS values with traffic as specified by the marking and policing rules 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).

Classification and Marking with a Layer 2 Switching Engine

With a Layer 2 switching engine, QoS can classify traffic addressed to specified MAC address/VLAN pairs to be marked with a configured CoS value (for more information, see the "Definitions" section and the "Mapping a CoS Value to a Host Destination MAC Address/VLAN Pair" section).


Note   Classification and marking with a Layer 2 switching engine uses Layer 2 CoS values. Classification and marking with a Layer 2 switching engine does not use or set Layer 3 IP precedence or DSCP values.

Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking

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


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

Transmit Queues


Note   Enter the show port capabilities command to see the queue structure of a port. The command displays tx-(2q2t) for dual-transmit-queue ports (2q2t indicates two standard queues with two thresholds each). The command displays tx-(1p2q2t) for triple-transmit-queue ports (1p2q2t indicates one strict-priority queue and two standard queues with two thresholds each).

All ports have a low-priority transmit queue and a high-priority transmit queue. Triple-queue ports have a strict-priority queue in addition to the standard queues.

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

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

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

Scheduling

For triple-transmit-queue ports, with the default configuration, QoS assigns all traffic with CoS 5 to the strict priority queue, traffic with CoS 4, 6, and 7 to the high-priority standard queue, and traffic with CoS 0, 1, 2, and 3 to the low-priority standard queue.

Congestion Avoidance on Dual Transmit Queue Ports

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

Congestion Avoidance on Triple Transmit Queue Ports

For triple-transmit queue ports, the low- and high-priority standard transmit queues each have two drop thresholds that function as follows:


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

Marking

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

QoS Default Configuration

Table 35-3 shows the QoS default configuration.


Table 35-3: QoS Default Configuration
Feature Default Value

QoS enable state

Disabled

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

Port CoS value

0

Intra-VLAN microflow policing

Disabled

Port-based or VLAN-based

Port-based

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

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

Policing rules

None

Named ACLs

None

Default ACLs

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

COPS-DS support

Disabled

RSVP support

Disabled

With QoS enabled

Port trust state

Untrusted

Receive queue drop threshold1 percentages

  • Threshold 1: 50%

  • Threshold 2: 60%

  • Threshold 3: 80%

  • Threshold 4: 100%

Transmit queue drop threshold percentages

  • Low-priority queue threshold 1: 80%

  • Low-priority queue threshold 2: 100%

  • High-priority queue threshold 1: 80%

  • High-priority queue threshold 2: 100%

Transmit queue low-priority/high-priority ratio

4:255

Standard transmit queue size ratio

  • Low priority: 80%

  • High priority: 20%

CoS value/drop threshold mapping

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

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

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

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

With QoS disabled

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

1QoS implements receive queue drop thresholds only on ports configured with the trust-cos port keyword.
2On ports with dual receive queues and triple transmit queues, CoS 5 is mapped to the strict priority queues.

Configuring QoS

These sections describe how to configure QoS on the Catalyst 6000 family switches:


Note   Some QoS show commands support config and runtime keywords. Use the runtime keyword to display the QoS values 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 values from commands that have been entered, but which may not currently be programmed into the hardware (for example, locally configured QoS values that are currently not used because COPS-DS has been selected as the QoS policy source or QoS values 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 Port-Based or VLAN-Based QoS


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

By default, QoS uses ACLs attached to ports. On a per-port basis, you can configure QoS to use ACLs 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_num/port_num {port-based | vlan-based}

Step 2 

Verify the configuration.

show port qos mod_num/port_num

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

This example shows how to enable 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) 

Note   Changing a port from port-based to VLAN-based QoS detaches all ACLs from the port. Any ACLs attached to the VLAN apply to the port immediately (for more information, see the "Attaching ACLs to Interfaces" 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 mod_num/port_num trust {untrusted | trust-cos | trust-ipprec | trust-dscp}

Step 2 

Verify the configuration.

show port qos mod_num/port_num

QoS only supports the trust-ipprec and trust-dscp keywords with a Layer 3 switching engine.

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 ISL or 802.1Q frames carry CoS values. Configure ports with the trust-cos keyword only when the received traffic is ISL or 802.1Q frames carrying CoS values that you know to be consistent with network policy.

Configuring the CoS Value for a Port

Unmarked frames from ports configured as trusted and all frames from ports configured as untrusted are assigned the CoS value 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 mod_num/port_num cos cos-value

Step 2 

Verify the configuration.

show port qos mod_num/port_num

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 mod_num/port_num cos

Step 2 

Verify the configuration.

show port qos mod_num/port_num

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 Policing Rules


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

To create a policing rule, perform this task in privileged mode:

Task Command

Step 1 

Create a policing rule.

set qos policer {microflow | aggregate} policer_name rate rate burst burst {drop | policed-dscp}

Step 2 

Verify the configuration.

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

For more information, see the "Policing Rules" section.

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

The valid values for the rate parameter are 32 Kbps (entered as 32) to 8 Gbps (entered as 8000000); or to classify all traffic as out of profile, set the rate parameter to zero (0).

The valid values for the burst parameter are 1 Kb (entered as 1) to 32 Mb (entered as 32000).


Note   The recommended minimum value of burst size is 32 Kb; specifying a smaller value might result in a lower than specified rate. You can experiment with smaller values, but if there are problems, you should up your burst to this minimum recommended value.


Note   QoS programs the hardware with values that are multiples of 32K, not with the specific value entered.

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

This example shows how to create a microflow policing rule 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)

Deleting Policing Rules


Note   You can only delete policing rules if they are not attached to any interfaces (for more information, see the "Detaching ACLs from Interfaces" section).

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

Task Command

Step 1 

Delete one or all policing rules.

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 policing rule named my_micro:

Console> (enable) clear qos policer microflow my_micro 
my_micro QoS microflow policer cleared.
Console> (enable) 

Creating or Modifying ACLs


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

These sections describe ACL creation and modification:

ACL Names

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

ACE Name, Marking Rule, Policing, and Filtering Syntax

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

For example, in 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]

Named IP ACLs

These sections describe creating or modifying IP ACLs:

Source and Destination IP Addresses and Masks

In IP ACEs, specify 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 zero bits, which need not be contiguous, where you want wildcards.

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

Port Operator Parameters

In IP ACEs, the operator parameter can be lt (less than), gt (greater than), eq (equal), neq (not equal), and range keywords with a port or, for the range keyword, a pair of port parameters.

Precedence Parameter Options

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

IP ACEs for TCP Traffic

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

Task Command

Step 1 

Create or modify an IP ACE for TCP traffic.

set qos acl ip acl_name {dscp dscp | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] tcp src_ip_spec [operator port | range port port] dest_ip_spec [operator port | range port port] [established] [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 port parameter keyword options, see the "IP ACE Layer 4 TCP Classification Criteria" section. Only the range operator keyword accepts a second port parameter.

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

This example shows how to create an IP ACE for 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 UDP traffic, perform this task in privileged mode:

Task Command

Step 1 

Create or modify an IP ACE for UDP traffic.

set qos acl ip acl_name {dscp dscp | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] tcp src_ip_spec [operator port | range port port] dest_ip_spec [operator port | range port port] [established] [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 port parameter keyword options, see the "IP ACE Layer 4 UDP Classification Criteria" section. Only the range operator keyword accepts a second port parameter.

This example shows how to create an IP ACE for 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 ICMP traffic, perform this task in privileged mode:

Task Command

Step 1 

Create or modify an IP ACE for 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 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 IGMP traffic when IGMP snooping is enabled.

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

Task Command

Step 1 

Create or modify an IP ACE for IGMP traffic.

set qos acl ip acl_name {dscp dscp | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] igmp src_ip_spec dest_ip_spec [igmp_type] [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 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 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 | trust-cos | trust-ipprec | trust-dscp} [microflow microflow_name] [aggregate aggregate_name] protocol src_ip_spec dest_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]

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

This example shows how to create an IP ACE for 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)

Default IP ACL

To modify the default IP 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]

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

Named IPX ACLs

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

Task Command

Step 1 

Create or modify an IPX ACL.

set qos acl ipx acl_name {dscp dscp | trust-cos} [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, IPX ACEs support the following optional parameters:

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)

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

set qos acl mac acl_name {dscp dscp | 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 zero bits, which need not be contiguous, where you want 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)

Default IPX and MAC ACLs

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

Task Command

Step 1 

Modify the default IPX or MAC ACL.

set qos acl default-action {ipx | mac} {dscp dscp | trust-cos} [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   IPX and MAC ACLs support only aggregate policing rules.

Deleting Named ACLs

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) 

Note   You cannot successfully use the commit command on a deleted ACL while the ACL is attached to any ports or VLANs.

Reverting to Default Values in 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}

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 Uncommitted ACLs

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   Changes to the default ACLs take effect immediately and cannot be discarded.

Committing ACLs

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 interfaces, the new values go into effect immediately. Changes to the default ACLs do not need to be committed.

Attaching ACLs to Interfaces


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

You can attach one ACL of each type to each VLAN and to each port configured for port-based QoS. You cannot attach ACLs to a port configured for VLAN-based QoS (for more information, see the "Enabling Port-Based or VLAN-Based QoS" section). When an ACL of a particular type (IP, IPX, or Ethernet) 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_num/port_num | vlan}

Step 2 

Verify the configuration.

show qos acl map {config | runtime} {acl_name | mod_num/port_num | vlan | all}

This example shows how to attach an ACL named my_acl to port 2/1:

Console> (enable) set qos acl map my_acl 2/1
Hardware programming in progress...
ACL my_acl is attached to port 2/1.
Console> (enable) 
 

This example shows how to attach an ACL named my_acl to VLAN 4:

Console> (enable) set qos acl map my_acl 4
Hardware programming in progress...
ACL my_acl is attached to vlan 4.
Console> (enable) 

Note   The default ACLs do not need to be attached to any interfaces.

Detaching ACLs from Interfaces


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

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_num/port_num | vlan | all}

Step 2 

Verify the configuration.

show qos acl map {config | runtime} {acl_name | mod_num/port_num | vlan | all}

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.

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


Note   QoS only supports this command with a Layer 2 switching engine.

To map a CoS value to all frames 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_addr 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 only supports this command 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 clear all CoS assignments to destination MAC addresses and VLANs:

Console> (enable) clear qos mac-cos all
All CoS to Mac/Vlan entries are cleared.
Console> (enable) 

Enabling Microflow Policing of Nonrouted Traffic


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

By default, microflow policing rules affect only routed traffic. To enable microflow policing of nonrouted traffic on the switch or on specified VLANs, perform this task in privileged mode:

Task Command

Step 1 

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

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

Step 2 

Verify the configuration.

show qos bridged-packet-policing {config | runtime} [vlan]

For more information, see the "Policing Rules" section.

This example shows how to enable microflow policing of traffic in VLANs 1 through 20:

Console> (enable) set qos bridged-packet-microflow-policing enable 1-20
QoS microflow policing is enabled for bridged packets on vlans 1-20.
Console> (enable) 

Disabling Microflow Policing of Nonrouted Traffic


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

To disable microflow policing of nonrouted traffic on the switch or on specified VLANs, perform this task in privileged mode:

Task Command

Step 1 

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

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

Step 2 

Verify the configuration.

show qos bridged-packet-policing {config | runtime} [vlan]

This example shows how to disable microflow policing of traffic in VLAN 10:

Console> (enable) set qos bridged-packet-microflow-policing disable 10
QoS microflow policing is disabled for bridged packets on vlan(s) 10. 
Console> (enable) 

Configuring Receive Queue Tail-Drop Thresholds

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

Task
Command

Configure the receive queue 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 single-receive queue ports and dual-receive queue ports. Use the 1q4t keyword as the port_type parameter to configure single-receive-queue ports and the 1p1q4t keyword to configure dual-receive-queue ports. With either keyword, this command configures only the standard queue. Specify queue 1 for both port types (the threshold in the strict priority queue is not separately configurable; it uses threshold 4 as specified for queue 1).

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

This example shows how to configure the receive queue 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) 

Configuring Dual Transmit Queue Tail-Drop Thresholds

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

Task
Command

Set the dual transmit drop queue thresholds.

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

QoS maintains separate configurations for single-receive queue ports and dual-receive queue ports. Use the 2q2t keyword as the port_type parameter to configure dual-transmit-queue ports and the 1p2q2t keyword to configure triple-transmit-queue ports. With either keyword, this command configures only the standard queues.

The queue number is 1 for the low-priority transmit queue and 2 for the high-priority queue.

The thresholds are all specified as percentages, ranging from 1 to 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 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) 

Configuring Triple Transmit Queue WRED Drop Thresholds

To configure the transmit queue weighted-random early detection (WRED) drop thresholds on all triple transmit queue ports in the switch, perform this task in privileged mode:

Task
Command

Configure the triple transmit drop queue thresholds.

set qos wred-threshold 1p2q2t tx queue q# thr1 thr2

The queue number is 1 for the low-priority standard transmit queue and 2 for the high-priority standard transmit queue. The threshold in the strict priority queue is not configurable; it uses threshold 2 as specified for queue 2.

The thresholds are all specified as percentages, ranging from 1 to 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 drop thresholds:

Console> (enable) set qos wred 1p2q2t tx queue 1 50 100
WRED thresholds for queue 1 set to 50%, 100% on all WRED-capable 1p2q2t ports.
Console> (enable) 

Note   The WRED algorithm uses a high and a low threshold. You configure the high threshold with the set qos wred-threshold command. QoS configures the low threshold automatically.

Allocating Bandwidth Between Transmit Queues

The switch transmits frames from one standard queue at a time using a weighted-round robin (WRR) algorithm. WRR uses a weight value to decide how much to transmit from one queue before switching to the other. The higher the weight assigned to a queue, the more transmit bandwidth is allocated to it.

To allocate bandwidth, perform this task in privileged mode:

Task
Command

Allocate bandwidth between standard transmit queue 1 (low-priority) and standard transmit queue 2 (high-priority).

set qos wrr port_type queue1-weight queue2-weight

QoS maintains separate configurations for dual-transmit queue ports and triple-transmit queue ports. Use the 2q2t keyword as the port_type parameter to configure dual-transmit-queue ports and the 1p2q2t keyword to configure triple-transmit-queue ports. With either keyword, 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 configure bandwidth:

Console> (enable) set qos wrr 2q2t 30 70
QoS wrr ratio is set successfully.
Console> (enable) 

Configuring the Transmit Queue Size Ratio

For triple-transmit queue ports, estimate the mix of low-priority, high-priority, and strict-priority traffic on your network (for example, 75 percent low-priority traffic, 15 percent high-priority traffic, and
10 percent strict-priority traffic). For dual-transmit queue ports, estimate the mix of low priority-to-high priority traffic on your network (for example, 80 percent low-priority traffic and 20 percent high-priority traffic). Specify queue ratios with the estimated percentages, which must range from 1 to 99 and together add up to 100.

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

Task
Command

Configure the transmit queue size ratio between transmit queue 1 (low-priority) and transmit queue 2 (high-priority).

set qos txq-ratio 2q2t queue1-val queue2-val

QoS maintains separate configurations for dual-transmit queue ports and triple-transmit queue ports. Use the 2q2t keyword as the port_type parameter to configure dual-transmit-queue ports and the 1p2q2t keyword to configure triple-transmit-queue ports. 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 CoS Values to Drop Thresholds

This command associates CoS values with receive and transmit drop thresholds. QoS maintains separate configurations for single-receive/dual-transmit queue ports, which have all CoS values mapped to standard queues, and dual-receive/triple-transmit queue ports, which have some CoS values mapped to the strict-priority queues.

These sections describe mapping CoS values to drop thresholds:

Configuring Single-Receive, Dual-Transmit Queue Ports

To associate CoS values to the drop thresholds on single-receive, dual-transmit queue ports, perform this task in privileged mode:

Task Command

Step 1 

Associate a CoS value to a drop threshold.

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

Step 2 

Verify the configuration.

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

The receive and transmit drop thresholds have this relationship:

Use the transmit queue and transmit queue drop threshold values in this command. This example shows how to map the CoS values 0 and 1 to both standard receive queue 1/threshold 1 and 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) 

Clearing Single-Receive, Dual-Transmit Queue Ports

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

Task Command

Step 1 

Revert to QoS map defaults.

clear qos map 2q2t tx

Step 2 

Verify the configuration.

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

This example shows how to revert to QoS map defaults:

Console> (enable) clear qos map 2q2t tx
Qos map setting cleared.
Console> (enable) 

Configuring Dual-Receive, Triple-Transmit Queue Ports

On dual-receive, triple-transmit queue ports, you can configure the receive queues and the transmit queues separately.

Receive Queues

To associate CoS values to the receive-queue drop thresholds on dual-receive, triple-transmit queue ports, perform this task in privileged mode:

Task Command

Step 1 

Associate a 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 | 1p2q2t tx | 2q2t tx}

This example shows how to map the CoS value 7 to strict priority receive queue 2/threshold 1:

Console> (enable) set qos map 1p1q4t rx 3 1 cos 7
Qos tx strict queue and threshold mapped to cos successfully.
Console> (enable) 
Transmit Queues

To associate CoS values to the transmit queue drop thresholds on dual-receive, triple-transmit queue ports, perform this task in privileged mode:

Task Command

Step 1 

Associate a 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 {1p1q4t rx | 1p2q2t tx | 2q2t tx}

This example shows how to map the CoS value 7 to strict priority transmit queue 3/drop threshold 1:

Console> (enable) set qos map 1p2q2t tx 3 1 cos 7
Qos tx strict queue and threshold mapped to cos successfully.
Console> (enable) 

Clearing Dual-Receive, Triple-Transmit Queue Ports

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

Task Command

Step 1 

Revert to QoS map defaults.

clear qos map {1p1q4t rx | 1p2q2t tx | 2q2t tx}

Step 2 

Verify the configuration.

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

This example shows how to revert to QoS map defaults:

Console> (enable) clear qos map 1p2q2t tx
Qos map setting cleared.
Console> (enable) 

Configuring DSCP Value Maps


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

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

Mapping CoS Values to DSCP Values

To map received CoS values to the DSCP value that QoS uses internally on a Layer 3 switching engine (see the "Internal DSCP Values" section), perform this task in privileged mode:

Task Command

Step 1 

Map CoS values to DSCP values.

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

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

Enter 8 DSCP values to which QoS maps CoS values 0 through 7. This example shows how to map CoS values to 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 default CoS to DSCP value mapping, perform this task in privileged mode:

Task Command

Step 1 

Revert to CoS value/DSCP value map defaults.

clear qos cos-dscp-map

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to CoS-DSCP map defaults:

Console> (enable) clear qos cos-dscp-map
QoS cos-dscp-map setting restored to default.
Console> (enable) 

Mapping IP Precedence Values to DSCP Values

To map received IP precedence values to the DSCP value that QoS uses internally on a Layer 3 switching engine (see the "Internal DSCP Values" section), perform this task in privileged mode:

Task Command

Step 1 

Map IP precedence values to DSCP values.

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

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

Enter 8 DSCP values to which QoS maps IP precedence values 0 through 7. This example shows how to map IP precedence values to 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 default IP precedence to DSCP value mapping, perform this task in privileged mode:

Task Command

Step 1 

Revert to IP precedence value to DSCP value map defaults.

clear qos ipprec-dscp-map

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to QoS map defaults:

Console> (enable) clear qos ipprec-dscp-map
QoS ipprec-dscp-map setting restored to default.
Console> (enable) 

Mapping DSCP Values to CoS Values

To map DSCP values that QoS uses internally on a Layer 3 switching engine to the CoS values used for egress port scheduling and congestion avoidance, perform this task in privileged mode:

Task Command

Step 1 

Map DSCP values to CoS values.

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

Step 2 

Verify the configuration.

show qos maps [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 DSCP value list/CoS value pairs. This example shows how to map DSCP values to 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 default CoS to DSCP value mapping, perform this task in privileged mode:

Task Command

Step 1 

Revert to DSCP value/CoS value map defaults.

clear qos dscp-cos-map

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to CoS-DSCP map defaults:

Console> (enable) clear qos dscp-cos-map
QoS dscp-cos-map setting restored to default.
Console> (enable) 

Mapping DSCP Markdown Values

To map DSCP markdown values used by policing rules, perform this task in privileged mode:

Task Command

Step 1 

Map DSCP values to markdown DSCP values.

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

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

For more information, see the "Policing Rules" section.

Enter up to 64 DSCP-value-list/DSCP-value pairs. This example shows how to map DSCP markdown values:

Console> (enable) set qos policed-dscp-map 20-25:7 33-38:3
QoS dscp-cos-map set successfully.
Console> (enable) 

Note   Configure marked-down DSCP values that map to CoS values consistent with the markdown penalty (see the "Mapping DSCP Values to CoS Values" section).

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

Task Command

Step 1 

Revert to DSCP markdown map defaults.

clear qos policed-dscp-map

Step 2 

Verify the configuration.

show qos maps [cos-dscp-map | ipprec-dscp-map | dscp-cos-map | policed-dscp-map]

This example shows how to revert to DSCP markdown map defaults:

Console> (enable) clear qos policed-dscp-map
QoS dscp-cos-map setting restored to default.
Console> (enable) 

Displaying QoS Information

To display QoS information, perform this task:

Task
Command

Display QoS information.

show qos info [runtime| config] mod_num/port_num

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

To display QoS statistics, perform this task:

Task
Command

Display QoS statistics.

show qos statistics {mod_num[/port_num]| L3stats}

This example shows how to display QoS statistics for port 2/1:

Console> (enable) show qos statistics 2/1
On Transmit:Port 2/1 has 2 Queue(s) 2 Threshold(s)
Q #  Threshold #:Packets dropped
---  -----------------------------------------------
1    1:0 pkts, 2:0 pkts
2    1:0 pkts, 2:0 pkts
On Receive:Port 2/1 has 1 Queue(s) 4 Threshold(s)
Q #  Threshold #:Packets dropped
---  -----------------------------------------------
1    1:0 pkts, 2:0 pkts, 3:0 pkts, 4:0 pkts
 

This example shows how to display QoS Layer 3 statistics:

Console> (enable) show qos statistics l3stats 
QoS Layer 3 Statistics show statistics since last read.
Packets dropped due to policing: 0
IP packets with ToS changed:     0
IP packets with CoS changed:     26
Non-IP packets with CoS changed: 0
Console> 

Reverting to QoS Defaults


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

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

Task
Command

Revert to QoS defaults.

clear qos config

This example shows how to revert to 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-DS Support


Note   QoS only supports the commands in this section when configured on a switch with a
Layer 3 switching engine.

These commands describe configuring COPS-DS support:


Note   Throughout this publication and all Catalyst 6000 family documents, the term "COPS-DS" refers to COPS-DS support as implemented on the Catalyst 6000 family.

Port ASICs

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


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


Note   Changes to an EtherChannel port apply to all ports in the EtherChannel and to all ports 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 ports and VLANs.

Selecting COPS-DS as the QoS Policy Source

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

Task Command

Step 1 

Select COPS-DS 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-DS 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-DS as the QoS policy source switches the following values from locally configured values to received COPS-DS values:

Selecting Locally Configured QoS Policy

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

Task Command

Step 1 

Select 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 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 Locally Configured QoS Policy

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

Task Command

Step 1 

Enable use of locally configured QoS policy on a port.

set port qos mod_num/port_num policy-source {local | cops}

Step 2 

Verify the QoS policy source for the port.

show port qos mod_num/port_num

This example shows how to enable use of locally configured QoS policy:

Console> (enable) set port qos 1/1 policy-source local
QoS policy source set to COPS on port(s) 1/1-2.
Console> (enable) 

Configuring Port Roles

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

A role is a name that describes the capability of 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 role names assigned to a port ASIC cannot exceed 255 characters.

The role name can be up to 31 characters long, 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 (.). Role names must start with an alphabetic character.

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

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

Task Command

Step 1 

Assign roles to a port ASIC.

set port qos mod_num/port_num roles role1 [role2] ...

Step 2 

Verify the roles for the port.

show port cops [mod_num/port_num]

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 Roles From 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_num/port_num {all-roles | roles role1 [role2] ...}

Step 2 

Verify the roles for the port.

show port cops [mod_num/port_num]

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 Roles

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_num/port_num]

This example shows how to delete a role:

Console> (enable) clear cops roles backbone_port main_port
Roles cleared.
Console> (enable) 

Configuring Policy Decision Point Servers


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

COPS-DS obtains 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 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-DS.

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 PDP Server Configuration

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

Task Command

Step 1 

Delete PDP server configuration.

clear cops server {all | ip_address [diff-serv | rsvp]}

Step 2 

Verify the PDP server configuration.

show cops info

This example shows how to delete PDP server configuration:

Console> (enable) clear cops server all
All COPS diff-serv servers cleared.
All COPS rsvp servers cleared.
Console> (enable) 

Configuring the COPS-DS Domain Name

PDP servers use a COPS-DS domain name to communicate with policy enforcement point (PEP) devices such as switches. To configure a COPS-DS domain name for the switch, perform this task in privileged mode:

Task Command

Step 1 

Configure the COPS-DS domain name.

set cops domain-name domain_name

Step 2 

Verify the COPS-DS domain name.

show cops info

This example shows how to configure a COPS-DS domain name:

Console> (enable) set cops domain-name my_domain
Domain name set to my_domain.
Console> (enable) 

Deleting the COPS-DS Domain Name

To delete the COPS-DS domain name, perform this task in privileged mode:

Task Command

Step 1 

Delete the COPS-DS domain name.

clear cops domain-name

Step 2 

Verify the configuration.

show cops info

This example shows how to delete the COPS-DS domain name:

Console> (enable) clear cops domain-name
Domain name cleared.
Console> (enable) 

Configuring the COPS-DS Communications Parameters

To configure the parameters COPS-DS uses to communicate with the PDP server, perform this task in privileged mode:

Task Command

Step 1 

Configure the parameters COPS-DS uses to communicate with the PDP server.

set cops retry-interval initial increment maximum

Step 2 

Verify the configuration.

show cops info

Enter the parameters as a number of seconds in the range 0 to 65535. The value of the initial parameter plus the value of the increment parameter must not exceed the value of the maximum parameter.

This example shows how to configure the parameters COPS-DS uses to communicate with the PDP server:

Console> (enable) set cops retry-interval 15 1 30
Connection retry intervals set.
Console> (enable) 

Configuring RSVP Support


Note   QoS only supports the commands in this section with a Layer 3 switching engine.

These sections describe configuring RSVP null service template and receiver proxy functionality support:


Note   Throughout this publication and all Catalyst 6000 or 6500 series switch documents, the term "RSVP" refers to RSVP null service template and receiver proxy functionality support as implemented on the Catalyst 6000 family switches.


Note   To use RSVP, enable and configure COPS-DS support (for more information, see the "Configuring COPS-DS Support" section).

Enabling RSVP Support

To enable RSVP support, perform this task in privileged mode:

Task Command

Step 1 

Enable RSVP support on the switch.

set qos rsvp {enable | disable}

Step 2 

Verify the configuration.

show qos rsvp info

This example shows how to enable RSVP support:

Console> (enable) set qos rsvp enable
RSVP enabled on the switch.
Console> (enable) 

Disabling RSVP Support

To disable RSVP support, perform this task in privileged mode:

Task Command

Step 1 

Disable RSVP support on the switch.

set qos rsvp {enable | disable}

Step 2 

Verify the configuration.

show qos rsvp info

This example shows how to disable RSVP support:

Console> (enable) set qos rsvp disable
RSVP disabled on the switch.
Console> (enable) 

Enabling Participation in the DSBM Election

Catalyst 6000 family switches can serve as the designated subnet bandwidth manager (DSBM). You can enable participation in the election of the DSBM on a per-port basis.


Note   The DSBM is not reelected when additional RSVP devices join the network. To control which device is the DSBM, disable election participation in all devices except the one that you want elected as DSBM. After the DSBM is elected, reenable election participation in other devices, as appropriate for the network configuration.

To enable the participation of a port in the election of the DSBM, perform this task in privileged mode:

Task Command

Step 1 

Enable the participation of a port in the election of the DSBM.

set port rsvp mod_num/port_num dsbm-election {disable | enable priority}

Step 2 

Verify the configuration of the port.

show port rsvp [mod_num/port_num]

The range for the priority parameter is 128 to 255.

This example shows how to enable the participation of ports 2/1 and 3/2 in the election of the DSBM:

Console> (enable) set port rsvp 2/1,3/2 dsbm-election enable 232
DSBM enabled and priority set to 232 for ports 2/1,3/2.
Console> (enable)

Disabling Participation in the DSBM Election

To disable the participation of a port in the election of the DSBM, perform this task in privileged mode:

Task Command

Step 1 

Disable the participation of a port in the election of the DSBM.

set port rsvp mod_num/port_num dsbm-election {disable | enable priority}

Step 2 

Verify the configuration.

show port rsvp [mod_num/port_num]

This example shows how to disable the participation of port 2/1 in the election of the DSBM:

Console> (enable) set port qos 2/1 rsvp dsbm-election disable
DSBM disabled for port 2/1.
Console> (enable)

Configuring Policy Decision Point Servers


Note   COPS-DS and RSVP can use the same PDP server.

When the switch is the DSBM, RSVP communicates with 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 name of the server.

The port variable is the PDP server TCP port number.

Use the rsvp keyword to set the address only for RSVP.

This example shows how to configure a PDP server:

Console> (enable) set cops server my_server1 primary rsvp
my_server1 added to the COPS rsvp server table as primary server.
Console> (enable)

Deleting PDP Server Configuration

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

Task Command

Step 1 

Delete PDP server configuration.

clear cops server {all | ip_address [diff-serv | rsvp]}

Step 2 

Verify the PDP server configuration.

show cops info

Use the rsvp keyword to delete only the RSVP address.

This example shows how to delete PDP server configuration:

Console> (enable) clear cops server all
All COPS diff-serv servers cleared.
All COPS rsvp servers cleared.
Console> (enable) 

Configuring RSVP Policy Timeout

When the switch is the DSBM and communication with the PDP server is lost, the switch continues to function as the DSBM, using cached values, for the period specified by the timeout value; no new reservations are accepted.

If communication with the PDP server is not reestablished before the timeout period expires, the switch reverts to the role of subnet bandwidth manager (SBM) client for all ports and forwards RSVP messages to a newly elected DSBM on the segment. When there is no communication with the PDP server, the switch does not participate in election of the DSBM.

To configure the time that the switch continues to be the DSBM after communication with the PDP server is lost, perform this task in privileged mode:

Task Command

Step 1 

Configure the RSVP policy timeout.

set rsvp policy-timeout timeout

Step 2 

Verify the configuration.

show rsvp info

Enter the timeout parameter as a number of minutes in the range 0 to 65535 (default: 30).

This example shows how to configure the RSVP policy timeout:

Console> (enable) set qos rsvp policy-timeout 45
RSVP database policy timeout set to 45 minutes.
Console> (enable) 

Configuring RSVP Use of Local Policy

To configure how RSVP operates in the absence of communication with the PDP server, perform this task in privileged mode:

Task Command

Step 1 

Configure how RSVP operates when there is no communication with the PDP server.

set qos rsvp local-policy {forward | reject}

Step 2 

Verify the configuration.

show rsvp info

The forward keyword enables use of local policy. This example shows how to set RSVP to use local policy when communication with the PDP server is lost:

Console> (enable) set qos rsvp local-policy forward
RSVP local policy set to forward.
Console> (enable) 


hometocprevnextglossaryfeedbacksearchhelp
Posted: Tue Sep 5 15:17:46 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.