Hierarchical QoS: Shaping Parents and Queueing Children

A single flat QoS policy works fine until reality intrudes: you have a 100 Mbps physical interface but the carrier only sold you 20 Mbps, or one physical link carries traffic for ten branch sites that each need their own guarantees. A flat policy cannot express "shape everything to 20 Mbps, and within that 20, give voice priority and data a floor." That two-level problem is exactly what Hierarchical QoS solves, by nesting one policy inside another.

This article covers hierarchical QoS and the shaping that underpins it. It extends the QoS cluster guide and builds on LLQ and CBWFQ.

First: Shaping vs Policing

Hierarchical QoS is built on shaping, so the shaping-versus-policing distinction has to be clear. Both limit traffic to a rate; they differ in what they do with the excess:

The analogy: policing is a bouncer who turns away anyone over capacity; shaping is a queue outside the club that lets people in at a steady rate. Policing is cheaper (no buffers) but wastes the excess traffic; shaping preserves it but costs delay and memory. For the classic carrier-mismatch problem, you want shaping, because dropping traffic your own router could have buffered and sent a moment later is needlessly lossy.

The Problem HQoS Solves

The canonical case: you buy a 20 Mbps WAN service, but it is delivered over a 100 Mbps physical handoff (Metro Ethernet, for example). Your router's interface is 100 Mbps, so it will happily send bursts at 100 Mbps, and the carrier, seeing traffic above the 20 Mbps you paid for, will police (drop) the excess. Worse, the carrier's drop is indiscriminate, it does not know your voice from your bulk data, so your carefully prioritised voice gets dropped along with everything else.

The fix is to shape your own traffic to 20 Mbps first, so it never exceeds what the carrier will accept, and then apply your queueing policy within that shaped 20 Mbps, so your voice gets priority inside the rate the carrier honours. That is two levels of policy: shape (parent), then queue (child). And a single flat policy cannot do it, because a flat policy's percentages are of the physical 100 Mbps, not the 20 Mbps you actually have.

Parent and Child

HQoS nests a child policy inside a parent policy. The parent shapes; the child queues within the shaped rate:

! CHILD: the queueing policy (LLQ + CBWFQ), unchanged
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        ! shape everything to 20 Mbps
  service-policy CHILD-QUEUEING  ! then queue within that 20 Mbps
!
interface GigabitEthernet0/0
 service-policy output PARENT-SHAPER

The magic is the last line of the parent: service-policy CHILD-QUEUEING nested inside the parent's class-default. This says "shape all traffic to 20 Mbps, and within that shaped queue, apply the child's LLQ/CBWFQ logic." Now the child's priority percent 20 means 20% of the 20 Mbps service rate (4 Mbps), not 20% of the 100 Mbps interface. The percentages finally mean what you intend.

Read it as a pipeline: traffic hits the parent shaper, which buffers anything above 20 Mbps and releases it smoothly at 20 Mbps; the traffic released by the shaper flows through the child policy, which prioritises voice and guarantees the data floor within that 20 Mbps. Shape first, queue within the shaped rate.

The Per-Site Case: Nested Shaping

The same structure scales to the multi-site problem. Imagine a physical link carrying traffic to ten branches, each with its own contracted rate. You build a parent that shapes each branch to its rate (matched by a class per branch), with a child queueing policy inside each:

policy-map PER-SITE-PARENT
 class SITE-A               ! matches traffic to branch A
  shape average 5000000     ! branch A gets 5 Mbps
  service-policy CHILD-QUEUEING
 class SITE-B
  shape average 10000000    ! branch B gets 10 Mbps
  service-policy CHILD-QUEUEING

Each branch is independently shaped to its rate, and within each branch's shaped bandwidth, voice still gets priority. This is how a service provider or a large enterprise delivers differentiated per-site QoS over one shared physical link, and it is only expressible with the hierarchy.

The Shaper's Details That Matter

Two shaping parameters affect behaviour and cause confusion:

The interaction with LLQ matters: a shaper adds delay (it buffers), and delay is the enemy of voice. When you shape a link carrying voice, the shaper's queue can add latency to voice packets before they even reach the child's priority queue. This is why HQoS designs for voice often tune the shaper's Bc down, so the shaping interval is short and voice is not held long. It is a real tension: shaping smooths bursts (good) but adds delay (bad for voice), and the child priority queue only helps within the shaped rate.

Verifying the Hierarchy

The same command shows both levels, nested:

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)     <- 20% of the SHAPED 20 Mbps, not the interface
        Class-map: BULK-DATA
          bandwidth 40% (8000 kbps)

Notice the child's Priority: 20% (4000 kbps): the percentage is now calculated against the parent's 20 Mbps shape rate, giving 4 Mbps, exactly the intent. On a flat policy it would have been 20% of the physical interface. That recalculation is the entire reason the hierarchy exists.

FAQ

Shaping or policing for a carrier rate mismatch?

Shaping. It buffers the excess and sends it later at the contracted rate, avoiding the drops that policing (yours or the carrier's) would cause. Dropping traffic you could have buffered is needlessly lossy.

Why can't a flat policy handle the 100/20 Mbps case?

A flat policy's percentages are of the physical interface (100 Mbps). You need to shape to 20 Mbps first and apply queueing within that 20, so the percentages mean 20% of 20 Mbps. That requires a parent (shape) and a child (queue).

Does shaping add latency?

Yes. Shaping buffers traffic above the rate, and buffering is delay. This matters for voice; HQoS designs carrying voice often tune the shaper's Bc down to keep the shaping interval short.

What is the difference between shape average and shape peak?

average shapes strictly to the rate; peak allows brief bursts above it. Use average to match a carrier's contracted rate exactly, or the carrier will police your peaks.

Can I shape different sites to different rates on one link?

Yes, that is the multi-site HQoS case: a parent with a class and shaper per site, each with a nested child queueing policy. Each site is independently shaped, with voice priority within its rate.

Key Takeaways

• Policing drops excess (sharp, no delay, bursty); shaping buffers it and sends later (smooth, adds delay, needs memory). Use shaping to match a downstream rate.
• HQoS solves the case a flat policy cannot: shape to the service rate (parent), then queue within it (child). A 100 Mbps interface delivering a 20 Mbps service needs this.
• The parent's service-policy CHILD nesting makes the child's percentages calculate against the shaped rate (20% of 20 Mbps = 4 Mbps), not the physical interface.
• The same structure scales to per-site shaping: a class and shaper per branch, each with a nested queueing child.
• Shaping adds delay, which fights voice; HQoS-for-voice designs tune Bc down to shorten the shaping interval.
• Verify with show policy-map interface, which displays both levels nested and the recalculated child percentages.

Next: Interpreting QoS configurations, or the QoS cluster guide.