DHCP客户认为什么是“最好”的答案？

它是供应商，甚至固件特定客户如何反应多个DHCP答案。

我多年来看到的变体是：

1）接受第一个，不pipe它是ACK还是NACK。

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

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

例如：几年前，我们遇到了理光MFP的问题。
我们有2个DHCP服务器。 一个提供地址，另外一个提供DHCP选项。 第二台服务器总是先回答。
理光使用的变体1）即使第一次提供只包含DHCP选项。 在我们向他们解释问题后，理光将其更改为变体2）。

假设路由器仍然充当DHCP中继并将请求转发到您的原始服务器，那么原因很简单，因为Windows DHCP服务器告诉它继续使用IP。 在这种情况下，来自新服务器的DHCPNACK是不相关的，因为DHCP客户端会考虑所有的响应，并且由于它从Windows DHCP框中获得了一个提议，所以它非常乐意使用它。

PC：呵呵嗨，我可以用192.168.1.123吗？

新的DHCP：我说不。

老DHCP：我说是的。

PC：有人说是的！ 甜，我会用它！

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

RFC 2131概述了DHCP操作。

1.6节指出，DHCP 必须 ：

保留DHCP服务器重新启动时的DHCP客户端configuration，并尽可能为DHCP客户端分配相同的configuration参数，尽pipe重新启动DHCP机制，

现在一个有趣的问题是，如何devise一个客户，不知道过去的目标是如何实现的。 第3.2节概述：

3.2客户端 – 服务器交互 – 重用以前分配的networking地址

如果客户记得并希望重新使用以前分配的
networking地址，客户可能会select省略一些步骤
在上一节中描述。 图4中的时间线图
显示客户机重新使用先前分配的networking地址的典型客户机 – 服务器交互中的时序关系。

1. 客户端在其本地子网上广播DHCPREQUEST消息。 该消息在“请求的IP地址”选项中包含客户端的networking地址。 由于客户端没有收到networking地址，所以不能填写'ciaddr'字段。 BOOTP中继代理将消息传递到不在同一子网上的DHCP服务器。 如果客户端使用“客户端标识符”来获取其地址，则客户端必须在DHCPREQUEST消息中使用相同的“客户端标识符”。

2. 知道客户端configuration参数的服务器向客户端回应一个DHCPACK消息。 服务器不应该检查客户端的networking地址是否已被使用; 此时客户端可能会响应ICMP回显请求消息。

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

1. 客户端：DHCREQUEST（MAC-Adress，广播，将在本地广播域中发送 – 在这里是本地VLAN，通过IP-helper到Windows-DHCP-server）
2. Laptop-DHCP-Server：DHCPOFFER
3. Windows-DHCP-Server：嗨 – 我已经知道你–DCPACK
4. 客户：哦，我有两个答复。 一个已经知道我。 酷，我会采取的

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

所以我们的解决scheme可能会（当我们实际testing时，我会更新它）：

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

这个新问题可能应该是一个不同的问题 – 问题的标题与问题的大部分内容完全不符。

在任何情况下，关于客户如何select提供哪种服务，在没有当前租约的情况下：由客户决定，但是在我知道的每个DHCP客户端实现中，这是一个简单的种族。

RFC 2131涵盖了这一点：

DHCP客户端可以自由使用任何策略来select客户端收到DHCPOFFER消息的DHCP服务器。

有一个IETF草案似乎已经死了，这将增加select过程的可configuration性，还提到了十多年前的平淡无奇的客户端实现，但没有太多改变：

在实践中，大多数供应商在这里实施政策是非常基本的（例如，收到的第一个报价或首先接受的报价）并且是“硬编码的”（即不可configuration的）。

有两台DHCP服务器向不同configuration的相同networking提供服务只会导致竞争，从可靠性或可预测性的angular度来看这是不可取的。 你真的没有理由不能让你的单一的DHCP服务器提供你所需要的。