主页 / server / 问题 / 104791
In Process
Geoff Dalgas
Asked: 2010-01-21 13:50:32 +0800 CST

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

  • 772

TL；DR 版本：原来这是 Windows Server 2008 R2 中的一个深部 Broadcom 网络错误。更换英特尔硬件修复了它。我们不再使用 Broadcom 硬件。曾经。

我们一直在使用HAProxy以及来自 Linux-HA 项目的心跳。我们正在使用两个 linux 实例来提供故障转移。每台服务器都有自己的公共 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上显示：

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) 在 00:21:5e:4d:61:1a [ether] 在 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] 在 eth1

为什么 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 英尺长的绿色电缆，另一套用于公共接口的红色电缆。我们用不同的品牌换掉了所有公共接口跳线，并在整整一周内没有问题地运行我们的服务器...... aaaaa 然后问题再次出现。

禁用校验和卸载，删除 TProxy

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

交换机虚拟化提供商

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

切换主机型号

我们已经到了故障排除的尽头，现在正式涉及 Microsoft 支持。他们建议更改主机模型：

我们这样做了，而且我们还获得了一些未发布的内核修补程序，这些修补程序可能已被纳入 2008 R2 SP1。没有修复。

更换网卡硬件

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

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

networking windows-server-2008-r2 broadcom

9 个回答

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

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

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

    • 7

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

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

    • 5

  3. 正如 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) 以查看 ARP 流量从 Linux 机器一侧的样子。

    我从博客中知道，您有一个后端网络和一个前端网络。在这些中断期间，“失败”的 Windows 服务器 (69.59.196.220) 是否在与前端网络中的其他机器通信时遇到任何问题，或者只是在与网关通信时遇到问题？我很好奇，当您正在捕捉故障机器时，您是否会通过前端或后端网络访问故障机器。

    当问题发生时，您正在做什么来“解决”问题？

    编辑：

    我从您的更新中看到您正在重新启动“失败”的 Windows 机器来解决问题。在你下次这样做之前，你能否验证 Windows 机器是否能够在其前端界面上“对话”？route print此外，在故障期间也从 Windows 机器 ( ) 中获取路由表的副本。（基本上，我试图确定 NIC / 驱动程序在 Windows 机器上是否出现问题。）

    • 4

  4. 本文档显示了不同的状态（表 2.1）。不完整意味着它已经发送了第一个 ARP 请求（大概在陈旧、延迟、探测之后）但尚未收到响应。

    • 2

  5. haproxy 节点上的静态 ARP 不起作用的原因是您的 Web 服务器仍然无法弄清楚如何返回网关。

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

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

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

    • 2

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

    听起来您的 HAproxy 和 Web 服务器之间的切换很糟糕（或混淆）。重新启动它。

    要么是这样，要么你的 HAproxy 服务器不同意哪一个在控制中，并且两者都回答 .211 的 arp 查找。

    同样，如果您的交换机过载，您的 HAproxy 可能无法以足够快的速度相互通信，并且正在故障转移。

    • 2

  7. 下次出现此问题时，我建议在有问题的两台主机上运行一些数据包捕获，以确定它们各自观察到的 ARP 流量。

    您的 HAproxy 机器很可能安装了某种类型的tcpdump。对于 Windows 机器，您将需要WinPCAP应用程序，如Wireshark或Microsoft Network Monitor。

    事实上，考虑到这一点，由于问题似乎与 ARP 相关，您可能只是连续记录 HAproxy 机器和有问题的 Windows 机器上的所有 ARP 流量，滚动捕获文件（为了论证）10MB。这应该足够大，以便在您检测到故障时，捕获文件仍将包含故障前的 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？这些 00-15-5D MAC 地址是否与您在 Windows 服务器上执行“ipconfig /all”时看到的与硬件 NIC 相关联的地址相同？

    检查是否/何时再次发生这种情况：

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

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

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

    • 0

  9. 我对华硕主板局域网也有同样的问题。通过从realtek网站安装最新驱动程序已修复

    • 0

相关问题