Hierarchical QoS: Parent Shaping with Child Queueing

A flat QoS policy cannot express the sentence "shape everything to 20 Mbps and give voice priority inside that 20 Mbps". The parent has to shape first and the child has to queue within the shaped rate — which is exactly what hierarchical QoS does. The payoff is that percentage values in the child policy are recalculated against the shaped rate rather than the physical interface, so priority percent 20 finally means what you intended. This article builds the canonical two-level hierarchy and shows how to verify it.

Shaping versus policing, briefly

• Policing drops or remarks traffic above a rate. Sharp, no buffering, no added delay, bursty output. Used at the edge to enforce a hard ceiling.
• Shaping buffers traffic above a rate and sends it later. Smooth output, adds delay, consumes memory. Used to match a downstream rate without dropping.

The canonical case for HQoS is a 20 Mbps service delivered over a 100 Mbps physical handoff. The router will happily burst at 100 Mbps, and the carrier — seeing traffic above what you paid for — police it indiscriminately, dropping your prioritised voice alongside bulk data. Shaping your own traffic to 20 Mbps first, and queueing within that shaped rate, is the fix.

The two-level policy

! CHILD: queueing policy (LLQ + CBWFQ)
policy-map CHILD-QUEUEING
 class EF-VOICE
  priority percent 20
 class BULK-DATA
  bandwidth percent 40
  random-detect dscp-based
 class class-default
  fair-queue
!
! PARENT: shape to the service rate, then hand off to the child
policy-map PARENT-SHAPER
 class class-default
  shape average 20000000
  service-policy CHILD-QUEUEING
!
interface GigabitEthernet0/0
 service-policy output PARENT-SHAPER

The whole design lives in the last line of the parent: service-policy CHILD-QUEUEING nested inside class-default. Traffic hits the parent shaper, anything above 20 Mbps is buffered and released smoothly, and the released traffic flows through the child policy which prioritises voice and guarantees the data floor within that 20 Mbps.

Why the percentages change meaning

R1# show policy-map interface GigabitEthernet0/0
 Service-policy output: PARENT-SHAPER
  Class-map: class-default
   shape (average) cir 20000000, target shape rate 20000000
   Service-policy : CHILD-QUEUEING
    Class-map: EF-VOICE
     Priority: 20% (4000 kbps)
    Class-map: BULK-DATA
     bandwidth 40% (8000 kbps)

The child's voice class shows Priority: 20% (4000 kbps) — 20 % of the 20 Mbps shaped rate, not of the 100 Mbps interface. On a flat policy the same line would have read 20 Mbps, five times the intended bandwidth. That recalculation is the entire reason the hierarchy exists.

Per-site hierarchies

The same structure solves the multi-site problem: one physical link carrying traffic for several branches, each with its own contracted rate. Build a parent with one class per site, shape each to its rate, and nest the same child policy inside each:

policy-map PER-SITE-PARENT
 class SITE-A
  shape average 5000000
  service-policy CHILD-QUEUEING
 class SITE-B
  shape average 10000000
  service-policy CHILD-QUEUEING

Each branch is independently shaped and each retains voice priority. This is only expressible with a hierarchy; a flat policy forces you to choose between per-site rates and per-class queueing.

The shaper settings that cause trouble

• shape average vs shape peak — average shapes strictly to the rate; peak permits brief bursts above it. Use average when matching a carrier rate exactly.
• Bc (committed burst) — the amount that can be sent per interval. The default is usually fine, but on voice-heavy links a smaller Bc shortens the shaping interval so voice is not held in the shaper's queue for long before reaching the child priority queue.
• Delay versus smoothness — shaping smooths bursts (good) but adds delay (bad for voice). The child priority queue only helps within the shaped rate, so a badly tuned shaper can still add latency to voice before prioritisation happens.

Platform caveats

• On some switch platforms, ingress child-level policing is supported but the policing statistics are not updated when the parent also polices; only the HQoS shaper counters are updated. Use show policy-map type queuing interface <interface> to read shaper statistics.
• Hierarchical QoS is not supported on link aggregation groups on some router families, so plan the policy attachment point before bundling links.
• Bandwidth remaining ratio may not be supported on a parent policy on certain platforms — verify against the platform's QoS guide before designing around it.
• Supported combinations of actions per level are platform-specific. Applying an unsupported combination produces an explicit failure message rather than silent misbehaviour, so read the error instead of retrying.

Verification checklist

1. show policy-map interface <intf> — confirm the nesting is present and the child percentages recalculated against the shaped rate.
2. Confirm the shaper rate matches the contracted rate, and that the interface is not also policed upstream by your own policy.
3. Watch the child class counters under load: conformed traffic for the priority class, drops only where you expect them.
4. Measure one-way delay for the priority class after any Bc change — the shaper interval is the variable you just moved.

See also: QoS trust boundary: DSCP vs CoS, IOS-XR class-map and policy shaping, and WRED versus tail drop.

原文链接：https://pinglabz.com/hierarchical-qos-shaping