QoS in Switches: CoS Trust Boundaries

Cisco switches perform most Quality of Service (QoS) operations in hardware, while routers perform QoS functions in software. It is best practice to use the switch to perform deep packet classification and marking functionality on the switches. The router will need to re-classify the packet, but the classification can be on the DSCP marking rather than a transport layer port number. Most Cisco switches do not support the NBAR classification mechanism which can look into the layer 7 header of a packet (up to 400 bytes). NBAR is supported in the 6500 switch, but can cause a very, very large performance impact. The SUP32-PISA module can do NBAR in hardware at up to 1Gbps (very limited). This will be the first blog in a series of blogs covering switch based QoS. If you wish to learn the CoS and DSCP markings in detail, please read my first QoS blog series. This blog series will assume that you are familiar with the layer 2 (CoS) and layer 3 (DSCP) marking components. The first thing I’d like to talk about is trust boundaries. Every switch interface is untrusted by default. Untrusted indicates that the switch should not trust any of the QoS markings sent by the connected device and the switch will re-mark all inbound Ethernet frames to a layer 2 class of service (CoS or IEEE 802.1p) of 0. The CoS-DSCP mapping table is used for inbound traffic to the switch because the switch must derive an internal DSCP. The default CoS to DSCP mapping table is as follows: CoS DSCP PHB 0 0 default 1 8 cs1 2 16 cs2 3 24 cs3 4 32 cs4 5 40 cs5 6 48 cs6 7 56 cs7 Notice that each CoS is mapped to the equivalent DSCP PHB class selector (cs) which indicates that the last 3 bits of the DSCP end in 000 and the marking is backward compatible to IP Precedence values. The incoming port on a switch will assume a CoS of 0 even if the Ethernet frame is coming in on an access layer port without an 802.1Q trunk. Recall that an 802.1Q trunk is normally required to carry a layer 2 CoS value. There are two exceptions to this rule. A Cisco switch configured as an access layer port with a voice vlan is actually an 802.1Q trunk that will only allow traffic tagged on the voice vlan. The last exception is very seldom used, but does exist. Cisco supports a single VLAN access port in which Cisco IP phone traffic is not VLAN tagged, but contains an IEEE 802.1p value. Cisco IP phones mark their packets by default to following markings: signaling (SCCP or SIP) - CoS 3 / cs3 media (RTP) - CoS 5 / DSCP 46 (EF) When AutoQoS is used on the Cisco switch interface, the interface will include a trust statement similar to the following: Mls qos trust cos The first command changes the untrusted port to a trusted port based on the incoming CoS value. The CoS to DSCP mapping table will now be in charge of deriving the internal switch DSCP which will overwrite the packets current DSCP value. The incoming CoS of 5 for voice media is mapped to a DSCP of 40 (cs5) by default. The next switch or router to receive the packet will probably be expecting a DSCP value of 46 (EF) since that is the marking used for voice over IP. This challenge can be overcome by re-configuring the CoS to DSCP mapping table entry for CoS 5 to DSCP 46. The CoS to DSCP mapping table configuration change would be as follows: Mls qos map cos-dscp 0 8 16 24 32 46 48 56 This command can be confusing at first glance. There are eight decimal values in this command which represent the 8 possible CoS values. The switch map all CoS values in the same way as shown before, but the inbound CoS value of 5 is now mapped to a value of 46 (EF). AutoQoS also includes the “Mls qos trust device cisco-phone” statement which creates a conditional trust boundary. The switchport will trust CoS values, but only if they’re sent by a Cisco phone. The port obtains the Cisco phone information from the Cisco Discovery Protocol (CDP) announcement made from the phone. The next blog will cover some other trust state options that are not a part of AutoQoS.


Copyright © 2009 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022