Traditionally, network groups manage the physical network connection of a server from the switch all the way to...
the NIC. Virtualization changes that by extending the network into the server, snatching control out of the network administrator's hands. This poses a host of new problems that include a lack of visibility within the server and a lack of manageability of virtual network switches.
Virtual network switches effectively extend the physical network from the NIC in a VMware ESX host to a virtual switch that is managed by the ESX server, as well as a virtual NIC that connects a virtual machine (VM) to the virtual switch. This virtual switch is usually managed by virtualization administrators and not network administrators, which can cause some concern and friction between the two groups because the network admins can no longer control and manage part of the network that is inside a virtual host.
The role of virtual network switches
Virtual switches are the core networking component on an ESX and ESXi host. A virtual switch is built and contained in the RAM of a host and connects the physical NICs (referred to as uplinks) in the host server to the virtual NICs in virtual machines. Virtual switches (vSwitches) emulate many of the traits of traditional Ethernet switches and can perform many of the same functions, such as forwarding frames at the data link layer and VLAN segmentation, and they also support copying packets to a mirror port for use with a sniffer or IDS system. In VMware VI3, there was only one type of vSwitch; in vSphere, there are now three different types that you can use: the standard vSwitch, the new distributed vSwitch, and third-party vSwitches (Cisco Nexus 1000v). With the exception of the Nexus 1000v, you can have multiple vSwitches configured on a single host, but a single physical NIC can only be assigned to a single vSwitch.
Challenges of virtualization networking: Blind spots and a lack of control
One of the challenges with vSwitches is that much of the traffic between VMs on the same host never leaves the host, so it does not go over the physical network. As a result, it cannot be monitored or managed by the network devices on the physical network, such as IDS/IPS systems. In a post I did a while back, I explain the circumstances in which a VM's network traffic never leaves the host. To summarize, this occurs when VMs are connected to the same vSwitch and the same port group on that vSwitch. What happens is that all network traffic between those VMs stays within the host's memory subsystem as both the vNICs and vSwitch are contained in a host's memory. This can be desirable from a performance standpoint, as transferring data in a host's memory is much faster than sending it over the network. But it is not desirable from a network standpoint because the data cannot be seen by the physical network and, consequently, by network firewalls, QoS, ACLs and IDS/IPS systems that are designed to protect servers at the network layer.
Another challenge with virtual switches is that both the standard and distributed vSwitch do not have many features and are basically dumb, unmanaged switches. As a result, there is very little control over what happens on a vSwitch and no integration between vSwitches and physical switches.
One last challenge with virtual switches is with adding devices to the network. Most network admins like to control what is plugged into their network. They will typically disable ports that are not in use and set port security on all ports so that if a different NIC is plugged in, they are alerted to it and the port is disabled. With a vSwitch, they lose this control as they only have control of the uplink ports from the physical NICs in the host and not the many virtual machine ports that exist on a vSwitch.
New tools address virtualization networking management
These challenges all lead to reduced visibility and control of network traffic, which results in a less secure environment, incomplete network traffic analysis and unhappy network admins. One way to address this is to use network management products that are designed to work in virtual environments.
These typically allow you to secure, monitor and control all the virtual networking traffic on a host. These products typically deploy as virtual appliances on a host and either sit inline between VMs in a protected vSwitch or use the new VMsafe technologies in vSphere, which can protect VMs without being inline. Some examples of these types of products include Reflex System's Virtual Management Center, Altor Networks Virtual Firewall, and Catbird's vSecurity.
In part 2 of this series, learn how the Cisco Nexus 1000V virtual network switch gives network administrators visibility and control of virtualization networking.