Nil*_*ils 13 dhcp windows dhcp-server
我们有培训室，通常安装 Windows XP（通过 PXE）。“正常”的 DNS/DHCP 基础结构是 Windows 服务器。培训室有自己的 VLAN（与 Windows 服务器不同），因此最有可能在 Cisco 路由器上有一个用于 DHCP 请求的 IP 帮助程序，该房间的所有 PC 都连接到该路由器。
现在我们想将一些 PC 转换为 Linux。这个想法是：将我们自己的带有 DHCP 服务器的笔记本电脑放入房间的 VLAN 中，并覆盖“正常”的 DHCP 响应。这个想法应该可以工作，因为该 VLAN 中直接连接的 DHCP 服务器的响应时间应该比位于该 VLAN 一些跃点之外的“正常”DHCP 服务器的响应时间更快。
事实证明这是行不通的。我们必须手动释放原始 DHCP 服务器上的租约才能使其正常工作。
在笔记本电脑上，我们确实看到客户端请求 IP 并且“我们的”dhcp 正在向 Windows IP 请求发送 NACK，在此之前我们确实提供了我们自己的响应。
老问题：为什么这没有按预期进行？是什么让 PC 重新获得旧租约？
2012-08-08更新：
重新获得问题已在 DHCP-RFC 中进行了解释。现在这解释了为什么 PC 重新获得其旧租约。
现在，在再次尝试之前，我们确实从 Windows-DHCP 服务器中释放了 IP。
再次 - Windows-DHCP-server 获胜。
我怀疑 dhcp-client 有一些算法可以确定客户端的“最佳”dhcp-answer。新问题是：
客户如何选择“最佳”答案？
假设路由器仍然充当 DHCP 中继并将请求转发到您的原始服务器，那么它这样做的原因仅仅是因为 Windows DHCP 服务器告诉它继续使用 IP。在这种情况下，来自新服务器的 DHCPNACK 无关紧要，因为 DHCP 客户端将考虑所有响应，并且由于它从 Windows DHCP 框获得了报价，因此非常乐意使用它。
PC：哦，你好，我可以使用 192.168.1.123 吗？
New-DHCP：我说不。
Old-DHCP：我说是的。
PC：有人说是的！亲爱的，我会用的！
客户端对多个 DHCP 应答的反应方式取决于供应商，甚至固件。
我多年来见过的变体有：
1) 接受第一个，无论它是 ACK 还是 NACK。
2) 取第一个ACK，完全忽略NACK。
3) 在设定的时间间隔（通常5-10秒）内获取最后收到的ACK。
示例：几年前，我们的理光多功能一体机遇到了问题。
我们有 2 台 DHCP 服务器。一个提供地址，另一个仅提供额外的 DHCP 选项。第二个服务器总是先应答。
理光使用的变体 1) 即使第一个报价仅包含 DHCP 选项。在我们向他们解释问题后，理光通过固件更新将其更改为变体 2)。