The Great vSwitch Debate – Part 2

Table of Contents

• The Great vSwitch Debate – Part 1
  In this post, I discuss vSwitch functions, Port Groups, VLAN tagging/trunking, valid communications paths, and some other basic vSwitch information.
• The Great vSwitch Debate – Part 2
  In Part 2, I cover the vSwitch security features (Promiscuous Mode, MAC Address Change, and Forged Transmits) as well as network traffic shaping options.
• The Great vSwitch Debate – Part 3
  Here I discuss the various load balancing options that are available in a VMware vSwitch.
• The Great vSwitch Debate – Part 4
  In Part 4, I cover fault detection and the Cisco Discovery Protocol.
• The Great vSwitch Debate – Part 5
  In Part 5, I talk about the various networks that you have to contend with in an ESX environment as well as an approach to help in deciding which networks to combine, if you have to.
• The Great vSwitch Debate – Part 6
  I introduce the first host configuration. In this part, I talk about my recommendations for when you have eight pNICs and offer up a couple alternatives, including one for using an iSCSI initiator from within a VM.
• The Great vSwitch Debate – Part 7
  I discuss configurations for systems with two, four, and six pNICS.
• The Great vSwitch Debate – Part 8
  In this, the final article in the series, I discuss the importance of naming standards.

Part 2

This article is a continuation of the first in a series. See The Great vSwitch Debate – Part 1 for the beginning of the series.

In this Part Two of the series on vSwitch configurations, I want to address some of the advanced configuration options, but first – I need to go back and revisit the end of Part 1. There, I was discussing the routing of traffic between VMs on the same and different port groups on a single vSwitch. I presented the figure below (Figure 1) to describe what I was talking about.

Figure 1. Port Group Communications Paths

I need to add a scenario that I feel is quite important and I’m somewhat embarrassed that I left it out the first time. Consider the case where you have a single vSwitch with two port groups defines, VLAN_200_Dev and VLAN_200_Test – two port groups with (obviously) different labels, yet they use the same VLAN number. This is the ONLY case where traffic from a VM on two separate port groups with defined VLAN numbers (other than 0 & 4095) will communicate directly within the vSwitch without requiring an intervening Layer 3 device. This is shown as Scenario 4 in Figure 2 below.

Figure 2. Inter-Port Group Routing

OK, now that I’ve gotten that off my chest, let’s move on to cover some new information. As you’ll recall, I introduced the concept of vSwitch security features back in Part 1. The vSwitch offers three security features as follow:

• Security

• • Promiscuous mode enable/disable
  • MAC Address Change enable/disable
  • Forged Transmit enable/disable

Promiscuous Mode

Let’s look at each individually. First, there’s Promiscuous mode, which Wikipedia defines as “a configuration of a network card that makes the card pass all traffic it receives to the central processing unit rather than just packets addressed to it – a feature normally used for packet sniffing“. Well, that’s fine and dandy except we’re talking about a vSwitch rather than a network card. In actuality, the vSwitch promiscuous mode is much closer to Port Mirroring, which is defined as “used on a network switch to send a copy of all network packets seen on one switch port (or an entire VLAN) to a network monitoring connection on another switch port”. That’s pretty much what vSwitch promiscuous mode does – it enables a vNIC that has been placed into promiscuous mode to receive a copy of all network packets on the same vSwitch (or Port Group). If you configure a vNIC for promiscuous mode and the vSwitch/Port Group to which it is connected does not have Promiscuous mode enabled, then the vNIC will receive only traffic destined directly for it. To illustrate this concept, let’s start with Figure 3 as an example vSwitch configuration.

Figure 3. Promiscuous Mode vSwitch Talking Slide

In Figure 3, “VLAN A” can be any VLAN number from 1 to 4094 and “VLAN B” can be any other VLAN number from 1 to 4094 – for discussion purposes, it doesn’t really matter what the numbers are, only that they are valid and different from one another. To demonstrate who can talk to whom, let’s look at Table 1:

Table 1. Promiscuous Mode Port Group Connectivity

Basically, what Table 1 is saying is that, for a vSwitch configured in promiscuous mode, a promiscuous mode vNIC connected to PG_VGT can see all traffic on the vSwitch; however, if that same promiscuous mode vNIC connected were to be connect to PG_EST it would be able to see traffic only for other vNICs connected to PG_EST (or any other port group using EST Mode tagging); however, it cannot see traffic destined for any other VLAN.

The rest of the table is pretty simple, except for the PG_VGT column. The PG_VLA, PG_VLB, and PG_VLB1 rows show both a Yes and a No for PG_VGT which means, for example, a promiscuous mode vNIC connected to PG_VLA could see only traffic destined for VLAN A, which could include traffic destined for PG_VGT.

I hope that all made sense – it all seems overly convoluted on a cursory re-read. I’ll have to revisit before I publish to see if I can figure out a better way to describe it.

MAC Address Change

A MAC Address (http://en.wikipedia.org/wiki/MAC_address) is a pseudo-unique number assigned to most networking components. It is how a particular device is identified on the network. The MAC address functions at Layer Two in the network stack, whereas IP addresses function at Layer Three. In a VMware ESX environment, each vNIC is assigned a MAC address when the VM is initially powered on (unless you have manually configured a static MAC address in the .vmx file). This is the rough equivalent of the MAC address that comes burned in on pNICs. The description of the process ESX uses to generate MAC addresses is documented at http://kb.vmware.com/kb/219. (NOTE: The MAC-generation algorithm changed somewhere along the way. The new algorithm is documented here: https://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_3_server_config.pdf Page 67 [thanks Tyler!]) One thing that’s important is that there is a limit of unique MAC addresses per ESX host. This could be an issue in a couple of situations:

• In a VDI environment where a large number of VMs are created, powered on, and powered off
• In an environment where VMs are started on a “launch pad” system and DRS is used to distribute workload throughout the cluster

In any case, what this security feature deals with is allowing the guest OS within the virtual machine to change its MAC address. For information on how to change your MAC address in a variety of operating systems, see http://en.wikibooks.org/wiki/Changing_Your_MAC_Address. So, why do you care if a guest OS changes its MAC address? One reason is that MAC spoofing is a key element of ARP Poisoning (http://en.wikipedia.org/wiki/ARP_poisoning), so having the ability to lock a VM’s MAC address to the value configured in the .vmx file provides a level of enhanced security that’s not available in a physical environment.

The MAC Address Changes setting affects traffic that is received by a VM. If this configuration item is set to Accept, the vSwitch will honor requests to change the MAC address to a value other than the one stored in the .vmx file. If it is set to Reject, then any request to change the MAC address will cause the vSwitch to disable the port to which the vNIC is connected and the vNIC will not receive any traffic until its MAC address is reset back to its original value. The guest OS is not notified that the attempt to change the MAC address was not honored.

One thing of note – if you plan to configure your VMs in a unicast Network Load Balancing (NLB) cluster, you must enable the MAC Address Changes feature or your NLB cluster won’t work. A multicast NLB cluster doesn’t need this feature enabled.

Forged Transmit

Forged transmits are similar to MAC address changes – except this setting deals with traffic that is originated from rather than received by the vNIC. Basically, if this setting is set to Accept, the vSwitch will allow the guest OS to modify its MAC address and successfully transmit frames with the “forged” address. If this configuration item is set to Reject, then the vSwitch will compare the source MAC address in all outgoing frames with the MAC address stored in the .vmx file. If they do not match, the frame is dropped with no notification to the guest OS.

As with MAC Address Changes, Forged Transmit is required to be set to Accept to support unicast NLB configurations.

Traffic Shaping Configuration

A feature that I have only ever used in a lab setting is Traffic Shaping. Traffic shaping allows you to control the amount of bandwidth that a vSwitch will transmit. There are three configuration parameters that control traffic shaping, and they are:

• Average Bandwidth. This is the “guaranteed” data rate that you want to set for data transmission. You can view this as being similar to a committed information rate (CIR – http://www.2000trainers.com/cisco-ccna-11/ccna-frame-relay-cir/), if you’re familiar with frame relay networks.
• Peak Bandwidth. This is the absolute ceiling data rate that the vSwitch will transmit data at. Once again referring to the frame relay model, this is analogous to the Committed Burst Information Rate (CBIR).
• Burst Size. The final configuration parameter for Traffic Shaping is Burst Size. The burst size is specified as the number of bytes that can be sent each time the vSwitch “bursts” above the Average Bandwidth.

For a detailed description of when and how you might want to use Traffic Shaping, take a look at this article (http://www.petri.co.il/traffic_shaping_with_vmware_esx_server.htm) by Jason Boche – a great example use for this feature.

Miscellaneous Security Features

In addition to the configurable security features we’ve discussed above, there are a couple things that are unique to a vSwitch that directly impact its security. These benefits are:

• A vSwitch knows the MAC address of each vNIC that is connected to it. It relies on a notification mechanism for MAC updates and doesn’t have to rely on learning the MAC address from traffic that traverses the vSwitch.
• Traffic received on one vmnic is never forwarded to another vmnic. This means that a vSwitch will never create a network loop and thus the vSwitch does not need to (and, indeed, does not) participate in the Spanning Tree Protocol (STP).
• A vSwitch does not do IGMP snooping (http://en.wikipedia.org/wiki/IGMP_snooping) which is a Layer Three function; however, since the vSwitch knows which vNICs want to receive multicast traffic, multicast traffic is not flooded to all connected vNICs.
• The vSwitch does not trust user data within the network frame as it passes through the vSwitch:

• • The vSwitch makes a private copy of any network frame data used in forwarding and filtering.
  • The vSwitch carries VLAN data outside the frame as it passes through the virtual switch. Filtering is a simple integer comparison.

• vSwitches have no support for dynamic trunking (802.3ad)
• vSwitches do not implement support for the “native VLAN” [1]

Summary

OK, we’ve talked about some of the security features that are implemented in the vSwitch. that’s going to wrap it up for Part 2 of my series on vSwitches within ESX. Next time, we’ll talk about NIC Teaming policies, Load Balancing policies, and Network Path Failure Detection methods. Until then, enjoy – and keep it virtual!

Back to The Great vSwitch Debate – Part 1 — Forward to The Great vSwitch Debate – Part 3

References

The Great vSwitch Debate – Part 1

MAC Address (http://en.wikipedia.org/wiki/MAC_address)

Setting a static MAC address for a virtual NIC (VMware KB Article 219) (http://kb.vmware.com/kb/219)

 (https://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_3_server_config.pdf Page 67)

Changing your MAC address (http://en.wikibooks.org/wiki/Changing_Your_MAC_Address)

ARP Poisoning (http://en.wikipedia.org/wiki/ARP_poisoning)

Committed Information Rate (CIR – http://www.2000trainers.com/cisco-ccna-11/ccna-frame-relay-cir/)

Traffic Shaping article by Jason Boche (http://www.petri.co.il/traffic_shaping_with_vmware_esx_server.htm)

IGMP snooping (http://en.wikipedia.org/wiki/IGMP_snooping)

[1] Virtual LAN Security Best Practices: (http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/vlnwp_wp.pdf)