Showing results for 
Search instead for 
Did you mean: 

Configuration, Design, and Troubleshooting of Cisco Nexus 1000: FAQ from Live Webcast




With Louis Watta


During the live event, Louis will cover the  configuration and design options for the Virtual Supervisor Module and  Virtual Ethernet Module. He will also go over some common deployment  issues, how to troubleshoot them, and design options for the Cisco Nexus  1010 and 1110 appliances. Louis will also cover some of the common  issues that customers encounter when deploying Cisco Nexus 1000V Series  Switches and how to avoid these problems before they become major  issues.

With Cisco Nexus 1000V Series Switches, you can have a  consistent networking feature set and provisioning process all the way  from the virtual machine access layer to the core of the data center  network infrastructure. Learn how in this interactive webcast.


Louis  Watta is a technical leader in the services organization for  Cisco. Watta's primary background is in data center technologies:  servers (UNIX, Windows, Linux), switches (MDS, Brocade), storage arrays  (EMC, NetApp, HP), network switches (Cisco Catalyst and Cisco Nexus),  and enterprise service hypervisors (VMware ESX, Hyper-V, KVM, XEN). As a  Technical Leader in Technical Services, Louis currently supports beta  and early field trials (EFTs) on new Cisco software and hardware. He has  more than 15 years of experience in a wide variety of data center  applications and is interested in data center technologies oriented  toward data center virtualization and orchestration. Prior to Cisco,  Louis was a system administrator for GTE Government Systems. He has a  bachelor of science degree in computer science from North Carolina State  University.


The following experts were helping Louis to answer few of the questions asked  during the session:

Robert Burns and  Steve  Winters. Robert and Steve are top experts in Datacenter technologies  and have vast knowledge in the field.

Webcast  related links:


Nexus 1000V License and Version Related

Q:  Could you explain the numbers and letters in the NX-OS code for Nexus 1000V?

A: The start of the version number is actually the NX-OS specific version and the rest is the Nexus 1000V version number. For example, in 4.2(1)SV2(1.1); 4.2(1) is the NX-OS version and SV2(1.1) is the 2.1 version of ESXi Nexus 1000V.


Q:  Do I need an Enterprise Plus license on ESXi for Nexus Essentials?

A:  Yes. You need an Enterprise Plus license for any distributed switch, VMware, or Cisco.


Q:  Can we use Nexus Essentials as a training tool for Nexus for free and ongoing training?

A: Yes, it can be used since it is free. There is no specific Virtual Supervisor Module (VSM) for Essentials and Advanced versions, it is the same VSM. You can enable the advanced version for a 60-day grace period.


Q: If I have the Advanced license, do I have to use it?

A: No, if you do not want to use it you do not have to. If you do not want to use the four features specific to the Advanced license, there is no need to use the Advanced license.


Nexus 1000V Upgrade Related

Q:  Are snapshots supported as a pre-upgrade backup option?

A: The official answer is ‘No’. However, it is useful in some laboratory cases. Since it only takes only a few seconds to clone, it is better to clone than take a snapshot.


Q:  What are the impacts when you migrate the VSM from Layer 2 to Layer 3?

A: There is already a document (transition guide) which explains this in detail. It would be good to go through that document.


Q:  Is it recommended to update the Virtual Ethernet Module (VEM) manually (without vCenter Update Manager) if you want to control when the hosts go into maintenance mode one after another, such as not automatically?

A: Yes, if you want to control when and which ESX host goes into maintenance mode you should do it manually.


Q:  How can we perform a full 'level application backup'? CLI & show run for the Switch part and for the vCenter part?

A: It requires coordination between the network administrator and the VMware administrator. Also, it depends on the architecture of vCenter. Coordinate for an outage window, take a clone of the Nexus 1000V, and take a clone of the vCenter server.


Nexus 1000V on Microsoft Hyper-V

Q:  Is it recommended to use a vSwitch on VMware similar to Hyper-V?

A: No. For Nexus 1000V on VMware, it is good to keep the VSM on the VEM module.


Q:  Does the Nexus 1000V for Hyper-V not have Quality of Service (QoS) functionality yet?

A: It does have QoS functionality, but it does not have fair-weighted queing.


Q: When will Nexus 1000V ESXi and Hyper-V be on same NX-OS code version?

A: This will most likely happen with the next major release of Nexus 1000V ESX. It may not be in Release 2.2, but a release later than that.


Q: Will Nexus 1000V on Hyper-V support all the features as Nexus 1000V on ESX?

A: It depends on the deployment. For example, if VMware has a feature that Microsoft does not have, then it cannot be supported. Today we support all features on the Hyper-V version except Virtual Extensible LAN (VXLAN) and fair-weighted queing.


High Availability and VXLAN Related

Q:  Is Fault Tolerance (FT) still supported for the VSMs?

A: No, we do not support Fault Tolerance for VSMs. We already have our own high availability (HA) mechanism between the primary and secondary and there is no reason to support FT, which is an added burden.


Q: Can I have more than 2 VSMs for extra redundancy?

A: No, it is not possible. If you need extra backup, take a clone of the VSM. In case the VMware administrator mistakenly deletes the virtual machine (VM), you can promote the clone back to the VM.


Q:  What happens if the VSM-VSM latency spikes above 10ms?

A: The VSM HA works by broadcasting heartbeats between VSMs every second over the control0 interface. If three consecutive heartbeats are missed, it signals a problem and the VSM goes into degraded mode. If three more heartbeats are missed, the VSMs drop from each other. This indicates either one VSM is down or you end up in a type of split brain mode and when the connection comes up again it goes into split brain recovery. The recommended latency is 10ms. It is alright if it spikes for a second or two, and the VSM may drop and come back. However, try to keep latency low.


Q:  Are there any issues/concerns with the use of overlay transport virtualization (OTV) as the Layer 2 overlay to deploy VSM HA?

A: No, there are no such issues. In fact, it is recommended.


Q:  With Nexus 1000V support across Data Centers (DCs), will VXLAN be supported across DCs as well?

A: Yes. Currently VXLAN is supported across Data Centers.


Q:  Where does the VXLAN gateway functionality reside (at the VEM, the VSM, or the Nexus 1110)?

A: The plan is to support the VXLAN gateway with the Nexus 1110 appliance. Because of the way the VXLAN gateway is meant to work, it requires more dedicated hardware to perform well. Later on it will be released as a VM that can be deployed on the EXSi host.



Q:  Is there one VEM per ESXi host?

A:  Each VEM is an ESX host. Each ESX host runs our Nexus 1000V software, which is called the VEM agent. The Nexus 1000V is comprised of redundant and multiple VEMs.


Q:  Will you support Layer 3 connectivity for Stretch Mode in the future?

A: Layer 3 connectivity is supported between VSMs and the VEMs, but there is no plan for Layer 3 control for HA between primary and secondary VSMs. As of now it is Layer 2 only.


Q:  Do you need to renew the Secure Sockets Layer (SSL) certificate?

A:  No, the SSL certificate is self-signed. There is no need to regenerate the certificate.


Q:  Is OpenFlow support part of the current Nexus 1000V roadmap?

A:  Yes. This was detailed in the first slides that detail the roadmap features. Cisco intends to include this in a future major release; however, there is no commit date yet.


Q:  Nexus 1000V does not use virtual network tag (VNtag) technology as Fabric Extender (FEX) does, correct?

A: That is correct. Nexus 1000V does not use VNtag like Unified Computing System (UCS) does.


Q:  It is my understanding that Nexus 1000V is unable to work standalone and it requires the VSM and the VSM requires vCenter or the System Center Virtual Machine Manager (SCVMM). Is this correct or are any of these components optional?

A: That is correct. Nexus 1000V works with the infrastructure provided by these hypervisors.


Q:  Is vCenter Update Manager (VUM) supported on the vCentre WEB GUI yet?

A:  It should be supported in Release 5.1 and later.


Q:  It does not seem to be supported yet on Release 5.1 Update 1.

A:  OK. I would verify this in VMware vSphere Update Manager 5.1 Update 1 Release Notes. Look at VUM Web Client Plugin. You might have to install it first.


Q:  Since the VSMs are Layer 3, is NetFlow export supported?

A: Yes. It is supported.


Q:  Do you run into issues if vCenter is down when you try to bring everything up if the management interface is on the VEM?

A: No, you do not. If you complete the configuration correctly, the VEM module has a programming in itself and it will initialize that and bring up the interfaces which allows them to talk even if the VSM or vCenter is down.


Q: How does Nexus 1000V differ from Nexus 7000?

A: The Nexus 7000 is a hardware-based switch. The Nexus 1000V is a virtual (software-based) switch. Nexus 1000V works only with ESXi or Hyper-V hypervisors.


Q:  Are there any control plane concerns when the tech-support file is generated during operational hours?

A: There should not be any such concern. The VSM usually runs well and is a pretty efficient code.


Q:  Are any other sessions planned to cover Hyper-V in more detail - such as a demonstration of an installation, configuration, and so on?

A: We can do that. It is not currently planned, but it would be great to do it.


Q:  Use case of Nexus 1000V over VMware DVS ?

A: Nexus 1000V is about the same as Distributed Virtual Switch (DVS) feature-wise. Where Nexus 1000V adds value is that it is multi-hypervisor, multi-cloud supported and there is a lot to add on services with the use of vPath. Today you can VSG and Adaptive Security Appliance (ASA) 1000V with the Nexus 1000V for tenant security and full firewall functionality respectively. There is also a Cloud Services Router (CSR) which gives functionality of Layer 3 in the hypervisor environment. Work is in progress with Citrix and Imperva and also there will be a VXLAN gateway as well as Nexus 1000V inter-cloud product that allows you to take a (VM) from the private cloud and migrate them to third party web services environment.


Q:  Do Nexus 1010 and 1110 use ESXi or Hyper-V?

A: You can put a VSM VM on top of an ESXi or Hyper-V host. The Nexus 1010 and 1110 run NX-OS and the VSM runs on top of it as a VM.


Q:  What is the marketability of Nexus 1110 and can it interoperate in a multivendor environment?

A: Nexus 1110 is a Cisco appliance that runs NX-OS code and is aimed at network administrators who own the virtualization platform. They get the platform they are comfortable with (NX-OS) and also the ability to load Virtual Security Gateway (VSG) and ASA 1000V. It can also load Citrix Netscalar and Imperva WAS. The idea is to have the network administrator own the platform and remove the dependence on ESX or Hyper-V. Interoperability-wise there is not much to it except that it is a virtualization platform; you can only put appliances that Cisco has already certified. It will be made broader with the addition of a lot more features and functionalities.


Q:  Could you elaborate further on specific functions of the three VLANs between VSM and VEM (Management, Control, and Packet)?

A: These are three different interfaces and do not need to be on different VLANs. Initially it was a good idea to keep these on separate VLANs, but as customers started deploying the product they were more comfortable with using same VLAN and it is fine to do so. The Control interface is used for control traffic which is mostly heartbeat between VSMs. If you use Layer 2 control mode, it is also used to send heartbeats to the VEM. The Management interface is used to connect to the VSM via the CLI or SNMP or any other management application. If you use Layer 3 control mode, the Management interface becomes the default control interface to send heartbeats between the VSM and VEM. The Packet interface is only used in Layer 2 mode and is used to pass Internet Group Management Protocol (IGMP) and Cisco Discovery Protocol (CDP) information from the VEM to the VSM. In Layer 3 mode, everything that goes over the Packet interface is encapsulated and goes over either the Control or Management interface. Even if in some mode all these interfaces are not used, it is required that they are present for the VSM VM to initialize correctly.


Q:  Does VEM to VEM traffic have to pass through an external switch?

A: The VEMs do not talk to each other directly. If a VEM sees traffic that is not destined to any VM it is connected to, it forwards the traffic to an upstream switch and lets the upstream switch deal with it.


Q:  Can you integrate (deploy) both CSR 1000V and Nexus 1000V on the same ESXi?

A: Yes. Actually today the CSR does not have any requirement for Nexus 1000V and you can use it without Nexus 1000V at all.


Q:  Is it in the plan to add Layer 3 functionality in Nexus 1000V?

A: We do support Layer 3 functionality between the VSM and VEM, but not between VSMs.


Related Information


Hi Louis,

I just have a question about Port Security in the Nexus 1000v. I applied Port security on the Port-profile level to dynamically remember 1 MAC address and to shut down the port if limit has been reached, but I do not see the Virtual MAC addresses of the existing VM's in when I do a show port-security. My question is, how do I apply this security to the current VM's in the Port-profiles? Do the changes take effect immidiatly on the new VM's and not the existing ones?

port-profile type vethernet DMZ_Internal

  vmware port-group

  switchport port-security violation shutdown

  switchport mode access

  switchport access vlan 123

  switchport port-security maximum 1

  no shutdown

  max-ports 128

  description "vlan 123"

  state enabled

NX1000v-SW01# sho port-security

Total Secured Mac Addresses in System         : 0

Max Secured Mac Addresses limit in System       : 8192


Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action

                (Count)       (Count)          (Count)



Cisco Employee


Great question. Let me make sure I understand what the flow.

  • port-profile DMZ_Internal already existed and had VM attached to it
  • You added the port-security settings to the port-profile
  • Since adding teh port-security settings the current VMs are not showing up with port-security.

Is that correct?


This is correct Louis


Great question. Let me make sure I understand what the flow.

  • port-profile DMZ_Internal already existed and had VM attached to it
  • You added the port-security settings to the port-profile
  • Since adding teh port-security settings the current VMs are not showing up with port-security.

Is that correct?



You've not enabled port-security. The command 'switchport port-security' enables port-security on the interface:

So please add the 'switchport port-security' command to the port-profile and see if it makes a difference.

Also, it would be good if you can post these questions under the Discussions section (rather than the documents section).



Content for Community-Ad