Table Of Contents
Configuring QoS
Understanding How QoS Works
QoS Terminology
Flowcharts
QoS Feature Set Summary
Ethernet Ingress Port Features
Layer 3 Switching Engine Features
Layer 2 Switching Engine Features
Ethernet Egress Port Features
Single-Port ATM OC-12 Switching Module Features
Multilayer Switch Feature Card (MSFC, MSFC2, or MSFC3)
Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification
Overview
Marking at Untrusted Ports
Marking at Trusted Ports
Ethernet Ingress Port Scheduling and Congestion Avoidance
Receive Queues
Ingress Scheduling
Ingress Congestion Avoidance
Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine
Classification, Marking, and Policing with a Layer 3 Switching Engine
Internal DSCP Values
ACLs
Named ACLs
Default ACLs
Marking Rules
Policers
PFC2 Policing Decisions
PFC3 Policing Decisions
Attaching ACLs
PFC3 Egress DSCP Mutation
Final Layer 3 Switching Engine CoS and ToS Values
Classification and Marking on a Supervisor Engine 1 with a Layer 2 Switching Engine
Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking
Overview
Transmit Queues
Scheduling and Congestion Avoidance
Marking
QoS Statistics Data Export
QoS Default Configuration
QoS Configuration Guidelines and Restrictions
Configuring QoS on the Switch
Enabling QoS
Enabling DSCP Rewrite
Disabling DSCP Rewrite
Enabling Port-Based or VLAN-Based QoS
Configuring the Trust State of a Port
Configuring the CoS Value for a Port
Creating Policers
Deleting Policers
Creating or Modifying ACLs
ACL Names
ACE Name, Marking Rule, Policing, and Filtering Syntax
Named IP ACLs
Modifying the Default IP ACLs
Creating or Modifying the Named IPX ACLs
Creating or Modifying the Named MAC ACLs
Creating or Modifying the Default IPX and MAC ACLs
Deleting a Named ACL
Reverting to the Default Values in the Default ACLs
Discarding an Uncommitted ACL
Committing an ACL
Attaching an ACL to an Interface
Detaching an ACL from an Interface
Configuring PFC3 Egress DSCP Mutation
Configuring a DSCP Mutation Map
Clearing a Configured DSCP Mutation Map
Applying a DSCP Mutation Map to a VLAN
Clearing a DSCP Mutation Map from a VLAN
Configuring CoS-to-CoS Maps on 802.1Q Tunnel Ports
Defining a CoS-to CoS Map
Enabling a CoS-to CoS Map on a Port
Clearing a CoS-to-CoS Map
Mapping a CoS Value to a Host Destination MAC Address/VLAN Pair
Deleting a CoS Value to a Host Destination MAC Address/VLAN Pair
Enabling or Disabling Microflow Policing of Bridged Traffic
Configuring the Standard Receive-Queue Tail-Drop Thresholds
Configuring the 2q2t Port Standard Transmit-Queue Tail-Drop Thresholds
Configuring the Standard Queue WRED-Drop Thresholds
Allocating Bandwidth Between the Standard Transmit Queues
Configuring the Receive-Queue Size Ratio
Configuring the Transmit-Queue Size Ratio
Mapping the CoS Values to the Drop Thresholds
Associating the 1q4t/2q2t Ports
Associating the 1q8t, 1q2t/1p2q2t, and 1p1q4t/1p2q2t Ports
Associating the 1p1q0t/1p3q1t Ports
Associating the 1p1q8t/1p2q1t, 1p3q8t, and 1p7q8t Ports
Reverting to the CoS Map Default
Configuring the DSCP Value Maps
Mapping the Received CoS Values to the Internal DSCP Values
Mapping the Received IP Precedence Values to the Internal DSCP Values
Mapping the Internal DSCP Values to the Egress CoS Values
Mapping the DSCP Markdown Values
Displaying QoS Information
Displaying the QoS Statistics
Reverting to the QoS Defaults
Disabling QoS
Configuring COPS Support
Port ASICs
Understanding QoS Policy
Selecting COPS as the QoS Policy Source
Selecting the Locally Configured QoS Policy
Enabling Use of the Locally Configured QoS Policy
Assigning a Port Role
Removing a Role from the Port ASICs
Deleting a Role
Configuring the Policy Decision Point Servers
Deleting the PDP Server Configuration
Configuring the COPS Domain Name
Deleting the COPS Domain Name
Configuring the COPS Communications Parameters
Configuring RSVP Support
Enabling RSVP Support
Disabling RSVP Support
Enabling the Participation in the DSBM Election
Disabling the Participation in the DSBM Election
Configuring the Policy Decision Point Servers
Deleting the PDP Server Configuration
Configuring the RSVP Policy Timeout
Configuring the RSVP Use of Local Policy
Configuring QoS Statistics Data Export
Enabling QoS Statistics Data Export Globally
Enabling Per-Port QoS Statistics Data Export
Enabling Per-Aggregate Policer QoS Statistics Data Export
Clearing the Aggregate Policer QoS Statistics
Setting the QoS Statistics Data Export Time Interval
Configuring the QoS Statistics Data Export Destination Host and UDP Port
Displaying the QoS Statistics
Configuring QoS
This chapter describes how to configure quality of service (QoS) on the Catalyst 6500 series switches and includes the configuration information that is required to support Common Open Policy Service (COPS) and Resource ReSerVation Protocol (RSVP).
Note
•
For complete syntax and usage information for the commands that are used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.
•
For information on using automatic QoS, see Chapter 52, "Using Automatic QoS."
You can configure QoS using one of the following:
•
SNMP
•
COPS protocol
•
RSVP null service template and receiver proxy functionality
•
Command-line interface (CLI)
This chapter consists of these sections:
•
Understanding How QoS Works
•
QoS Default Configuration
•
Configuring QoS on the Switch
Understanding How QoS Works
Note
Throughout this publication and all Catalyst 6500 series publications, the term QoS refers to the QoS feature as implemented on the Catalyst 6500 series switch.
Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.
QoS on the Catalyst 6500 series switches selects network traffic, prioritizes it according to its relative importance, and provides priority-indexed treatment through congestion avoidance techniques. QoS makes network performance more predictable and bandwidth utilization more effective.
QoS sets the Layer 2 and Layer 3 values in the network traffic to a configured value or to a value that is based on the received Layer 2 or Layer 3 values. The IP traffic retains the Layer 3 value when it leaves the switch.
With PFC3, you can configure QoS for both the ingress and egress traffic. You can configure QoS per-port or per-VLAN for the ingress traffic. You can configure QoS only per VLAN for the egress traffic.
With other hardware, you can configure QoS per port or per VLAN for the ingress traffic.
These sections describe QoS:
•
QoS Terminology
•
Flowcharts
•
QoS Feature Set Summary
•
Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification
•
Classification, Marking, and Policing with a Layer 3 Switching Engine
•
Classification and Marking on a Supervisor Engine 1 with a Layer 2 Switching Engine
•
Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking
•
QoS Statistics Data Export
QoS Terminology
This section defines some QoS terminology:
•
Packets carry traffic at Layer 3.
•
Frames carry traffic at Layer 2. The Layer 2 frames carry the Layer 3 packets.
•
Labels are prioritization values that are carried in the packets and the frames:
–
Layer 2 class of service (CoS) values range between zero for low priority and seven for high priority:
The Layer 2 Inter-Switch Link (ISL) frame headers have a 1-byte User field that carries an IEEE 802.1p CoS value in the three least significant bits.
The Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the CoS value in the three most significant bits, which are called the User Priority bits.
The other frame types cannot carry the CoS values.
Note
On the ports that are configured as ISL trunks, all traffic is in ISL frames. On the ports that are configured as 802.1Q trunks, all traffic is in the 802.1Q frames except for the traffic in the native VLAN.
–
Layer 3 IP precedence values—The IP version 4 specification defines the three most significant bits of the 1-byte Type of Service (ToS) field as the IP precedence. The IP precedence values range between zero for low priority and seven for high priority.
–
Layer 3 differentiated services code point (DSCP) values—The Internet Engineering Task Force (IETF) defines the six most significant bits of the 1-byte ToS field as the DSCP. The priority that is represented by a particular DSCP value is configurable. The DSCP values range between 0 and 63 (for more information, see the "Configuring the DSCP Value Maps" section).
Note
The Layer 3 IP packets can carry either an IP precedence value or a DSCP value. QoS supports the use of either value, because DSCP values can be set equal to the IP precedence values.
•
Classification is the selection of traffic.
•
Marking, according to RFC 2475, is the process of setting a Layer 3 DSCP value in a packet; in this publication, the definition of marking is extended to include setting the Layer 2 CoS values.
•
Scheduling is the assignment of traffic to a queue. QoS assigns the traffic that is based on the CoS values.
•
Congestion avoidance is the process by which QoS reserves the ingress and egress port capacity for the traffic with the high-priority CoS values. QoS implements congestion avoidance with the CoS value-based drop thresholds. A drop threshold is the percentage of buffer utilization at which the traffic with a specified CoS value is dropped, leaving the buffer available for the traffic with the higher-priority CoS values.
•
Policing is the process by which the switch limits the bandwidth that is consumed by a flow of traffic. Policing can mark or drop traffic.
•
Except where specifically differentiated, the Layer 3 switching engine refers to either of the following:
–
Supervisor Engine 2 with Layer 3 Switching Engine II (Policy Feature Card 2 or PFC2)
–
Supervisor Engine 1 with Layer 3 Switching Engine WS-F6K-PFC (Policy Feature Card or PFC)
•
Random early detection (RED) is a drop threshold algorithm.
•
Shaped round robin (SRR) is a dequeuing algorithm.
•
Weighted random early detection (WRED) is a drop threshold algorithm.
•
Weighted round robin (WRR) is a dequeuing algorithm.
•
Deficit weighted round robin (DWRR) is a dequeuing algorithm.
Flowcharts
Figure 51-1 shows how traffic flows through the QoS features; Figure 51-2 through Figure 51-9 show more details of the traffic flow through QoS features.
Figure 51-1 Traffic Flow Through QoS Features with PFC3
Note
PFC3 can provide Layer 3 switching for the WAN traffic. PFC3 can provide QoS for the ingress WAN traffic that is forwarded in the software by MSFC3. PFC3 can provide QoS for the egress WAN traffic that entered the switch through a LAN port or that was forwarded in the software by MSFC3.
Figure 51-2 Traffic Flow Through QoS Features with PFC and PFC2
Note
•
PFC or PFC2 can provide Layer 3 switching for the ingress WAN traffic.
•
PFC or PFC2 does not provide QoS for the WAN traffic. With PFC or PFC2, PFC QoS does not change the ToS byte in the WAN traffic.
•
Ingress LAN traffic that is Layer 3 switched does not go through the Multilayer Switch Feature Card (MSFC or MSFC2) and retains the CoS value that is assigned by the Layer 3 switching engine.
•
Enter the show port capabilities command to see the queue structure of a port (for more information, see the "Receive Queues" section and the "Transmit Queues" section).
Figure 51-3 Ethernet ingress Port Classification, Marking, Scheduling, and Congestion Avoidance
Figure 51-4 PFC3 Classification, Marking, and Policing
Figure 51-5 PFC and PFC2 Classification, Marking, and Policing
Figure 51-6 Layer 2 Switching Engine Classification and Marking
Figure 51-7 Multilayer Switch Feature Card Marking (MSFC and MSFC2)
Figure 51-8 Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking
Figure 51-9 Single-Port ATM OC-12 Switching Module Marking
QoS Feature Set Summary
The QoS feature set on your switch is determined by the switching engine on the supervisor engine. Enter the show module command for the supervisor engine to display your switching engine configuration. The display shows the "Sub-Type" to be one of the following:
•
Supervisor Engine 32 (WS-SUP32-GE-3B) with Policy Feature Card 3B (PFC3B/PFC3BXL)
•
Supervisor Engine 720 (WS-SUP720) with PFC3A/PFC3B/PFC3BXL
•
Supervisor Engine 2 (WS-X6K-SUP2-2GE) with Layer 3 Switching Engine II (WS-F6K-PFC2—Policy Feature Card 2 or PFC2)
•
Supervisor Engine 1 (WS-X6K-SUP1A-2GE or WS-X6K-SUP1-2GE) with one of the following:
–
Layer 3 Switching Engine (WS-F6K-PFC—Policy Feature Card or PFC)
–
Layer 2 Switching Engine II (WS-F6020A)
–
Layer 2 Switching Engine I (WS-F6020)
The Layer 3 Switching Engine (WS-F6K-PFC) and Layer 3 Switching Engine II (WS-F6K-PFC2) support similar feature sets. The two Layer 2 switching engines support the same QoS feature set.
In addition to the features that are supported by the other two Layer 3 switching engines, PFC3A supports these features:
•
Egress QoS
•
Egress DSCP mutation
•
Optional egress DSCP rewrite
These sections describe the QoS feature sets:
•
Ethernet Ingress Port Features
•
Layer 3 Switching Engine Features
•
Layer 2 Switching Engine Features
•
Ethernet Egress Port Features
•
Single-Port ATM OC-12 Switching Module Features
•
Multilayer Switch Feature Card (MSFC, MSFC2, or MSFC3)
Ethernet Ingress Port Features
With any switching engine, QoS supports classification, marking, scheduling, and congestion avoidance using the Layer 2 CoS values at the Ethernet ingress ports. Classification, marking, scheduling, and congestion avoidance at the Ethernet ingress ports do not use or set the Layer 3 IP precedence or DSCP values. With a Layer 3 switching engine, you can configure the Ethernet ingress port trust states that can be used by the switching engine to set the Layer 3 IP precedence or DSCP values and the Layer 2 CoS value. For more information, see the "Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification" section.
Layer 3 Switching Engine Features
With PFC3A/PFC3B/PFC3BXL, PFC2, or PFC, QoS supports classification, marking, and policing using the access control lists (ACLs).
PFC3A/PFC3B/PFC3BXL provides QoS for the ingress and egress traffic. PFC2 and PFC provide QoS only for the ingress traffic.
With PFC3, QoS supports map-based egress DSCP mutation, which allows you to remark the egress traffic after it has been subjected to a policing rule, and the option to preserve the received DSCP in the egress traffic.
The ACLs contain the access control entries (ACEs) that specify the Layer 2, 3, and 4 classification criteria, a marking rule, and policers. Marking sets the Layer 3 IP precedence or DSCP values and the Layer 2 CoS value to either the received or configured Layer 2 or Layer 3 values. Policing uses bandwidth limits to either drop or mark the nonconforming traffic. For more information, see the "Classification, Marking, and Policing with a Layer 3 Switching Engine" section.
During processing, a Layer 3 switching engine associates a DSCP value with all traffic, including non-IP traffic. For more information, see the "Internal DSCP Values" section.
Layer 2 Switching Engine Features
With a Layer 2 Switching Engine, QoS can classify traffic using the Layer 2 destination MAC addresses, VLANs, and marking using the Layer 2 CoS values. Classification and marking with a Layer 2 Switching Engine do not use or set the Layer 3 IP precedence or DSCP values. For more information, see the "Classification and Marking on a Supervisor Engine 1 with a Layer 2 Switching Engine" section.
Ethernet Egress Port Features
With any switching engine, QoS supports Ethernet egress port scheduling and congestion avoidance using the Layer 2 CoS values. Ethernet egress port marking sets the Layer 2 CoS values and, with a Layer 3 switching engine, the Layer 3 DSCP values. For more information, see the "Ethernet Egress Port Scheduling, Congestion Avoidance, and Marking" section.
Single-Port ATM OC-12 Switching Module Features
The ingress interface from a single-port ATM OC-12 switching module is untrusted, and QoS sets CoS to zero in all traffic that is received from it. With a Layer 3 switching engine, QoS can mark the IP traffic that is transmitted to a single-port ATM OC-12 switching module with the Layer 3 DSCP values.
Multilayer Switch Feature Card (MSFC, MSFC2, or MSFC3)
QoS marks the IP traffic that is transmitted to an MSFC with the Layer 3 DSCP values. The CoS is zero in all traffic that is sent from an MSFC to the egress ports.
Note
The traffic that is Layer 3 switched does not go through the MFSC and retains the CoS value that is assigned by the Layer 3 switching engine.
Ethernet Ingress Port Marking, Scheduling, Congestion Avoidance, and Classification
These sections describe the Ethernet ingress port marking, scheduling, congestion avoidance, and classification:
•
Overview
•
Marking at Untrusted Ports
•
Marking at Trusted Ports
•
Ethernet Ingress Port Scheduling and Congestion Avoidance
•
Receive Queues
•
Ingress Scheduling
•
Ingress Congestion Avoidance
•
Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine
Overview
The trust state of an Ethernet port determines how it marks, schedules, and classifies the received traffic, and whether or not congestion avoidance is implemented. You can configure the trust state of each port with one of these keywords:
•
untrusted (default)
•
trust-ipprec (Layer 3 switching engine only—not supported on 1q4t ports except Gigabit Ethernet)
•
trust-dscp (Layer 3 switching engine only—not supported on 1q4t ports except Gigabit Ethernet)
•
trust-cos
Note
On 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates the receive queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to the traffic. You must configure the trust-cos ACL that matches the ingress traffic to apply the trust-cos trust state.
For more information, see the "Configuring the Trust State of a Port" section.
In addition to the port configuration keywords that are listed above, with a Layer 3 switching engine, QoS uses the trust-ipprec, trust-dscp, and trust-cos ACE keywords. Do not confuse the ACE keywords with the port keywords.
The ports that are configured with the untrusted keyword are called "untrusted ports." The ports that are configured with the trust-ipprec, trust-dscp, or trust-cos keywords are called "trusted ports." QoS implements ingress port congestion avoidance only on the ports that are configured with the trust-cos keyword.
Ingress port marking, scheduling, and congestion avoidance use the Layer 2 CoS values. Ingress port marking, scheduling, and congestion avoidance do not use or set the Layer 3 IP precedence or DSCP values.
Marking at Untrusted Ports
QoS marks all frames that are received through the untrusted ports with the port CoS value (the default is zero). QoS does not implement ingress port congestion avoidance on the untrusted ports. The traffic goes directly to the switching engine.
Marking at Trusted Ports
When an ISL frame enters the switch through a trusted port, QoS accepts the three least significant bits in the User field as a CoS value. When an 802.1Q frame enters the switch through a trusted port, QoS accepts the User Priority bits as a CoS value. QoS marks all traffic that is received in the other frame types with the port CoS value.
The port CoS value is configurable for each Ethernet port. For more information, see the "Configuring the CoS Value for a Port" section.
Ethernet Ingress Port Scheduling and Congestion Avoidance
QoS does not implement ingress port congestion avoidance on the ports that are configured with the untrusted, trust-ipprec, or trust-dscp keywords. The traffic goes directly to the switching engine.
QoS uses the CoS-value-based receive-queue drop thresholds to avoid congestion in the traffic that is entering the switch through a port that is configured with the trust-cos keyword (for more information, see the "Configuring the Trust State of a Port" section).
Receive Queues
Enter the show port capabilities command to see the queue structure of a port. The command displays one of the following:
•
rx-(1q8t) indicates one standard queue with eight configurable tail-drop thresholds.
•
rx-(1q2t) indicates one standard queue with one configurable tail-drop threshold and one nonconfigurable tail-drop threshold.
•
rx-(1q4t) indicates one standard queue with four configurable tail-drop thresholds.
•
rx-(1p1q4t) indicates one strict-priority queue and one standard queue with four configurable tail-drop thresholds.
•
rx-(1p1q0t) indicates one strict-priority queue and one standard queue with a nonconfigurable threshold.
•
rx-(1p1q8t) indicates one strict-priority queue and one standard queue with eight configurable WRED-drop thresholds (on the 1p1q8t ports, the standard queue also has one nonconfigurable tail-drop threshold).
Strict-priority queues are serviced in preference to other queues. QoS services the traffic in a strict-priority queue before servicing the standard queue. When QoS services the standard queue, after receiving a packet, it checks for the traffic in the strict-priority queue. If QoS detects the traffic in the strict-priority queue, it suspends its service of the standard queue and completes the service of all traffic in the strict-priority queue before returning to the standard queue.
Ingress Scheduling
QoS schedules the traffic through the receive queues based on the CoS values. In the default configuration, PFC QoS assigns all traffic with CoS 5 to the strict-priority queue (if present); PFC QoS assigns all other traffic to the standard queue. In the absence of a strict-priority queue, PFC QoS assigns all traffic to the standard queues.
Ingress Congestion Avoidance
If a port is configured with the trust-cos keyword, QoS implements CoS-value-based receive-queue drop thresholds to avoid congestion in the received traffic. See the "QoS Default Configuration" section for the default CoS-to-threshold mapping.
Note
For some port types, you can configure the standard receive queue to use both a tail-drop and a WRED-drop threshold by mapping a CoS value to the queue or to the queue and a threshold. The switch uses the tail-drop threshold for the traffic carrying the CoS values that are mapped only to the queue. The switch uses the WRED-drop thresholds for the traffic carrying the CoS values that are mapped to the queue and a threshold. For more information, see the "1p1q8t Receive Queues" section.
Figure 51-10 shows the drop thresholds for a 1q4t port. The drop thresholds in the other configurations function similarly.
Figure 51-10 Receive-Queue Drop Thresholds
Ethernet Ingress Port Classification Features with a Layer 3 Switching Engine
You can use the untrusted, trust-ipprec, trust-dscp, and trust-cos port keywords to classify the traffic on a per-port basis for a Layer 3 switching engine to mark.
The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine and are not supported on the 1q4t ports except Gigabit Ethernet. On the 1q4t ports (except Gigabit Ethernet), the trust-cos port keyword displays an error message, activates the receive-queue drop thresholds, and—as indicated by the error message—does not apply the trust-cos trust state to the traffic. You must configure the trust-cos ACL that matches the ingress traffic to apply the trust-cos trust state.
In addition to the per-port classification, you can create the ACEs that classify the traffic on a per-packet basis (for the IP and IPX traffic, see the "Named IP ACLs" section and the "Creating or Modifying the Named IPX ACLs" section) or on a per-frame basis (for the other traffic, see the "Creating or Modifying the Named MAC ACLs" section), regardless of the port configuration (see the "Marking Rules" section).
To mark the traffic in response to per-port classification, the traffic must match an ACE that contains the dscp ACE keyword (see the "Marking Rules" section). In their default configuration, the ACEs in the default ACLs contain the dscp ACE keyword. Table 51-1 lists the per-port classifications and the marking rules that they invoke.
Table 51-1 Marking Based on Per-Port Classification
Port Keyword
|
ACE Keyword
|
Marking Rule
|
untrusted
|
dscp
|
Set the internal and egress DSCP as specified in the ACE.
|
trust-ipprec
|
dscp
|
For the IP traffic, set the internal and egress DSCP from the received Layer 3 IP precedence value. For the other traffic, set the internal and egress DSCP from the received or port Layer 2 CoS value.
Note—With the trust-ipprec port keyword, QoS uses only the IP precedence bits. If the traffic with a DSCP value enters the switch through a port that is configured with the trust-ipprec port keyword, the three most significant bits of the DSCP value are interpreted as an IP precedence value; QoS ignores the rest of the DSCP value.
|
trust-dscp
|
dscp
|
For the IP traffic, set the internal and egress DSCP from the received Layer 3 DSCP value. For other traffic, set the internal and egress DSCP from the received or port Layer 2 CoS value.
|
trust-cos
|
dscp
|
Set the internal and egress DSCP from the received or port Layer 2 CoS value.
|
QoS uses the configurable mapping tables to set the internal and egress DSCP, which is a 6-bit value, from the CoS and IP precedence, which are 3-bit values (for more information, see the "Internal DSCP Values" section and the "Configuring the DSCP Value Maps" section).
Classification, Marking, and Policing with a Layer 3 Switching Engine
Note
With a Layer 3 switching engine, the Catalyst 6500 series switches provide QoS only for the following frame types: Ethernet_II, Ethernet_802.3, Ethernet_802.2, and Ethernet_SNAP.
These sections describe classification, marking, and policing with a Layer 3 switching engine:
•
Internal DSCP Values
•
ACLs
•
Named ACLs
•
Default ACLs
•
Marking Rules
•
Policers
•
PFC2 Policing Decisions
•
PFC3 Policing Decisions
•
Attaching ACLs
•
PFC3 Egress DSCP Mutation
•
Final Layer 3 Switching Engine CoS and ToS Values
Note
Classification with a Layer 3 switching engine uses the Layer 2, 3, and 4 values. Marking with a Layer 3 switching engine uses the Layer 2 CoS values and the Layer 3 IP precedence or DSCP values.
Internal DSCP Values
These sections describe the internal DSCP values:
•
Internal DSCP Sources
•
Egress DSCP and CoS Sources
Internal DSCP Sources
During processing, the priority of all traffic (including non-IP traffic) is represented with an internal DSCP value. QoS derives the internal DSCP value from the following:
•
For the trust-cos traffic, from the received or port Layer 2 CoS values (the traffic from an untrusted port has the port CoS value and if the traffic from an untrusted port matches a trust-cos ACL, QoS derives the internal DSCP value from the port CoS value)
•
For the trust-ipprec traffic, from the received IP precedence values
•
For the trust-dscp traffic, from the received DSCP values
•
For the untrusted traffic, from the port CoS or configured DSCP values
The trust state of the traffic is the trust state of the ingress port unless set otherwise by the matching ACE.
Note
A trust-cos ACL cannot restore the received CoS in the traffic from the untrusted ports. The traffic from the untrusted ports always has the port CoS value.
QoS uses the configurable mapping tables to derive the internal 6-bit DSCP value from the CoS or IP precedence, which are 3-bit values (see the"Mapping the Received CoS Values to the Internal DSCP Values" section or the "Mapping the Received IP Precedence Values to the Internal DSCP Values" section).
Egress DSCP and CoS Sources
For the egress IP traffic, QoS creates a ToS byte from the internal DSCP value (which you can set equal to an IP precedence value) and sends it to the egress port to be written into the IP packets. For the trust-dscp and untrusted IP traffic, the ToS byte includes the original 2 least-significant bits from the received ToS byte.
For all egress traffic, QoS uses a configurable mapping table to derive a CoS value from the internal DSCP value that is associated with the traffic (see the "Mapping the Internal DSCP Values to the Egress CoS Values" section). QoS sends the CoS value to the Ethernet egress ports for use in scheduling and to be written into the ISL and 802.1Q frames.
ACLs
QoS uses the ACLs that contain the ACEs. The ACEs specify the classification criteria, a marking rule, and the policers. QoS compares the received traffic to the ACEs in the ACLs until a match occurs. When the traffic matches the classification criteria in an ACE, QoS marks and polices the packet as specified in the ACE and makes no further comparisons.
There are three ACL types: IP, and with a Layer 3 switching engine, IPX and MAC. QoS compares the traffic of each type (IP, IPX, and MAC) only to the corresponding ACL type (see Table 51-2).
Table 51-2 Supported EtherType Field Values
ACL Type
|
EtherType Field Value
|
Protocol
|
IP
|
0x0800
|
IP
|
IPX 1
|
0x8137 and 0x8138
|
IPX
|
MAC2
|
0x0600 and 0x0601
|
XNS
|
0x0BAD and 0x0BAF
|
Banyan VINES
|
0x6000-0x6009 and 0x8038-0x8042
|
DECnet
|
0x809b and 0x80f3
|
AppleTalk
|
QoS supports the user-created named ACLs, each containing an ordered list of ACEs, and the user-configurable default ACLs, each containing a single ACE.
Named ACLs
You create a named ACL when you enter an ACE with a new ACL name. You add an ACE to an existing ACL when you enter an ACE with the name of the existing ACL.
You can specify the classification criteria for each ACE in a named ACL. The classification criteria can be specific values or wildcards (for more information, see the "Creating or Modifying ACLs" section).
These sections describe the classification criteria that can be specified in a named ACL:
•
IP ACE Layer 3 Classification Criteria
•
IP ACE Layer 4 Protocol Classification Criteria
•
IP ACE Layer 4 TCP Classification Criteria
•
IP ACE Layer 4 UDP Classification Criteria
•
IP ACE Layer 4 ICMP Classification Criteria
•
IP ACE Layer 4 IGMP Classification Criteria
•
IPX ACE Classification Criteria
•
MAC ACE Layer 2 Classification Criteria
IP ACE Layer 3 Classification Criteria
You can create the IP ACEs that match the traffic with the specific Layer 3 values by including these Layer 3 parameters (see the "Named IP ACLs" section):
•
IP source address and mask, entered as specific values or with the any keyword or with the host keyword and a host address.
•
IP destination address and mask, entered as specific values or with the any keyword or with the host keyword and a host address.
•
DSCP value (0-63) or IP precedence that is specified with a numeric value (0-7) or these keywords:
–
Network (IP precedence 7)
–
Internet (IP precedence 6)
–
Critical (IP precedence 5)
–
Flash-override (IP precedence 4)
–
Flash (IP precedence 3)
–
Immediate (IP precedence 2)
–
Priority (IP precedence 1)
–
Routine (IP precedence 0)
Note
The IP ACEs that do not include a DSCP or IP precedence value parameter match all DSCP or IP precedence values.
IP ACE Layer 4 Protocol Classification Criteria
You can create the IP ACEs that match the specific Layer 4 protocol traffic by including a Layer 4 protocol parameter (see the "IP ACLs for Other Layer 4 Protocols" section). You can specify the protocol numerically (0-255) or with these keywords: ahp (51), eigrp (88), esp (50), gre (47), igrp (9), icmp (1), igmp (2), igrp (9), ip (0), ipinip (4), nos (94), ospf (89), pcp (108), pim (103), tcp (6), or udp (17).
Note
The IP ACEs that do not include a Layer 4 protocol parameter or that include the ip keyword match all IP traffic.
IP ACE Layer 4 TCP Classification Criteria
You can create the Transmission Control Protocol (TCP) ACEs that match the traffic for the specific TCP ports by including the TCP source and/or destination port parameters (for more information, see the "IP ACEs for TCP Traffic" section).
You can specify the TCP port parameters numerically (0-65535) or with these keywords:
Keyword
|
Port
|
|
Keyword
|
Port
|
|
Keyword
|
Port
|
|
Keyword
|
Port
|
bgp
|
179
|
|
ftp
|
21
|
|
lpd
|
515
|
|
telnet
|
23
|
chargen
|
19
|
ftp-data
|
20
|
nntp
|
119
|
time
|
37
|
daytime
|
13
|
gopher
|
70
|
pop2
|
109
|
uucp
|
540
|
discard
|
9
|
hostname
|
101
|
pop3
|
110
|
whois
|
43
|
domain
|
53
|
irc
|
194
|
smtp
|
25
|
www
|
80
|
echo
|
7
|
klogin
|
543
|
sunrpc
|
111
|
|
|
finger
|
79
|
kshell
|
544
|
tacacs
|
49
|
|
|
Note
The TCP ACEs that do not include a Layer 4 TCP port parameter match all TCP traffic.
IP ACE Layer 4 UDP Classification Criteria
You can create the User Datagram Protocol (UDP) ACEs that match the traffic for specific UDP source and/or destination ports by including the UDP port parameters. For more information, see the "IP ACEs for UDP Traffic" section.
You can specify the UDP port parameters numerically (0-65535) or with these keywords:
Keyword
|
Port
|
|
Keyword
|
Port
|
|
Keyword
|
Port
|
|
Keyword
|
Port
|
biff
|
512
|
|
echo
|
7
|
|
rip
|
520
|
|
talk
|
517
|
bootpc
|
68
|
mobile-ip
|
434
|
snmp
|
161
|
tftp
|
69
|
bootps
|
67
|
nameserver
|
42
|
snmptrap
|
162
|
time
|
37
|
discard
|
9
|
netbios-dgm
|
138
|
sunrpc
|
111
|
who
|
513
|
dns
|
53
|
netbios-ns
|
137
|
syslog
|
514
|
xdmcp
|
177
|
dnsix
|
195
|
ntp
|
123
|
tacacs
|
49
|
|
|
Note
The UDP ACEs that do not include a Layer 4 UDP port parameter match all UDP traffic.
IP ACE Layer 4 ICMP Classification Criteria
You can create the Internet Control Management Protocol (ICMP) ACEs that match the traffic containing specific ICMP messages by including the ICMP types and optionally, the ICMP codes. For more information, see the "IP ACEs for ICMP Traffic" section.
You can specify the ICMP types and codes numerically (0-255) or with these keywords:
Keyword
|
Type
|
Code
|
Keyword
|
Type
|
Code
|
administratively-prohibited
|
3
|
13
|
net-tos-unreachable
|
3
|
11
|
alternate-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
|
—
|