Modern IOS QoS Tools

Cisco has made QoS a great deal more flexible and useful by introducing a few new IOS features: Modular QoS CLI (MQC), Class-Based Weighted Fair Queuing (CBWFQ), and Network-Based Application Recognition (NBAR ).

First, we'll look at what NBAR can do for us. NBAR helps us identify types of traffic, which is useful for deciding which QoS type to apply to different traffic types.

11.3.1. Network-Based Application Recognition (NBAR)

NBAR stands for Network Based Application Recognition. In a nutshell, so to speak, NBAR allows you to identify packets by application (OSI layers 4 through 7). This can be used to identify traffic for classification in our QoS policies.

NBAR helps us classify traffic using sophisticated methods. Not only can it match an application's usual network ports, but NBAR can use regular expressions to match characteristics like HTTP URLs.

Table 11-4 shows configuration commands that accept NBAR.

11.3.1.1. NBAR in action

Suppose for a moment that a new virus has just been detected on the Internet. We know that it infects a machine when the browser downloads a file called reallybadworm.exe. While we are waiting for our favorite vendor to release a patch, we could do something useful, such as block the URL right on our router by using NBAR. To do so, we can create a class map that looks for that specific file:

class-map match-any virusblocker match protocol http url "*reallybadworm.exe*"

Later, we'll see how we can configure MQC to discard incoming packets that match our "virusblocker" class.

For a more detailed example, see how people were (and still are?) blocking the CodeRed worm:

11.3.1.2. NBAR protocol discovery

With the command ip nbar protocol-discovery, we can enable NBAR protocol discovery on an interface. This command tells the router to keep application-level statistics for the interface. NBAR uses its database of known applications to classify the traffic.

Here we enable NBAR protocol discovery on interface serial0:

interface serial0 ip nbar protocol-discovery

Once enabled, you can view the gathered application statistics with the command show ip nbar protocol-discovery. With the output of this command, you can see what applications are flowing across your network and adjust your QoS policies accordingly.

Router# show ip nbar protocol-discovery interface serial0 Serial0 Input Output Protocol Packet Count Packet Count Byte Count Byte Count 5 minute bit rate (bps) 5 minute bit rate (bps) ------------------------ ------------------------ ----------------------- eigrp 114302 0 13861488 0 1200 0 ntp 41437 44367 1101231 119213 1000 0

11.3.2. Modular QoS CLI (MQC)

Modular QoS CLI (MQC) makes QoS much easier to configure. Basically, we configure QoS in three steps that define which packets we are going to match and classify, what we will do with them, and where we will implement this QoS policy. In a bit more detail, the three steps look like this:

1. Create the class maps, which define which packets we are going to match.
2. Define our QoS policy, which is what are we going to do.
3. Apply the QoS policy to an interface, which is where we are going to handle the QoS

11.3.2.1. Step One: Defining the class maps

The first part of the configuring QoS with MQC is telling the router or switch which packets we are going to classify for our QoS policy. To do this, we use the command class-map, which basically acts as a matching access-list. In other words, if a packet matches the criteria in the class-map, we are going to classify that packet.

Options to the class-map command are match-any and match-all. match-any means that if any of the criteria in the class-map is matched, the packet is marked, sort of like a binary OR. If match-all is used, all the criteria in the class map must be met before the packet is marked, which is like a binary AND. match-all is the default if no option is specified.

In this example, we are going to call our class-maps "premium," "mid-grade," and "low-grade," reflecting the level of service the packets will receive. For the premium service, either of the statements must match (match-any). For the mid-grade service, all of the statements in the class map must match. And finally, for the low-level service, only one statement must match.

class-map match-any premium match protocol ipsec match access-group 101 ! class-map match-all mid-grade match access-group 102 match access-group 103 ! class-map low-level match access-group 104

In this example, you see two different types of match statements: protocol and access-group. There are many more options. Table 11-5 lists the available matching options and provides a brief description. Consult the Quick Reference (Chapter 17) for more information on each of these options.

This example uses more of the matching features for two new class maps. Notice that the class map 2 uses the class-map command, which actually nests class map 1 inside it. This feature (match class-map) makes configuring maps much easier because we can break our maps into smaller chunks, which can be nested as necessary.

! class-map match-any map1 match protocol ip match access-group 101 ! class-map match-all map2 match class-map map1 match fr-dlci 500 match destination-address mac 00:00:00:00:AE:01

11.3.2.2. Step Two: Defining the QoS policy

Now that we have defined our class maps, we need to apply a policy to each of our classes: premium, mid-grade, low-level. This policy specifies what we are going to do with the packets we classified in step one.

To start, we use the policy-map command, which puts us into the pmap (policy map) configuration mode. From this mode, we can define the policies for each of our classes:

policy-map policy1 class premium bandwidth 5000

In this example, we set the bandwidth for the premium class, which determines how the queue is handled. In this case, the queue is handled in a way that ensures that the class receives its designated share of the bandwidth. We'll revisit this in the next section.

Table 11-6 lists all the policy map commands . For now, we are going use only the bandwidth command in our examples. The rest of this chapter touches on the other commands in the appropriate sections.

We can now finish our configuration for step two, which defines the bandwidth for each of our grades of services. Notice that the class-default command defines a policy setting for any traffic that doesn't match one of our class criteria.

policy-map policy1 class premium bandwidth 5000 class mid-grade bandwidth 2000 class low-grade bandwidth 500 class class-default bandwidth 200

Now that we have configured our policies, we need to apply them, which takes us to step three.

11.3.2.3. Step 3: Defining where to apply the service policy

This step, which defines where we are going to define our policy, is the easiest to configure. All we have to do is apply our service policy to an interface. The service-policy command applies our class-based QoS policy directly to an interface:

interface ethernet0 ! apply our policy-map policy1 to the outbound traffic service-policy output policy1

11.3.3. Implementing Class-Based Weighted Fair Queuing with MQC

Class-Based Weighted Fair Queuing (CBWFQ ) extends WFQ by allowing the user to define traffic classes based on various matching criteria and apply different WFQ settings to each class of traffic, which provides significant scalability. The older method of WFQ applied to the entire interface, so you could apply only one type of QoS. On the other hand, CBWFQ is more flexible, can run on higher speed interfaces, and allows more than one type of QoS, such as WRED, which prevents network congestion. Without CBWFQ, you'd be able to run WFQ or WRED on an interface but not both. To enable CBWFQ, we use the bandwidth and queue-length policy commands.

In our previous example, we defined several classes that related to a different level of service for our packets. In the policy definitions, we assigned a bandwidth to each of these classes. Essentially, the bandwidth is the guaranteed bandwidth for the class in times of network congestion.

Another option to CBFWQ is the queue-limit command, which allows you to change the queue sizes. Bigger queues mean fewer tail drops, but they require more memory utilization and potentially greater queuing delays.

Usually, the default queue size is 64 packets (it may be higher depending on the hardware typefor example, 2,600, 3,600, or 7,200 packetsbut we can change this value and allot a much larger queue size for certain classes:

! Define our class of traffic class-map match-any class1 match protocol ipsec match access-group 101 ! ! Create our policy map policy-map qos1 class class1 bandwidth 10000 queue-limit 500 class class-default ! Set WFQ for our default class fair-queue fair-queue queue-limit 200 ! ! Apply our policy map to the interface interface ATM2/0/0.110 point-to-point service-policy output qos1

11.3.4. Low-Latency Queuing (LLQ)

Low-latency queuing (LLQ) was first called "PQCBWFQ," which is quite a mouthful but describes exactly what LLQ is; CBWFQ with a priority queue (PQ). Basically, LLQ creates a separate queue (the low-latency queue) that has priority over all other queues.

This exhaustive, priority queue is given the maximum share of the bandwidth that it can use. By doing this, a certain amount of bandwidth is reserved for the lower-priority queues so they aren't starved by the higher-priority queues. For this reason, LLQ has all the advantages of regular priority queuing for low latency and limiting jitter in real-time applications (such as VoIP) but doesn't have the same problems that priority queuing does. (Priority queuing was covered earlier in this chapter in "Older Queuing Methods.") And its major flaw is that on highly congested networks, the demanding applications will starve the less-demanding and well-behaved network traffic. LLQ works in much the same way except that it provides a certain amount of bandwidth to our priority queue instead of allowing the priority queue to hog all the bandwidth. The major use of LLQ is for VoIP traffic.

To configure LLQ, we use the priority command described in Table 11-6. The priority command takes a bandwidth value either in kbps or as a percentage.

! demonstrates the bandwidth in kbps policy-map voiceservice class voice priority 240 ! ! demostrates the bandwidth in percentages policy-map voiceservice2 class voice2 priority percentage 20