背景
我有一台Windows DHCP服务器（Server 2008 R2）分发多个作用域的地址。这些范围之一是某些Mitel IP电话。电话配置为使用dhcp选项125获取配置信息。当电话启动时，它不知道要使用哪个VLAN，因此它仅获得其连接到的任何端口的默认（未标记）VLAN。dhcp服务器给它一个响应，其中包含选项125信息，并且电话能够从该响应中读取应使用的VLAN。然后，电话释放其原始地址，并使用正确的vlan标签请求新的dhcp租约。这些电话通常还具有连接到直通端口的计算机。来自计算机的数据包不会被标记，因此PC将保留在端口的原始（未标记）VLAN中。这为我们工作了多年。
问题与症状
最近几周的某个地方发生了某些变化，我不确定是什么。只要不重启电话，电话就可以继续工作，这意味着必须正确处理dhcp更新请求。连接到某些交换机的电话甚至可以在重启后幸存下来。但是，连接到其他交换机的电话在重启时将无法完成该过程。我们所有的电话都使用由UPS备份的PoE，因此距离任何电话都已经重启很久了。这意味着我不知道问题何时首次出现。我所知道的是，一部电话在昨天重启时发生了故障，今天在对其进行故障排除时，我们重置了该开关柜。现在，该交换机上的所有电话都无法正常工作（幸运的是，电话数量仍然很少）。我也知道1月底前一切正常，
当我看到电话启动时，可以看到它成功获取了第一个地址。然后，它成功读取选项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更新更改了该行为，但我看不到如何。或者核心交换机可能无法正确处理该REQUEST数据包，但我确定在那里没有任何更改，并且它也无法解释为什么仅某些端点交换机会受到影响。我该如何解决这个问题？
更新：
这是故障电话的dhcp日志摘录：
10,03 / 06 / 15,12：40：40，Assign，10.1.2.158，，08000F197844，，3189088995,0 ,,, 11,03 / 06 / 15,12：40：40，Renew，10.1.2.158， ，08000F197844，，3189088995,0 ,,, 12,03 / 06 / 15,12：40：41，发布，10.1.2.158，，08000F197844，，318,899,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的端口进行测试，但是如果在此期间其他人有更好的解释，我希望能听到。
这是开关配置的副本：