1.4 Interpret QoS configurations

What this objective means

ENCOR says “interpret,” not “design a carrier QoS architecture from scratch.” You need to read a QoS configuration and explain what traffic matches, what happens during congestion, and which counters prove it.

QoS has four basic jobs:

• classify traffic,
• mark or trust markings,
• queue or 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 on "show policy-map interface" prove which class matched

Classification and marking

Classification decides what a packet is. Marking writes that decision into a field such as DSCP. Trust boundary means the point where the network starts believing or overwriting endpoint markings.

Example:

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 this carefully. Voice matches DSCP EF. Business data matches either AF31 or HTTPS by ACL. If the ACL is too broad, the class may catch more than intended.

match-any means any match statement can classify the packet. match-all means every match statement must be true. That distinction matters when a class combines DSCP, ACL, protocol, or input-interface matching. A class-map can look correct but match nothing because the logic is too strict, or match too much because the logic is too broad.

Queuing and scheduling

Queuing matters when there is congestion. A priority queue protects delay-sensitive traffic, but it must be controlled so it does not starve other classes.

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 it this way:

• Voice gets low-latency priority treatment during congestion.
• priority percent 10 creates an LLQ-style priority class and normally polices that priority class so it cannot starve the rest of the policy.
• Business data gets a reserved minimum share during congestion; bandwidth percent is not a permanent speed limit when the interface is uncongested.
• Default traffic gets fair queuing.
• The policy only affects outbound traffic on the interface where it is applied.

Attachment direction is part of interpretation. An output service policy on the WAN edge shapes or queues traffic as it leaves that interface. It does not classify traffic entering from the WAN in the opposite direction.

Policing and shaping

Policing enforces a rate by dropping or remarking excess traffic. Shaping buffers traffic to smooth it toward a rate. Policing is harsher. Shaping is usually better when you are sending into a slower provider circuit.

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

Read the counters

The configuration is only half the answer. The counters tell you whether anything is matching and whether drops are happening.

show policy-map interface GigabitEthernet0/0/0

Class-map: VOICE (match-any)
  123456 packets, 98765432 bytes
  Match: dscp ef
  Queueing
  priority level 1
  0 packets dropped

Class-map: BUSINESS-DATA (match-any)
  567890 packets, 345678901 bytes
  1200 packets dropped

If the voice class has zero packets, voice is not matching the policy. If business data is dropping, either congestion exists, the class is undersized, or the matching is too broad.

Read counters in this order:

1. Is the service policy attached to the interface and direction you care about?
2. Are class packet counters increasing?
3. Are drops in the class queue, the policer, or the physical interface?
4. Is the link actually congested when the drops occur?
5. Does the class map match logic explain the traffic that hit the class?

Lab: prove QoS behavior

Build a router with a LAN side and a WAN side. Mark one test flow as EF and another as AF31. Apply an outbound policy to the WAN interface. Generate traffic. Then answer four questions from the output, not from memory.

• Which class matched the voice packets?
• Which class dropped packets?
• Is the policy inbound or outbound?
• Is the rate guarantee relevant when there is no congestion?

Useful commands:

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

Pass check

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