Windows Network Load Balancing on ESX Cluster with Dell PowerConnect stacks

We recently switched out our Cisco 6500 core switch for a pair of Dell PowerConnect 6248 stacks. Since then, our Network Load Balanced Sharepoint, which runs on two virtual machines on an ESX cluster has been behaving very poorly. The symptoms are that opening and saving documents stored in sharepoint takes a very very long time. There are no errors showing up on the Sharepoint servers or SQL server, just a lot of annoyed users. Initially I thought there was no way NLB could cause this, but as soon as we repointed the DNS records for our intranet to the ip address of one of the web front ends, the problems disappeared.

We suspect there is an issue related to multicast in the Dell configs - NLB is configured for multicast, but not IGMP.

Has anyone got a similar set up to us and fixed this sort of issue? Sharepoint on VMware ESX, with Dell PowerConnect switches.

From serverfault dunxd

• We have seen almost the same issue. We are using NLB with multicast (but not IGMP) to load balance 14 web servers across two ESX 4 servers plugged in a pair of stacked Dell PowerConnect6248. The nlb was working but the performance was terrible. We tried chnaging everying on nlb (unicast, multicast, igmp) and vmware switch (promicous, nitify switch, etc) and could not make it work. We added multicast MAC to dell bridge and arp tables all to no effect. We eventually solved it by turning routing off the vlan on the PowerConnect (i.e. using simple layer 2 VLAN) and using an external router to route traffic. Would love to know how to using the routing on Dell to make this work as it should be supported.

  joeqwerty : The problem, IMHO, is not the switch but the NLB. We had similar problems with our TS NLB. There was so much NLB heartbeat traffic that it was smothering the rest of the network. We solved it by using 2 NIC's on each TS (which is MS best practice BTW) and connecting the NLB bound NIC to an isolated layer 3 switch and routing traffic for the backend through the second NIC, which was connected to the production network.
  From Alec