11.3. 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.

Table 11-4. QoS types that can use 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.

Table 11-5. Valid match commands for our MQC class-map

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.

Table 11-6. Policy-map commands

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