Interpreting QoS Configurations: An ENCOR Exam Skill Guide

The ENCOR blueprint has a specific, easily-underestimated line: "interpret QoS configurations." Not design them, not configure them from scratch, but read an existing policy and a show output and say what it does and whether it is working. This is a distinct skill, and it is where a lot of otherwise-prepared candidates lose marks, because reading someone else's QoS policy under time pressure is harder than writing your own.

This article is a method for interpreting QoS configurations and output, using the real policy from this cluster. It extends the QoS cluster guide.

Reading a policy-map: A Repeatable Method

Given an unfamiliar policy-map, work through it in a fixed order and it stops being intimidating:

1. List the classes. Each class line is a category of traffic. How many are there, and is there a class-default (there always is, explicitly or implicitly)?
2. For each class, find how it is matched. Trace back to the class-map: what match statement selects the traffic (DSCP, ACL, protocol)?
3. For each class, identify the action. priority, bandwidth, police, shape, set, random-detect, each is a different behaviour with different implications.
4. Check the numbers add up. Do the priority and bandwidth percentages fit within the reservable bandwidth? Is anything over-allocated?

Apply it to the cluster's policy:

policy-map WAN-EDGE
 class EF-VOICE
  priority percent 20
 class BULK-DATA
  bandwidth percent 40
  random-detect dscp-based
 class class-default
  fair-queue
  random-detect

Walk the method: three classes (EF-VOICE, BULK-DATA, class-default). Matched by DSCP EF, DSCP AF11, and everything-else respectively (from the class-maps). Actions: EF-VOICE gets strict-priority queueing (LLQ), BULK-DATA gets a 40% bandwidth guarantee plus WRED, class-default gets fair-queueing plus WRED. Numbers: 20% priority + 40% bandwidth = 60%, comfortably within the default 75% reservable. In four steps you have fully understood a policy you had never seen.

Recognise the Action Verbs Instantly

Interpretation speed comes from recognising each action's meaning without thinking:

Two pairs are the classic exam traps. priority vs bandwidth: a fast lane with a latency guarantee versus a reserved minimum with none. police vs shape: drop the excess versus buffer it. If you can tell each pair apart on sight, most QoS interpretation questions answer themselves.

Reading show policy-map interface

The other half of interpretation is reading the operational output to answer "is it working?" This is where the real signal lives. Here is the cluster's EF class under load:

Class-map: EF-VOICE (match-all)
  1125 packets, 1673362 bytes
  5 minute offered rate 37000 bps, drop rate 0000 bps
  Match:  dscp ef (46)
  Priority: 20% (2000 kbps), burst bytes 50000, b/w exceed drops: 0

What each line tells you:

Reading this specific output: 1125 packets matched (classification works), 0 drop rate and b/w exceed drops: 0 (the priority class is healthy and protected), matched on DSCP EF (as intended). Verdict: the policy is working and voice is protected. That is the exact kind of judgment the exam asks for.

The Diagnostic Questions

When a question shows you output and asks what is wrong, these are the tells:

• A class with 0 packets that should have traffic: the classification is broken. The match statement does not match the real traffic (wrong DSCP, wrong ACL). This is the most common QoS fault and a favourite exam scenario.
• A non-zero drop rate on a class you expected to be protected: either the class is over-subscribed (offered rate exceeds its allocation) or, for a priority class, traffic is exceeding the policer (b/w exceed drops climbing).
• Traffic landing in class-default that you expected in a named class: again, classification. The traffic is not being marked or matched as intended and is falling through to the catch-all.
• The policy not applied at all: show policy-map interface returns nothing for the interface. The service-policy is missing, or on the wrong interface/direction.

Almost every "why is QoS not working" answer is one of two things: the traffic is not classified as you think (check packet counts and the Match line), or the policy is not applied where the traffic egresses. Check those two first, always.

FAQ

How do I read a policy-map I have never seen?

Four steps: list the classes, find how each is matched (trace to the class-map), identify each action verb, and check the percentages add up within the reservable bandwidth. In order, it is mechanical.

What is the fastest way to tell priority from bandwidth?

priority is a policed fast lane with a latency guarantee (voice). bandwidth is a guaranteed minimum share with no latency guarantee (data). Fast lane vs reserved minimum.

A class shows 0 packets. What does that mean?

Nothing is matching it, so the classification is broken. The match statement does not match the real traffic. This is the single most common QoS fault.

What does "b/w exceed drops" tell me?

On a priority (LLQ) class, how many packets exceeded the policer and were dropped. Zero is healthy. A rising number means the priority traffic is exceeding its reservation and being policed.

How do I know if the policy is even applied?

show policy-map interface <intf>. If it returns nothing, the service-policy is missing or on the wrong interface or direction (remember: queueing is output).

Key Takeaways

• "Interpret QoS configurations" is a real, distinct exam skill: read an existing policy and output, not build one from scratch.
• Read a policy-map in four steps: list classes, find the match, identify the action verb, check the numbers.
• Recognise the verbs on sight. The traps: priority vs bandwidth (fast lane vs reserved minimum) and police vs shape (drop vs buffer).
• In show policy-map interface, the key signals are packet counts (is it classifying?), drop rate (is it dropping?), and b/w exceed drops (is the priority class healthy? 0 = yes).
• Most "QoS not working" answers are one of two things: traffic not classified as expected (0 packets, wrong Match) or policy not applied where traffic egresses.

Next: LLQ and CBWFQ in depth, or the QoS cluster guide.