From: Pierre-Alex (paguanel@hotmail.com)
Date: Sat Jun 03 2006 - 13:25:36 ART
Petr,
Sorry point 3) did not make it in my previous e-mail:
When you say:
"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."
I do not see the relationship between the class-default and the ability to
create a new queue.
Can you please elaborate?
Thanks
Pierre
----- Original Message -----
From: Pierre-Alex
To: Petr Lapukhov
Cc: ccielab@groupstudy.com
Sent: Saturday, June 03, 2006 6:16 PM
Subject: Re: hierarchical shaping versus shaping in conjunction to cbwfq
Petr,
Thank you for the reply, but I do not understand the point about the
configuration being meaningless: shaping does introduce a point of congestion,
doesn't it?
I would interpret the config bellow as follows:
" class A
shape 128000
bandwidth 128
class B
shape 64000
bandwidth 64
Introduce a point of congestion at 128000 for Class A, then if shapping is
activated, allocate 128 K of the total bandwidth of the interface to class A.
Introduce a point of congestion at 64000 for Class A, then if shapping is
activated, allocate 64 K of the total bandwidth of the interface to class
B.
2) Woud that then mean that the CCO example is incorrect?
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqo
s_c/fqcprt4/qcfcbshp.htm#wp1002798
3)
Thanks for your help
Pierre
----- Original Message -----
From: Petr Lapukhov
To: Pierre-Alex
Cc: ccielab@groupstudy.com
Sent: Saturday, June 03, 2006 5:50 PM
Subject: Re: hierarchical shaping versus shaping in conjunction to cbwfq
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
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:31 ART