From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Fri Mar 20 2009 - 07:50:42 ART
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.comInternetwork 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
This archive was generated by hypermail 2.1.4 : Mon Apr 06 2009 - 06:44:06 ART