VMware vSwitch and 802.1p CoS Value

One of my readers opened another can of VMware vSwitch worms. He sent me this question:

If a VM were to set a COS value, would the vSwitch reset it to 0 as part of its process of building the dot1q header?

The nasty detail (as you probably know) is that 802.1p CoS value resides in the 802.1q (VLAN) tag.

I wasn't able to find anything within the vSphere documentation or VMware knowledge base that would help me answer this question, so I'm guessing the answer is "it doesn't work." vSwitch seems to expects either untagged VM-to-vSwitch link, in which case the 802.1q tag with VLAN set to zero would throw it off, or a tagged link, in which case the VM has to set the VLAN ID as well. If you have a better answer, please share it in the comments.

On the other hand, vSphere 5.5 can set CoS value based on DSCP field – on the distributed vSwitch. Yet again, we have to pay a hefty tax (Enterprise vSphere license) to get the functionality that has been available in low-end physical switches and Linux-based virtualization solutions for years. No wonder the application developers stopped trying to influence the network behavior.

You can probably guess how much it irritates me when VMware marketing tries to tell us that the network stands in everyone's way instead of giving people the tools they need to get their job done correctly.

Recent posts in the same categories

6 comments:

  1. Anonymous 31 July 2014 00:41
    Both vSS and vDS support virtual guest tagging. In vSS you use VLAN 4095 in vDS you specify VLAN ranges. On top of that with vDS and NetIOC you can create custom network resource pools, define their CoS and assign them to port groups.
    Replies
    1. Ivan Pepelnjak 31 July 2014 14:25
      That's exactly what I wrote - and if you use VLAN 4095, the VM has to know the proper VLAN ID to use. Why would you want to set that up if all you need is CoS tagging?
    2. Anonymous 31 July 2014 15:27
      Another way to look at it is should the VM owner be able to prioritize his own traffic? Should not that be done by Network admin at the infrastructure level via Resource Pool tagging?

      No comment on the licensing. This is business decision - you also make your webinars payware.
  2. James Hess 02 August 2014 01:10
    The VM owner should be able to supply the CoS values he could supply if he had a physical server, yes; the network admin might (or might) not reason to decide what to do or not to do with those declarations the VM owner has put in the packets' priority fields.

    Ivan didn't sell webinars with some of the important parts bleeped out and "come pay us $4000 extra per server in your datacenter, if you want to come find out what you missed".
  3. Anonymous 04 August 2014 17:40
    First, you engineer a full networking stack and try not to pull some benefit out of it. This is directly running against legacy vendors. You want the goodies, pay up.

    Conversely, a lot of virtualization farms treat the last mile (vswitch) as a dumb pathway. Everything should be line rate at that point with any-to-any availability. COS and QOS in general should not apply as there is no contention.

    I agree above, that applications should rarely declare their own values. We all know that they will select the priority queues as theirs is the most important. We end up back at zero.

    What use case does this really solve?

    COS/QOS make sense at the border or across the WAN. Inside the DC, where VMware resides, it makes far less sense.
  4. Anonymous 10 August 2014 04:49
    "You can probably guess how much it irritates me when VMware marketing tries to tell us that the network stands in everyone's way instead of giving people the tools they need to get their job done correctly."

    It's a shame that VMWare has done this has gotten away with it. Sad truth is most of IT is run by folks that really don't care about the details.
Add comment
Home
Sidebar