From: Pavel Bykov (slidersv@gmail.com)
Date: Tue Mar 24 2009 - 21:24:16 ART
Petr, while I completely agree with this for pre 12.4.20T behavior, in post
12.4.20T there are two changes which completely change this perception due
to two following changes:
1. You can use WFQ in any CBWFQ class, not just class-default
2. You can use bandwidth reservation together with WFQ
before WFQ was not good because it was not possible to reserve bandwidth and
at the same time use WFQ. I'm not sure how it is done now, because the
commands I used to look at immediate CBWFQ queueing state do not work
anymore.
They could augment WFQ sequence numbers with the assigned relative weight,
but I don't know...
Many many many changes in 12.4.20T+
It's like this new command in 6k5 SXI: "spanning-tree portfast network"...
what's network? no mention in any document. Sure, there are suspicions and
guesses, but no documentation/test results.
On Fri, Mar 20, 2009 at 11:50 AM, Petr Lapukhov <petr@internetworkexpert.com
> wrote:
> Malcom,
>
> I don't know all the details of your stress-test (e.g. IP precedence
> for traffic matching class-default) so I cannot make any consistent
> conclusion. However, here are my thoughts on the whole idea of using
> fair-queue. As you know, all classes under CBWFQ policy that have
> manual weight assigned (via the bandwidth statement) are treated
> in the way similar to WFQ "RSVP reserved" flows. Any traffic matching
> class-default with fair-queue configured, will have dynamic queue created,
> with the scheduling weight based on flow's IP precedence marking.
>
> Every dynamic WFQ flow's weight is always much less preferred by the
> scheduler,
> than any "manually configured" class. Thus, in situations where you have
> traffic matching class-default with WFQ, all manual classes will have
> preference and get the guaranteed bandwidth.
>
> You can read more about weight computations for CBWFQ here:
>
> http://blog.internetworkexpert.com/2008/08/17/insights-on-cbwfq/
>
> The drawback of using WFQ is that it does not scale for high-speed
> interfaces.
> Basically, if your inteface (or shaper) rate is above 2Mbs you probably
> don't want to configure WFQ inside class-default. Configure this class with
> a low bandwidth value, if you dont want it to compete with other classes.
>
> As for control plane traffic. You may want to read the following article:
>
>
> http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094612.shtml
>
> Basically, with WFQ enabled, some control plane traffic (e.g. keepalives)
> will be mapped
> to special link WFQ queues (reserved). This is OK in most situations,
> since those queues
> have relatively "good" weights. BGP connections will be scheduled via WFQ
> using
> the dynamic queue with the weight corresponding to IP precedence of 6.
> When you have
> other non-default classes, BGP connections might starve. Thus, you may
> want to create
> a special class for control-plane traffic marked with CS6 and assign
> static weight to it.
> This will result in better performance and prevent queue starvation.
>
> Thus the conclusion is: Avoid using WFQ for class-default, unless you
> really dont care
> for this traffic :) This will put additional load on the scheduler in case
> if there are
> many flows matching class default. Create a separate class matching
> control-plane traffic
> and guarantee it some bandwidth.
>
> It would be good to see the results of your experiments. QoS is an
> interesting topic,
> and I always try to learn more about it :)
>
> HTH
> --
> Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice)
> petr@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> ----- Original Message -----
> From: "Malcom Sargla" <msargla@rim.com>
> Sent: Thu, March 19, 2009 19:32
> Subject:WFQ vs CBWFQ for class Class-Default
>
> Dear Folks,
>
> We are currently testing qos extensively in our lab and I'm at the point
> now where I'm trying to decide to use fair-queuing or cbwfq for class
> Class-default.
>
> To expand, we've done our homework to create efficient class-maps and
> respective acl's so Class-default should never really see any traffic
> once we go live with our policy. However, under testing we wanted to
> traffic stress class-default in order to understand the true behavior of
> qos as a whole.
>
> We found under a traffic saturation test ( where all 4 classes were
> stressed) that when fair-queue is applied to Class-default that it
> actually consumes about 3% more traffic then we expected it would.
> However when I fix bandwidth percent X and random-detect on
> class-default it consumes approximately the remaining bandwidth and does
> not grow into another class.
>
> Question - Opinion's
>
> - What would be the pro's or con's of using CBWFQ with
> bandwidth percent and random detect over WFQ? I know WFQ provides
> another level of intelligence in deciding how to queue packets and
> provide fairness but I don't think we need it. On the other hand CBWFQ
> only considers 'bandwidth percent' as a weight when deciding to how to
> divide additional bandwidth so I'm not sure if fixing a percentage to
> Class-default is a good idea, particularly if we have other, more
> important classes that we would like to dynamically grow if under times
> of congestion. Essentially I don't want class-default to have the
> lion's share of bw over another defined class.
>
> - Secondly, CS6 router traffic - my understanding is that
> pak-priority is given to -all- igp routing protocols by default on most
> new ios - pak-priority (cs6) traffic is essentially treated similarly to
> llq traffic in that it is forwarded to the tx ring before all other
> traffic. However, pak-priority does not apply to BGP - how do most
> people handle this? Set up an access-list, class, and set CS6 or is
> there another preferred configuration to prioritize BGP routing updates
> when peering with an external neighbour?
>
> Thank you very much in advance,
>
>
>
> Malcom.
>
>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your
> system. Use, dissemination, distribution, or reproduction of this
> transmission
> by unintended recipients is not authorized and may be unlawful.
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
> ----- End of original message -----
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- Pavel Bykov ---------------- Don't forget to help stopping the braindumps, use of which reduces value of your certifications. Sign the petition at http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Apr 06 2009 - 06:44:07 ART