Hi Michael
1) version:
Nexus1000V# sh ver
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
Software
loader: version unavailable [last: image booted through mgmt0]
kickstart: version 4.0(4)SV1(3a)
system: version 4.0(4)SV1(3a)
kickstart image file is:
kickstart compile time: 7/25/2010 21:00:00
system image file is: bootflash:/nexus-1000v-mz.4.0.4.SV1.3a.bin
system compile time: 7/25/2010 21:00:00 [07/26/2010 10:44:30]
Hardware
Cisco Nexus 1000V Chassis ("Virtual Supervisor Module")
Intel(R) Xeon(R) CPU with 2075028 kB of memory.
Processor Board ID T5056A50004
Device name: Nexus1000V
bootflash: 2332296 kB
Kernel uptime is 13 day(s), 2 hour(s), 44 minute(s), 2 second(s)
plugin
Core Plugin, Ethernet Plugin
Nexus1000V#
2) this notes from technet might clarify how MS NLB works:
Network Load Balancing uses layer-two broadcast or multicast to simultaneously distribute incoming network traffic to all cluster hosts. In its defaultunicast mode of operation, Network Load Balancing reassigns the station address ("MAC" address) of the network adapter for which it is enabled (called the cluster adapter), and all cluster hosts are assigned the same MAC address. Incoming packets are thereby received by all cluster hosts and passed up to the Network Load Balancing driver for filtering. To insure uniqueness, the MAC address is derived from the cluster's primary IP address entered in the Network Load Balancing Properties dialog box. For a primary IP address of 1.2.3.4, the unicast MAC address is set to 02-BF-1-2-3-4. Network Load Balancing automatically modifies the cluster adapter's MAC address by setting a registry entry and then reloading the adapter's driver; the operating system does not have to be restarted.
If the cluster hosts are attached to a switch instead of a hub, the use of a common MAC address would create a conflict since layer-two switches expect to see unique source MAC addresses on all switch ports. To avoid this problem, Network Load Balancing uniquely modifies the source MAC address for outgoing packets; a cluster MAC address of 02-BF-1-2-3-4 is set to 02-h-1-2-3-4, where h is the host's priority within the cluster (set in the Network Load Balancing Properties dialog box). This technique prevents the switch from learning the cluster's actual MAC address, and as a result, incoming packets for the cluster are delivered to all switch ports. If the cluster hosts are connected directly to a hub instead of to a switch, Network Load Balancing's masking of the source MAC address in unicast mode can be disabled to avoid flooding upstream switches. This is accomplished by setting the Network Load Balancing registry parameter MaskSourceMAC to 0. The use of an upstream level three switch will also limit switch flooding.
Network Load Balancing's unicast mode has the side effect of disabling communication between cluster hosts using the cluster adapters. Since outgoing packets for another cluster host are sent to the same MAC address as the sender, these packets are looped back within the sender by the network stack and never reach the wire. This limitation can be avoided by adding a second network adapter card to each cluster host. In this configuration, Network Load Balancing is bound to the network adapter on the subnet that receives incoming client requests, and the other adapter is typically placed on a separate, local subnet for communication between cluster hosts and with back-end file and database servers. Network Load Balancing only uses the cluster adapter for its heartbeat and remote control traffic.
But in fact did the veth of the first vm "learn" the clusters actual MAC address - and I guess that this caused the traffic to be sent only to this VM.
3) We have a "funny" disconnect/reconnect when we try to run the cluster in multicast mode - I cannot find anything why my client is behaving like this but my guess is that we have multiple adapters in the server and hereby will the Session Directory re-assign the session to other ip-adress of the server - I have attached a screenshot of the login-sequence where you can see the disconnect & re-connect between packet 1094 & 1095 - the cluster ip is .31 and the other i/f is .150
But you see - we have now been re-configuring a few of the ESX hosts to run under VMWares native switch where we have - for the time - a single cluster with 4 vm's used by ~ 250 interactive RDP users on it - this runs fine - but we would prefer to move it to the Cisco 1000V if possibly. It would really be nice if you could show me the trick in how this should be set up. It doesn't look to me as if other have had much succes with NLB and Nexus 1k :-)
best regards /ti
