The QoS trust boundary: where markings should be set and where rewritten

The QoS trust boundary defines where your network begins to trust and act on quality-of-service markings. Understanding this boundary is critical for proper QoS implementation: mark too early and untrusted sources pollute your policies; mark too late and you lose visibility into application intent. This guide explains where markings should originate, where they should be rewritten, and how to design a trust boundary that works.

What is the QoS trust boundary?

The trust boundary is the network edge point where you decide to accept or ignore QoS markings from a source. Beyond this boundary, markings are trusted and used for forwarding decisions. Before this boundary, markings are either ignored, rewritten, or validated.

In most enterprise designs, the trust boundary sits at the access switch port or the device itself. Markings from end hosts (PCs, phones, IoT devices) are typically not trusted because they may be misconfigured, compromised, or simply not QoS-aware. Markings from managed infrastructure (servers, network appliances, VoIP phones with trusted firmware) may be trusted closer to the source.

Where to set markings: the origination point

QoS markings should be set as close as possible to the source of the traffic, but only if that source is trusted or the marking is validated by policy.

• →End-host marking (Layer 3 DSCP): Set by the application or OS. Useful for enterprise applications that understand their own priority, but not trusted from untrusted endpoints.
• →Access switch marking (Layer 2 CoS): Set based on access control lists, NBAR, or static port policy. This is where most enterprises enforce the trust boundary.
• →Distribution or core marking: Rewrite or validate markings from access switches. Rarely the origination point for initial marking.
• →Network device marking (routers, firewalls): Often trusted because these are managed infrastructure. DSCP markings from routers are typically accepted downstream.

Trust boundary design patterns

Three common patterns determine where your trust boundary sits:

• →Untrusted access: All end-host markings are ignored. The access switch re-marks all traffic based on policy. This is the safest default.
• →Trusted endpoints: VoIP phones, video conferencing systems, or managed servers are allowed to set DSCP. The access switch trusts and preserves their markings.
• →Conditional trust: Markings are trusted only if they match a whitelist. For example, trust DSCP EF only from known VoIP subnets.

Where to rewrite markings

Rewriting (or re-marking) happens at policy enforcement points, typically at the trust boundary itself or at domain boundaries.

! Cisco IOS access switch: do not trust host DSCP, mark based on ACL
interface GigabitEthernet0/1
 description User access port
 mls qos trust cos
 mls qos cos 0

! Map traffic to CoS based on policy
class-map match-any VOIP_TRAFFIC
 match ip dscp ef
 match protocol sip

policy-map UNTRUSTED_ACCESS
 class VOIP_TRAFFIC
  set cos 5
 class class-default
  set cos 0

service-policy input UNTRUSTED_ACCESS

Rewrite at these points:

• →Ingress on untrusted ports: Clear all markings and apply policy-based markings.
• →Egress at domain boundaries: When traffic leaves your domain (to ISP, partner network, or cloud), rewrite to ensure compliance with external policies.
• →Ingress from external networks: Untrust all inbound markings and re-mark based on your internal policy.
• →Between trust domains: If you segment your network into QoS domains (campus, data center, WAN), rewrite at the boundary.

CoS to DSCP mapping at the boundary

At the trust boundary, Layer 2 CoS markings must be mapped to Layer 3 DSCP for consistency across routed domains. This mapping is often pre-configured but should be validated.

! Cisco IOS: default CoS-to-DSCP mapping
mls qos map cos-dscp 0 8 16 24 32 40 48 56

! This maps:
! CoS 0 -> DSCP 0 (default)
! CoS 1 -> DSCP 8 (CS1)
! CoS 2 -> DSCP 16 (CS2)
! CoS 3 -> DSCP 24 (CS3)
! CoS 4 -> DSCP 32 (CS4)
! CoS 5 -> DSCP 40 (EF)
! CoS 6 -> DSCP 48 (CS6)
! CoS 7 -> DSCP 56 (CS7)

Verify this mapping matches your organization's QoS policy. If you use non-standard DSCP values, customize the mapping.

Best practices for trust boundary implementation

• →Document your trust boundary location in your QoS design document.
• →Default to untrusted at the access layer; trust only where justified.
• →Use NBAR or deep packet inspection to classify traffic, not just end-host markings.
• →Rewrite markings at domain boundaries to prevent external influence on your QoS policy.
• →Monitor and audit QoS markings to detect policy violations or misconfiguration.
• →Test trust boundary policies in a lab before production deployment.