01-07-2008 09:06 AM - edited 03-03-2019 08:09 PM
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
01-07-2008 09:44 AM
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.
01-07-2008 01:19 PM
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
01-07-2008 05:00 PM
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.
01-08-2008 04:06 AM
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
01-07-2008 05:03 PM
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
01-08-2008 04:02 AM
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
01-08-2008 03:59 AM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide