QoS: the parts people skip

Most QoS deployments mark traffic carefully and then do nothing with the marking. Marking is a label. It changes behaviour only where a queueing policy acts on it, and only where there is congestion for it to act on.

The three parts

Classification — deciding what a packet is. Marking — recording that decision in the packet so later devices need not repeat the work. Queueing — behaving differently based on it when there is contention.

Skip the third and you have an elaborately labelled network that behaves exactly as it did before.

Mark at the edge, trust in the core

Classify where you understand the traffic, which is the access layer. Deep inspection in the core is expensive and unnecessary if the edge has already labelled things.

Critically: do not trust markings from devices you do not control. A user workstation can mark its traffic as expedited forwarding, and if you trust it, one person’s download outranks everyone’s calls.

! trust the phone, not the PC behind it
interface GigabitEthernet0/5
 mls qos trust device cisco-phone
 mls qos trust dscp

Priority queue with a limit

Voice belongs in a strict priority queue so it is always served first. It must also be policed. An unpoliced priority queue can consume the entire link, starving everything else — including the signalling that sets up the calls.

policy-map WAN-OUT
 class VOICE
  priority percent 20        ! served first, capped at 20%
 class SIGNALLING
  bandwidth percent 5
 class class-default
  fair-queue

It only acts under congestion

On an uncongested link, every packet is forwarded immediately and QoS changes nothing. This is why testing QoS on a quiet network proves nothing. Generate real congestion and then measure.

Where it must be applied

At the bottleneck, in the direction of the bottleneck. Usually that is the WAN-facing interface outbound. A policy applied on the LAN side of a router does nothing useful for traffic queueing to leave via a slower link.