ASR 1001 - QoS - How to allow queues to burst

[joerggrau]

I am running a number of ASR1001s running 15.1(1)S.  I have QoS setup but see drops in some of the queues from time to time.  I know we have the bandwidth to accommodate the traffic.  There has to be a way to allow the queues to go beyond their bandwidth limitations if there is bandwidth available.

Here is the current config:

!

class-map match-any Node-AF31

match ip dscp af31

match access-group name U-AF31

class-map match-any Node-AF21

match ip dscp af21

match access-group name U-AF21

class-map match-any Node-Voice

match ip dscp ef

!

policy-map DM_QoS

class Node-Voice

  priority 35000

  set dscp ef

class Node-AF31

  bandwidth 20000

  set dscp af31

class Node-AF21

  bandwidth 15000

  set dscp af21

class class-default

  set dscp default

policy-map QOS-PARENT

class class-default

  shape average 70000000

  service-policy DM_QoS

!

!

int g0/0/0.1

service-policy output QOS-PARENT

How can I allow the queues to go beyond the bandwidth limits put on them?

Thanks

Joerg

[paul driver]

Hello

The Bandwidth XXX - actual value to be assigned to that class regardless of any increase in link BW -

Bandwidth percent - % of whatever the link bw is - this will incrrease as the link BW increases.

Bandwidth remaining percent = the remaining amount of BW available - meaning it will get its % vaule of any remaining available BW

Also by default class class-default automatically gets 25% of defined BW for routing process etc which can be a bit to high is you have a large BW value set on the outgoing interface - this can be changed  by the max-reserved-bandwidth command which would allow this extra BW to be shared between the other classes.

int g0/0/0.1

service-policy output QOS-PARENT

max-reserved-bandwidth 95

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[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

Also by default class class-default automatically gets 25% of defined BW for routing process etc which can be a bit to high is you have a large BW value set on the outgoing interface - this can be changed  by the max-reserved-bandwidth command which would allow this extra BW to be shared between the other classes.

Actually, in pre-HQF CBWFQ, by default you're unable to define more than 75% of bandwidth to named classes without using the max-reserved-bandwidth command.  So in the pre-HQF variant of CBWFQ, class-default class should by default have at least, but may have more (if other classes didn't allocation the full 75%) than, a 25% bandwidth guarantee.  However, also keep in mind, regardless of bandwidth allocations unused bandwidth is available to other classes.  I.e. bandwidth settings (excluding LLQ) set a guarantee minimum, not a maximum.

You can juggle bandwidth allocations per class to reduce drop rates of some classes when there's bandwidth competition between classes.  However, doing this often leads to increased drop rates for other classes as you're basically taking bandwidth from one class (or classes) and providing it to another class (or classes).

[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

I know we have the bandwidth to accommodate the traffic.  There has to be a way to allow the queues to go beyond their bandwidth limitations if there is bandwidth available.

If there was short term available bandwidth, your traffic wouldn't queue.  If you do have long term available bandwidth, you just need to increase your queue limits so the short term bursts don't overflow their queues while they drain over the long term.  (NB:  Of course, when you increase queue depths you also often increase latency and you might encourage rate adaptive flows to try to go beyond currently available bandwidth.)