最近経験したこの奇妙な問題についての考えや意見をいただければ幸いです。
問題のあるクライアントから確認された一貫した行動:
- 午前中のある時間まで、ユーザーのPCは169.254.x APIPAアドレスの使用を要求していました。
- この時間枠内にDHCPサーバーから提供された正当なアドレスを受け入れない
- 2回目のDHCPDISCOVERの後、クライアントはDHCPが提供するIPアドレスを受け入れるようになります。
まとめ
- 週末に単一の建物ネットワークに影響
- 週末にマシンの電源を入れたままにしていたユーザーも問題なく、DHCPの更新などが正常に動作しています。
- 念入りにPCの電源を切ったにもかかわらず、電源を入れた後にDHCPの問題を経験したユーザー
- この影響は建物に2時間にわたって及んだが、問題は見つからず、自然に解決した。
- ネットワークは監視され、徹底的な調査が完了しました。期間中にネットワークの問題は発生しませんでした。
- DHCPサーバーはサイト全体にアドレスを発行しますが、これは1つの建物にのみ限定されます。
- クライアント マシンは主に Windows 7 で、さまざまなハードウェアおよび NIC ベンダーが影響を受けますが、パターンは見つかりません。
- 静的デスクトップとラップトップの混合
- 有線接続
- VLAN 内のすべてのクライアントが影響を受けるわけではありませんが、1 つの VLAN が影響を受けます。
DHCP サーバー ログに記録されたイベントのシーケンス
- DHCPDISCOVER - クライアント PC - クライアントによる最初の検出アクション
- DHCPOFFER DHCP サーバー - DHCP サーバーが提供する正当な IP アドレス
- DHCPREQUEST - クライアント PC - クライアントからの 169.254x の要求: 「ネットワークが間違っています」というメッセージ
- DHCPNAK - DHCP サーバー - サーバーは NAK を介して否定応答します。クライアントはプロセスを再度開始する必要があります。
- DHCPDISCOVER - クライアント PC - クライアントによる 2 番目の検出アクション
- DHCPOFFER - DHCP サーバー - 正当な IP アドレスが提供されます
- DHCPREQUEST - クライアントPC - クライアントは正当なIPアドレスの使用を要求します
- DHCPACK - DHCPサーバー - サーバーが肯定応答する
RFC3927 のポイントの擬似要約:
RFC 3927 IPv4 リンクローカル アドレスの動的構成を「簡単に」読んでみると、答えよりも多くの疑問が見つかります。
リンクローカル169.254.xアドレスが使用される場合
- 169.254. /16 アドレスまたはアドレス構成が利用できない場合に使用されるリンクローカルアドレス指定
- 通常は起動時に実行されます
169.254.xアドレスとルーティング可能なアドレスを使用しているホストが現在利用可能な場合、ホストは
- ルーティング可能なアドレスを使用する
- 169.254.x の宣伝をやめる
ルーティング可能なアドレスが利用できなくなる可能性がある
- DHCPリースの有効期限
- 手動設定によるアドレスの削除
- アドレスが使用できなくなった新しいネットワークへのホストのローミング
169.254.x アドレス選択
- WindowsおよびMACホストはリンクローカル自動構成を実装します
- Windows に関する注意:
- ネットワーク接続が検出されるとすぐに、インターフェース上でDHCPREQUESTまたはDHCPDISCOVERが送信されます。
- 接続が可能になるとすぐに、システムは自動構成から移行します。
- ホスト(MAC)に対してシードされた疑似乱数生成
- 起動時に発生
169.254.x アドレスの取得
- ホストは、169.254.x リンク ローカル アドレスがネットワーク上で使用されていないかどうかをテストする必要があります。
- ブロードキャストされた ARP 要求によって完了 (ターゲット IP アドレスを含む - プローブ対象)
169.254.x アドレスのアナウンス
- 2回目のARPブロードキャストですが、今回は送信元とターゲットのIPアドレスが含まれ、選択された169.254.x IPになります。
最終まとめ
- クライアントはDHCPDISCOVERを実行し、DHCPサーバーはDHCPOFFERで応答します。
- クライアントは、このルーティング可能なアドレスの提供を受け入れ、リンクローカル 169.254.x の使用を停止する必要があります。何らかの理由で、そうはなりません。
- クライアントからの後続の DHCPREQUEST は、ARP プローブまたは ARP アナウンスメント ブロードキャストのように見えますか? クライアントは 169.254.xx を使用しており、DHCP サーバーの応答と相関していない可能性がありますか?
- 2 番目の DHCPDISCOVER - PC の電源が最初にオンになっていたため、何がこれを促すのかは不明です。
ここまで読んでくださった方には、忍耐強くお礼を申し上げます。
これを理解する上で助けていただければ幸いです。
ありがとう、
答え1
リース プールのアドレスが不足していますか? おそらく、追加の IP アドレスを配布できなくなったのはそのせいです。
Windows に入ったら、影響を受けるマシンから DHCP サーバーに ping を実行できますか? DHCP 範囲の未使用の IP に NIC をハードコードできますか? そうすれば、テストのためにネットワークに接続できますか? 必要に応じて、動作している PC の 1 台を、動作していないマシンと同じネットワーク ポートでテストします。