WRR vs CBWFQ

[Hari Vishnu]

Hi All,

Can any body describe the use case differences between CBWFQ and WRR. ? I guess using CBWFQ we can create software queues. On other hand WSS allows us to use the existing hardware queue. Sorry, I'm novice in QOS. Can any one please help.

I have also seen WSS used in 6500's.. Does 6500 not support CBWFQ. Is it only for routers ?

Thanks

[Francesco Molino]

Hi 

I will try to answer simply add there is a lot of documentation on Cisco website.

WRR is based on weight with 4 configurable queues. This is most access switches who work with this feature. You also have it on old supervisor card on 6500. 

The goal is to affect COS/DSCP values on different queues and set the weight for each and activate the priority queue.

CBWFQ: you can define more precisely your qos (bandwidth, policing,...) as it is based on class-map. That means you can create acls to clarify a very specific traffic and apply a configuration, in the same Vlan create another acl for another type of traffic and define another rule  and so forth... While with WRR you work with cos/dwith and queues.

CBWFQ is more user defined qos and It is working on routers, catalyst switches,....

Again if it's a very simplified explanation. To be more technical I recommend to Cisco documentations.

Thanks, hope that answered your question.

PS: Please don't forget to rate and mark as correct answer if this answered your question 

[Hari Vishnu]

Thanks. Just to be clear. Are you suggesting that WRR and CBWFQ are used for same purpose ?

CBWFQ is newer and have more features and WRR is used on old 6500's.

Also we can use CBWFQ on switches aswell  ?

Thanks

Hari

[Francesco Molino]

There aren't exactly the same. One is managing only queue and the other is more for user defined traffic.

Yes actual switches (ex: catalyst 3750) can be configured to use both.

How this is more clear.

Thanks 

PS: Please don't forget to rate and mark as correct answer if this solved your issue 

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

First, understand, QoS features could be implement in hardware, software or some combination.  Hardware implementations provide "speed" but they tend to be more costly.  So, hardware QoS is often feature poor compared to software QoS.

Second, understand, the need for QoS, and the features supported for QoS, has evolved over the years.  When looking at hardware QoS, you'll often fine hardware QoS is "locked" to the original design, where software based isn't.

Can any body describe the use case differences between CBWFQ and WRR

Perhaps, but much depends on what you want to consider as cases.  Both allow you to deal with congestion.  How they can deal with congestion varies.  Cisco has lots of material, on their main web site, that discusses both.

Does 6500 not support CBWFQ. Is it only for routers ?

Hmm, the 6500 might support CBWFQ (of close to it) on its FlexWAN cards.

CBWFQ doesn't have to be restricted to routers (some "routers", such as the 7600s series, have support issues with it too), but full CBWFQ implementations would be difficult and/or expensive to fully support with hardware.  Hardware would also make difficult to enhance hardware only CBWFQ without new hardware.

[Hari Vishnu]

Thanks very much  for clarification. Couple of questions.

1) I understand that Hardware QOS (WRR) will be wire speed and faster option. So that should be always the fist choice right ? You mentioned it will be costly..Can you please brief why you suggested that ? Can you also mention any case where you will choose CBWFQ over WRR (if both are supported in a platform) (any specific eg will be great)

2)  Other question is direction of QOS. If below is my sample network topology..

Edge -  core - Transit - Internet.

Should I apply QOS upstream (ie from Edge to Core and..) or downstream (core to edge...)

many thanks in advance..

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I understand that Hardware QOS (WRR) will be wire speed and faster option. So that should be always the fist choice right ?

You often (or always?) don't have a choice.  Software QoS can be done at wirespeed too, it's more a question of overall capacity.

You mentioned it will be costly..Can you please brief why you suggested that ?

It's costly and/or difficult to implement all the features found CBWFQ.

Should I apply QOS upstream (ie from Edge to Core and..) or downstream (core to edge...)

By the book, you apply it everywhere.  However, you might start with bottlenecks, especially if they are congested and the congestion is such that it;s adverse to your traffic.

Often, common bottleneck are the LAN to WAN handoffs, as the latter often has much less bandwidth to offer than the former.