Nexus 1000v, VMWare ESX and Microsoft SC VMM

Hi,
Im curious if anybody has worked up any solutions managing network infrastructure for VMWare ESX hosts/vms with the Nexus 1000v and Microsoft's System Center Virtual Machine Manager.
There currently exists support for the 1000v and ESX and SCVMM using the Cisco 1000v software for MS Hyper-V and SCVMM.   There is no suck support for VMWare ESX.
Im curious as to what others with VMWare, Nexus 1000v or equivalent and SCVMM have done to work around this issue.
Trying to get some ideas.
Thanks

Aaron,
The steps you have above are correct, you will need steps 1 - 4 to get it working correctly.  Normally people will create a separate VLAN for their NLB interfaces/subnet, to prevent uncessisary flooding of mcast frames within the network.
To answer your questions
1) I've seen multiple customer run this configuration
2) The steps you have are correct
3) You can't enable/disable IGMP snooping on UCS.  It's enabled by default and not a configurable option.  There's no need to change anything within UCS in regards to MS NLB with the procedure above.  FYI - the ability to disable/enable IGMP snooping on UCS is slated for an upcoming release 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

Similar Messages

  • Nexus 1000v UCS Manager and Cisco UCS M81KR

    Hello everyone
    I am confused about how works the integration between N1K and UCS Manager:
    First question:
    If two VMs on different ESXi and different VEM but in the same VLAN,would like to talk each other, the data flow between them is managed from the upstream switch( in this case UCS Fabric Inteconnect), isn'it?
    I created a Ethernet uplink port-profile on N1K in switch port mode access(100), I created a vEthernet port-profile for the VM in switchport mode access(100) as well. In the Fabric Interconnect I created a vNIC profile for the physical NICs of ESXi(where there are the VMs). Also I created the vlan 100(the same in N1K)
    Second question: With the configuration above, if I include in the vNIC profile the vlan 100 (not as native vlan) only, the two VMs can not ping each other. Instead if I include in the vNIC profile only the defaul vlan(I think it is the vlan 1) as native vlan evereything works fine. WHY????
    Third question: How it works the tagging vlan on Fabric interconnectr and also in N1K.
    I tried to read differnt documents, but I did not understand.
    Thanks                 

    This document may help...
    Best Practices in Deploying Cisco Nexus 1000V Series Switches on Cisco UCS B and C Series Cisco UCS Manager Servers
    http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html
    If two VMs on different ESXi and different VEM but in the same  VLAN,would like to talk each other, the data flow between them is  managed from the upstream switch( in this case UCS Fabric Inteconnect),  isn'it?
    -Yes.  Each ESX host with the VEM will have one or more dedicated NICs for the VEMs to communicate with the upstream network.  These would be your 'type ethernet' port-profiles.  The ustream network would need to bridge the vlan between the two physicall nics.
    Second question: With the configuration above, if I include in the vNIC  profile the vlan 100 (not as native vlan) only, the two VMs can not ping  each other. Instead if I include in the vNIC profile only the defaul  vlan(I think it is the vlan 1) as native vlan evereything works fine.  WHY????
    -  The N1K port profiles are switchport access making them untagged.  This would be the native vlan in ucs.  If there is no native vlan in the UCS configuration, we do not have the upstream networking bridging the vlan.
    Third question: How it works the tagging vlan on Fabric interconnectr and also in N1K.
    -  All ports on the UCS are effectively trunks and you can define what vlans are allowed on the trunk as well as what vlan is passed natively or untagged.  In N1K, you will want to leave your vEthernet port profiles as 'switchport mode access'.  For your Ethernet profiles, you will want them to be 'switchport mode trunk'.  Use an used used vlan as the native vlan.  All production vlans will be passed from N1K to UCS as tagged vlans.
    Thank You,
    Dan Laden
    PDI Helpdesk
    http://www.cisco.com/go/pdihelpdesk

  • VMware ESX and dual homing

    We are beginning to deploy VMware ESX servers for Windows production environments. How do I set up the VNICs to dual home the VM's to separate Catalyst 6500's.
    Thanks, Lisa

    Hi Steve,
    Specific to VSS by itself, that is available and shipping today, but support for the FWSM with VSS is not yet available (as you have already noted :-). I am currently hearing Q3CY08 as a possible timeframe for supporting VSS and the FWSM, but that is not written in stone. In the mean time, you could still take advantage of VSS to do the multi-chassis EtherChannel, just not with the FWSM included.
    Specific to the question on the quad mezz cards, I personally do not have any experience with this specific card, but do know that teaming/bonding software is getting better every day, but we all know that not everything works as advertised, so in that case (and actually, in every case if you think about it), any such design should be fully tested before going into production, to make sure it works as expected/desired.
    In your post you mention the 3020 (HP Cisco blade switch). That does indeed throw a bit of a wrench in the works, since as you noted, the NICs will each go to separate physical switches in the enclosure, thus making EtherChannel type solutions on the server impossible. In that case, I normally recommend a simple Active/Standby form of teaming/bonding, as it is robust and deterministic (proprietary forms of Active/Active, in my experience, are neither). If you did decide to go with pass-thru (instead of 3020) to a VSS environment, you could then take advantage of the EtherChannel type teaming, but then you introduce the headache of all of those cables from the pass-thru's, which defeats one of the more common purposes many people go to blades, reduced cabling.
    Another solution that would give you the best of both worlds in a blade enclosure (reduced cabling and EtherChannel teaming on the servers), is to look at the new 3120's just coming out. With their stacking ability, multiple switches look and act as a single logical switch (exactly like the 3750E), so when these are deployed in the enclosure and stacked, you can indeed use EtherChannel on the server NICs while still getting cable reduction for the enclosure.
    HTH, Matt

  • Vmware Tools for Nexus 1000v, VNMC and VSG

    Hi everyone, a customer is asking me about how to install the vmware tools in the virtual machines of N1Kv, VSG and VNMC.
    Someone knows the procedure, or if thats posiible or not.

    @Robert
    Wanted to know / understand what hardware version would be compatible for Nexus 1000V ? Is there any dependency for hardware version ?
    Regards,
    Amit Vyas

  • Firewall between Nexus 1000V VSM and vCenter

    Hi,
    Customer has multiple security zones in environment, and VMware vCenter is located in a Management Security Zone. VSMs in security zones have dedicated management interface facing Management Security Zone with firewall in between. What ports do we need to open for the communication between VSMs and vCenter? The Nexus 1000V troubleshooting guide only mentioned TCP/80 and TCP/443. Are these outbound from VSM to vCenter? Is there any requirements from vCenter to VSM? What's the best practice for VSM management interface configuration in multiple security zones environment? Thanks.

    Avi -
    You need the connection between vCenter and the VSM anytime you want to add or make any changes to the existing port-profiles.  This is how the port-profiles become available to the virtual machines that reside on your ESX hosts.
    One problem when the vCenter is down is what you pointed out - configuration changes cannot be pushed
    The VEM/VSM relationship is independent of the VSM/vCenter connection.  There are separate VLANs or L3 interfaces that are used to pass information and heartbeats between the VSM and its VEMs.
    Jen

  • Can a Nexus 1000v be configured to NOT do local switching in an ESX host?

    Before the big YES, use an external Nexus switch and use VN-Tag. The question is when there is a 3120 in a blade chassis that connects to the ESX hosts that have a 1000v installed on the ESX host. So, first hop outside the ESX host is not a Nexus box.
    Looking for if this is possible, if so how, and if not, where that might be documented. I have a client who's security policy prohibits switching (yes, even on the same VLAN) within a host (in this case blade server). Oh and there is an insistance to use 3120s inside the blade chassis.
    Has to be the strangest request I have had in a while.
    Any data would be GREATY appreciated!

    Thanks for the follow up.
    So by private VLANs, are you referring to "PVLAN":
    "PVLANs: PVLANs are a new feature available with the VMware vDS and the Cisco Nexus
    1000V Series. PVLANs provide a simple mechanism for isolating virtual machines in the
    same VLAN from each other. The VMware vDS implements PVLAN enforcement at the
    destination host. The Cisco Nexus 1000V Series supports a highly efficient enforcement
    mechanism that filters packets at the source rather than at the destination, helping ensure
    that no unwanted traffic traverses the physical network and so increasing the network
    bandwidth available to other virtual machines"

  • Nexus 1000v and vcenter domain admin account

    I changed out domain admin account on our domain in which vcenter services runs as and now its using a different services account. I am wondering if I need to update anything on the nexus 1000v switch side between the 1000v and venter

    Hi Dan,
    You are on the right track. However you can perform some of these function "online".
    First you want to ensure that you are running at a minimum, Nexus 1000v SV1(4a) as ESXi 5.0 only began support on this release. With SV1(4a), it provides support for both ESXi 5.0 and ESX/i 4.1.
    Then you can follow the procedure documented here:
    Upgrading from VMware Release 4.0/4.1 to VMware Release 5.0.0
    This document walks you through upgrading your ESX infrastructure to VMware Release 5.0.0 when Cisco Nexus 1000V is installed. It is required to be completed in the following order:
    1. Upgrade the VSMs and VEMs to Release 4.2(1)SV1(4a).
    2. Upgrade the VMware vCenter Server to VMware Release 5.0.0.
    3. Upgrade the VMware Update Manager to VMware Release 5.0.0.
    4. Upgrade your ESX hosts to VMware Release 5.0.0 with a custom ESXi image that includes the VEM bits.
    Upgrading the ESX/ESXi hosts consists of the following procedures:
    –Upgrading the vCenter Server
    –Upgrading the vCenter Update Manager
    –Augmenting the Customized ISO
    –Upgrading the ESXi Hosts
    There is also a 3 part video highlighting the procedure to perfrom the last two steps above (customized ISO and upgrading ESXi hosts)
    Video: Upgrading the VEM to VMware ESXi Release 5.0.0
    Hope that helps you with your upgrade.
    Thanks,
    Michael

  • Nexus 1000V. problem when working with the console VMWare

    I have a problem when working with the console VMWare.
    Sometimes it is impossible to connect any of the hypervisor to the guest OS managed by them.
    I get the message: "Unable connect to the MKS: Host address lookup for server <name of the hypervisor> failed: No such host is known."
    This message always appears in conjunction with the reconfiguration of virtual switch: "Reconfigure vNetwork Distributed Switch .... Initiated by Cisco_Nexus_1000V_ ....."
    Upon completion of the reconfiguration, Communication console, with guest OS is restored, or on its own or after a reboot srv-vc.
    In this time, I do not see any message in Nexus 1000v log.
    What is this?
    Thanks in advance.

    Smells of a DNS issue.  Are you sure your ESX hosts are reachable from your client via DNS hostname?  Try pinging them from a command prompt/terminal.  You may have DNS server issues.
    As a temp fix, edit your [windowspath]/system32/etc/drivers/hosts file and manually add the ESX host name and IP, then re-test.
    Regards,
    Robert

  • VWLC and Nexus-1000V

    Hi Experts!
    Does anybody try to install vWLC on ESX with Nexus-1000V as switch?
    All deployment guide are based on standard VMWare vSwitch and I can not find any information about questions:
    1. Is vWLC compatible with Nexus-1000V?
    2. What configuration should be done on Nexus-1000V to vWLC works properly?

    Hi Dave,
    You can access  below URL for nexus 1000v -4.0(4)SV1(3b) docs:
    http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_3_b/roadmap/guide/n1000v_roadmap.html
    And
    Nexus5000
    http://www.cisco.com/en/US/products/ps9670/tsd_products_support_series_home.html
    BR,
    John Meng

  • VSM and Cisco nexus 1000v

    Hi,
    We are planning to install Cisco Nexus 1000v in our environment. Before we want to install we want to explore little bit about Cisco Nexus 1000v
    •  I know there is 2 elements for Cisco 1k, VEM and VSM. Does VSM is required? Can we configure VEM individually?
    •   How does Nexus 1k integrated with vCenter. Can we do all Nexus 1000v configuration from vCenter without going to VEM or VSM?
    •   In term of alarming and reporting, does we need to get SNMP trap and get from individual VEM or can be use VSM to do that. OR can we   get    Cisco Nexus 1000v alarming and reporting form VMware vCenter.
    •  Apart from using Nexus 1010 can what’s the recommended hosting location for VSM, (same Host as VEM, different VM, and different physical server)
    Foyez Ahammed

    Hi Foyez,
    Here is a brief on the Nexus1000v and I'll answer some of your questions in that:
    The Nexus1000v is a Virtual Distributed Switch (software based) from Cisco which integrated with the vSphere environment to provide uniform networking across your vmware environment for the host as well as the VMs. There are two components to the N1K infrastructure 1) VSM 2) VEM.
    VSM - Virtual supervisor module is the one which controls the entire N1K setup and is from where the configuration is done for the VEM modules, interfaces, security, monitoring etc. VSM is the one which interacts with the VC.
    VEM - Virtual ethernet module are simply the module or virtual linecards which provide the connectivity option or virtual ports for the VMs and other virtaul interfaces. Each ESX host today can only have one VEM. These VEMs recieve their configuration / programing from the VSM.
    If you are aware of any other switching products from Cisco like the Cat 6k switches, the n1k behaves the same way but in a software / virtual environment. Where the VSM are equal of a SUPs and the VEM are similar to the line cards. The control and the packet VLANs in the n1k provide the same kind of AIPC and Inband connectivity as the 6k backplane would for the communication between the modules and the SUP (VSM in this case).
    *The n1k configuration is done only from the VSM and is visible in the VC.However the port-profiles created from the VSM are pushed from the VSM to the VC and have to be assigned to the virtual / physical ports from the VC.
    *You can run the VSM either on the Nexus1010 as a Virtual service blade (VSB) or as a normal VM on any of the ESX/ESXi server. The VSM and the VEM on the same server are fully supported.
    You can refer the following deployment guide for some more details: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/guide_c07-556626.html
    Hope this answers your queries!
    ./Abhinav

  • If we got Nexus 1000V from VMWARE , can we add the N1K to our CCO ( Cisco Account ) to have direct support from Cisco

    Hi
    If we got Nexus 1000V from VMWARE , can we add the N1K to our CCO ( Cisco Account ) to have direct support from Cisco
    as sometimes it take some more time to get answer from VMWARE -> Cisco
    Thanks

    No.  When you purchase support from Vmware, they are your support contact and they will escalate support to Cisco on your behalf if needed.  This is the case for all OEM support.  Cisco provides support for RHEL, Microsoft and VMware.  We follow the same practice. 
    Deciding who to purchase support from is a decision of single point of contact for all VMware & N1K related issues vs. maintaining separate support contracts with each vendor individually.
    Regards,
    Robert

  • Nexus 1000v: Control VLAN must be same VLAN as ESX hosts?

    Hello,
    I'm trying to install nexus 1000v and came across the below prerequisite.
    The below release notes for Nexus 1000v states
    VMware and Host Prerequisites
    The VSM VM control interface must be on the same Layer 2 VLAN as the ESX 4.0 host that it manages. If you configure Layer 3, then you do not have this restriction. In each case however, the two VSMs must run in the same IP subnet.
    What I'm trying to do is to create 2 VLANs - one for management and the other for control & Data (as per latest deployment guide, we can put control & data in the same vlan).
    However, I wanted to have all ESX host management same VLAN as the VSM management as well as the vCenter Management. Essentially, creating a management network.
    However, from the above "VMWare and Host Prerequisites", does this means I cannot do this?
    I need to have the ESX host management same VLAN as the control VLAN?
    This means that my ESX host will reside in a different VLAN than my management subnet?
    Thanks...

    Control vlan is a totally seperate VLAN then your System Console. The VLAN just needs to be available to the ESX host through the upstream physical switch and then make sure the VLAN is passed on the uplink port-profile that you assign the ESX host to.
    We only need an interface on the ESX host if you decide to use L3 control. In that instance you would create or use an existing VMK interface on the ESX host.

  • VM-FEX and Nexus 1000v relation

    Hi
    I am a new in virtulaization world and I need to know what is the relation between Cisco Nexus 1000v and Cisco VM-FEX?, and when to use VM-FEX and when to use Nexus 1000v.
    Regards

    Ahmed,
    Sorry for taking this long to get back to you.
    Nexus 1000v is a virtualized switch and as such will require that any traffic coming in or leaving the VM will first need to pass through the virtualization layer, therefore causing a minimum delay that for some applications (VMs) can be catastrophic enough that may mean too much delay.
    With VM-FEX you gain the option to bypass the virtualization layer with for example "Pass-Through" mode where the vmnics are really assigned and managed by the OS, minimizing the delay and making the VMs look as if they were directly attached, also, this offloads CPU workload in the mean time, optimizing the host/VM's performance.
    The need for one or the other will be defined as always by the needs your organization/business has.
    Benefits of VM-FEX (from cisco.com):
    Simplified operations: Eliminates the need for a separate, virtual networking infrastructure
    Improved network security: Contains VLAN proliferation
    Optimized network utilization: Reduces broadcast domains
    Enhanced application performance: Offloads virtual  machine switching from host CPU to parent switch application-specific  integrated circuits (ASICs)
    Benefits of Nexus 1000v here on another post from Rob Burns:
    https://supportforums.cisco.com/thread/2087541 
    https://communities.vmware.com/thread/316542?tstart=0
    I hope that helps 
    -Kenny

  • Port-security and Nexus 1000v

    Is there really any true need for port-security on Nexus 1000v for vethernet ports? Can a VM be assigned a previously used vethernet port that would trigger a port-security action?

    If you want to prevent admins or malicious users from being able change the mac address of a VM then port-security is a useful feature. Especially in VDI environments where users might have full admin control of the VM and can change the mac of the vnic.
    Now about veths ports. A veth gets assigned to a VM and stays with that VM. A veth is only released when either the nic on the VM is deleted or the nic is assigned to another port-profile on the N1KV or a port-group on a vSwitch or VMware DVS. Now when the veth is released it does not retain any of the piror information. It's freed up and added to a pool of available veths. When a veth is needed for a VM in either the same port-profile or a different port-profile the free veth will be grabbed and initialized. It does not retain any of the previous settings.
    So assigning a VM to a previsously used veth port should not trigger a violation. The MAC should get learned and traffic should be able to flow.

  • Nexus 1000V and strange ping behavior

    Hi ,
    I am using a Nexus 1000v a FI 6248 with a Nexus 5K in redundant architecture and I have a strange bevahior with VMs.
    I am using  port-profiles without any problems but in one case I have this issue
    I have 2 VMs assigned to the same port profile
    When the 2 Vms are on the same esx I can ping (from a VM)  the gateway and the other VM, now when I move one of the VM to an other ESX (same chassis or not).
    From both , I can ping the gateway, a remote IP but VMs are unreachable between them.
    and a remote PC are able to ping both Vms.
    I checked the mac table, from N5k it's Ok , from FI 6348 it's Ok , but from N1K I am unable to see the mac address of both VMs.
    Why I tried ( I performed at each step a clear mac table)
        Assign to an other vmnic , it works.
        On UCS I moved it to an other vmnic , it works
        On UCS I Changed the QOS policy , it works.
        I reassigned it , and I had the old behavior
        I checked all trunk links it's ok
    So i didn't understand why I have this strange behavior and how I can troubleshoot it deeper?
    I would like if possible to avoid to do that but the next step will be to create a new vmnic card and assign the same policy and after to suppress the vnmic and to recreate the old one.
    Regards

    From what you mentioned here's my thoughts.
    When the two VMs are on the same host, they can reach each other.  This is because they're locally switching in the VEM so this doesn't tell us much other than the VEM is working as expected.
    When you move one of the VMs to a different UCS ESX host, the path changes.    Let's assume you've moved one VM to a different host, within the UCS system.
    UCS-Blade1(Host-A) - VM1
    UCS-Blade2(Host-B) - VM2
    There are two paths option from VM1 -> VM2
    VM1 -> Blade1 Uplink -> Fabric Interconnect A -> Blade 2 Uplink -> VM2
    or
    VM1-> Blade1 Uplink -> Fabric Interconnect A -> Upstream Switch -> Fabric Interconnect B -> Blade 2 Uplink -> VM2
    For the two options I've seen many instances were the FIRST option works fine, but the second doesn't.  Why?  Well as you can see option 1 has a path from Host A to FI-A and back down to Host B.  In this path there's no northbound switching outside of UCS.  This would require both VMs to be be pinned to the Hosts Uplink going to the same Fabric Interconnect. 
    In the second option if the path involves going from Host-A up to FI-A, then northbound to the upstream switch, then back down eventually to FI-B  and then Host-B. When this path is taken, if the two VMs can't reach each other then you have some problem with your upstream switches.  If both VMs reside in the same subnet, it's a Layer2 problem.  If they're in different subnets, then it's a Layer 2 or 3 problem somewhere north of UCS.
    So knowing this - why did manual pinning on the N1K fix your problem?  What pinning does is forces a VM to a particular uplink.  What likely happened in your case is you pinned both VMs to Host Uplinks that both go to the same UCS Fabric Interconnect (avoiding having to be switched northbound).  Your original problem still exists, so you're not clear out of the woods yet.
    Ask yourself is - Why are just these two VMs affected.   Are they possibly the only VMs using a particular VLAN or subnet?
    An easy test to verify the pinning to to use the command below.  "x" is the module # for the host the VMs are running on.
    module vem x execute vemcmd show port-old
    I explain the command further in another post here -> https://supportforums.cisco.com/message/3717261#3717261.  In your case you'll be looking for the VM1 and VM2 LTL's and finding out which SubGroup ID they use, then which SG_ID belongs to whch VMNIC.
    I bet your find the manual pinning "that works" takes the path from each host to the same FI. If this is the case, look northbound for your L2 problem.
    Regards,
    Robert

Maybe you are looking for