Enterprise QoS Part 05 – A consistent QoS strategy: L2 & L3 traffic marking.

872 Words. Plan about 3 minute(s) to read this.

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.

  1. 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.
  2. 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.

Search for all parts in the Enterprise QoS series.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks


  1. Manfred Arndt

    Good info and this one offers the best practical advice. This is because I’ve learned a simple “consitent” QoS policy will outperform a complex one implemented poorly…much like “a chain is only as strong as it’s weakest link”.

    One comment though. Since most modern Ethernet switches now support L3/DSCP based QoS, I’ve been encouraging all our customers to use DSCP based QOS where possible. Not only will this help ensure a more consistent end-to-end policy, but also will be easier to diagnose using SW tools like Wireshark (e.g. most Ethernet NICs will strip VLAN headers containing the 802.1p COS value).

    1. Post
      Ethan Banks

      I agree with your point on DSCP, and actually made a big deal of this point in my Interop presentation, although my point was more that in the average LAN/WAN, you won’t actually have Ethernet end-to-end. And even if you did, you possibly don’t have 802.1q end to end. There’s no guarantee that the CoS value will be preserved, but you can count on DSCP.

      Can you offer a more detailed comment on what exactly is stripped by a NIC in the presence of the CoS bits being populated with a value? I rarely look at L2 headers in Wireshark (usually I’m dealing with a higher level protocol analysis), and L2 header stripping is not something I’ve noticed before.

  2. Manfred Arndt

    Depending on what vendor NIC card and Ethernet driver you are using on a Windows laptop, it’s fairly common for the entire VLAN header to be stripped. Most captures I get from our customers and field don’t include any VLAN headers.

    In addition, since many folks seem to use the monitor/mirror port on a switch for taking packet captures (rather than say inserting a hub to tap into a wire — and even if you wanted to, good luck finding a hub these days), I’ve seen cases where the VLAN priority was not properly preserved by the switch ASIC when mirroring traffic. As such, I’m always a bit learly looking at the L2 802.1q priority, unless I’ve taken the capture myself.

Comments are closed.