背景
我有一个 Windows DHCP 服务器（Server 2008 R2）为多个范围分发地址。其中一个范围适用于某些 Mitel IP 电话。电话被配置为使用 dhcp 选项 125 来获取配置信息。当电话启动时，它不知道要使用哪个 vlan，因此它只会获取它所连接的任何端口的默认（未标记）vlan。dhcp 服务器给它一个包含选项 125 信息的响应，并且电话能够从该响应中读取它应该使用的 vlan。然后电话会释放其原始地址并使用正确的 vlan 标签请求新的 dhcp 租约。电话通常还具有连接到直通端口的计算机。来自计算机的数据包永远不会被标记，因此 PC 将保留在端口的原始（未标记）vlan 上。这已经为我们工作了多年。
问题和症状
在过去几周的某个地方，发生了一些变化，我不确定是什么。只要电话不重新启动，它们就会继续工作，这意味着必须正确处理 dhcp 更新请求。连接到某些交换机的手机甚至可以在重启后存活下来。但是，连接到其他交换机的电话在重新启动时将无法完成该过程。我们所有的电话都使用由 UPS 支持的 PoE，所以很久没有重启了。这意味着我不知道问题何时首次出现。我所知道的是，昨天重启时一部手机出现故障，今天在对其进行故障排除时，我们重置了那个开关柜。现在，该交换机上的所有电话都无法正常工作（谢天谢地，它仍然是一个小数字）。我也知道一月底的时候一切都在运转，
当我看着手机启动时，我可以看到它成功地获得了第一个地址。然后它成功读取选项 125 信息，设置正确的 vlan 标签，并释放原始 IP 租约。它甚至能够接收和接受来自服务器的正确 vlan 的报价。然而，这就是事情停止的地方。电话在屏幕上显示“ DHCP: Offer 2 ACC”的消息，但 Windows DHCP 服务器没有记录租约，电话永远不会继续运行。我只能猜测 DHCP REQUEST 数据包永远不会到达 Windows 服务器，因此手机正在等待来自 Windows 的最终 ACK，它可以继续。
解决方法
我终于可以让电话再次工作了。为此，我必须先断开计算机。然后我将电话的交换机端口设置为在电话 vlan 上未标记，在 PC vlan 上没有成员资格。手机现在将正确重启。此时，我可以将交换机端口配置放回应有的位置，并且只要在我重置端口时没有人尝试拨打该号码，电话就不会错过任何一个节拍。然后我可以重新连接电脑。显然，这不是一个理想的过程，尽管由于手机很少重启，我将能够使用它让人们再次工作，直到找到根本原因。办公室现在本周关闭，因此这个问题实际上将被允许在周末进行（我没有电话所在的各个办公室的钥匙）。
我固定的这个电话是服务器机房的服务电话，直接连接到我们的核心交换机。问题可能是核心交换机上的路由或处理标签的问题，因此该解决方法在数据包首先通过（由其他交换机标记）的远程办公室无效，但我会感到非常惊讶如果发生这种情况，鉴于我知道它必须正确处理 dhcp 续订和实际电话对话。
一个转折是，将端口标记在 PC vlan 上意味着电话会失败并显示消息“ DHCP: Offer 1 ACC”。我需要完全删除该 vlan 才能成功。
注意：我现在已经确认该变通方法在偏远建筑物中是有效的。这让我怀疑我的设备没有分配到正确的 vlan。我在核心交换机上遇到了问题，而且它几乎同时在网络上的多个地方发生，这表明核心交换机可能是问题所在。由于没有什么特别的东西可看，我在本周末附近安排了一个维护窗口来重新启动交换机。我也可以更新固件。
环境
我们的核心交换机是 HP 5406zl。此交换机处理 VLAN 间路由。Windows DHCP 服务器直接连接到交换机。端点交换机通过光纤 SFP 连接到核心交换机，这些端口被标记为两端的所有 vlan。核心交换机为每个 vlan 配置一个ip helper-address指向我们的 DHCP 服务器的设置，以及一条dhcp relay-option 82 replace线，以便 dhcp 服务器知道要使用的范围。这些配置以及端点交换机上的端口配置至少在 16 个月内没有更改。在那段时间里，我们进行了其他开关和电话重置。
我们的大多数端点交换机都是 HP 2530 系列。这些开关似乎工作正常（今天 3 个不同 2530 上的电话已正确重启）。有问题的是较旧的交换机。我们有一台旧的 3Com 4200 和一台无法工作的 4210。前面提到的直接连接到核心交换机的服务电话也不起作用。
问题
在这一点上，我最好的猜测是 dhcp 服务器上的 Windows 更新改变了行为，但我不知道如何。或者可能核心交换机没有正确处理该请求数据包，但我确信那里没有任何改变，并且它没有解释为什么只有某些端点交换机受到影响。我该如何解决这个问题？
更新：
以下是故障电话的 dhcp 日志摘录：
10,03/06/15,12:40:40,分配,10.1.2.158,,08000F197844,,3189088995,0,,, 11,03/06/15,12:40:40,更新,10.1.2.158, ,08000F197844,,3189088995,0,,, 12,03/06/15,12:40:41,Release,10.1.2.158,,08000F197844,,3189088995,0,,, 15,03/06/15,12: 40:45,NACK,10.1.2.154,,08000F197844,,0,6,,, 15,03/06/15,12:40:45,NACK,10.1.2.154,,08000F197844,,0,6,,,
10.xxx 地址是 PC vlan（这个选择早于我在这个地方）。电话应该首先获得这种地址，所以这是意料之中的。但是，在发布消息之后，我还希望找到 192.168.16.x 范围内的地址的报价，因为我可以在电话上看到报价已被接受（除非我误解了“ACC”）。有趣的是，我从未见过服务器尝试发出这样的地址，即使电话认为它收到了地址。
我考虑过网络上有一个流氓 dhcp 服务器的想法（它在 Windows 服务器之前分发一个地址，但没有电话继续所需的 dhcp 选项），但这并不能解释为什么电话工作当且仅当我完全删除了任何通往 PC vlan 的路径。无论如何，我都会在早上通过将我的笔记本电脑连接到电话 vlan 的端口来测试它，但如果其他人同时有更好的解释，我很想听听。
这是交换机配置的副本：
我今天通过删除连接到我们的 dhcp 服务器的端口上的电话 vlan 的 vlan 标签解决了这个问题。这对我来说很奇怪，因为其他使用类似方案的系统（又名：使用 802.1q 的 Wifi SSID）需要标签或客户端无法获取地址。它奏效了，所以我不会太努力，但我有兴趣看到理论的答案，为什么会这样。
您应该考虑在有问题的交换机的任一侧运行数据包捕获，然后在 Wireshark 中查看。这将能够告诉您 1) 流量是否被流氓 DHCP 服务器拦截（基于 MAC 地址）和 2) 是否有东西被破坏或丢弃（例如，也许您需要 DHCP 中继）。这可能需要端口镜像，或者 3com 可能支持直接在交换机上捕获。
如果您发现此问题再次出现，您可能需要检查 DHCP 范围的大小以及正在使用的租约数量。如果旧的 DHCP 租约没有被破坏，您的服务器可能会认为池中没有地址，无法分配新地址。即使 vlan 中没有设备响应也是如此。如果您的 DHCP 范围为 7 天，则最多可能需要 7 天才能获得新的租约。同样，更改您的配置将解决问题，因为可能会抛出一个新的地址范围，或者它可能会根据配置更改刷新租约。如果是这种情况，我建议将租约生命周期设置为非常低的值，例如该范围的一个小时。