Go CCIE Go!! - A Cisco Certified Internetwork Expert

Pierre,
I did not dig though all of you scenarios in depth, but it seems that you confuse some concepts here.
First, CBWFQ. This is basically good old WFQ. But at this time, we set “weights” and define “classes” ourself. So a good undestanding of WFQ is required to get how CBWFQ works, by the way.
Secondly, “bandwidth”. This is what replaces automatic weight computation of WFQ (WFQ uses flow, instead of class, and precedence to weight the flows).
Bandwidth command actually sets class’ weight for CBWFQ scheduler, and engages per-class FIFO queue in case of congestion. Sure thing, if no congestion occurs (TX-Ring is not filled up), your bandwidth setting has no effect, and does _not_ limit traffic at all.
(If you need to limit traffic flow, you need either shaper of policer)
Third thing, the shaper. Now, as you recall shaper utilizes leaky bucket algorithm to delay traffic, and hence introduces some sort of queue, to hold delayed packets.
Back in days, GTS utilizes only WFQ as queueing system. Nowdays, you may specify CBWFQ as per-shaper queue system. This is precisely what is being done when you write:
…. class X shape 128000 service-policy CBWFQ
where policy-map CBWFQ defines your queueing configuration. That is, you shape all traffic of class X to rate 128K, and apply CBWFQ queueing strategy to shapers’ queue.
So you see now, that things like:
…. class A shape 128000 bandwidth 128 ….
are rather useless, since they do _different_ things! Bandwidth specifies class weight in case of congestion, and shape limits traffic flow for class. I don’t see any practical reason to use these things together.
Also, placing shaper in class-default is the standard way to queue traffic at subinterface. That is, subinterface by default has no queue by itself, so you need to introduce one. You then put CBWFQ configuration inside shaper, and that is your queueing mechanism for subinterface.
HTH Petr