DHCP 客戶端認為什麼是“最佳”答案？
我們有培訓室，通常安裝 Windows XP（通過 PXE）。“正常”的 DNS/DHCP 基礎結構是 Windows 伺服器。培訓室有自己的 VLAN（與 Windows 伺服器不同），因此很可能有一個 IP 幫助程序用於在 Cisco 路由器上活動的 DHCP 請求，該房間的所有 PC 都連接到該路由器。
現在我們想將一些 PC 轉換為 Linux。想法是：將我們自己的帶有 DHCP 伺服器的筆記型電腦放入房間的 VLAN 中，並覆蓋“正常”的 DHCP 響應。這個想法應該可行，因為該 VLAN 中直接連接的 DHCP 伺服器的響應時間應該比位於遠離該 VLAN 一些躍點的“普通”DHCP 伺服器更快。
事實證明，這不起作用。我們必須手動釋放原始 DHCP 伺服器上的租約才能使其正常工作。
在筆記型電腦上，我們確實看到客戶端請求 IP 並且“我們的”dhcp 正在向 Windows IP 請求發送 NACK，在此之前我們確實提供了自己的響應。
老問題：為什麼這沒有按預期工作？是什麼讓 PC 重新獲得了舊租約？
2012 年 8 月 8 日更新：
重新獲得問題已在 DHCP-RFC 中進行了解釋。現在這就解釋了為什麼 PC 會重新獲得其舊租約。
現在我們在再次嘗試之前從 Windows-DHCP 伺服器釋放 IP。
再次 - Windows-DHCP 伺服器獲勝。
我懷疑 dhcp-client 有一些算法可以確定客戶端的“最佳”dhcp-answer。新問題是：
客戶如何選擇“最佳”答案？
它是供應商，甚至是特定於韌體的客戶端如何對多個 DHCP 響應做出反應。
這些年來我看到的變種是：
1）無論是ACK還是NACK，都接受第一個。
2）取第一個ACK，完全忽略NACK。
3）在設定的時間間隔（通常為5-10秒）內接收到最後一個ACK。
範例：幾年前，我們遇到了 Ricoh MFP 的問題。
我們有 2 台 DHCP 伺服器。一個提供地址，另一個僅提供附加的 DHCP 選項。第二個伺服器總是首先回答。
理光使用的變體 1) 即使第一個報價僅包含 DHCP 選項。在我們向他們解釋問題後，理光將其更改為變體 2) 並進行了韌體更新。