LAN内のTCP再送信の原因を見つける


25

こんにちはサーバー障害の住人

約100台のコンピューター、2台のWindowsドメインサーバー、12台のVoIP電話で構成されるLANで、いらいらする問題があります。約1年前、毎週かそこらにインストールしてから、VoIP電話が自動的にリセットされることに気付きました-時々通話の途中です。同時に、コンピューター上の接続が一時的に失われる兆候もしばしば見られます。ネットワーク共有にアクセスしているときにエクスプローラーがフリーズしたり、データベースサーバーへの接続が失われたために管理ソフトウェアにエラーが発生したりします。

VoIP PBXとネットワークの残りの部分との間の接続でWiresharkの監視を行っています。Wiresharkは、電話の再起動を記録するときに、再送信されたTCPパケットの塊を拾います。Wiresharkのログには、1日あたり5パケットから数百件までの約2クラスターの再送信が記録されています。各クラスター内のそれらは主にPBXとVoIP電話のセットの間にありますが、常に同じセットではありません。多くの場合、同時に再送信されるのは同じスイッチに接続された電話ですが、ネットワークの両端にある電話に対して再送信が同時に発生することもあります。通常、クライアントマシンとファイルサーバー間など、TCPトラフィックの受け渡しでいくつかの偶然の再送信があります。

再送信と電話のリセットの急増は、ネットワークの負荷が高い場合とはあまり相関しません。それらは日中にわずかに多く発生するようですが、ほとんどの場合、トラフィックが減少するはずの夜に発生します。ほとんどのコンピューターの電源がオフになっていて、トラフィックを最小限に抑える必要がある夜間にかなり頻繁に発生します。

このような問題の原因を診断するのに役立つアイデアはありますか?まだ試していませんが、そうすべきである1つのことは、すべてのスイッチのファームウェアを更新することです。


1
どのモデルが切り替わりますか?proccessor、memeory、などの統計はどのように見えますか?1つのブロードキャストドメインにいますか?ネットワーク上で最大スループットにどれだけ近づいていますか?
ザイファー

どのVoIPプロトコルを使用していますか?また、UDPまたはTCPを使用していますか?
クリスS

すべてのスイッチは3Comです:ベースライン2924-PWR Plus(3CBLSG24PWR)x 2、4200(3C17304A)x 3、4200(3C17304)x 2、2824-SPF Plus(3C16487)、2250 plus(3C16476CS)。プロセッサやメモリに関する統計情報を提供するとは思わないが、そうでなければ学ぶことができてとてもうれしい。はい、1つのブロードキャストドメインにいます。スループットについては知りません。測定を検討します。
シュール

回答:


17

TCP再送信は通常、ネットワークの輻輳が原因です。問題が発生したときに多数のブロードキャストパケットを探します。キャプチャのブロードキャストトラフィックの割合が、キャプチャされたトラフィック全体の約3%を超えている場合、間違いなく輻輳が発生しています。ネットワーク上の物理層(ARP)とネットワーク層(名前解決)の両方のブロードキャストを探します。大量のブロードキャストトラフィックが見つかった場合、キャプチャデータからソースまでトレースできます。


9
さらに、TCP再送信は問題の原因ではなく、問題の症状です。
joeqwerty

UDPブロードキャストを見たが、再送信とは相関していなかったことに言及する必要がありました。再送信イベントのいくつかは、UDPブロードキャストのスパイクと一致しますが、ほとんどはそうではありません。別の見方をしたところ、UDPブロードキャストが10分の時間セグメントでトラフィックの1.5%(約350パケット)を超えておらず、そのレベルに達することはまれであることがわかりました。しかし、私はイーサネット放送を見ていませんでした。現在、すべてのWiresharkログをフィルタリングするスクリプトを実行しています。UDPブロードキャストとイーサネットブロードキャストの個別の3%の経験則は個別ですか、それとも組み合わされていますか?
シュール

1
3%は実際には経験則ではありません。それは私が言われたこと、そして自分の環境で見たことです。10〜20%の数値を聞いたことがありますが、3〜5%を超えると、通常は問題が発生することがわかりました。輻輳を引き起こす可能性があるため、すべてのブロードキャストトラフィック(イーサネット、ネットワーク、マルチキャストブロードキャスト)を確認する必要があります。基本的に、すべてのスイッチポートにブロードキャストされるトラフィックは、分析して削減または排除する必要があるトラフィックです。
joeqwerty

長期にわたって良好な相関関係を確認するためのきれいなグラフはまだありませんが、イーサネットブロードキャストは非常に有望です。再送信が発生したログには、3%を超えるブロードキャストがあり、別のログでは約6%でした。少なくとも1つの問題が見つかりました。古いサーバーがGratuitous ARPパケットの一定のストリームを送信しています。
シュール

1
私はのWiresharkのフィルタを使用して、過剰なARPエントリを発見したarp-とのみ放送のものを見るために、フィルタの使用eth.addr==ff:ff:ff:ff:ff:ff
mlhDev

2

スイッチのトラフィック統計を収集すると、キャパシティまたはキャパシティ近くで実行している期間があることがわかります。これにより、初期タイムアウト(多くの場合3秒)以内に応答が返されない場合、再試行が行われる可能性があります。これにより、輻輳緩和メカニズムが作動するまで、輻輳が一時的に増加します。

ストリーミングメディアを使用している人を探してください。帯域幅をすぐに使い果たす可能性があります。

トラフィックシェーピングにより、電話機の問題を軽減できる場合があります。これにより、問題が他のユーザーに移動します。


2

特に、再送信と問題が同じスイッチ(異なる)にローカライズされている場合、スパニングツリーループまたはブロードキャストストームのように聞こえます。発生した場合、L2デバイスのポート状態は何ですか?おそらく悪いスイッチまたは悪いルートブリッジの優先順位?興味深い問題。


恥ずかしいほどに無知であるスパニングツリーについて調べるように促してくれてありがとう。ただし、ネットワーク内に冗長リンクがないため(おそらくそれ自体に問題があるため)、スパニングツリーループであるとは思わない。「L2デバイスのポート状態」とは、スパニングツリーアルゴリズムの結果としてスイッチがどのポートを有効にしたという意味ですか?ルートブリッジを手動で構成していませんが、そうすることをお勧めしますか?
シュール

STPに慣れるのは良い考えですが、冗長リンクがないことが確実であれば、STPは問題になりません。
-joeqwerty

ええ、冗長なリンクがなければ問題はありません。ポートの状態では、はい、どちらが転送/ブロック/学習されているかを意味します。
マクジェフ

2

長い間これを解決したと思いますが、本質的にはエンドポイント(VoIP電話、ワークステーション、サーバー)を持つポートで「ポートファースト」を有効にする必要があります。電話機はPDUを送信できるため、その人がリブートするとSTPコンバージェンスが発生し、FDBテーブルがフラッシュされて、すべてのデバイスが4/5ステップのSTPを通過します。エンドポイントを持つポートを「ポートファースト」にすることで、待機をスキップし、転送モードにすぐに移行します。


1

電話機が他のコンピューターとは異なるサブネットとVLANにあることを願っていますか?


いいえ、それらは同じIPサブネット上にあり、同じVLANもかなり確信しています。これは深刻な問題ですか?それは確かに良いアイデアのように聞こえます。電話と他のすべてのブロードキャストドメインが分離されることがわかります。他の利点はありますか?
シュール

はい、間違いなく電話を専用のVLANに配置します。
グレッグアスキュー

1

また、障害のあるスイッチのような障害のある機器である可能性もあります。再送信は、1つの特定のスイッチまたはネットワークの一部の電話/コンピューターに相関していますか?

私の答えを少し拡張するだけです。仕様が同じであっても、すべてのスイッチが同じように作成されるわけではありません。中には高速なプロセッサを搭載しているため、他のものよりもはるかに高い負荷に対処できるものもあります。スイッチが完全にグレードアップしていない可能性があります。

まず、最も面倒なVOIP電話を自分の物理的なスイッチに置き、それらのリセットが継続するかどうかを確認します。それがなくなったら、すぐに解決する道を進んでいます。


彼らがしたい ネットワークの両端にある2つのスイッチに接続されたデバイスには、ほとんどの問題があるようです。ただし、ネットワークの他の部分の電話機への重要な再送信もあります。
シュール
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.