一見空のパケットでネットワークが溢れている
私はネットワークの知識がほとんどない私の会社の単なるWeb開発者であるという事実を前置きにしましょう。
今日の初めに、すべてのネットワーク接続を失った部門があったので、Wiresharkを開いて、自分のマシンへのパケットの流入を観察しました。
毎秒最大50パケットで着信する通常のトラフィック（ARP要求など）がありました。その後、突然、ログは1秒あたり約5000に到着するパケットで溢れかえりました。それらはすべて同じデータを含んでいるように見えますが、ループされたシーケンスだけです。
ここに誰かが見ているのですが、こんなものを見たことがある人はいないかと思いました。
これは、Wiresharkのキャプチャの1つからの選択です（画像をクリックしてCloudsharkキャプチャを開きます）： 
まず、フレーム数もデータ量も、ファストイーサネットを配置しただけでも、ネットワーク接続に大きな影響を与えることはありません。500バイトの5,000フレームは、データの2.5 MB /秒より少し少ない量になります。ただし、スイッチでブロードキャストストーム検出メカニズムがトリガーされ、正当なトラフィック（特にARP要求）のブロードキャストフレームドロップが発生し、IP接続に悪影響を与える可能性があります（通常、完全に中断することはありませんが、タイムリーでないARPが原因でパケット損失が発生する可能性があります）解決）。
送信されたキャプチャのLLCフレームは奇妙に見えます。送信元アドレスもマルチキャスト宛先アドレスも、有効な実際のアドレスのようには見えません。また、LLCフレーム形式は標準に違反しています-NULLアドレスはUIフレームタイプと組み合わせて使用されます-これは決して起こらないはずです：
Nullアドレスは、XIDおよびTESTPDUのアドレスフィールドでの使用にのみ有効です。ヌルアドレス（DSAPおよびSSAP）の使用は、ISO/IEC8802-2で指定されています。
（出典： IEEE LLCチュートリアル ）
いくつかのデバイス（おそらくnotではありませんが、送信元アドレスはXeroxのMACアドレス空間に解決されます-私は彼らが基本的なことを知って従うことを期待しますルール）はプロトコルに違反しています。管理対象スイッチのFDB /アドレステーブルを調べて、それを探してみてください。任意の管理対象スイッチから開始し、テーブル内で00:00:03:20:00:00アドレスを見つけます。これは、おそらく別のスイッチのアップストリームポートに関連付けられていると思われます。次のスイッチは、エッジポート（つまり、単一のホストが接続されているポート）に関連付けられているアドレスが見つからない限り、手順を繰り返します。
Hexdumpを見ると、4バイトが何度も繰り返されているのと同じシーケンスであることがわかります。この4バイトのシーケンスは有効なデータではなく、デコードしようとしても有用な情報は得られません。
この繰り返しシーケンスは、送信元と宛先の両方のMACアドレス、およびEtherタイプを対象としています。これは、送信元MACアドレスも宛先MACアドレスも何も意味せず、破損していることを意味します。これもLLCフレームではなく、このバイトシーケンスがLLCとしてデコードされただけです。
そのようなものが再び表示された場合は、最初に複数のブランドのイーサネットアダプターを使用してトラフィックをキャプチャし、それらの破損したフレームが実際にネットワーク上で送信されていることを確認します。キャプチャ。
このトラフィックが実際にネットワーク上で送信されていることを確認した場合は、どのデバイスがトラフィックを生成しているかを探し始める必要があります。これは、MAC層の下の物理層での低レベルの問題のように見えます。通過するMACアドレスがないため、ソースを見つけるための唯一のオプションは、点滅しているリンクステータスを確認し、それらのパケットを生成しているものが見つかるまでワイヤを抜くことです。
根本的な原因がハードウェアの欠陥である可能性はほとんどありません。
障害NICはこれを行うことができ、理由はわかりません。これが表示されることはめったにありませんが、常に1つですNICこれはおかしくなりました。交換して、あなたはおそらくこれを二度と見ることはないでしょう。