I know it's hard to see due to the formatting but there are no delayed packets recorded in either show output.

As for the Bc, it's recommended to be the CIR/100 for real time networks to have a burst interval of 10ms. I originally had this shaper at 2Mb and had the same results (More than 2Mb of traffic, but the shaper did not activate).

I'm not sure what you mean by Max Packet (MTU?), but I don't think it would be the issue since I had the same behavior at 2Mbps.

I'll double check the output rate state when I get to do some testing tomorrow, good idea.

I'm using a Cisco 2811 that is running, SP Services 12.4(3i). I plan on changing the IOS to Advanced IP Services tomorrow.

As for the "max-reserved-bandwidth 100", my customer wants to be able to do CBFWQ for the entire bandwidth of the circuit (2Mbps). I know this isn't best practice and so does he, but it's his network so his call.

Thanks for the reply.

Yes, the whitespace compression is a problem, so for

- 0 72 9070 0 0 no

- 0 109 14642 0 0 no

what's the non-zero values counting?

Yes, generally smaller Tc are better for traffic like VoIP, but to get your Bc to match 1500 bytes would only require Tc to be 12ms for 1 Mbps (I think). Unlikely the extra 2ms, alone, would be a problem. (Plus so far you're only shaping, that alone isn't going to do much for real time traffic, although it provides WFQ[?].)

Without knowing your actual 2 Mbps parameters, can't say whether your Bc was too small. (Again, not positive this is an issue.) MTU is maximum transmission unit, i.e. largest packet media can tranmit. Standard Ethernet's is about 1500.

If there's a downstream limitation of 2 Mbps, why shaping for 1 Mbps?

I would be surprised changing the feature set would make a difference. (Although it wouldn't be the first time I've been surprised.) Changing the release, might be something you want to try. 3i is from 11/7. The latest of those is 3j, from 12/7. You might consider something that's current with many patches, e.g. 18e (4/9).

You don't need to use "max-reserved-bandwidth 100" to use all possible bandwidth, it has more to do with how much bandwidth you can define (reserve) for non-class-default classes, but doesn't cap them (excluding LLQ).

They are for:

Adapt Active: - & -

Queue Depth: 0 & 0

Packets: 72 & 109

Bytes: 9070 & 14642

Packets Delayed: 0 & 0

Bytes Delayed: 0 & 0

Shaping Active: no & no

The ultimate goal is for WFQ and we have all the classes and such defined, but when it wasn't working as expected we removed the WFQ as part of troubleshooting.

We then lowered the shaper to 1Mbps, so in our tests if we got more then 1Mbps on the receiving end we knew the shaper wasn't working.

So in the end we plan on having CBWFQ inside a shaper configured for 2Mbps, with the CBWFQ using the entire bandwidth (configured to 2000 via the bandwidth command in the interface).

For the configuration at 2Mbps, we stuck with the Bc at CIR/100, i.e. it was set to 20000 (2500 bytes).

In any case I'll try setting it to 12000 and see if that makes a difference.

I was thinking about grabbing the latest Advanced IP Services IOS release. This router doesn't need SP services on it anyways.

Thanks again for the reply.

Most what you write makes sense. The lack of shaping and the shaper's counters, I agree is what's odd.

If your Bc for 2 Mbps was 2500 bytes, that likely was larger than your MTU. I.e. unlikely the 12000 will make a difference for 1 Mbps.

Were you also using max-reserve 100 with the 2 Mbps? If you were, you might try removing it and seeing what happens.

A later version 12.4, I also agree, is worth trying. (If it, or other solution, corrects the issue, try to post an update.)

PS:

You might also try a GTS (generic traffic shaper) on the interface in lieu of the policy map. Won't be useful for your end-purpose, but interesting to see if it shapes.

PPS:

Don't believe the 2000 for the interface bandwidth has any interaction with the policy map unless you use percentage based bandwidths.