11-01-2014 12:56 AM - edited 03-07-2019 09:20 PM
Hi all,
I have a question on priority queueing.
When enabling 'priority-queue out' all traffic that belongs to queue 1 will be send out immediately, before the other queues.
This has a risk of letting the other queues starve, if traffic for queue 1 is to extensive.
therefore it is probably best to rate limit traffic belonging to queue 1.
Sometimes you see something like this:
interface gigabitethernet 1/0/1
srr-queue bandwidth share 1 60 30 10
srr-queue bandwidth shape 25 0 0 0
priority-queue out
the 'srr-queue bandwidth shape 25 0 0 0' entry in the example above both limits and reserves at the same time 1/25 of the interface bandwidth for queue 1, correct?
But this does not make sense in combination with priority-queue, right?
In the manuals they say that once 'priority-queue out' has been enabled, the values for queue 1 for the 'srr-queue bandwidth share' and 'srr-queue bandwidth shape' are discarded.
So basicaly the 'srr-queue bandwidth shape 25 0 0 0' entry is useless?
Sometimes you see this:
policy-map MY-QOS
class VOICE
set ip dscp 46
police 128000 8000 exceed-action drop
This polices priority traffic to 128k, but this is inbound, correct?
so It won't prevent the priority queue from starving the other queues (outbound)?
Since priority traffic can come from somewhere where it is not policed.
So how can we prevent the outbound priority queue from starving the other queues?
Thanks for your input
Solved! Go to Solution.
11-04-2014 01:47 PM
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
My understanding, is like yours, i.e. PQ (unlike LLQ) can stave lower classes.
So, what can you do?
Well, first, know what traffic you allow into PQ, such that (hopefully) it won't consume all the port's bandwidth.
Or, don't use PQ, just use SRR. With the latter, you can set SRR weight to give Q1 very high relative priority (to give it nearly PQ treatment) but then you could also shape it; if needed. (Even if you don't shape it, SRR wouldn't allow total bandwidth starvation.)
e.g.
srr-queue bandwidth share 255 6 3 1
11-04-2014 12:41 PM
Hi all,
Does someone have some input on this?
Thanks!
11-04-2014 01:47 PM
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
My understanding, is like yours, i.e. PQ (unlike LLQ) can stave lower classes.
So, what can you do?
Well, first, know what traffic you allow into PQ, such that (hopefully) it won't consume all the port's bandwidth.
Or, don't use PQ, just use SRR. With the latter, you can set SRR weight to give Q1 very high relative priority (to give it nearly PQ treatment) but then you could also shape it; if needed. (Even if you don't shape it, SRR wouldn't allow total bandwidth starvation.)
e.g.
srr-queue bandwidth share 255 6 3 1
11-04-2014 10:50 PM
Thanks for your reaction Joseph, I wanted to be shure about this before implmenting our QoS design.
03-21-2018 02:24 PM
This is a fantastic answer. It got me thinking and I went and redid my switches because I don't like the "priority-queue out" possibility of starvation.
I set it up like this:
no priority-queue out
srr-queue bandwidth shape 2 0 0 0
This sets the first queue to 50% (1/2) of all the bandwidth, and the remaining queues combined will be given the other 50% of the possible bandwidth. I'm pretty sure that if the first queue is empty, the shared bandwidth can consume 100% of all the bandwidth, but I'll let you know if my max speeds drop in half.
This is almost like configuring "priority-queue out limit 50%", if you will, so the 1st queue would only be able to consume half the bandwidth if there was a DoS attack on it.
Also, as a side note, I found that you cannot configure the shape above a combined value of 1.0. For example:
srr-queue bandwidth shape 1 0 0 0
The total bandwidth exceeds 1, Please choose new value
This error occurs because the first queue uses 100% (1/1) leaving 0% left over for the shared queues.
Same with this:
srr-queue bandwidth shape 2 2 0 0
The total bandwidth exceeds 1, Please choose new value
The first queue uses 50% (1/2), the second queue uses 50% (1/2), leaving 0% left for the shared queues.
So apparently the shape command has two safety checks. First, it will not let you configure more than 100%, and second, it will not let you leave the shared queue with 0% unless you configure all four queues as shaping. For example, the following works:
srr-queue bandwidth shape 4 4 4 4
This sets all queues evenly at 25% each. This of course leaves 0% for the shared queues, but we didn't define any shared queues (by setting them to 0), so this is ok.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide