QoS Question

Unanswered Question
Jun 10th, 2009

Hello Experts-I know "jack" about QoS other than it's short for quality of service. With that said, here's the sit:

We had a 2851 router acting as a WAN data link and voice gateway for our DC location until this AM. we cut over to a mpls 3rd party managed router which will now serve as the wan link and provide the layer 3 hopping and the 2851 will serve only as a voice gateway. Since cutover, we've seen while during backups over the WAN, some ip phones unregister and cannot obtain ip adds. The operations team seem is going to open a ticket w/vendor to troubleshoot QoS. My question: Is QoS even in play at that point (when devices are registering?) is thought it's only applied to active rtp voice streams (traffic of calls in progress). Please see config as to how we're doing QoS. As always, thanks.

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
parshah Wed, 06/10/2009 - 11:38

hi,

QoS is in play all the times. Consider QoS as dividing your IP pipe into sections. The policy-map defines how big each section is.

So if you are experiencing phone unreg issue when you have heavy traffic on the link, means there are some packets, in this case keep alive packets between CUCM and IP Phone are not being exchanged.

Am not an expert on QoS but looking at your config, I think there are a few things you have missed. In the Voice-Control Class Map you are matching packets with AF31 only. You should be matching CS3 as well. Per new QoS recommendations, voice signalling traffice is marked CS3. So match both AF31 and CS3

In policy map, you are re-marking all the voice traffic to EF, not a good idea. packets with AF41, AF42 in CUCM are video packets. These are large packets, you don't want them marked as EF and you don't want them in the priority queue, primarily because of their size.

Also, your Voice control traffic has bandwidth percent of 2. I don't know what kind of bandwidth you have but try and increase to 5 and see if that helps.

Finally, you don't have a fair-queue in the policy map. Without that command you are allowing packets with other marking to possibly hog up the bandwidth.

Finally, make sure that your service provider is honoring these markings. If not, than no matter what you do on the WAN edge the service provider will always mess things up.

Thanks,

Nicholas Matthews Wed, 06/10/2009 - 17:34

This is a little messy of a configuration.

There are multiple ways for your voice signaling to be marked as EF, and if your voice traffic is going over your EF guarantee, you can have drops.

Both the access list and your 'match protocol h323' are in your voice class.

I don't know your subnetting, but if your CUCM or gateways are in that subnet, it's very likely that all of your signaling is getting thrown in there. If you're using H323, it definitely is.

I would remove the access list if it is only for RTP traffic, and replace it with 'match protocol rtp audio'.

Then, move the 'protocol H323' down to your signaling class-map.

What type of interface are you applying this to? If the interface speed is faster than your WAN, as is the case when you have a FastE connection to your provider's T1, this policy will not do anything.

'show policy-map interface' and 'show interface' are going to be your best guides on determine how your policy is classifying and dropping.

hth,

nick

Googi1974 Thu, 06/11/2009 - 11:42

Hi Nick,

Please forgive my lacking knowledge, some of this is a bit over my head. I don't quite understand the question"what type of interface are you applying this to," but maybe this diagram can help you tell me? Is the interface in question the one generating the traffic? I think I can say that the interface speed is faster than the WAN (gigabit interface to XO's mpls router which is providing a 6 meg pipe to dc.) Thanks again for your patience, I'm trying to navigate an aggressive learning curve here. -Kelly

Attachment: 
Nicholas Matthews Thu, 06/11/2009 - 12:50

Hi Kelly,

This is precisely what I was talking about.

Qos is only really applicable at bottle necks, where you would drop packet. In your diagram you're not going to drop packets on the gigabit link to the provider's router.

The place you'll drop is on the provider's router, but you can't really change what they're doing normally.

What you can do is create your own bottleneck at the same speed as your uplink on your router, and then do QoS there. That way, when traffic gets to the managed router, it doesn't have to drop anything.

In this case, you do a hierarchical policy. It looks like this:

policy-map parent

class class-default

shape average 1544000

service-policy child

policy-map child

class voice

priority percent 60

class class-default

fair queue

What this particular one does is shape the traffic to 1.5 Mb/sec, which is the speed of your T1.

If you only get a partial T1 like 700 kb/sec, you would need to reduce that number.

Make more sense?

-nick

Actions

This Discussion