我们有培训室，通常安装 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-server 释放 IP。
再次 - Windows-DHCP-server 获胜。
我怀疑 dhcp-client 有一些算法可以确定客户端的“最佳”dhcp-answer。新问题是：
客户如何选择“最佳”答案？
假设路由器仍然充当 DHCP 中继并将请求转发到您的原始服务器，那么它这样做的原因仅仅是因为 Windows DHCP 服务器告诉它继续使用 IP。在这种情况下，来自新服务器的 DHCPNACK 是无关紧要的，因为 DHCP 客户端将考虑所有响应，并且由于它从 Windows DHCP 机器获得了一个提议，它非常乐意使用它。
它是供应商，甚至是特定于固件的客户端如何对多个 DHCP 应答做出反应。
我多年来看到的变体是：
1）接受第一个，不管它是ACK还是NACK。
2）取第一个ACK，完全忽略NACK。
3) 获取在设定时间间隔（通常为 5-10 秒）内收到的最后一个 ACK。
示例：几年前，我们遇到了 Ricoh MFP 的问题。
我们有 2 个 DHCP 服务器。一个提供地址，另一个仅提供额外的 DHCP 选项。第二台服务器总是先回答。
理光使用的变体 1) 即使第一个报价仅包含 DHCP 选项。在我们向理光解释了问题后，理光通过固件更新将其更改为变体 2)。
如果没有其他帮助 - RTFM（阅读精美的手册）。在这种情况下，第一个是命中。
RFC 2131概述了 DHCP 操作。
第 1.6 节指出 DHCP必须：
现在有趣的问题是，这个设计目标是如何在一个不了解其过去的客户身上实现的。第 3.2 节概述：
因此，持有活动租约的 DHCP 服务器通过使用协议中的快捷方式获得优先权。
从那时起，客户端将忽略 Laptop-DHCP-Server。
所以我们的解决方案可能是（我会在实际测试时更新）：
新问题可能应该在一个不同的问题中——问题的标题与问题的大部分内容完全不相符。
无论如何，关于客户端如何选择要使用的报价，在没有当前租约的情况下：这取决于客户端，但在我所知道的每个 DHCP 客户端实现中，这是一场简单的竞赛.
RFC 2131涵盖了这一点：
那里有一个IETF 草案，它似乎已经死了，它会增加选择过程的可配置性，并且还提到了乏善可陈的客户端实现（十多年前，但变化不大）：
让两个 DHCP 服务器向具有不同配置的同一网络提供服务只会导致竞争，从可靠性或可预测性的角度来看，这是不可取的。没有理由不能让您的单个 DHCP 服务器提供您需要的东西。