Virtual switches in the VMkernel do not need vLANs if an ESX Server host has enough physical network adapters to connect to each of the vLAN subnets.
Blade servers provide an excellent example of when vLANs offer tremendous benefit, because the blade servers offer limited expansion slots for physical network adapters due to the small form factor of the blade casing. Figure 3.33 shows a vSwitch architecture with vLANs as it integrates with a physical architecture also using vLANs. For a vSwitch to successfully send and receive packets tagged as one vLAN or another, a trunk port must be configured on the physical switch port to which the physical network adapter assigned to the vSwitch is connected.
Figure 3.33 The physical switch port to which a vSwitch's assigned physical network adapter is connected must be configured as a trunk port for vLAN tagging to work between virtual and physical switches.
Follow these steps to configure a vSwitch with a virtual machine port group with a vLAN using an ID of VLAN 117:
1. Use the VI Client to establish a connection to a VirtualCenter server or an ESX Server host.
2. Click the hostname in the inventory panel on the left, select the Configuration tab from the details pane on the right, and then select Networking from the Hardware menu list.
3. Click the Properties link for the vSwitch where the new vLAN should be created.
4. Click the Add button, select the Virtual Machine radio button option, and then click Next.
5. Type the name of the virtual machine port group in the Network Label text box. In this case, vLAN117 would be appropriate.
6. Type 117 in the VLAN ID (Optional) text box, as shown in Figure 3.34.
Figure 3.34 The vLAN tagging support of vSwitches simplifies integration with existing physical hardware configured with vLANs.
7. Click Next to review the vSwitch configuration and then click Finish.
Although vLANs reduce the costs of constructing multiple logical subnets, keep in mind that the contention through physical switches and network adapters is still present. For bandwidth-intensive network operations, the disadvantage of the shared physical network might outweigh the scalability and cost savings of the vLAN.
Configuring Virtual Switch Security
Even though the vSwitches created in the VMkernel are considered to be “dumb switches”, they can be configured with vSwitch security policies to enhance or ensure Layer 2 security. Security policies can be applied at the vSwitch or at the lower-level connection types configured on a vSwitch and include the following three security options:
♦ Promiscuous Mode
♦ MAC Address Changes
♦ Forged Transmits
Applying a security policy to the vSwitch is effective, by default, for all connection types within the switch. However, if a connection type, or port group, is configured with a competing security policy, it will override the policy set at the vSwitch. As in the example in Figure 3.35, if a vSwitch is configured with a security policy that rejects the use of MAC address changes but a virtual machine port group on the switch is configured to accept MAC address changes, then any virtual machines connected to that port group will be allowed to communicate even though it is using a MAC address that differs from what is configured in its VMX file.
Figure 3.35 Security policies at the switch level are effective by default for all connection types on the switch. Security policies at the connection type (port group) level override the policy set at the virtual switch.
The default security profile for a vSwitch, shown in Figure 3.36, is set to reject Promiscuous mode and to accept MAC address changes and Forged transmits.
Promiscuous Mode
The Promiscuous Mode option is set to Reject by default to prevent virtual network adapters from observing any of the traffic submitted through the vSwitch. For enhanced security, allowing Promiscuous mode is not recommended because it is an insecure mode of operation that allows virtual adapters to access traffic other than its own. Despite the security concerns, there are valid reasons for permitting a switch to operate in Promiscuous mode. An intrusion detection system (IDS) requires the ability to identify all traffic to scan for anomalies and malicious patterns of traffic. To support the use of the IDS without overextending the reduced security of Promiscuous mode, you can create a dedicated virtual machine port group for use with the IDS. As shown in Figure 3.37, the virtual switch security policy will remain at the default setting of Reject for the Promiscuous Mode option, while the virtual machine port group for the IDS will be set to Accept. This setting will override the virtual switch, allowing the IDS to monitor all switch traffic.
Figure 3.36 The default security profile for a virtual switch prevents Promiscuous Mode but allows MAC Address Changes and Forged transmits.
MAC Address Changes and Forged Transmits
When a virtual machine is created with one or more virtual network adapters, a MAC address is generated for each virtual adapter. Just as Intel, Broadcom, and others manufacture network adapters and include unique MAC address strings, VMware is also a network adapter manufacturer that has its own MAC prefix to ensure uniqueness. Of course, VMware doesn't actually manufacture anything, since the product exists as a virtual NIC in a virtual machine. The six-byte, randomly generated MAC addresses for a virtual machine can be seen in the configuration file (.vmx) of the virtual machine, as shown in Figure 3.38. A VMware-assigned MAC address begins with the prefix 00:50:56 or 00:0C:29. The value of the fourth set (XX) cannot exceed 3F to prevent conflicts with other VMware products, while the fifth and sixth sets (YY:ZZ) are generated randomly based on the Universally Unique Identifier (UUID) of the virtual machine that is tied to the location of the virtual machine. For this reason, when a virtual machine location is changed a prompt will appear prior to successful boot. The prompt will inquire about keeping the UUID or generating a new UUID, which helps prevent MAC address conflicts.
Figure 3.37 Promiscuous mode, though a reduction in security, is required when using an intrusion detection system.
Figure 3.38 A virtual machine's initial MAC address is automatically generated and listed in the configuration file for the virtual machine.
Manually Setting a MACManually configuring a MAC address in the configuration file of a virtual machine will not work unless the first three bytes are VMware-provided prefixes and the last three bytes are unique. If a non-VMware MAC prefix is entered in the configuration file, the virtual machine will not power on.
All virtual machines have two MAC addresses: the initial MAC and the effective MAC. The initial MAC address is the MAC discussed in the previous paragraph that is generated automatically and that resides in the configuration file. The guest operating system has no control over the initial MAC address. The effective MAC address is the MAC address configured by the guest operating system that is used during communication with other systems. The effective MAC address is included in network communication as the source MAC of the virtual machine. By default, these two addresses are identical. To force a non-VMware-assigned MAC address to a guest operating system, change the effective MAC address from within the guest operating system, as shown in Figure 3.39.
Figure 3.39 A virtual machine's source MAC address is the effective MAC address, which by default matches the initial MAC address configured in the VMX file. The effective MAC, however, can be changed in the guest operating system.