两个相同的负载服务于相同的网站往往放缓，并停止响应平。 缓慢（或间歇性）的ping会导致我们的负载均衡器认为服务器处于脱机状态并禁用它们。 有一个内容相同的第三台服务器没有问题，所以我相当有信心，这不是网站。
操作系统是Windows Server 2008.configuration有点特别：因为我们在直接服务器返回模式下使用梭子鱼networking负载均衡器，所以我们必须configuration许多环回适配器，这些环境适配器会像这里描述的那样“伪造”IP。 物理适配器已将转发设置为根据2008年的要求启用，以使环回适配器正常运行。
症状：
题：
这有什么可能的原因呢？ 我应该如何诊断？ 我没有排除任何事情。 开关configuration，域名/ DNS服务器，所有的想法都欢迎。
可悲的是，我对networkingpipe理的知识很less，所以我们也欢迎这样明显的答案。
编辑：
回答一些提出的问题。
我已经联系了梭子鱼，他们似乎认为这个问题与networking有关。 我想我在这一点上同意。
IP被分配给物理接口，不在服务器之间共享。 Ping是在同一个子网内完成的。
第三个盒子处理所有的网站负载时，其他两个下去，并没有太多的问题，但偶尔也有麻烦。 我还没有find一个模式。
今天晚上，我和另一位（更有经验的）networking人员坐下来查看一些域和服务器configuration。 他发现的一件事是域控制器上的一个不好的DNS设置。 他们configuration了外部DNS服务器作为替代，而不是其他DC。 我们将它们切换为互相引用dns，并将转发添加到dns服务。 我们还从所有的Web服务器中删除了外部的dns引用。
编辑2：
使用Wireshark，我可以在一个停机时间内检查ICMPstream量。 我开始这个testing，因为我无法从方框1到达方框2的共享文件夹。
testing：
所以不知怎的，两个盒子之间的stream量导致了盒子2在ICMP上一段时间。
我应该注意到，在这个testing中，方框1工作正常，但没有看到方框2的任何请求。在从方框2 ping Box 1时，方框2上的Wireshark显示消息“Destination unreachable（Communication administratively filtered）”from source IP我不认识。
你需要使用ICMP ping来进行服务器testing吗？ 大多数负载平衡器都支持HTTP请求，通常情况下这是个好主意，因为当网卡仍然运行时，Web服务器可能会closures。
我会先检查梭子鱼networking。 这可能是一个已知的问题。 我们遇到了一个类似的问题，原来是我们的思科负载平衡器。 固件更新解决了这个问题。
第三台服务器是否正在加载，还是以另一种方式与另外两台服务器是唯一的？
不知道更多，我build议让Wireshark到这些服务器，同时ping他们，看看ICMP的活动。 我的（可能是没有根据的）怀疑是这些服务器有ARP麻烦和发回应答包，你只是从来没有得到他们。
使用Wireshark，将你的filter设置为“arp或icmp”，看看它带来了什么。 您还应该快速查看一下系统事件日志 – 可能会有一些明显的内容，可以进一步快速猜测。
如果您不熟悉arp，则将第3层（IP）地址转换为第2层（MAC）地址的协议。 这必须正确发生，否则包含第3层数据包的第2层帧将永远不会被发送，或将到达错误的目的地。
最后，其他海报的双面/速度build议是坚实的最佳实践，但我怀疑它们是这里的根本原因。 请注意，在千兆以太网中，您不再需要担心自动协商吮吸。
编辑
您所做的DNS更改肯定是一个好主意，但是我很难想象会导致ICMP超时的场景。 可能是应用程序阻止了数以千计的DNS查询并耗尽其资源以至于无法响应ICMP？
无论如何，如果这不能解决问题，数据包跟踪应该显示更多的事情。
我发现的一件事情是帮助确保服务器上的NIC和它所连接的交换机上的端口都被设置为相同的速度和双工设置。 我遇到了“自动协商”不好的协商，开始在端口和网卡上引起很多错误。
尝试手动将接口设置为速度，并尽可能避免使用自动协商。
将服务器上的networking驱动程序更新为硬件供应商提供的最新版本。 我发现这有时修复了奇怪的networking问题。
pipe理过滤的源IP是什么？ 这很可能是问题的根源，我怀疑它是负载均衡器的内部