All Entries in the "Network Services" Category

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:

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:

Popularity: 6% [?]

Cisco: How to shape traffic on Frame-Relay connection

In some previous article, I explained how to configure a Frame-Relay Hub and Spoke network environment. Based on that example, I will show you today how you can implement traffic shaping over the Frame-Relay Hub and Spoke.You can have a look at the topology that we will use here.

A note from the beginning. Since I do not have a traffic generator, I cannot really prove that the traffic is shaped, you’ll just have to believe me or to try on your own.

Let’s assume that we have an excessive amount of packet loss between R1 and R2 from the topology and the R1 is overwhelming the Frame-Relay connection to R2. R1 has a port speed of 512Kbps and we have to assure that R1 is sending traffic at 384Kbps. In case that the connection get congested R1 should throttle down the CIR to 256Kbps. R1 should be permitted to burst in case it accumulate credit and to minimize the delay due to serialization the interval (Tc) should be 10ms.

To summarize:
-we have a CIR of 384Kbps; CIR = 384Kbps
-when congested CIR throttle down to 256Kbps;  minCIR = 256 Kbps
-time interval is 10ms; Tc = 10ms
-burst size, based on the date above is 3840 bps;  Bc=CIR*Tc=384000*0.01=3840; (note that CIR has to be in bps and time in seconds)
-also R1 is allowed to send burst in excess in case of accumulated credit, so excess burst is 1280 bps;  Be=(AR-CIR)*Tc=(512000 – 384000) * 0.01=1280 (AR is the port speed 512Kbps)

After we have gathered all this data let’s proceed to the Cisco device configuration. Please see the presentation below:

Popularity: 3% [?]

Cisco: How to use kron to automate tasks

Now and then everybody in IT network industry has to stay awake over the night to accomplish some tasks that cannot be performed during the work hours because will disturb regular activity. Some of this task usually need your presence in field (virtually or in place), to assure that everything is working fine and you don’t have any unwanted surprise the next day.Skipping this tasks, there are other ones with less impact in case of a failure, which I believe you rather prefer to do it automatically and to check the results when you can. I’m talking here usually about configuration save or archive, IP addresses being renew by DHCP  or data backup

All this stuff can be achieved by using the Cisco “kron” present in the IOS. I think that everybody who’s ready this post heard about cron jobs, so I will issue just a small explanation. Cron jobs are tasks definite to run at one certain moment or to be recursive over a period of time. In human terms, cron jobs can help us sleep well why they are doing the job over the night.

Speaking now about Cisco “kron” command, you should know that it appear starting with IOS version 12.3(1), so don’t try to find it if you have a previous version installed. Also, The EXEC CLI specified in a Command Scheduler policy list must not generate a prompt or have the ability to be terminated using keystrokes. Command Scheduler is designed as a fully automated facility and no manual intervention is permitted. Command Scheduler allows you to schedule fully-qualified EXEC mode CLI commands to run once, at specified intervals, or at specified calendar dates and times.
Command Scheduler has two basic processes. A policy list is configured containing lines of fully-qualified EXEC CLI to be run at the same time or interval. One or more policy lists are then scheduled to run after a specified interval of time or at a specified calendar date and time. Each scheduled occurrence can be set to run once only or on a recurring basis. Policy lists can be configured after the policy list has been scheduled, but each policy list must be configured before it is scheduled to run.  Policy lists consist of one or more lines of fully-qualified EXEC CLI commands. All commands in a policy list are executed when the policy list is run by Command Scheduler using the kron occurrence command. Use separate policy lists for CLI commands to be run at different times.

One mandatory tasks is that before you try to run “kron”, your Cisco device has to know the time. Either manully set or through NTP server. If the device does not know the time, than a warning message will appear when you’ll try to configure kron tasks.

Please see below some brief examples about how you can configure kron tasks.

Popularity: 5% [?]

Cisco: How-to get notifications for IP SLA monitor using EEM

In some previous post, I explained how to configure a basic IP SLA monitor for checking the round-trip time between two Cisco routers. Because in the comments of that post I have been asked how you can get e-mail notification for IP SLA monitor, I have decided to write another post to extend a little bit this topic.

To accomplish e-mail notification for IP SLA monitors we will use Embedded Event Manager (EEM) and some SNMP knowledge.Cisco IOS EEM is a powerful device and system management technology integrated into specific Cisco switches and routers. EEM gives us the ability to customize Cisco IOS behavior based on network events as they happen.

EEM will use a SNMP event to report anomalies in regarding the RTT threshold value. For SNMP to work we need to know and Object name and the OID associated with it. In my example I will use the SNMP Object name: rttMonCtrlOperOverThresholdOccurred (OID: 1.3.6.1.4.1.9.9.42.1.2.9.1.7). On Cisco website you can find more about this SNMP Object and I advice you to read it before going on with this tutorial.

Below you have a basic example about how to get e-mail notification when the threshold of the RTT IP SLA monitor is reached. More examples you can find on Ivan Pepelnjak’s blog: blog.ioshints.info . It’s a good idea to check them also.

The topology remains the same like in the previous post about IP SLA. You can check it here. Please click below to check the tutorial:

If you cannot check the tutorial above, please read this text file, as it contains all the information from the video presentation.

Popularity: 8% [?]