QoS Classification, Marking, and Trust Boundaries

Classification, marking, and the trust boundary together form the policy edge of every QoS deployment. Get them right and the rest of QoS is mechanics. Get them wrong and you spend the next year chasing weird voice quality issues that always seem to happen when no one is around to capture packets.

This article walks through what classification really means, how marking fits in, where to place trust boundaries, and the production patterns for the three or four scenarios you will actually encounter in an enterprise network. If you are building a new QoS deployment, auditing an existing one, or trying to figure out why a single user's traffic is somehow getting EF-class treatment, this is the discipline.

What Classification and Marking Are

Classification is the act of identifying what kind of traffic a packet represents. Voice? Video? Salesforce? Bulk backup? The output of classification is conceptual: "this packet belongs to class X."

Marking is the act of writing that classification into the packet itself, in a field every downstream device can read without redoing the classification work. The output of marking is a bit pattern: a DSCP value in the IP header, a CoS value in the 802.1Q tag, or an MPLS EXP value in the MPLS label.

The two are usually paired: classify and mark in one configuration step at the network edge, then trust the marks throughout the rest of the path.

Why Mark at the Edge?

Classification is expensive. Pattern matching on application signatures (NBAR), running ACLs against every packet, keeping flow state - all of that costs CPU and memory. On a busy WAN edge, classification can be the dominant cost.

Marking shifts the cost from "every device re-classifies every packet" to "one device classifies, every device reads a few bits." This is what makes end-to-end QoS practical. A 1 Gbps link sees millions of packets per second; reading 6 bits of DSCP and indexing into a queue is much cheaper than parsing payloads.

The discipline that makes this work: edge marking must be correct and trustworthy. If your edge marks 50 percent of voice traffic correctly and 50 percent as best-effort, your QoS policy is broken regardless of how clever your queueing config is.

Where to Classify and Mark

The general rule: as close to the traffic source as possible, on a device you trust to do it correctly. Three classification sources, in priority order:

1. The source application itself. Some applications mark their own DSCP correctly. Cisco IP phones do this for voice. Microsoft Teams sets DSCP markings for media. Modern enterprise apps from major vendors increasingly do.
2. The first-hop infrastructure. Access switch ports for end hosts; WAN edges for inbound flows from outside the network. Classify and mark at this point if the source did not, or if you do not trust the source's markings.
3. Mid-network NBAR-based classification. When a flow has crossed several hops without being marked correctly. Less ideal than edge marking but sometimes necessary for cloud-native traffic.

The classic anti-pattern: classifying at every hop because you do not trust any prior hop. This works but is operationally expensive and indicates that your trust model is broken.

The Trust Boundary

The trust boundary is the perimeter inside which DSCP markings are honored. Outside the boundary, markings are suspect (or rewritten). Inside, every device respects the marks and applies policy accordingly.

Common trust boundary placements:

The classic failure mode: a user marks every packet from their PC as DSCP EF (voice). Without re-marking at the access port, that PC's traffic gets priority queueing and starves the legitimate voice traffic. The fix: never trust DSCP from generic end hosts. Re-mark to BE or BG by default; trust only via the IP phone's conditional-trust mechanism for known traffic flows.

Cisco IOS XE Configuration: The Patterns

Three patterns cover most enterprise access ports.

Pattern 1: Untrusted Access Port (Generic PC)

interface GigabitEthernet1/0/3
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 spanning-tree bpduguard enable
 ! No QoS trust - default behavior is to re-mark to 0 (BE)

By default on Cisco access ports, incoming DSCP is rewritten to 0. No explicit configuration required. Verify with:

Switch# show mls qos interface GigabitEthernet1/0/3
GigabitEthernet1/0/3
 trust state: not trusted
 trust mode: not trusted

Pattern 2: IP Phone with PC Behind It (Conditional Trust)

interface GigabitEthernet1/0/5
 switchport mode access
 switchport access vlan 10                ! Data VLAN
 switchport voice vlan 20                 ! Voice VLAN
 mls qos trust device cisco-phone         ! Conditional trust via CDP
 spanning-tree portfast
 spanning-tree bpduguard enable

The mls qos trust device cisco-phone tells the switch to trust DSCP/CoS only when CDP detects a Cisco IP phone on the port. If the phone is unplugged, the switch reverts to untrusted and rewrites DSCP to 0.

The IP phone itself handles the per-VLAN trust: it tags its own voice traffic with DSCP EF on VLAN 20, and forwards PC traffic from the data VLAN unchanged (which the access port then re-marks because the PC is untrusted).

Pattern 3: Explicit Classification and Marking

For traffic the source did not mark and you cannot use simple trust:

! Define classes
class-map match-any VOICE
 match protocol rtp audio                 ! NBAR-based
class-map match-any VIDEO-CONF
 match protocol rtp video
class-map match-any TRANSACTIONAL
 match access-group name SALESFORCE-IPS
class-map match-any SCAVENGER
 match access-group name BACKUP-IPS

ip access-list extended SALESFORCE-IPS
 permit ip any 13.108.0.0 0.0.255.255
ip access-list extended BACKUP-IPS
 permit tcp any any eq 873                ! rsync

! Define actions
policy-map MARK-INGRESS
 class VOICE
  set dscp ef
 class VIDEO-CONF
  set dscp af41
 class TRANSACTIONAL
  set dscp af21
 class SCAVENGER
  set dscp cs1
 class class-default
  set dscp default

! Apply at ingress
interface GigabitEthernet0/0/2
 service-policy input MARK-INGRESS

This pattern is common at WAN edges where the upstream did not mark. NBAR2 (with match protocol) handles application-aware classification for hard-to-pin-down apps. The full MQC walkthrough is in Cisco MQC: The Operator's Walkthrough.

Standardized Marking Values

Use standardized DSCP values everywhere. The DSCP article has the full reference. The minimum set for any production QoS deployment:

Defining your own arbitrary DSCP values (like 35 because "it's between AF31 and AF41") will cause grief. Stick to the standardized PHBs. Every Cisco platform has built-in QoS maps for these values; non-standard values do not get the same hardware acceleration.

Layer 2: CoS and the 802.1Q Connection

CoS (802.1p Priority) lives in the 802.1Q tag, three bits, 8 values. Inside switched Layer 2 segments, CoS is what gets honored. Across Layer 3 hops, the 802.1Q tag is stripped and only DSCP survives.

Cisco's standard mapping derives CoS from the top three bits of DSCP:

You can override the mapping with mls qos map dscp-cos or equivalent on the platform. Most production deployments leave it at default. See 802.1Q VLAN Tag Explained for where CoS lives in the frame.

Auditing an Existing Trust Boundary

Three things to verify on any existing deployment:

1. Every access port for end hosts is untrusted. show mls qos interface GigabitEthernet1/0/3 should show "trust state: not trusted" or equivalent. If it shows "trust dscp" without conditional trust, end hosts can mark whatever they want.
2. Voice VLAN trust is conditional, not absolute. Verify with show interfaces switchport that voice VLAN config exists, and show mls qos interface that conditional trust (cisco-phone) is configured rather than absolute trust.
3. WAN edges re-validate inbound markings. Verify with show policy-map interface that an input service-policy exists and the class hit counts make sense.

The single most common audit finding: an access port that was configured for an IP phone five years ago, the phone got swapped for a USB phone or a softphone on the PC, and the trust setting was never updated. Now that PC's marked-as-EF traffic gets priority over real voice. The fix: re-audit periodically.

Re-marking at the Trust Boundary

Two re-marking patterns are common:

Strict re-marking (paranoid). Default-deny-style: mark everything to BE on ingress, except specific traffic that matches your classification rules. Best for high-security environments where you cannot tolerate untrusted markings escaping into the QoS domain.

Permissive re-marking (pragmatic). Trust DSCP from designated sources, re-mark only obvious abuse (anything from end-host PCs marked above CS3, for example). Fewer rules; works well when you have control over most sources.

Most production deployments use permissive on internal trunks and strict at WAN edges. The cost-benefit shifts based on what is on the other side.

Anti-Patterns to Avoid

• Trusting CoS from end hosts. CoS only exists on tagged frames. End hosts on access ports send untagged frames, so CoS is moot - but if a malicious user sends tagged frames (a misconfigured VM, an attacker), trusting CoS lets them choose their own queue.
• Re-marking at every hop. Operationally wasteful. Indicates that the trust model is broken.
• Mixing marking schemes. Different parts of the network using different DSCP values for the same traffic class. One sub-network uses AF31 for streaming video; another uses CS5; queueing policies have to handle both. Standardize.
• Defining custom DSCP values for "special" traffic. The standardized PHBs cover everything. Custom values do not get hardware acceleration on most platforms.
• Relying on application markings without validation. "Microsoft Teams sets DSCP correctly" is true 95 percent of the time. The other 5 percent is misconfigured Teams clients sending video as best-effort. NBAR-based classification at the edge as a backstop catches it.

Summary

Classification and marking at the trust boundary are the foundation of every QoS deployment. Classify and mark once at a controlled edge, trust those markings throughout the QoS domain, and re-mark or re-validate at any boundary where trust changes. The standard Cisco patterns (untrusted access port, conditional trust for IP phones, explicit MQC classification at WAN edges) cover most enterprise scenarios.

The discipline matters more than the configuration. Audit the trust boundaries periodically. Standardize on the IETF PHBs. Never trust DSCP from generic end hosts. Bookmark this article alongside the QoS cluster pillar and the DSCP article for the marking values, and the Cisco MQC walkthrough for the configuration grammar.