DHCPクライアントはどのように複数のDHCPOFFERSのうちどれを受け入れるべきかを知っていますか？
写真のようなネットワークがあるとします。 1つのレイヤ2ネットワーク上に6つのホストがあり、VLANはありません。ネットワークは、それぞれ1つのDHCPサーバーを持つ2つのサブネットに分割されることになっています。 DHCPサーバーは固定IPアドレスを持っているので、明らかに彼らはどのサブネットに属しているかを知っています。
その後、新しいクライアントが接続されます。どのサブネットに入っているはずなのかわからないので、DHCPDISCOVERをEthernetブロードキャスト255.255.255.255に送信します。両方のDHCPサーバーに。両方のサーバーがオファーで応答します。これが私の質問です。クライアントはどのDHCPOFFERを受け入れればよいのでしょうか。
最も単純な答え - 先着順です。
複数のVLANがあり、10.10.10.0/24が10.10.20.0/24とは異なるVLANにあった場合 - ブロードキャストはVLANを越えません。
DHCPサーバーがクライアントとは別のVLANにある場合は、VLAN間のルーティングインターフェイスのiphelperがブロードキャストを正しい場所に転送します。
あなたのシナリオでは、同じVLAN内に2つの別々のネットワークがあり（またはそれがない）、異なるサブネットにサービスを提供しています。
DHCP以下のトランザクションを使用してサービスを提供します。
- DHCPディスカバリ（DHCPDISCOVER） - クライアントブロードキャスト - 「そこにDHCPサーバはありますか？」
- DHCPオファー（DHCPOFFER） - サーバーからクライアントへ - "ええ、私はここにいて利用可能です！"
- DHCP要求（DHCPREQUEST） - クライアントからサーバーへ「素晴らしい、アドレスを教えてください。」
- DHCP確認応答（DHCPACK） - サーバーからクライアントへ "確かに、これはIP、マスク、ゲートウェイ、いくつかのDNS/WINSサーバー、タイムサーバー、そしてあなたのスコープに合わせて設定されたその他すべてのものです"
これはすべて、サーバー用のUDPポート67とクライアント用の68で発生します。
ステップ2に達するとすぐに - クライアントは他のDHCPサーバーの応答を "聴く"のをやめます - 最初のサーバーを処理して注意を促します。
補足として - この権利を悪用する一連のDoS（Denial of Service）攻撃が実際に知られています。攻撃者は、DHCPOFFERパケットに応答して送信し、その後要求されたときにDHCPACKを送信しないデバイスを差し込みます。また、 "偽の" DHCPサーバーがルーティングできないアドレスや他のIPと衝突するアドレスを提供するというDoS攻撃もあります。
@ Fazer87からの 既存の答え は実際には大体正しいので、私はそれを支持して受け入れることを勧めます。この回答では、もう少し詳しくもう少し詳しく説明します。
両方のDHCPサーバーがDHCPOfferメッセージで応答することがあります。
DHCPクライアントは、「先着順」でそれらを受け入れます。しかし、そのようなアプローチをとる必要はありません。
RFC2131 は以下を指定します。
クライアントは、1つ以上のサーバーから1つ以上のDHCPOFFERメッセージを受信します。クライアントは複数の応答を待つことを選択できます。クライアントは、DHCPOFFERメッセージで提供されている設定パラメータに基づいて、設定パラメータを要求するサーバを1つ選択します。
したがって、2番目のDHCPサーバーがより長いIPアドレス予約を提供した場合、または他のDHCPサーバーが提供していないタイムサーバーを提供した場合、またはクライアントが優先するようにプログラムされたカスタムフィールドがある場合は、2番目のオファーを受け入れます。
通常、「先着順」というアプローチでは、デバイス間で何度もホップしたことのないオファー（BOOTPの再ブロードキャスト）が得られるため、気にする理由がない場合は従うのが良いプロトコルです。
私は、カスタムデバイスが、アップデートされたファームウェアを見つけることができるTFTPサーバを含むDHCPOfferを好むという1つのプロジェクトに取り組んでいました。