私は私の仕事で今日起こった有益な物語を伝えたいです。 私は、特にWorld Wide Webへのアクセスを提供する非常に有名な会社で働いています。 そして、私の仕事の本質は、データネットワークの通常の運用を維持することです。 このネットワークは、コア、集約、アクセスの古典的な構造に従って構築されています。 アクセススイッチは、D-Linkの生産の約半分で、2番目の（最大）部分はHuawei製です。 すべてのネットワークハードウェアの管理は個別のvilanで行われ、すべて監視されます。
そして今日の朝、何かがおかしくなりました。 鉄の管理および監視システムは、イベント「スイッチ***オフライン」-「スイッチ***オンライン」の「フットバッグ」を捨て始めました。 さらに、これらのメッセージは、Huaweiが製造したスイッチがインストールされたネットワークのセグメントで送信されました。 ストーム制御の状態と集約上のインターフェイスの輻輳の状態をすばやく確認しても何も得られず、ログも何も言いませんでした。 楽しい日になると約束した日...
ネットワーク監視サービスからの呼び出しは喜びを追加しませんでした-彼らは家のノードの損失で事件を始めました。 同時に、サービスの取得の制限に関するクライアントからの大量の苦情はありませんでした。 ICMPに0.8ミリ秒で応答する問題セグメントでクライアントを見つけることさえできました。 telnetを介してスイッチにアクセスする試みは拷問に似ていました。タイムアウトのために接続が切断されるか、ログイン/パスワードとコマンドの入力に対する反応を数分間待つ必要がありました。 「半死」スイッチのログを見たいと必死で、私は良心をクリアするために、かなりの量に苦しんでいたので、それを再起動しました。 開始から約10秒後、スイッチは稼働し、ICMP要求に積極的に応答しましたが、すぐに「ping」が800〜1000ミリ秒の目で完全に不適切な値を取り始め、その後完全に消えました。
それから、スイッチ上で決して高性能ではないプロセッサに、明らかに何かがロードされており、ほとんどの場合、100％満杯であることに気付き始めました。 監視サーバーのVLANインターフェイスでtcpdumpを実行すると、スイッチのCPU負荷が高くなる理由がわかりました。 コントロールバンの異常に大量のARPトラフィックは、1秒あたり数千パケットです。 理由は見つかりましたが、そのソースを見つける方法は？ 集約のすべてのポートで制御ベーンをブロックし、次に問題のあるセグメントが見つかるまでロックを解除することを決定しました。
この操作は、アグリゲーションの2つのノードでしか実行できませんでしたが、突然すべてのホイッスルが停止しました。 しかし、次のテーブルに座っている同僚が1分前に、機器にアクセスして設定するために使用されたスイッチポートからネットワークパッチコードを引き出したのは非常に疑わしかったようです。 私は同僚にラップトップをネットワークに再接続するように頼みました-10秒後、スイッチの「ping」が再びvaluesい値になりました。 ソースは見つかりましたが、このラップトップはソフトウェアを更新し、ネットワーク機器を構成するために数ヶ月間使用されています。
そもそも、ウイルス対策ソフトウェアはインストールされていましたが、医師や研究室のユーティリティを使用してマルウェアをスキャンすることにしました。 重要なものは見つかりませんでした。 Linuxを起動しようとしました-ネットワークは静かで、洪水はありませんでした。 彼らはWindowsをロードし直しました。これは永続的な効果で、すぐにvilanはARPフラッドでいっぱいになりました。 しかし、昨日、すべてがラップトップで正常に行われました！ そして、ここで、何らかの理由で、ネットワークカードの設定に登りました...私の同僚は、ハードウェアの構成とソフトウェアの更新にあまり関与していないため、制御ネットワークのマスクとゲートウェイの値を思い出せませんでした。 そして、彼はネットワークカードの設定で不幸なミスを犯しました-サブネットマスクの255.255.224.0の代わりに、彼は255.255.254.0を示しました！
しかし、さらに私を驚かせたのは、明らかに間違った構成（その中のゲートウェイが誤って指定されたマスクのためにネットワークセグメントの外側にあった）にもかかわらず、OSがこのナンセンスをsignみ込んだことです！ ラップトップをARPトラフィックジェネレーターに変える。 ipv4プロトコル設定には次のものがあります。
IP 10.220.198.111 255.255.254.0 10.220.192.1
このマスクを使用すると、サブネットはIPアドレス10.220.198.1〜10.220.199.254によって制限され、ゲートウェイ10.220.192.1はこの範囲外になります。 オペレーティングシステムでは、別のネットワークからのゲートウェイアドレスの割り当てを許可しないでください。 これは明らかなバグです！
誰かがこの状況でARPフラッドの発生のメカニズムを説明するのに苦労してくれたら感謝します。私自身で、すべてのネットワークスペシャリストの注意と再度の注意を望みます。 彼らが言うように-7回測定し、一度カットします。