☰

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

tag-icon • tag-icon networking windows-server-2008-r2 broadcom
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 字节数据对 69.59.196.211 进行 ping 操作：
来自 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显示：

peak-colo-196-220.peak.org (69.59.196.220) 位于 eth1 上的 <incomplete>
stackoverflow.com (69.59.196.212) 于 00:21:5e:4d:45:c9 [ether] 在 eth1 上
peak-colo-196-215.peak.org (69.59.196.215) 于 eth1 上的 00:21:5e:4d:61:1a [ether]
peak-colo-196-219.peak.org (69.59.196.219) 于 eth1 上的 00:21:5e:4d:38:e5 [ether]
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) 于 eth1 上的 00:26:88:63:c7:80 [ether]
peak-colo-196-217.peak.org (69.59.196.217) 于 eth1 上的 00:21:5e:4d:2c:e8 [ether]

为什么 arp 偶尔会将此故障服务器的条目设置为 <incomplete>？ 我们应该静态定义我们的 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 服务器有两个物理网络接口，因此我交换了两个接口上的电缆和网络设置，以查看问题是否出在接口上。如果公共接口再次关闭，我们就会知道这不是网卡的问题。

（我们还尝试了手头上的另一个开关，没有变化）

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

我们在使用最新的 Broadcom 驱动程序以及 Windows Server 2008 R2 附带的内置驱动程序时也遇到了同样的问题。

更换网线

作为最后的努力，我们想起发生的另一个变化是更换了我们服务器/交换机之间的所有跳线。我们购买了两套，一套长度为 1 英尺 - 3 英尺的绿色跳线用于专用接口，另一套红色跳线用于公共接口。我们用不同品牌的跳线替换了所有公共接口跳线，并让服务器运行了整整一周，没有出现问题……然后问题又出现了。

禁用校验和卸载，删除 TProxy

我们还尝试在驱动程序中禁用 TCP/IP 校验和卸载，但没有任何变化。我们现在正在撤出 TProxy，并转向更传统的x-forwarded-for网络安排，而无需任何花哨的 IP 地址重写。我们会看看这是否有帮助。

交换机虚拟化提供商

万一这与 Hyper-V 有某种关联（我们确实在其上托管 Linux VM），我们就切换到 VMWare Server。没有变化。

切换主机型号

我们已经到了故障排除的最后阶段，现在正式联系 Microsoft 支持。他们建议更改主机模型：

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

更换网卡硬件

最终，我们将 Broadcom 网络硬件替换为 Intel 网络硬件解决了这个问题。因此，我倾向于认为 Broadcom Windows Server 2008 R2 驱动程序存在问题！

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

答案1

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

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

看起来您的网关盒没有响应（或响应太慢）来自网关盒的 ARP 请求。<incomplete>最终会切换到吗<failed>？服务器和网关之间有什么网络硬件？广播 ARP 请求是否可能在两台主机之间的某处被过滤或阻止？

答案2

这意味着您已 ping 该地址，IP 具有 PTR 记录（因此得名），但相关机器没有响应。我们看到这种情况时，最常见的原因是子网掩码设置不正确 - 或者绑定到环回接口的 IP 意外地绑定到 eth 接口。

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

答案3

正如 Max Clark 所说，<incomplete> 仅表示 69.59.196.211 已向 69.59.196.220 发出 ARP 请求，但尚未收到响应。（在 Windows 中，您会看到这是到“00-00-00-00-00-00”的 ARP 映射……顺便说一句，我觉得很奇怪，您没有在 69.59.196.220 上看到 69.59.196.211 的这种 ARP 映射。）

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

如果是我，我会嗅探“故障”Windows 计算机 (69.59.196.220) 上的相应以太网接口，观察它对 69.59.196.211 的 ARP 操作，并观察它如何/是否响应来自 69.59.196.211 的 ARP 请求。我还考虑嗅探网关计算机上的 ARP（仅用于 ARP tcpdump -i interface-name arp），以查看 Linux 计算机端的 ARP 流量。

我知道，从博客，您有一个后端网络和一个前端网络。在这些中断期间，“故障”的 Windows 服务器 (69.59.196.220) 在与前端网络中的其他计算机通信时是否存在任何问题，或者它只是在与其网关通信时存在问题？我很好奇，当您在发生故障时，您是通过前端网络还是后端网络来访问它的。

当问题出现时，您会做什么来“解决”这个问题？

编辑：

我从您的更新中看到您正在重新启动“故障”的 Windows 计算机以解决问题。下次执行此操作之前，您能否验证 Windows 计算机是否能够在其前端接口上“通信”？此外，route print在发生故障时也从 Windows 计算机（）获取路由表的副本。（我基本上是在尝试确定 Windows 计算机上的 NIC/驱动程序是否出现故障。）

答案4

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

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

您在故障的 Web 服务器上安装了任何类型的安全软件吗？我花了一个晚上研究安装了 Symantec Endpoint Security 的 Windows 2008 服务器——它在网络堆栈中安装了一些过滤代码，使其根本无法看到网关的 ARP 数据包。修复方法（由 Microsoft 提供）是删除加载 DLL 的注册表项。

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

相关内容