TCP LAN内での再送信の原因を見つける
こんにちはサーバー障害の住人
約100台のコンピューター、2台のWindowsドメインサーバー、および12台のVoIP電話のLANで、いらいらする問題があります。約1年前のインストール以来、毎週かそこらで、VoIP電話が自動的にリセットされることに気づきました-通話の途中で。同時に、コンピューターの接続が一時的に失われる兆候がしばしばあります。ネットワーク共有へのアクセス中にエクスプローラーがフリーズする、データベースサーバーへの接続が失われるために管理ソフトウェアにエラーが発生する。
私はVoIP PBXとネットワークの残りの部分との間の接続でいくつかのWireshark監視を行っています。Wiresharkは再送信されたTCPパケットの塊を拾います電話の再起動を記録する時間。Wiresharkログには、1日に約2クラスターの再送信が5パケットから数百までの範囲で表示されます。各クラスターのクラスターは、主にPBXとVoIP電話のセットの間にあります。 、ただし常に同じセットであるとは限りません。多くの場合、同じスイッチに接続された電話への再送信は同時に行われますが、ネットワークの反対側にある電話への再送信が同時に発生する場合があります。通常、TCPトラフィック。たとえば、クライアントマシンとファイルサーバーの間。
再送信の急増と電話のリセットは、ネットワークの負荷が高いときとはよく相関していません。それらは日中わずかに多く発生するようですが、ほとんどの場合、トラフィックが減少するはずの夕方に発生します。それらは、ほとんどのコンピューターの電源がオフになっていてトラフィックが最も少ないはずの夜遅くにかなり頻繁に発生します。
このような問題の原因を診断するのに役立つアイデアはありますか？私がまだ試していないが、持っているべきである1つのことは、すべてのスイッチのファームウェアを更新することです。
TCPの再送信は通常、ネットワークの輻輳が原因です。問題が発生したときに、多数のブロードキャストパケットを探します。キャプチャ内のブロードキャストトラフィックのパーセンテージがキャプチャされた総トラフィックの約3％を超える場合は、確実に輻輳しています。ネットワーク上で物理層（ARP）とネットワーク層（名前解決）の両方のブロードキャストを探します。大量のブロードキャストトラフィックが見つかった場合は、キャプチャデータからソースまで追跡できます。
スイッチのトラフィック統計を収集すると、キャパシティーまたはその近くで実行している期間があることが示される場合があります。これにより、最初のタイムアウト（多くの場合3秒）以内に応答が返されない場合、再試行が行われる可能性があります。これにより、輻輳緩和メカニズムが作動するまで、一時的に輻輳が増加します。
ストリーミングメディアを使用している人を探してください。帯域幅をすぐに吸収してしまう可能性があります。
トラフィックシェーピングにより、電話の問題を軽減できる場合があります。これは問題を他のユーザーに移すだけです。
特に再送信と問題が同じスイッチ（異なる）にローカライズされている場合は、スパニングツリーループやブロードキャストストームのように聞こえます。それが発生した場合、L2デバイスのポート状態は何ですか？おそらくスイッチまたはルートブリッジの優先順位が悪いですか？興味深い問題。
長い間、おそらくこれを解決しましたが、本質的には、エンドポイント（VoIP電話、ワークステーション、サーバー）があるポートで「ポート高速」を有効にする必要があります。電話はPDUを送信できるため、その人が再起動するとSTP=収束が発生し、FDBテーブルがフラッシュされ、すべてのデバイスが4/5ステップを通過するSTP楽しい。エンドポイントのあるポートを "port fast"にすることで、待機をスキップして転送モードに移行します。
うまくいけば、あなたの電話は別のサブネット上にあり、VLAN他のコンピュータとは？
また、スイッチの故障など、機器の故障の可能性もあります。再送信は、1つの特定のスイッチまたはネットワークの一部にある電話/コンピューターと相関関係がありますか？
私の答えを少し広げるだけです。同じ仕様であっても、すべてのスイッチが同等に作成されるわけではありません。内部にはより高速なプロセッサが搭載されているため、他の負荷よりもはるかに高い負荷に対応できるものもあります。それはあなたのスイッチが完全にグレードアップしていない可能性があります。
まず、最も厄介なVOIP電話を物理スイッチに接続し、それらのリセットが続くかどうかを確認します。それが消えた場合、あなたはすぐにそれを解決する道を進んでいます。