我遇到了一个奇怪的Windows 2008R2集群相关的问题，困扰着我。 我觉得我已经接近了这个问题，但是还没有完全理解发生了什么。
我有两个2008R2服务器上运行的两节点交换2007群集。 在“主”群集节点上运行时，交换群集应用程序正常工作。 将群集资源故障转移到辅助节点时会发生此问题。
将群集故障转移到与“主”相同的子节点上的“辅助”节点时，故障转移最初工作正常，群集资源在新节点上继续工作几分钟。 这意味着接收节点确实发送了更新networking上arp表的免费ARP响应数据包。 但是在x时间之后（通常在5分钟之内），再次更新arp表，因为突然间群集服务不响应ping。
所以基本上，我开始ping到交换机群集地址，当它在“主节点”上运行。 它工作得很好。 我将集群资源组故障切换到“辅助节点”，并且只丢失了一个可接受的ping。 失败后，群集资源仍然会回答一段时间，突然间，ping开始超时。
这告诉我，arp表最初是由辅助节点更新的，但是之后有些东西（我还没有发现）会错误地更新它，可能是主节点的MAC。
为什么会发生这种情况 – 有没有人遇到同样的问题？
群集没有运行NLB，问题在故障转移回没有问题的主节点后立即停止。
每个节点正在使用网卡绑定（intel）和ALB。 就我而言，每个节点都在同一个子网上，并具有网关等等。
编辑：
我想知道它是否可能与networking绑定顺序有关？ 因为我注意到，从节点到节点的唯一区别就是在显示本地的arp表时。 在“主”节点上，arp表作为源在集群地址上生成。 而在其次要的，它从节点自己的网卡产生。
对此有何意见？
编辑：
好的，这里是连接布局。
集群地址：AB6.208 / 25交换申请地址：AB6.212 / 25
节点A：3个物理的nics。 两个使用Intere和地址AB6.210 / 25合作的群组称为public最后一个群集通信使用private 10.0.0.138/24
节点B：3个物理节点。 两个使用Intere和AB6.211 / 25组合在一起称为public最后一个用于集群通信的被称为private的10.0.0.139/24
每个节点都位于一个连接在一起的独立数据中心。 terminal交换机是DC1中的思科交换机，DC2中的NEXUS 5000/2000。
编辑：
我一直在testing多一点。 我现在在同一个集群上创build了一个空的应用程序，并且在交换应用程序的同一个子网上给它一个另外的ip地址。 失败这个空的应用程序结束后，我看到了完全相同的问题发生。 在一两分钟后，其他子网上的客户端无法ping应用程序的虚拟IP地址。 但是，当其他子网上的客户端不能使用同一个子网上的另一个群集的另一台服务器时，则无法ping通。 但是，如果我再做一个故障转移到原来的状态，那么情况是相反的。 所以，现在在同一子网上的客户端不能，而在另一个上他们可以。 我们有另外一个集群在相同的子网上设置，使用相同的intel网卡，相同的驱动程序和相同的分组设置。 在这里，我们没有看到这一点。 所以它有点混乱。
编辑：
好，做了一些更多的研究。 删除了辅助节点的网卡绑定，因为它无效。 在接下来的一些标准问题之后，我最终设法通过一个物理网卡上的旧网卡绑定设置重新运行。 现在我无法重现上述问题。 所以它与团队有某种关系 – 可能是某种错误？
编辑：
没有能够使它失败，一些更多的失败。 因此，删除NIC组看起来像是一种解决方法。 现在我试图重新build立与ALB的intel NIC（就像以前一样），我仍然不能让它失败。 这是令人讨厌的，因为现在我实际上不能确定问题的根源。 现在看起来似乎是某种MS / intel的hick-up，这很难接受，因为如果在14天内问题再次出现呢？ 有一件奇怪的事发生了。 在重新创buildNIC队伍之后，我无法将队伍重命名为旧队伍所称的“PUBLIC”。 所以有些东西还没有在Windows中清理 – 虽然服务器已经重新启动！
编辑：
好的，重buildALB后，错误又回来了。 所以我现在要做一些彻底的testing，我会回到我的观察。 有一件事情是肯定的。 它与Intel 82575EB NICS，ALB和Gratuitous Arp有关。
我很高兴听到这个:)我现在要通过密集testing找出是什么原因造成的。 希望能得到一些结果。 我还没有看到Broadcom的这些问题。
@Kyle Brandt：你在系统上看到了什么样的驱动程序版本？ 请提供网卡驱动程序版本和组合驱动程序版本。
我正在运行11.7.32.0和9.8.17。
我知道一个事实，这些驱动程序确实是非常老的 – 但由于这个问题只是周期性地发生，所以如果更新驱动程序正在解决问题，则很难排除故障。 截至目前我有FX试图使用此行动计划：1.删除ALB团队 – 无法挑起错误发生2.重buildALB团队 – 问题再次出现3.尝试AFT（适配器容错） – 问题再次出现4 。安装最新的驱动程序，并再次运行ALB团队（试用11.17.27.0） – 问题了5.卷动驱动器回来 – 这个行动现在正在等待 – 但直到现在，系统工作正常。
再次，我发现很难排除这个周期性的问题，因为我现在不知道上面哪个步骤解决了这个问题。 最有可能的是安装新的驱动程序后 – 但我现在不知道一个事实。
我希望你们中有些遇到同样问题的人可以添加一些笔记/观点/意见，以便我们能够根据这一点。
我已经开始看到机器为故障转移群集中的多个SQL Server实例获取不正确的ARP表条目。
客户端服务器可以使用正确的NIC组的MAC地址和另一个群集节点上的其中一个物理NIC（不一定是该服务器上相应的NIC组MAC）上的MAC地址填充其ARP表。
这导致与SQL群集在同一LAN上的客户端的间歇性连接失败。
VM客户端和物理盒都已经注意到这种行为。
这发生在故障转移之后并持续几天。
为了减轻这一点，我不得不在更麻烦的客户端上设置静态ARP条目。
环境：
英特尔网卡组创build一个具有其中一个物理网卡的MAC地址的虚拟适配器。
我有一个怀疑，英特尔网卡团队的软件是罪魁祸首，但任何其他疑难解答的想法或解决scheme，将不胜感激。
我很可能会用Server 2012重build集群主机，并使用内部网卡组合在一起（因为我没有看到与我的平台testing问题）。
您是否应用了最新的群集修补程序？ 有一些相当严重的已知缺陷。
瞬间通信失败导致Windows Server 2008 R2故障转移群集停止工作
https://support.microsoft.com/kb/2550886
如果群集与应用程序服务器之间不存在路由器，则执行慢故障转移操作
https://support.microsoft.com/kb/2582281
“出现此问题是因为应用程序服务器的TCP / IP堆栈错误地忽略免费地址parsing协议（ARP）请求。
这是纯粹的推测，但我的猜测是，可能会有一些不良的RLB被启用（默认情况下打开，并与Lazerpld，史蒂文，和堆栈交易都打这个bug现在）的交互。 从英特尔合作白皮书 ：
接收负载均衡（RLB）是ALB的一个子集。 它允许stream量在队伍中的所有适配器上同时stream入Tx和Rx。 在Windows中创buildRLB团队时，此function默认为开启。 可以使用团队的高级设置通过英特尔®PROSet GUI禁用它。
在RLB模式下，当客户端通过发送ARP请求消息尝试连接到组时，Intel ANS将响应来自TCP堆栈的服务器ARP应答消息的控制权。 然后，根据RLBalgorithm，Intel ANS将ARP响应复制到所select的服务组中的一个端口的MAC地址。 当客户端得到这个回复消息时，它包含了在本地ARP表中的团队IP和给定的MAC地址之间的匹配。 随后，来自此最终客户端的所有数据包将被选定的端口接收。 在这种模式下，Intel ANS分配团队成员以循环方式为最终客户端连接提供服务，因为客户端请求连接到服务器。 为了在团队中所有已启用的成员之间实现最终客户端的公平分配，RLB客户端表将以均等间隔刷新（默认为五分钟）。 这是接收平衡间隔，这是registry中的一个预configuration设置。 刷新包括根据需要为每个客户select新的团队成员。 Intel ANS使用新的MAC地址向受影响的客户端发起ARP回复连接，并在所有客户端都已经通过Intel ANS更新其ARP表后，完成接收通信量的重新分配。
操作系统可以随时发送ARP请求，而这些不在Intel ANS驱动程序的控制之下。 这些是通过主端口发出的广播包。 由于请求数据包是使用组的MAC地址（组中主要端口的MAC地址）传输的，因此与组连接的所有最终客户端都将通过将组的IP地址与主要港口。 发生这种情况时，这些客户端的接收负载折叠到主端口。
要重新启动Rx负载平衡，Intel ANS将向接收哈希表中的所有传输到非主端口的客户端发送免费ARP，以及各个团队成员的MAC地址。 另外，操作系统发送的ARP请求保存在RLB哈希表中，当接收到来自terminal客户端的ARP应答时，客户端的MAC地址在哈希表中更新。 这与服务器启动连接时启用RLB的机制相同。
所以我的理论是，也许当Windows群集释放虚拟IP，比英特尔驱动程序没有看到IP已经发布，并继续宣布它。 这就是说，现在这只是一个理论。
你使用哪些网卡？ Broadcom的机会（ 恐怖，恐怖 ）吗？
你有没有尝试更新他们的固件，驱动程序和团队软件？
根据我的经验，有bug的固件/驱动程序/组合可能会对Windows服务器造成严重破坏， 尤其是在涉及集群和/或Hyper-V时。
即时通信有一个类似的问题，与你们不同的是，同一子网上的服务器（随机）在任何给定时间停止ping我的SQL CLuster，而不切换/移动群集上的主动节点，即：节点A是活动的，节点B是备用数据库，突然我的应用程序服务器失去了与SQL Server的连接（节点A-活动）。 当我检查他们的ARP表时，我发现集群IP的入口填充了来自（节点B – 备用）的MAC地址。 不知何故（我仍然找不到原因）应用程序服务器更新了它的ARP表。 我已经用wireshark嗅探过，无法得到任何包含这个改变的ARP回复。
问候，
胜利者
我们已经看到了基本相同的行为，但在Linux下。 我们已经诊断了一点。
我们可以在一台服务器上从一个alb bond下拉一个VIF，并在另一个服务器上的另一个alb bond上带一个具有相同IP的VIF。 。 。 并且来自第一台服务器的从属接口继续为VIF的IP发送未经请求的ARP回复，导致客户端的ping在路由到第一台服务器时开始丢弃。 就好像一些代码 – 也许是负责RLB MAC伪装的代码 – 被困在一个循环中，没有得到有关VIF的备忘录。
编辑 ：为了强调，原始服务器的从属接口不是喷出免费ARP，而是主动提供给客户端的ARP回复。 最重要的是，如果你把一个新的客户端联机，它会发出一个ARP请求，第二个服务器会回复，一切都会好的。 但是，原来的客户端将无法与VIF IP上的第二台服务器进行通话，直到第一台服务器无法继续进行未经请求的ARP应答（例如，服务networking重新启动）为止。
我们所学到的：
只有英特尔网卡（e1000e驱动程序）的问题。 在各种内核上使用2.4.x以上的最新驱动程序进行转载。
只有alb债券的问题。
在RHEL5.3下容易复制，在RHEL5.5下难以复制，在RHEL5.8下似乎没有了 – 由于粘合模块在5.5和5.8之间变化不大，所以有点奇怪。 但是，鉴于上面的报告是针对Windows的，在网卡驱动程序/固件中出现错误的结论似乎是合理的。
我们还没有find根本原因，但可能只是停止使用这些NIC的模式6，或者完全停止使用这些NIC – 似乎是解决方法。 如果问题确实发生在新内核之后，我怀疑是否会有修复 – 可能是因为操作系统错误使NIC出现不良行为。