IPSecトンネル経由で10 Mbpsに制限される20 Mbps WAN


11

最近、リモートサイトを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内のツールには、トラフィックの測定に使用している奇妙なデータがあります。それは何もないかもしれません。フィルター処理されたクエリを使用していたので、これに気付くことはありませんでした。フィルターを削除したときにのみ表示されました。


MTUはどのように見えますか?
xeon

いい視点ね。両端のスイッチで9000、サーバーとクライアント自体で1500、リンクのVDSL部分で1480です。私が制御するリンクの部分はそれだけです。
マークヘンダーソン

ping -t -f -l 1500(失敗後20減少)宛先、1300前後になると動作するはずです。これは、ASA / Mikrotik IPsecトンネルでMTUを調整する必要があることを示すか、設定できる場合がありますそのため、フラグメントが大きくドロップされることはありません。
-xeon

1394は、私が通過できた最大のMTUです。
マークヘンダーソン

データは断片化されているため、トンネルのMTUを1350-1380に減らすと、スループットが向上します。IPsecオーバーヘッドは約84バイトです(カプセル化などによって異なります)ので、1480-84 = 1396で、見た最大値に近くなります。
xeon

回答:


3

CPUは3番目に確認したものですが、次のように書きました。

これらの転送テストを実行すると、Mikrotikは約25%-33%のCPU使用率になります

CPUグラフで確認されます

ここに画像の説明を入力してください

ハードウェア暗号化をオフロードするモデルを取得しない限り、ほとんどのMikrotikルーターは3DESまたはAES暗号化で11Mbpsを超えるIPSecトラフィックをプッシュできないことを外部リソース(つまり、他の多くのサポートフォーラムやブログ)で確認しました。。

したがって、これはハードウェアの制限にすぎないようです。私はもっ​​と早くそれを捕まえるべきでしたが、何らかの理由で、MikrotikはCPUバウンドであることを私に示していませんでした。

買い物に出かけます。


IPSecトラフィックにこの上限を課している特定の制限について知りたいと思います。あなたの外部情報源のどれかがそれをより詳細に説明しましたか?
ブラックライト

残念ながら違います。Mikrotikフォーラムで、このルーターの最大値として11 Mbpsがスローされたスレッドを見つけました(これを確認したようです)。私がこの人にリンクしたブログでは、テストを実行して約1 Mbpsのトラフィックを取得しましたが、はるかに低電力のルーターでした。私の方が6〜10倍強力になるはずで、6〜10倍のIPSecトラフィックを取得しているように見えます。CPUバウンドの問題、IRQバウンドの問題、またはメモリバウンドの問題のようには見えません。ここで実際に何が起こっているのか分かりません。
マークヘンダーソン

2

原因はCPUであることを確認できます。 ここでは、Mikrotik RB750GLのベンチマークを行い、AES-128トラフィックで12 Mb / sを測定しました(3DESでは6.0 Mb / sのみ)。

あなたの結果は私が記録したものと完全に一致しているようです。


750と2011の間の速度が200Mhz余分に増えても、IPSecの速度に違いはないようです。Mikrotikがこれらの図をどこかに公開することを願っています。
マークヘンダーソン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.