urgent qos shaping policing problem

Unanswered Question
Jan 7th, 2008

we have the task to connect an ethernetsubinterface to a switch where our provider is connected.

the provider expects 6mb/s of traffic from our router.

because the ethernetinterface is 100mb/s, we have to configure hirachical queueing because we ave qos for voip.

so the idea was to configure a parent policy map for shaping and a child for llq and cbwfq

the problem is, that the shaping prozess discards also voip pakets when the linespeed exceeds 6mb/s for incomming.

we think, that the shaping-prozess takes place before the queueing and it doesn't notice the voip pakets and drops it.

so we have dropped voice pakets before the queueing takes place.

is there a solution - a kind of precedence or dscp based shaping on the outgoing interface.

following the config, where we have the problem:

policy-map egress_queue

class voice

priority percent 30 4000

class gold

bandwidth percent 20

class silber

bandwidth percent 20

class stahl

bandwidth percent 10

class system_intern

bandwidth percent 5

class class-default

bandwidth percent 10

policy-map egress_queue_parent_10240

class class-default

shape average 102400000

service-policy egress_queue

!

interface FastEthernet0/0.412

description to r-bbi-test2

bandwidth 10000

encapsulation dot1Q 412

ip address 5.5.5.2 255.255.255.0

no snmp trap link-status

mpls label protocol tdp

tag-switching mtu 1512

tag-switching ip

arp timeout 300

service-policy output egress_queue_parent_10240

!

thanks for any answer

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (3 ratings)
Loading.
bvsnarayana03 Mon, 01/07/2008 - 09:44

Configuration looks ok.

can you see the output of "sh policy-map int fa0/0.412".

Do u see any matches against voice class or drops. Output may help predict the behaviour & reason for deviation.

royalblues Mon, 01/07/2008 - 13:19

Shaping would definitely start delaying the packets when the rate of traffic input is higher than the threshold configured.

Since VoIP is very sensitive to delay, this would affect the call quality though the packets are not actually dropped.

You can also try using max-reserved-bandwidth 100 command under the interface otherwise by default only 75% of the configuered bandwidth would be used for QoS

HTH

Narayan

chschroe Mon, 01/07/2008 - 17:00

Major issue: you're shaping to 102 megabits per second. The shape rate needs to be set to what the provider is expecting. If its 6 megs, set it to shape average 6291456. Its very important that you set that to the exact same value your provider is expecting.

Fixing that should almost certainly fix the basic problem. You'll want to change the bandwidth statement in the interface to match 6 megabits as well.

You also said packets were being dropped before they're queued? Queuing absolutely happens before shaping - shaping requires queueing in order to occur - packets would be discarded by your CBWFQ configuration, but in your configuration I'd be surprised if any packets were being dropped by your router at all. All the queues are set up as percentages of 102 megabits in your config example.

For VOIP networks to work correctly - your shape rate must be exactly what the provider is expecting. No more. We can optimize the shaping quite a bit to really make the traffic flow look the way it should, but that can get to be quite complex. Let's see if the simple changes fix this first.

NS

You said packets are being dropped when you hit 6 megabits incoming? There's nothing you can control about that - the provider is handling the egress queuing from their interface to yours. You would have had to control the rate coming into their network on the other end to affect how packets would be arriving on yours.

rabeder Tue, 01/08/2008 - 04:06

hi, thanks for answer,

as i describet - we found the solution and the problem with the 102 mega was a copy paste problem - sorry for that.

of course we shaped to 6 mega

the solution was the burst size in voice queue

dgahm Mon, 01/07/2008 - 17:03

Kurt,

Here is a working example for a 10mb Metro pipe that allocates 4mb for voice/video, and 6mb data that is traffic shaped at 6mb. The real time voice/video bandwidth, in this case is controlled by Call Manager to not exceed 4mb, and voice/video is very non-bursty by nature, so traffic shaping is not required. The priority queueing ensures that the real time traffic will experience minimum jitter.

The downside to this approach is that the data cannot burst to use the extra 4mb when voice is not present, but the voice quality is always excellent.

policy-map AdvantageVV

class voice_video

priority 4000

class class-default

shape average 6000000 100000 0

service-policy Data

Please rate helpful posts.

Dave

rabeder Tue, 01/08/2008 - 04:02

thanks for answer,

the only problem of this is, that can only have data traffic up to 6mb/s although the line has 10 mb/s - and that is not what we want.

but today i found the solution - see in my posting

rabeder Tue, 01/08/2008 - 03:59

SOLUTION FOUND

Hi, to everybodey - thanks for any answer.

the reason was the burst size of the voice queue.

i increasd it from 4000 to 64000 - and now it works.

the 6 mb/s and 10mb/s missunderstanding was only because of labor enviroment.

OF COURSE we have shaped to 6 mb/s and not as in the above outout to 102400000 - sorry for that - wrong output!

Actions

This Discussion