This chapter describes how to configure quality of service (QoS) on your switch. With this feature, you can provide preferential treatment to certain types of traffic. Without QoS, the switch offers best-effort service to each packet, regardless of the packet contents or size. It transmits the packets without any assurance of reliability, delay bounds, or throughput.
To use the features described in this chapter, you must have the enhanced software image installed on your switch.
If you have the standard software image installed on your switch, you cannot configure some of the features. Table 24-1 lists the sections that describe the features that you can configure.
Topic | Section |
|---|---|
Queueing and scheduling at the egress ports | |
Configuring QoS | |
QoS can be configured either by using the Cluster Management Suite (CMS) or through the command-line interface (CLI). Refer to the CMS online help for step-by-step configuration procedures through CMS. For information about accessing and using CMS, see "Getting Started with CMS."
This chapter consists of these sections: This section describes how QoS is implemented on the Catalyst 2950 switch. If you have the standard software image installed on your switch, some concepts and features in this section might not apply. 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. When you configure the QoS feature, you can select specific network traffic, prioritize it according to its relative importance, and use congestion-management and congestion-avoidance techniques to provide preferential treatment. Implementing QoS in your network makes network performance more predictable and bandwidth utilization more effective. The QoS implementation is based on the DiffServ architecture, an emerging standard from the Internet Engineering Task Force (IETF). This architecture specifies that each packet is classified upon entry into the network. The classification is carried in the IP packet header, using 6 bits from the deprecated IP Type-of-Service (TOS) field to carry the classification (class) information. Classification can also be carried in the Layer 2 frame. These special bits in the Layer 2 frame or a Layer 3 packet are described here and shown in Figure 24-1: • Layer 2 802.1Q frame headers have a 2-byte Tag Control Information field that carries the class of service (CoS) value in the three most-significant bits, which are called the User Priority bits. On interfaces configured as Layer 2 802.1Q trunks, all traffic is in 802.1Q frames except for traffic in the native VLAN. Other frame types cannot carry Layer 2 CoS values. Layer 2 CoS values range from 0 for low priority to 7 for high priority. • Layer 3 IP packets can carry a Differentiated Services Code Point (DSCP) value. The supported DSCP values are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56. Figure 24-1 QoS Classification Layers in Frames and Packets All switches and routers that access the Internet rely on the class information to provide the same forwarding treatment to packets with the same class information and different treatment to packets with different class information. The class information in the packet can be assigned by end hosts or by switches or routers along the way, based on a configured policy, detailed examination of the packet, or both. Detailed examination of the packet is expected to happen closer to the edge of the network so that the core switches and routers are not overloaded. Switches and routers along the path can use the class information to limit the amount of resources allocated per traffic class. The behavior of an individual device when handling traffic in the DiffServ architecture is called per-hop behavior. If all devices along a path provide a consistent per-hop behavior, you can construct an end-to-end QoS solution. Implementing QoS in your network can be a simple or complex task and depends on the QoS features offered by your internetworking devices, the traffic types and patterns in your network, and the granularity of control that you need over incoming and outgoing traffic. Figure 24-2 shows the basic QoS model. Actions at the ingress interface include classifying traffic, policing, and marking: • • • Actions at the egress interface include queueing and scheduling: • • Figure 24-2 Basic QoS Model Classification is the process of distinguishing one kind of traffic from another by examining the fields in the packet. Classification occurs only on a physical interface basis. No support exists for classifying packets at the VLAN or the switched virtual interface level. You specify which fields in the frame or packet that you want to use to classify incoming traffic. You can use IP standard, IP extended, and Layer 2 MAC ACLs to define a group of packets with the same characteristics (class). In the QoS context, the permit and deny actions in the access control entries (ACEs) have different meanings than with security ACLs: • • • • • – – – • After a traffic class has been defined with the ACL, you can attach a policy to it. A policy might contain multiple classes with actions specified for each one of them. A policy might include commands to classify the class as a particular aggregate (for example, assign a DSCP) or rate-limit the class. This policy is then attached to a particular port on which it becomes effective. You implement IP ACLs to classify IP traffic by using the access-list global configuration command; you implement Layer 2 MAC ACLs to classify Layer 2 traffic by using the mac access-list extended global configuration command. A class map is a mechanism that you use to isolate and name a specific traffic flow (or class) from all other traffic. The class map defines the criteria used to match against a specific traffic flow to further classify it; the criteria can include matching the access group defined by the ACL. If you have more than one type of traffic that you want to classify, you can create another class map and use a different name. After a packet is matched against the class-map criteria, you further classify it through the use of a policy map. A policy map specifies which traffic class to act on. Actions can include setting a specific DSCP value in the traffic class or specifying the traffic bandwidth limitations and the action to take when the traffic is out of profile. Before a policy map can be effective, you must attach it to an interface. You create a class map by using the class-map global configuration command or the class policy-map configuration command. You should use the class-map global configuration command when the map is shared among many ports. When you enter the class-map global configuration command, the switch enters the class-map configuration mode. In this mode, you define the match criterion for the traffic by using the match class-map configuration command. You create and name a policy map by using the policy-map global configuration command. When you enter this command, the switch enters the policy-map configuration mode. In this mode, you specify the actions to take on a specific traffic class by using the class or set policy-map configuration and policy-map class configuration commands. To make the policy map effective, you attach it to an interface by using the service-policy interface configuration command. The policy map can also contain commands that define the policer, the bandwidth limitations of the traffic, and the action to take if the limits are exceeded. For more information, see the "Policing and Marking" section. A policy map also has these characteristics: • • • For configuration information, see the "Configuring a QoS Policy" section. Policing involves creating a policer that specifies the bandwidth limits for the traffic. Packets that exceed the limits are out of profile or nonconforming. Each policer specifies the action to take for packets that are in or out of profile. These actions, carried out by the marker, include dropping the packet or marking down the packet with a new value that is user-defined. You can create this type of policer: Individual—QoS applies the bandwidth limits specified in the policer separately to each matched traffic class. You configure this type of policer within a policy map by using the policy-map configuration command. For non-IP traffic, you have these marking options: • • The trust DSCP configuration is meaningless for non-IP traffic. If you configure a port with this option and non-IP traffic is received, the switch assigns the default port CoS value and classifies traffic based on the CoS value. For IP traffic, you have these classification options: • • When configuring policing and policers, keep these items in mind: • • • • • – – – • Understanding QoS
For a list of available features, see Table 24-1. 
Prioritization values in Layer 2 frames Prioritization bits in Layer 3 packets 
Basic QoS Model
Classifying distinguishes one kind of traffic from another. For more information, see the "Classification" section. Policing determines whether a packet is in or out of profile according to the configured policer, and the policer limits the bandwidth consumed by a flow of traffic. The result of this determination is passed to the marker. For more information, see the "Policing and Marking" section. Marking evaluates the policer and configuration information for the action to be taken when a packet is out of profile and decides what to do with the packet (pass through a packet without modification, mark down the DSCP value in the packet, or drop the packet). For more information, see the "Policing and Marking" section. Queueing evaluates the CoS value and determines which of the four egress queues in which to place the packet. Scheduling services the four egress queues based on their configured weighted round robin (WRR) weights. 
Classification
Classification Based on QoS ACLs
If a match with a permit action is encountered (first-match principle), the specified QoS-related action is taken. If no match with a permit action is encountered and all the ACEs have been examined, no QoS processing occurs on the packet. If multiple ACLs are configured on an interface, the packet matches the first ACL with a permit action, and QoS processing begins. Configuration of a deny action is not supported in QoS ACLs on a Catalyst 2950 switch. System-defined masks are allowed in class maps with these restrictions: A combination of system-defined and user-defined masks cannot be used in the multiple class maps that are a part of a policy map. System-defined masks that are a part of a policy map must all use the same type of system mask. For example, a policy map cannot have a class map that uses the permit tcp any any ACE and another that uses the permit ip any any ACE. A policy map can contain multiple class maps that all use the same user-defined mask or the same system-defined mask.For more information on ACL restrictions, see the "Guidelines for Configuring ACLs on the Catalyst 2950 Switches" section. Classification Based on Class Maps and Policy Maps
A policy map can contain multiple class statements. A separate policy-map class can exist for each type of traffic received through an interface. A policy-map configuration state supersedes any actions due to an interface trust state. Policing and Marking
Use the port default. If the frame does not contain a CoS value, assign the default port CoS value to the incoming frame. Trust the CoS value in the incoming frame (configure the port to trust CoS). Layer 2 802.1Q frame headers carry the CoS value in the three most-significant bits of the Tag Control Information field. CoS values range from 0 for low priority to 7 for high priority. Trust the IP DSCP in the incoming packet (configure the port to trust DSCP), and assign the same DSCP to the packet for internal use. The IETF defines the 6 most-significant bits of the 1-byte Type of Service (ToS) field as the DSCP. The priority represented by a particular DSCP value is configurable. The supported DSCP values are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56. Trust the CoS value (if present) in the incoming packet, and generate the DSCP by using the CoS-to-DSCP map. By default, no policers are configured. Policers can only be configured on a physical port. There is no support for policing at a VLAN or switched virtual interface (SVI) level. Only one policer can be applied to a packet in the input direction. Only the average rate and committed burst parameters are configurable. Policing occurs on the ingress interfaces: 60 policers are supported on ingress Gigabit-capable Ethernet ports. 6 policers are supported on ingress 10/100 Ethernet ports. Granularity for the average burst rate is 1 Mbps for 10/100 ports and 8 Mbps for Gigabit Ethernet ports. On an interface configured for QoS, all traffic received through the interface is classified, policed, and marked according to the policy map attached to the interface. On a trunk interface configured for QoS, traffic in all VLANs received through the interface is classified, policed, and marked according to the policy map attached to the interface.
Mapping Tables
The Catalyst 2950 switches support these types of marking to apply to the switch:
•CoS value to the DSCP value
•DSCP value to CoS value
Before the traffic reaches the scheduling stage, QoS uses the configurable DSCP-to-CoS map to derive a CoS value from the internal DSCP value. The CoS-to-DSCP and DSCP-to-CoS map have default values that might or might not be appropriate for your network. For configuration information, see the "Configuring CoS Maps" section. The Catalyst 2950 switches provide QoS-based 802.1P CoS values. QoS uses classification and scheduling to transmit network traffic from the switch in a predictable manner. QoS classifies frames by assigning priority-indexed CoS values to them and gives preference to higher-priority traffic such as telephone calls. Before you set up 802.1P CoS on a Catalyst 2950 that operates with the Catalyst 6000 family of switches, refer to the Catalyst 6000 documentation. There are differences in the 802.1P implementation, and they should be understood to ensure compatibility. Frames received from users in the administratively-defined VLANs are classified or tagged for transmission to other devices. Based on rules that you define, a unique identifier (the tag) is inserted in each frame header before it is forwarded. The tag is examined and understood by each device before any broadcasts or transmissions to other switches, routers, or end stations. When the frame reaches the last switch or router, the tag is removed before the frame is transmitted to the target end station. VLANs that are assigned on trunk or access ports without identification or a tag are called native or untagged frames. For IEEE 802.1Q frames with tag information, the priority value from the header frame is used. For native frames, the default priority of the input port is used. Each port on the switch has a single receive queue buffer (the ingress port) for incoming traffic. When an untagged frame arrives, it is assigned the value of the port as its port default priority. You assign this value by using the CLI or CMS. A tagged frame continues to use its assigned CoS value when it passes through the ingress port. CoS configures each transmit port (the egress port) with a normal-priority transmit queue and a high-priority transmit queue, depending on the frame tag or the port information. Frames in the normal-priority queue are forwarded only after frames in the high-priority queue are forwarded. The Catalyst 2950 switches (802.1P user priority) have four priority queues. The frames are forwarded to appropriate queues based on priority-to-queue mapping that you defined. The Catalyst 2950 switches support four CoS queues for each egress port. For each queue, you can specify these types of scheduling: • Strict priority scheduling is based on the priority of queues. Queues can have priorities from 0 to 7, 7 being the highest. Packets in the high-priority queue always transmit first, and packets in the low-priority queue do not transmit until all the high-priority queues become empty. • WRR scheduling requires you to specify a number that indicates the importance (weight) of the queue relative to the other CoS queues. WRR scheduling prevents the low-priority queues from being completely neglected during periods of high-priority traffic. The WRR scheduler transmits some packets from each queue in turn. The number of packets it transmits corresponds to the relative importance of the queue. For example, if one queue has a weight of 3 and another has a weight of 4, three packets are transmitted from the first queue for every four that are transmitted from the second queue. By using this scheduling, low-priority queues have the opportunity to transmit packets even though the high-priority queues are not empty. Before configuring QoS, you must have a thorough understanding of these items: • • • • This section describes how to configure QoS on your switch: • • Table 24-2 shows the default QoS configuration. Table 24-2 Default QoS Configuration The default port trust state is untrusted.1 No policy maps are configured.1 No policers are configured.1 No policers are configured.1 The default CoS-to-DSCP map is shown inTable 24-3.1 The default DSCP-to-CoS map is shown in Table 24-4.1 For default QoS and WRR values, see the "Configuring CoS and WRR" section. 1 Available only on a switch running the enhanced software image. Before beginning the QoS configuration, you should be aware of this information: • • • • • • • This section describes how to classify incoming traffic by using port trust states: • • Packets entering a QoS domain are classified at the edge of the QoS domain. When the packets are classified at the edge, the switch port within the QoS domain can be configured to one of the trusted states because there is no need to classify the packets at every switch within the QoS domain. Figure 24-3 shows a sample network topology. Figure 24-3 Port Trusted States within the QoS Domain Beginning in privileged EXEC mode, follow these steps to configure the port to trust the classification of the traffic that it receives: To return a port to its untrusted state, use the no mls qos trust interface configuration command. For information on how to change the default CoS value, see the "Configuring the CoS Value for an Interface" section. For information on how to configure the CoS-to-DSCP map, see the "Configuring the CoS-to-DSCP Map" section. QoS assigns the CoS value specified with mls qos cos interface configuration command to untagged frames received on trusted and untrusted ports. Beginning in privileged EXEC mode, follow these steps to define the default CoS value of a port or to assign the default CoS to all incoming packets on the port: To return to the default setting, use the no mls qos cos {default-cos | override} interface configuration command. Configuring a QoS policy typically requires classifying traffic into classes, configuring policies applied to those traffic classes, and attaching policies to interfaces. For background information, see the "Classification" section and the "Policing and Marking" section. This section contains this configuration information: • • • You can classify IP traffic by using IP standard or IP extended ACLs; you can classify Layer 2 traffic by using Layer 2 MAC ACLs. Beginning in privileged EXEC mode, follow these steps to create an IP standard ACL for IP traffic: Step 1 configure terminal Enter global configuration mode. Step 2 access-list access-list-number {deny | permit | remark} {source source-wildcard | host source | any} Create an IP standard ACL, repeating the command as many times as necessary. For access-list-number, enter the ACL number. The range is 1 to 99 and 1300 to 1999. Enter deny or permit to specify whether to deny or permit access if conditions are matched. The source is the source address of the network or host from which the packet is being sent, specified in one of three ways: • • • (Optional) The source-wildcard applies wildcard bits to the source (see first bullet item). Note Step 3 end Return to privileged EXEC mode. Step 4 show access-lists Verify your entries. Step 5 copy running-config startup-config (Optional) Save your entries in the configuration file. To delete an ACL, use the no access-list access-list-number global configuration command. This example shows how to allow access for only those hosts on the two specified networks. The wildcard bits apply to the host portions of the network addresses. Any host with a source address that does not match the ACL statements is rejected. Beginning in privileged EXEC mode, follow these steps to create an IP extended ACL for IP traffic: Step 1 configure terminal Enter global configuration mode. Step 2 access-list access-list-number Create an IP extended ACL, repeating the command as many times as necessary. For access-list-number, enter the ACL number. The range is 100 to 199 and 2000 to 2699. Enter deny or permit to specify whether to deny or permit access if conditions are matched. For protocol, enter the name or number of an IP protocol. Use the question mark (?) to see a list of available protocol keywords. For source, enter the network or host from which the packet is being sent. You specify this by using dotted decimal notation by using the any keyword as an abbreviation for source 0.0.0.0 source-wildcard 255.255.255.255, or by using the host keyword for source 0.0.0.0. For source-wildcard, enter the wildcard bits by placing ones in the bit positions that you want to ignore. You specify the wildcard by using dotted decimal notation, by using the any keyword as an abbreviation for source 0.0.0.0 source-wildcard 255.255.255.255, or by using the host keyword for source 0.0.0.0. For destination, enter the network or host to which the packet is being sent. You have the same options for specifying the destination and destination-wildcard as those described by source and source-wildcard. Define a destination or source port. • • • • • • Note Step 3 end Return to privileged EXEC mode. Step 4 show access-lists Verify your entries. Step 5 copy running-config startup-config (Optional) Save your entries in the configuration file. To delete an ACL, use the no access-list access-list-number global configuration command. This example shows how to create an ACL that permits only TCP traffic from the destination IP address 128.88.1.2 with TCP port number 25: Beginning in privileged EXEC mode, follow these steps to create a Layer 2 MAC ACL for Layer 2 traffic: Step 1 configure terminal Enter global configuration mode. Step 2 mac access-list extended name Create a Layer 2 MAC ACL by specifying the name of the list. After entering this command, the mode changes to extended MAC ACL configuration. Step 3 {deny | permit} {any | host source MAC address} {any | host destination MAC address} [ aarp | amber | appletalk | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo |vines-ip | xns-idp] Enter deny or permit to specify whether to deny or permit access if conditions are matched. For source MAC address, enter the MAC address of the host from which the packet is being sent. You specify this by using the any keyword to deny any source MAC address or by using the host keyword and the source in the hexadecimal format (H.H.H). For destination MAC address, enter the MAC address of the host to which the packet is being sent. You specify this by using the any keyword to deny any destination MAC address or by using the host keyword and the destination in the hexadecimal format (H.H.H). (Optional) You can also enter these options: aarp | amber | appletalk | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo |vines-ip | xns-idp (a non-IP protocol). Note Step 4 end Return to privileged EXEC mode. Step 5 show access-lists [number | name] Verify your entries. Step 6 copy running-config startup-config (Optional) Save your entries in the configuration file. To delete an ACL, use the no mac access-list extended access-list-name global configuration command. This example shows how to create a Layer 2 MAC ACL with a permit statement. The statement allows traffic from the host with MAC address 0001.0000.0001 to the host with MAC address 0002.0000.0001. You use the class-map global configuration command to isolate a specific traffic flow (or class) from all other traffic and to name it. The class map defines the criteria to use to match against a specific traffic flow to further classify it. Match statements can only include ACLs. The match criterion is defined with one match statement entered within the class-map configuration mode. Beginning in privileged EXEC mode, follow these steps to create a class map and to define the match criterion to classify traffic: Step 1 configure terminal Enter global configuration mode. Step 2 access-list access-list-number {deny | permit} {source source-wildcard | host source | any} or access-list access-list-number or mac access-list extended name {deny | permit} {any | host source MAC address} {any | host destination MAC address} [aarp | amber | dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo |vines-ip | xns-idp] Create an IP standard or extended ACL for IP traffic or a Layer 2 MAC ACL for non-IP traffic, repeating the command as many times as necessary. For more information, see the "Classifying Traffic by Using ACLs" section. For more information on this command, see the "Creating Named MAC Extended ACLs" section. Note Step 3 class-map class-map-name Create a class map, and enter class-map configuration mode. By default, no class maps are defined. For class-map-name, specify the name of the class map. Step 4 match {access-group acl-index | name acl-name} Define the match criterion to classify traffic. By default, no match criterion is supported. Only one match criterion per class map is supported, and only one ACL per class map is supported. For access-group acl-index | name acl-name, specify the number or name of the ACL created in Step 3. Step 5 end Return to privileged EXEC mode. Step 6 show class-map [class-map-name] Verify your entries. Step 7 copy running-config startup-config (Optional) Save your entries in the configuration file. To delete an existing class map, use the no class-map class-map-name global configuration command. To remove a match criterion, use the no match {acl-index | name acl-name} class-map configuration command. This example shows how to configure the class map called class1. The class1 has one match criterion, which is an ACL called 103. A policy map specifies which traffic class to act on. Actions can include trusting the CoS or DSCP values in the traffic class; setting a specific DSCP value in the traffic class; and specifying the traffic bandwidth limitations for each matched traffic class (policer) and the action to take when the traffic is out of profile (marking). A policy map also has these characteristics: • • You can attach only one policy map per interface in the input direction. Beginning in privileged EXEC mode, follow these steps to create a policy map: Step 1 configure terminal Enter global configuration mode. Step 2 access-list access-list-number {deny | permit} {source source-wildcard | host source | any} or access-list access-list-number or mac access-list extended name (deny | permit} {any | host source MAC address} {any | host destination MAC address} [aarp | amber | appletalk |dec-spanning | decnet-iv | diagnostic | dsm | etype-6000 | etype-8042 | lat | lavc-sca | mop-console | mop-dump | msdos | mumps | netbios | vines-echo |vines-ip | xns-idp] Create an IP standard or extended ACL for IP traffic or a Layer 2 MAC ACL for non-IP traffic, repeating the command as many times as necessary. For more information, see the "Classifying Traffic by Using ACLs" section. Note Step 3 policy-map policy-map-name Create a policy map by entering the policy map name, and enter policy-map configuration mode. By default, no policy maps are defined. The default behavior of a policy map is to set the DSCP to 0 if the packet is an IP packet and to set the CoS to 0 if the packet is tagged. No policing is performed. Step 4 class class-map-name [access-group name acl-index-or-name] Define a traffic classification, and enter policy-map class configuration mode. By default, no policy map class maps are defined. If a traffic class has already been defined by using the class-map global configuration command, specify its name for class-map-name in this command. For access-group acl-index-or-name, specify the number or name of the ACL created in Step 2. Note Step 5 set {ip dscp new-dscp} Classify IP traffic by setting a new value in the packet. For ip dscp new-dscp, enter a new DSCP value to be assigned to the classified traffic. The supported DSCP values are 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56. Step 6 police rate-bps burst-byte [exceed-action {drop | dscp dscp-value}] Define a policer for the classified traffic. You can configure up to 60 policers on ingress Gigabit-capable Ethernet ports and up to 6 policers on ingress 10/100 Ethernet ports. For rate-bps, specify average traffic rate in bits per second (bps). The range is 1 Mbps to 100 Mbps for 10/100 Ethernet ports and 8 Mbps to 1000 Mbps for the Gigabit-capable Ethernet ports. For burst-byte, specify the normal burst size in bytes. The values supported on the 10/100 ports are 4096, 8192, 16384, 32768, and 65536. The values supported on the Gigabit-capable Ethernet ports are 4096, 8192, 16348, 32768, 65536, 131072, 262144, and 524288. (Optional) Specify the action to take when the rates are exceeded. Use the exceed-action drop keywords to drop the packet. Use the exceed-action dscp dscp-value keywords to mark down the DSCP value and transmit the packet. Step 7 exit Return to policy-map configuration mode. Step 8 exit Return to global configuration mode. Step 9 interface interface-id Enter interface configuration mode, and specify the interface to attach to the policy map. Valid interfaces include physical interfaces. Step 10 service-policy {input policy-map-name} Apply a policy map to the input of a particular interface. Only one policy map per interface per direction is supported. Use input policy-map-name to apply the specified policy map to the input of an interface. Step 11 end Return to privileged EXEC mode. Step 12 show policy-map [policy-map-name class class-name] Verify your entries. Step 13 copy running-config startup-config (Optional) Save your entries in the configuration file. To delete an existing policy map, use the no policy-map policy-map-name global configuration command. To delete an existing class map, use the no class class-map-name policy-map configuration command. To remove an assigned DSCP value, use the no set {ip dscp new-dscp} policy-map configuration command. To remove an existing policer, use the no police rate-bps burst-byte [exceed-action {drop | dscp dscp-value}] policy-map configuration command. To remove the policy map and interface association, use the no service-policy {input policy-map-name} interface configuration command. This example shows how to create a policy map and attach it to an ingress interface. In the configuration, the IP standard ACL permits traffic from network 10.1.0.0. For traffic matching this classification, the DSCP value in the incoming packet is trusted. If the matched traffic exceeds an average traffic rate of 48000 bps and a normal burst size of 8000 bytes, its DSCP is marked down to a value of 10 and transmitted. This example shows how to create a Layer 2 MAC ACL with two permit statements and attach it to an ingress interface. The first permit statement allows traffic from the host with MAC address 0001.0000.0001 destined for the host with MAC address 0002.0000.0001. This section describes how to configure the DSCP maps: • • All the maps are globally defined. You use the CoS-to-DSCP map to map CoS values in incoming packets to a DSCP value that QoS uses internally to represent the priority of the traffic. Table 24-3 shows the default CoS-to-DSCP map. If these values are not appropriate for your network, you need to modify them. Beginning in privileged EXEC mode, follow these steps to modify the CoS-to-DSCP map: To return to the default map, use the no mls qos map cos-dscp global configuration command. This example shows how to modify and display the CoS-to-DSCP map: You use the DSCP-to-CoS map to map DSCP values in incoming packets to a CoS value, which is used to select one of the four egress queues. The Catalyst 2950 switches support these DSCP values: 0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56. Table 24-4 shows the default DSCP-to-CoS map. Table 24-4 Default DSCP-to-CoS Map DSCP values 0 8, 10 16, 18 24, 26 32, 34 40, 46 48 56 CoS values 0 1 2 3 4 5 6 7 If these values are not appropriate for your network, you need to modify them. Beginning in privileged EXEC mode, follow these steps to modify the DSCP-to-CoS map: To return to the default map, use the no mls qos map dscp-cos global configuration command. This example shows how the DSCP values 26 and 48 are mapped to CoS value 7. For the remaining DSCP values, the DSCP-to-CoS mapping is the default. This section describes how to configure CoS priorities and weighted round-robin (WRR): • Beginning in privileged EXEC mode, follow these steps to configure the CoS priority queues: To disable the new CoS settings and return to default settings, use the no wrr-queue cos-map global configuration command. Beginning in privileged EXEC mode, follow these steps to configure the WRR priority: To disable the WRR scheduler and enable the strict priority scheduler, use the To display the current QoS information, use one or more of the privileged EXEC commands in Table 24-5: Table 24-5 Commands for Displaying QoS Information show class-map [class-map-name]1 Display QoS class maps, which define the match criteria to classify traffic. show policy-map [policy-map-name [class class-name]]1 Display QoS policy maps, which define classification criteria for incoming traffic. show mls qos maps [cos-dscp | dscp-cos]1 Display QoS mapping information. Maps are used to generate an internal DSCP value, which represents the priority of the traffic. show mls qos interface [interface-id] [policers]1 Display QoS information at the interface level, including the configuration of the egress queues and the CoS-to-egress-queue map, which interfaces have configured policers, and ingress and egress statistics (including the number of bytes dropped).2 show mls masks [qos | security] 1 Display details regarding the masks3 used for QoS and security ACLs. show wrr-queue cos-map Display the mapping of the CoS priority queues. show wrr-queue bandwidth Display the WRR bandwidth allocation for the CoS priority queues. 1 Available only on a switch running the enhanced software image. 2 You can define up to 16 DSCP values for which byte or packet statistics are gathered by hardware by using the mls qos monitor {bytes | dscp dscp1 ... dscp8 | packets} interface configuration command and the show mls qos interface statistics privileged EXEC command. 3 Access Control Parameters are called masks in the switch CLI commands and output. This example shows how to display the DSCP-to-CoS maps: Queueing and Scheduling
How Class of Service Works
Port Priority
Port Scheduling
CoS and WRR
Strict priority scheduling Weighted round-robin (WRR) scheduling Configuring QoS
The types of applications used and the traffic patterns on your network. Traffic characteristics and needs of your network. Is the traffic bursty? Do you need to reserve bandwidth for voice and video streams? Bandwidth requirements and speed of the network. Location of congestion points in the network. Configuring Classification Using Port Trust States Displaying QoS Information, page 24-25 Default QoS Configuration
Configuration Guidelines
If you have EtherChannel ports configured on your switch, you must configure QoS classification, policing, mapping, and queueing on the individual physical ports that comprise the EtherChannel. You must decide whether the QoS configuration should match on all ports in the EtherChannel. It is not possible to match IP fragments against configured IP extended ACLs to enforce QoS. IP fragments are transmitted as best-effort. IP fragments are denoted by fields in the IP header. Control traffic (such as spanning-tree bridge protocol data units (BPDUs) and routing update packets) received by the switch are subject to all ingress QoS processing. Only one ACL per class map and only one match command per class map are supported. The ACL can have multiple access control entries, which are commands that match fields against the contents of the packet. Policy maps with ACL classification in the egress direction are not supported and cannot be attached to an interface by using the service-policy input policy-map-name interface configuration command. In a policy map, the class named class-default is not supported. The switch does not filter traffic based on the policy map defined by the class class-default policy-map configuration command. For more information on guidelines for configuring ACLs, see the "Classification Based on QoS ACLs" section. Configuring Classification Using Port Trust States
Configuring the Trust State on Ports within the QoS Domain Configuring the CoS Value for an Interface Configuring the Trust State on Ports within the QoS Domain
Configuring the CoS Value for an Interface
Configuring a QoS Policy
Classifying Traffic by Using ACLs Classifying Traffic by Using Class Maps Classifying, Policing, and Marking Traffic by Using Policy Maps Classifying Traffic by Using ACLs
The 32-bit quantity in dotted-decimal format. The keyword any as an abbreviation for source and source-wildcard of 0.0.0.0 255.255.255.255. You do not need to enter a source-wildcard. The keyword host as an abbreviation for source and source-wildcard of source 0.0.0.0. Deny statements are not supported for QoS ACLS. See the "Classification Based on QoS ACLs" section for more details. Switch(config)# access-list 1 permit 192.5.255.0 0.0.0.255
Switch(config)# access-list 1 permit 36.0.0.0 0.0.0.255
{deny | permit | remark} protocol
{source source-wildcard | host source | any}[operator port] {destination destination-wildcard | host destination | any} [operator port] The operator can be only eq (equal). If operator is after source source-wildcard, conditions match when the source port matches the defined port. If operator is after destination destination-wildcard, conditions match when the destination port matches the defined port. The port is a decimal number or name of a TCP or UDP port. The number can be from 0 to 65535. Use TCP port names only for TCP traffic. Use UDP port names only for UDP traffic. Deny statements are not supported for QoS ACLS. See the "Classification Based on QoS ACLs" section for more details. Switch(config)# access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq
25
Deny statements are not supported for QoS ACLS. See the "Classification Based on QoS ACLs" section for more details. Switch(config)# mac access-list extended maclist1
Switch(config-ext-macl)# permit host 0001.0000.0001 host 0002.0000.0001
Classifying Traffic by Using Class Maps
{deny | permit | remark} protocol
{source source-wildcard | host source | any} [operator port] {destination destination-wildcard | host destination | any} [operator port] Deny statements are not supported for QoS ACLS. See the "Classification Based on QoS ACLs" section for more details. Switch(config)# access-list 103 permit any any tcp eq 80
Switch(config)# class-map class1
Switch(config-cmap)# match access-group 103
Switch(config-cmap)# end
Switch#
Classifying, Policing, and Marking Traffic by Using Policy Maps
A policy map can contain multiple class statements, each with different match criteria and policers. A separate policy-map class can exist for each type of traffic received through an interface.
{deny | permit | remark} protocol
{source source-wildcard | host source | any}[operator port] {destination destination-wildcard | host destination | any} [operator port] Deny statements are not supported for QoS ACLS. See the "Classification Based on QoS ACLs" section for more details.
For more information on this command, see the "Creating Named MAC Extended ACLs" section. In a policy map, the class named class-default is not supported. The switch does not filter traffic based on the policy map defined by the class class-default policy-map configuration command. Switch(config)# access-list 1 permit 10.1.0.0 0.0.255.255
Switch(config)# class-map ipclass1
Switch(config-cmap)# match access-group 1
Switch(config-cmap)# exit
Switch(config)# policy-map flow1t
Switch(config-pmap)# class ipclass1
Switch(config-pmap-c)# police 5000000 8192 exceed-action dscp 10
Switch(config-pmap-c)# exit
Switch(config-pmap)# exit
Switch(config)# interface gigabitethernet0/1
Switch(config-if)# switchport mode access
Switch(config-if)# service-policy input flow1t
Switch(config)# mac access-list extended maclist1
Switch(config-ext-mac)# permit host 0001.0000.0001 host 0002.0000.0001
Switch(config-ext-mac)# exit
Switch(config)# mac access-list extended maclist2
Switch(config-ext-mac)# permit host 0001.0000.0003 host 0002.0000.0003
Switch(config-ext-mac)# exit
Switch(config)# class-map macclass1
Switch(config-cmap)# match access-group name maclist1
Switch(config-cmap)# exit
Switch(config)# policy-map macpolicy1
Switch(config-pmap)# class macclass1
Switch(config-pmap-c)# set ip dscp 56
Switch(config-pmap-c)# exit
Switch(config-pmap)# class macclass2 maclist2
Switch(config-pmap-c)# set ip dscp 48
Switch(config-pmap-c)# exit
Switch(config-pmap)# exit
Switch(config)# interface gigabitethernet0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# mls qos trust cos
Switch(config-if)# service-policy input macpolicy1
Configuring CoS Maps
Configuring the CoS-to-DSCP Map Configuring the DSCP-to-CoS Map Configuring the CoS-to-DSCP Map
Switch# configure terminal
Switch(config)#mls qos map cos-dscp 8 8 8 8 24 32 56 56
Switch(config)# end
Switch# show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 8 8 8 8 24 32 56 56
Configuring the DSCP-to-CoS Map
Switch(config)#mls qos map dscp-cos 26 48 to 7
Switch(config)#exit
Switch#show mls qos maps dscp-cos
Dscp-cos map:
dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56
-----------------------------------------------
cos: 0 1 1 2 2 3 7 4 4 5 5 7 7
Configuring CoS and WRR
CLI: Configuring CoS Priority Queues CLI: Configuring CoS Priority Queues
Configuring WRR
no wrr-queue bandwidth global configuration command. Displaying QoS Information
Switch# show mls qos maps dscp-cos
Dscp-cos map:
dscp: 0 8 10 16 18 24 26 32 34 40 46 48 56
-----------------------------------------------
cos: 0 1 1 2 2 3 3 4 4 5 5 6 7
QoS Configuration Examples
This section provides a QoS migration path to help you quickly implement QoS features based on your existing network and planned changes to your network, as shown in Figure 24-4. It contains this information:
•QoS Configuration for the Common Wiring Closet
•QoS Configuration for the Intelligent Wiring Closet
Figure 24-4 QoS Configuration Example Network
QoS Configuration for the Common Wiring Closet
The common wiring closet in Figure 24-4 consists of existing Catalyst 2900 XL and 3500 XL switches. These switches are running IOS release 12.0(5)XP or later, which supports the QoS-based IEEE 802.1P CoS values. QoS classifies frames by assigning priority-indexed CoS values to them and gives preference to higher-priority traffic.
Recall that on the Catalyst 2900 and 3500 XL switches, you can classify untagged (native) Ethernet frames at the ingress ports by setting a default CoS priority (switchport priority default default-priority-id interface configuration command) for each port. For IEEE 802.1Q frames with tag information, the priority value from the header frame is used. On the Catalyst 3524-PWR XL and 3548 XL switches, you can override this priority with the default value by using the switchport priority default override interface configuration command. For Catalyst 2950 and Catalyst 2900 XL switches and other 3500 XL models that do not have the override feature, the Catalyst 3550-12T switch at the distribution layer can override the 802.1P CoS value by using the mls qos cos override interface configuration command.
For the Catalyst 2900 and 3500 XL switches, CoS configures each transmit port (the egress port) with a normal-priority transmit queue and a high-priority transmit queue, depending on the frame tag or the port information. Frames in the normal-priority queue are forwarded only after frames in the high-priority queue are forwarded. Frames that have 802.1P CoS values of 0 to 3 are placed in the normal-priority transmit queue while frames with CoS values of 4 to 7 are placed in the expedite (high-priority) queue.
QoS Configuration for the Intelligent Wiring Closet
The intelligent wiring closet in Figure 24-4 is composed of Catalyst 2950 switches. One of the switches is connected to a video server, which has an IP address of 172.20.10.16.
The object of this example is to prioritize the video traffic over all other traffic. To do so, a DSCP of 46 is assigned to the video traffic. This traffic is stored in queue 4, which is serviced more frequently than the other queues.
Beginning in privileged EXEC mode, follow these steps to configure the switch to prioritize video packets over all other traffic:
