Windows Server 2008 R2网络适配器停止工作，需要重新启动

TL; DR版本：原来，这是Windows Server 2008 R2中的一个Broadcom网络深层错误。替换为英特尔硬件即可修复它。我们不再使用Broadcom硬件。曾经

我们一直在使用HAProxy和Linux-HA项目的心跳信号。我们正在使用两个Linux实例来提供故障转移。每个服务器都有自己的公共IP和一个IP，这两个IP使用虚拟接口（eth1：1）在IP：69.59.196.211之间共享。

虚拟接口（eth1：1）IP 69.59.196.211被配置为位于它们后面的Windows服务器的网关，我们使用ip_forwarding路由通信。

我们偶尔会在linux网关后面的其中一台Windows服务器上遇到网络中断的情况。HAProxy将检测到服务器处于脱机状态，我们可以通过将其远程处理到故障服务器并尝试对网关进行ping操作来进行验证：

使用32个字节的数据ping 69.59.196.211：
来自69.59.196.220的回复：无法访问目标主机。

arp -a在此失败的服务器上运行表明没有网关地址（69.59.196.211）的条目：

接口：69.59.196.220-0xa
互联网地址物理地址类型
69.59.196.161 00-26-88-63-c7-80动态
69.59.196.210 00-15-5d-0a-3e-0e动态
69.59.196.212 00-21-5e-4d-45-c9动态
69.59.196.213 00-15-5d-00-b2-0d动态
69.59.196.215 00-21-5e-4d-61-1a动态
69.59.196.217 00-21-5e-4d-2c-e8动态
69.59.196.219 00-21-5e-4d-38-e5动态
69.59.196.221 00-15-5d-00-b2-0d动态
69.59.196.222 00-15-5d-0a-3e-09动态
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静态
225.0.0.1 01-00-5e-00-00-01静态

在我们的Linux网关实例上arp -a显示：

eth1上<不完整>处的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上的00：21：5e：4d：61：1a [ether]上的peak-colo-196-215.peak.org（69.59.196.215）
eth1上的peak-colo-196-219.peak.org（69.59.196.219）在00：21：5e：4d：38：e5 [ether]
eth1上的peak-colo-196-222.peak.org（69.59.196.222）在00：15：5d：0a：3e：09 [ether]
eth1上的peak-colo-196-209.peak.org（69.59.196.209）在00：26：88：63：c7：80 [ether]
eth1上的peak-colo-196-217.peak.org（69.59.196.217）在00：21：5e：4d：2c：e8 [ether]

为什么arp有时会将此故障服务器的条目设置为<不完整>？ 我们应该静态定义arp条目吗？我一直将arp搁置一旁，因为它有99％的时间都可以工作，但是在这种情况下，它似乎失败了。我们还有其他疑难解答步骤可以帮助您解决此问题吗？

我们尝试过的事情

我添加了一个静态arp条目，用于在仍然没有帮助的Linux网关之一上进行测试。

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服务器可以暂时解决此问题，而无需对网络进行任何其他更改，但是我们的经验表明，此问题将再次出现。

交换网卡和交换机

我注意到发生故障的Windows服务器的交换机端口上的链接指示灯以100Mb的速度运行，而不是出现故障的接口上的1Gb。我将电缆移到了其他几个开放的端口，并且该链接为我尝试的每个端口指示100Mb。我也用相同的结果交换了电缆。我尝试更改Windows中网卡的属性，服务器被锁定，并且在单击“应用”后需要进行硬重置。该Windows Server具有两个物理网络接口，因此我已在两个接口上交换了电缆和网络设置，以查看问题是否出在该接口后面。如果公用接口再次出现故障，我们将知道这与网卡无关。

（我们也尝试过手头的另一个开关，没有任何变化）

更改网络硬件驱动程序版本

最新的Broadcom驱动程序以及Windows Server 2008 R2附带的内置驱动程序都存在相同的问题。

更换网线

作为最后的努力，我们记得发生的另一个变化是更换了服务器/交换机之间的所有跳线。我们已经购买了两组，一组用于专用接口的绿色（长度为1ft-3ft），另一组用于公共接口的红色电缆。我们换掉了其他品牌的所有公共接口跳线，并使我们的服务器运行了整整一周……aaaaa，然后问题再次出现。

禁用校验和卸载，删除TProxy

我们还尝试禁用驱动程序中的TCP / IP校验和卸载，请不要进行任何更改。现在，我们正在撤出TProxy，并转向更传统的x-forwarded-for网络安排，而无需重写任何精美的IP地址。我们将看看是否有帮助。

交换机虚拟化提供商

在某种程度上这与Hyper-V有关（我们确实在上面托管Linux VM），我们切换到了VMWare Server。没变。

切换主机型号

我们的疑难解答已经结束，现在正式涉及Microsoft支持。他们建议更改主机模型：

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/zh-cn/magazine/2007.09.cableguy.aspx

我们这样做了，并且还获得了一些未发布的内核修补程序，这些修补程序大概已包含在2008 R2 SP1中。没有修复。

更换网卡硬件

最终，用英特尔网络硬件代替Broadcom网络硬件为我们解决了此问题。因此，我倾向于认为Broadcom Windows Server 2008 R2驱动程序有问题！

http://blog.serverfault.com/post/broadcom-die-mutha/

从http://linux-ip.net/html/ether-arp.html：

如果请求的目标IP没有ARP缓存条目，则内核将生成mcast_solicit ARP请求，直到收到答案为止。在此发现期间，ARP缓存条目将以不完整状态列出。如果在指定数量的ARP请求后查找未成功，则ARP缓存条目将以失败状态列出。如果查找确实成功，则内核将响应输入ARP缓存，并重置确认和更新计时器。

看来您的网关箱没有响应（或响应速度太慢）您网关箱的ARP请求。这是否<incomplete>最终切换到<failed>？服务器和网关之间有哪些网络硬件？是否有可能在两台主机之间的某个地方过滤或阻止了广播ARP请求？

这意味着您对地址进行了ping操作，该IP具有PTR记录（因此为名称），但是相关机器没有任何响应。当我们看到此错误时，最常见的原因是子网掩码设置不正确-或在IP绑定到回送接口的IP意外绑定到eth接口的情况下。

196.220是什么？它与196.211有什么关系？我假设.220是HA代理主机之一。当在其上运行ifconfig -a和arp -a时，它显示什么？

正如Max Clark所说，<incomplete>只是意味着69.59.196.211已发出针对69.59.196.220的ARP请求，但尚未收到响应。（在Windows操作系统下，您会看到这是到“ 00-00-00-00-00-00-00”的ARP映射。。。顺便说一句，顺便说一句，在我看来，您没有看到这样的ARP映射69.59.196.211的69.59.196.220。）

我倾向于不喜欢使用静态ARP条目，因为根据我的经验，ARP通常一直在完成其工作。

如果是我，我会在“出现故障”的Windows计算机（69.59.196.220）上嗅探适当的以太网接口，以观察ARP是否为69.59.196.211，并观察它如何/是否响应来自69.59的ARP请求。 196.211。我还将考虑仅在ARP网关机器上进行嗅探（tcpdump -i interface-name arp），以从Linux机器的侧面查看ARP流量。

我从博客中知道您拥有一个后端网络和一个前端网络。在这些中断期间，“发生故障”的Windows服务器（69.59.196.220）与前端网络中的其他计算机进行通信是否有任何问题，还是与网关进行通讯时是否有问题？我很好奇，如果您在行动中遇到故障的机器时是通过前端或后端网络访问的。

您正在做什么以“解决”问题？

编辑：

我从您的更新中看到，您正在重新启动“失败”的Windows计算机以解决该问题。下次再进行此操作之前，是否可以验证Windows计算机是否完全可以在其前端接口上进行“对话”？另外，route print在发生故障时，也可以从Windows计算机（）获取路由表的副本。（基本上，我试图确定NIC /驱动程序是否正在Windows计算机上运行。）

本文档显示了不同的状态（表2.1）。不完整将意味着它已发送了第一个ARP请求（可能是在过时，延迟，探测之后），但尚未收到响应。

haproxy节点上的静态ARP无法提供帮助的原因是，您的Web服务器仍然无法弄清楚如何返回网关。

当haproxy节点之一发生故障时，Web服务器上的静态ARP会破坏您的Web服务器切换网关的能力-我猜测虚拟接口与haproxy节点的eth1共享相同的MAC地址，因此您必须努力编码到每个Web服务器的两个网关之一。

发生故障的Web服务器上是否安装了任何类型的安全软件？我在装有Symantec Endpoint Security的Windows 2008服务器上呆了一整夜-它在网络堆栈中安装了一些过滤代码，使该过滤器根本无法看到网关的ARP数据包。解决此问题（由Microsoft提供）的方法是删除加载DLL的注册表项。

另一时间发生此问题，从设备管理器中删除整个网络适配器并重新安装似乎有所帮助。

由于您已经静态设置了arp条目，因此服务器知道在哪里可以找到网关。但是，如果您的交换机不知道网关在哪里，它将不会转发您的数据包。

听起来您的HAproxy和Web服务器之间切换不好（或感到困惑）。重新启动它。

要么，要么您的HAproxy服务器在控制哪一台服务器上存在分歧，并且都回答了.211的arp查找。

同样，如果您的交换机过载，则HAproxies可能无法足够快地相互通信，并且会进行故障转移。

下一次出现此问题时，我建议在有问题的两个主机上运行一些数据包捕获，以确定每个主机正在观察的ARP流量。

您的HAproxy机器很可能安装了tcpdump。对于Windows计算机，您将需要WinPCAP应用程序（如Wireshark）或Microsoft网络监视器。

实际上，考虑一下问题，因为问题似乎专门针对ARP，因此您可能会连续地使用一个10MB的滚动捕获文件（连续记录下来）在HAproxy计算机和相关的Windows计算机上记录所有ARP流量。它应该足够大，以使到您检测到故障时，捕获文件仍将包含故障之前的ARP流量。（值得运行一个小时左右的捕获来进行实验，以查看捕获的数据量）。

Linux tcpdump的示例捕获语法（注意，我没有方便使用的Linux盒子来进行测试；请在生产环境中使用前测试-C和-W的行为！）：

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

希望这可以给您一些指示，确切说明失败了。当ARP条目过期时（根据本文，新版本的Windows似乎会非常积极地淘汰“不活动”的条目），我希望会发生以下情况：

1. 源主机将向目标主机发送ARP请求。ARP请求通常是广播的，但是在主机刷新现有条目的情况下，可以单播发送ARP。
2. 目标主机将以ARP答复进行响应。99％的时间将是单播，但是RFC允许广播响应。（有关更多详细信息，另请参阅关于IPv4地址冲突检测的RFC ）。

听起来很简单，但是还有很多其他因素可能会干扰此过程：

• 原始请求可能未到达目标。
• 该请求可能到达目标，但响应可能未到达源。
• 某种高可用性机制可能会干扰ARP的“正常”行为：
  • HAProxy节点之间的故障转移如何工作？它使用共享的MAC地址，还是使用免费的ARP使节点之间的IP地址失效？
  • 上面的ARP表中的许多MAC地址都是以00-15-5D开头的，显然已向Microsoft注册。您是否在有问题的Windows计算机上使用任何形式的群集或其他HA？在Windows服务器上执行“ ipconfig / all”操作时，这些00-15-5D MAC地址是否与硬件NIC关联的地址相同？

检查是否/何时再次发生的事情：

• 查看ARP流量的数据包捕获；对话的任何部分显然没有发生吗？
• 检查交换机的桥接/ CAM表；是否所有有问题的MAC地址都映射到您期望它们的端口？
• 子网上的其他主机是否对Windows和HAProxy主机的IP地址都具有有效的ARP条目？
• 多个不同源计算机上的相同目标IP的ARP条目是否解析为相同的MAC地址？例如，登录到子网上的其他几个主机，并验证196.211解析为两个主机上的相同MAC地址。

我们的一台2008 R2终端服务器也遇到了类似的问题，其中NIC上的所有流量都将停止但保持连接，并且NIC LED会显示通信。这是一个持续存在的问题，每周仍会出现2-3次，但只有在正常运行时间约12-13小时之后（每晚重新启动服务器）。

在尝试（出于好奇）终止NetbalancerService服务之后，我发现了Seriousbit Netbalancer是原因。然后，流量开始跨接口移动。此后，我已经卸载了Netbalancer。

华硕主板局域网存在相同的问题。通过安装Realtek网站上的最新驱动程序进行了修复