最近、リモートサイトを10 / 10Mbpsファイバーから20 / 20Mbpsファイバーリンクにアップグレードしました(地下へのファイバー、次に地下からオフィスへのVDSL、約30メートル)。このサイトと中央サイトの間には通常の大きな(マルチギグ)ファイルコピーが存在するため、リンクを20/20に増やすと転送時間がほぼ半減するはずであるという理論がありました。
ファイルをコピーするための転送(たとえばrobocopy
、いずれかの方向にファイルをコピーするために使用したり、Veeam Backup and Recoveryの複製を使用する)の場合、それらは10Mbpsで制限されます。
アップグレード前:
アップグレード後(robocopy
):
ほぼ同じ(転送時間の長さの違いは無視してください)。
転送は、Cisco ASA5520とMikrotik RB2011UiAS-RMの間のIPSecトンネルを介して行われています。
最初の考え:
- QoS-いいえ。QoSルールはありますが、このフローに影響するものはありません。とにかくチェックするために数分間すべてのルールを無効にしましたが、変更はありません
- ソフトウェア定義の制限。このトラフィックのほとんどは、オフサイトでのVeeam Backup and Recoveryの出荷ですが、そこに定義されている制限はありません。さらに、私はまっすぐに
robocopy
して、まったく同じ統計を見ました。 - ハードウェアに対応していません。まあ、5520の公開されたパフォーマンスの数値は225Mbpsの3DESデータであり、Mikrotikは数値を公開しませんが、10Mbpsをはるかに超えます。これらの転送テストを実行すると、MikrotikのCPU使用率は約25%〜33%になります。(また、IPSecトンネルを介してHTTP転送を行うと、20Mbps近くまでヒットします)
- 遅延とTCPウィンドウサイズの組み合わせ?サイト間の遅延は15ミリ
32*0.015
秒なので、最悪の場合でも32 KBのウィンドウサイズは最大2.1 MB /秒です。さらに、複数の同時転送はまだ合計で10Mbpsになりますが、これはこの理論をサポートしていません - たぶん、ソースとデスティネーションの両方がたわごとですか?ソースは、1.6GB /秒の持続シーケンシャルリードをプッシュできるので、そうではありません。宛先は、200MB /秒の持続的な順次書き込みを行うことができるため、そうではありません。
これは非常に奇妙な状況です。これまでにこのような形で何かが明らかになるのを見たことはありません。
他にどこを見ることができますか?
さらなる調査で、問題としてIPSecトンネルを指すことに自信があります。不自然な例を作成し、サイト上の2つのパブリックIPアドレス間でいくつかのテストを直接行った後、内部IPアドレスを使用してまったく同じテストを行いました。側。
以前のバージョンには、HTTPに関するニシンがありました。これを忘れて、これは不完全なテストメカニズムでした。
Xeonからの提案およびISPにサポートを依頼した際にISPがエコーしたとおり、この計算に基づいて、IPSecデータのMSSを1422にドロップするマングルルールを設定しました。
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
ISPの1480 MTUに収まるようにします。しかし悲しいかな、これは効果的な違いをもたらしませんでした。
Wiresharkのキャプチャを比較した後、TCPセッションは現在、両端で1380のMSSをネゴシエートします(いくつかの点を調整し、数学がうまくいかない場合に備えてバッファーを追加しました。ヒント:おそらくそうします)。とにかく1380はASAのデフォルトMSSでもあるので、とにかくこれをずっと交渉していたのかもしれません。
Mikrotik内のツールには、トラフィックの測定に使用している奇妙なデータがあります。それは何もないかもしれません。フィルター処理されたクエリを使用していたので、これに気付くことはありませんでした。フィルターを削除したときにのみ表示されました。
1394
は、私が通過できた最大のMTUです。