我们最近将一台Dell PowerConnect 6248堆栈换成了Cisco 6500核心交换机。 此后，在ESX群集上的两个虚拟机上运行的networking负载均衡Sharepointperformance得相当糟糕。 症状是打开和保存存储在SharePoint中的文档需要很长时间。 在Sharepoint服务器或SQL服务器上没有出现错误，只是很多恼人的用户。 最初我以为NLB没有办法解决这个问题，但是一旦我们把内部网的DNSlogging重新写到networking前端的IP地址上，问题就消失了。
我们怀疑Dellconfiguration中存在与组播相关的问题 – NLBconfiguration了多播，但不configurationIGMP。
有没有人有类似的设置，并解决这类问题？ VMware ESX上的Sharepoint，以及Dell PowerConnect交换机。
我们已经看到几乎相同的问题。 我们使用NLB与多播（但不是IGMP）通过插入一对堆叠的Dell PowerConnect6248中的两台ESX 4服务器来平衡14台Web服务器。 nlb正在工作，但performance糟透了。 我们尝试了nlb（单播，组播，igmp）和VMware交换机（promicous，nitify交换机等），并且无法使其工作。 我们添加了多播MAC到dell bridge和arp表，都不起作用。 我们最终通过closuresPowerConnect上的vlan的路由（即使用简单的第2层VLAN）并使用外部路由器来路由stream量来解决此问题。 想知道如何使用戴尔的路由，使其工作，因为它应该支持。
听起来很熟悉。 我有完全相同的问题。 交换和共享上的NLB在一组ESX虚拟机上，任何时候有到NLB的stream量，都会停下来。 我们与戴尔密切合作，问题是多播。 假设有一个关于这个的戴尔白皮书，说你必须使用单播而不是多播。
现在我们正在等待将NLB移到单播。 我们有30个这样的开关，现在都运行在3.2.0.7上。 v3固件是一个很大的改进，但要小心从v2升级，并确保您阅读他们的说明，这不是一个简单的安装和重新启动。 另外，有些东西以不同的方式configuration，例如DHCP中继。 它开始大规模打破了我们的NLB。
如果您不确定，请尝试pingpipe理界面（像PingPlotter一样的graphics），同时监视到NLB的stream量。 您将看到ping时间与stream量相关联。 我们从1ms跳到200ms以上，甚至丢包。 当交换机处理器正在处理组播时，pipe理接口locking，而不是在硬件中完成。
希望有帮助，当我们最终移动时，我会回来。
某些Dell交换机不支持多播NLB。 这就是为什么你有一个性能问题。 你也会看到过度的CPU使用率。 你可以在这个链接看到更多关于这个。
http://www.dell.com/us/business/p/powerconnect-6200-series/pd
pipe理networkingping丢失的另一个案例与固件版本有关。 新的固件解决了这个问题。 我build议你更新你的固件级别。