DHCPクライアントは何を「最良の」答えと見なしますか？
通常はWindows XPがインストールされている（PXE経由））トレーニングルームがあります。「通常の」DNS/DHCPインフラストラクチャはWindows-Serverです。トレーニングルームには独自のVLAN（Windowsサーバーとは異なります）。したがって、その部屋のすべてのPCが接続されているCiscoルーターでアクティブなDHCP要求のIPヘルパーが最も適切に存在します。
ここで、代わりに一部のPCをLinuxに変換したいと思いました。アイデアは次のとおりでした：DHCPサーバーを備えた独自のラップトップを部屋のVLANその点で、VLANは、そのVLANからホップ離れた場所にある「通常の」DHCPサーバーよりも応答時間が速いはずです。
これは機能しないことが判明しました。元のDHCPサーバーを機能させるには、リースを手動で解放する必要がありました。
ラップトップでは、クライアントがIPを要求し、「私たちの」dhcpがWindows IP要求にNACKを送信しているのを確認しました。その前に、独自の応答を提供しました。
古い質問：なぜこれが期待どおりに機能しなかったのですか？ PCが古いリースを取り戻す理由は何ですか？
更新 2012-08-08：
回復の問題は、DHCP-RFCで説明されています。これで、PCが古いリースを取り戻す理由が説明されます。
ここで、もう一度試す前に、Windows-DHCPサーバーからIPを解放します。
繰り返しますが、Windows-DHCPサーバーが優先されます。
クライアントにとって「最良の」dhcp-answerを決定するdhcp-clientのアルゴリズムがあるのではないかと思います。新しい質問は次のとおりです。
クライアントはどのようにして「最良の」答えを選択しますか？
これはベンダーであり、クライアントが複数のDHCP応答にどのように反応するかはファームウェア固有です。
私が何年にもわたって見た変種は次のとおりです。
1）ACKかNACKかに関係なく、最初のものを受け入れます。
2）最初のACKを取得し、NACKを完全に無視します。
3）設定された時間間隔（通常は5〜10秒）内に受信した最後のACKを取得します。
例：数年前、リコーのMFPで問題が発生しました。
2台のDHCPサーバーがありました。 1つはアドレスを提供し、もう1つは追加のDHCPオプションのみを提供しました。 2番目のサーバーは常に最初に応答しました。
リコーが使用したバリアント1）最初のオファーにDHCPオプションしか含まれていなかったとしても。リコーは、問題を説明した後、ファームウェアをアップデートしてバリアント2）に変更しました。
ルーターが引き続きDHCPリレーとして機能し、要求を元のサーバーに転送していると仮定すると、その理由は、WindowsDHCPサーバーが先に進んでIPを使用するように指示したためです。この場合、新しいサーバーからのDHCPNACKは関係ありません。これは、DHCPクライアントがすべての応答を考慮するためであり、Windows DHCPボックスからオファーを受け取ったため、完全に使用できます。
PC：Hoh Hi World、192.168.1.123を使用できますか？
New-DHCP：いいえと言います。
Old-DHCP：はいと言います。
PC：誰かがそう言った！甘い、使ってみます！
新しい質問はおそらく別の質問に含まれているはずです。質問のタイトルは、質問の本文の大部分にまったく適合していません。
いずれにせよ、クライアントがどのオファーを選択するかに関しては、現在のリースがない場合：それはクライアント次第ですが、私が知っているすべてのDHCPクライアントの実装では、それは単純な競争です。
RFC 2131 これをカバーしています：
DHCPクライアントは、クライアントがDHCPOFFERメッセージを受信するサーバーの中からDHCPサーバーを選択する際に任意の戦略を自由に使用できます。
IETFドラフト があり、選択プロセスに構成可能性を追加したと思われる死んでいるように見えます。また、クライアントの実装が不十分であることに言及しています（10年以上前ですが、あまり変更されていません）。
実際には、ここでのほとんどのベンダーのポリシーの実装は非常に基本的であり（たとえば、最初に受け取ったオファーまたは最初に受け入れ可能なオファーを受け取った）、「ハードコーディング」されています（つまり、構成できません）。
異なる構成で同じネットワークにサービスを提供する2つのDHCPサーバーがあると、競合が発生するだけであり、信頼性や予測可能性の観点からは望ましくありません。単一のDHCPサーバーで必要なものを提供できない理由は実際にはありません。
他に何も役に立たない場合-RTFM（細かいマニュアルを読んでください）。この場合、最初のものがヒットしました。
RFC 2131 DHCP操作の概要。
セクション1.6は、DHCPmust：
サーバーの再起動後もDHCPクライアント構成を保持し、可能な場合は常に、DHCPメカニズムの再起動にもかかわらず、DHCPクライアントに同じ構成パラメーターを割り当てる必要があります。
ここで興味深い質問は、過去の知識がないクライアントでその設計目標がどのように達成されているかということです。セクション3.2の概要：
3.2クライアント/サーバーの相互作用-以前に割り当てられたネットワークアドレスを再利用する
クライアントが以前に割り当てられたものを覚えていて再利用したい場合
ネットワークアドレス、クライアントはいくつかの手順を省略することを選択できます
前のセクションで説明しました。図4のタイムライン図
は、以前に割り当てられたネットワークアドレスを再利用するクライアントの一般的なクライアントサーバーインタラクションのタイミング関係を示しています。
クライアントは、ローカルサブネットでDHCPREQUESTメッセージをブロードキャストします。メッセージには、「要求されたIPアドレス」オプションにクライアントのネットワークアドレスが含まれています。クライアントはネットワークアドレスを受け取っていないため、「ciaddr」フィールドに入力してはなりません（MUSTNOT）。 BOOTPリレーエージェントは、同じサブネット上にないDHCPサーバーにメッセージを渡します。クライアントが「クライアント識別子」を使用してアドレスを取得した場合、クライアントはDHCPREQUESTメッセージで同じ「クライアント識別子」を使用する必要があります。
クライアントの構成パラメーターを知っているサーバーは、DHCPACKメッセージでクライアントに応答します。サーバーは、クライアントのネットワークアドレスがすでに使用されていることを確認するべきではありません。クライアントは、この時点でICMPエコー要求メッセージに応答する可能性があります。
したがって、アクティブなリースを保持しているDHCPサーバーは、プロトコルのショートカットを使用することで優先されます。
- クライアント：DHCREQUEST（MACアドレス、ブロードキャスト、ローカルブロードキャストドメインで送信されます-ここではローカルVLANおよびIPヘルパーを介してWindows-DHCPサーバーに）
- ラップトップ-DHCPサーバー：DHCPOFFER
- Windows-DHCP-Server：ねえ-私はすでにあなたを知っています-DHCPACK
- クライアント：ああ-私は2つの応答を得ました。すでに私を知っている人。かっこいい
それ以降、Laptop-DHCP-Serverはクライアントによって無視されます。
したがって、この場合の解決策はおそらく次のようになります（実際にテストするときにこれを更新します）。
- クライアントがオフになっていることを確認します
- ラップトップのDHCPサーバー、ラップトップの偽のクライアントMAC、DHCP要求をオフにします
- IPを解放する
- 元のIPとMACを回復し、DHCPサーバーをオンにします
- クライアントの電源を入れ、PXEブートを実行します...