Welcome back to our study of Quality of Service. In our previous lesson, we dove into the specifics of traffic marking, distinguishing between Layer 2 Class of Service (CoS) and the more versatile Layer 3 Differentiated Services Code Point (DSCP). We established that these markings are the "priority tags" that allow network devices to treat different types of traffic appropriately.
Now that we know how to mark traffic, we must address the equally important question of where we should trust those markings. This lesson introduces the critical concept of the QoS trust boundary. We will define what a trust boundary is and explore the strategic decisions involved in placing it correctly within an enterprise network. By the end of our session, you'll be able to analyze a network design and determine the most appropriate location for the trust boundary to ensure a secure and effective QoS policy.
Defining the Trust Boundary
A trust boundary is a logical line in your network that separates the "trusted" zone from the "untrusted" zone.
- Inside the trusted zone: Network devices (switches, routers) will accept and honor the QoS markings (CoS or DSCP) on incoming packets.
- Outside the trusted zone: Devices are considered untrustworthy. When traffic from an untrusted device enters the trusted zone, its existing QoS markings are typically ignored and either reset to a default value (like DSCP 0 for best-effort) or re-marked according to a centrally defined policy.
Establishing this boundary is crucial for two main reasons:
- Security: It prevents users or compromised devices from unfairly prioritizing their own traffic by applying high-priority markings.
- Consistency: It ensures that your QoS policy is applied uniformly, starting from a known, controlled point in the network.
To begin, let's watch a concise explanation that defines the trust boundary and illustrates its basic function.
Free CCNA | QoS (Part 2) | Day 47 | CCNA 200-301 Complete Course
This segment from Jeremy's IT Lab provides a clear, animated introduction to the concept of the trust boundary.
Please watch the section that defines the trust boundary, from the introduction. Pay close attention to the example of what happens when a marking is trusted versus when it is not.
Strategic Placement of the Trust Boundary
The core challenge is deciding where this logical line should be drawn. The optimal location depends on the types of devices connected to your network and the level of control you want to maintain. Let's examine the most common scenarios.
The article "QoS trust boundary on Cisco Switches" from NetworkLessons.com illustrates the main options.
QoS trust boundary on Cisco Switches - NetworkLessons.com
This reading uses simple diagrams to show the three primary locations for a trust boundary in a typical hierarchical network.
Please read the introduction and review the three diagrams under the headings the introduction and the three examples. As you read, consider the security and management implications of each placement option.
As the article explained, you can place the boundary at the IP phone, the access layer switch, or even the distribution layer. Let's analyze these choices.
Scenario 1: The Boundary at the End Device (e.g., IP Phone)
In this design, you extend trust to certain intelligent endpoints. IP phones are the classic example because they are purpose-built devices that correctly mark their own voice traffic (typically with DSCP EF) and can pass through traffic from a connected PC.
The switch port connected to the phone is configured to trust the markings it receives. This is efficient because the device generating the critical traffic is also the one marking it. However, the switch must be configured not to trust traffic coming from the PC daisy-chained to the phone.
Scenario 2: The Boundary at the Access Layer Switch
This is the most common and secure approach for general user access. Here, the access switch is the first point of trust. It does not trust markings from any connected endpoint (PCs, servers, unknown devices).
In this model, the switch is responsible for inspecting the traffic, classifying it (e.g., identifying voice vs. web traffic based on port numbers), and applying the correct DSCP/CoS markings itself. This gives you complete control but requires more configuration on the switch.
Scenario 3: The Boundary at the Distribution/Core Layer
Placing the boundary further into the network (at the distribution or core layer) is rare and generally not recommended for enterprise designs. This would imply that you do not trust your own access layer switches. While technically possible, it is inefficient as it forces unprioritized traffic to travel farther into the network before being managed. This model might be seen in environments where different administrative teams manage different layers of the network.
Best Practices for Trust Boundary Placement
Now that we've seen the options, let's solidify the decision-making process. The goal is to apply a simple rule: Trust what you control and what is known to behave correctly; be skeptical of everything else.
The following video and reading provide excellent summaries of these best practices.
Free CCNA | QoS (Part 2) | Day 47 | CCNA 200-301 Complete Course
Let's return to the Jeremy's IT Lab video to hear the recommended best practice and test your understanding.
First, watch the segment explaining the recommended approach for IP phones versus PCs: Recommended boundary. Then, answer the quiz question that follows to confirm your understanding: Quiz question.
To reinforce these concepts, let's read a clear FAQ that directly addresses best practices for placing the trust boundary.
DSCP vs CoS & Trust Boundary - CCNP Enterprise
The FAQ section of this NetworkJourney article provides concise, actionable answers to the most important questions about trust boundaries.
Please read the answers to the following three questions: Where should it be placed? What happens if configured improperly? What's the best practice?
How Switches Implement Trust: A Practical Preview
You might be wondering how a switch can trust an IP phone but not the PC connected to it. Cisco switches typically use the Cisco Discovery Protocol (CDP) to identify the type of device connected to a port. When a switch sees a Cisco IP phone via CDP, it can apply a special trust policy to that device.
Configuring this involves a two-step logic on the switch interface:
- Tell the switch what to trust (e.g.,
mls qos trust cos). - Qualify that trust by telling it who to trust (e.g.,
mls qos trust device cisco-phone).
The following video demonstrates this concept and the associated commands. While the next module will cover implementation in detail, seeing it now helps connect the theory to practice.
CCNA R&S version 3 Topic: Quality of Service (QoS) - Trusting Devices
Kevin Wallace provides a practical look at how a Cisco switch can be configured to selectively trust devices.
First, watch the explanation of how CDP enables a switch to identify and trust specific devices like IP phones: Selective trust. Next, watch the demonstration of the two-step configuration logic for trusting a specific device: Configuration logic. This shows how you first define the marking to trust (CoS) and then apply it only to a specific device type (cisco-phone).
Conclusion
In this lesson, we have defined the QoS trust boundary and established its critical role in maintaining a secure and consistent quality of service policy. You are now equipped to analyze a network and make informed decisions about where to place this boundary.
Key Takeaways:
- A QoS trust boundary is the network perimeter where devices begin to honor the priority markings on traffic.
- Traffic from outside the boundary is considered untrusted and should be re-marked by a trusted device.
- The placement of the boundary is a strategic choice based on security and network device capabilities.
- Best Practice: Trust specialized devices like IP phones but do not trust general-purpose endpoints like user PCs. For most user ports, the trust boundary should be the access layer switch.
- Switches can use protocols like CDP to identify device types and apply selective trust policies.
This lesson concludes our module on QoS concepts. You now understand the mechanisms of QoS, the details of marking, and the strategic importance of the trust boundary. In the next module, "Implementing QoS Policies," we will move from theory to practice, using the command line to configure traffic classification, marking, and queuing on a Cisco router.