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

QoS type	Configuration command
Class-based marking	set
CBWFQ	bandwidth, queue-limit
LLQ	priority
Policing	police
Shaping	shape

 

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

Match command	Description
access-group	Match an access number or name.
any	Match all packets.
class-map	Match another class map. This handy feature is illustrated in the example following this table.
cos	Match IEEE 802.1Q/ISL CoS values. Up to four values can be listed in one match statement.
destination-address	Match the destination MAC address.
discard-class	Match discard class (a value from 0 to 7).
dscp	Match a specific IP differentiated service code point.
fr-dlci	Match a frame relay DLCI (data-link connection identifier).
input-interface	Match the input interface of the packet.
ip dscp	Defunctuse dscp command instead .
ip precedence	Defunctuse the precedence command listed below.
ip rtp	Match a Real Time Protocol (RTP) port range.
match not	Match everything but the listed item. For example, match not protocol ip matches all protocols except IP.
packet length	Match the packet header's Layer 3 packet length.
precedence	Match the IP precedence value.
protocol	Match the protocol name (e.g., cdp, ip, ipv6, ipx, etc.) See the Quick Reference for a complete listing. Can also use NBAR to match.
qos-group	Match a specific QoS group value.
source-address mac	Match the source MAC address.

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

Policy-map command	QoS type	Traffic direction	Description
bandwidth	CBWFQ	Output	Assigns a slice of the bandwidth in kilobits per second or as a percentage.
queue-limit	CBWFQ	N/A	Defines a queue size (in packets), which is the number of packets that can be queued before packets are dropped.
random-detect	WRED	Output	Enables Weighted Random Early Detection (WRED) instead of tail-drop for dropping packets.
shape	Shaping	Output	Enables traffic shaping.
police	Policy	Input/Output	Defines a committed access rate.
priority	LLQ	Output	Enables low-latency queuing.
set	Marking	Input/Output	Enables class-based packet marking.

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