今天，我们有许多机器无法访问互联网。经过大量故障排除后，发现一个共同点是，它们今天都续订了 dhcp 租约（我们这里的租约是 8 天）。
租约续签后，一切看起来都很好：它们有有效的 IP 地址、DNS 服务器和网关。它们可以访问内部资源（文件共享、内联网、打印机等）。进一步的故障排除表明它们无法 ping 或 tracert 到我们的网关，但它们可以到达网关前面的核心第 3 层交换机。为机器分配静态 IP 是一种临时解决方案。
最后一个问题是，到目前为止，只有与网关位于同一 VLAN 上的客户端才会收到报告。我们的行政人员和教职员工与服务器和打印机位于同一 VLAN，但电话、钥匙链/摄像头、学生/wifi 和实验室各自都有自己的 VLAN，而且据我所知，其他 VLAN 上还没有出现任何问题。
我与网关供应商单独开过一张票，但我怀疑他们会轻易地告诉我问题出在网络的其他地方，所以我也在这里问。我已经清除了网关和核心交换机上的 arp 缓存。欢迎提出任何想法。
更新：
我尝试从网关 ping 回一些受影响的主机，奇怪的是，我确实收到了响应：来自一个完全不同的 IP 地址。我随机尝试了几个，最终得到了这个：
2011 年 9 月 2 日星期五 13:08:51 GMT-0500（中部夏令时间） PING 10.1.1.97 (10.1.1.97) 56(84) 字节数据。 来自 10.1.1.105 的 64 字节：icmp_seq=1 ttl=255 时间=1.35 毫秒 来自 10.1.1.97 的 64 字节：icmp_seq=1 ttl=255 time=39.9 ms（DUP！）
10.1.1.97 是 ping 的实际目标。10.1.1.105 应该是另一栋楼里的打印机。我已经绝不之前在 ping 响应中看到过 DUP。
我目前最好的猜测是，我们的一个宿舍房间里的 10.1.1.0/24 子网上有一个恶意 wifi 路由器，其网关有问题。
...继续。我现在已经关闭了有问题的打印机，从网关到受影响主机的 ping 操作完全失败。
更新 2：
我检查了受影响的机器、网关以及它们之间的每个交换机上的 arp 表。在每个点上，这些设备的条目都是正确的。我没有验证表中的每个条目，但每个可能影响主机和网关之间流量的条目都没有问题。ARP 不是问题所在。
更新 3：
目前一切正常，但我看不出我做了什么来修复它们，所以我不知道这是否只是暂时的停滞。无论如何，我现在无法做太多诊断或故障排除，但如果它再次出现故障，我会更新更多。
答案1
“目前我最好的猜测是，我们宿舍里 10.1.1.0/24 子网上的某个房间里有一个恶意 wifi 路由器，其网关有问题。”
这事发生在我的办公室。肇事设备原来是一台恶意 Android 设备：
http://code.google.com/p/android/issues/detail?id=11236
如果 Android 设备通过 DHCP 从另一个网络获取网关的 IP，它可能会加入您的网络并开始使用其 MAC 响应网关 IP 的 ARP 请求。您使用通用 10.1.1.0/24 网络会增加这种恶意场景发生的可能性。
我能够检查网络上受影响工作站的 ARP 缓存。在那里，我发现了一个 ARP 流量问题，工作站会在正确的 MAC 地址和来自某个恶意设备的 MAC 地址之间来回切换。当我查找工作站网关的可疑 MAC 地址时，它返回的前缀是三星。有问题的工作站的精明用户回答说，他知道谁在我们的网络上有三星设备。原来是首席执行官。
答案2
正如评论部分所讨论的，获取数据包捕获确实至关重要。不过，还有一个非常棒的工具，叫做 arpwatch：
（或者http://sid.rstack.org/arp-sk/对于 Windows）
此工具会向您发送电子邮件或仅记录网络上看到的所有新 MAC 地址以及给定子网上 IP 的 MAC 地址的任何更改（触发器）。对于您遇到的这个问题，它会通过报告 IP 发生触发器来更改 MAC，或者当恶意 DHCP 路由器首次开始与主机通信时，您会看到新的 MAC，从而检测到当前的两种理论。此工具的一个缺点是您需要将主机连接到您监控的所有网络，但相对于它可以提供的帮助诊断此类问题的大量信息来说，这只是一个小小的代价。
答案3
检测典型恶意 DHCP 服务器的快速方法是 ping 其所服务的网关，然后在相应的 ARP 表中检查其 MAC。如果交换基础设施是托管的，那么还可以将 MAC 追踪到托管它的端口，并且可以关闭该端口或追溯到有问题的设备的位置以进行进一步的补救。
在支持 DHCP 监听的交换机上使用 DHCP 监听也是保护网络免受恶意 DHCP 服务器攻击的有效选择。