06-14-2013 08:32 AM - edited 03-04-2019 08:12 PM
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
06-14-2013 09:04 AM
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.
06-14-2013 09:40 AM
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).
06-14-2013 09:26 AM
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.)
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