All Entries in the "Cisco-QoS" 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: 5% [?]

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: 2% [?]

Cisco: Configuring Compressed Real-Time Protocols

I had lately to configure compressed real-time protocols (CRTP) over a Frame-relay link.
I thought that it will be good to make a tutorial about how to configure this on the Serial interfaces (with HDLC or PPP encapsulation) and on the Frame-relay interface. Another type of interface supporting this is and ISDN interface, but the configuration there is the same like in the Serial interface case.
If you were asking why I don’t configure this on a Ethernet interface, well this is because CRTP is not supported on the Ethernet interfaces. This was just an explanation for those of you who didn’t knew this. The role of CRTP is to improve communication over low bandwidth links like Serial interfaces, Frame-relay or ISDN, and that’s why is not supported on Ethernet links (who’s speed is starting at 10 Mbps).

In the following tutorial I will configure CRTP on a Serial interface with PPP encapsulation (I chose this randomly as is the same with HDLC and ISDN) and Frame-relay interface, limit the number of header compression connections and check CRTP with “show…” commands. Since the purpose of this tutorial is CRTP the connection will no be active.

See the tutorial below:

Popularity: 3% [?]

Cisco: How-to limit HTTP traffic on weekdays during working hours

Some time ago a person asked me to set the HTTP traffic to 256 kbits during weekdays from 8:00 – 16:00, to limit “the fun” in the office while other are working. In theory I’m against this type of policy, because if you have a team of network engineers and they have to access cisco.com in the same time for information and other stuff like IOS download, then this will take a lot of time. Of course if you see that the productivity is going down because 80% of the traffic is to YouTube site (nothing against them, just picked randomly), then such measures are welcomed.

Since the discussion below is beyond the scope of this tutorial and represent only a personal opinion, let me tell you what I’ll show in the tutorial below.  On Fa0/0 (out connection) we will limit the HTTP responses sent out to 256kbps from Monday to Friday between 8:00 and 16:00

Please see the tutorial below:

Popularity: 1% [?]