Cisco Nexus 1000v Virtual Switch for VMWare ESX

Recently the server group came to me and let me know that they had purchased Nexus 1000v licensing for the new ESX cluster.  As a Cisco geek, I was pretty stoked to get to work with the Nexus 1000v as it was virtual and the first Nexus platform I would get to work on.

In this article, I am going to try to lay out some of the basic nomenclature surrounding the Nexus 1000v.  If you are like me and have been living in your network world with little exposure to the guts of VMWare, this article will hopefully help bring you up to speed.

The first concept that can get a bit confusing in the VMWare world is the way they refer to their NICs.  The physical NICs on the server are referred to as vmnic<x> starting with vmnic0.  When I was first getting started, I kept wanting to think that these were virtual NICs since it started with VM, but that is not the case.  Usually the onboard NICs are the first vmnics and then any expansion cards are after that.


Next there is the matter of the different types of virtual switches that can be configured.  The most basic type is the standard vSwitch.  To the average networking guy this is basically configuring the ESX host's interfaces to be used as tagged (trunked) VLAN interfaces.  Each VLAN that you want to support is added as a standard vSwitch.  Once added the vSwitch can be associated with any VM.  The drawback to vSwitch from a VMWare perspective is that they need to be identically configured on every ESX host in the cluster to allow for vMotion of VMs since their network has to be present for them to move.  From a network guy's point of view the drawbacks are numerous including:

• No ACL capabilities.
• No SNMP monitoring of traffic counters.
• No Netflow monitoring.

Realizing the problems with vSwitch design for vMotion, VMWare came up with the distributed vSwitch or DVS.  This switch is configured for the entire cluster and ensures that all members of the cluster have the same network configuration available for VMs.  From a VMWare perspective this is the cat's meow, but it still lacks SNMP, ACL and Netflow capabilities that us networking nerds crave.  

That's where the Nexus 1000v comes in.  It is a cisco developed distributed vSwitch that uses the VMWare APIs to give a full NX-OS controlled DVS.  If you can do it in NX-OS you can do it with the Nexus 1000v.  In my next post I will discuss how the Nexus 1000v architecture interacts with VMWare.

Configuration Rollback Update

Jeff over at www.fryguy.net has just blogged about the Cisco Archive and Configure tools that I discussed back in March.  He does a good job of explaining how to use it to avoid long downtimes for a mistyped command.

Review of Enterprise Network Testing: Testing Throughout the Network Lifecycle to Maximize Availability and Performance

I have recently finished reading the new Cisco Press book Enterprise Network Testing: Testing Throughout the Network Lifecycle to Maximize Availability and Performance by Andy Sholomon and Tom Kunath.  Prior to reading this book I will admit that my only experience with network testing has been much more adhoc than the structure they present.


The first section of the book is devoted to learning about the methodologies, tools and types of network testing.  This section discusses how to test networks and where in the lifecycle testing should take place.  It also builds a case for why network testing is important and how to get funding and management support for testing.  If you don't get anything else from this book, that chapter is probably the most important.  Getting budgets for testing capital expenses (lab gear, space, testing tools) and operational expenses (labor, power, cooling) require showing the return on investment that can be had from preventing downtimes later.


The second section of the book looks at how testing of various types has helped real world businesses.  These case studies give the reader a good idea of tangible benefits of network testing.  Most of this section reads more like a business textbook than a technical guide which should help network engineers bridge the gap to the holders of the purse strings.  As network engineers, we have to come out of our geek world and explain to non-geeks why what we do matters to them and to them business matters.


Finally in the last section the authors explore various network projects and the test plans used to verify their operation.  For someone like me with no formal network testing training or experience, this section is an invaluable resource.  The test plan examples are very thorough and will be a great reference for building your on test plans.


I highly recommend this book, although it may not be as sexy as say a book on the Nexus 7000 or FCoTR it provides useful skills for a network engineer to improve their network.