Cisco

Learn the benefits of Cisco AutoQoS

Configuring quality of service (QoS) can be very complex. To help make network administrators' lives easier, Cisco has developed AutoQoS, which configures QoS settings for you. In this edition of Cisco Routers and Switches, David Davis introduces you to AutoQoS, discusses its benefits, and tells you how to configure it.

Configuring quality of service (QoS) can be very complex. The Cisco IOS features many different methods for QoS—so many that there are entire books that cover the topic of QoS.

To help make network administrators' lives easier, Cisco has developed AutoQoS, which configures QoS settings for you. The concept almost sounds too good to be true, but is it? Let's review AutoQoS to see how it really works.

Review the basics

Let's start off by reviewing the basics. QoS offers the following benefits:

  • Prioritize traffic to delay sensitive traffic—for example, to ensure that lower priority traffic doesn't damage voice traffic.
  • Prioritize traffic to ensure a less-critical application doesn't slow down business-critical applications.
  • Prioritize traffic to ensure that undesirable traffic doesn't overutilize bandwidth.
  • Conserve bandwidth by slowing the transfer of non-critical data.

You can configure QoS using a number of different methods on a Cisco IOS router. Here are some of your options:

  • Manually configure QoS by creating ACLs to identify traffic and then control that traffic with QoS commands.
  • Use Cisco's Security Device Manager (SDM) and the QoS Wizard to create predefined QoS policies, and then edit those policies.
  • Use AutoQoS to create policies based on real-time traffic flowing through your router or switch.
  • Use AutoQoS to create predefined voice over IP (VoIP) policies for VoIP traffic flowing through your IOS device.

Understand the benefits of AutoQoS

AutoQoS runs on Cisco IOS routers series 2600 through 7200, and it runs on most Cisco routers with IOS version 12.2(15)T and later. AutoQoS offers the following benefits:

  • You don't need to understand QoS as much as you would if creating QoS policies from scratch.
  • You can modify the QoS polices you've created and use them elsewhere, like a template.
  • You can save time in QoS configuration.

Before running AutoQoS commands, you should enable CEF using the ip cef command when in Global Configuration Mode. In addition, you need bandwidth statements on your interfaces. This is because AutoQoS uses the bandwidth statements when configuring bandwidth limitations for protocols it will be prioritizing. If you change your bandwidth statements after configuring AutoQoS, you must rerun AutoQoS.

Also, keep in mind that you don't configure AutoQoS in Global Configuration Mode—you do it in Interface Configuration Mode. Now, let's look at an example for how to configure AutoQoS for VoIP.

Configure AutoQoS

Configuring AutoQoS is easy—the hard part is understanding what it configured for you, modifying the configuration if necessary, and testing it to make sure it works. For our example, we'll configure AutoQoS for VoIP.

AutoQoS VoIP runs on certain types of interfaces. The most simplistic example is a point-to-point T1 circuit between two routers with VoIP traffic traversing that link.

Let's say that we're configuring AutoQoS on the Serial interface between these routers. To begin, go into Interface Configuration Mode for the interface that faces the source of the traffic you want to control. Here's an example:

Router(config)# interface Serial0/0
Router(config-if)# auto qos voip

And that's it! The amount of commands that this one command generates is surprising. Listing A offers a look at the part of this router's show running-config affected by this command.

As you can see, the auto qos voip command is still on the interface, but there's been the addition of a policy called AutoQoS-Policy-unTrust. The untrusted version of the command is the default.

Alternatively, we could have run the auto qos voip trust command. The trusted version of the command uses Differentiated Service Code Point (DSCP) marking to prioritize traffic. The version that we ran uses Network Based Application Recognition (NBAR) and access control lists to identify the VoIP traffic we're trying to control.

The new AutoQoS configuration generates many new commands, but don't let them confuse you. If you can see these commands working together in the system, these commands don't seem as daunting. Here's a basic breakdown:

  • The access control lists define traffic.
  • The class-maps put the traffic into classes. They know which traffic to put into each class by the access control list that it matched, the DSCP bit that it matched, or the NBAR protocol that it matched.
  • The policy-map assigns priorities to the classes.
  • It applies the policy-map to the interface, which affects the traffic.

Now that we've run these commands on one side of the interface, we also need to run them on the other side (i.e., the other router) as well. I highly recommend running these commands in a test environment prior to using them on a production network.

For more information on AutoQoS, check out these Cisco resources:

Miss a column?

Check out the Cisco Routers and Switches Archive, and catch up on David Davis' most recent columns.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.

8 comments
dlee
dlee

This part of the sample concerns me: permit udp any any range 16384 32767 That would work fine for Cisco phones, but we use Avaya and they operate on UDP ports 50000 through 55000. Does the router use some sort of traffic analysis to discover what ports are used for VOIP or does this work only for Cisco phones? Edit: Great article by the way!

ddavis
ddavis

Hi, Thanks for your post! This QoS should work for any type of traffic if the ACL or NBAR traffic identification can be modified to recognize your traffic. In your case, I would modify this ACL to add your ports & protocol: ip access-list extended AutoQoS-VoIP-RTCP I would watch your traffic with a protocol analyzer to ensure you get everything classified properly. Thanks for reading TechRepublic! -David

mohd_arab
mohd_arab

what if i want to change the bandwidth or the priority percentage for certain traffic (ex: voip?) does that affect the operation of the auto Qos?

alan
alan

My understanding is the AUTOQOS uses traffic markings. VOIP traffic uses EF markings not protocols or port based ACL's so should work with all VOIP solutions as long as they are marking the IP traffic correctly. Alan Scott New Zealand CCIE Candidate

ddavis
ddavis

Hi, Thanks for your post. You are welcome to change the config after it is created by autoqos. No, it really doesn't affect the operation just make sure what you are doing makes sense so that you don't actually hurt your traffic instead of help it. Thanks for reading TechRepublic! -David

skispcs
skispcs

I believe that it will remark traffic marked ef, cs3, and af31 to default. This is to prevent someone from setting their traffic to those dscp values and getting priority treatment. In the policy map that class will only be hit if the two above it are not matched, meaning it isn't valid rtp or control traffic.

kgardiner
kgardiner

I am a bit confused about what the class AutoQoS-VoIP-Remark set dscp default statement is doing. Is it matching packets that have been marked by the far end and then setting it back to 0? BTW, excellent series of articles.

Editor's Picks