Trust Boundaries (Classification, Marking, and NBAR)

End-system devices such as personal computers, IP phones, IP conference devices, and video conference gateways, plus switches and routers at different levels of the network hierarchy, can mark the IP packets or the encapsulating frames such as 802.1Q/P. One of the design and policy decisions you have to make is where to place your network trust boundary. The trust boundary forms a perimeter on your network; your network respects and trusts (does not override) the markings that the devices on or inside this perimeter (trust boundary) make. Markings that devices make outside the trust boundary are often reset, or at least checked and modified if necessary. The devices that check and reset the markings of the traffic received from the untrusted devices (devices outside the trust boundary), form the trust boundary of the network. The devices that form the trust boundary are the first set of devices that are trusted because they forward traffic toward the network core. It is considered good practice to place the trust boundary as close to the traffic source (and away from the network core) as possible.

You should certainly try to place the trust boundary as close to the network edge as possible. However, two other factors can affect your decision. First, the trusted device must be under your administration and control; at the very least, you should be confident that its marking is in-line with your QoS policies. Second, different devices have different capabilities and feature sets with respect to the ability to check and set/reset various QoS markings such as CoS and DSCP. With all facts considered, the trust boundary is implemented at one of the following network hierarchy layers:


■ End system

■ Access switch

■ Distribution switch

Figure 3-6 depicts three scenarios with the trust boundary placed on the IP phone, the access switch, and the distribution switch. The end systems, except for telephony and conference systems, are generally recommended not to be trusted. New microcomputer operating systems such as the Linux and Microsoft operating systems make it possible to set the DSCP or CoS field on the transmitted traffic. Access switches, if they have the capability, are generally configured to (or by default do) trust the markings set by the IP phone only. If the access switch does not have any or enough QoS capabilities, you might have to shift the trust boundary to the distribution layer switch.

Figure 3-6 Trust Boundary Placement Choices

Trust Boundary Placement Choices


In the first scenario displayed in Figure 3-6, the trust boundary is placed on the Cisco IP phone. The phone sets/resets the CoS field to 0 (000 binary) for the frames it receives from the PC as it forwards them to the switch. The CoS value on the IP phone-generated frames that are carrying voice signaling is set to 3 (011 binary), and it is set to 5 (101 binary) for those that are carrying voice. The access switch is configured to trust the markings of the traffic received on the port that the Cisco IP phone is connected to. But how does the switch know that a Cisco IP phone, and not another IP device such as a PC, is connected to that port? The switch discovers that a Cisco IP phone is connected to its port by means of the Cisco Discovery Protocol version 2 (CDP v2) that both the switch and the IP phone are supposed to have enabled. If the switch does not discover an IP phone, it does not extend the trust boundary to the end device and dynamically shifts the trust boundary to itself (the access switch).

In the second scenario, the PC is connected to the access switch, the trusted device. The access switch must be configured to check (and reset if necessary) the CoS field in case it receives 802.1Q/P frames from the PC (rare case). Some access switches are capable of checking (and setting) the IP header QoS fields (ToS field’s IP precedence or DSCP). When the traffic from the PC is forwarded toward the distribution switch, because the connection between the access switch and distribution switch is usually an 802.1Q/P trunk, the access switch can set the CoS field (and the DSCP field, if the switch has the capability) of the outgoing traffic to certain values based on QoS policies and the traffic type. For instance, the PC can run several different applications, including Cisco IP Communicator. In that case, if the marking of the traffic coming from the PC is not trusted, classification and marking of the traffic must happen on the trusted access switch. Network QoS treatments and PHBs are based on the markings that happen at the trusted boundary.

The third scenario in Figure 3-6 shows the trust boundary placed on the distribution switch. This usually happens when the access switch does not have enough or complete QoS classification, policing, or marking capabilities. It is also possible that the access switch is not under your administrative control; this is quite common in data center environments. For instance, the access switch might be able to set or reset the CoS field of the 802.1Q/P header but might not be able to set or reset the DSCP field on the IP packet header. The distribution switch has QoS capabilities and features so that it can do classification, policing, and marking based on CoS or DSCP (or IP precedence).

Next post:

Previous post: