Skip to content
Log in Sign up My account

4.2 End-to-End QoS Policies

Blueprint 4.2: End-to-end QoS policies

  • 4.2.a Classification and marking
  • 4.2.b Shaping
  • 4.2.c Policing
  • 4.2.d Queuing

Once the strategy exists, the design question is where each tool belongs. A QoS policy is a chain: classify and mark at the edge, police where you must enforce a limit, shape where a rate mismatch exists, and queue where congestion forms. The syntax is covered in ENCOR QoS. The class and marking plan comes from 4.1.

Where each tool goes

graph LR
  PC["Endpoint"] --> AS["Access switch:<br/>classify, mark, police ingress"]
  AS --> DS["Distribution:<br/>trust, queue"]
  DS --> WE["WAN edge:<br/>shape, queue, remark"]
  WE ==>|"Provider circuit"| PR["Provider"]
  PR ==> RE["Remote WAN edge"]
Tool Best place Design reason
Classification and marking Access layer (closest to source) Marks are written once and trusted afterwards
Ingress policing Access ports for untrusted or scavenger traffic, provider handoff for contracted rates Enforce limits before traffic uses shared resources
Shaping Egress of any link where the contracted rate is lower than the port speed Creates the congestion point that lets queuing work
Queuing Every egress where oversubscription can occur Congestion is where priority matters
Congestion avoidance (WRED) TCP-heavy data classes Avoids global synchronisation

Traffic can only be queued where it waits. In a campus with a 10 Gbps uplink and a 1 Gbps access port, the access port's egress queue (towards the user) can congest while the uplink never does. Aggregation uplinks, WAN edge links and any fan-in point need explicit policies. Interfaces that cannot be congested need none.

4.2.a Classification and marking

Classification identifies a packet. Marking writes a value. Classification can use:

Method Strength Weakness
Existing DSCP or CoS Cheap, fast Only as good as the trust decision
ACL on addresses and ports Predictable, hardware friendly Breaks with dynamic ports and cloud applications
NBAR2 application recognition Names applications, tracks protocol updates Uses more CPU on software platforms, needs updated protocol packs
Cisco Catalyst Center application policy Intent-based, applies one business relevance across the network Needs the controller and compatible devices

Marking fields are CoS (3 bits, 802.1Q, trunks only), DSCP (6 bits, IP) and MPLS EXP (now called the Traffic Class field, 3 bits). Layer 2 marks disappear when a frame crosses a router, so end-to-end designs map between CoS, DSCP and EXP at each boundary. Wireless adds 802.11 User Priority, mapped to and from DSCP at the access point.

Exam trap

CoS exists only on tagged frames. A frame on an access port with no 802.1Q tag has no CoS, and a routed hop strips it. If a scenario depends on a CoS marking surviving a routed network, the design is wrong. Use DSCP.

On Catalyst 9000, the access switch can trust DSCP, trust CoS, or classify and re-mark. Re-marking all traffic from untrusted ports to match your class model is the safest default for guest and contractor VLANs.

4.2.b Shaping

Shaping buffers traffic so that the output rate conforms to a configured average rate. It works on egress only. Its main design use is the rate mismatch: a router with a gigabit Ethernet port connected to a 100 Mbps Metro Ethernet service, or a 1 Gbps handoff carrying a 200 Mbps contract.

Think of it as a combination of rate and time. The shaper sends Bc bits in each time interval Tc, where Tc = Bc / CIR. A smaller Bc gives a smaller Tc and therefore lower delay variation. Voice paths need a small Tc, because a long interval with no transmission adds jitter. For this reason the shaper in front of a voice queue is set with a small Bc, and the priority class sits in the child policy where it is served first.

The standard sub-rate WAN pattern is a hierarchical policy:

policy-map CHILD-QUEUING
 class VOICE
  priority percent 10
 class CRITICAL
  bandwidth percent 30
 class class-default
  fair-queue
!
policy-map PARENT-SHAPER
 class class-default
  shape average 100000000            ! match the provider's contracted rate
  service-policy CHILD-QUEUING
!
interface GigabitEthernet0/0/1
 service-policy output PARENT-SHAPER

Design guidance:

  • Shape to the contracted rate, not the port speed. If the contract is 100 Mbps, shaping to 100 Mbps means your queues, not the provider's policer, decide what is dropped.
  • Shape slightly below the contract if the provider counts Layer 2 overhead differently than your router does, so the provider policer is never triggered.
  • A shaper adds delay. Do not shape real-time traffic with a long buffer. Real-time classes belong in the priority queue of the child policy.
  • Shaping works only at egress, so for ingress limits you must police.

4.2.c Policing

Policing measures a rate and acts on traffic that exceeds it, either by dropping it or by re-marking it. There is no buffering, so a policer adds no delay but produces bursty loss. It works on ingress or egress.

Policer Colours What it does Typical use
Single-rate two-colour conform, exceed Transmit or drop at CIR Simple limits
Single-rate three-colour (CIR, Bc, Be) conform, exceed, violate Allows a burst above CIR Bandwidth contracts with bursts
Dual-rate three-colour (CIR, PIR, RFC 2698) conform, exceed, violate Two rates, separate Bc and Be Provider-style commitments, PIR above CIR

Use a policer when:

  1. You must enforce a limit that someone else will not (a guest SSID, a scavenger class, a customer connection).
  2. You want to protect a shared resource, such as the priority queue (the LLQ is itself an implicit policer under congestion).
  3. You want to re-mark excess rather than drop it. For example, traffic above CIR is re-marked from AF21 to AF22 so WRED drops it first. This is the remark on exceed pattern.
policy-map ACCESS-INGRESS
 class SCAVENGER
  police cir 1000000 conform-action set-dscp-transmit cs1 exceed-action drop
 class TRANSACTIONAL
  police cir 10000000 conform-action transmit exceed-action set-dscp-transmit af22
Shaping Policing
Excess traffic Delayed in a buffer Dropped or re-marked
Direction Egress Ingress or egress
Delay and jitter Adds delay None
Effect on TCP Smooth Sawtooth after drops
Design placement Before a slower link At the edge of a contract or untrusted source

Exam trap

If the provider polices your traffic at the contracted rate, shaping at the same rate on your side prevents the provider from dropping packets you did not choose to drop. The trap answer is "police on the router at the same rate." A policer drops the excess instead of delaying it, which wastes TCP throughput. For a sub-rate egress, the answer is shaping.

4.2.d Queuing

Queuing decides the order of departure when an interface is congested. The key mechanisms are:

Mechanism Behaviour Design role
FIFO Single queue Default on uncongested links
LLQ (priority) Strict-priority queue, policed under congestion Voice, and optionally interactive video
CBWFQ (bandwidth) Guaranteed minimum share per class Data classes
Fair queue (in class-default) Per-flow fairness Prevents one flow dominating best effort
WRED Early random drop by DSCP or precedence TCP data classes, to avoid tail-drop synchronisation

Design rules that appear repeatedly:

  • Put only genuinely delay-sensitive traffic in the priority queue. Everything in it competes with itself and starves the other classes if over-provisioned.
  • Cap total priority traffic at about one third of the link as a common rule of thumb. Beyond that, data classes get too little and delays in the non-priority queues grow.
  • Do not apply WRED to voice or to UDP real-time streams. They do not slow down in response to drops, so early drops only hurt quality.
  • Reserve bandwidth for network control (CS6) and management (CS2) so a flood of user traffic cannot stop routing protocols and SSH.
  • Remember that bandwidth is a floor, not a ceiling. An idle class's bandwidth is shared among busy ones.
  • Priority levels: more than one priority class can be configured. Where supported, priority level 1 is served before priority level 2, so interactive video can have its own priority queue without delaying voice.

Hardware platforms such as Catalyst 9000 use a fixed number of egress queues per port (eight). Platform-specific queue buffers and thresholds can be tuned, but the class model must fit the number of queues available. A design with 12 classes on a platform with 8 queues needs classes to share queues.

End-to-end consistency

Everything in this chapter fails if one hop differs. A design review should check, from one end to the other:

  1. Are classes identical at the access, distribution, WAN edge, and the remote site?
  2. Does each congestion point have a queuing policy, and each rate mismatch a shaper?
  3. Is every trust boundary deliberate, and is the provider mapping documented?
  4. Do tunnels and encryption preserve or copy the DSCP?
  5. Is network control traffic protected on every link?
Branch PC  -> Access (mark/police) -> Dist (queue) -> WAN edge (shape+queue+remark)
   -> provider (3 classes) -> HQ WAN edge (remark back, queue) -> Dist -> Server

Design exercise

Scenario. A hospital runs voice, a real-time patient-monitoring feed over UDP, an electronic record system, imaging file transfers of several gigabytes, and guest Wi-Fi. A 1 Gbps Metro Ethernet circuit to the data centre is billed at 300 Mbps. The provider polices at 300 Mbps and silently drops the excess. Imaging transfers regularly cause voice clipping in the evenings.

Requirements.

  • Voice and patient-monitoring traffic must never be delayed by imaging.
  • The record system must stay responsive.
  • Guests must not affect clinical traffic.

Constraints.

  • The circuit runs at 1 Gbps physical speed with a 300 Mbps contract.
  • Guest traffic is untrusted.

Design the policy chain.

Model answer
  • Guest edge: classify guest SSID and VLAN traffic and re-mark to scavenger (CS1), with an ingress policer at the access layer so guests cannot saturate the uplinks.
  • Clinical edge: trust DSCP from managed devices only through conditional trust. Mark voice EF and patient monitoring CS4 (or EF if the platform has one priority queue), record system AF21, imaging bulk AF11.
  • WAN edge: apply a hierarchical policy. The parent shapes to 300 Mbps (slightly under, for example 290 Mbps, to absorb overhead differences). The child has a priority queue for voice and monitoring with a combined limit well under one third, CBWFQ for the record system with a guaranteed share, a small bandwidth reservation for network control, and imaging in a bulk class with WRED. Guest and scavenger traffic go to a minimal-bandwidth class.
  • Return path: the same policy at the data centre end, since the provider drops in both directions.

Rejected alternatives.

  • Policing at 300 Mbps on the router. This drops excess indiscriminately and cannot protect voice. It does not create a queue where priority can act.
  • Queuing only, no shaper. The interface is a 1 Gbps port. It never congests locally, so the queue never activates. The provider's policer would still decide what is dropped, and voice would be dropped with imaging.
  • Buying more bandwidth only. It postpones the symptom. Imaging is greedy and will fill any size link.
  • Putting imaging in the priority queue because it is "important". Large bulk transfers in a strict-priority queue would starve everything else once the policer starts dropping them.

Quick check

A policy has a single 10 Mbps shaper at the WAN edge with no child. Is voice protected?

No. The shaper delays everything equally in one queue. Voice needs a child policy with a priority class under the shaper.

Why should WRED not be applied to the voice class?

Voice is UDP and does not reduce its rate in response to drops. Early drops add loss without relieving congestion.

Where does ingress policing of guest traffic make sense?

At the access port or SSID, which is the first point where the traffic enters the network and before it consumes shared uplinks.

References

  • Modular QoS CLI Configuration Guide, Cisco IOS XE (search "Modular QoS CLI IOS XE" on cisco.com)
  • Catalyst 9000 QoS configuration guide (search "Catalyst 9300 QoS configuration guide" on cisco.com)
  • RFC 2697 (single-rate three-colour marker), RFC 2698 (dual-rate three-colour marker), RFC 4594 at rfc-editor.org
  • Cisco Live On-Demand Library: search "enterprise QoS design"