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:
priority percent 30 4000
bandwidth percent 20
bandwidth percent 20
bandwidth percent 10
bandwidth percent 5
bandwidth percent 10
shape average 102400000
description to r-bbi-test2
encapsulation dot1Q 412
ip address 126.96.36.199 255.255.255.0
no snmp trap link-status
mpls label protocol tdp
tag-switching mtu 1512
arp timeout 300
service-policy output egress_queue_parent_10240
thanks for any answer
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.
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
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.
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.
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
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.
shape average 6000000 100000 0
Please rate helpful posts.
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
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!