04-01-2008 12:55 PM - edited 03-05-2019 10:07 PM
I've set up some QoS for voip on one of our routers and I'm trying to figure out if it's working well or not. When I do a sh policy-map int fa0/1 (fa0/1 is our wan interface) I get this:
FastEthernet0/1
Service-policy output: VOIP
Class-map: VOIP (match-any)
5874312 packets, 1117621866 bytes
30 second offered rate 21000 bps, drop rate 0 bps
Match: ip precedence 6
98126 packets, 7294839 bytes
30 second rate 0 bps
Match: access-group 105
5749717 packets, 1104816650 bytes
30 second rate 21000 bps
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 240 (kbps) Burst 6000 (Bytes)
(pkts matched/bytes matched) 119803/24766098
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
76560769 packets, 16724285480 bytes
30 second offered rate 2571000 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
no drops or anything like that....it's a 3MB line though so the 30 sec offered rate for class-default is very close to the max which is fine. When I do a sh int fa 0/1 I get this:
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 501451
which is showing output drops. Why would it show output drops when I do a sh int but when I do sh policy-map it doesn't show any drops?
here is the relevant configs:
access-list 105 permit ip any 10.13.6.0 0.0.0.255
class-map match-any VOIP
match ip precedence 6
match access-group 105
policy-map VOIP
class VOIP
priority 240
class class-default
fair-queue
interface FastEthernet0/1
bandwidth 3000
ip address 172.16.14.162 255.255.255.252
ip nbar protocol-discovery
rate-limit output access-group 110 200000 15000 18000 conform-action transmit e
xceed-action drop
ip route-cache flow
load-interval 30
speed 100
full-duplex
service-policy output VOIP
04-01-2008 05:37 PM
You really don't want to use a rate limiter with your service policy. Try something like this:
(pseudo config)
policy-map parentShaper
class class-default
shape 3 (Mbps - I forget whether value is kbps or bps)
service-policy VOIP
interface FastEthernet0/1
bandwidth 3000
ip address 172.16.14.162 255.255.255.252
ip nbar protocol-discovery
ip route-cache flow
load-interval 30
speed 100
full-duplex
service-policy output parentShaper
04-01-2008 06:35 PM
The reason I have a rate limit in there is because there's an app that they run once in a while that eats up all the bandwidth for a few minutes, so I'm rate limiting that app to 200k so it doesn't interfere with everything else too much. Do you still think I should remove that limiter?
For shaping it's bps...so would it be something like this?
policy-map parentShaper
class class-default
shape peak 3000000
service-policy VOIP
or would it be shape average 3000000 ?
04-01-2008 07:06 PM
I would use shape average.
For the app you're concerned about, you could try allowing it to fall into the FQ you have defined within your VOIP's class-default. FQ might manage it, if not, provide it its own class, also in the VOIP policy, and give it 1% bandwidth. That will allow it all excess bandwidth, but not impact (much) other traffic.
04-01-2008 07:25 PM
Thanks a lot I appreciate the advice...I set up the new policy and applied it, I'll see how it works out tomorrow.
Also about my original question, why would the sh int fa0/1 show output drops but the sh policy did not show output drops? Would those output drops be from the rate limiter?
04-02-2008 08:18 AM
Ok I changed the config to look like this:
policy-map VOIP
class VOIP
priority 240
class hungryapp
bandwidth 200
class class-default
fair-queue
policy-map parentShaper
class class-default
shape average 2750000
service-policy VOIP
interface FastEthernet0/1
description 14-Wall-Yipes
bandwidth 3000
ip address 172.16.14.162 255.255.255.252
ip nbar protocol-discovery
ip route-cache flow
load-interval 30
speed 100
full-duplex
service-policy output parentShaper
Here is the output of sh policy-map int fa0/1:
FastEthernet0/1
Service-policy output: parentShaper
Class-map: class-default (match-any)
2392277 packets, 635036078 bytes
30 second offered rate 2700000 bps, drop rate 31000 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
2750000/2750000 16500 66000 66000 24 8250
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 9 2377148 630705393 945044 333410957 yes
Service-policy : VOIP
Class-map: VOIP (match-any)
234285 packets, 48958171 bytes
30 second offered rate 192000 bps, drop rate 7000 bps
Match: access-group 105
234041 packets, 48940475 bytes
30 second rate 192000 bps
Match: ip precedence 5
0 packets, 0 bytes
30 second rate 0 bps
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 136
Bandwidth 240 (kbps) Burst 6000 (Bytes)
(pkts matched/bytes matched) 91207/19044059
(total drops/bytes drops) 2469/524556
Class-map: hungryapp (match-any)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 105
0 packets, 0 bytes
30 second rate 0 bps
Weighted Fair Queueing
Output Queue: Conversation 137
Bandwidth 200 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
2157992 packets, 586077907 bytes
30 second offered rate 2509000 bps, drop rate 26000 bps
Match: any
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 128
(total queued/total drops/no-buffer drops) 0/12659/0
According to this output the VoiP traffic has a good amount of drops which I'm trying to avoid. The line right now does look pretty saturated...but does that look right? Should I increase the bandwidth for on the VOIP class?
04-02-2008 09:41 AM
Yes, increase the VOIP priority bandwidth allocation to avoid drops. Doesn't hurt (much) to be overly generous, bandwidth not used by voice available to other traffic.
If voice drops eliminated and if you bump into any voice quality issues, you might need to adjust the parent shaper's burst size (to reduce the measured time interval).
04-02-2008 10:22 AM
Ok...another question, hopefully the last!:)
FastEthernet0/1
Service-policy output: parentShaper
Class-map: class-default (match-any)
615571 packets, 143218775 bytes
30 second offered rate 1135000 bps, drop rate 47000 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
2750000/2750000 16500 66000 66000 24 8250
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 573648 135529959 91406 51652873 no
Service-policy : VOIP
Class-map: VOIP (match-any)
15458 packets, 2975430 bytes
30 second offered rate 80000 bps, drop rate 0 bps
Match: access-group 105
15458 packets, 2975430 bytes
30 second rate 80000 bps
Match: ip precedence 5
0 packets, 0 bytes
30 second rate 0 bps
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 136
Bandwidth 340 (kbps) Burst 8500 (Bytes)
(pkts matched/bytes matched) 2614/507521
(total drops/bytes drops) 0/0
Class-map: ssgbroadcast (match-any)
32989 packets, 47763234 bytes
30 second offered rate 421000 bps, drop rate 0 bps
Match: access-group 110
32989 packets, 47763234 bytes
30 second rate 421000 bps
Weighted Fair Queueing
Output Queue: Conversation 137
Bandwidth 200 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 27831/41740267
(depth/total drops/no-buffer drops) 0/11/0
Class-map: class-default (match-any)
567124 packets, 92480111 bytes
30 second offered rate 639000 bps, drop rate 47000 bps
Match: any
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 128
(total queued/total drops/no-buffer drops) 0/42043/0
class-map match-any VOIP
match access-group 105
match ip precedence 5
class-map match-any ssgbroadcast
match access-group 110
!
!
policy-map VOIP
class VOIP
priority 340
class ssgbroadcast
bandwidth 200
class class-default
fair-queue
policy-map parentShaper
class class-default
shape average 2750000
service-policy VOIP
Why does the class-default show so many more drops then the class ssgbroadcast? It shows ssgbroadcast using 421000bps, and the configured for 200k, so unless I'm wrong it should be dropping alot more from that class then the class-default class (which is only getting about 630k).
04-02-2008 02:34 PM
Service-policy output: parentShaper
Class-map: class-default (match-any)
615571 packets, 143218775 bytes
30 second offered rate 1135000 bps, drop rate 47000 bps
Since your overall rate appears well under the shaper's value, it's curious there are active drops in child's class-default, unless some traffic is very bursty. Hard to tell what might help without seeing the traffic queued up. Try a peak shaper instead of the average shaper and/or try queue-limit 96 or 128 in the child's class-default, see if either makes a difference. (You might also try no fair-queue in the parent's class-default.)
On the question of ssgbroadcast vs. class-default drop ratios, two things to keep in mind, your ssgbroadcast isn't restricted to 200K it's provided a minimum of 200K. Second, what's the bandwidth allocation for class-default? These two factors can unexpectedly allow ssgbroadcast to grab bandwidth from class-default.
Some options for ssgbroadcast:
Don't provide ssgbroadcast its own class (if few flows in ssgbroadcast, allow FQ to sort them out in class-default)
Reduce ssgbroadcast bandwidth guarantee (even down to the minimum)
Add a policer or shaper to ssgbroadcast's class (e.g. provide minimum of 200K and shape to 200K)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: