QoS Configuration and Verification

This section covers the configuration of some of the QoS methods mentioned earlier in this chapter. It's important to point out that the configuration and verification coverage in this section covers only the basics there is much more to QoS configuration than what is in this book.

Modular QoS CLI

Modular QoS CLI (MQC) is the term Cisco uses to define the implementation of QoS on an IOS device. MQC is used to create your QoS traffic policies and then to associate these policies to the device's interface(s). Each traffic policy you create has two components: a traffic class that classifies (or groups) traffic, and a traffic policy that defines how the traffic should be processed.

Creating Classes

When dealing with MQC, one of the first things you do is define what traffic is to be grouped together within a class. Here are the commands you'll use:

 Switch(config)# class-map class_map_name [match-all|match-any] Switch(config-cmap)# match access-group ACL_#|name ACL_name Switch(config-cmap)# match input-interface interface_name Switch(config-cmap)# match protocol protocol_name

The class-map command associates a grouping of match commands that group specified traffic together into a single class. The match-all parameter says that for traffic to be included, the traffic must match on all match statements in the class. The match-any parameter says that traffic has to match against only one match statement to be included in the class.

I've listed three common match commands in the preceding code listing. Please note that there are many parameters that you can match on with the match command that I haven't included (such as cos, ip precedence, and dscp, to name a few). The match access-group command enables you to specify the number or name of an ACL, including traffic that matches permit statements in the ACL. The match input-interface command specifies the name and number of the interface that traffic is received on; any traffic received on this interface is included in the class. The match protocol specifies a particular protocol to include in the class.

Actually, NBAR extends the match protocol command. NBAR works with QoS features to ensure that traffic receives a guaranteed amount of bandwidth, doesn't exceed bandwidth limits by shaping it, and marks packets with the appropriate QoS information. New classifications with NBAR include the following, which provide a lot of additional grouping flexibility:

Classifying applications that use dynamic TCP or UDP port numbers
Classifying Citrix ICA traffic
Classifying application traffic that uses subport information
Classifying HTTP traffic by URL, host, or MIME type

Creating Policies

The second thing you do when configuring MQC is to define your traffic policies. This is done with the policy-map command:

 Switch(config)# policy-map policy_map_name Switch(config-pmap)# class class_map_name Switch(config-pmap-c) bandwidth Kbps_value Switch(config-pmap-c) queue-limit #_of_packets

The policy-map command creates your policies. The class command within the policy configuration specifies the name of the class of traffic that should be processed by this policy (created with the class-map command). This takes you into a subconfiguration mode in which you can limit the amount of bandwidth (bandwidth) and the number of packets in the queue (queue-limit) for the class. You can include multiple classes in the same policy map. Please note that there are additional policy commands that you can use for your included classes. Listing 9.1 shows a simple example.

Listing 9.1 A Policy Map Example

 Switch(config)# access-list 1 permit 192.168.1.0 0.0.0.255 Switch(config)# class-map map-one match-all Switch(config-cmap)# match access-group 1 Switch(config-cmap)# exit Switch(config)# policy-map policy-one Switch(config-pmap)# class map-one Switch(config-pmap-c)# bandwidth 1000 Switch(config-pmap-c)# queue-limit 150

In this example, any traffic from 192.168.1.0 is associated with a map class called map-one. That class is then associated with a policy, called policy-one, that restricts the traffic to 1Mbps and a queue limit of 150 packets.

Classification and marking are used to mark packets and/or frames with QoS prioritization information. At Layer 2, CoS information is included. With IP, the TOS field is either marked using IP precedence or DSCP. This process is sometimes referred to as coloring. Listing 9.2 shows the configuration performed within your policy map.

Listing 9.2 Policy Map Configuration

 Switch(config)# policy-map policy_map_name Switch(config-pmap)# class class_map_name Switch(config-pmap-c) set cos cos_value Switch(config-pmap-c) set ip precedence precedence_value Switch(config-pmap-c) set dscp DSCP_value

If you don't use the set commands, no traffic is marked as it exits an interface. Listing 9.3 shows a simple example.

Listing 9.3 A Coloring Example

 Switch(config)# access-list 2 permit 192.168.2.0 0.0.0.255 Switch(config)# class-map map-two match-all Switch(config-cmap)# match access-group 2 Switch(config-cmap)# exit Switch(config)# policy-map policy-two Switch(config-pmap)# set cos 1

In this example, any traffic from 192.168.2.0 is associated with a map class called map-two. That class is then associated with a policy, called policy-two, that marks this traffic with a COS value of 1.

Activating Policies

After you've created your classes and associated them with a policy map, you need to activate your policy map on an interface:

 Switch(config)# interface type slot_#/port_# Switch(config-if)# service-policy input|output policy_map_name

After you enter an interface, use the service-policy command to activate the name of the policy map created with the policy-map command. Note that you can specify the direction of the policy on the interface: inbound (input) or outbound (output).

To activate the two policies created in the last section, use this configuration:

 Switch(config)# interface fastethernet0/1 Switch(config-if)# service-policy input policy-one Switch(config-if)# service-policy input policy-two

By default, QoS is disabled on your switch. You can enable it with the following command:

 Switch(config)# mls qos

When enabled, the default is to not trust any classifications or markings (CoS and DSCP) in frames or packets. You can enable the trust option with the following configuration:

 Switch(config)# interface type slot_#/port_# Switch(config-if)# mls qos trust [dscp|cos]

If you don't specify any parameters, both DSCP and CoS parameters are examined. Please note that there are match commands within a class-map configuration that enable you to match on this kind of traffic.

Given our previous configuration examples, here's how you would enable QoS:

 Switch(config)# mls qos

Notice that because I didn't execute the mls qos trust command on fastethernet0/1, any QoS markings coming into this interface will be ignored and the policy and class maps I created earlier will be used instead.

Classification of traffic is done with the class-map commands. The policy-map commands associate your QoS parameters to your traffic classes. The service-policy command activates your QoS policies on an interface. To enable QoS, use the mls qos command.

Verifying the Configuration

When you've configured your classes and policies and activated your policies on your switch's interfaces, you can use various show commands to examine your configuration and operation. The show class-map command displays all class maps that you've created:

 Switch# show class-map  Class Map match-any class1   Match access-group 101  Class Map match-all class2   Match protocol ip   Match input-interface Ethernet1/1

In this example, there are two map classes: class1 and class2. class1 includes all traffic specified by permit statements in ACL 101. class2 specifies that all IP traffic coming into Etherent1/1 is included.

The show policy-map command displays all the policy maps that you've created:

 Switch# show policy-map Policy Map policy1 Weighted Fair Queueing Class class1 Bandwidth 64 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 64 (kbps) Max thresh 64 (packets)

In this example, there is one policy map, policy1, on the switch. It uses WFQ for queuing and contains two classes. Each class is allowed 64Kbps of bandwidth and each is allowed to queue up 64 packets. To see whether a policy map has been activated on an interface, use the show policy-map interface command:

 Switch# show policy-map interface Ethernet1/1  Ethernet1/1   Service-policy output: policy1    Class-map: class1 (match any)     0 packets, 0 bytes     5 minute rate 5ps     Match: access-group 101 <--output omitted-->

Queuing Methods

This section covers the configuration of six different queuing methods: WFQ, PQ, CQ, IP RTP-PQ, LLQ, and WRRB. Please note that the configuration discussed here provides only the very basic information to set up these queuing methods.

Configuring WFQ

WFQ is the default queuing method on serial interfaces. WFQ breaks traffic streams into conversations of two types: low volume (such as telnets) and high volume (such as file transfers). It gives preference to the low volume over high volume. But within a conversation type, such as two file transfers, WFQ uses a round-robin and treats the streams equally. WFQ dispatches information based on conversations.

WFQ is the default queuing method on routers with a serial interface at E1 (2.048Mbps) speeds or less. You don't need to do anything to enable it, but you can change the threshold at which WFQ begins dropping packets.

The default congestive discard threshold for WFQ is 64 packets. This threshold is used to queue packets for a conversation. A conversation is essentially a single connection. If a conversation reaches this limit, the conversation's newly arriving packets are dropped. This threshold ensures that one conversation doesn't hog all the buffer space. The configuration to change this threshold is as follows:

 Router(config)# interface type slot_#/port_# Router(config-if)# priority-group packet_threshold

The packet threshold can be from 1 512, where 64 is the default.

 Router(config)# interface serial0 Router(config-if)# priority-group 75

In this example, the router's WFQ congestive discard threshold is set to 75 packets for serial0.

To verify queuing on your interfaces, you can either use show interfaces or show queueuing fair commands. Notice that queueing is misspelled this is correct.

WFQ is the default queueing method on serial interfaces of routers with speeds of E1 or less. WFQ works by breaking up traffic into high and low priority conversations. The default congestive discard threshold is 64.

Configuring PQ

To prioritize your traffic for PQ, use priority-list commands:

 Router(config)# priority-list list_# protocol name of protocol                      high|medium|normal|low additional_parameters Router(config)# priority-list list_# interface interface_name

The first command specifies, by protocol, what information is placed into what queue: high, medium, normal, and low (remember that PQ has only four queues). For additional parameters, you can specify TCP or UDP as well as the port number, or you can specify an ACL.

The second command specifies that traffic for the specified interface should be placed into the denoted queue. The commands are processed top-down by the IOS which places the traffic in the appropriate queue. You can create up to 16 lists in 11.x and later. Traffic not specified for a certain queue is placed into the normal priority queue.

The default size of the different queues for PQ, in packets, is as follows: high queue (20 packets), medium queue (40 packets), normal queue (60 packets), and low queue (80 packets). You can change this with the following command:

 Router(config)# priority-list list # queue-limit high_queue_packets              medium_queue_packets normal_queue_packets low_queue_packets

Here's an example of changing the sizes:

 Router(config)# priority-list 7 queue-limit 20 40 120 80

In this example, we've doubled the size of the normal queue.

When you've created your priority list, you need to activate it on one (or more) of your interfaces:

 Router(config)# interface type slot_#/port_# Router(config-if)# priority-group list_#

After you do this, the router no longer uses WFQ on the interface, but uses PQ instead.

Here is a simple example of a PQ configuration:

 Router(config)# priority-list 1 protocol appletalk high Router(config)# priority-list 1 protocol ip normal Router(config)# interface serial0 Router(config-if)# priority-group 1

In this example, a priority list was created placing AppleTalk traffic in the high queue and IP traffic in the normal queue. The list was then activated on the router's serial interface.

To verify queuing on your interfaces, you can use either show interfaces or show queueuing priority.

PQ has four queues: high, medium, normal, and low. The high queue is guaranteed to be serviced. Use the priority-list commands to specify what traffic goes into what queue and activate the PQ list with the priority-group command.

Configuring CQ

To prioritize your traffic for CQ, use queue-list commands:

 Router(config)# queue-list list_# protocol name_of_protocol                         Queue_# additional_parameters Router(config)# queue-list list_# interface interface_name

The first command specifies, by protocol, what information is placed into what queue. The second command does this on an interface-by-interface basis. Please note that these commands are similar to the configuration of PQ.

Here's an example that places AppleTalk traffic in queue 1 and IP traffic in queue 2:

 Router(config)# queue-list 1 protocol appletalk 1 Router(config)# queue-list 1 protocol ip 2

The commands are processed top-down by the router, which places the traffic in the appropriate queue. You can create up to 16 lists in CQ. Unlike PQ, there is no default queue in CQ. Traffic that is not specified for a certain queue is dropped. However, you can create a default queue. To change the default queue, use the following command:

 Router(config)# queue-list list_# default queue_#

Given our previous example, all other traffic will be placed in queue 3:

 Router(config)# queue-list 1 default 3

The default number of packets that a CQ queue can hold is 20. If you're dropping packets, you want to increase that number with the following command:

 Router(config)# queue-list list # queue queue # limit #_of_packets

For our previous example, let's increase the size of the queue IP traffic is held in, doubling its size:

 Router(config)# queue-list 1 queue 2 limit 40

CQ processes queues in a round-robin fashion. When CQ is processing a queue, it processes at least the number of bytes specified by the byte-count threshold, assuming that there is enough traffic in the queue. It does not fragment packets, but instead discards the whole packet. As an example, if the threshold is 500 bytes and the packet in the queue is 600 bytes, CQ forwards the entire packet. The default threshold is 1500 bytes. You can change this with the following command:

 Router(config)# queue-list list_# queue queue_# byte-count #_of_bytes

Given our previous example, let's double the threshold for AppleTalk traffic, giving it preference over IP traffic:

 Router(config)# queue-list 1 queue 1 byte-count 1500

Note that this is the command in which you can give larger or smaller amounts of bandwidth to specific traffic types it's not traffic shaping, but it comes somewhat close to it.

After you've created your queue list for CQ, you need to activate it on one (or more) of your interfaces:

 Router(config)# interface type slot_#/port_# Router(config-if)# custom-queue-list list_#

After you do this, the router no longer uses WFQ on the interface, but uses CQ instead.

To complete our previous example of CQ list 1, here's how to activate it on serial0:

 Router(config)# interface serial0 Router(config-if)# custom-queue-list 1

To verify queuing on your interfaces, you can use either show interfaces or show queueuing custom commands.

CQ has 16 queues that are processed in a round-robin fashion. Use the queue-list command to configure CQ. You can give preference to a queue by specifying the amount of traffic a queue can process with the byte-count parameter. Use the custom-queue-list command to active CQ.

Configuring IP RTP-PQ

RTP handles real-time data streams, such as voice and video. RTP-PQ is a combination of PQ and WFQ methods to handle the prioritization of RTP traffic in a mixed-traffic network. RTP packet streams are given a strict priority over other types of packets. When the IOS processes the RTP-PQ queue, all traffic in the RTP, or priority queue, is processed first. All other traffic is processed using WFQ or CBWFQ, depending on what you have enabled on the interface these are the only other two queuing methods supported with RTP-PQ. One nice feature of RTP-PQ is that this process does not occur on the interface until the interface experiences congestion.

To configure RTP-PQ, use the following configuration:

 Switch(config)# interface type slot_#/port_# Switch(config-if)# ip rtp priority starting_port_# total_#_of_ports    bandwidth Switch(config-if)# max-reserved-bandwidth percentage

The ip rtp priority command specifies the starting port number of the RTP application(s) and the total number of ports, beginning with the starting port number, that should be included in the prioritization. This is followed by the amount of total bandwidth, in Kbps, that is reserved for this RTP traffic on the interface.

The total amount of bandwidth available to RTP-PQ, LLQ, and other types of queuing cannot exceed 75% of the total bandwidth of the interface, by default. This takes into account overhead such as the headers of IP, RTP, and UDP. However, it doesn't take into account the Layer 2 overhead. Therefore, if you're trying to squeeze as much bandwidth as possible from a link, and you realize that you can get another 5% out of the link (perhaps through compression or some other means), you can change the maximum percentage with the max-reserved-bandwidth command. However, care must be taken when changing this value: If you set it too high, you might be starving other types of traffic, including control traffic.

Here's a simple example of prioritizing traffic for RealNetworks' RealPlayer product:

 Switch(config)# interface vlan 3 Switch(config-if)# ip rtp priority 6970 200 10000

In this example, RTP traffic (ports 6,970 to 7,170) for interface VLAN 3 is reserved 10Mbps of bandwidth (10,000Kbps) if it needs it.

After you've configured RTP-PQ, you can examine the queuing configuration on your interface with the show queue command.

Configuring LLQ

Configuring LLQ is fairly simple: Its configuration is done within a priority map, which was explained earlier. Here's the configuration for LLQ:

 Switch(config)# policy-map policy_map_name Switch(config-pmap)# class class_map_name Switch(config-pmap-c) priority BW_Kbps|percent percentage [bust_value]

As you can see from this example, LLQ configuration is done with the priority command within the class configuration in the policy map. You have two options for configuring the priority: maximum amount of bandwidth allocated to the prioritized information, or a percentage of the total interface bandwidth. You can optionally specify a burst value, which allows the prioritized traffic to burst up to this level temporarily. If you don't specify a burst value, it defaults to one of the two configured values.

One interesting thing about this bandwidth allocation is that it applies only during times of congestion. During congestion, traffic is processed up to the configured level, and then temporarily up to the burst level. Traffic above these levels is dropped. However, if no congestion is occurring on the interface, the prioritized traffic can exceed the configured parameters.

The priority command serves a similar function compared to the bandwidth command. However, the bandwidth class command doesn't prioritize one type of traffic over another. Within the class configuration, you can use either the priority or bandwidth command, but not both. However, multiple classes can use the priority command. In this situation, all the classes with a configured priority are associated with the high priority queue in other words, you can't give different levels of priority to different classes of traffic. Listing 9.4 shows a simple example.

Listing 9.4 Using the priority Command

 Switch(config)# access-list 3 permit 192.168.3.0 0.0.0.255 Switch(config)# class-map map-three match-all Switch(config-cmap)# match access-group 3 Switch(config-cmap)# exit Switch(config)# policy-map policy-three Switch(config-pmap)# class map-three Switch(config-pmap-c)# priority 10000

In this example, any traffic from 192.168.3.0 is associated with a map class called map-three. That class is then associated with a policy, called policy-three, that gives this traffic 10Mbps of bandwidth over other types of traffic that might be associated with policy map policy-three.

Use the priority command to enable a priority queue with LLQ.

Table 9.5 lists three show commands that you can use to verify your LLQ configuration and operation.

Table 9.5. 802.1P CoS Priorities
Command	Explanation
show queue	Displays the queuing configuration and statistics for queuing on the specified interface
show policy interface	Displays the class configurations for policy queuing on the specified interface
show policy-map	Displays the configuration of all classes in your policy maps

Configuring WRRQ

WRRQ is the default queuing method used on Layer 3 Catalyst switches. To use WRRQ, you must first enable QoS; by default, QoS is disabled on your switch. Globally enable QoS with the mls qos command:

 Switch(config)# mls qos

When WRRQ is enabled, you're ready to configure it. Listing 9.5 shows WRRQ's configuration done at the interface level.

Listing 9.5 Configuring WRRQ

 Switch(config)# interface type slot_#/port_# Switch(config-if)# wrr-queue random-detect max-threshold queue_#                         threshold-percentage1 threshold-percentage2 Switch(config-if)# wwr-queue cos-map                         queue_# COS_value1 COS_value2...COS_value_8 Switch(config-if) priority-queue out Switch(config-if)# wrr-queue bandwidth queue_1_weight                         queue_2_weight queue_3_weight queue_4_weight Switch(config-if)# wrr-queue queue-limit weight1 weight2 weight3 weight4

The wrr-queue random-detect max-threshold command enables WRRQ on the switch's interface. You can specify a threshold value for each queue. There are two threshold values: 1 and 2. Value 1 must be less than value 2. Any time queue space is filled between the percentages of value 1 and value 2, tail dropping occurs. For example, if you have 50 and 100 as threshold values for queue 2, WRRQ starts dropping traffic for queue 2 when the queue is filled between 50 100% capacity. You typically want to leave the second threshold at 100%. The default thresholds are listed in Table 9.6.

Table 9.6. WRRQ Thresholds
Queue Number	Minimum Threshold	Maximum Threshold
1	50	100
2	70	100
3	50	100
4	70	100

The wrr-queue cos-map command assigns a COS to one of the four queues used by WWRQ. Queue numbers can range from 1 4. By default, queue 4 is the expedite (high priority queue) and COS 6 7 are assigned to it. COS 4 5 are assigned to queue 3, COS 2 3 are assigned to queue 2, and COS 0 1 are assigned to queue 1.

Please note that you do not have to use all four queues. By default, the expedite queue is disabled. You can enable it with the priority-queue out command.

The wrr-queue bandwidth command enables you to change the weights of the four queues. The weights are used to determine the ratio of the frequency of how often each queues is serviced. By default, each weight is set to 25, meaning that each queue gets 1/4 of the bandwidth. The exception to this is when the expedite queue is enabled. In that case, the expedite queue is always emptied before the other three queues are processed.

The wrr-queue queue-limit command specifies the amount of buffer space assigned to each of the four queues. The weight value specifies the ratio of queue space assigned to the queue when compared to all four weights. The weight value is between 1 100. By default, all four queues have a weight of 25, which means that each queue gets 25% of the queue space. Listing 9.6 shows a simple example.

Listing 9.6 Assigning Buffer Space

 Switch(config)# mls qos Switch(config)# interface gigabit0/1 Switch(config-if)# wrr-queue cos-map 1 6 7 Switch(config-if)# wrr-queue cos-map 2 4 5 Switch(config-if)# wrr-queue cos-map 3 2 3 Switch(config-if)# wrr-queue cos-map 4 0 1

In this example, queue 1 is has COS 6 and 7 traffic placed in it; queue 2 has COS 4 and 5; queue 3 has COS 2 and 3; and queue 4 has COS 0 and 1.

Use the show mls qos interface command to view your WRRQ configuration and operation.

Congestion Avoidance Methods: WRED

The IOS can use WRED to implement congestion avoidance. WRED uses both RED and IP precedence to prioritize traffic and discard low priority traffic when congestion begins. WRED is different from queueing in that WRED attempts to determine when congestion begins and then begins dropping low priority traffic.

The configuration of WRED is done on the switch's interface:

 Switch(config)# interface type slot_#/port_# Switch(config-if)# random-detect [dscp-based|prec-based] Switch(config-if)# random-detect dscp dscp_value min_threshold max_threshold

By default, WRED is disabled on the switch's interfaces. It is enabled with the random-detect command. Without any parameters, the random-detect command enables WRED and causes it to use the IP precedence value when performing congestion avoidance (this is the optional prec-based parameter). You can optionally override this and have WRED use the DSCP value when performing congestion avoidance by specifying the dscp-based parameter.

The random-detect dscp command specifies the congestion avoidance behavior based on the type of traffic. The DSCP value specifies the type of traffic and can be specified by either a number (0 63) or a name (af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2, cs3, cs4, cs5, or cs7). The minimum threshold value for the specified DSCP traffic denotes when WRED will begin randomly dropping packets. When the average queue length reaches this threshold, WRED begins to drop packets. When the average queue length reaches the maximum threshold, WRED drops all packets (of the DSCP type) that exceed the threshold.

Here's a simple example:

 Switch(config)# interface vlan 3 Switch(config-if)# random-detect prec-based

In this example, WRED is enabled on interface VLAN 3 and uses the IP precedence value when performing congestion avoidance.

Use the show queueing interface command to verify your WRED configuration.

debug Commands

There are many debug commands that you can use to troubleshoot your QoS configuration and operation. However, I'm only mentioning two of the more important ones. The debug ip rsvp command debugs RSVP QoS. You must be very careful with this command because it can be very resource-intensive. The debug priority command displays information about priority queuing. It displays priority queuing operations, in a real-time fashion, including what traffic is placed in what queue and when that traffic gets serviced.

There are many, many other commands that you can use to troubleshoot QoS, but these commands are beyond the scope of this book. See the "Need to Know More?" section at the end of this chapter for a reference to Cisco's site on debug commands.

Use the debug priority command to troubleshoot in PQ.