Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

Hierarchical QoS: Zero Drops, Perfect Counters, and Users Who Cannot Hear Each Other

Infrastructure Security and Services ｜ Configuration ｜ Advanced ｜ 24 min read

Quality of service only does anything when there is congestion. That sentence is obvious, it is on every introductory slide, and it is the reason a very large number of carefully built policies accomplish nothing at all. A router with a gigabit interface feeding a fifty megabit circuit is never congested — the provider's equipment is — so the router queues nothing, prioritises nothing, and every class counter reads perfectly while users complain.

A hierarchy fixes that by creating the congestion point deliberately. A parent policy shapes traffic down to the rate the circuit can actually carry, which makes the router the place where the queue forms, and a child policy nested inside decides what happens in that queue. The child is the part everyone writes; the parent is the part that makes it matter.

This article covers why a flat policy is inert on a subrate circuit, how a hierarchy is actually assembled, what a percentage means at each level and why that changes between levels, how the shaper is tuned and why voice is what forces the tuning, and the hierarchies that are configured correctly and still do nothing. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

Blog ClaimA child policy with no parent shaper is decoration — on a gigabit port feeding a fifty megabit circuit the router never queues a single packet, so every class counter reads zero drops and perfect service while the users on that circuit are the ones complaining.
The parent shaper exists to move the congestion point from the provider's equipment onto the router, because a class-based queue can only act where a queue actually forms.

Why Is a Flat Policy Inert on a Subrate Circuit?

What is the mechanism?

Classification, marking and policing act on every packet. Queuing acts only when packets have to wait, and packets only wait when the outgoing interface cannot send them immediately. A router with a fast interface feeding a slower circuit sends everything at once; the interface is never full, nothing queues, and the priority and bandwidth statements in the policy are never consulted. The discarding happens downstream, in equipment that knows nothing about the classification.

A Deeper Dive into Where the Queue Forms

What congestion actually means here

An interface is congested when it has more to send than it can transmit in the moment, so packets accumulate. That accumulation is the queue, and everything a queuing policy does is decide the order in which the accumulation is drained and what to discard when it grows too large.

No accumulation, no decisions. A policy attached to an interface that never accumulates anything has classification counters that increment and queuing behaviour that never runs. The counters are what mislead people: the classes are matching, the packets are being counted, and nothing is being prioritised.

The subrate case, which is most enterprise WAN

A router connects to a carrier with a gigabit Ethernet handover and buys fifty megabits of service. The physical interface is a gigabit interface and behaves like one. The carrier's equipment enforces the fifty megabits, by policing or by shaping, and it enforces it on everything equally.

So during a busy period the router transmits three hundred megabits, the carrier accepts fifty and discards the rest, and what it discards is whatever arrived when the bucket was empty. Voice packets and backup traffic are equally likely to be among them. The router's policy is irrelevant because the router never had a decision to make.

What the shaper changes

A parent policy that shapes to the purchased rate makes the router transmit no faster than the circuit carries. Now the router has more to send than it is permitted to send, an accumulation forms on the router, and a queue exists for the child policy to manage.

Nothing else about the design changes. The same traffic, the same circuit, the same carrier behaviour. The only difference is that the decision about what to discard has moved from equipment that classifies nothing to equipment that classifies everything.

Shape rather than police, and why

A policer discards or remarks traffic above the rate. A shaper delays it. For a rate limit applied to your own traffic before handing it to a circuit, delay is what you want: a packet that waits three milliseconds arrives, and a packet that is discarded has to be retransmitted.

Policing belongs where the intent is to enforce a limit on somebody else, or to cap a class that should not be allowed to grow regardless of available capacity. For the outer rate limit of a hierarchy it is the wrong tool, and using it produces a policy that discards traffic the circuit could have carried.

Shaping slightly below the purchased rate

The carrier's measurement and yours differ. They may count the Ethernet framing overhead you do not, or measure over a different interval, or enforce with a burst allowance that behaves differently from the shaper's. Shaping to exactly the purchased figure therefore produces occasional discards at the carrier despite the shaper.

Shaping a few percent below is the usual practice and it costs a few percent of a circuit to remove a class of problem that is otherwise very hard to diagnose — because the router shows no drops and the carrier does not show you its counters.

! The minimum hierarchy: a shaper that creates the queue,
! and a child policy that manages it.
R1(config)# policy-map WAN-PARENT
R1(config-pmap)# class class-default
R1(config-pmap-c)# shape average 48000000
R1(config-pmap-c)# service-policy WAN-CHILD
!
R1(config)# interface GigabitEthernet0/1
R1(config-if)# service-policy output WAN-PARENT
Pitfall: a complete QoS policy with zero drops and unhappy users Symptom: voice quality is poor during busy periods on a WAN circuit, the policy is attached, every class shows matching traffic, and the drop counters on every class are zero. Increasing the priority allocation changes nothing. Cause: the physical interface is far faster than the purchased circuit rate, so the router is never congested and the queuing policy never runs. The discards happen in the carrier's equipment, which treats every class identically. Confirm: show policy-map interface under load shows a queue depth of zero and no drops on any class. Fix: add a parent policy shaping to just below the purchased rate, with the existing policy nested inside it as the child.
Situation Where the queue forms What decides the drops
Interface speed equals circuit speed The router Your policy
Fast interface, slower circuit, no shaper The carrier Nothing you control
Fast interface, slower circuit, shaped The router Your policy
Shaped to exactly the purchased rate Mostly the router Mostly yours, occasionally theirs
Sub claimAdding a shaper does not improve the circuit by a single bit — it moves the decision about which packets to discard from equipment that classifies nothing to equipment that classifies everything.

How Is a Hierarchy Actually Built?

What are the levels?

Two at minimum: a parent that shapes and a child that queues. Three where traffic for several sites or several customers shares one circuit: a top-level shaper for the physical handover, a middle level shaping each logical connection to its own rate, and a child under each that queues by class. The nesting is always the same — a class in one level names a policy as its service policy — and the constraint is that shaping and queuing belong at different levels.

A Deeper Dive into Construction

The child, which is the familiar part

A policy with classes for each traffic type: strict priority for voice, guaranteed bandwidth for the classes that need it, and whatever remains for everything else. This is an ordinary queuing policy and it is written exactly as it would be for an interface whose speed matches the circuit.

The one thing that changes is what the percentages refer to, which is covered in the next section and is the most common source of arithmetic errors in a hierarchy.

! The child: an ordinary queuing policy
R1(config)# class-map match-any VOICE
R1(config-cmap)# match dscp ef
R1(config)# class-map match-any SIGNALLING
R1(config-cmap)# match dscp cs3 af31
R1(config)# class-map match-any BUSINESS
R1(config-cmap)# match dscp af21 af22 af23
R1(config)# class-map match-any BULK
R1(config-cmap)# match dscp af11 af12 af13
!
R1(config)# policy-map WAN-CHILD
R1(config-pmap)# class VOICE
R1(config-pmap-c)# priority percent 20
R1(config-pmap)# class SIGNALLING
R1(config-pmap-c)# bandwidth percent 5
R1(config-pmap)# class BUSINESS
R1(config-pmap-c)# bandwidth remaining percent 60
R1(config-pmap-c)# random-detect dscp-based
R1(config-pmap)# class BULK
R1(config-pmap-c)# bandwidth remaining percent 10
R1(config-pmap)# class class-default
R1(config-pmap-c)# bandwidth remaining percent 30
R1(config-pmap-c)# random-detect

The parent, which is short

One class — everything — with a shaper and a reference to the child. That is the whole parent in the two-level case. Its brevity is deceptive because it is the part that makes the child function at all.

The parent may also carry things that apply to all traffic regardless of class: a marking that the carrier expects on every packet, for instance. What it must not carry is queuing, because queuing belongs to the child.

Three levels, for several sites on one handover

A hub with one physical connection carrying traffic for many branches, each of which has its own smaller circuit at the far end, needs a rate limit per branch as well as one for the handover. The top level shapes the handover, each middle-level class matches one branch and shapes to that branch's rate, and each has its own child queuing policy.

The important property is that the middle-level rates may sum to more than the top-level rate. That is intentional — branches are not all busy at once — and the top-level shaper is what prevents the oversubscription from becoming a problem at the handover.

! Three levels: handover, per-branch, per-class
R1(config)# class-map match-all BRANCH-A
R1(config-cmap)# match vlan 101
R1(config)# class-map match-all BRANCH-B
R1(config-cmap)# match vlan 102
!
R1(config)# policy-map PER-BRANCH
R1(config-pmap)# class BRANCH-A
R1(config-pmap-c)# shape average 10000000
R1(config-pmap-c)# service-policy WAN-CHILD
R1(config-pmap)# class BRANCH-B
R1(config-pmap-c)# shape average 20000000
R1(config-pmap-c)# service-policy WAN-CHILD
!
R1(config)# policy-map HANDOVER
R1(config-pmap)# class class-default
R1(config-pmap-c)# shape average 100000000
R1(config-pmap-c)# service-policy PER-BRANCH
!
R1(config)# interface GigabitEthernet0/1
R1(config-if)# service-policy output HANDOVER

Where each construct is allowed

Strict priority exists only in the lowest level, because it is a queuing decision. Shaping exists at the levels above, because it creates the queue that the lowest level manages. Attempting to put priority in a parent, or to attach a child policy to a class that has no shaper, produces either a rejected configuration or a policy that behaves differently from the intention.

The rule that keeps this straight: every level except the bottom one exists to create a rate limit, and the bottom one exists to decide what happens inside that limit.

Per-subinterface policies

Where each logical connection is a subinterface, the policy can be attached there instead, which is often clearer than a middle level matching on tags. It introduces one risk: subinterface policies do not know about each other, so their shaped rates can sum to more than the physical interface can carry.

The answer is a policy on the physical interface as well, shaping the aggregate. Without it, a design where every subinterface is individually correct can oversubscribe the port, and the resulting discards happen outside any policy.

! Per-subinterface, with an aggregate limit on the port
R1(config)# policy-map BRANCH-A-PARENT
R1(config-pmap)# class class-default
R1(config-pmap-c)# shape average 10000000 100000 0
R1(config-pmap-c)# service-policy WAN-CHILD
!
R1(config)# interface GigabitEthernet0/1.101
R1(config-subif)# encapsulation dot1Q 101
R1(config-subif)# service-policy output BRANCH-A-PARENT
!
! Without this, the subinterfaces can together exceed the port
R1(config)# policy-map PORT-AGGREGATE
R1(config-pmap)# class class-default
R1(config-pmap-c)# shape average 100000000
!
R1(config)# interface GigabitEthernet0/1
R1(config-if)# service-policy output PORT-AGGREGATE

Reusing the child policy

One child policy referenced by several parents is normal and is how a consistent class treatment is applied across many branches. Because the child uses percentages, the same policy produces the correct absolute rates under parents with different shape rates.

That is the main argument for percentages over absolute rates in a child policy, and it is a strong one: a single child policy maintained once, applied to two hundred branches with different circuit sizes.

Write the child in percentages, alwaysAbsolute rates in a child policy tie it to one circuit size, which means a policy per branch and two hundred things to maintain. Percentages make one child policy correct under every parent, and correct again when a circuit is upgraded and only the parent's shape rate changes.
Sub claimEvery level above the bottom exists only to create a rate limit and the bottom level exists only to decide what happens inside it, which is the rule that settles where any given statement belongs.

What Does a Percentage Mean at Each Level?

Percentage of what?

In a child policy under a shaper, a bandwidth or priority percentage is a percentage of the parent's shape rate, not of the physical interface. That is the whole answer and it is the single most common misunderstanding in a hierarchy, because the same statement on a flat policy means a percentage of the interface. A remaining-bandwidth percentage means something different again: a share of what is left after the priority classes have taken what they need.

A Deeper Dive into the Arithmetic

Guaranteed bandwidth against remaining bandwidth

A guarantee reserves an amount and the reservations must fit within the available rate. A remaining share divides whatever is left after the guarantees and the priority traffic, proportionally, and the shares are relative to each other rather than to any absolute figure.

Mixing the two in one policy is legal and confusing. A policy where some classes have guarantees and others have shares requires working out what remains before the shares mean anything, and the arithmetic changes whenever a guarantee changes. A policy using shares throughout is easier to reason about and adjusts itself when the shape rate changes.

Why shares are usually the better choice

Under a shaper, the rate available to the child is the shape rate, and every class should get a proportion of it. Shares express exactly that and always sum to a hundred by construction. Guarantees express an absolute reservation, which under a shaper is a percentage of a number that may be adjusted later.

Where a class genuinely needs a floor regardless of what else is configured — a management class, for instance — a guarantee is right. For the ordinary business classes, shares are simpler and survive a circuit upgrade without recalculation.

Priority, and what it takes first

A priority class is served before everything else. Its percentage is of the parent's shape rate and it is an upper bound rather than a reservation: the class may use up to that much, and during congestion it is policed to it so that it cannot starve the rest.

That policing only engages under congestion, which means a priority class can exceed its percentage on an uncongested circuit and be cut back the moment the circuit fills. That is the intended behaviour and it surprises people who expect the limit to apply always.

How much priority is too much

A conventional ceiling is a third of the rate, and the reasoning is sound: priority traffic is served ahead of everything, so a large priority allocation means that during congestion everything else shares a small remainder and behaves badly.

The number matters less than the principle, which is that a priority class sized for the worst case rather than for the actual call volume degrades every other class in exchange for headroom that is never used. Sizing it from measured concurrent calls, with a modest margin, is the right approach.

! Under a 48 Mbps shaper, these are the real numbers
!   priority percent 20      -> up to 9.6 Mbps, served first
!   bandwidth percent 5      -> 2.4 Mbps guaranteed
!   remaining = 48 - 9.6 - 2.4 = 36 Mbps
!   bandwidth remaining percent 60 -> 21.6 Mbps
!   bandwidth remaining percent 10 -> 3.6 Mbps
!   bandwidth remaining percent 30 -> 10.8 Mbps
!
! Confirm what the device computed, rather than the arithmetic
R1# show policy-map interface GigabitEthernet0/1 output | include Class-map|bandwidth|priority|rate

The sum that must not exceed the rate

Guarantees plus priority must fit inside the shape rate, and the device will usually refuse a policy where they do not. What it will not refuse is a policy that fits under the current shape rate and stops fitting when the shape rate is reduced — a circuit downgrade, or a shaper adjusted downward after a carrier change.

A policy written entirely in shares has no such failure, because shares are always relative. That is another argument for them and it is the one that matters during a change nobody connected to the QoS configuration.

Pitfall: reducing the shape rate breaks a policy that was correct Symptom: after a circuit is downgraded and the parent's shape rate reduced accordingly, the policy is rejected or classes stop receiving the service they did before. Nothing in the child policy was changed. Cause: guaranteed bandwidth percentages in the child are percentages of the parent's shape rate. Lowering that rate lowers every guarantee, and a fixed guarantee expressed in absolute terms may no longer fit. Confirm: the policy-map output shows the recalculated rates against the new shape rate. Fix: express the child policy in remaining-bandwidth shares rather than guarantees, so that it adjusts itself whenever the parent's rate changes.

Marking, which is not affected by any of this

Classification and marking act on every packet regardless of congestion, so they work identically in a flat policy and in a hierarchy. A hierarchy is needed for queuing and not for marking, and a policy that only marks does not need one.

That is worth knowing because it explains why a marking policy on a subrate circuit appears to work while the queuing policy next to it does not. The two halves of the same policy behave differently for a reason that has nothing to do with how they were written. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

! Marking acts everywhere; queuing acts only under congestion
R1(config)# policy-map WAN-CHILD
R1(config-pmap)# class BULK
R1(config-pmap-c)# set dscp af11
R1(config-pmap-c)# bandwidth remaining percent 10
!
! The marking counter increments regardless of load
R1# show policy-map interface GigabitEthernet0/1 output | include QoS Set|dscp af11|packets marked
    QoS Set
      dscp af11
        Marker statistics: Disabled
Statement Relative to Behaviour Survives a rate change
shape average at the parent An absolute rate Delays traffic above it It is the rate
priority percent The parent's shape rate Served first, policed when congested Yes
bandwidth percent The parent's shape rate Guaranteed minimum Recalculated, may not fit
bandwidth remaining percent What is left after priority Proportional share Yes, always
set dscp Nothing Acts on every packet Unaffected
Sub claimA percentage in a child policy refers to the parent's shape rate rather than to the interface, which means the same child policy is correct under every parent and is the reason to write it in percentages rather than absolute rates.

How Is the Shaper Tuned, and Why Does Voice Care?

What is there to tune?

A shaper does not transmit smoothly; it releases a measured amount of traffic each interval and then stops until the next one. The interval is what matters for delay-sensitive traffic, because a packet that arrives just after the allowance is exhausted waits for the next interval. A long interval means a large amount released at once and a correspondingly long wait for whatever missed it — which is jitter, and voice is where it is noticed.

A Deeper Dive into Shaper Behaviour

How a shaper releases traffic

Over any second the shaper delivers the configured rate. It does so by permitting a fixed quantity per interval, where the quantity divided by the interval equals the rate. Two shapers configured for the same rate with different intervals deliver the same throughput and very different delay characteristics.

Setting the quantity therefore sets the interval, because the rate is fixed. A smaller quantity means more intervals per second, each releasing less, which is smoother. That is the entire tuning decision.

Why voice is the constraint

A voice stream sends a packet every twenty milliseconds and the receiver plays them out at that spacing, absorbing small variations in a buffer. A packet that arrives late enough is played out as a gap, or discarded.

If the shaper's interval is longer than the tolerance, a voice packet that misses one interval arrives a full interval late, every time it happens. An interval comfortably under ten milliseconds keeps that within what a playout buffer absorbs; an interval of several tens of milliseconds does not.

Setting it deliberately

The quantity is configurable alongside the rate. Choosing it so that the interval lands around five to ten milliseconds is a good general target, and the arithmetic is straightforward: quantity equals rate multiplied by the desired interval.

The cost of a smaller interval is more frequent shaper processing, which on modern platforms is not a concern at enterprise WAN rates. There is little reason to leave it at whatever the default produces.

! Rate 48 Mbps, target interval 10 ms
!   quantity = 48,000,000 x 0.010 = 480,000 bits
R1(config)# policy-map WAN-PARENT
R1(config-pmap)# class class-default
R1(config-pmap-c)# shape average 48000000 480000 0
R1(config-pmap-c)# service-policy WAN-CHILD
!
! What the device is actually using
R1# show policy-map interface GigabitEthernet0/1 output | include shape|Bc|Be|Target
      shape (average) cir 48000000, bc 480000, be 0
      target shape rate 48000000

The excess allowance

A shaper can be permitted to carry unused allowance forward and release a larger burst later. That improves throughput for bulk traffic and directly undermines the smoothness the interval tuning was for, because a burst is exactly the thing that delays whatever follows it.

On a circuit carrying voice, setting the excess allowance to zero is the right choice. On a circuit carrying only bulk data it is a reasonable way to use capacity the carrier permits. Deciding it rather than inheriting it is the point.

Queue depth, which is the other delay source

Each class has a maximum queue length, and a long queue means a packet at the back waits a long time. For bulk traffic a long queue is good — it absorbs bursts instead of discarding them. For interactive traffic it is the opposite, and for a priority class it should be short because anything that has waited long is already too late to be useful.

Platforms express the limit in packets, in bytes or in time. Time is the most useful unit where it is available because it states the thing that actually matters. Where it is not, the conversion from packets to time depends on the rate, which means a queue limit correct for one circuit size is wrong for another.

! Short queues where delay matters, long where it does not
R1(config)# policy-map WAN-CHILD
R1(config-pmap)# class VOICE
R1(config-pmap-c)# priority percent 20
R1(config-pmap-c)# queue-limit 64 packets
R1(config-pmap)# class BULK
R1(config-pmap-c)# bandwidth remaining percent 10
R1(config-pmap-c)# queue-limit 512 packets
R1(config-pmap-c)# random-detect
!
! Depth and drops, per class, under load
R1# show policy-map interface GigabitEthernet0/1 output | include Class-map|queue limit|depth|drops

Discarding early for responsive traffic

Traffic that reacts to loss by slowing down behaves better when a few packets are discarded as the queue grows than when the queue fills completely and a large block is discarded at once. Randomised early discard does that and belongs on bulk and general classes.

It does not belong on voice, which does not react to loss by slowing down and simply sounds worse. A priority class should discard only when it genuinely must.

Pitfall: voice is worse with the policy than without it Symptom: after a hierarchy is deployed, voice quality on the circuit is reported as worse than it was before, with intermittent choppiness rather than continuous degradation. Throughput for everything else improved. Cause: the shaper's release interval is long, so traffic is delivered in large bursts. A voice packet arriving just after an interval's allowance is exhausted waits for the next interval, producing jitter the playout buffer cannot absorb. Confirm: the shaper's configured quantity divided by the rate gives an interval of several tens of milliseconds. Fix: set the quantity so that the interval is under ten milliseconds, and set the excess allowance to zero so that bursts are not carried forward.
Sub claimTwo shapers at the same rate with different intervals deliver identical throughput and very different jitter, which is why the interval is the setting that decides whether voice is better or worse after the hierarchy is deployed.

Which Hierarchies Do Nothing at All?

What should be suspected?

Four. A policy applied in the wrong direction, since queuing acts on traffic leaving an interface and a policy applied inbound will never queue anything. A shape rate above what the circuit actually carries, which leaves the congestion at the carrier. Subinterface policies with no aggregate limit, which oversubscribe the physical port. And a platform that silently does something different from the configuration, which is more common on switches than on routers.

A Deeper Dive into Inert Hierarchies

Applied inbound

Queuing is an output behaviour. There is no queue on ingress because the packet has already arrived. A policy with priority and bandwidth statements attached inbound will classify, mark and police, and will never queue, which makes it another version of the policy that appears to work and does nothing.

The check is one line of configuration and it is worth including in a verification list precisely because it is too obvious to look at.

A shape rate that is wrong

The circuit was upgraded and the shaper was not. Or the shape rate was taken from a commercial document that described a different unit. Or the carrier enforces something different from what was ordered. In every case the router shapes to a rate above what the circuit carries and the congestion stays at the carrier.

The symptom is identical to having no shaper at all: no drops on the router and unhappy users. The distinguishing check is whether the router's queue depth grows under load. If it never grows, the shape rate is above the real capacity regardless of what the configuration says.

! The check that distinguishes every inert hierarchy
R1# show policy-map interface GigabitEthernet0/1 output
  Class-map: class-default (match-any)
    Queueing
      queue limit 416 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 18405212/22483920144
      shape (average) cir 48000000, bc 480000, be 0
      target shape rate 48000000
!
! Depth 0 and drops 0 under real load = the queue is not here.
! Compare the offered rate against the shape rate:
R1# show policy-map interface GigabitEthernet0/1 output | include offered rate|shape rate

Subinterfaces that sum to more than the port

Each subinterface has a policy shaping to its own rate and each is individually correct. Together they can offer more than the physical interface can transmit, and the excess is discarded by the interface with no policy involved.

A policy on the physical interface shaping the aggregate resolves it. This is the same three-level structure described earlier, arrived at from a different direction, and it is frequently missing in designs that grew one subinterface at a time.

Platform differences

Switches implement queuing in hardware with a fixed number of queues, and a policy naming more classes than there are queues is mapped onto what exists. The result is a configuration that is accepted and a behaviour that is not what it describes.

The number of hierarchy levels supported also varies, as does whether a shaper is available on a logical interface at all. Checking the specific platform's capability before designing a three-level policy avoids designing something that cannot be implemented on half the estate.

Pitfall: the same policy behaves differently on a switch and a router Symptom: a hierarchy that works correctly on a branch router produces different class behaviour when applied to a switch at another site, with some classes appearing to share a queue. The configuration is identical and was accepted without error. Cause: switch queuing is implemented with a fixed number of hardware queues. A policy naming more classes than there are queues is mapped onto the available ones, so classes intended to be separate are serviced together. Confirm: the platform's queue count against the number of classes in the policy. Fix: design the class scheme to the smallest queue count in the estate, or accept different policies per platform and document which is which.

A verification sequence

Five checks in order. The policy is attached, outbound, on the right interface. The shape rate matches the circuit, minus a margin. The queue depth grows under load, which proves the congestion is here. Each class's drops are consistent with its intent — bulk dropping, voice not. And the offered rate per class is within what was planned.

The third of those is the one that matters most and the one least often performed, because it requires load. Generating it deliberately, once, during commissioning, establishes that the whole structure works and is far cheaper than discovering it does not during a busy period.

! Five checks, in order
R1# show running-config interface GigabitEthernet0/1 | include service-policy
R1# show policy-map interface GigabitEthernet0/1 output | include shape rate
R1# show policy-map interface GigabitEthernet0/1 output | include depth
R1# show policy-map interface GigabitEthernet0/1 output | include Class-map|drops
R1# show policy-map interface GigabitEthernet0/1 output | include offered rate

What to monitor

Drops per class, which is the direct evidence the policy is acting. Queue depth on the priority class, which should be small at all times and whose growth indicates either too much priority traffic or a shaper interval problem. And the offered rate against the shape rate, whose ratio tells you how close the circuit is to needing an upgrade.

The third is the one that turns the policy into planning information. A circuit consistently offering more than its shape rate is a capacity decision waiting to be made, and the data to make it is already being collected.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers quality of service within its services domain, including classification, marking, policing, shaping and queuing. Hierarchical policies appear as the mechanism for applying queuing on a subrate circuit, and the point most likely to be examined is why the parent shaper is required at all.

Symptom Cause Check
Zero drops, unhappy users No shaper, or shape rate too high Queue depth under load
No queuing at all Policy applied inbound The service-policy direction
Port discards outside any policy Subinterfaces sum above the port Sum of shape rates
Classes share treatment More classes than hardware queues Platform queue count
Voice worse after deployment Shaper interval too long Quantity divided by rate
Policy rejected after a downgrade Guarantees no longer fit Use remaining shares instead
Generate load once, at commissioningEvery inert hierarchy in this article looks identical to a working one when the circuit is quiet. A few minutes of deliberate load during commissioning, with the queue depth watched, distinguishes them conclusively — and it is the only test that does.
Sub claimA queue depth that never grows under load is conclusive evidence that the congestion point is not on this router, regardless of what the shape rate says it should be.

Conclusion

Queuing acts only where a queue forms, and on the typical enterprise WAN the queue does not form on the router. A gigabit handover carrying a fifty megabit service means the router transmits freely and the carrier discards, without regard to any classification. The parent shaper exists for one reason: to move that discard decision onto equipment that knows the difference between a voice packet and a backup stream. It improves the circuit by nothing and improves what crosses it considerably.

Inside the hierarchy, the rule that settles most questions is that every level above the bottom creates a rate limit and the bottom level decides what happens inside it. Percentages in the child refer to the parent's shape rate rather than to the interface, which is what allows one child policy to be correct under two hundred parents with different circuit sizes — provided it is written in remaining-bandwidth shares, which adjust themselves, rather than in guarantees, which stop fitting when a circuit is downgraded.

The tuning that decides whether voice is better or worse afterwards is the shaper's release interval, because two shapers at the same rate with different intervals deliver identical throughput and very different jitter. And every failure here looks identical to success on a quiet circuit: no drops, clean counters, and a queue that never forms. A few minutes of deliberate load at commissioning, with the queue depth watched, is the only test that tells the two apart. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

Reference Notes

  1. RFC 2475 describes the differentiated services architecture, in which traffic conditioning at the network edge includes both shaping, which delays traffic, and policing, which discards or remarks it.
  2. RFC 2475 states that a shaper delays packets to bring a stream into conformance with a traffic profile, and that a shaper therefore requires buffering.
  3. RFC 3246 defines the expedited forwarding per-hop behaviour intended for traffic requiring low loss, low latency and low jitter, and notes that it must be rate limited to prevent starvation of other traffic.
  4. RFC 3246 observes that the aggregate arrival rate of expedited forwarding traffic must be less than the configured departure rate, which is the basis of the convention that priority allocation be bounded.
  5. RFC 2597 defines the assured forwarding per-hop behaviour group, providing several classes each with multiple drop precedences.
  6. RFC 2474 defines the differentiated services field and the codepoints used to mark packets for the behaviours above.
  7. RFC 4594 provides configuration guidelines for differentiated services classes, including recommended codepoints and queuing treatment for voice, signalling and bulk data.
  8. RFC 2698 defines a two rate three colour marker, whose committed and peak rates with their associated burst sizes correspond to the rate and burst parameters of a configured shaper.
  9. Cisco documentation describes hierarchical policy maps, in which a child policy is attached to a class in a parent policy using a nested service policy.
  10. Cisco documentation states that in a child policy nested under a shaped parent, bandwidth and priority percentages are calculated against the parent's shape rate rather than against the interface bandwidth.
  11. Cisco documentation describes the committed burst parameter of a shaper, which together with the configured rate determines the interval over which the shaper meters traffic.
  12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include quality of service within the infrastructure services domain.