-
Catalyst 6500 Series Software Configuration Guide, 6.3 and 6.4
-
Product Overview
-
Command-Line Interfaces
-
Configuring the Switch IP Address and Default Gateway
-
Configuring Ethernet, Fast Ethernet, and Gigabit Ethernet Switching
-
Configuring Ethernet VLAN Trunks
-
Configuring EtherChannel
-
Configuring IEEE 802.1Q Tunneling
-
Configuring Spanning Tree
-
Configuring Spanning Tree PortFast, UplinkFast, BackboneFast, and Loop Guard
-
Configuring VTP
-
Configuring VLANs
-
Configuring InterVLAN Routing
-
Configuring CEF for PFC2
-
Configuring MLS
-
Configuring NDE
-
Configuring Access Control
-
Configuring GVRP
-
Configuring Dynamic Port VLAN Membership with VMPS
-
Checking Port Status and Connectivity
-
Administering the Switch
-
Configuring Switch Access Using AAA
-
Configuring Redundancy
-
Modifying the Switch Boot Configuration
-
Working With the Flash File System
-
Working with System Software Images
-
Working with Configuration Files
-
Configuring System Message Logging
-
Configuring DNS
-
Configuring CDP
-
Configuring UDLD
-
Configuring NTP
-
Configuring Broadcast Suppression
-
Configuring Layer 3 Protocol Filtering
-
Configuring the IP Permit List
-
Configuring Port Security
-
Configuring SNMP
-
Configuring RMON
-
Configuring SPAN and RSPAN
-
Using Switch TopN Reports
-
Configuring Multicast Services
-
Configuring QoS
-
Configuring a VoIP Network
-
Configuring ASLB
-
Configuring the Switch Fabric Modules
-
Table Of Contents
Ethernet Ingress Port Features
Layer 3 Switching Engine Features
Layer 2 Switching Engine Features
Single-Port ATM OC-12 Switching Module Features
Multilayer Switch Feature Card (MSFC or MSFC2)
Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification
Ethernet Ingress Port Scheduling and Congestion Avoidance
Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine
Classification, Marking, and Policing with a Layer 3 Switching Engine
Final Layer 3 Switching Engine CoS and ToS Values
Classification and Marking with a Layer 2 Switching Engine
Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking
Scheduling and Congestion Avoidance
Enabling Port-Based or VLAN-Based QoS
Configuring the Trust State of a Port
Configuring the CoS Value for a Port
ACE Name, Marking Rule, Policing, and Filtering Syntax
Creating or Modifying Named IPX ACLs
Creating or Modifying Named MAC ACLs
Creating or Modifying the Default IPX and MAC ACLs
Reverting to Default Values in Default ACLs
Detaching ACLs from Interfaces
Mapping a CoS Value to a Host Destination MAC Address/VLAN Pair
Deleting a CoS Value to a Host Destination MAC Address/VLAN Pair
Enabling or Disabling Microflow Policing of Bridged Traffic
Configuring Standard Receive-Queue Tail-Drop Thresholds
Configuring 2q2t Port Standard Transmit-Queue Tail-Drop Thresholds
Configuring Standard Transmit-Queue WRED-Drop Thresholds
Allocating Bandwidth Between Standard Transmit Queues
Configuring the Receive-Queue Size Ratio
Configuring the Transmit-Queue Size Ratio
Mapping CoS Values to Drop Thresholds
Associating 1p1q4t, 1p2q2t Ports
Associating 1p1q0t, 1p3q1t Ports
Mapping Received CoS Values to Internal DSCP Values
Mapping Received IP Precedence Values to Internal DSCP Values
Mapping Internal DSCP Values to Egress CoS Values
Selecting COPS as the QoS Policy Source
Selecting Locally Configured QoS Policy
Enabling Use of Locally Configured QoS Policy
Removing Roles from Port ASICs
Configuring Policy Decision Point Servers
Deleting PDP Server Configuration
Configuring the COPS Domain Name
Configuring the COPS Communications Parameters
Enabling Participation in the DSBM Election
Disabling Participation in the DSBM Election
Configuring Policy Decision Point Servers
Deleting PDP Server Configuration
Configuring RSVP Policy Timeout
Configuring RSVP Use of Local Policy
Configuring QoS Statistics Data Export
Enabling QoS Statistics Data Export Globally
Enabling Per-Port QoS Statistics Data Export
Enabling Per-Aggregate Policer QoS Statistics Data Export
Setting the QoS Statistics Data Export Time Interval
Configuring QoS Statistics Data Export Destination Host and UDP Port
Displaying QoS Statistics Information
Configuring QoS
This chapter describes how to configure quality of service (QoS) on the Catalyst 6000 family switches and includes the configuration information required to support Common Open Policy Service (COPS) and Resouce ReSerVation Protocol (RSVP).
Note
For complete syntax and usage information for the commands used in this chapter, refer to the Catalyst 6000 Family Command Reference publication.
You can configure QoS using one of the following:
•
•
•
•
This chapter consists of these sections:
Understanding How QoS Works
Note
•
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.
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:
•
•
•
–
Layer 2 Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries an IEEE 802.1p CoS value in the three least significant bits.
Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most significant bits, which are called the User Priority bits.
Other frame types cannot carry CoS values.
Note
–
–
Note
•
•
•
•
•
•
–
–
Flowcharts
Figure 41-1 shows how traffic flows through the QoS features; Figure 41-2 through Figure 41-7 show more details of the traffic flow through QoS features.
Figure 41-1 Traffic Flow Through QoS Features
Note
Note
Figure 41-2 Ethernet ingress Port Classification, Marking, Scheduling, and Congestion Avoidance
Figure 41-3 Layer 3 Switching Engine Classification, Marking, and Policing
Figure 41-4 Layer 2 Switching Engine Classification and Marking
Figure 41-5 Multilayer Switch Feature Card Marking (MSFC and MSFC2)
Figure 41-6 Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking
Figure 41-7 Single-Port ATM OC-12 Switching Module Marking
QoS Feature Set Summary
The QoS feature set on your switch is determined by the switching engine on the supervisor engine. Enter the show module command for the supervisor engine to display your switching engine configuration. The display shows the "Sub-Type" to be one of the following:
•
•
–
–
–
The Layer 3 Switching Engine WS-F6K-PFC and Layer 3 Switching Engine II support similar feature sets. The two Layer 2 switching engines support the same QoS feature set.
These sections describe the QoS feature sets:
•
•
•
•
•
•
Ethernet Ingress Port Features
With any switching engine, QoS supports classification, marking, scheduling, and congestion avoidance using Layer 2 CoS values at Ethernet ingress ports. Classification, marking, scheduling, and congestion avoidance at Ethernet ingress ports do not use or set Layer 3 IP precedence or DSCP values. With a Layer 3 switching engine, you can configure Ethernet ingress port trust states that can be used by the switching engine to set Layer 3 IP precedence or DSCP values and the Layer 2 CoS value. For more information, see the "Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification" section.
Layer 3 Switching Engine Features
With a Layer 3 switching engine, QoS supports classification, marking, and policing using IP, IPX, and Media Access Control (MAC) access control lists (ACLs). ACLs contain access control entries (ACEs) that specify Layer 2, 3, and 4 classification criteria, a marking rule, and 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.
During processing, a Layer 3 switching engine associates a DSCP value with all traffic, including non-IP traffic (for more information, see the "Internal DSCP Values" section).
Layer 2 Switching Engine Features
With a Layer 2 Switching Engine, QoS can classify traffic using Layer 2 destination MAC addresses, VLANs, and marking using Layer 2 CoS values. Classification and marking with a Layer 2 Switching Engine do not use or set Layer 3 IP precedence or DSCP values. For more information, see the "Classification and Marking with a Layer 2 Switching Engine" section.
Ethernet Egress Port Features
With any switching engine, QoS supports Ethernet egress port scheduling and congestion avoidance using Layer 2 CoS values. Ethernet egress port marking sets Layer 2 CoS values and, with a Layer 3 switching engine, Layer 3 DSCP values. For more information, see the "Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking" section.
Single-Port ATM OC-12 Switching Module Features
The ingress interface from a single-port ATM OC-12 switching module is untrusted, and QoS sets CoS to zero in all traffic received from it. With a Layer 3 switching engine, QoS can mark IP traffic transmitted to a single-port ATM OC-12 switching module with Layer 3 DSCP values.
Multilayer Switch Feature Card (MSFC or MSFC2)
QoS marks IP traffic transmitted to an MSFC with Layer 3 DSCP values. CoS is zero in all traffic sent from an MSFC to egress ports.
Note
Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification
These sections describe Ethernet ingress port marking, scheduling, congestion avoidance, and classification:
•
•
Overview
The trust state of an Ethernet port determines how it marks, schedules, and classifies received traffic, and whether or not congestion avoidance is implemented. You can configure the trust state of each port with one of these keywords:
•
•
•
•
Note
•
For more information, see the "Configuring the Trust State of a Port" section.
In addition to the port configuration keywords listed above, with a Layer 3 switching engine, QoS uses trust-ipprec, trust-dscp, and trust-cos ACE keywords. Do not confuse the ACE keywords with the port keywords.
Ports 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.
Ingress port marking, scheduling, and congestion avoidance use Layer 2 CoS values. Ingress port marking, scheduling, and congestion avoidance do not use or set Layer 3 IP precedence or DSCP values.
Marking at Untrusted Ports
QoS marks all frames 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.
The port CoS value is configurable for each Ethernet port (for more information, see the "Configuring the CoS Value for a Port" section).
Ethernet Ingress Port Scheduling and Congestion Avoidance
QoS does not implement ingress port congestion avoidance on ports 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
Enter a show port capabilities command to see the queue structure of a port. The command displays one of the following:
•
•
•
Strict-priority queues are serviced in preference to other queues. QoS services traffic in a strict-priority queue before servicing the standard queue. When QoS services the standard queue, after receiving a packet, it checks for traffic in the strict-priority queue. If QoS detects traffic in the strict-priority queue, it suspends its service of the standard queue and completes service of all traffic in the strict-priority queue before returning to the standard queue.
Ingress Scheduling
QoS schedules traffic through the receive queues based on CoS values. In the 1p1q4t and 1p1q0t default configurations, QoS assigns all traffic with CoS 5 to the strict-priority queue; QoS assigns all other traffic to the standard queue. In the 1q4t default configuration, QoS assigns all traffic to the standard queue.
Ingress Congestion Avoidance
If a port is configured with the trust-cos keyword, QoS implements CoS-value-based receive-drop thresholds to avoid congestion in received traffic.
1q4t ports have this default drop-threshold configuration:
•
•
•
•
1p1q4t ports have this default drop-threshold configuration:
•
–
–
–
–
•
1p1q0t ports have this default drop-threshold configuration:
•
•
Note
Figure 41-8 shows the drop thresholds for a 1q4t port. Drop thresholds in other configurations function similarly.
Figure 41-8 Receive Queue Drop Thresholds
Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine
You can use the untrusted, trust-ipprec, trust-dscp, and trust-cos port keywords to classify traffic on a per-port basis for a Layer 3 switching engine to mark.
The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine and are not supported on 1q4t ports except Gigabit Ethernet. On 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates receive-queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to traffic. You must configure the trust-cos ACL that matches the ingress traffic to apply the trust-cos trust state.
In addition to per-port classification, you can create ACEs that classify traffic on a per-packet basis (for IP and IPX traffic, see the "Named IP ACLs" section and the "Creating or Modifying Named IPX ACLs" section) or on a per-frame basis (for other traffic, see the "Creating or Modifying Named MAC ACLs" section), regardless of the port configuration (see the "Marking Rules" section).
To mark traffic in response to per-port classification, the traffic must match an ACE that contains the dscp ACE keyword (see the "Marking Rules" section). In their default configuration, the ACEs in the default ACLs contain the dscp ACE keyword. Table 41-1 lists the per-port classifications and the marking rules that they invoke.
QoS uses configurable mapping tables to set internal and egress DSCP, which is a 6-bit value, from CoS and IP precedence, which are 3-bit values (for more information, see the "Internal DSCP Values" section and the "Configuring DSCP Value Maps" section).
Classification, Marking, and Policing with a Layer 3 Switching Engine
Note
These sections describe classification, marking, and policing with a Layer 3 switching engine:
•
•
Note
Internal DSCP Values
These sections describe the internal DSCP values:
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:
•
•
•
•
The trust state of traffic is the trust state of the ingress port unless set otherwise by the matching ACE.
Note
QoS uses configurable mapping tables to derive the internal 6-bit DSCP value from CoS or IP precedence, which are 3-bit values (see the"Mapping Received CoS Values to Internal DSCP Values" section or the "Mapping Received IP Precedence Values to Internal DSCP Values" section).
Egress DSCP and CoS Sources
For egress IP traffic, QoS creates a ToS byte from the internal DSCP value (which you can set equal to an IP precedence value) and sends it to the egress port to be written into IP packets. For trust-dscp and untrusted IP traffic, the ToS byte includes the original 2 least-significant bits from the received ToS byte.
For all egress traffic, QoS uses a configurable mapping table to derive a CoS value from the internal DSCP value associated with traffic (see the "Mapping Internal DSCP Values to Egress CoS Values" section). QoS sends the CoS value to Ethernet egress ports for use in scheduling and to be written into ISL and 802.1Q frames.
ACLs
QoS uses ACLs that contain ACEs. The ACEs specify classification criteria, a marking rule, and 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.
There are three ACL types: IP and, with a Layer 3 switching engine, IPX and MAC. QoS compares traffic of each type (IP, IPX, and MAC) only to the corresponding ACL type (see Table 41-2).
Table 41-2 Supported Ethertype Field Values
IP
0x0800
IP
IPX
0x8137 and 0x8138
IPX
MAC1
0x0600 and 0x0601
XNS
0x0BAD and 0x0BAF
Banyan VINES
0x6000-0x6009 and 0x8038-0x8042
DECnet
0x809b and 0x80f3
AppleTalk
1 QoS MAC ACLs that do not include an ethertype parameter match traffic with any value in the ethertype field, which allows MAC-level QoS to be applied to any traffic except IP and IPX.
QoS supports user-created named ACLs, each containing an ordered list of ACEs, and user-configurable default ACLs, each containing a single ACE.
Named ACLs
You create a named ACL when you enter an ACE with a new ACL name. You add an ACE to an existing ACL when you enter an ACE with the name of the existing ACL.
You can specify the classification criteria for each ACE in a named ACL. The classification criteria can be specific values or wildcards (for more information, see the "Creating or Modifying ACLs" section).
These sections describe the classification criteria that can be specified in a named ACL:
•
•
•
•
•
•
•
•
IP ACE Layer 3 Classification Criteria
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):
•
•
•
–
–
–
–
–
–
–
–
Note
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 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:
Note
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:
Note
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:
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
—
1 Matches all code values
Note
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
Note
IPX ACE Classification Criteria
You can create IPX ACEs that match specific IPX traffic by including these parameters (for more information, see the "Creating or Modifying 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 "Creating or Modifying Named MAC ACLs" section):
•
•
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
QoS MAC ACLs that do not include an ethertype parameter match traffic with any value in the ethertype field,
