背景
我有一台 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,分配,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,发布,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 设置的端口来测试它，但如果在此期间其他人有更好的解释，我很乐意听听。
这是交换机配置的副本：
答案1
今天，我通过删除连接到 dhcp 服务器的端口上的电话 VLAN 的 VLAN 标签解决了这个问题。对我来说，这很不寻常，因为使用类似方案的其他系统（又称：使用 802.1q 的 Wifi SSID）需要标签，否则客户端无法获取地址。它有效，所以我不会太费力地寻找，但我有兴趣看到有关为什么事实就是这样。
答案2
您应该考虑在有问题的交换机的任一侧运行数据包捕获，然后在 Wireshark 中查看。这将能够告诉您 1) 流量是否被恶意 DHCP 服务器拦截（基于 MAC 地址）和 2) 是否有东西被破坏或丢失（例如，您可能需要 DHCP 中继）。这可能需要端口镜像，或者 3com 可能支持直接在交换机上进行捕获。
答案3
如果您发现此问题再次出现，您可能需要检查 DHCP 范围的大小以及正在使用的租约数量。如果旧的 DHCP 租约没有被销毁，您的服务器可能会认为池中没有剩余地址，并且无法分配新地址。即使 VLAN 中没有响应的设备也是如此。如果您的 DHCP 范围是 7 天，则可能需要最多 7 天才能获得新租约。同样，更改配置可以解决此问题，因为可能会有一个新的地址范围被分配，或者它可能会根据配置更改刷新租约。如果是这种情况，我建议将租约有效期设置为非常低的值，例如该范围的租约有效期为一小时。您可以通过手动删除租约并查看如果问题再次出现，电话现在是否能够获取新地址来确认这一点。