An internal virtual switch is used to provide communication to virtual machines that are on a single ESX host. In other words, when you deploy an internal virtual switch, virtual machines on the ESX host can communicate with one another but are completely isolated from the rest of the network and are unable to communicate with other VMs on other ESX hosts or any other devices on the network. Figure 4.1 shows a sample of this configuration. A possible usage scenario for this type of virtual switch is isolating a single application for testing purposes where you build a series of VMs on a single ESX host that are required by this application, and then you test against this application before allowing to communicate with the rest of the production network.

Figure 4.1. Internal only vSwitch.

A single adapter virtual switch is one that is supported or serviced by a single physical NIC. This NIC is what allows the virtual switch and the VMs access to the rest of the network. Figure 4.2 shows an example of how this can be implemented.

Figure 4.2. Single NIC vSwitch.

NIC teaming, or multiple adapter virtual switches, is a virtual switch that is supported by two or more NICs. This type of virtual switch allows for fault tolerance and High Availability. This is a typical scenario for mission-critical applications that you want to make sure have the maximum resources available to them and built-in failover and packet distribution. Figure 4.3 shows a sample configuration.

Figure 4.3. NIC Team vSwitch.

The Service Console connection type allows for communication to and from the Service Console. During the installation of ESX 3.5, a Service Console port labeled vswif0 is automatically associated with vSwitch0, as illustrated in Figure 4.4. The Service Console requires that you configure the IP stack, including a dedicated IP address, a subnet mask, and a default gateway.

Figure 4.4. Service Console port group.

Because the Service Console is a critical component, you might want to think of providing some redundancy, and as such, two scenarios exist to help facilitate that, as follows:

• Multiple Service Console ports: Create a Service Console port group on two different virtual switches that are serviced by two different physical NICs and assign each service console a different IP address. This creates a redundant second entry point into your ESX host should the primary fail. Figure 4.5 illustrates this scenario.

Figure 4.5. Multiple SC port groups.

• Service Console NIC Team: Add a second physical NIC to the same virtual switch where the original Service Console port groups reside, and therefore, you create redundancy at the physical level. If a NIC fails, the second one picks up seamlessly. In this scenario, you do not need a second IP address because it is being shared. Figure 4.6 illustrates this scenario clearly.

Figure 4.6. SC NIC Team.

A VMkernel port group connection type allows you to configure communication for technologies like VMotion, iSCSI, and NAS/NFS. This connection type requires you to configure the IP stack. The reason behind this is that these technologies will more than likely be connecting to different VLANs or different networks altogether. Figure 4.7 gives an example of how this works.

Figure 4.7. VLANs.

A virtual machine (VM) port group opens communication between the VMs configured on the virtual switch and the rest of the physical network by connecting the virtual switch to the physical switch by way of the NIC or NICs configured to support the virtual switch. Figure 4.8 shows this configuration scenario.

Figure 4.8. VM to physical network connectivity.

A trunk port is a port on the physical switch that you configure to be aware of other VLANs that exist on other switches. Anything that plugs into this port is able to pass IP communications to all the visible VLANs. Traditionally, a switch could see and give access only to a single IP segment or subnet. With port trunking, you can now configure multiple ports on multiple switches to be part of the same VLAN. This characteristic helps overcome geographic limitations and eases management. Figure 4.10 illustrates trunk ports.

Figure 4.10. Physical switch trunk port.

ESX has built-in support for 802.1Q VLAN tagging. The first thing you do to get 802.1Q VLAN tagging to work is to connect a physical NIC to a port that is configured as a trunk port on the physical switch. You then assign this NIC to a vSwitch. What you have accomplished so far, then, is making all the VLANs that are configured on that trunked port visible to the vSwitch.

Now you create port groups on this virtual switch. Port groups, as the name implies, are groupings of several ports and are configured to see a particular VLAN by configuring a VLAN ID in the port group that matches the VLAN ID assigned on the physical switch. Now when you try to add virtual machines to these port groups, your VMs are part of the VLAN assigned to that port group. Figure 4.11 illustrates VLAN tagging.

Figure 4.11. VLAN tagging.

Three types of Layer 2 security policies can be configured on virtual switches or port groups from the Security tab:

• Promiscuous Mode: If set to Accept, this setting would pass all the unicast frames that pass through the virtual switch to a virtual machine connected to that virtual switch. This setting is set to Reject by default to prevent frames destined for a particular VM from being read by other VMs. You should enable this mode only if you are running troubleshooting tests or running intrusion detection systems that require the system to investigate these frames.

• MAC Address Changes: If set to Reject, this setting would deny incoming IP traffic from reaching the VM if the MAC address defined in the guest operating system does not match the MAC address listed in the VM’s configuration file or vmx, as illustrated in Figure 4.13. By default, this setting is set to Accept.

Figure 4.13. VM MAC match configuration file.

• Forged Transmits: This setting is the same as the MAC Address Changes setting, except it controls the outgoing IP traffic rather than the incoming. If set to Reject, this setting would deny outgoing IP traffic from the VM if the MAC address specified in the guest OS does not match the MAC address listed in the VM’s configuration file or vmx. By default, this setting is set to Accept.

When applying security to a virtual switch or to a port group, you need to understand the policy processing and what takes precedence over what. You can apply the policy as follows:

Traffic shaping gives you greater control over the amount of outgoing bandwidth available to virtual machines and enables you to tweak it and prioritize it. Traffic shaping is a great feature and can be useful in some cases in which adding more physical NICs is not permitted. However, given the relatively cheap cost of adding network interface cards, it would be much easier to add more NICs and increase network bandwidth using NIC teaming than it is to tweak bandwidth with traffic-shaping policies.

Traffic shaping is disabled by default; however, should the need arise for traffic shaping and should you need to enable it, you have three configurable settings that can help you tweak bandwidth:

NIC teaming provides for fault tolerance, redundancy, and load balancing of outgoing IP traffic from the virtual switch. You can adjust the settings on the NIC Teaming tab of the vSwitch Properties window, as shown in Figure 4.14.

Figure 4.14. NIC teaming.

ESX 3.5 has built-in capabilities that would notify it when a network failover was detected from one physical NIC to the other, and you can configure this either based on virtual switch or port groups in one of two ways:

The Notify Switches option is a great performance tweak. When set to Yes, it notifies physical switches of changes such as the following:

This feature is especially helpful because, without it, virtual machines would experience latency and slowness as the physical switches update their lookup tables. This is especially helpful after VMotions and, of course, in the event of failovers.

The Failback policy determines what happens when a failed physical NIC is functional again. There are two options:

When the Explicit Failover Order option is selected, you can manually control what happens in the event of a failover. For example, in the Active adapters, the topmost adapter is always the first one to be used; however, you can control which adapter is on top. The Standby adapters are the ones that are used in the event the active adapter fails; again, you can control which one is used first. The Unused adapters are simply out of commission and should not be used.