Re: hierarchical shaping versus shaping in conjunction to cbwfq posted 06/03/2006
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
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
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
to delay traffic, and hence introduces some sort of queue, to hold delayed
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:
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:
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
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.