Nested QoS policy oddities

[John Blakley]

All,

We had a situation where we noticed we were getting 11mb on a medium queue. We have nested policies, and it wasn't making sense. Here are the two policies:

policy-map AVPN
class SEP
shape average 2500000
class ALTIRISBLOCK
shape average 5000000
class SCANS
shape average 1024000
class class-default
shape average 100000000
bandwidth 90000
service-policy COS

policy-map COS
class HIGH
priority 6000
set ip dscp ef
class MEDIUM
bandwidth remaining percent 60
set ip dscp af31
service-policy MARK-BGP
class LOW
bandwidth remaining percent 15
set ip dscp af21
class class-default
bandwidth remaining percent 5
set ip dscp default


Here is the weirdness. I've always been under the impression that the policy would base its calculation on the bandwidth of an interface. The interface in question is 100Mb and had the bandwidth statement configured as such. The MEDIUM class above was allocating 11.4mb after it did whatever calculation it needed to do, but it should have allocated about 50mb. We only had the shaping config and the service policy on the class-default. Being that this wasn't correct, we put a TAC case in since this was a newly upgraded router to version 15.1. Okay, long story short, the TAC engineer had to lab it up and he wasn't seeing the same result. His fix was to add the bandwidth statement under the AVPN policy class-default. This absolutely fixed the issue, now I'm trying to figure out why.

My question is this. Does the interface bandwidth command ONLY affect the parent policy? It seems that way, and the embedded policy-map seems to run off of the bandwidth statement in the class default. I've not heard this anywhere, so I'm wanting to clarify if this is the way it is designed to work, or if this was a successful hack of sorts.

Thanks!
John

*** Please rate all useful posts ***

[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

John, only Cisco can tell us how it's supposed to work, but there are some major differences in capabilities for CBWFQ pre-HQF and post-HQF, some behaviors (annoyingly) differ with the exact same policy.  Was the earlier IOS version pre-HQF?  (There are also some subtle behavior differences with 15.x - bug fixes.)  I do recall some of the features of post-HQF CBWFQ concerned bandwidth inheritance.

Additionally, whether pre- or post- HQF (or pre- or post- 15.x), your parent policy's classes didn't use bandwidths.  So, without an explicit bandwidth declaration, how does (or should) CBWFQ treat your different classes?  In other words, without an explicit declaration, you're depending on some inherent or default behavior of CBWFQ.  As this behavior, I don't recall, being documented (at all?), I'm not surprised such behavior changes with a newer IOS.

Besides, perhaps, default behaviors changing, shaping (or policing) within a class and its bandwidth are not implicitly related, so I might have:

class x

bandwidth percent 50

shape average

vs.

class x

bandwidth percent 90

shape average

or

class x

bandwidth percent 9

shape average

I'm sure the 1st, above, makes sense, but if the 2nd and 3rd example make sense too (and their expected behaviors), you'll understand why leaving bandwidth off exposes our CBWFQ policy to IOS version dependent behavior.

[John Blakley]

Thanks Joseph for the response. So, what I've been playing with this morning on 12.4 code is the same thing and I do get a different response (it shows the correct calculations without the bandwidth statement and using nested policies). I'm wondering if the 12.4(25) code that I was on before worked before we upgraded to 15. So, I'm thinking that with newer code, 15.X, the bandwidth remaing percent isn't inheriting from the interface at all, or at least not correctly, if there are any classes in the parent policy. I'd like to remove the classes from the parent policy, put them under the child policy, and then configure the shaper on the class default to see what the outcome is.

Do you think it's good practice to use nested policies at all if we have this limitation of needing to add the bandwidth statement to the default class for it to calculate correctly? My thought is that if we need to make a change to the parent policy, we'll have to make adjustments to bandwidth statement to correctly identify what's available to the child policy.

Thanks!

John

[Joseph W. Doherty · Accepted solution]

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

12.4(24) is pre-HQF (HQF was with 12.4(20)T.) so that may account for some of the behavior differences you're seeing.

Do you think it's good practice to use nested policies at all if we have this limitation of needing to add the bandwidth statement to the default class for it to calculate correctly?

I think the bandwidth statement should always be used, so you know explicitly what the expected behavior should be.  (In you original posting, without research and/or testing, I'm not sure what your defined policy's behavior will be.)

PS:

BTW I would recommend against using a policy like yours without very good reason.  Bandwidth statements control prioritization ratios.  So, if I have only two active classes, and there's available bandwidth, why shape individual classes precluding them from not using the available excess bandwidth when I can still prioritize between them?

[John Blakley]

Thanks again Joseph. Those two classes that you're seeing are us trying to control some Altiris and SEP traffic so it doesn't take up the whole bandwidth which we've seen it do in the past.

[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

Those two classes that you're seeing are us trying to control some Altiris and SEP traffic so it doesn't take up the whole bandwidth which we've seen it do in the past.

Ok, but is it really bad for them to consume all the bandwidth if it's otherwise being unused?  (Of course, if you being paying for tiered bandwidth rates, then I can see a reason to hold their usage.)