qos | IPNET

Cisco QoS at-a-glance

Stephan, a colleague of mine, found the following documents digging through multiple pages of Cisco.com. The documents present a nice view of different QoS approaches and the most important information. Somehow like “cheatsheets”. They were helpful to us when need to implement QoS in some parts of the network that we administer. I hope they will help you as well.

Maybe you’re wondering why I’m adding them here, since the documents are already somewhere in Cisco.com. As you probably know, Cisco has constantly changing their website in the last months and a lot of documentation is misplaced in the Cisco.com sitemap. We already had problems finding all links, so I said why not share it here as they are already public made by Cisco.

You’ll find a Download button under each document, for PDF version and at the end of this post there is a Link to download all documents in an archive. If somebody needs only one document and has a poor Internet connection why to force them to download the full archive.

Cisco – Campus QoS Design

Cisco – Branch QoS Design

Cisco – IPv6 QoS

Cisco – QoS Best Practices

Cisco – QoS Design for IPsec VPNs

Cisco – QoS Design for MPLS VPN Service Providers

Cisco – Scavenger class – QoS Strategy for DoS Worm Attack

Cisco – QoS Design for MPLS VPN Subscribers

Cisco – QoS-Baseline

Cisco – WAN QoS Design

As said in the beginning, if you’d prefer, you download all QoS graphs in one archive.

Let me know your opinions on the above approach on QoS from Cisco. Is is accurate? Do you apply them in your organization weather for Campus, WAN, VPN or even Security?

Cisco: Prioritize Voice traffic with LLQ

In one of my previous posts I was explaining how to mark packets closer to network edge. Starting from that point, we are sure the packets are market with the correct value, so on the router device we can directly match those packets and prioritize using Low Latency Queueing.

I believe you already know why queueing is so important for Voice packet especially, but also for all other kind of real time protocol (e.g. Video over IP), but just a small reminder. Most of the interfaces are using FIFO method for queuing. This is the most basic queue method and as you probably know means First In First Out. In human terms, first packet how arrive on the interface will be send first. Nothing wrong with this theory until this point and I can assure you that most of the time you don’t have to do anything to improve this technique. But what if you have real time protocols (e.g. voip services) and data transfer over the same physical interface? With FIFO the packets are sent out the interface as they arrive, but this is not very good for the delay sensitive traffic like voice. If a TCP packet in HTTP flow can wait it’s turn to be sent out, with not visible impact for user, than a delayed voice packet will cause deprecation in voice call.

With this problems need to be solved we arrive at LLQ, which is an ehanced version of Priority Queueing (PQ) in a Class-Based Weighted Fair Queueing (CBWFQ).

Before we start let’s have a look to the topology we will use (the same like in Cisco: Mark voice packets at the network edge post):

After marking the packets on the Access Switch,now we want to prioritize voice packets on the core router:

1) Match packets market with EF in a class-map

class-map VOICE
match dscp 46

2) Configure a policy-map unde which you match the traffic in the class-map VOICE and enable LLQ. The parameter “priority” is the one telling policy-map to enable priority queueing under that class. The value after the “priority” keyword can be a value in kbps or percentage from the total bandwidth. In the example below I assume that I have a 10Mbps bandwidth and I’ll configure LLQ class to use 10% from it, meaning 1000kbps

policy-map MYPOLICY
class VOICE
priority 1000

or with percentage

policy-map MYPOLICY
class VOICE
priority percent 10

I have to tell you that after the bandwidth or percent value you can add a burst value in bytes. If you don’t add this value, it will be calculated automatically. I chose this method when I’m doing simple config, but if you want to fine tune the values you can calculate it yourself and add it. Be careful that a higher value will influence the Tc value in the process.

3) Apply the policy to the WAN interface of the Core router (I assumed that the Core router is your direct connection to provider backbone) direction outbound. You cannot apply this type of queueing direction inbound. Keep this in mind.

interface s0/0
service-policy output MYPOLICY

If you insist on applying it inbound, you’ll get an error message:

Core(config-if)#service-policy input MYPOLICY
Low Latency Queueing feature not supported in input policy.

To check that your queueing policy is applied:

show policy-map interface s0/0

Service-policy output: MYPOLICY

queue stats for all priority classes:

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: EF
Priority: 10% (1000 kbps), burst bytes 25000, b/w exceed drops: 0

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Cisco: Mark voice packets at the network edge

You know how Cisco always advise to mark the packet as close to the your network edge as you can? Even more you can find a lot of example where Cisco show how to trust the packets directly on the access switch, but not all the time you can do this.

First because not everybody has devices that mark correct packets (like Cisco IP Phones) but we still have to deal somehow with packet marking as maybe your provider treat packets different on their backbone based on their marking.

In this idea what I’m taking care the most are the voice packets as usually this has to be prioritized on the network. Let’s face it, if you have a TCP connection and some FTP packet are retransmitted you don’t notice this too much, but if you have delay on your phone conversation with your boss, that it’s not so good.

Please have a look at the topology below:

In this scenario we have a Voice server and some IP Phones (I know they look like Cisco IP phone, but pretend they are not) connected to the access switch. Let’s assume that we cannot trust marking on this packets as they arrive from this devices.

Here we run into one of the two issues. First if we trust the marking on the access port, than we don’t know what we are stuck with. If we don’t trust them, then the packets header DiffServ (TOS) bits are rewrite with a value of zero making no difference between voice packets and regular ones.

My solution is the following. I’m not saying that’s the only solution or the best, but it’s working:

On the access switch:

1. enable globally:

mls qos

2. configure and access-list that match the voice packet; this is a very general list:

access-list 101 permit udp any any range 16384 32767
access-list 101 permit udp any range 16384 32767 any
access-list 101 permit udp any any range 5060 5061
access-list 101 permit udp any range 5060 5061 any

3. match the access-list in a class-map

class-map match-all VOIP
match access-group 101

4.configure a policy-map with the class-map above and set the DSCP value to EF (decimal 46) or COS or whatever you need

policy-map ASTERISK
class VOIP
set dscp ef

5.on the access port configure the service-policy direction inbound

int x/y
service-policy input ASTERISK

6.on all trunks from your access switch to your first Layer 3 device trust this DSCP value (or what you have set, as now we are sure what values we set) with:

mls qos trust dscp

Let me know if it’s working!

Average IP Packet Size | Slaptijack (etherealmind.com)
Announcing the Packet Pushers Podcast – “Lab Scenario 1? (etherealmind.com)
Blog – How to Spot Suspicious VoIP signals (technologyreview.com)
Simple VOIP test calls and Toll Fraud (blindhog.net)

Great tool for testing QoS implementation

After my last post, some readers were asking what tool did I used for testing the QoS and how satisfied I’m with it.

The name of the tool is Packgen. According to its developer developers, “Packgen is a simple network packet generator handling diffserv markers, useful for testing network bandwidth and QoS.” It support features like:
– Network packet flows generation with given bandwidth (packets sent at each time interval depending on the bandwidth to produce and the size of the packets to generate);
– UDP and TCP flows;
– DSCP marking;
– Log generation which gives the possibility to compute statistics on the flows (to come later).

The main difference between IPerf (which is also a great testing tool, especially for bandwidth, jitter, packet loss tests…) and Packgen, is that the last one support diffserv marking natively. Of course you can achieve the same results with IPerf, with and ACL and inbound marking of the packets matched in the access-list, but with Packgen this is straight forward.

I had a little issue when downloading this tool, as the first result in Google search engine directed me to a page with no download link: http://packgen.rubyforge.org. This contains all the needed information about features, installation and how to use it (actually one of the best README that I ever saw for such tools), but no suggestion where to download the package. I search a little bit and you can download it from this official link.

To install this tool, you need to have Ruby on your system and then just run from inside the unpacked Packgen folder:

ruby ./setup.rb

Now some words about how to use it. From my post about AutoQoS, you can see that you need at least one client and one server. This 2 devices, use different files with Packgen (Don’t worry as the files come in the source package and if not, it’s very easy to create them).
First the server file, called listen.yml (if you create it, you can give whatever name you want) looks like this:

LISTEN:

udp:
–
ports: !ruby/range 17000..17002
tcp:
–
ports: !ruby/range 5002..5004

As you can see, there are 2 sections defined for UDP and TCP traffic. Then with “!ruby/range” you define a range where the server will listen. However, you can also simply use an Integer port number.

Then on the client side, there is file called sent.yml:

SEND:

udp:
–
name: Voice
host: 10.10.10.100:17000
bandwidth: 700Kb
packet_size: 252B
dscp: ef
from..to: !ruby/range 0.0..60.0
–
name: Video
host: 10.10.10.100:5002
bandwidth: 2.8Mb
packet_size: 750B
dscp: cs4
from..to: !ruby/range 10.0..60.0
tcp:
–
name: Best Effort
host: 10.10.10.100:5002
bandwidth: 3.2Mb
packet_size: 1KB
from..to: !ruby/range 20.0..60.0
–
name: Background
host: 10.10.10.100:5002
bandwidth: 3.2Mb
packet_size: 1KB
dscp: cs1
from..to: !ruby/range 30.0..60.0

Here it’s a little bit more complex, but still human readable. This file also have 2 sections for UDP and TCP traffic, with the following paramters being defined:

-name: I believe it say everything
-host: ServerIP:port
-bandwidth: bandwidth to simulate
-packet size: packet in size in B, KB
-dscp: value
-from..to: !ruby/range: time intervals

After everything is defined, you just have to run Packgen to test.
On Server side first:

packgen -i listen.yml

Then on Client side:

packgen -i sent.yml

Optional you can add the -l file option, which will log the traffic send:

1258663872.6248 SEND dest=10.10.10.100:16385
1258663882.62591 SEND dest=10.10.10.100:5001
1258663895.65219 SEND dest=10.10.10.100:5002
1258663905.66876 SEND dest=10.10.10.100:5003
1258663933.72797 STOP dest=10.10.10.100:16385

or received:

1258663869.80496 LISTEN port=16384 proto=udp
1258663869.81079 LISTEN port=16385 proto=udp
1258663869.81441 LISTEN port=5002 proto=tcp
1258663869.81506 LISTEN port=5003 proto=tcp
1258663872.5886 RECV sent_at=1258663872.64102 flow=0 size=252 id=6
1258663872.58893 RECV sent_at=1258663872.64613 flow=0 size=252 id=7
1258663872.58903 RECV sent_at=1258663872.64719 flow=0 size=252 id=8
1258663872.58915 RECV sent_at=1258663872.65052 flow=0 size=252 id=9
1258663872.58924 RECV sent_at=1258663872.6742 flow=0 size=252 id=10

The configuration files and logs excerpt were from my AutoQos test. If you have any issues with using it, please contact me, or just check in details the documentation from developers site.

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:

Other articles that you might be interested in: