QoS per-hop behavior

QoS defines per-hop behavior: what each device does to a packet as it forwards it, hop by hop — that's the DiffServ model — per-hop, with no built-in end-to-end reservation (reservation-oriented approaches like IntServ/RSVP are a different model). The chain is: classify (recognize traffic) → mark (tag it for downstream trust) → queue/schedule (who goes first under congestion) → optionally police/shape (enforce rates).

Policing measures traffic against a configured rate and drops or re-marks the excess — it does not delay. Shaping buffers excess traffic to emit a smooth rate — it delays instead of dropping but can still drop once buffers fill. Voice is delay-, jitter- and loss-sensitive, so the usual pattern is a parent WAN shaper with a child priority queue rather than shaping alone; providers police customers, enterprises shape to their contracted rate.

Verifying QoS

• show policy-map interface shows packets matched per class and drops — proof traffic is being classified and queued.
• Marked values can be read with packet captures — verify the edge actually writes DSCP.
• If queues never fill, QoS has nothing to do — benefits appear only under congestion.

Common mistakes

• Expecting QoS to create bandwidth — it only chooses who suffers when the link is full.
• Marking deep in the network — mark at the trust boundary (edge); re-marking at every hop defeats the purpose.
• Confusing policing (drop/re-mark) with shaping (buffer/smooth).
• Treating CoS as end-to-end or trunk-only — it lives inside any 802.1Q tag, including tagged frames on voice/edge trunks.
• Queuing voice with everything else — EF traffic needs a priority queue, not just a higher weight.