ダウンロードは頻繁に一時停止してタイムアウトします
私は新しいシステムおよびネットワーク管理者です。私の経験はシステムとサーバーのハードウェアとソフトウェアでしたが、ネットワークの部分は私にとってかなり新しいものです。私はネットワーク構成に番号を接続することに精通していますが、サブネット化やパケットのドロップ（;）について尋ねると、この本当に失われた外観が私の顔全体に点滅しているのがわかります。勉強中です。
これが私の問題です：
ここで手綱を引き継ぐ約2か月前から、以前のネットワーク管理者は、大きなファイルのダウンロードで問題が発生したと報告しています。まあ、実際には大きなファイルだけでなく、大きなファイルの方がイライラします。ダウンロードを行っているのは私です（ランダムなドライバーから、Technetサブスクリプションおよびライセンス契約の最新のディストリビューションやSP、さまざまな部門向けの数ギガバイトのエンジニアリングソフトウェアパッケージまで）「ベビーシッター」する必要があります。ダウンロードして、一度に何時間もデスクにつながれていました。
ダウンロードは問題なく開始され、ダウンロードが失敗する前に一時停止して再開しないと、ダウンロードが停止して失敗する前に、数Kから数Gの範囲のランダムなポイントに到達します。一時停止/再起動がすぐに機能する場合があります。ダウンロードは速度を上げて、サイクルが繰り返される前に少し進行します。ダウンロードが実際に再度ダウンロードを開始する前に、いくつかの一時停止/再起動サイクルを実行する必要がある場合があります。
ネットワークとISPの詳細：
- 私たちのISPが提供するファイバーインターネット接続（私たちの地方都市は私たちのISPです）。ダウンロード速度は通常1.1Mbps前後で、1.6Mpbsものスパイクがあります。一時停止/再起動サイクルの最中に、速度が数百Kbpsと低くなることがありますが、数サイクル後に再び速度が上がります。異なるホストからの速度はかなり一貫しています。
- 内部ネットワークにはプロキシがなく、接続をブロックしていることを認識しているファイアウォールもありません。ゲートウェイとしてCisco1811Wを使用していますが、これまで問題はありませんでした。
この問題は9月頃に最初に指摘されましたが、その頃に私たちの側に変化はありませんでした。
問題が私たちの側にあるのかISPにあるのかを判断するには、何をテスト、チェックなどする必要がありますか？
更新：
数日間問題が発生した大規模なダウンロードのTCPストリーム）用にフィルタリングされたwiresharkフィードを見ています。ほとんどのトラフィックフレームにはラベルが付けられています...
継続または非HTTPトラフィック
...これは、ダウンロードを構成する後続のパケットだけだと思います。ただし、比較的頻繁に（3〜20秒ごとに）、Firefoxによって報告されるダウンロード速度の低下にほぼ正確に対応するのは、...というラベルの付いたフレームの大きなセクションです。
[TCP再送信]継続または非HTTPトラフィック
また、いくつかのランダムなフレームがあり、通常、再送信パケットの周囲に広がり、両側に数十フレームのラベルが付けられています...
[TCP前のセグメントが失われました]継続または非HTTPトラフィック
...そしてwhadayaknow、ダウンロードは3.2GBファイルの約半分で失敗しました。最後のフレームはTCP前のセグメントが失われましたフレームです。これは、ダウンロードを一時停止して再起動しようとした直後に発生しました。キューの即時失敗です。
ダウンロードの最後のフレームはhttp [ACK]、続いてhttp [FIN、ACK]で、これは「優雅な」TCP =接続の閉鎖。
仲介者による中断を示すものは他に見られませんでした。
アップデート2
この問題は、ダウンロードするすべてのブラウザーとアプリで観察され、一時停止/再起動機能は、一時停止/再起動を許可するすべてのアプリで99％の時間機能します。これを簡単に複製できる特定のアプリとブラウザー：Firefox（現在のバージョン）、IE（9）、iTunes（iOSデバイス用のアプリとアップデートのダウンロード）。これらすべてかどうかはわかりません。ダウンロードの一時停止/再開機能にも同じ機能を使用してください。
iTunesはすべて再起動を許可するサーバーからダウンロードするため（iOSアップデートファイルを除く）、ダウンロードを一時停止する時間は関係ありません。大きなファイルをダウンロードしているほとんどのサイト（MS、PTC、Solidworks、AutoDesk）は、停止/キャンセルされたダウンロードの再開をサポートしていません（MSはサポートしていますが、Javaベースのダウンロードマネージャーからのみです）。そのため、約15秒間しか一時停止できません。再開を試みるとすぐにダウンロードが失敗する前の最大値。
アップデート
Mturoute（Thanks Tom H）を使用すると、断片化前の一貫したルートの最大MTUは1500バイトであり、パスは、ISPデバイスを介したホップを含め、エンドツーエンドで10000バイトの断片化を伴うICMPペイロードを伝送しました。したがって、問題は断片化や互換性のないMTU設定ではないようです。
これらのファイルをダウンロードするためにBTを使用していませんが、ICMPもISPによってブロックされておらず、BitTorrentもブロックされていません。
更新4
したがって、WireSharkログから判断して、調査する必要があるのは、再送信と前のセグメントの失われたフレームの原因を特定する方法です。これらの考えられる原因をどのように分離しますか？
問題は解決しました！
この問題は不定期に発生したため、診断が非常に困難でした。また、まれではありませんが、頻繁でもありません（はい、それは矛盾です。私はそれと一緒に暮らします）。
やがて問題は悪化し、接続の他の側面に影響を及ぼしているように見え、pingのドロップなどでそれを捉えることができ、問題がネットワークにないことが明らかになりました。
私たちのISP（当時）は再販されたAT＆T接続だったので、最初に再販業者に話しかけて、収集した情報を提示しました（これはメモリからのもので、問題は約6か月前に解決されたため、技術的な詳細はほとんどありません、申し訳ありません）問題の証明は私たちのネットワークの内部ではありませんでした。彼らは自分のスイッチの1つに問題があることを発見し、それを交換しましたが、これでは問題が修正されなかったため、テストを行い、AT＆Tの上流で問題を見つけ、AT＆Tは問題を裏付けて解決することができました。
問題がAT＆Tだけにあったかどうかは完全にはわかりません。症状がどのようにエスカレートしたかを考えると、AT＆T側の問題が原因だったと思いますが、元々はローカルISPに問題があったため、信頼の問題がありました。
私たちはISPを切り替え、その理由で地元の再販業者を離れて、AT＆Tに行きました。フライパンから火の中へ。しかし、私たちは今、より多くの保証に対してはるかに少ない金額を支払っています。AT＆Tが問題を見つけるとすぐに、彼らはそれを修正しました。これは私たちの本では問題ありません。
通常、ネットワークのさまざまな部分を体系的に証明することで、問題を切り分けて解決することができます。これは自信を持って言うプロセスです。Iknowこれは適切なツールを使用して調査することで機能し、パーツごとにジグソーパズルの最後のピースに到達して、I と言います。知っているこれは問題です。他のすべてが良いからです！
両方イーサネット[〜＃〜]および[〜＃〜]ワイヤレスに接続されたデバイスで問題を再現できる場合は、問題を切り分けます。ネットワーク<=> Cisco 1811W <=> DSLファイバー<=> ISP <=>とインターネット間の最終リンク
有線ネットワーク[〜＃〜]または[〜＃〜]ワイヤレスデバイスのいずれかでのみ問題が発生する場合は、Cisco1811Wで有線イーサネットまたはワイヤレス構成をターゲットにできます。次に、問題のあるセグメントに共通の設定を次のステップとして確認できます。
通常、一般的にリンクされているイーサネットケーブルを取り付け直し、可能であればDSLケーブルを交換してみてください。
DSLに設定されているルータのMTUおよび自動ネゴシエーション設定を確認し、IOSからルータのログファイルを確認します。
ルーターはIOS 12またはそのようなものを実行します。これには、ネゴシエートされた設定をチェックするためにssh経由でアクセスされるいくつかの優れたコマンドラインツールがあります。
使用 show interfacesコマンドを使用して、再送信やドロップされたパケットなどのエラー統計を確認します。 Webインターフェイスを備えている場合もあります（ただし、現時点ではCisco IOSデバイスを使用していないため、Ciscoネットワークのトラブルシューティングに関するメモだけではテストされていません）
ただし、を使用してCiscoコンソールからポートごとのエラー統計のテーブルをプルアップできるはずです。
# show interfaces status
# show interfaces counter errors
特定のポートの場合（例：.
# show interface GigabitEthernet 5/28 status
# show interface GigabitEthernet 0/24 switchport
編集： ここに小さなビデオがあります 問題をトラブルシューティングするためにios「showinterfacescounterserrors」を使用する方法を示している人の。それは実際には本当にクールですが、おそらく深すぎますが、デュプレックスの不一致を検出したり、設定を自動ネゴシエートしたりするために必要な情報を提供します。
p.s.代替のDSLルーターをファイバー接続に接続することで、接続のルーター部分を証明できます。ダウンロードが機能する場合は、ISP側ではなく、こちら側に問題があることがわかります。
一部のISPは奇妙な決定を下します スイッチまたはファイアウォール上のすべてのICMPパケットをブロックします。これにより、パスMTUの計算がブロックされます。つまり、MTUが低いルートを通過するときに、より多くのフラグメント化されたパケットが発生します。多分あなたはこれの結果を見ているでしょう。
断片化されたパケットは再構築する必要があります。これは、パケット損失もある場合に問題になる可能性があります。大きなファイルをダウンロードしようとしている場合、パケットの断片化と損失の両方がより大きな問題になります。パスMTUディスカバリーは、断片化を減らすように設計されています。
では、ISPがこれを行ったかどうかをどうやって知るのでしょうか。あなたは彼らに尋ねることができます-しかし、私の経験では、ISPは彼らが何か間違ったことをしたかもしれないと認めるよりも数日/週の間基本的なトラブルシューティングであなたを送り出すことをはるかに好むでしょう。そしてもちろん、時には彼らは正しいです！
あなたは彼らにあなたが見ているものを示すために情報を集めるべきです。 Wiresharkで行った、またはファイアウォールで収集したようなパケットキャプチャは、断片化のレベルを明らかにすることが多いため、役立ちます。パスMTU検出が機能しているかどうかは、tracepath（* nix）または mturoute （Windows）を使用して確認できます。
PMTUが機能していない場合は、ISPか、ダウンロードしようとしているサイトのISPのいずれかである可能性があります。複数のサイトからのダウンロードで問題が発生した場合は、ISPが原因である可能性があります。
そしてもちろん、それは他にもたくさんあるかもしれません:-)頑張ってください！
これらの大きなファイルをダウンロードするためにBitTorrentを使用していますか？多くのISPは、トラフィックの悪用者を検出してレート制限するための特別なハードウェアをインストールしています。
私はあなたのISPに電話して、あなたが彼らとどのような計画を立てているか、そして彼らがトラフィックシェーピングやスロットルを認識しているかどうかを尋ねます。
これが私のISPが使用しているものです：
そのようなハードウェア/ソフトウェアのレート制限デバイスが存在することが判明した場合にそれらをバイパスする方法を決定するための演習として、OPに任せます。
好奇心が強いのですが、これらはすべてWindows 7マシンですか？ Win7マシンにのみ影響する同様の問題がありました。ありそうもない解決策がうまくいき、私は人生でこれほど幸せになったことがありません。
私の質問はもともと電子メールに関するものでしたが、すぐにこの問題がネットワークに関係するほとんどすべてのものに広がっていることに気付きました。 Microsoftの修正はシンプルで簡単で、展開前にすべてのW7マシンに構成するようになりました。それ以来、何の問題もありませんでした。
ここに質問があります： 元の質問