Cisco Nexus 1000V – What should you know before an Update/Upgrade

As a Technical Account Manager, in my case at VMware, you came across a variety of customers and 3 of my 5 current customers running Cisco Nexus 1000V. Because two of my previous customers, when I was a Consultant, had also Nexus 1000V, I have some experience with this product. I saw that the main reason for my customers to run Nexus 1000V is the operational separation (separation of VMware and Networking Team). Such customers running Nexus 1000V for a long time (since 4.0) and don’t want to change this because it would be a bigger operational effort to change the internal workflows of doing things in this areas.
All of these customer are currently in the progress of planning their upgrade from their current vSphere version incl. Nexus 1000V to vSphere 5.5 U2 or 6.0. I will show in this post based on an example infrastructure what you should consider when upgrading an infrastructure with Nexus 1000V.
But before we start I would like to explain in short what the Nexus 1000V is and which components it includes.
The Cisco Nexus 1000V for VMware provides a distributed, Layer 2 virtual switch that extends across many virtualized hosts. The Cisco Nexus 1000V manages a datacenter defined by the vCenter Server. Each server in the datacenter is represented as a line card in the Cisco Nexus 1000V and can be managed as if it were a line card in a physical Cisco switch.
The Virtual Ethernet Module (VEM) runs as part of the VMware ESXi kernel and replaces the VMware Virtual Switch functionality. The VEM uses the VMware Virtual Distributed Switch (vDS) API, therefor you need vSphere Enterprise Plus licensing to be able to use Nexus 1000V. The VEM acts as a line card and runs in each ESXi host to handle packet forwarding and other localized functions.
The Virtual Supervisor Module (VSM) controls multiple VEMs as one logical modular switch. Instead of physical line-card modules, the VSM supports multiple VEMs running in software inside the ESXi hosts. Configuration is performed through the VSM and is automatically propagated to the VEMs. Instead of configuring soft switches inside the hypervisor on a host-by-host basis, administrators can define configurations for immediate use on all VEMs being managed by the VSM, from a single interface.

Example environment

Current

  • vSphere 5.0 U3
  • Nexus 1000V 4.2(1)SV2(1.1)

Planned Upgrade

  • vSphere 5.5 U2
  • most recent Nexus 1000V version

Cisco is offering a Cisco Nexus 1000V and VMware ESX/ESXi Upgrade Utility site, where you can select the current version of N1KV and vSphere and then choose the version you wanted to end up.
n1kv_01
In my case I selected that I wanted to use 5.5 and the most recent N1KV version. As you can see the suggestion is to upgrade vCenter first, then VSM and finally all the hosts incl. VEM modules.
Well depending on my experience I would suggest to update the VSM (Virtual Supervisor Module) first, to a version which is supported by the current and the planned vSphere version. For this purpose I created a little table which shows the available Nexus 1000V versions and the compatibility to the respective vSphere version.

Attention: The internal data of table “26” is corrupted!

As you can see 4.2(1)SV2(1.1) is not supported with vSphere 5.5. Therefor we need to update either to 4.2(1)SV2(2.3) or 5.2(1)SV3(1.4). But which version should you use?
The first part of the version 4.2(1) or 5.2(1) refers to the NX-OS version of the base software that is used in the Nexus 1000V. The second part SV2(2.3) or SV3(1.4) I would describe as major verion (SV2,SV3) and minor version (2.3, 1.4). Minor versions will repeat when there is a major version changed e.g. SV4(1.4). From Cisco side the recommendation is the use the latest version of Nexus 1000V (5.2(1)SV3(1.4) as of June 16th, 2015). Another different between 4.2(1) and 5.2(1) is the feature set. Nexus 1000V version 5.2(1) includes new features around additional scale, IPv6, TrustSec enhancements, Storm Control, BPDU Guard and others which you can find in the Release Notes of the respective Nexus 1000V version. Version 5.2(1) also includes vSphere 6.0 support which, from my point of view, will not be released in the 4.2(1) track.
When an Nexus 1000V version 5.2(1)SV3(1.1) or earlier was installed the vDS version of the created switch is 4.0 and will not change if you upgrade to the newest version. Starting with 5.2(1)SV3(1.2) the created Nexus 1000V switch is vDS version 5.0. In vSphere 6.0 you can’t create Virtual Distributed Switches with version 4.0 but you can still manage such switches, so there is no problem when using Nexus 1000V switches which were upgraded from previous versions.
After the upgrade of the VSM to the most recent version, we can start to upgrade vCenter to the desired version, in our example 5.5 U2.
Last but not least we need to upgrade the hosts to 5.5 U2 which can be a little bit tricky if you don’t know that the VEM is not included in the Vanilla nor the Vendor custom ESXi installer. Therefor you need to create a custom ESXi image which includes the VEM required for the VSM version. To create a custom ESXi image see this post.

Licensing Information

With Cisco Nexus 1000V version 4.2(1)SV2(1.1) a tier-based licensing model was introduced which includes an Essential and Advanced version. The Essentials version is available at no cost and Cisco Technical Assistance Center (TAC) support is optional but recommended. In the following table you have a comparison between the two licensing versions.

FeaturesEssential EditionAdvanced Edition
Layer 2 switching: VLANs, private VLANs, VXLAN, loop prevention, multicast, virtual PortChannels, LACP, ACLs
Network management: SPAN, ERSPAN, NetFlow 9, vTracker, vCenter Server plug-in
Enhanced QoS features
Cisco vPath
Storm Control
BPDU Guard
DHCP Snooping
IP Source Guard
Dynamic ARP Inspection
Cisco TrustSec SGA Support
Security Group Tagging (SGT) Support
Security Group ACL (SGACL) Support
VXLAN gateway as a Virtual machine and as an appliance on the Nexus 1010 or 1110 platform
VXLAN BGP control plane connecting multiple switches running compatible protocol
Cisco Virtual Security Gateway (VSG)SupportedIncluded
Other Virtual Services (Cisco ASA1000V, Cisco vWAAS, etc.)Available separatelyAvailable separately

Cisco Nexus 1000V is still licensed by CPU sockets where a VEM module is installed.

Additional Information

Cisco Nexus 1000V for VMware vSphere Data Sheet
Cisco Nexus 1000V Installation and Upgrade Guides
Cisco Nexus 1000V Configuration Guides (includes Licensing Guides)
I am a member of the Cisco Champions Program. Cisco Champions are passionate about Cisco and enjoy sharing our knowledge, expertise, and thoughts across the social web and with Cisco. I am not a representative of Cisco. My views as a Cisco Champion are my own.”

4 Responses

  1. Stan says:

    Hi Manfred,
    Great article! in my experience (failed attempt at upgrade from 4.1 update 1 to 5.1) vCenter upgrade can result in unusable vCenter or not go as smoothly as vmware or cisco upgrade documents state. As for plan B, is there a way to migrate existing Nexus 1k and hosts attached to it to newly built vCenter 5.5 or 6 with minimum downtime (without recreating portgroups on standard switches)?
    Thanks

  2. Eric says:

    Hi Manfred,
    Vmware seems to put an End Of Support aate on the vSphere 6.5 update 1 and i know its capable to install on 6.5 .Can you share some case for people still use n1kv in Vsphere 6.0 or they just all mirgreate to Vmware dvs?
    Thanks

  3. Hi Eric,
    we (VMware) will shutdown the API for 3rd party switch integration in future releases. 6.5 Update 1 is the last release you can use 3rd party switches. You will get a warning if you upgrade to Update 1 and 4rd party switches are in use. But you can still use 6.0 until EOL (2020) with 3rd party switches.
    It depends for what you are using e.g. N1KV. Is it just for separating virtualization team from networking team or do you use specific features of the N1KV, DVS is not offering?
    Cheers,
    Fred

Leave a Reply

Your email address will not be published. Required fields are marked *