DHCPリースが更新された後、インターネットがありません
今日、私たちは多くのマシンがインターネットアクセスを停止しました。多くのトラブルシューティングの後、共通のスレッドは、すべてのdhcpリースが本日更新されたことです（ここでは8日間のリースを使用しています）。
リースの更新後、期待するものはすべて良好に見えます。有効なIPアドレス、DNSサーバー、およびゲートウェイがあります。内部リソース（ファイル共有、イントラネット、プリンターなど）にアクセスできます。もう少しトラブルシューティングを行うと、ゲートウェイにpingまたはtracertを実行できないことがわかりますが、ゲートウェイのすぐ前にあるコアレイヤー3スイッチに到達できます。静的IPをマシンに割り当てることは、一時的な解決策として機能します。
最後の問題の1つは、これまでのところ、ゲートウェイと同じVLAN上のクライアントに対してのみレポートが届いていることです。私たちの管理スタッフと教職員はサーバーやプリンターと同じVLAN上にありますが、電話、キーフォブ/カメラ、学生/ Wi-Fi、ラボにはそれぞれ独自のVLANがあり、他のVLANには何も表示されていません。まだ問題があります。
ゲートウェイベンダーとは別のチケットを持っていますが、彼らは簡単に解決して、問題はネットワークの他の場所にあると言ってくれるのではないかと思うので、ここでも質問します。ゲートウェイとコアスイッチのarpキャッシュをクリアしました。どんなアイデアでも大歓迎です。
更新：
ゲートウェイから影響を受けるいくつかのホストにpingを返してみましたが、奇妙なことに、まったく異なるIPアドレスから応答がありました。私はさらにいくつかをランダムに試し、最終的にこれを手に入れました：
2011年9月2日金曜日13：08：51GMT-0500（中央昼光時間） PING10.1.1.97（10.1.1.97）56（84）バイトのデータ。 10.1.1.105から64バイト：icmp_seq = 1 ttl = 255 time = 1.35 ms 10.1.1.97から64バイト：icmp_seq = 1 ttl = 255 time = 39.9 ms（DUP！）
10.1.1.97は、pingの実際の意図されたターゲットです。 10.1.1.105は、別の建物のプリンターであると想定されています。以前にping応答でDUPを見たことがありません。
現時点での私の最善の推測は、ゲートウェイが不良な10.1.1.0/24サブネット上の寮の部屋の1つにある不正なwifiルーターです。
...続き。問題のあるプリンターの電源を切りましたが、ゲートウェイから影響を受けるホストへのpingが完全に失敗します。
更新2：
影響を受けるマシン、ゲートウェイ、およびそれらの間のすべてのスイッチでarpテーブルをチェックします。各時点で、これらのデバイスのエントリはすべて正しいものでした。テーブル内のすべてのエントリを確認したわけではありませんが、ホストとゲートウェイ間のトラフィックに影響を与える可能性のあるすべてのエントリは問題ありませんでした。 ARPは問題ではありません。
更新3：
現在は機能していますが、修正するために何をしたかわからないため、これが一時的な落ち着きであるかどうかはわかりません。とにかく、今診断やトラブルシューティングを行うためにできることはあまりありませんが、再び壊れた場合はさらに更新します。
「現時点での私の最善の推測は、ゲートウェイが不良な10.1.1.0/24サブネット上の寮の部屋の1つにある不正なwifiルーターです。」
これは私のオフィスで起こりました。問題のあるデバイスは不正であることが判明しましたAndroidデバイス：
http://code.google.com/p/Android/issues/detail?id=11236
AndroidデバイスがDHCPを介して別のネットワークからゲートウェイのIPを取得すると、ネットワークに参加し、MACを使用してゲートウェイIPに対するARP要求への応答を開始する場合があります。共通の10.1.1.0を使用します。/24ネットワークは、この不正なシナリオの可能性を高めます。
ネットワーク上の影響を受けるワークステーションのARPキャッシュを確認できました。そこで、ワークステーションが正しいMACと不正なデバイスのMACアドレスの間でフリップフロップするARPフラックスの問題を観察しました。ワークステーションがゲートウェイ用に持っていた疑わしいMACを調べたところ、Samsungプレフィックスが付いていました。問題のあるワークステーションを持っている賢明なユーザーは、私たちのネットワークにサムスンのデバイスを持っている人を知っていると答えました。 CEOであることが判明しました。
コメントセクションですでに説明したように、パケットキャプチャを取得することは非常に重要です。ただし、arpwatchと呼ばれる非常に優れたツールもあります。
（または http://sid.rstack.org/arp-sk/ Windowsの場合）
このツールは、電子メールを送信するか、ネットワーク上で見られるすべての新しいMACアドレスと、特定のサブネット（フリップフロップ）上のIPのMACアドレスの変更のログを保持します。この問題では、MACを変更するIPに対してフリップフロップが実行されていることを報告するか、不正なDHCPルーターが最初にホストとの通信を開始したときに新しいMACが表示されることで、現在の両方の理論を検出していました。このツールの欠点の1つは、監視するすべてのネットワークにホストを接続する必要があることですが、この種の問題の診断に役立つ優れた情報を提供するための低価格です。
一般的な不正なDHCPサーバーを検出する簡単な方法は、サービスを提供しているゲートウェイにpingを実行してから、対応するARPテーブルでそのMACを調べることです。スイッチングインフラストラクチャが管理対象のインフラストラクチャである場合は、MACをホストしているポートまで追跡し、ポートをシャットダウンするか、問題のあるデバイスの場所までさかのぼってさらに修復することができます。
DHCPスヌーピングをサポートするスイッチでDHCPスヌーピングを使用することも、不正なDHCPサーバーからネットワークを保護する上で効果的なオプションになる可能性があります。