cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
687
Views
5
Helpful
4
Replies

QOS - CBWFQ - bandwidth and priority

SJ K
Contributor
Contributor

Hi

 

I understand the priority queue but i want to understand further on the remaining queues and how to prioritize them

 

 

For CBWFQ, which extends the standard WFQ fair queueing, the weight specified for the class becomes the weight of each packet that meets the match criteria of the class. Packets that arrive at the output interface are classified according to the match criteria filters you define, then each one is assigned the appropriate weight. The weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it; in this sense the weight for a class is user-configurable. 

The weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it; in this sense the weight for a class is user-configurable.

 

q1) does this means the more bandwidth allocated to the class, the more weight and priority it has to be de-queue earlier ?

 

q2) what if i have some traffic that are of higher priority but does not required that much of bandwidth ?

 

q3) i have some udp heartbeat packets that are of great importance and cannot tolerate any drops - is allocating them to the LLQ/priority queue the only option ?  the rest of the classes/queues seems to have WRED configured

 

Thank you

 

4 Replies 4

Leonid Voronkin
Collaborator
Collaborator

1) CBWFQ it is a fair queue. The weight does not affect to order of queuing

2) You should use LLQ

3) Usually for this purpose CS7 is used

 

If you want to better understand QoS you should watch this presentation from cisco live.

https://www.ciscolive.com/global/on-demand-library.html?search=qos%20ios%20xe&search=qos+ios+xe#/session/1509501648736001PWvg

I think you will find a lot of interesting things there

_____________________________________________________________

If you like the answer, put an asterisk. If the answer helped solve your problem, approve it as a solution

 

________________________________________________________
Если ответ понравился, ставь звёздочку. Если ответ помог решить твою проблему, утверди его в качестве решения

Hi Leonid

 

I thought CBWFQ is using Weighted Round Robin ?  In CBWFQ - what does the weight do then ? Does it affect how often the queue is service ? As in higher weight = higher chance to get service/dequeue ?

 

Thanks

(Sorry for what appears to be a tardy reply.  I thought I posted this, concurrently with my other posting, but found it only, now, just "saved".)

 

1) CBWFQ it is a fair queue. The weight does not affect to order of queuing

Could you please further explain that?  Perhaps you're thinking of FQ within a class, which since HQF, is FQ although prior to HQF, it was WFQ.

2) You should use LLQ

Not knowing how else LLQ is being used, or might be used in the future, "should" might be too strong a recommendation.

3) Usually for this purpose CS7 is used

Could you please provide some references for this usage?  Reason I ask, CS7, and the prior/overlapping IPPrec 7, have traditionally used that marking for network operation control (of the network itself).

Joseph W. Doherty
Hall of Fame Master Hall of Fame Master
Hall of Fame Master

q1) does this means the more bandwidth allocated to the class, the more weight and priority it has to be de-queue earlier ?

Yes and no. A class with a higher bandwidth guarantee, and a better "weight", all else being equal, will be dequeued more often, but that classes packets don't really have "priority" over the other class with the worst "weight".

For example, these two policies, as exactly configured, should provide the same dequeuing results:

policy-map LLQ1
class Foreground
priority percent 10
class class-default
bandwidth percent 90

policy-map LLQ2
class Foreground
priority percent 10
class class-default
bandwidth percent 1

but given the policy:

policy-map no-LLQ1
class Foreground
bandwidth percent 99
class class-default
bandwidth percent 1

This latter policy should provide results much like the two LLQ policies, but perhaps not exaclty the same. (Also, the LLQ classes have an implicit policer, which I've ignoring. Here I'm just concerned with dequeuing prioryites.)

Further if we had policies like (which appear more similar to the two LLQ policies):

policy-map no-LLQ2
class Foreground
bandwidth percent 10
class class-default
bandwidth percent 90

policy-map no-LLQ3
class Foreground
bandwidth percent 10
class class-default
bandwidth percent 1

They are quite different from the LLQ policies, and each other. If this is still a bit unclear, dequeuing ratios, for all these polices would be:

LLQ1: absolute priority:doesn't-matter
LLQ2: absolute priority:doesn't-matter
no-LLQ1: 99:1
no-LLQ2: 1:9
no-LLQ3: 10:1

q2) what if i have some traffic that are of higher priority but does not required that much of bandwidth ?

You might place such into LLQ (and the latter CBWFQ implementations now offer two levels within LLQ), or you need policies, with this traffic in the "Foreground" class, more like no-LLQ1 or no-LLQ3, NOT no-LLQ2.

BTW, a common example of such traffic being sent to LLQ, when it doesn't really need LLQ, would be VoIP control traffic. However, it doesn't so much need LLQ's low latency but insurance it's not dropped.

q3) i have some udp heartbeat packets that are of great importance and cannot tolerate any drops - is allocating them to the LLQ/priority queue the only option ? the rest of the classes/queues seems to have WRED configured

No, LLQ isn't the only option, see answer to q2. Also if using a CBWFQ with LLQ levels, you might place them there, but in the 2nd level. (NB: I believe the intent of 2nd level LLQ is really for real-time video.)

Further, if they are in a class with WRED (which I very, very strongly recommend against using, unless you're QoS wizard - class FQ is often much, much better choice), if distinctly tagged, you could set WRED parameters to (hopefully) not drop those UDP packets (latency/jitter different issue).

BTW, here's my handy-dandy, only four class, QoS policy (which effectively deals with most QoS needs):

policy-map General
class real-time
priority percent 35
class Foreground
bandwidth remaining percent 81
fair-queue
class Background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue

For usage, traffic that really needs priority, provide best latency/jitter (e.g. VoIP bearer), is directed to the "real-time" class.

All other traffic, by default, goes to "class-default", where FQ, usually, keeps heavy bandwidth flows from being adverse to light bandwidth flows.

(BTW, sometimes I demonstrate the "power" of FQ by first opening a telnet session across a link. Then I slam multiple UDP traffic generated flows across that link, filling it. [Often I generate more than 100% of link's capacity in UDP test flow bandwidth.] The telnet session becomes about totally useless. Then I enable FQ. Then telnet starts working almost like there's no UDP test traffic.)

If you have some light bandwidth usage traffic that really, really (really) needs priority (but not LLQ level), and/or is really critical, but FQ isn't working well enough (and there are some possible cases with Cisco's FQ), you direct that traffic to the "Foreground" class.

If you have some heavy bandwidth usage traffic, that will work okay with "left over" bandwidth (e.g. large bulk TCP data transfers), you direct that traffic to "Background" class.

In theory, the Foreground and Background classes could work w/o FQ, because in the former, there shouldn't be much, if any queuing, and in the latter, the traffic flow(s) shouldn't "care" about optimal performance.  Yet, I still recommend FQ for those classes too.  Why?  In the former, just in case there are multiple flows and there's congestion.  In the latter, it "just works better" (w/o me describing why).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers