DHCPクライアントは、「最良の」回答とは何を考えますか？

通常、Windows XPが（PXE経由で）インストールされるトレーニングルームがあります。「通常の」DNS / DHCPインフラストラクチャはWindowsサーバーです。トレーニングルームには独自のVLAN（Windowsサーバーとは異なります）があるため、そのルームのすべてのPCが接続されているCiscoルーターでアクティブなDHCP要求用のIPヘルパーが最も適切です。

ここで、代わりにいくつかの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応答にどのように反応するかはファームウェア固有です。

私が長年見てきたバリアントは次のとおりです。

1）ACKであるかNACKであるかにかかわらず、最初のものを受け入れます。

2）最初のACKを取得し、NACKを完全に無視します。

3）設定された時間間隔（通常5〜10秒）以内に受信した最後のACKを取得します。

例：数年前、リコーMFPに問題がありました。
2台のDHCPサーバーがありました。1つはアドレスを提供し、もう1つは追加のDHCPオプションのみを提供しました。2番目のサーバーは常に最初に応答しました。
最初のオファーにDHCPオプションしか含まれていなかったとしても、リコーの使用バリアント1）。リコーは、問題を説明した後、ファームウェアを更新して2）に変更しました。

ルーターがまだDHCPリレーとして機能し、元のサーバーに要求を転送していると仮定すると、その理由は、Windows DHCPサーバーが先に進んでIPを使用するように指示したためです。この例では、DHCPクライアントはすべての応答を検討するため、新しいサーバーからのDHCPNACKは無関係です。WindowsDHCPボックスからオファーを受け取ったので、それを使用しても問題ありません。

PC：こんにちは、192.168.1.123を使用できますか？

新しいDHCP：いいえ。

Old-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. クライアント：ああ-2つの応答がありました。すでに私を知っている人。かっこいい

それ以降、ラップトップDHCPサーバーはクライアントに無視されます。

したがって、この場合の解決策はおそらく次のようになります（実際にテストするときにこれを更新します）。

1. クライアントがオフになっていることを確認してください
2. ラップトップでDHCPサーバーをオフにし、ラップトップで偽のクライアントMACをオフにし、DHCPリクエスト
3. IPをリリース
4. 元のIPとMAC​​を取り戻し、DHCPサーバーをオンにする
5. クライアントの電源を入れ、PXEブートを実行します...

新しい質問は、おそらく別の質問に含まれている必要があります。質問のタイトルは、質問のほとんどの本文にまったく当てはまりません。

いずれにせよ、クライアントがどのオファーを選択するかに関して、現在のリースがない場合：それはクライアント次第ですが、私が知っているすべてのDHCPクライアント実装では、それは単純な競争です。

RFC 2131はこれをカバーしています：

DHCPクライアントは、クライアントがDHCPOFFERメッセージを受信するDHCPサーバーを選択する際に、任意の戦略を自由に使用できます。

IETFドラフトがあり、選択プロセスに設定可能性が追加されたと思われます。また、（10年以上前の、あまり変化していない）クライアントの実装の不備についても言及しています。

実際には、ほとんどのベンダーのここでのポリシーの実装は非常に基本的であり（たとえば、最初に受け取ったオファーまたは最初に受け入れたオファーを受け取った）、「ハードコーディング」されています（つまり、構成不可）。

構成が異なる同じネットワークにサービスを提供する2つのDHCPサーバーがあると、競合が発生します。これは、信頼性または予測可能性の観点から望ましくありません。単一のDHCPサーバーで必要なものを提供できない理由はまったくありません。