Enterprise Edge FAQ: Best Practices for Deploying QoS Trust Boundaries on Campus Edge Switches

Overview & Thematic Scope

Implementing QoS trust boundaries on campus edge switches is a critical design decision that determines where your network begins to trust packet markings. This FAQ addresses the most common technical and deployment questions network engineers face when configuring trust boundaries at the enterprise edge. Whether you are deploying IP telephony, preparing for unified communications, or hardening your campus QoS architecture, these expert answers will guide your implementation.

Frequently Asked Questions

Q1: What is a QoS trust boundary and why does it matter on campus edge switches?

A QoS trust boundary defines the point in your network where packet markings (DSCP or CoS values) are trusted and preserved rather than re-marked. On campus edge switches, this boundary determines whether the switch trusts markings from connected endpoints like IP phones or re-classifies all traffic itself. Establishing the correct trust boundary is essential because it ensures that priority traffic such as VoIP receives appropriate treatment throughout the network while preventing untrusted devices from manipulating QoS markings to gain unfair bandwidth priority.

Q2: How do I enable QoS globally before configuring trust boundaries on a campus edge switch?

You must explicitly enable QoS globally before any trust boundary configuration takes effect, as QoS is disabled by default on most campus switches. On Cisco Catalyst switches, use the global configuration command mls qos, then verify with show mls qos that QoS is enabled. Note that enabling QoS globally will cause the switch to re-mark all incoming packets by default; if you want to preserve existing DSCP markings, configure no mls qos rewrite ip dscp before proceeding.

Q3: What is the difference between trusted, untrusted, and conditionally-trusted ports?

A trusted port preserves incoming QoS markings, an untrusted port re-marks all traffic, and a conditionally-trusted port applies trust only when a specific device type is detected. By default, all physical ports become untrusted when QoS is enabled, meaning the switch will overwrite incoming DSCP or CoS values. Trusted ports are typically used for connections to servers or uplinks where markings are known to be accurate, while conditionally-trusted ports are ideal for IP phone connections where the switch trusts markings only after detecting a Cisco IP phone via CDP.

Q4: Should I use DSCP or CoS trust mode on campus edge switches?

DSCP-based trust is the recommended best practice for campus edge switches as it provides higher classification granularity than CoS. DSCP operates at Layer 3 and offers 64 distinct priority levels compared to CoS which only provides 8 levels at Layer 2. For trusted endpoints that mark their own traffic, configure mls qos trust dscp on the access port to preserve these Layer 3 markings throughout the switching fabric.

Q5: How do I configure conditional trust for IP phones with attached PCs?

Configure conditional trust using the mls qos trust device cisco-phone command on ports connecting IP phones. This configuration ensures the port remains untrusted and marks all traffic to CoS/DSCP 0 until an IP phone is detected via CDP, at which point the port begins trusting the phone’s QoS markings. Any traffic from an attached PC passes through the phone’s internal switch and is marked by the phone according to its configured trust policy, typically with the PC data placed in a best-effort queue.

Q6: What commands verify the current trust state and mode on an interface?

Use the show mls qos interface [interface-id] command to display the trust state, trust mode, and trust device configuration for a specific port. The output shows whether the port is currently trusted or not trusted, the trust mode (DSCP or CoS), and whether a conditional trust device like Cisco-phone is configured. For Aruba AOS-CX switches, use show interface [interface-id] qos to verify trust settings and show qos trust for global trust configuration.

Q7: What happens to DSCP markings when I enable QoS globally on a switch?

When you enable QoS globally, the switch re-marks all incoming packets according to the CoS-to-DSCP or DSCP-to-CoS mapping tables by default. This means even trusted traffic may have its DSCP value rewritten unless you explicitly configure the switch to preserve markings. To prevent re-marking on trusted ports, configure mls qos trust dscp on the interface and optionally use pass-through to ensure the original DSCP value is preserved during CoS trust operations.

Q8: What are the recommended DSCP values for common campus applications at the edge?

Use the following IETF-standard DSCP values: EF (46) for VoIP bearer traffic, CS3 (24) for call signaling, AF41 (34) for video conferencing, AF31 (26) for streaming video, AF21 (18) for transactional data, and DF (0) for best-effort traffic. These values align with RFC 4594 recommendations and ensure consistent treatment across multi-vendor campus networks. Trusted endpoints like IP phones and video endpoints should be configured to mark their own traffic with these values, while untrusted PC traffic should be classified and marked by the switch using ingress policy maps.