キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
8830
閲覧回数
1
いいね!
2
返信

AnyConnectでのパフォーマンス改善について(特にTLS接続時)

athirano1
Level 1
Level 1

こんにちは
ASA 5545X + OS 9.6系 + AnyConnect 4.6系でエンドユーザにSSL-VPN環境を提供しています。
エンドユーザはWindowsパソコンを使用しています。
(ASAは近いうちに、OS 9.12系 + AnyConnect 4.9 or 4.10 系にVer.Upを予定しています)

Ver.Upにあたりパフォーマンス改善ができないかを考えております。

以前から気になっていたのですが、
・DTLSを使うgroup-policy(ユーザグループ)で接続した時と
・DTLSを使わずにTLSで接続した時で、
通信速度が極端に違うことです。

同じ時間帯に同じASAに、同じインターネット接続環境から接続して
同じスピード測定サイトで測定しても、かなりの差が出ます。
・VPN未接続時:Download速度は60~70Mbps, Upload速度は10Mbps
・DTLS使用時 :Download速度は30Mbps, Upload速度は10Mbps
・TLS使用時 :Download速度は5Mbps, Upload速度は10Mbps

以下を確認しました
■パケットキャプチャでの確認
Wiresharkでモニターすると(インターフェースは、AnyConnectのVAではなく物理アダプタを指定)
TLS使用時は、
・クライアント → サーバ(ASA)のTCP Dupicate ACKや
・クライアント ← サーバ(ASA)のTCP Fast Retransmission
が多発していました。
(これでは遅くても無理がないな、、という感じ)

■MTUの確認
VPNで遅延が目立つ時に疑うものとしてMTUの設定があるかと思いますが
DTLSでもTLSでも、自動調整が働いているようです。
(Windowsのコマンドプロンプトから
 netsh interface ipv4 show interfaceで確認しました
 結果は以下の通りでした
 DTLS:1406 Byte ←group-policyにも設定してある上限値
 TLS :1367 Byte ←自動調整した結果と思われます )

TLS接続時に、AnyConnectのVAに対して
 netsh interface ipv4 set interfaceコマンドでMTUを
 1367から1300,1250などと下げてみましたが効果はありませんでした。
 (AnyConnect側で調整せずに、勝手に書き換えて意味があるのか?は置いておくとして・・)

---補足---
・ASA5545X×2台で運用しており、クライアントはほとんどがSSL-VPN接続です(わずかにスマホからIPsec-VPN接続もあり)
・クライアント数はASA5545X 1台あたりの同時接続数は400~500程度です
・ASAのCPU使用率は20~30%でまだ余裕があると思います。

・udp:443が遮断される環境からVPN接続するユーザには、TLSを使うgroup-policy(ユーザグループ)での接続を案内しています

==============================
質問事項
==============================
何か他にないかと思い、調べているとこんな情報がありました

------------------------------------------------------
ASA: リモートアクセスVPN パフォーマンス最適化のためのベストプラクティス (AnyConnect)
https://community.cisco.com/t5/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3-%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/asa-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9vpn-%E3%83%91%E3%83%95%E3%82%A9%E...

---「ハイエンドモデルのパフォーマンス最適化 」の項の抜粋---
Note: ハイエンドモデルで AnyConnectの SSL接続を多用する場合は チューニングを検討してください
ASA5545/5555/5585や、FPR4100/9300シリーズ(※)などハイエンドモデルでは、専用の高速処理用の暗号処理エンジンを搭載しており、暗号処理エンジンの処理優先度を、IPsec もしくはSSL もしくは Balancedの何れかに変更が可能です。
ASA5545/5555/5585は IPsecがデフォルト、FPR4100/9300シリーズは Balanced がデフォルト値です

例えば、SSL利用が殆どの環境の場合、"crypto engine accelerator-bias ssl"コマンドを実行することで、暗号処理エンジン内のコアが SSL処理優先の割当に切り替わり、AnyConnectのSSL接続時のパフォーマンスを最大化できます。

例えば、SSLと IPsecの処理負荷が同程度の環境の場合は、"crypto engine accelerator-bias balanced"コマンドを実行することで、暗号処理エンジン内のコアが IPsec処理と SSL処理用で半々となり、バランスよく両方の暗号処理が可能になります。

(以下省略)
------------------------------------------------------
私が使っているASA5545Xではデフォルトで運用しているので、IPsecの方が優先度が高くなるようです。

通信量がやや多い時間帯にshow crypto accelerator load-balanceコマンドを打ってみたところ

・コアの割振りは(IPsec用):(SSL用)=5:3でした

・SSL-VPNの処理に関して、3つのコアでの分散具合は、偏りが多い時で75%:20%:5%くらいでした

 

■質問事項

IPsec/SSL/Balancedで目に見える差が出るかは、「ユーザの環境次第」という面もあるかと思いますが
SSLまたはBalancedに変えたとして、TLS接続時のパフォーマンス改善は期待できるのでしょうか?

 

-----------------------------

検証環境にはASA 5545Xのようなハイエンド機がなく、設定変更のコマンドは性質上、メンテナンス時間でもない限り
本番環境で試せるものではないため、こちらに書き込みをさせていただきました。

よろしくお願いします。

1 件の受理された解決策

受理された解決策

Akira Muranaka
Level 8
Level 8

こんにちは!

 

TLSの通信が遅いのは、キャプチャから確認して頂いてますが、TCPベースのリモートVPN接続の場合、TCP特有の確認応答や手間が増えるので、そこでASA/AnyConnect端末や 経路機器で処理遅延が増えて低速化するのが主因かと思います。

 

VPN系は DTLS/TLSのAnyConnect終端しかASAで使ってない場合は、ハイエンドの場合は深く考えずに"crypto engine accelerator-bias ssl"を有効化して使うようにしてますが(暗号処理時におけるASA内部のボトルネックが減るので それでASA全体のパフォーマンが上がったと嬉しい報告も多数うけてます)、TLSが遅い理由は「暗号処理」""の所が主因だと思うので、その場合は高速化はあまり期待できないのではと思います。。たぶん。

元の投稿で解決策を見る

2件の返信2

Akira Muranaka
Level 8
Level 8

こんにちは!

 

TLSの通信が遅いのは、キャプチャから確認して頂いてますが、TCPベースのリモートVPN接続の場合、TCP特有の確認応答や手間が増えるので、そこでASA/AnyConnect端末や 経路機器で処理遅延が増えて低速化するのが主因かと思います。

 

VPN系は DTLS/TLSのAnyConnect終端しかASAで使ってない場合は、ハイエンドの場合は深く考えずに"crypto engine accelerator-bias ssl"を有効化して使うようにしてますが(暗号処理時におけるASA内部のボトルネックが減るので それでASA全体のパフォーマンが上がったと嬉しい報告も多数うけてます)、TLSが遅い理由は「暗号処理」""の所が主因だと思うので、その場合は高速化はあまり期待できないのではと思います。。たぶん。

athirano1
Level 1
Level 1

Akira Muranakaさん

こんにちは。回答ありがとうございます!

1.本番環境にあるASA5545Xについては、今度のメンテナンス作業時に
crypto engine accelerator-bias ssl コマンドを入れてパフォーマンス改善を図ります!

2.AnyConnectにTLSで接続したときに通信速度が低下する件ですが、
検証機(ASA5506X)でクライアント接続数が1の状態で試しても通信速度が低下するので、crypto engine accelerator-bias ssl による改善とは関係のない話となりそうです。
DTLS接続時と比べてTLS接続時は、クライアントPCからみて、
・ダウンロード方向の通信が極端に遅くなります(DTLSの方が動きが軽いとはいえ差が大きすぎる気がします)
・アップロード方向の通信は特に影響は受けません

最初の書き込みでクライアントPCでのパケットキャプチャについて記載しましたが、他の調べ方が無いかと考えて、show asp dropコマンドで確認してみました。
カウンタ値の中で
「SVC Module is in flow control (mp-svc-flow-control)」が
ダウンロード通信の時にどんどんカウントアップしました。これが関係ありそうです。

-------------------
# show asp drop
Frame drop:
SVC Module is in flow control (mp-svc-flow-control) 4598 ←コレ
No route to host (no-route) 5
Flow is denied by configured rule (acl-drop) 21
First TCP packet not SYN (tcp-not-syn) 15
TCP failed 3 way handshake (tcp-3whs-failed) 1
TCP SEQ in SYN/SYNACK invalid (tcp-seq-syn-diff) 4
Early security checks failed (security-failed) 16

Last clearing: ~

Flow drop:
Flow is denied by access rule (acl-drop) 56

Last clearing: ~
#
------------------------
capture [名前] type asp-drop コマンドでも調べてみましたが
34: 17:43:56.299728 [送信先IP].443 > [送信元IP].61349: P 1013273471:1013273608(137) ack 2092040983 win 30240 Drop-reason: (mp-svc-flow-control) SVC Module is in flow control
と表示されるだけで、新しい情報は得られませんでした
------------------------

SVCモジュールから見た時に、流れ込むデータ量が多すぎるのでドロップが発生した ということのようです。
ということで、次の一手を思案中です。。