今天我们有一些机器停止上网。 经过大量的故障排除，共同的线索是他们所有的dhcp租约今天更新（我们在这里8天的租约）。
在续约之后，您所期望的一切都会变得很好：它们有一个有效的IP地址，DNS服务器和网关。 他们可以访问内部资源（文件共享，内联网，打印机等）。 多一点故障排除表明他们无法ping或tracert到我们的网关，但他们可以到达我们的核心layer3交换机就在网关前面。 将静态IP分配给机器是一个临时解决scheme。
最后的一个问题是，到目前为止，报告只是针对与网关相同的vlan上的客户端。 我们的pipe理人员和教职员工与服务器和打印机在同一个VLAN上，但是手机，钥匙链/摄像机，学生/无线networking和实验室都有自己的vlans，而且据我所知没有任何其他vlan已经有问题了。
我有一个单独的门票与网关供应商，但我怀疑他们会容易出来，告诉我的问题是在networking上的其他地方，所以我也在这里问。 我清除了网关和核心交换机上的ARPcaching。 任何想法欢迎。
更新：
我尝试了从网关ping回一些受影响的主机，奇怪的是我得到了一个响应：从一个完全不同的IP地址。 我尝试了几个随机，最终得到这个：
周五9月02 2011 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.35ms 来自10.1.1.97的64字节：icmp_seq = 1 ttl = 255时间= 39.9ms（DUP！）
10.1.1.97是ping的实际预期目标。 10.1.1.105应该是另一个build筑物的打印机。 之前我从来没有在ping响应中看到DUP。
我现在最好的猜测是一个stream氓无线路由器，在我们的一个10.1.1.0/24子网的宿舍里有一个坏的网关。
…继续。 我现在closures了有问题的打印机，并从网关Ping到受影响的主机只是完全失败。
更新2：
我在受影响的机器，网关，以及它们之间的每个交换机上检查ARP表。 在每个点上，这些设备的条目都是正确的。 我没有validation表中的每个条目，但是可能会影响主机和网关之间stream量的每个条目都可以。 ARP不是问题。
更新3：
目前情况正在发生变化，但是我看不出有什么办法来解决这些问题，所以我不知道这是否只是一个暂时的平静。 无论如何，我现在可以做很多诊断或排除故障，但如果再次发生故障，我会更新。
“我现在最好的猜测是在10.1.1.0/24子网的宿舍里有一台stream氓无线路由器。
这发生在我的办公室。 冒犯的设备竟然是一个stream氓安卓设备：
http://code.google.com/p/android/issues/detail?id=11236
如果android设备通过DHCP从另一个networking获取网关的IP，则它可能会join您的networking，并使用其MAC来响应网关IP的ARP请求。 您使用通用的10.1.1.0/24networking会增加此stream氓scheme的可能性。
我能够检查networking上受影响的工作站上的ARPcaching。 在那里，我观察到ARP通量问题，工作站将在正确的MAC和来自某些非法设备的MAC地址之间进行触发。 当我查看工作站对网关的可疑MAC时，它回来了一个三星的前缀。 有问题的工作站的精明用户回答说，他知道谁在我们的networking上有三星设备。 原来是首席执行官。
正如在评论部分已经讨论的那样，捕获数据包是非常关键的。 不过也有一个非常棒的工具叫做arpwatch：
（或http://sid.rstack.org/arp-sk/ for windows）
此工具将通过电子邮件发送给您，或者只是logging在networking上看到的所有新MAC地址以及给定子网（触发器）上IP地址的任何MAC地址更改。 对于这个问题，你可以通过报告触发器发生改变MAC的触发器来检测当前的理论，或者当第一次开始与主机通信时，你会看到一个新的MAC用于stream氓DHCP路由器。 这个工具的缺点是你需要把主机连接到你监控的所有networking上，但是它可以提供很好的信息来帮助诊断这些问题。
检测典型的非法DHCP服务器的一个快速方法是ping其服务的网关，然后在相应的ARP表中检查其MAC。 如果交换基础设施是托pipe的，那么MAC也可以被追踪到托pipe它的端口，并且该端口可以被closures或者追溯到违规设备的位置以进一步补救。
在支持DHCP Snooping的交换机上使用DHCP Snooping也是保护networking免受恶意DHCP服务器的有效select。