TL; DR版本：原来这是Windows Server 2008 R2中一个深度的Broadcomnetworking错误。 用英特尔硬件代替它。 我们不再使用Broadcom硬件。 永远。
我们一直在使用HAProxy以及来自Linux-HA项目的心跳 。 我们使用两个linux实例来提供故障转移。 每台服务器都有自己的公用IP和一个IP，这两个IP使用虚拟接口（eth1：1）在IP：69.59.196.211
虚拟接口（eth1：1）IP 69.59.196.211被configuration为它们后面的windows服务器的网关，我们使用ip_forwarding来路由stream量。
在我们的linux网关后面的一台windows服务器上偶尔发生networking中断。 HAProxy将检测到服务器处于脱机状态，我们可以通过远程validation服务器来validation服务器并尝试ping网关：
用32字节数据Pinging 69.59.196.211： 来自69.59.196.220的回复：目标主机无法访问。
在此失败的服务器上运行arp -a显示网关地址 （69.59.196.211） 没有条目 ：
接口：69.59.196.220 --- 0xa Internet地址物理地址types 69.59.196.161 00-26-88-63-c7-80dynamic 69.59.196.210 00-15-5d-0a-3e-0edynamic 69.59.196.212 00-21-5e-4d-45-c9dynamic 69.59.196.213 00-15-5d-00-b2-0ddynamic 69.59.196.215 00-21-5e-4d-61-1adynamic 69.59.196.217 00-21-5e-4d-2c-e8dynamic 69.59.196.219 00-21-5e-4d-38-e5dynamic 69.59.196.221 00-15-5d-00-b2-0ddynamic 69.59.196.222 00-15-5d-0a-3e-09dynamic 69.59.196.223 ff-ff -ff -ff -ff -ff静态 静态224.0.0.22 01-00-5e-00-00-16 224.0.0.252 01-00-5e-00-00-fc static 225.0.0.1 01-00-5e-00-00-01静态
在我们的linux网关实例上， arp -a显示：
在eth1的<incomplete>上的peak-colo-196-220.peak.org（69.59.196.220） 在eth1上00：21：5e：4d：45：c9 [ether]上的stackoverflow.com（69.59.196.212） eth1上的peak-colo-196-215.peak.org（69.59.196.215）00：21：5e：4d：61：1a [ether] eth1上的00：21：5e：4d：38：e5 [ether]上的peak-colo-196-219.peak.org（69.59.196.219） eth1上的00：15：5d：0a：3e：09 [ether]上的peak-colo-196-222.peak.org（69.59.196.222） eth1上00：26：88：63：c7：80 [ether]上的peak-colo-196-209.peak.org（69.59.196.209） eth1上的00：21：5e：4d：2c：e8 [ether]上的peak-colo-196-217.peak.org（69.59.196.217）
为什么偶尔会把这个失败的服务器的条目设置为<incomplete>？ 我们应该静态定义我们的arp条目吗？ 我一直离开arp，因为99％的时间工作，但在这个例子中，它似乎失败了。 是否有任何其他疑难解答步骤可帮助解决此问题？
我们尝试过的东西
我添加了一个静态arp条目用于在其中一个linux网关上进行testing，但仍然没有帮助。
root@haproxy2:~# arp -a peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1 peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1 stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1 peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1 peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1 peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1 peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1 root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d root@haproxy2:~# ping 69.59.196.220 PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data. --- 69.59.196.220 ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 6006ms
重新启动Windows Web服务器暂时解决这个问题，没有其他的networking变化，但我们的经验表明，这个问题将回来。
交换网卡和交换机
我注意到交换机的端口上的链接指示灯，失败的Windows服务器运行在100Mb而不是失败的接口上的1Gb。 我把电缆移到了其他几个打开的端口上，而且我试过的每个端口的链路都显示为100Mb。 我也换了同样的结果。 我尝试更改在Windows中的网卡的属性，并将服务器locking，并单击应用后需要硬重置。 这个Windows服务器有两个物理networking接口，所以我换了两个接口上的电缆和networking设置，看看接口是否出现问题。 如果公共接口再次closures，我们将知道这不是网卡的问题。
（我们还尝试了另一个开关，我们手头没有变化）
更改networking硬件驱动程序版本
我们遇到了与最新的Broadcom驱动程序以及Windows Server 2008 R2中的内置驱动程序相同的问题。
更换networking电缆
作为最后的努力，我们还记得另外一个改变是我们的服务器/交换机之间的所有跳线replace。 我们已经购买了两套，一套绿色的长度为1ft – 3ft的专用接口，另一套红色电缆作为公共接口。 我们用不同的品牌replace了所有的公共接口跳线，然后在没有问题的情况下运行我们的服务器，等待整整一个星期… aaaaa然后问题重演。
禁用校验和卸载，删除TProxy
我们也尝试禁用驱动程序中的TCP / IP校验和卸载，没有改变。 我们现在正在拔出TProxy，并转移到一个更传统的x-forwarded-fornetworking安排，没有任何花哨的IP地址重写。 我们会看看是否有帮助。
切换虚拟化提供商
在某种程度上，这与Hyper-V有关（我们在其上托pipeLinux虚拟机），我们切换到了VMWare服务器。 不用找了。
切换主机模式
我们已经完成了故障排除工作，现在正式涉及到Microsoft的支持。 他们build议更改主机型号：
我们这样做了，而且我们还得到了一些未发布的内核修补程序，这些修补程序大概是2008 R2 SP1的版本。 没有修复。
更换网卡硬件
最终，用英特尔networking硬件取代Broadcomnetworking硬件为我们解决了这个问题。 所以我倾向于认为Broadcom Windows Server 2008 R2驱动程序是错误的！
http://blog.serverfault.com/post/broadcom-die-mutha/
从http://linux-ip.net/html/ether-arp.html ：
如果所请求的目标IP不存在ARP高速caching条目，则内核将生成mcast_solicit ARP请求，直到收到答复。 在此发现期间，ARPcaching条目将以不完整状态列出。 如果在指定数量的ARP请求之后查找失败，则ARPcaching条目将被列为失败状态。 如果查找成功，则内核将响应input到ARPcaching中，并重置确认和更新定时器。
它看起来像您的网关盒没有响应（或响应太慢）来自您的网关盒ARP请求。 这个<incomplete>是否最终会切换到<failed> ？ 服务器和网关之间有什么networking硬件？ 是否有可能在两台主机之间的某处广播ARP请求被过滤或阻塞？
这意味着你ping地址，IP有一个PTRlogging（因此名称），但没有任何回应有问题的机器。 当我们看到这种情况时，最常见的原因是子网掩码设置不正确，或者在IP被绑定到回路接口的情况下被意外绑定到eth接口。
什么是196.220？ 它与196.211有什么关系？ 我假设0.220是HA代理主机之一。 当你运行ifconfig -a＆arp -a时，它显示了什么？
正如Max Clark所说，<incomplete>仅仅意味着69.59.196.211已经发出了69.59.196.220的ARP请求，还没有收到响应。 （在Windows的土地上，你会看到这是一个ARP映射到“00-00-00-00-00-00”…我似乎很奇怪，顺便说一句，你没有看到这样的ARP映射69.59.196.220为69.59.196.211）。
我倾向于不喜欢使用静态ARP条目，因为根据我的经验，ARP一直在不断地完成它的工作。
如果是我，我会在“失败的”Windows计算机（69.59.196.220）上嗅探相应的以太网接口，观察其对69.59.196.211的ARP攻击，并观察它是如何/是否响应来自69.59的ARP请求。 196.211。 我也考虑在网关机器上只嗅探ARP（ tcpdump -i interface-name arp ），以查看Linux机器侧面的ARPstream量。
我从博客上知道，你有一个后端networking和一个前端networking。 在这些中断期间，“失败的”Windows服务器（69.59.196.220）在与前端networking中的其他计算机通信时是否存在问题，还是在与网关交谈时遇到问题？ 我很好奇，如果你正在通过前端或后端networking来到发生故障的机器，那么当你正在捕捉它的时候。
当发生问题时，你正在做什么来“解决”这个问题？
编辑：
我从你的更新中看到，你正在重启“失败”的Windows机器来解决这个问题。 在你下次做之前，你可以validationWindows机器能够在其前端接口上“交谈”吗？ 此外，在发生故障时，也可以从Windows机器（ route print ）中获取路由表的副本。 （我试图确定网卡/驱动程序是否正在Windows机器上奔波，基本上。）
这个文件显示了不同的状态（表2.1）。 不完整意味着它已经发送了第一个ARP请求（推测是在一个陈旧的延迟探测之后），但还没有收到响应。
haproxy节点上的静态ARP不起作用的原因是您的Web服务器仍然无法弄清楚如何返回到网关。
networking服务器上的静态ARP会破坏networking服务器在其中一个haproxy节点发生故障时切换网关的能力 – 我猜虚拟接口与haproxy节点的eth1共享相同的MAC地址，所以您必须努力代码到两个网关之一进入每个networking服务器。
你有没有安装在失败的Web服务器上的任何一种安全软件？ 我花了漫长的一晚在Windows 2008服务器上安装了Symantec Endpoint Security – 它在networking堆栈中安装了一些过滤代码，防止它看到网关的ARP数据包。 该修补程序（由Microsoft提供）是删除加载该DLL的registry项。
另一次发生这个问题，从设备pipe理器中删除整个networking适配器，并重新安装似乎有帮助。
由于您已经静态设置了arp条目，因此您的服务器知道在哪里查找网关。 但是，如果您的交换机不知道网关在哪里，它将不会转发您的数据包。
听起来好像你的HAproxy和你的Web服务器之间有一个不好的（或混淆的）切换。 重新启动它。
要么是这样，要么是你的HAproxy服务器不同意哪一个在控制中，而且两个都应答为.211的arp查找。
沿着同样的路线，如果你的交换机超负荷，你的HA代理可能无法与对方进行足够的通信，并且正在失败。
下一次发生这个问题时，我会build议在这两台主机上运行一些数据包捕获，以确定每个用户正在观察的ARPstream量。
你的HAproxy机器很可能会安装一些tcpdump 。 对于Windows机器，您将需要一个WinPCAP应用程序，如Wireshark或Microsoftnetworking监视器 。
事实上，考虑到这个问题，因为问题似乎与ARP有关，您可能会连续loggingHAproxy计算机和Windows计算机上的所有ARP通信，并带有一个滚动捕获文件（参数为10MB）。 这应该足够大，以便在检测到故障时，捕获文件仍将包含故障发生前的ARP通信。 （通过运行捕捉一个小时左右，看看它产生了多less数据是值得尝试的）。
Linux tcpdump的捕获语法的例子（注意，我没有一个Linux的方块来testing这个;请在生产中使用之前testing-C和-W的行为）：
tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp
这应该有希望给你一些指示什么是失败。 当一个ARP条目到期（根据这篇文章 ，更新版本的Windows似乎非常积极地老化“非活跃”条目），我期望以下事情发生：
听起来很简单，还有一些其他的东西可能会干扰这个过程：
事情要检查/如果再次发生这种情况：
我们与2008 R2terminal服务器之一有类似的问题，NIC上的所有stream量都会停止但保持连接状态，NIC LED将显示通讯。 这是一个持续不断的问题，每周保持2-3次，但是只有在12-13小时的正常运行时间（服务器每晚重新启动）之后。
我发现Seriousbit Netbalancer是原因，我试图（出于好奇）终止NetbalancerService服务。 stream量开始在界面上移动。 我已经卸载Netbalancer。
我和华硕主板LAN有同样的问题。 这是从realtek网站安装最新的驱动程序