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.
Dennis Hartmann, CCIE No. 15651, is a consultant with www.highpoint.com and author of Implementing Cisco Unified Communications Manager, Part 1. Dennis is also a lead instructor at Global Knowledge. Dennis has various certifications, including the Cisco CCVP, CCSI, CCNP, CCIP, and the Microsoft MCSE. Dennis has various specializations including unified communications, data center, routing & switching, service provider (MPLS and optical). Dennis has worked for various Fortune 500 companies, including AT&T, Sprint, Merrill Lynch, KPMG, and Cabletron Systems. He lives with his wife and children in Hopewell Junction, New York.
The Leader in Network Knowledge
Trusted CoS vs policy
Switches should not be getting into the business of deep packet inspection to determine CoS. This is how carriers get into trouble with the FCC, by examining what their customers are doing and placing value judgments. Instead, switches should be applying policy and taking measurements. High priority/low latency CoS needs to be limited if a network will be capable of handling the corresponding QoS from end-to-end. The network operator should instead limit the amount of high priority CoS packets accepted by the switch, or mark the packets eligible for discard. It should also count the number of packets and bytes at each priority and discard eligibility. Charging can be applied at different rates for different CoS if desired. Other policy might allow more high priority traffic if the destination is within a local region, such as on-campus traffic might allow more low-latency traffic than traffic leaving the area.
A corporate network may limit the amount of high priority traffic to the amount of a voice call. If the user decides to mark their video Skype call with high priority/low latency, the network could drop the excess bandwidth. A carrier may allow different quantities of different priorities based on the price of the service. Low priority/high latency traffic might be allowed on a capacity available basis, but free. This would move the peer-to-peer traffic out of the way of web surfing. The hardest nut to crack is how to handle traffic which moves between administrative boundaries (such as AT&T to Verizon), as different CoS mapping and policies are likely to apply.
The key here is that the network should not be in the business of making value judgments from deep packet inspection, unless the endpoint has delegated the marking to the network. This is true network neutrality.
Good Discussion
Very good discussion. I believe you're speaking primarily from a service provider/carrier perspective. Throughout this blog series you will see that I'm a fan of performing classification and marking at the access layer ingress port and trusting throughout the network from that point. Please keep reading. Thanks.
Ah the memory
Wasn't there a standard some time back wherein end-to-end QoS was considered right from its inception. As I recall, it was much much too complicated for the average person -- much much moreso than the layer2-layer3 mapping retrofit kludge we now call QoS, or is it CoS ?? Does anyone recall?? For some reason the 3 letter acronym reminded me of cash machines...
Intserv vs. Diffserv?
Intserv was the original end-to-end QoS solution. In intserv, each session is negotiated, monitored and given specific QoS performance. On core routers though, the session count could go in to the m(b)illions and be nearly impossible to track. Diffserv is the solution which breaks up traffic in to classes and assigns QoS to the various classes.
Intserv is an end-to-end QoS, which was never scalable.
Diffserv is the layer 2/3 mapping kludge, which works pretty nice.
-Mike
Post new comment