Introduction to the Nexus 1000V

The Nexus 1000V is a software-based Cisco NX-OS switch that integrates into VMware vSphere 4 and operates inside the VMware ESX hypervisor. With the 1000V your virtual servers have the same network configuration, security policy, and diagnostic tools as your physical servers. VMware has also certified it to be compatible with vSphere, vCenter ESX and ESXi.

System Overview

The Nexus 1000V has two major components…

• Virtual Ethernet Module (VEM) – Think of this like a line card in a switch. The VEM actually integrates with the ESX(i) kernel. It uses the VMware vNetwork Distributed Switch (vDS) API to provide advanced networking capability to virtual machines. The VEM also takes configuration information from the Virtual Supervisor Module (below) and performs Layer 2 switching and advanced networking functions including port channels, QoS, PVLANs, ACLS, port security, Netflow, and SPAN/ERSPAN.
• Virtual Supervisor Module (VSM) – Think of this like the supervisor module in your switch. The VSM actually controls multiple VEMs as one logical modular switch. Instead of physical line card modules, we define profiles for immediate use on all VEMs.

Cisco also allows you to run the 1000V in a active/standby pair, these should run on separate VMware ESX hosts to ensure high availability if one host fails.

While the VEM actually lives on the ESX server, the VSM is actually a guest machine running in its own VM which runs inside your virtual datacenter. You can access the VSM just like you would a normal physical switch using the CLI via SSH. The VSM and VEM communicate on two separate VLANs.

• Control VLAN – The Control VLAN handles extended management communication between the VEM and VSM similar to control communication of the Nexus 7000, or Catalyst 6500. It also maintains a synchronization between the active/standby VSMs and carries a 2-second heartbeat between the VSM and VEM.
• Packet VLAN – The Packet VLAN is used for carrying network packets from the VEM to the VSM, such as CDP, Interior Gateway Management Protocol (IGMP).

STP Oddities

The Nexus 1000V does not run spanning tree protocol (STP). To prevent loops, it has a rule set that it adheres to. All BPDUs are dropped, no switching is allowed from physical NIC to NIC, and layer 2 local MACs address packets are dropped on ingress. In addition, each VEM learns and independently maintains a separate MAC table. The virtual machine’s MAC addresses are statically mapped including vEthernet interfaces, vmknics (used by the hypervisor for management, vMotions, iSCSI, NFS… ), and vswifs (the VMware service console interface). Devices external to the VEM are learned dynamically as normal.

Scalability

The Nexus 1000V supports the following configuration…

• 2 VSMs
• 64 VEMs
• 512 Active VLANs
• 2048 ports (Eth + vEth)
• 256 Port Channels

Each VEM supports…

• 216 vEthernet Ports
• 32 Physical NICs
• 8 Port Channels

Conclusion

Enough of the hype, why should you invest in the 1000v?? Well, if you’re already on the Nexus platform in your datacenter its a no brainier, but even if you’re not, the Nexus 1000v does some things to help us out…

• Eliminate the management overhead of dealing with separate virtual switches (one for each ESX host).
• Present a familiar interface to your engineers something they are familiar with and let them manage the connection down to the host, virtualized or not.
• Ease of management for systems engineers. No more vswitch reconfiguration when migrating to new servers.
• Allow system engineers to easily assign profiles to a server no matter what ESX host it resides on. Prevents them from having to mess with the network side of things.
• Give server and network guys insight into the virtualized environment. Give virtualized servers the same bells and whistles (ACL’s, netflow, Port spanning, Vlans, etc.) we can get on our physical servers connected to real switches.