DHCP客户端认为什么是“最佳”答案？

我们的培训室通常安装Windows XP（通过PXE）。“常规” DNS / DHCP基础结构是Windows服务器。培训室拥有自己的VLAN（与Windows服务器不同），因此最可能有一个IP帮助程序，用于在该路由器上所有PC连接到的Cisco路由器上激活的DHCP请求。

现在，我们想将某些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服务器获胜。

我怀疑dhcp-client有某种算法，可以为客户端确定“最佳” dhcp-answer。新问题是：

客户如何选择“最佳”答案？

这是供应商，甚至是特定于固件的客户端如何响应多个DHCP答复。

这些年来我看到的变体是：

1）接受第一个，无论是ACK还是NACK。

2）取得第一个ACK，完全忽略NACK。

3）在设定的时间间隔（通常5-10秒）内获取最后收到的ACK。

示例：几年前，我们遇到了理光MFP的问题。
我们有2个DHCP服务器。一个提供了地址，另一个仅提供了其他DHCP选项。第二台服务器始终优先回答。
即使第一个报价仅包含DHCP选项，理光仍使用变体1）。我们向他们解释了问题之后，理光通过固件更新将其更改为版本2）。

假设路由器仍在充当DHCP中继并将请求转发到原始服务器，那么这样做的原因仅是因为Windows DHCP服务器告诉它继续使用IP。在这种情况下，来自新服务器的DHCPNACK是无关紧要的，因为DHCP客户端将考虑所有响应，并且由于它从Windows DHCP盒中获得了报价，因此非常乐意使用它。

PC：嗨，世界，我可以使用192.168.1.123吗？

New-DHCP：我说不。

旧的DHCP：我同意。

PC：有人说可以！亲爱的，我会用它！

如果没有其他帮助-RTFM（请阅读精美的手册）。在这种情况下，第一个是命中。

RFC 2131概述了DHCP操作。

1.6节指出DHCP 必须：

在服务器重新启动期间保留DHCP客户端配置，并且在可能的情况下，尽管重新启动了DHCP机制，仍应为DHCP客户端分配相同的配置参数，

现在有趣的问题是，如何在不了解其过去的客户上实现该设计目标。3.2节概述：

3.2客户端-服务器交互-重用先前分配的网络地址

如果客户端记住并希望重用先前分配的
网络地址，则客户端可以选择省略
上一节中描述的某些步骤。图4
中的时间线图显示了在典型的客户端-服务器交互中，客户端重新使用先前分配的网络地址的时序关系。

1. 客户端在其本地子网上广播DHCPREQUEST消息。该消息在“请求的IP地址”选项中包括客户端的网络地址。由于客户端尚未收到其网络地址，因此不得填写“ ciaddr”字段。BOOTP中继代理将消息传递给不在同一子网中的DHCP服务器。如果客户端使用“客户端标识符”获取其地址，则客户端必须在DHCPREQUEST消息中使用相同的“客户端标识符”。

2. 知道客户端配置参数的服务器将以DHCPACK消息响应客户端。服务器不应该检查客户端的网络地址是否已经被使用；客户端此时可以响应ICMP Echo Request消息。

因此，拥有活动租约的DHCP服务器会通过使用协议中的快捷方式获得优先权。

1. 客户端：DHCREQUEST（MAC地址，广播，将在本地广播域中传输-这里是本地VLAN，并通过IP帮助器传输到Windows-DHCP服务器）
2. 便携式DHCP服务器：DHCPOFFER
3. Windows-DHCP-Server：嘿-我已经知道你了-DHCPACK
4. 客户：哦-我收到了两个回复。一个已经认识我的人。酷，我会接受

从那时起，客户端将忽略Laptop-DHCP-Server。

因此，本例中的解决方案可能是（我将在实际测试时对其进行更新）：

1. 确保客户端关闭
2. 关闭笔记本电脑上的DHCP服务器，笔记本电脑上的假客户端MAC，DHCP请求
3. 发行IP
4. 重新获得原始IP和MAC，打开DHCP服务器
5. 打开客户端并执行PXE引导...

新问题可能在另一个问题中-问题的标题与大部分问题根本不符。

无论如何，关于客户端如何选择要提供的报价，在没有当前租约的情况下：取决于客户端，但是在我知道的每个DHCP客户端实现中，这都是一场简单的比赛。

RFC 2131涵盖了以下内容：

DHCP客户端可以自由使用任何策略来选择从中接收DHCPOFFER消息的DHCP服务器。

那里有一个IETF草案似乎已经死了，它会增加选择过程的可配置性，并且还提到了乏善可陈的客户端实现（十多年前，但变化不大）：

实际上，大多数供应商在这里对策略的实现都是非常基本的（例如，收到的第一个要约或收到的第一个可接受的要约），并且是“硬编码的”（即不可配置的）。

具有两个以不同配置向同一网络提供服务的DHCP服务器只会导致竞争，从可靠性或可预测性的角度来看这是不希望的。确实没有理由不能让您的单个DHCP服务器提供所需的内容。