7609 wrr queue-limit

[hetao]

I have some puzzles on configuration qos on 7609 with sup720-3B and 6724-SFP line card as below:

transmit queue capability for 6724-SFP: 1P/3Q/8T

question 1:

as we konw, traffic on PQ will be forwarded before other standard queue, and WRR can allocate different bandwidth to different queue. Does it mean traffic on PQ cannot be limit bandwidth? On ios command, wrr-queue bandwidth ** ** **, we can allocate bandwidth ratio to Q4, that is pq? Is my understand right?

question 2:

there is ios command: wrr queue-limit ** ** **, allocate 3 queue-limit to 3 standard queue, but i found some document say: wrr queue-limit 20 20 20, that is allocating 20% to q1, 20% to q2, 20% to q3, and left 40% to q4(pq). I cann't understand: since pq will handle strictly before other 3 standard queue, why we need leave some queue size to PQ. (PQ will be forward out of the interface without needing to enter the buffer). Am i right?

question 3:

for queue-limit ratio, who can give me some recommedation or best practice? For example, if i will allocate 25% to Q1(best effort & bronze), 25% to Q2(Silver), 30% to Q3(Golden), 20% to Q4(PQ for voice), how will i should allocate queue-limit?

Very Thanks!

[hetao]

Sorry for question 1's mistake,

On ios command, wrr-queue bandwidth ** ** **, we cannot allocate bandwidth ratio to Q4, that is pq.

Is my understand right?

[Peter Koltl]

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSDesign.html

[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 whatsoever (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

Cisco does have some bandwidth percentages recommendations in their later 11 (or is it 12) class QoS model.  But bandwidth reservations are really subject to what your traffic mix is and your service requirements.

I do have my own personal generic QoS model.  It uses 4 classes like:

policy-map Generic

class real-time

priority percent 40

class foregound

bandwidth remaining percent 81

fair-queue

class background

bandwidth remaining percent 1

fair-queue

class class-default

bandwidth remaining percent 9

fair-queue

Conceptionally, traffic that has real-time service requirements, e.g. VoIP bearer, is directed to the real-time class.  By default (laugh) everything else goes to the default class (where fair-queue proportions bandwidth per flow).  If some traffic really needs priority treatment, it's directed to the foreground class.  An example might be something like a screen scraping (e.g. Citrix, RDP) app.  (Basically traffic that wants RT like treatment, but doesn't require true RT treatment.)  Lastly, traffic that isn't in any rush and might want lots of bandwidth (e.g. server backup), is directed to the background class.  (Basically such traffic only gets a minimal guarantee, but is allowed to use any and all available bandwidth, i.e. bandwidth not otherwise needed by any more "important" traffic.)

Unfortunately, devices like 6500 LAN cards don't support FQ, so you often need to carefully distinguish what class (6500 queue) traffic should be directed to and if you push more toward the foreground class, such that it risks excessively delaying the default class, you might want to reduce its bandwidth guarantee and increase default's.