ネットワークスループットの問題（ARP関連）
私が働いている小さな大学では、非常に奇妙なネットワークの問題が発生しています。ここでアドバイスやアイデアを探しています。夏は元気でしたが、秋学期に学生がキャンパスに戻ってから数日でトラブルが始まりました。
症状
主な症状は、インターネットアクセスが機能することですが、非常に遅いです...多くの場合、タイムアウトになります。例として、Speedtest.netからの典型的な結果は、.4Mbpsのダウンロードを返しますが、3〜8Mbpsのアップロード速度を許可します。症状が少ない場合は、ファイルサーバーとの間でデータを転送するパフォーマンスが大幅に制限されている場合や、場合によってはコンピューターにログインできない（ドメインコントローラーに到達できない）ことがあります。この問題は複数のVLANにまたがっており、運用しているほぼすべてのVLANのデバイスに影響を及ぼしています。
この問題は、ネットワーク上のすべてのマシンに影響するわけではありません。影響を受けていないマシンでは、通常、speedtest.netから少なくとも11Mbpsのダウンロードが見られますが、その時点での大規模なキャンパストラフィックパターンによっては、さらに多くのダウンロードが見られます。
より大きな問題には1つのバリエーションがあります。ユーザーがほぼすべてのマシンにまったくログインできなかったVLANが1つあります。 ITスタッフは、ローカル管理者アカウント（または場合によってはキャッシュされた資格情報）を使用してログインし、そこからリリース/更新またはゲートウェイへのpingにより、マシンが動作できるようになります...しばらくの間。この問題を複雑にしているのは、このVLANが、DeepFreezeと呼ばれるソフトウェアを使用して再起動後にハードドライブを完全にリセットするコンピューターラボをカバーしていることです。数週間にわたって低レベルの情報を永続的に変更していないマシン上の古いデータが原因で、同じ問題が異なって現れる可能性があります。ただし、新しいVLANを作成し、ラボを新しいVLANホールセールに移動することで、これを解決することができました。
扇動
最終的に、影響を受けたマシンすべてに最近のdhcpリースがあることに気付きました。 DHCPリースが更新される時期を監視することで、マシンが「低速」になる時期を予測できます。テストVLANのリース時間を非常に短く設定してみましたが、それは、マシンがいつ遅くなるかを予測する機能を削除することだけでした。静的IPを備えたマシンは、ほとんど常に正常に動作しています。アドレスを手動で解放/更新しても、マシンの速度が低下することはありません。実際、このプロセスでは、その状態のマシンが修正されている場合があります。しかし、ほとんどの場合、それは役に立ちません。また、ラップトップなどのモバイルマシンは、新しいVLANに移行すると速度が低下する可能性があることにも気づきました。キャンパス内のワイヤレスは「ゾーン」に分割され、各ゾーンは小さな建物のセットにマッピングされます。新しい建物に移動すると、ゾーンに配置され、新しい住所を取得する可能性があります。スリープモードから再開するマシンも、低速になる可能性が非常に高くなります。
緩和策
常にではありませんが、影響を受けるマシンのarpキャッシュをクリアすると、正常に動作するようになる場合があります。すでに述べたように、ローカルマシンのIPアドレスを解放/更新すると、そのマシンを修正できますが、保証はされません。デフォルトゲートウェイにpingを実行すると、マシンの速度が低下する場合もあります。
この問題を軽減するのに最も役立つと思われるのは、コアレイヤー3スイッチのarpキャッシュをクリアすることです。このスイッチは、すべてのVLANのデフォルトゲートウェイとしてdhcpシステムに使用され、VLAN間ルーティングを処理します。モデルは3Com4900SXです。この問題を軽減するために、スイッチのキャッシュタイムアウトを可能な限り短い時間まで設定していますが、それは役に立ちませんでした。また、スイッチに自動的に接続してキャッシュをリセットするために数分ごとに実行されるスクリプトをまとめました。残念ながら、これは常に機能するとは限らず、一部のマシンが短時間低速状態になることもあります（ただし、これらは数分後に自動的に修正されるようです）。現在、コアスイッチにARPキャッシュをクリアさせるために、10分ごとに実行されるスケジュールされたジョブがありますが、これは完全または望ましいとは言えません。
複製
これで、自由に低速状態にすることができるテストマシンができました。これは、VLANごとに設定されたポートを備えたスイッチに接続されています。異なるVLANに接続することでマシンの速度を低下させますが、新しい接続を1、2回実行すると、速度が低下します。
このセクションでは、これが前の学期の開始時に以前に発生したことも注目に値しますが、過去には、問題は数日後に自然に解消されました。多くの診断作業を行う前に、それは自然に解決しました...したがって、なぜ今回はそれを用語に長くドラッグすることを許可したのですか？これは短期間の状況になると予想されていました。
その他の要因
昨年、約5ダースのスイッチが完全にフェイルオーバーしたことは言及する価値があります。これらは主に2003/2004年の3Com（主に4200）であり、すべてほぼ同時に投入されました。それらはまだ保証の対象となるはずです。HPを購入するとサービスを受けるのがやや難しくなります。主に故障した電源装置ですが、いくつかのケースでは、メインボードに故障したスイッチの電源装置を使用して、故障した電源装置のスイッチを復活させました。現在、4つのスイッチのうち3つを除くすべてにUPSデバイスがありますが、2年半前に始めたときはそうではありませんでした。厳しい予算の制約（数年前にEdの財政的に困難な機関のリストに載っていた）により、私はNetgearやTrendNetのようなものに取って代わることを余儀なくされましたが、これまでのところ、これらのローエンドモデルは独自のものを保持しているようです。
この夏のネットワークの大きな変化は、単一のキャンパス間ワイヤレスSSIDから前述のゾーンアプローチへの移行であったことにも言及する価値があります。私が言ったように、これが問題の原因であるとは思いません。これは以前に見たことがあります。ただし、これが問題を悪化させている可能性があり、分離が非常に困難であった理由の多くである可能性があります。
診断
問題のタイミングと永続的な性質を考えると、問題の原因はARPキャッシュポイズニングを実行している感染した（または悪意のある）学生のマシンであることが最初は明らかでした。ただし、ソースを分離するための繰り返しの試みは失敗しました。これらの試みには、多数のwiresharkパケットトレースが含まれ、建物全体を短時間オフラインにすることさえあります。煙を吐く銃の悪いARPエントリを見つけることさえできませんでした。私の現在の最善の推測は、コアスイッチの過負荷または障害ですが、これをテストする方法がわからず、盲目的に交換するコストは高額です。
繰り返しになりますが、どんなアイデアでもありがたいです。
更新：
コアスイッチが交換されました。 4日後、すべてが正常に実行されています...しかし、問題が解決したと電話する前に、2週間のマークを待ちます。
ジョエル、
トランクがセットアップされており、問題を自由に複製できるためです。ラップトップにWiresharkをインストールし、アップリンクポートをミラーリング/スパンします。パケットレートが10,000を超えているか、ポート使用率が最大速度に近い場合は、問題があります。
ハードウェア/スパニングツリーに問題がある可能性があります。通常、ユーザーが「スループットを向上させるために」マシンに両方のNICを接続しているのを発見しました。
通常、スパニングツリーの問題については、ベンダーからのポートごとにループ検出またはブロードキャスト制限をオンにすることができます。これにより、ループが見つかったポートがすべて強制終了されます。 「bpdu保護」をオンにすることもできます。これは、bpduが受信されたポートを無効にして、syslog/snmpトラップレシーバーにエラーをスローすることを意味します。
ジョー
私は以前にこれと同様の問題を見たことがあり、それはLANのループであり、サブネット全体の混乱と飽和を引き起こしました（おそらく、スイッチが追加のポートで独自のMACを認識しているためにブロードキャストトラフィックが原因です）。
編集：また、これは教育機関（私の以前のシステム管理者の仕事の2つ）では一般的です。小さな最愛の人はパッチケーブル/ソケットをいじり回すのが好きだからです...
ジョーのアイデアは良いものですが、問題を引き起こすブロードキャストストームではない可能性が高いことを考えると（ARPキャッシュポイズニングまたは同様の問題で正しい方向に進んでいると思います。IPアドレスの競合である可能性もあります）、それはおそらく問題を解決しないでしょう。
スイッチがサポートしている場合に、動的ARPおよびDHCP検査を使用するための関連手法。これをオンにすると、スイッチはDHCPトランザクションを監視し、DHCPデータベース内の既知のエントリまたは手動で指定したエントリと一致するARPエントリのみを許可します。
スイッチにこの機能がない場合、それを追跡するための別のオプションはLinuxユーティリティarpwatchです。これはすべてのARP要求を追跡し、IP-MACマッピングの変更に気付いたときに通知します。
ブロードキャストストームを引き起こすいくつかの悪いハードウェアを手に入れたので、私には聞こえます。 Wiresharkを使用してブロードキャストを監視し、問題を引き起こすホストを見つけます...