Cisco AutoQoS VoIP

QoS – one of the most interesting and challenging part of the network engineer’s life. I think I’m not wrong when I’m saying that most engineers that hear the word QoS, react somehow like “ah, that ugly stuff…” I have to be honest and say that QoS is not one of my preferred part, but as a network engineer you have to accomplish all task, not only the one that you like. With QoS you can achieve some great results, and once you have started to work with it, you’ll see that is not such a monster. The idea that QoS is not a friendly topic was develop due to historical ways to configure this service. In fact there were so many ways that without working with this topic everyday, you have no chance to remember how has to be implemented. Even among Cisco devices, there were multiple way to configure QoS from device to device. Nowadays Cisco is putting a lot of effort to standardize the implementation of QoS and in the same time to simplify it.

In this context AutoQoS appeared. First, AutoQoS VoIP was developed as the more QoS configuration is needed for Voice traffic over the network and then a more complex Auto QoS Enterprise was released. Today I plan to speak a little bit about AutoQoS VoIP and in one of the future articles about the Enterprise edition.

AutoQoS VoIP gives you the ability to deploy QoS features for converged IP telephony and data networks in a fast and reliable way, by simplifying the MQC (Modular QoS command-line interface). AutoQoS VoIP generate automatically traffic classes and policy map CLI templates. In more human terms, if AutoQoS VoIP is configured on an interface, the traffic that is passing by is receiving the required QoS treatment automatically. By doing this automatically AutoQoS spares you from having in-depth knowledge about the services policies, link  efficiency mechanism or best practice for Voice QoS. Everything is done by AutoQoS, which automatically discovers applications and provides appropriate QoS treatment, generate policies and provide configuration.

Of course that are some drawbacks like in any other technology, but this can be easy overcome if you have some knowledge about QoS configuration. It theory everything should run smoothly, but in real environment, you run into the situation that QoS should be fine tuned to reach the level of your expectation. This is easy done with AutoQoS, as after it enable and configure the QoS templates, you can easy configure them to fine tune parameters, add or delete policies. Basically you start from nice template, sourced by AutoQoS, and develop your own QoS. As I said before, you have only to do this is something is not working or if you feel the strong attraction to “make it your own way”.

AutoQoS VoIP is supported on the most popular Cisco routers and switches platform with the appropriate IOS or CatOS image. Before you configure AutoQoS VoIP you should know that:

– CEF is required to be configured, as AutoQoS use NBAR (Network-Based Application Recognition) which is based on Cisco Express Forwarding
– no QoS Policies are attached on the interface on which you are configuring AutoQoS
– correct bandwidth has to be configured on the interface; if there is no bandwidth statement, then this defaults to 1544 Mbps, which is not all the time accurate

Now a tricky part in regards to interface bandwidth. If this is 768kbps or below, you have to configure an IP address on the interface due to the fact the AutoQoS is enabling by default Multilink PPP and copy the  configured IP under the multilink interface. If you configure AutoQoS on a remote site, and the 768kbps (or lower) interface is the only connection there, please pay attention as configuring AutoQoS Voip may break your connection due to MLP situation explained above.

Another recommendation from Cisco and me, is that you should use no auto qos voip command when you stop using the interface on which AutoQoS VoIP is configured. In this way you assure that all the QoS configuration will be removed. If you just shutdown the interface or delete the PVC, without the above command, then the AutoQoS VoIP will not be completely removed.

Configuration is very simple:

router# configure terminal
router(config)# interface Serial x/y
router(config-if)# bandwidth 1540
router(config-if)# auto qos voip
router(config-if)# exit

I tried to put together a scenario like in the following topology, to generate some traffic and show you have AutoQoS behave when configuring policies:

Cisco AutoQoS VoIP topology

After applying the AutoQoS config you should see something like this in your running-config:

class-map match-any AutoQoS-VoIP-Remark
match ip dscp ef
match ip dscp cs3
match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
!
!
policy-map AutoQoS-Policy-UnTrust
class AutoQoS-VoIP-RTP-UnTrust
priority percent 70
set dscp ef
class AutoQoS-VoIP-Control-UnTrust
bandwidth percent 5
set dscp af31
class AutoQoS-VoIP-Remark
set dscp default
class class-default
fair-queue
!
ip access-list extended AutoQoS-VoIP-Control
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range 16384 32767

I will try to generate some traffic between this, so called, voice server and client and to let AutoQoS  VoIP do it’s job and configure automatically traffic flow policies.

Below you have a video tutorial about AutoQoS VoIP has to be configured and some monitoring commands that will output the result of traffic flow:

cisco-autoqos-voip

How to integrate GNS3 with Virtual PC

In this article I want to show you how to extend your posibilities to test a network in GNS3. Sure, it’s simple sometime to use a Loobpack interface on one of your edge routers to simulate an external network, but sometime is useful to have something connected to the router port. Take as an example QoS marking and classification. If you want to mark something inbound, then you need a connection to the router port where you want to mark the packets.

Additional to my example here, which include Virtual PC Simulator, you can find useful tutorial about GNS3 and VMware integration on  gns3-labs.com or how to emulate a voice lab with the same tools on blindhog.net.

Even most of you are familiar with GNS3 and maybe Virtual PC Simulator, let me begin with some short description about this 2 software.


GNS3 is a Graphical Network Simulator that allows emulation of complex networks. It allows you to run a Cisco IOS in a virtual environment on your computer (running Linux, MacOS X or Linux). GNS3 is a graphical front end to a product called Dynagen. Dynamips is the core program that allows IOS emulation.

The Virtual PC Simulator (VPCS) allow you to simulate up to 9 PCs. You can ping/traceroute them, or ping/traceroute the other hosts/routers from the virtual PCs when you study the Cisco routers in the Dynamips. VPCS is not the traditional PC, it is just a program running on the Linux or Windows, and only few network commands can be used in it. But VPCS can give you a big hand when you study the Cisco devices in the Dynamips. VPCS can replace the routers or VMware boxes which are used as PCs in the Dynamips network.

Before we start, I assume that you already have these tools installed. If not, please download and install GNS3 and VPCS.

On the following example I will show you how to configure a network topology including 2 Virtual PCs and one router and how to interconnect them in GNS3. This presentation is simulate a basic network, but after you learn how to do it, you can configure more complex one. You can have a look to the topology to understand better what I’m talking about.

Please see the video presentation below:

gns3-virtualpc