2.1 QoS Components: Classification, Marking & Trust Boundaries

2.1 QoS Components: Classification, Marking & Trust Boundaries

ENCOR v1.2 topic 1.4 is worded precisely: "Interpret QoS configurations." The verb matters. Cisco is not asking you to design a queuing strategy from scratch; it is asking you to look at a policy-map, a show policy-map interface counter block, or a switchport trust statement and correctly predict what happens to a packet. Everything in this section and the next exists to make that prediction reliable.

1. The Four Impairments QoS Actually Manages

QoS cannot create bandwidth. It can only decide who suffers first when a link is oversubscribed. There are exactly four impairments:

These thresholds come from the long-standing Cisco design guidance derived from ITU-T G.114 and they show up constantly in scenario stems. When a question says "voice calls are choppy but throughput tests pass", it is describing jitter, not bandwidth. When it says "callers hear each other talk over one another", it is describing delay.

2. Three QoS Models

DiffServ won because it pushes complexity to the network edge. The edge classifies and marks once; every downstream hop simply reads the mark and applies a Per-Hop Behaviour (PHB). That single sentence is the conceptual core of topic 1.4.

3. Marking Fields: Where the Bits Live

  LAYER 2 (802.1Q tagged frame)                LAYER 3 (IPv4 header, byte 2)
  +--------+--------+------------+             +---------------------------------+
  | TPID   | PCP|DEI|   VLAN ID  |             |  DSCP (6 bits)  |  ECN (2 bits) |
  | 0x8100 | 3b | 1b |   12 bits  |             |   0 .. 63       |    0 .. 3     |
  +--------+--------+------------+             +---------------------------------+
            ^                                   ^
            |                                   |
         CoS / 802.1p                    Formerly "IP Precedence" was the
         values 0-7                      top 3 bits of this same byte

The single most common design error the exam probes: a marking placed only in CoS is destroyed the moment the frame crosses a routed hop or leaves a trunk, because CoS lives in the 802.1Q tag. Mark in DSCP if the value must survive end to end.

DSCP-to-CoS mapping is lossy

Mapping 6 bits into 3 bits cannot be reversible. The default Cisco behaviour takes the three most significant DSCP bits, which is equivalent to the old IP Precedence value. So DSCP 46 (EF, binary 101110) maps to CoS 5, and DSCP 34 (AF41, binary 100010) also maps to CoS 4 — and AF41, AF42, and AF43 all collapse onto the same CoS. Drop-precedence granularity does not survive the mapping.

4. DSCP Arithmetic and the Standard PHBs

You must be able to convert between the DSCP name and its decimal value without a lookup table.

Class Selector (CS) PHBs

CS values are backward compatible with IP Precedence: the top 3 bits carry the precedence and the low 3 bits are zero. Therefore CSn = n x 8.

Assured Forwarding (AF) PHBs

The AF name is AFxy where x is the AF class (1-4, meaning increasing queue priority) and y is the drop precedence (1 = lowest chance of being dropped, 3 = highest). The encoding is xxxyy0, which gives the formula AFxy = 8x + 2y.

Worked example: AF31 is class 3, drop precedence 1, so binary 011 01 0 = 26. Worked example: AF43 is class 4, drop precedence 3, so binary 100 11 0 = 38. The formula 8x + 2y reproduces both: 8(3) + 2(1) = 26 and 8(4) + 2(3) = 38.

Expedited Forwarding (EF)

EF = DSCP 46 = binary 101110. EF is the single PHB defined for low-loss, low-latency, low-jitter service and is reserved for voice bearer traffic. It is deliberately not a CS value and not an AF value — memorise 46 outright. The higher-order bits 101 are why EF maps down to CoS 5.

5. RFC 4594 Marking Recommendations Used in Cisco Designs

Exam-relevant asymmetry: signalling is CS3 while the media it sets up is EF. Losing signalling breaks call setup; losing bearer breaks audio. They are marked differently on purpose so they can be queued differently.

6. Trust Boundaries

A trust boundary is the point at which the network begins believing the QoS markings inside arriving packets. Everything outside the boundary is untrusted and gets re-marked or zeroed.

+---------------------------------------------------------------------------+
|            WHERE TO PUT THE TRUST BOUNDARY (best -> acceptable)           |
+---------------------------------------------------------------------------+
|  BEST:  IP phone           -- trusted endpoint you administer             |
|  GOOD:  Access switchport  -- classify/mark here with an ingress policy   |
|  OK:    Distribution layer -- further from the source, more traffic to    |
|                               classify, more CPU/TCAM per policy          |
|  NEVER: Trust a PC, a printer, or anything a user can reconfigure         |
+---------------------------------------------------------------------------+

The governing principle is "trust as close to the source as possible, but never trust a device you do not administer." A user workstation can set DSCP 46 on a torrent client trivially; if the access port trusts DSCP, that torrent lands in the voice priority queue.

The three switchport trust states

• Untrusted (default on Catalyst access ports) — incoming CoS and DSCP are overwritten with 0. Safe, but it also destroys legitimate endpoint markings.
• Unconditional trust — trust dscp or trust cos accepts whatever arrives. Appropriate only on uplinks toward other switches you administer, or toward a server you control.
• Conditional trust — the port trusts markings only after the attached device identifies itself over CDP or LLDP-MED. On IOS-XE the modern syntax is trust device cisco-phone (also cts, ip-camera, media-player). If the phone is unplugged and a laptop is connected in its place, CDP/LLDP-MED verification fails and the port silently reverts to untrusted. This is the elegant answer to the "phone plus daisy-chained PC" topology, and it pairs naturally with the voice VLAN behaviour covered in Section 7.1.

7. Classification vs. Marking, and the MQC That Expresses Them

These two words are not synonyms and the exam separates them.

• Classification answers "which bucket is this packet in?" It inspects something — an ACL, a DSCP value, an incoming interface, or an NBAR2 application ID — and assigns the packet to a class. Classification changes nothing in the packet.
• Marking answers "what value should I write so downstream hops do not have to re-inspect?" It rewrites DSCP, CoS, or MPLS EXP.

The Modular QoS CLI (MQC) is the three-step construct that carries both. You have already met it in a security context in Section 16.3, where CoPP uses exactly the same grammar.

! STEP 1 - class-map: CLASSIFY. 'match-any' = logical OR, 'match-all' = logical AND.
class-map match-any VOICE-BEARER
 match dscp ef
 match protocol rtp audio
!
class-map match-any CALL-SIGNALLING
 match dscp cs3
 match protocol sip
!
class-map match-all TRANSACTIONAL-ERP
 match access-group name ERP-SERVERS
 match protocol http
!
! STEP 2 - policy-map: decide the ACTION per class
policy-map INGRESS-MARK
 class VOICE-BEARER
  set dscp ef
 class CALL-SIGNALLING
  set dscp cs3
 class TRANSACTIONAL-ERP
  set dscp af21
 class class-default
  set dscp default
!
! STEP 3 - service-policy: ATTACH, in exactly one direction
interface GigabitEthernet1/0/12
 description Access port - user + phone
 trust device cisco-phone
 service-policy input INGRESS-MARK

Reading that policy the way the exam wants

1. match-any in VOICE-BEARER means a packet qualifies if it carries DSCP EF or NBAR2 identifies it as audio RTP.
2. match-all in TRANSACTIONAL-ERP means the packet must match the ERP-SERVERS ACL and be identified as HTTP. Miss either condition and it falls through.
3. Classes are evaluated top to bottom, first match wins. Reordering the classes changes behaviour.
4. class-default catches everything unmatched. Here it is explicitly re-marked to DF, which is the correct hardening posture at a trust boundary: anything you did not deliberately recognise loses its markings.
5. service-policy input applies on ingress only. A separate service-policy output would be required to queue on egress — and queuing is an egress-only action, which is the subject of Section 2.2.