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 ?

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.

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?

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?

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).

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).

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)