Re: CBWFQ Congestion Allocations

hi Matt,
   I found this doc by Petr Lapukhov very useful.

http://blog.ine.com/2008/08/17/insights-on-cbwfq/

Fabian

On Tue, Sep 21, 2010 at 4:38 PM, Babatunde Sanda <sbabatunde1_at_ca.rr.com>wrote:

> Matt,
> Consider this a crash course.
> When you use the "Priority" command under a class you have moved into what
> is known as LLQ (Low latency queue). Without you specifying this command
> you are basically configuring "CBWFQ".
> I will be dissecting your examples as much as I can for this explanation.
> Remember "WHEN THERE IS NO CONGESTION THERE IS NO QUEUING".
>
> class TEST1
> priority percent 15
>
> (This is a way of policing and guaranteeing bandwidth within a class. Take
> it as saying this classs will receive the first and only 15 percent of
> available bandwidth if congestion happens. This means it will be cut off
> bandwidth usage as soon as it gets the 15%)
>
>
> class TEST2
> bandwidth percent 30
>
> (This means this class will get a minimum of 30% of available bandwidth.
> The key word here is "Minimum". This basically means this class will get
> more if it is available)
>
> class TEST3
> bandwidth percent 30
>
> (This means this class will get a minimum of 30% of available bandwidth.
> The key word here is "Minimum". This basically means this class will get
> more if it is available)
>
>
> class class-default
> fair-queue
> random-detect
>
> (The "class default" is what matches any other traffic not defined by you.
> And it is there by default. When you say "fair-queue" this is going to
> listen to the lower talkers over the higher talkers. Say ftp and SQL are
> used for explaining this. Assume SQL traffic is coming to the router more
> than FTP. Because you have fair queue configured instead of the default
> "RED" (tail drop) under here, for every time the FTP decides to send
> anything the router will listen and attend to it because it initially was
> granting more bandwidth to SQL because SQL was the higher talker (I hope
> you
> understand what am getting at.) Maybe someone else can throw more light on
> this if need be.
>
> In addition to you using "Fair-queue", you have also told the router to use
> "fair-queue" on the basis of "IP-precedence" (layer two classification).
> What this means is "I the router will listen to lower talkers but still
> use
> 0-7 classification to do this. "I would personally use dscp here instead
> of
> the default IP-Precedence". You ask why, I have more possibilities for
> marking 0-63, dscp is also a layer 3 marking so I wouldn't worry about
> losing my markings when the traffic leaves my hop (router).
>
> Now CISCO is known for telling us about best practices. But they still
> give
> us the gun to shot ourselves in the foot. That is the way I see
> "max-reserved-bandwidth". On an interface by default 25% is reserved.
> This
> is used for lots of other stuffs the router does i.e routing protocols,
> communication between devices etc.
> So you see you technically cannot use more than 75% of an interface. But
> guess what if you decide to shoot yourself in the foot you can go under the
> interface and use the command "max-reserved-bandwidth" to change the
> default
> 25% to whatever you want and end up starving other critical traffics.
>
> Hope my ranting helped a little.
>
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Matt
> Bentley
> Sent: Tuesday, September 21, 2010 10:33 AM
> To: Cisco certification
> Subject: CBWFQ Congestion Allocations
>
> Hi GS:
>
> Question about the exact behaviors of CBWFQ.
>
> Say you have this policy-map:
>
> class TEST1
> priority percent 15
> class TEST2
> bandwidth percent 30
> class TEST3
> bandwidth percent 30
> class class-default
> fair-queue
> random-detect
>
> So I understand the following:
>
> TEST1 no congestion -> EF treatment for up to 15%, Can send up to line rate
> with normal treatment (assuming none of the other classes are sending)
>
> TEST1 congestion -> LLQ treatment for up to 15%, policed for greater than
> 15%
>
> TEST2 no congestion -> Can Send Up To Line Rate (assuming none of the other
> classes are sending)
>
> TEST2 congestion -> AF treatment for up to 30%, excess ????
>
> TEST3 no congestion -> Can Send Up To Line Rate (assuming none of the other
> classes are sending)
>
> TEST3 congestion -> AF treatment for up to 30%, excess ????
>
> For TEST2/TEST3 congestion scenario, I see this statement from Cisco
>
>
> http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080
> 103eae.shtml<http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080%0A103eae.shtml>
>
> If class-default does not need it, the unused bandwidth is available for
> use
> by class TEST1 and class TEST2 (they use different names for their
> classes).
> If both classes need the bandwidth, they share it in proportion to the
> configured rates. In this configuration, the sharing ratio is 30:30 or 1:1
>
>
> Instead of trying to word my questions, if someone could elaborate the
> allocations in the following scenarios, it would be immensely helpful.
>
>
> 1) Scenario#1
> TEST1 is sending traffic at exactly at 100% of line rate
> TEST2 is sending traffic at exactly at 100% of line rate
> TEST3 is sending traffic at exactly at 100% of line rate class-default is
> sending traffic at exactly 100% of line rate
>
> How is the bandwidth going to be allocated between them?
>
> 2) Scenario#2
> TEST1 is sending traffic at exactly at 15% of line rate
> TEST2 is sending traffic at exactly at 42.5% of line rate
> TEST3 is sending traffic at exactly at 42.5% of line rate class-default is
> sending traffic at exactly 50% of line rate
>
> How is the bandwidth going to be allocated between them?
>
> Also, I don't think the max-reserved-bandwidth assists in determining how
> much bandwidth the default class gets when congestion occurs, but not sure?
>
> Thanks very much,
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Regards,
Fabian Pucciarelli
Blogs and organic groups at http://www.ccie.net