Explain the Forwarding Per-Hop Behavior (PHB) for QoS

Domain 4.7 | IP Services — 10% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Explain what “per-hop behavior” means and why QoS treatment is applied independently at each device along a path.
• Describe classification and marking, including the difference between DSCP and CoS markings.
• Explain the purpose of queuing and how it prioritizes latency-sensitive traffic during congestion.
• Distinguish between congestion management and congestion avoidance at a conceptual level.
• Correctly distinguish policing from shaping, including how each handles traffic that exceeds a configured rate.

Key Terms Glossary

What “Per-Hop Behavior” Actually Means

QoS exists because not all traffic is equally sensitive to delay. A voice call degrades noticeably with even small amounts of added latency or jitter; a large file download barely notices an extra fraction of a second here and there. When a link becomes congested — more traffic wants to cross it than it currently has capacity for — some traffic has to wait or get dropped, and QoS is the set of techniques that decides which traffic that should be, rather than leaving it to chance.

The phrase per-hop behavior describes something specific about how this works: each device along a packet’s path makes its own local decision about how to treat that packet, based on how the packet is marked, without needing to coordinate with any other device or maintain awareness of the packet’s full end-to-end journey. This is a meaningfully different model from approaches that track per-flow state across an entire path — PHB is deliberately lightweight and stateless at each hop, which is exactly what allows it to scale to large, busy networks without every router needing to track the state of every individual conversation crossing it.

It’s worth being precise about how this relates to something covered earlier in this domain: objective 3.2 covered how a router decides where to send a packet — the longest-prefix-match, administrative distance, and metric hierarchy governing path selection. PHB is a related but distinct question: once a router has already decided where a packet is going, PHB governs how that packet is treated relative to other packets competing for the same outbound link — which one gets sent first, and which one waits or gets dropped if the link is oversubscribed. Routing answers “which way,” QoS answers “how urgently.”

Classification and Marking: The First Step

Before any device can treat traffic differently, it first needs to identify what kind of traffic it’s looking at — this is classification. A device examines a packet (or frame) and determines what category it belongs to: voice, video, bulk file transfer, routine best-effort traffic, and so on.

Once classified, a packet is typically marked — tagged with a value that records its classification directly in the packet or frame itself, so that every subsequent device along the path can apply consistent treatment without needing to re-run the classification logic itself. This “classify once, trust the marking downstream” approach is significantly more efficient than every single hop independently trying to inspect and re-classify the same traffic repeatedly.

Two marking mechanisms matter at the CCNA level, operating at different layers:

• DSCP (Differentiated Services Code Point) marks traffic at Layer 3, using a field within the IP header itself. Because it’s part of the IP header, a DSCP marking survives across an entire routed path, visible to every Layer 3 device the packet crosses.
• CoS (Class of Service) marks traffic at Layer 2, using a field within an 802.1Q VLAN tag. Because it’s part of a Layer 2 frame header rather than the IP packet, a CoS marking only has meaning within a single Layer 2 segment — it doesn’t survive being routed, since routing strips and rebuilds Layer 2 framing at each hop.

This layer distinction has a practical consequence worth internalizing: a network relying purely on CoS marking loses that marking information the moment traffic crosses a router, while DSCP marking persists end to end across a routed network. This is exactly why DSCP is the more commonly emphasized marking mechanism in modern QoS design, even though CoS still matters within individual switched segments.

Queuing: Prioritizing During Congestion

Once traffic is classified and marked, queuing puts that classification to work. Rather than treating an outbound interface as a single first-in-first-out line for every packet regardless of type, queuing places classified traffic into separate queues, each with its own priority level. When a link is congested, a well-configured queuing scheme services high-priority queues (voice, for instance) ahead of lower-priority queues (a large file transfer), ensuring latency-sensitive traffic gets through with minimal delay even while less time-sensitive traffic waits longer or, in a genuinely saturated scenario, gets dropped first.

This is the direct payoff of classification and marking: without a marking already in place identifying which queue a packet belongs in, a device would need to re-inspect and classify every single packet at every single hop, which is precisely the overhead PHB’s marking-based model is designed to avoid.

Congestion Management vs. Congestion Avoidance

These two terms sound similar and are sometimes used loosely, but they describe genuinely different strategies, applied at different points relative to actual congestion.

Congestion management describes techniques for handling traffic once a link is already congested — queuing itself is the primary example, deciding which already-competing packets get serviced first when there simply isn’t enough capacity for everyone right now.

Congestion avoidance describes proactive techniques aimed at preventing a link from reaching full congestion in the first place. A commonly referenced example (useful for conceptual recognition at this level) is Weighted Random Early Detection (WRED), which begins selectively dropping some lower-priority packets before a queue completely fills, as a queue’s fill level rises past certain thresholds — the idea being that a small number of early, deliberate drops (which well-behaved transport protocols like TCP will react to by slowing down their sending rate) can prevent the much worse scenario of a queue overflowing completely and dropping everything indiscriminately once it’s full.

The distinction to keep straight: management works during congestion, deciding who goes first; avoidance works before full congestion, trying to prevent the worst-case scenario from happening at all.

Policing vs. Shaping: The Most Frequently Tested Pair in This Objective

Both policing and shaping enforce a rate limit — neither allows traffic to exceed a configured threshold indefinitely — but they respond to traffic that exceeds that rate in fundamentally different ways, and this distinction is one of the most reliably tested conceptual pairs in the entire IP Services domain.

Policing enforces a strict, hard rate limit. The moment traffic exceeds the configured rate, the excess is handled immediately — typically dropped outright, or in some configurations, re-marked to a lower-priority classification instead of being dropped. There’s no buffering, no smoothing, no delay involved; policing’s response happens at the exact instant a violation occurs, and once that instant passes, it’s over — the decision has already been made.

Shaping also enforces a rate, but handles excess traffic completely differently: rather than dropping it, shaping buffers and delays the excess, releasing it later, smoothed out over time, in a way that conforms to the configured rate rather than exceeding it. Shaping is often implemented using a token bucket mechanism conceptually — tokens accumulate at a steady rate representing permitted transmission capacity, and traffic can only be sent when enough tokens are available, with excess traffic held in a buffer until new tokens accumulate rather than being thrown away immediately.

A brief concrete illustration makes this easier to hold onto: imagine a bucket that fills with tokens at a steady rate matching the configured shaping rate, and each byte of traffic sent consumes one token. If traffic arrives faster than tokens accumulate, the excess simply waits in a buffer until enough new tokens have arrived, then gets sent — smoothing a sudden burst out into a steadier stream over a slightly longer window, rather than either dropping it outright or letting it blast through at full burst speed regardless of the configured limit.

The practical consequence of this difference matters: policing is simpler and doesn’t introduce any additional delay to traffic that stays within the configured rate, but it can be harsh on bursty traffic that briefly exceeds the rate even if its average rate over time is genuinely fine — those bursts get dropped rather than smoothed out. Shaping is gentler on legitimate bursts, smoothing them out rather than discarding them, at the cost of some added latency for the buffered excess and additional memory required to hold that buffered traffic.

A simple, reliable way to keep the two straight for exam purposes: if a scenario describes traffic being dropped immediately upon exceeding a rate, that’s policing. If it describes traffic being delayed or buffered to smooth out a burst, that’s shaping.

Common Misconceptions

• “Per-hop behavior means all devices along a path coordinate their QoS treatment together.” The opposite is true — each device makes its own independent, local treatment decision based purely on how a packet is marked, without coordinating with other devices or tracking the packet’s full path.
• “CoS marking survives across a routed network the same way DSCP does.” CoS is a Layer 2 marking within an 802.1Q tag and doesn’t survive being routed, since routing rebuilds Layer 2 framing at each hop; DSCP, being part of the IP header itself, does persist end to end.
• “Congestion management and congestion avoidance are the same thing, just different names.” Management handles traffic that’s already competing during active congestion (queuing); avoidance proactively tries to prevent full congestion from occurring at all (mechanisms like WRED).
• “Policing and shaping produce the same outcome for traffic exceeding the configured rate, just with different terminology.” They produce genuinely different outcomes — policing drops or re-marks excess traffic immediately, while shaping buffers and delays it, releasing it later rather than discarding it.
• “QoS decides which path a packet takes.” That’s routing’s job, covered under objective 3.2’s forwarding-decision hierarchy. QoS operates after the path has already been chosen, governing how a packet is treated relative to other traffic competing for the same outbound link.

Configuration and Verification at a Conceptual Level

This objective focuses on explaining PHB conceptually rather than a full configuration walkthrough, but seeing the basic building blocks grounds the theory. Cisco IOS implements classification, marking, and policy application through a three-part structure: a class-map defines what traffic to match, a policy-map defines what to do with matched traffic, and a service-policy applies that policy to an interface.

class-map match-any VOICE-TRAFFIC
 match dscp ef
policy-map QOS-POLICY
 class VOICE-TRAFFIC
  priority percent 20
 class class-default
  fair-queue
interface GigabitEthernet0/1
 service-policy output QOS-POLICY

Here, traffic already marked with DSCP value ef (Expedited Forwarding, a standard marking commonly used for voice) is matched by the class-map, guaranteed 20% of the interface’s bandwidth with priority treatment in the policy-map, and the whole policy is applied outbound on the interface. Everything else falls into class-default and is handled with basic fair-queuing rather than priority treatment.

Verification confirms whether this policy is actually doing anything:

Router# show policy-map interface GigabitEthernet0/1
  Service-policy output: QOS-POLICY
    Class-map: VOICE-TRAFFIC (match-any)
      1542 packets, 987456 bytes
      Priority: 20% (200 Kbps), bandwidth
    Class-map: class-default (match-any)
      8213 packets, 6543210 bytes

Rising packet and byte counters under the VOICE-TRAFFIC class confirm traffic is actually being matched and receiving priority treatment, rather than silently falling through into the default class — a stalled counter here despite voice traffic clearly present on the network points toward a classification or marking mismatch rather than a queuing configuration problem.

Troubleshooting Patterns

“Voice quality is poor despite a QoS policy being configured.” Confirm traffic is actually being matched by the intended class — check show policy-map interface for rising counters in the voice-specific class rather than everything falling into class-default, which would indicate a classification or marking mismatch upstream rather than a queuing problem on this specific device.

“QoS marking seems to disappear somewhere along the path.” If the marking in question is CoS rather than DSCP, this is expected once traffic crosses a Layer 3 boundary — CoS doesn’t survive routing. If DSCP marking is unexpectedly missing, check whether an upstream device is configured to trust incoming markings or is instead overwriting/clearing them, which some devices do by default at an untrusted boundary.

“Bursty traffic that should be within its average rate is being dropped.” This is a classic symptom of policing rather than shaping being applied to that traffic class — if smoothing occasional legitimate bursts rather than dropping them is the goal, shaping is the more appropriate mechanism.

“A queuing policy is configured, but low-priority traffic never seems to get serviced at all during sustained congestion.” This can indicate a priority queue that’s been allowed to consume more bandwidth than intended, effectively starving lower-priority classes — reviewing the actual bandwidth guarantees and limits configured per class, rather than just confirming a policy exists, is the appropriate next troubleshooting step.

Frequently Asked Questions

Does every device along a path need to apply the same QoS policy for PHB to work?

No — each device applies its own configured policy based on the marking it sees, independently. Consistent end-to-end treatment requires each device to be configured sensibly with respect to the same marking scheme, but there’s no requirement for identical configuration at every hop; PHB’s whole design assumes independent, local decisions.

Can a device both police and shape traffic simultaneously?

They’re typically applied at different points for different purposes rather than combined on the exact same traffic in the same direction, but a network can certainly use policing at one point (say, an ingress boundary) and shaping at another (an egress link to a slower downstream connection) as part of an overall QoS design.

Is DSCP marking trusted automatically by every device that sees it?

Not necessarily — a device at a network boundary can be configured to trust incoming markings from an internal, controlled source while remarking or clearing markings from an external, untrusted source, since blindly trusting arbitrary incoming markings would let anyone claim high-priority treatment for their own traffic.

What happens to traffic that doesn’t match any specific classification?

It typically falls into a default class (class-default in Cisco’s model) and receives best-effort treatment — not necessarily dropped, but not given any priority guarantee either.

Why does shaping require a buffer while policing doesn’t?

Shaping’s entire mechanism depends on holding excess traffic temporarily until it can be released within the configured rate, which inherently requires somewhere to hold that traffic; policing makes an immediate drop-or-remark decision with nothing to hold onto afterward.

Summary

• Per-hop behavior means each device along a path independently decides how to treat a packet based on its marking, without coordinating with other devices — a deliberately lightweight, scalable model.
• Classification identifies traffic type; marking (DSCP at Layer 3, CoS at Layer 2) tags that classification directly onto the packet or frame so downstream devices don’t need to reclassify it themselves. DSCP persists across routed paths; CoS does not.
• Queuing prioritizes classified traffic during congestion; congestion management (queuing) handles traffic once congestion exists, while congestion avoidance (like WRED) proactively tries to prevent full congestion from happening at all.
• Policing drops or re-marks traffic immediately upon exceeding a configured rate; shaping buffers and delays excess traffic, smoothing it out over time instead of discarding it — the single most frequently tested distinction in this objective.
• QoS and routing answer different questions: routing decides which path a packet takes, while QoS (per-hop behavior) decides how that packet is treated relative to other traffic once the path is already chosen.