A significant part of the challenge of delivering a QoS strategy to a network is in the execution. How, exactly, does one write a QoS policy that will accomplish business goals consistently across a diverse network infrastructure? There is no obvious answer to this question (and large books have been written on the topic), as the types of QoS tools to apply differ by network location and by the types of problems that can be experienced at each of those locations. Even so, there’s a number of general recommendations that can be followed.
The first recommendation is to mark your traffic as close to the traffic source as possible. By “mark,” I’m referring to marking one of two possible things in the context of this series: Ethernet frames (L2) or IPv4 packets (L3). Marking an Ethernet frame at L2 is accomplished with an 802.1p Class of Service (CoS) mark, populating the first 3 bits of the 802.1Q header – what we normally think of as holding the VLAN tag, which of course it also does. Marking an IPv4 packet at L3 is accomplished by populating the first 6 bits of the IP header ToS byte with a DSCP value.
Understand that Ethernet frames contain IP packets. A frame is the wrapper placed around a packet so that the IP data can be transported between Ethernet devices. When an Ethernet switch is transporting a frame at L2, the marks of interest are usually the CoS values. When a network device is routing a packet, for instance from the LAN to a WAN, the marks of interest are usually the ToS byte. Note that these are not hard and fast rules, but typically the way QoS policies are deployed.
Marking traffic near the source means that the QoS policy assigned to your access ports (the ports that connect end hosts such as user desktops, IP phones, servers, etc.) will either mark the traffic coming into port, or will trust the marks already assigned to that traffic by the hosts themselves. In QoS lingo, “trust” is an important word. Should your switch trust incoming traffic marks? Or should your switch strip the marks off of all incoming traffic, and re-mark it according to your own policy? There is no one right answer to this question, but there are a couple of useful considerations.
- Conditional trusting is possible, based on the identity of the host. For example, a Cisco switch can be configured to trust the marks of any device that identifies itself using Cisco Discovery Protocol (CDP) as a Cisco IP phone. This makes sense, as the normal deployment for a Cisco phone is to have the user workstation plug into the phone, and the phone plug into the switch. The phone is a known entity that can be trusted to mark application traffic from the workstation as well as voice & call-signaling traffic from the phone correctly.
- There’s nothing stopping a savvy user from marking traffic to their advantage, although considering the expertise of most users, this is unlikely to happen very often. Still, it’s worth pondering what effect incorrectly marked traffic might have on your network. What would happen if large quantities of bulk traffic was marked with the same value as real-time voice traffic?
Once your marking policy is established, the next consideration is to preserve those marks across your network infrastructure. Note that the default behavior of many (but not all) Cisco switches is to strip off incoming marks, i.e. to not trust them. Therefore, if you’ve configured your access layer switches to mark traffic, you’ll also need to configure distribution and core layer switches to trust the incoming marks.
Assuming an Ethernet access layer, your initial marks will be CoS values, i.e. setting the first 3 bits of the 802.1Q tag to a value of 0-7. However, you’ll also want to map that CoS value to a DSCP value, as not all network devices in the path will necessarily make queueing decisions based on CoS. Why? Not all transport links in the path the IP packet will follow will necessarily be Ethernet. Different wrappers (frames) will go around the IP packet depending on what medium the packet needs to go across. Therefore, it’s not enough to mark the Ethernet frame with a CoS value; that CoS value should also be mapped to a DSCP value in the IP header.
Why all this talk about marking? Marking your traffic is the only consistent way to identify a traffic class across a network infrastructure. In addition, marks are the only attribute of your traffic that your WAN provider is going to pay attention to. While it is possible to create traffic classes based on IP addresses or ports, policies structured this way should be considered as only locally significant. In other words, if you base traffic classification on transient traffic attributes, then you run the risk of that traffic not being treated the same way all the way through your network infrastructure. Marking traffic gives it the best chance consistent QoS policy application at every junction point, no matter if the traffic has been NAT, tunneled, or carried across a variety of different media.