Wednesday, May 12, 2010

Cisco Nexus 1000v Virtual Network Switch - The Eyes Returns 8-)

Today I want to talk a little bit about the importance of knowing what's going on in the virtual network environment. Nowadays it is a common practice for companies to move to a virtual server environment after realizing the real advantages of doing so. I don't want to talk about the advantages of a virtual environment, since in my opinion, pretty much everyone interested on this topic will already understand its importance, from an economic and environmental perspective; but I would like to talk about the virtual network environment in which this virtual servers infrastructure relies.

Traditionally, network groups have managed 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 virtual networking:Blind spots and 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. 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. Admins 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 virtual 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. Another important product among this family, is the Cisco Nexus 1000v virtual network switch, which gives network administrators visibility and control of virtual networking and the one we will be reviewing on this post.


Cisco Nexus 1000v virtual network switch: Virtual network management

While virtualization networking management tools are helpful for monitoring, securing and managing virtual networks, they don't give control of the virtual network back to network administrators. One solution to this problem lies in implementing the Cisco Nexus 1000v distributed virtual switch (vSwitch). 

The Cisco Nexus 1000v distributed virtual switch shifts virtual network management inside a virtual host back to network administrators and helps to make peace between server and network teams. In addition to solving the political problem of administration, it also adds many advanced features and better security to virtualization networking inside a host. The Nexus 1000v provides features not found in the VMware-provided vSwitches, including QoS, support for Switch Port Analyzer (SPAN), Encapsulated Remote SPAN (ERSPAN), NetFlow, RADIUS and TACACS, access control lists, packet capture/analysis, DHCP/IGMPv3 snooping and much more.  

How the Nexus 1000v distributed virtual switch works

The Cisco Nexus 1000v distributed virtual switch consists of two components: a Virtual Supervisor Module (VSM) and a Virtual Ethernet Module (VEM). The VSM manages one or more VEMs as one logical switch and supports up to 64 VEMs. All the configuration of the VEMs is done using the VSM with the NX-OS command line interface, which is pushed to all the VEMs.


The VSM uses port profiles that are configured for each VEM and then appear as port groups in the vCenter Server. The VSM is integrated with the vCenter Server so all network configuration involving the VEMs is synchronized between them. The VSM is packaged as a virtual appliance and is deployed on an ESX or ESXi host using the vSphere Client. Once deployed and powered on, the VSM is managed using a command line interface (my favorite ;)). The VEM is installed on each ESX and ESXi host, and only one VEM can exist on a single host. The VEM executes as part of the VMKernel and uses an API to interface with the vCenter Server and virtual machines. The VEM gets all of its configuration information from the VSMs, and if it loses connectivity to the VSM, it will continue to switch traffic based on the last known configuration.

The Cisco Nexus 1000v distributed virtual switch can be used with any physical switch, regardless of the manufacturer. This allows anyone who uses non-Cisco physical network gear to take advantage of the 1000v to handle virtual network management.

Preparing the network team for virtual network management

The Cisco Nexus 1000v distributed virtual switch hands virtual network management back to network administrators so they once again have total control of the entire network environment. It ends the feud between server administrators and network administrators that often occurs when deploying virtualization. However, just giving control of the virtual network back to network administrators is often not enough. Many network administrators are accustomed to dealing only with the physical world, and virtualization may be new to them. They are commonly leery of virtualization and put up resistance. Educating everyone involved in the virtualization project is the best way to combat this problem.
Educational steps for network administrators include:

  • Explaining the concept of virtual switches and virtual NICs and how they interact with physical switches and physical NICs.
  • Demonstrating setup and configuration of a virtual switch, how to install a virtual NIC in a VM, and how to connect the virtual NIC to a virtual switch.
  • Explaining how ESX uses trunked network ports and how 802.1Q VLAN tagging works in a virtual networking environment.
  • Explaining virtual network security principles and how virtual switches are isolated from one another so traffic can't leak between them.
  • Demonstrating NIC teaming and failover in a virtual switch.  
I hope this have been informative for you and I want to thanks you for reading this post.

No comments:

Post a Comment