priority queue on 3560

[carl_townshend]

Hi all

On a 3560

If I enable an interface for qos, trust the dscp, map it to queue set 2 and enable the priority queue

does the interface have 2 queues on it, queue 2 and also the priority queue ?

is the priority queue seperate or is it queue set 1 ?

cheers

Carl

[Jose Jara]

Hello Carl,

It will always have two input queues and four output queues. The input priority queue is queue 2 and the output priority queue is queue 1.

By default, DSCP 40 to 47 is mapped to the priority queue:

sh mls qos maps dscp-input-q

   Dscp-inputq-threshold map:

     d1 :d2    0     1     2     3     4     5     6     7     8     9

     ------------------------------------------------------------

      0 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

      1 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

      2 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

      3 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

     4 :    02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 01-01 01-01

      5 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01

      6 :    01-01 01-01 01-01 01-01

sh mls qos maps dscp-output-q

   Dscp-outputq-threshold map:

     d1 :d2    0     1     2     3     4     5     6     7     8     9

     ------------------------------------------------------------

      0 :    02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01

      1 :    02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01

      2 :    03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01

      3 :    03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01

     4 :    01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01

      5 :    04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01

      6 :    04-01 04-01 04-01 04-01

Be aware that if you enable the egress priority queue ( priority-queue out ), all the traffic coming to this queue will be dequeued before any other traffic, with the possibility of starving the rest. However, if you do not enable it, the default Shaped queue will apply with a rate limit of 4% ( 1/25) of this traffic. 

Hope this helps,

Jose.

[carl_townshend]

Hi there

these are the settings I have applied

mls qos queue-set output 2 threshold 2 3100 3100 100 3200

mls qos queue-set output 2 buffers 10 70 10 10

mls qos

on the interface

srr-queue bandwidth share 20 60 10 10

queue-set 2

priority-queue out

mls qos trust dscp

Does this look OK ?

I have noticed im not getting any output drops in queue 2 since this config now

[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

Does this look OK ? 
I have noticed im not getting any output drops in queue 2 since this config now

Look ok?  Well that depends totally on what your network traffic is like and what you're trying to accomplish although your q2 logical drop limits are way, way beyond what's possible with your other configuration settings.

As the other poster (Jose) has described, (egress) PQ can starve other egress queues from all bandwidth.  Your buffer allocations devote so much to q2, it's possible other queues could be starved for buffer resources, even PQ.

In one of your other posting (same issue?), I noted additional tuning was possible beyond the change I suggested.  What I suggested was a change that might reduce the drop rate you're were seeing but without exposing your other traffic to an extreme adverse impact.

What you've done certainly provides increased resources for q2, but what's the impact to other traffic (now or in the future)?

If all you want to do is maximize resources just for q2 traffic, why have PQ enabled, and why not just allocate almost all bandwidth and buffers to q2?  If you do need to concern yourself with traffic other than what goes to q2, you might want to devote some additional consideration to what QoS parameters you change and by how much.

[carl_townshend]

Hi there

so are you saying that the config I have could starve the priority queue? why is that, I thought PQ is always serviced first etc ?

I could do with some help to be honest on a good config, that gives the best effort traffic a large buffer, but should voice traffic come in that will always get put first

please help

cheers

Carl

[JohnTylerPearce]

The PQ is serviced, until there is nothing left in the PQ, and then it starts dequeuing the rest, is basically how that works. So if someone is made to go to the PQ, that will be constant traffic flow, then it could very well starve out other traffic.

[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

so are you saying that the config I have could starve the priority queue? why is that, I thought PQ is always serviced first etc ?

Yes, I'm saying that (i.e your config might stave the PQ).  Yes PQ is serviced first, but that means it's dequeued first.  But to be dequeued, it must first be queued and what if there are no available buffers to queue it?

A "good config", as I've tried to explain in my other posting, across your 4 (?) separate threads, can be very dependent on the what your traffic is and what you want your QoS policy to accomplish.  Really don't have enough information to know what might be "good" for your situation and QoS goals.

When you use QoS to manage congestion, it often favors some traffic at the expense to other traffic performance.  Often not all traffic is going to obtain what it "wants".

When you provide a large buffer for BE traffic, to avoid drops, you take buffer resources/guarantees from non-BE traffic which means perhaps that non-BE traffic may now have higher drops.

What your new QoS settings do is very much skew buffer resources and bandwidth toward some traffic (BE?).  Although PQ overrides the high bandwidth allocation you've provided to Q2, it doesn't (as far as I know) impact buffer resources commitments.

Is what you did "bad"?  Don't know.  It might be ideal for your needs.

Again, what I posted in one of your other threads was a suggested change to allow Q2T1 a higher logical limit (and likely access to more buffers), hopefully without being adverse to your other traffic.  Also again, as I don't know your traffic or your QoS service goals, what I suggested might be far from ideal or even "bad", but from my experience I thought it likely you would see a reduction in drops w/o a too adverse if any impact to other traffic.