Skip to content
Study CCNP

Interpret

1.4 Interpret QoS configurations

4 min read ENCOR 350-401 v1.2 Updated

Aligned to Cisco's 350-401 ENCOR v1.2 exam topics.

On this page

What this objective tests

The blueprint verb is interpret. Read a Quality of Service (QoS) configuration and explain three things: which traffic matches, what happens during congestion, and which counters prove it.

QoS has four jobs:

  • Classify traffic.
  • Mark or trust markings.
  • Queue and schedule traffic during congestion.
  • Police or shape traffic to a rate.
Packet arrives
     |
     v
classify (class-map) -> mark/trust DSCP
     |
     v
queue/schedule on congested egress (policy-map)
     |
     v
optional police/shape toward provider rate
     |
     v
counters in "show policy-map interface" prove which class matched

Classification and marking

Classification decides what a packet is. Marking writes that decision into a field like the Differentiated Services Code Point (DSCP). The trust boundary is where the network starts to believe or overwrite endpoint markings.

class-map match-any VOICE
 match dscp ef

class-map match-any BUSINESS-DATA
 match dscp af31
 match access-group name BUSINESS-APPS

ip access-list extended BUSINESS-APPS
 permit tcp any any eq 443

Read it this way: VOICE matches DSCP EF. BUSINESS-DATA matches DSCP AF31 or HTTPS.

match-any means one true statement classifies the packet. match-all means every statement must be true. A class can match nothing because the logic is too strict. A class can match too much because an ACL is too broad.

Example: queuing policy on a WAN edge

Scenario: a branch router has a 100 Mbps WAN circuit on GigabitEthernet0/0/0. Voice needs priority. Business data needs a guaranteed share during congestion.

policy-map WAN-OUT
 class VOICE
  priority percent 10
 class BUSINESS-DATA
  bandwidth percent 30
 class class-default
  fair-queue

interface GigabitEthernet0/0/0
 description WAN edge
 service-policy output WAN-OUT

Interpret the policy:

  • VOICE enters a low-latency priority queue during congestion.
  • priority percent 10 also polices the priority class at 10 Mbps. Voice cannot starve the other classes.
  • bandwidth percent 30 guarantees 30 Mbps during congestion. It is not a speed limit on an idle link.
  • The policy acts on outbound traffic only. It does nothing to traffic that enters from the WAN.

Policing and shaping are different tools. Policing drops or remarks excess traffic. Shaping buffers traffic toward a rate. Shape when you send into a slower provider circuit.

policy-map INTERNET-IN
 class BUSINESS-DATA
  police cir 10000000
   conform-action transmit
   exceed-action drop

Example: expected output

The counters tell you whether traffic matches and whether drops happen.

R1# show policy-map interface GigabitEthernet0/0/0
 GigabitEthernet0/0/0

  Service-policy output: WAN-OUT

    Class-map: VOICE (match-any)
      15234 packets, 3046800 bytes
      5 minute offered rate 51000 bps, drop rate 0000 bps
      Match:  dscp ef (46)
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 15234/3046800

    Class-map: BUSINESS-DATA (match-any)
      40210 packets, 48252000 bytes
      5 minute offered rate 820000 bps, drop rate 12000 bps
      Match:  dscp af31 (26)
      Match: access-group name BUSINESS-APPS
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 12/1200/0
      (pkts output/bytes output) 39010/46812000

    Class-map: class-default (match-any)
      90311 packets, 54186600 bytes
      Match: any

Read the output:

  • VOICE counters increase and drops stay at zero. Voice matches, and the priority queue protects it.
  • BUSINESS-DATA shows 1200 drops. Congestion exists, the guarantee is too small, or the ACL matches too much.
  • A class with zero packets does not match. Check the DSCP values and the ACL.

Read counters in this order:

  1. Is the service policy on the correct interface and direction?
  2. Do the class packet counters increase?
  3. Are the drops in the class queue, the policer, or the physical interface?
  4. Is the link congested when the drops occur?
  5. Does the class-map logic explain the matched traffic?

Lab: prove QoS behavior

Topology:

PC1 (10.10.10.50) -- Gi0/0/1 [R1] Gi0/0/0 -- [R2] loopback 192.0.2.1
                         WAN-OUT applied outbound on Gi0/0/0

Do these steps:

  1. Configure the class-maps and the WAN-OUT policy from the example on R1.
  2. Attach the policy outbound on GigabitEthernet0/0/0.
  3. Send traffic marked EF from PC1 toward 192.0.2.1. Use extended ping with DSCP if no generator exists.
  4. Send traffic marked AF31 at the same time.
  5. Run show policy-map interface GigabitEthernet0/0/0 twice, 30 seconds apart.
  6. Confirm the VOICE and BUSINESS-DATA counters increase between the two runs.

Answer these questions from the output, not from memory:

  • Which class matched the voice packets?
  • Which class dropped packets?
  • Is the policy inbound or outbound?
  • Does the bandwidth guarantee matter on an idle link?

Useful commands:

show class-map
show policy-map
show policy-map interface
show access-lists
show interfaces GigabitEthernet0/0/0 | include rate|drop|queue

Exam traps

  • bandwidth percent is a minimum during congestion, not a cap.
  • The priority queue is policed. Too much marked voice still drops.
  • Direction matters. An output policy cannot queue inbound traffic.
  • Zero packets in a class means no match. Check match-any versus match-all first.

Pass check

You are ready when you can read a class-map, a policy-map, and an interface attachment and say: this traffic matches here, this action happens during congestion, this counter proves it, and this is the likely mistake.

Related objectives