Queue Limit - parent/child policy

[scottmanzie1]

Hi

Trying to understand the queue limit when using a parent/child policy

So Parent shaping the overall traffic and child doing the QOS

For example

In a config like this

policy-map PARENT
class class-default
shape average 17683258
service-policy CHILD

policy-map CHILD
!
class VOICE
  police 5200000 12000 12000 conform-action set-dscp-transmit ef exceed-action set-dscp-transmit ef violate-action drop
  priority
!
class DATA2
  bandwidth remaining ratio 101
  queue-limit 212 packets
  police 1048000 35500 71000 conform-action set-dscp-transmit af21 exceed-action set-dscp-transmit af21 violate-action set-dscp-transmit af22

class DATA1
  bandwidth remaining ratio 202
  queue-limit 300 packets
  police 2096000 50000 100000 conform-action set-dscp-transmit af11 exceed-action set-dscp-transmit af11 violate-action set-dscp-transmit af12

class class-default
  bandwidth remaining ratio 98
  queue-limit 420 packets

The Parent by default his a queue limit of 73 packets with no amendments to the config, yet the child has more. In a scenario like this is it the child configuration that takes preference?

Service-policy output: PARENT

    Class-map: class-default (match-any) 
      1342116125 packets, 632169233328 bytes
      30 second offered rate 2524000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 73 packets <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      (queue depth/total drops/no-buffer drops) 0/1274435/0
      (pkts output/bytes output) 1340841447/630571911337
      shape (average) cir 17683258, bc 70734, be 70734
      target shape rate 17683258

Thanks

[Joseph W. Doherty]

This is the type of question that only Cisco might be able to answer.

[vamikhai]

I've seen such question multiple times on the forum.

Here is a cosmetic bug for this - CSCve90185

[sdipippo]

The parent policy queue-limit value can be ignored when using hierarchical queueing. Just configure the queue-limits in the child policy and ignore the parent. If using ISR G1 or G2, you must also tune the "hold-queue" parameter on the physical interface where the policy is applied. On ISR 4k or ASR 1k, this is not required.