WAN QOS child shape exceeds parent

highittech · ‎06-19-2016

I stumbled upon a configuration that I did not think was supported but the router accepts it. In a three tiered egress QOS policy the child shape values exceed that of the parent. My understanding is the child policies will shape, prioritize, and drop independent of each other but ultimately the parent has to shape down to 10 Mbps. When the parent is oversubscribed in this way, what happens when the child policies exceed the parent CIR?

If I recall correctly the drop rate of the parent matched exactly that of the childs drop rate added together. So it doesn't seem like the parent is making drop decisions on its own.

Sample configuration:
policy-map Parent
class class-default
shape average 10M

service-policy tunnel-policy

!
policy-map tunnel-policy
class Tunnel1
   shape average 10M
   service-policy default-queue-policy
class Tunnel2
   shape average 10M
   service-policy default-queue-policy
class Tunnel3
   shape average 10M
   service-policy default-queue-policy

!

policy-map default-queue-policy
class VoIP
   priority level 1
class Video
   priority level 2
class class-default
   queue-limit 1024 packets
   random-detect dscp X X X...

Philip D'Ath · ‎06-19-2016

I don't believe this is a valid configuration. Probably just lucky that the IOS version accepted it.

Joseph W. Doherty · ‎06-20-2016

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 wha2tsoever (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

Logically, you're child shapers shouldn't shape, as each is the same as the parent's shaper.

Now if the child shaper's were, for example, each 4M, logically then, policy-map tunnel-policy should never see bandwidth more than 10M (because of the parent's shaper), but an individual tunnel-policy class's shaper would restrict its class to 4M, and if it does, that congestion should be managed by the default-queue-policy. (With each tunnel-policy class shaping at 4M, only two of the three classes might be shaping the parent's 10M.)

BTW, does a policy like what I just described, above, make sense? It can. Suppose the main interface had more physical bandwidth then its overall CIR, and further suppose, remote site's (per tunnel) interface had even less bandwidth. So, such a three tier policy, as above, would insure the local interface's CIR isn't exceeded and it would also insure remote interfaces bandwidth wasn't exceeded. However, the policy I described wouldn't always guarantee VoIP and/or Video had priority. For example, suppose the three tunnel-policy classes has directed to them 3.5M, each. Or suppose, only 5M was directed to the parent policy.

highittech · ‎06-20-2016

The policy you described makes perfect sense and I can see the use case. However, I still do not understand what happens when the collection of child policies attempt to exceed the parent's CIR. Logically it should not be possible to exceed 10 Mbps so the parent has to make a decision to 1) queue the packet or 2) drop the packet. In my example, there is a 3:1 over subscription and each child promises 10 Mbps to their class of traffic. If the child is not making the queuing and congestion avoidance decisions what is?

My assumption is the collection of child policies should never exceed the parent CIR?

Joseph W. Doherty · ‎06-20-2016

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 wha2tsoever (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

Logically, you child policies should never see more than the amount of the traffic being shaped by the parent. I.e. queuing/shaping starts with the top policy.

So, the most traffic your tunnel-policy should ever see is 10M. That could be just for one class, 2 classes or all 3 classes (or actually all 4, as there's always a default class, implicit when not explicitly defined).

Let's say 40M was directed to just tunnel 1. Parent's shape should provide 10M to tunnel 1. What happens to the other 30M? I believe it's dropped by Parent's shaper. I.e. tunnel 1 never "sees" the other 30M. Then as your tunnel 1's shaper is configured for 10M too, effectively there's not congestion for default-queue-policy to manage.