Basic QoS

January 17th, 2008 neteng

One topic I haven’t covered much is QoS. It’s something that I struggled with when first studying for the CCIE as there are a lot of different aspects to it. Thankfully, you won’t need to use some of the legacy stuff in today’s network. With that in mind, I’d like to cover some basics of modern implementations with this article, of course providing an example through Cisco IOS.

Now, I’m sure my audience knows better, but a lot of folks out there have great misconceptions as to what QoS actually does in the network. Firstly, QoS isn’t a tangible thing itself but is really a set of mechanisms that work together to manipulate traffic behavior. It’s composed of various functions such as congestion management (queuing), congestion avoidance (packet-drop behavior within a queue), traffic shaping (maintaining an average transfer rate using queuing), and traffic policing (maintaining an average transfer rate by dropping or remarking certain traffic).

Secondly, to many people’s dismay, QoS does not magically increase application speed and suddenly make T1 users think they’re running over an OC-48. QoS functions don’t really start to kick in until certain thresholds are met. For myself, I see two main reasons to implement QoS in the network (there are always exceptions):

• Audio/Video streaming - When it comes to applications that are absolutely intolerant of any sort of jitter, delay or packet loss, video and audio streaming take the cake. These typically run over a connectionless protocol such as UDP, therefore bypassing the overhead required for a smarter protocol like TCP. A single late or dropped streaming media packet can greatly affect and annoy users. When you have this type of traffic on your network, QoS is essential so that typical data traffic does not impede performance. You always want to give this type of media traffic priority in your network.
• Temporary solution - If your network is saturated, that means that you must either increase your bandwidth or reduce your traffic. It’s typical to do the first and not the second. There’s really no substitution for a bigger pipe. You can only prioritize and compartmentalize so much before your QoS policy starts to look ridiculously long and becomes self-defeating.

Occasionally, you’ll see some legacy QoS methods implemented throughout a network (priority queueing, custom queueing, etc.). I’d like to delve into the Class-Based Weighted Fair Queuing (CBWFQ), and Low Latency Queueing (LLQ) that you’ll see implemented in most networks today. For clarification, LLQ is just CBWFQ, but with a priority queue added in the mix. This queue will always be serviced before others, and that is why you will typically see it in use on unified networks (a fancy-schmancy name for a network containing data and multimedia traffic).

Topic

CBWFQ & LLQ

Definition

The are 3 keys to implementing CBWFQ/LLQ:

1. Classify traffic that you would like to match.
2. Create a policy that tells the router what to do with the traffic you’ve classified.
3. Apply this QoS policy to an interface.

This traffic you want to match is put into a class-map. There are a variety of ways to match traffic. You can do it based on QoS markings such as DSCP, IP Precedence and CoS. You can match based on Layer 3 addressing and Layer 4 port information. You can match by protocol type. The list goes on. I recommend checking out the references at the end of this article for further details. Something to remember is that all traffic not matched by a class-map is put into a default class, labeled class-default.

Once you’ve created your class-map, you need to define what you want to do with that traffic. Typically, you will assign this traffic a certain amount of bandwidth (based on actual numbers or percentages) or assign the traffic to a priority queue. This is done through a policy-map.

After you’ve classified your traffic and applied it to a policy-map, it’s time to determine which interface you want this QoS policy to take place on. It’s importat to realize that you can only apply CBWFQ to outbound traffic. If you think about it, for the most part, inbound traffic can’t be controlled by the router (unless you’re using some end-to-end QoS solution like RSVP). It has a much greater ability to affect outgoing traffic.

Example

Here’s a simple network:

Let’s say that we’ve come up with the following QoS policy:

• Voice traffic is to be guaranteed priority service and at least 40% of the outgoing bandwidth.
• HTTP traffic to “blog.humanmodem.com” is to be guaranteed 50% of the outgoing bandwidth (Hey, this is my fake policy. I can do what I want! ).
• The rest of the traffic is guaranteed the last 10% of available outgoing bandwidth.

After getting our policy down in plain English, it’s time to translate that to IOS-speak. We’ll being by defining the classes:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#class-map VOIP
R1(config-cmap)#match dscp ef
R1(config-cmap)#exit
R1(config)#class-map HTTP
R1(config-cmap)#match protocol http url “*blog.humanmodem.com*”
R1(config-cmap)#exit
R1(config)#class class-default
R1(config-pmap-c)#fair-queue
R1(config-cmap)#exit

There are a few things I want to highlight here before we move on. First, you’ll see that in our VOIP class, we are matching DSCP EF. This DSCP value is based on widely-used standards for Voice RTP traffic. Note that this only effects actual voice packets; not the control packets used to set up, maintain and tear down VoIP connections.

Secondly, we are using the Cisco-proprietary NBAR (Network Based Application Recognition) mechanism to match traffic in our HTTP class. This makes it easy for us to narrow down what we want to match concerning web-based traffic.

Lastly, you’ll see that we’ve configured a class named class-default. This is a class created by the Cisco router that matches all traffic not defined by other classes. We applied the fair-queue command to this class so that the queuing is consistent with the other classes. The class-default will normally run in FIFO mode unless configured otherwise.

Okay, so now we’ve defined our traffic. Let’s tell the router what we want to do with it:

R1(config)#policy-map QOS
R1(config-pmap)#class VOIP
R1(config-pmap-c)#priority percent 40
R1(config-pmap-c)#class HTTP
R1(config-pmap-c)#bandwidth percent 50
R1(config-pmap)#exit

As you can see, the configuration here is very basic. We’ve created our policy-map and named it QOS. We simply enter the class sub-configuration for each class and apply our policy. We’ve applied priority queuing to the VOIP class, therefore employing LLQ. The use of the priority command also has certain implications for this traffic. While the bandwidth statement guarantees a certain amount of a bandwidth to that class of traffic, the priority command acts as a policer to guarantee that it does not starve the other queues from being serviced. So if the link where this policy is applied is running at full capacity, you can feel secure in the knowledge that your voice traffic will never completely impede your other traffic and will be capped at 40% of the available bandwidth.

Another important thing to remember when configuring your policy is that you cannot mix-and-match how you apply the bandwidth command. That is to say, if I apply a percentage to one class, I cannot apply a static rate to another class. I must either use all percentages or all static rates.

Time to apply our policy-map to the FastEthernet1/0 interface:

R1(config)#int fa1/0
R1(config-if)#service-policy output QOS
I/f FastEthernet1/0 class HTTP requested bandwidth 50%, available only 35%

Eh? “What’s this”, you ask? Something that we need to remember is that by default, Cisco only allows you to reserve up to 75% of an interface’s bandwidth. We created a policy where we’re trying to reserve 90% of the bandwidth. After first reserving 40% for the VoIP traffic, the router tries to allocate 50% for the HTTP traffic and fails because only 35% is left to be allocated. This can be easily changed with the following command:

R1(config)#int fa1/0
R1(config-if)#max-reserved-bandwidth 90
R1(config-if)#service-policy output QOS
R1(config-if)#

And there we have it. No problemo. Let’s verify that our QoS configuration took:

R1#sh int fa1/0
FastEthernet1/0 is up, line protocol is up
Hardware is i82543 (Livengood), address is ca00.0ee8.0008 (bia ca00.0ee8.0008)
Internet address is 192.168.12.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 2/2 (allocated/max allocated)
Available Bandwidth 0 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
807 packets output, 76917 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

We can also view our applied policy-map:

R1#show policy-map int fa1/0
FastEthernet1/0

Service-policy output: QOS

Class-map: VOIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Queueing
Output Queue: Conversation 265
Bandwidth 40 (%)
Bandwidth 40000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url “*blog.humanmodem.com*”
Queueing
Output Queue: Conversation 266
Bandwidth 50 (%)
Bandwidth 50000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
316 packets, 29622 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0

References

Books:

• Network Warrior
• Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition) (Exam Certification Guide)
• End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs (Networking Technology)

Configuring Weighted Fair Queuing

NBAR Information

An Expedited Forwarding PHB

This example was very basic, but anything more complex would use the same tools. As always, the most important thing you can do when putting implementing QoS is to have a solid plan in place and written policies. This gives you a strong base to consistently refer to as you complete the process.

neteng

Bookmark It

Hide Sites

Posted in HOWTO, Networking, QoS | 1 Comment »