VM - FEX and Nexus 1000v relationship

Similar Questions

• How change 1010 Nexus and Nexus 1000v IP address

  Hi Experts,

  We run two VSM and a NAM in the Nexus 1010. The version of Nexus 1010 is 4.2.1.SP1.4. And the Nexus 1000v version is 4.0.4.SV1.3c. Now we need to change the IP address of management in the other. Where can I find the model SOP or config? And nothing I need to remember?

  If it is only the mgmt0 you IP address change, you can simply enter the new address under the mgmt0 interface. It automatically syncs with the VC.

  I guess you are trying to change the IP address of the VC and the management VLAN. One way to do this is:

  -From the Nexus 1000v, disconnect the connection to the VC (connection svs-> without logging)

  -Change the IP address of the VC and connect (connection-> remote ip address svs)

  -Change the address for mgmt0 Nexus 1000v

  -Change the mgmt VLAN on the 1010

  -Change the address of the 1010 mgmt

  -Reconnect the Nexus 1000v to VC (connection-> connect svs)

  Therefore, to change the configuration of VLANS on the switch upstream, more connection to the VC as well.

  Thank you

  Shankar

• ESXi 5 and Nexus 1000v

  Hello

  I have an ESXi 5 but only NIC I am migrating the VSS for Nexus 1000v. I installed Nexus VEM correctly and do primary and secondary, VSMs configured uplink port groups all according to the guides from Cisco. When I try to add a host under the link, I have first to migrate the vnic0 for the Group of appropriate uplink ports and it then asks me to migrate the management port (I think it is vmk0) so if I create a group of ports on Nexus to migrate a management port or do not migrate at all I always lose connectivity to ESXi.

  Can someone please share the configs of the Nexus 1000v and how to migrate properly vnic0 and vmk0 (with a single physical NETWORK adapter) so that I do not lose connectivity?

  Thanks in advacne.

  Remi

  control is vlan 152 and package is 153.

  You can make same vlan. We have supported using the same vlan for the control and the package for several years now.

  Louis

• vCenter Converter support for dvSwitch and Nexus 1000v

  Nothing changed since it was published in May 2009:

  http://www.VMware.com/support/vSphere4/doc/vsp_vcc_41_rel_notes.html

  VMware vCenter Converter vCenter Server 4.0 | May 21, 2009 | Build 161418

  Document last updated: May 21, 2009

  Import and export tasks fail when a vNetwork Distributed Switch is selected as the network for the virtual machine target

  When you create an import or export tasks and select a vNetwork Distributed Switch in the choice of the network for the virtual machine target, the task begins but does not immediately with the following error message: unknown error returned from agent vCenter Converter. This problem appears when you use the wizards to import or export or the convert Command Line Interface (CLI) tool to create the task.

  Solution: Select a network to the computer virtual target that is not a vNetwork Distributed Switch.

  We had this problem a few weeks back and see how this problem exists since last year, vCenter 4.0 Update 1 or 2 this address?  Thank you.

  Hi Terran0925,

  According to the "Known issues" section in the release notes for "VMware vCenter Converter vCenter Server 4.0 Update 1 | November 19, 2009 | Build 206170 "to http://www.vmware.com/support/vsphere4/doc/vsp_vcc_41u1_rel_notes.html#resolvedissues , the question was always present.

  There is no mention of the issue on the VMware vCenter Converter vCenter Server 4.1 release notes. The release notes can be found at http://www.vmware.com/support/vsphere4/doc/vsp_vcc_42_rel_notes.html

  The details of this version are;

  VMware vCenter Converter 4.2 | July 13, 2010 | Generation 254483

  vCenter Server 4.1 | July 13, 2010 | Build 258902

  Note: in order to get this version of VMware vCenter Converter vCenter Server, you must upgrade your vCenter server for "vCenter Server 4.1 | July 13, 2010 | Build 258902.

  I hope this helps.

  Kind regards

  Graham Daly

  Champion of knowledge

  VMware Inc.

• VXLAN on UCS: IGMP with Catalyst 3750, 5548 Nexus, Nexus 1000V

  Hello team,

  My lab consists of Catalyst 3750 with SVI acting as the router, 5548 Nexus in the vpc Setup, UCS in end-host Mode and Nexus 1000V with segmentation feature enabled (VXLAN).

  I have two different VLAN for VXLAN (140, 141) to demonstrate connectivity across the L3.

  VMKernel on VLAN 140 guests join the multicast fine group.

  Hosts with VMKernel on 141 VLAN do not join the multicast group.  Then, VMs on these hosts cannot virtual computers ping hosts on the local network VIRTUAL 140, and they can't even ping each other.

  I turned on debug ip igmp on the L3 Switch, and the result indicates a timeout when he is waiting for a report from 141 VLAN:

  15 Oct 08:57:34.201: IGMP (0): send requests General v2 on Vlan140

  15 Oct 08:57:34.201: IGMP (0): set the report interval to 3.6 seconds for 224.0.1.40 on Vlan140

  15 Oct 08:57:36.886: IGMP (0): receipt v2 report on 172.16.66.2 to 239.1.1.1 Vlan140

  15 Oct 08:57:36.886: IGMP (0): group record received for group 239.1.1.1, mode 2 from 172.16.66.2 to 0 sources

  15 Oct 08:57:36.886: IGMP (0): update EXCLUDE group 239.1.1.1 timer

  15 Oct 08:57:36.886: IGMP (0): add/update Vlan140 MRT for (*, 239.1.1.1) 0

  15 Oct 08:57:38.270: IGMP (0): send report v2 for 224.0.1.40 on Vlan140

  15 Oct 08:57:38.270: IGMP (0): receipt v2 report on Vlan140 of 172.16.66.1 for 224.0.1.40

  15 Oct 08:57:38.270: IGMP (0): group record received for group 224.0.1.40, mode 2 from 172.16.66.1 to 0 sources

  15 Oct 08:57:38.270: IGMP (0): update EXCLUDE timer group for 224.0.1.40

  15 Oct 08:57:38.270: IGMP (0): add/update Vlan140 MRT for (*, 224.0.1.40) by 0

  15 Oct 08:57:51.464: IGMP (0): send requests General v2 on Vlan141<----- it="" just="" hangs="" here="" until="" timeout="" and="" goes="" back="" to="">

  15 Oct 08:58:35.107: IGMP (0): send requests General v2 on Vlan140

  15 Oct 08:58:35.107: IGMP (0): set the report interval to 0.3 seconds for 224.0.1.40 on Vlan140

  15 Oct 08:58:35.686: IGMP (0): receipt v2 report on 172.16.66.2 to 239.1.1.1 Vlan140

  15 Oct 08:58:35.686: IGMP (0): group record received for group 239.1.1.1, mode 2 from 172.16.66.2 to 0 sources

  15 Oct 08:58:35.686: IGMP (0): update EXCLUDE group 239.1.1.1 timer

  15 Oct 08:58:35.686: IGMP (0): add/update Vlan140 MRT for (*, 239.1.1.1) 0

  If I do a show ip igmp interface, I get the report that there is no joins for vlan 141:

  Vlan140 is up, line protocol is up

  The Internet address is 172.16.66.1/26

  IGMP is enabled on the interface

  Current version of IGMP host is 2

  Current version of IGMP router is 2

  The IGMP query interval is 60 seconds

  Configured IGMP queries interval is 60 seconds

  IGMP querier timeout is 120 seconds

  Configured IGMP querier timeout is 120 seconds

  Query response time is 10 seconds max IGMP

  Number of queries last member is 2

  Last member query response interval is 1000 ms

  Access group incoming IGMP is not defined

  IGMP activity: 2 joints, 0 leaves

  Multicast routing is enabled on the interface

  Threshold multicast TTL is 0

  Multicast designated router (DR) is 172.16.66.1 (this system)

  IGMP querying router is 172.16.66.1 (this system)

  Multicast groups joined by this system (number of users):

  224.0.1.40 (1)

  Vlan141 is up, line protocol is up

  The Internet address is 172.16.66.65/26

  IGMP is enabled on the interface

  Current version of IGMP host is 2

  Current version of IGMP router is 2

  The IGMP query interval is 60 seconds

  Configured IGMP queries interval is 60 seconds

  IGMP querier timeout is 120 seconds

  Configured IGMP querier timeout is 120 seconds

  Query response time is 10 seconds max IGMP

  Number of queries last member is 2

  Last member query response interval is 1000 ms

  Access group incoming IGMP is not defined

  IGMP activity: 0 joins, 0 leaves

  Multicast routing is enabled on the interface

  Threshold multicast TTL is 0

  Multicast designated router (DR) is 172.16.66.65 (this system)

  IGMP querying router is 172.16.66.65 (this system)

  No group multicast joined by this system

  Is there a way to check why the hosts on 141 VLAN are joined not successfully?  port-profile on the 1000V configuration of vlan 140 and vlan 141 rising and vmkernel are identical, except for the different numbers vlan.

  Thank you

  Trevor

  Hi Trevor,

  Once the quick thing to check would be the config igmp for both VLAN.

  where did you configure the interrogator for the vlan 140 and 141?

  are there changes in transport VXLAN crossing routers? If so you would need routing multicast enabled.

  Thank you!

  . / Afonso

• Nexus 1000v, UCS, and Microsoft NETWORK load balancing

  Hi all

  I have a client that implements a new Exchange 2010 environment. They have an obligation to configure load balancing for Client Access servers. The environment consists of VMware vShpere running on top of Cisco UCS blades with the Nexus 1000v dvSwitch.

  Everything I've read so far indicates that I must do the following:

  1 configure MS in Multicast mode load balancing (by selecting the IGMP protocol option).

  2. create a static ARP entry for the address of virtual cluster on the router for the subnet of the server.

  3. (maybe) configure a static MAC table entry on the router for the subnet of the server.

  3. (maybe) to disable the IGMP snooping on the VLAN appropriate in the Nexus 1000v.

  My questions are:

  1. any person running successfully a similar configuration?

  2 are there missing steps in the list above, or I shouldn't do?

  3. If I am disabling the snooping IGMP on the Nexus 1000v should I also disable it on the fabric of UCS interconnections and router?

  Thanks a lot for your time,.

  Aaron

  Aaron,

  The steps above you are correct, you need steps 1-4 to operate correctly.  Normally people will create a VLAN separate to their interfaces NLB/subnet, to prevent floods mcast uncessisary frameworks within the network.

  To answer your questions

  (1) I saw multiple clients run this configuration

  (2) the steps you are correct

  (3) you can't toggle the on UCS IGMP snooping.  It is enabled by default and not a configurable option.  There is no need to change anything within the UCS regarding MS NLB with the above procedure.  FYI - the ability to disable/enable the snooping IGMP on UCS is scheduled for a next version 2.1.

  
  
  This is the correct method untill the time we have the option of configuring static multicast mac entries on
  
  the Nexus 1000v.  If this is a feature you'd like, please open a TAC case and request for bug CSCtb93725 to be linked to your SR.
  
  This will give more "push" to our develpment team to prioritize this request.
  Hopefully some other customers can share their experience.
  Regards,

  Robert

• Nexus 1000v and vMotion/VM traffic?

  Hello

  We are moving our servers of VM production to a new data center.

  There is a willingness to use the ports of 2 x 10 giga on each ESX host for the uplinks (etherchannel) Nexus 1000v for vMotion traffic and traffic VM.

  I don't know if that's even possible/supported? To devote nexus 1000v for vMotion and VM traffic ports at the same time? I think each guest will need an address unique IP for vMotion be able to operate.

  Best regards

  / Pete

  Info:

  vCenter/ESXi - 5.0 Update 3

  Yes - the characteristics of vmotion still apply if you use a virtual switch Standard or Distributed Virtual Switch as the Nexus 1000v - you should have a network for vmotion and each port vmkernel will need a unique IP address on the subnet of vmotion

• Nexus 1000v and vmkernel ports

  What is the best practice to put on the nexus 1000v vmkernel ports? Is it a good idea to put all the ports of vms and vmkernel on nexus 1000v? switch or dvs or some vmkernel as management ports must be on a standard?  If something happens to the 1000v, all management and vms will be unreachable.

  any tips?

  Yep, that's correct. Port system profiles don't require any communication between the MEC and VSM.

• How to check and confirm the Nexus 1000V secondary work if primary goes off

  Hello

  I installed Nexus 1000V Primarry and secondary on different ESXis

  but I have to turn off the primary, how to ensure that the school will be in charge and usually have any disconnection

  the module displays them and seem to be ok

  any other checks to do before continuing?

  Thank you

  Use "show system redundancy status. You can also manually failover

  http://www.Cisco.com/en/us/docs/switches/Datacenter/nexus1000/SW/4_2_1_s_v_1_4/high_availability/configuration/guide/n1000v_ha_3system.html

  The output from the example:

  n1000v# show system redundancy status
  

  Redundancy role
  ---------------
  administrative: primary
  operational: primary
  

  Redundancy mode
  ---------------
  administrative: HA
  operational: HA

  This supervisor (sup-1)
  -----------------------
  Redundancy state: Active
  Supervisor state: Active
  Internal state: Active with HA standby
  

  Another supervisor (sup-2)

  ------------------------
  Redundancy state: Standby
  Supervisor state: HA standby
  Internal state: HA standby
  

• Question about license for Nexus 1000v and it time to stand not licensed ESXi

  Hello

  I have the license for 12 cpu that are 3 popular ESXi with 4 processors each

  so if I add an another ESXi, which will support 60 days

  I'm pretty sure but wanted confirmation

  Thank you

  What version do you use? 2.1 they went to a model free and advanced, depending on the features you need, you can be able to upgrade and continue without additional licenses.

  No doubt, you can convert your current license VSG, contact your engineer.

  http://blogs.Cisco.com/tag/nexus-1000V/

• Nexus 1000v and vSwitch best practices

  I am working on the design of our vDS Nexus 1000v for use on HP BL490 G6 servers. 8 natachasery is allocated as follows:

  vmnic0, 1: management of ESXi, VSM-CTRL-PKT, VSM - MGT

  vmnic2, 3: vMotion

  vmnic4, 5: iSCSI, FT, Clustering heartbeats

  vmnic6, 7: data server and Client VM traffic

  Should I migrate all the natachasery to 1000v vDS, or should I let vmnic 0.1 on a regular vSwitch and others migrate to the vDS? If I migrate all the natachasery at the very least I would designate vmnic 0.1 as system so that traffic could elapse until the MSM could be reached. My inclination is to migrate all the natachasery, but I've seen elsewhere on comments in forums that the VSM associated networks and, possibly, the console ESX (i) are better let off of the vDS.

  Thoughts?

  Here is a best practice-how-to guide specific to 1000v & VC HP might be useful.

  See you soon,.

  Robert

• Replacement of failing on Nexus 1000v VEM

  I was curious how others accomplish the replacement of a failed ESXi host who is an on the Nexus 1000v VEM. I did this procedure once and it seemed endless. The goal is to make the swap of the transparent to the Nexus 1000v (VEM even #, just different VMware UUID)

  -Transition to the standard vSwitches home

  -Remove the switch distributed via vCenter host (host of right click and delete)

  -Swap physically on the chassis

  -Find the UUID for new host (got esxcfg-info)

  -Install new MEC in the 1000v with this UUID

  -Host of replacement over 1000v that assumes the number of Vincent who was installed just to migrate

  Ben,

  Note - 1000v in relationship issues are better posted in the «Server network» forum  This forum is specific to the UCS.

  https://supportforums.Cisco.com/community/NetPro/data-center/server-network?view=discussions

  The procedure that you use is the right.  Another method is to remove the host of 1000v with elegance, then issue a 'no vem X"that removes the MEC does record from the MSM.  Exchange your hosts, then add back to the 1000v.  Is there a reason that you need the same UUID?

  Kind regards

  Robert

• What does Nexus 1000v Version number Say

  Can any body provide long Nexus 1000v version number, for example 5.2 (1) SV3 (1.15)

  And what does SV mean in the version number.

  Thank you

  SV is the abbreviation of "Swiched VMware"

  See below for a detailed explanation:

  http://www.Cisco.com/c/en/us/about/Security-Center/iOS-NX-OS-reference-g...

  The Cisco NX - OS dialing software

  Software Cisco NX - OS is a data-center-class operating system that provides a high thanks to a modular design availability. The Cisco NX - OS software is software-based Cisco MDS 9000 SAN - OS and it supports the Cisco Nexus series switch Cisco MDS 9000 series multilayer. The Cisco NX - OS software contains a boot kick image and an image of the system, the two images contain an identifier of major version, minor version identifier and a maintenance release identifier, and they may also contain an identifier of reconstruction, which can also be referred to as a Patch to support. (See Figure 6).

  Software NX - OS Cisco Nexus 7000 Series and MDS 9000 series switches use the numbering scheme that is illustrated in Figure 6.

  Figure 6. Switches of the series Cisco IOS dial for Cisco Nexus 7000 and MDS 9000 NX - OS

  

  For the other members of the family, software Cisco NX - OS uses a combination of systems independent of the platform and is dependent on the platform as shown in Figure 6a.

  Figure 6 a. software Cisco IOS NX - OS numbering for the link between 4000 and 5000 Series and Nexus 1000 switches virtual

  

  The indicator of the platform is N for switches of the 5000 series Nexus, E for the switches of the series 4000 Nexus and S for the Nexus 1000 series switches. In addition, Nexus 1000 virtual switch uses a designation of two letters platform where the second letter indicates the hypervisor vendor that the virtual switch is compatible with, for example V for VMware. Features there are patches in the platform-independent code and features are present in the version of the platform-dependent Figure 6 a above, there is place of bugs in the version of the software Cisco NX - OS 4.0(1a) are present in the version 4.0(1a) N1(1a).

• The Nexus 1000V loop prevention

  Hello

  I wonder if there is a mechanism that I can use to secure a network against the loop of L2 packed the side of vserver in Vmware with Nexus 1000V environment.

  I know, Nexus 1000V can prevent against the loop on the external links, but there is no information, there are features that can prevent against the loop caused by the bridge set up on the side of the OS on VMware virtual server.

  Thank you in advance for an answer.

  Concerning

  Lukas

  Hi Lukas.

  To avoid loops, the N1KV does not pass traffic between physical network cards and also, he silently down traffic between vNIC is the bridge by operating system.

  http://www.Cisco.com/en/us/prod/collateral/switches/ps9441/ps9902/guide_c07-556626.html#wp9000156

  We must not explicit configuration on N1KV.

  Padma

• Cisco Nexus 1000V Virtual Switch Module investment series in the Cisco Unified Computing System

  Hi all
  I read an article by Cisco entitled "Best practices in Deploying Cisco Nexus 1000V Switches Cisco UCS B and C Series series Cisco UCS Manager servers" http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html

  A lot of excellent information, but the section that intrigues me, has to do with the implementation of module of the VSM in the UCS. The article lists 4 options in order of preference, but does not provide details or the reasons underlying the recommendations. The options are the following:

  ============================================================================================================================================================
  Option 1: VSM external to the Cisco Unified Computing System on the Cisco Nexus 1010

  In this scenario, the virtual environment management operations is accomplished in a method identical to existing environments not virtualized. With multiple instances on the Nexus 1010 VSM, multiple vCenter data centers can be supported.
  ============================================================================================================================================================

  Option 2: VSM outside the Cisco Unified Computing System on the Cisco Nexus 1000V series MEC

  This model allows to centralize the management of virtual infrastructure, and proved to be very stable...
  ============================================================================================================================================================

  Option 3: VSM Outside the Cisco Unified Computing System on the VMware vSwitch

  This model allows to isolate managed devices, and it migrates to the model of the device of the unit of Services virtual Cisco Nexus 1010. A possible concern here is the management and the operational model of the network between the MSM and VEM devices links.
  ============================================================================================================================================================

  Option 4: VSM Inside the Cisco Unified Computing System on the VMware vSwitch

  This model was also stable in test deployments. A possible concern here is the management and the operational model of the network links between the MSM and VEM devices and switching infrastructure have doubles in your Cisco Unified Computing System.
  ============================================================================================================================================================

  As a beginner for both 100V Nexus and UCS, I hope someone can help me understand the configuration of these options and equally important to provide a more detailed explanation of each of the options and the resoning behind preferences (pro advantages and disadvantages).

  Thank you
  Pradeep

  No, they are different products. vASA will be a virtual version of our ASA device.

  ASA is a complete recommended firewall.