- 最終編集日: 、編集者:
JapanTAC_CSC
- はじめに
- ASA データシート
- 主なボトルネック箇所と対策例
- パフォーマンス最適化のためのベストプラクティス
- スプリットトンネルの利用
- 1. 社内宛の通信のみトンネリング (Split Tunneling)
- 2. 特定ドメイン宛の通信のみトンネリング除外 (Dynamic Split Tunneling)
- 3. 端末のセキュリティ対策
- DTLSの利用
- 適切なMTUの利用
- 不要な機能や設定の削減
- 回線や経路の速度と品質
- 通信量の多いユーザの確認や切断
- 1. 通信量の多いAnyConnectセッションの確認
- 2. 通信量の多いコネクションとユーザの確認
- AnyConnect 最大接続可能数の変更
- ASAvのパフォーマンス最適化
- 1. 高性能な新しめのサーバにASAvをデプロイ
- 2. ASAバージョン 9.12以降と AnyConnect 4.7以降を利用
- 3. ASAv10のパフォーマンス比較例
- 4. ASAvのスループット上限
- 5. ASAvのネットワークアダプタ
- ハイエンドモデルのパフォーマンス最適化
- 構成変更
- 1. 上位モデルにアップグレード
- 2. 複数ASAの運用と サーバリスト機能の利用
- 3. 複数ASAの運用と VPNロードバランシング機能の利用
- 4. 構成変更例の比較
- トラブルシューティング
- CPU使用状況の確認
- ケーススタディ１： 通信量や接続量が多く過負荷の場合
- ケーススタディ２： CP機能の過剰利用による過負荷の場合
- VPNセッション数の確認
- トラフィック量と平均パケットサイズの確認
- 暗号処理エンジンの負荷確認 (ハイエンドモデルのみ)
- よくある質問
- AnyConnectソフトウェアのダウンロード方法を教えてください
- AnyConnectを利用したいが、手持ちのASAは 2つしかVPN終端できません
- 購入しているAnyConnectライセンス ユーザ数以上 接続すると切断されますか
- 各モデルの最大接続可能数を超える接続は可能ですか
- 多数の同時接続が発生し、アドレスプールの割当IPが不足した場合 どうなりますか
- show vpn-sessiondb detail コマンドで確認できる Parent-Tunnel とはなんでしょうか
- AnyConnectの終端に FTDも利用可能ですか
- AnyConnect端末のVPN速度を上げるにはどうすればよいですか
- AnyConnect端末のスループットが 最大100Mbps程度しか出ません
- AnyConnectの Compression機能の利用でパフォーマンスは向上しますか
- ASAv以外でもDTLSv1.2利用でパフォーマンスは向上しますか
- AnyConnectの自動調整されたMTUの確認方法を教えてください
- ASAのVPNスループットがデータシート通りに出ません
- AnyConnectの各セッションのQoSは可能ですか
- ASAでリモートアクセスVPN利用のための構成や設定例があれば教えてください
- パフォーマンス最適化のため推奨のAnyConnectバージョンはありますか
- 参考情報
はじめに
テレワークの推進に伴い、リモートアクセスVPN (RA VPN) の需要は増す一方です。しかし、リモートアクセスVPNの利用者の急増に伴い、そのアクセスを終端するリモートアクセスVPNサーバである、Cisco Adaptive Security Appliance (ASA) や Firepower Threat Defense (FTD) にアクセスが集中し、ASA や FTD の パフォーマンス低下に悩まされるケースも少なくありません。
本ドキュメントでは、ASA のリモートアクセスVPNのパフォーマンスを向上/最適化するためのベストプラクティスや、構成変更例、パフォーマンス低下トラブル時に確認すべきログなどについて紹介します。リモートアクセスVPN用の端末側のソフトウェアは、AnyConnect の利用を前提としております。
なお、本ドキュメントの情報は、一定以上のネットワークや製品の取扱い経験のある方向けに作成しております。本ドキュメントの情報は、ユーザー様ご自身の判断と責任において利用してください。なお、設定や構成変更は、事前に検証をしての、メンテナンスタイムや 通信影響の少ない時間帯に実施をお勧めします。
パフォーマンス最適化について具体的な設計や設定/導入支援が必要の場合は、弊社の 最適化サービス や、Cisco製品販売代理店様の最適化支援サービスなどのご利用を検討ください。 Cisco認定パートナーを探すには、購入案内 をご確認ください。
ASA データシート
VPNスループットや AnyConnect VPN ユーザセッション最大数はデータシートで確認できます。AnyConnect接続時の DTLSのスループットも、VPNスループットに近い処理性能を期待できます。なお、データシートの記載値は、テスト環境での最小限の設定でテスト時のデータがベースであることに注意してください。利用機能や設定、処理数、通信内容などにより最終的なパフォーマンスは変動します。
Cisco ASA 5500 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/asa-firepower-services/datasheet-c78-742475.html
Cisco ASA 5585-X Stateful Firewall Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/datasheet-c78-730903.html
Cisco ASA with FirePOWER Services Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/datasheet-c78-733916.html
Cisco Adaptive Security Virtual Appliance (ASAv) Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/adaptive-security-virtual-appliance-asav/datasheet-c78-733399.html
Cisco Firepower 1000 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-1000-series/datasheet-c78-742469.html
Cisco Firepower 2100 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-2100-series/datasheet-c78-742473.html
Cisco Firepower 4100 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-4100-series/datas
Cisco Firepower 9300 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-9000-series/datasheet-c78-742471.html
主なボトルネック箇所と対策例
ASAのリモートアクセスVPNのパフォーマンスは様々な要素の影響を受けます。以下は 主なボトルネック箇所と その対策例です。
| ボトルネック箇所 | 説明 | 対策例 |
| スループット |
通信量が多いほど、その通信の処理のため、ASAの負荷はあがります。 そのため、いかに通信量を下げるかが、パフォーマンスを保つうえで重要です。 通信効率の良いDTLSを利用することで スループット向上を期待できます |
|
| セッション数 | 各モデルには ハードコードの最大接続可能数があり、上限を超えてのAnyConnect接続はできません。また、新規AnyConnect接続のレートが高い場合、セッション確立処理負荷の上昇も伴います |
|
| 利用機能や設定 | 一般的に機能や設定を使うほど少しずつパフォーマンスは低下します。リモートアクセスVPN終端のパフォーマンスを最大化するのに最も良い対応は、ASAをリモートアクセスVPN終端専用機にすることです |
|
| モデル別の最適化 | ASAｖ 仮想Firewallは、導入しているサーバ性能でパフォーマンスが変わります。ASA5585やFPR4100などハイエンドモデルの場合、エンジンのSSL処理の最適化が可能です |
|
パフォーマンス最適化のためのベストプラクティス
スプリットトンネルの利用
AnyConnectはデフォルトで全てのトラフィックをトンネリングします。インターネット宛通信もトンネリングされるため、社内のProxy経由でWebサイトにアクセスする場合、リモートアクセスVPNやWebサイトアクセス速度の両方のパフォーマンス低下の原因となります。
端末とASAのパフォーマンスを最大化する 最もシンプルかつ効果的な方法の1つが、"本当に必要なトラフィックのみトンネリング"することです。当対応により、AnyConnect端末とASA間のトラフィックの削減を期待でき、端末とASA 双方のパフォーマンス向上を期待できます。
本項では、特定宛先の通信を Split (分割) する技術である スプリットトンネルの活用例と、当機能を利用時の端末のセキュリティ対策について紹介します。
1. 社内宛の通信のみトンネリング (Split Tunneling)
インターネット宛の通信はクライアントから直接アクセスさせ、社内宛の通信のみトンネリングすることで、クライアントと ASA両方のパフォーマンス向上を期待できます。対象のIPアドレスやセグメントを予め明示指定するため、Static Split Tunneling とも呼ばれます。
社内宛の通信のみトンネリングする設定例は以下ドキュメントを参照してください。
2. 特定ドメイン宛の通信のみトンネリング除外 (Dynamic Split Tunneling)
全通信をトンネリングしつつも、Office 365や Webex、Salesforce などクラウドアプリケーションや、指定ドメインや FQDN宛の通信のみ インターネットにダイレクトアクセスしたいケースもあるかと思います。当ケースの場合、かつ、AnyConnect 4.5以降を利用時は、Dynamic Split Tunneling 機能を用いて、指定のドメインのみ トンネリング対象から除外することも可能です。 Dynamic Split Tunnelingの設定例や動作確認例は以下ドキュメントを参照してください。
なお、Dynamic Split Tunnelingで設定可能なドメイン/FQDNの文字数は 最大5000文字までになり、標準的なドメインだと300個程度が目安となります。それ以上のドメイン/FQDNの設定/制御を行いたい場合は、Dynamic Split Tunnelingではなく、Static Split Tunneling と Umbrellaの併用を検討してください。
3. 端末のセキュリティ対策
クラウド利用などインターネットアクセスの多い業務の場合、スプリットトンネルを効果的に活用することで、必要なトラフィックのみトンネル化し、端末とASAのパフォーマンスを大きく上げることができます。しかし、端末からのインターネットダイレクトアクセスは、端末が直接 脅威にさらされることになります。
端末のセキュリティ保護のため、AnyConnectは以下の追加モジュールを利用可能です。
- Cisco Umbrella ・・・ DNS Web セキュリティ。悪意あるURLや 任意URLやアプリケーションのフィルタリングなど
- Cisco AMP ・・・・・ 先進的なマルウェア保護。機械学習や統合管理、感染経路可視化にも対応
以下は、Umbrella Dashboardからの、YouTubeアプリケーションのアクセス制御の実施例です。
以下は、Umbrella Dashboardからの、YouTubeドメインのアクセス制御の実施例です。
各モジュールの詳細や導入方法などについては、シスコ製品販売代理店様や シスコアカウントチームまでご相談ください。
Ciscoのテレワークソリューションや、各機能について より詳しくは、以下ガイドなどを参照してください。
DTLSの利用
AnyConnectクライアントのASA接続は以下段階で進みます。
- SSL(TCP443) (※) を利用しASAに接続し証明書や認証、プロファイル情報など交換し セッション確立
- SSL(※)でデータ転送をしつつ、UDP443が利用可能な場合は UDP443を利用したDTLS tunnelでのデータ転送に自動切り替えを行う
- UDP443が利用できない場合は、TCP443を利用したSSL Tunnel (TLS) でデータ転送を継続する
※実際はSSLの代わりに よりセキュアなTLSが利用されていますが、CLI表示上はSSL
UDP443が利用可能な場合にDTLS利用に切り替える理由ですが、UDPはオーバーヘッドの少ない高速なプロトコルのため、データ転送効率化を期待できるためです。AnyConnectクライアントは、UDP443が利用可能な場合は 積極的にDTLS Tunnelでデータ転送を試みます。
TCPベースのTLSによるデータ転送の場合、シーケンスや順番制御などTCP特有の処理が発生し、特に低品質や混雑したネットワークの場合 パケットドロップや順番変更などによる再送や遅延も発生し、これらがパフォーマンスを下げる要因となります。通信環境によっては、TLS利用時のパフォーマンスは、DTLS利用時の半分以下になることもあります。
DTLSによるAnyConnect接続を行いたい場合、経路で SSL(TCP443)とDTLS(UDP443)の両方の通過が許可されている必要があります。例えば在宅勤務者がリモート接続する場合、その在宅者の家のルータで、TCP443のみでなく UDP443が許可されているか確認してください。
接続方式やDTLSでのデータ交換状況は、show vpn-sessiondb detail anyconnect コマンドで確認可能です。以下例の場合、AnyConnectクライアント 1.176.100.101は DTLSv1.2で接続され 暗号化はAES-GCM-256で行われ、400Mbytesほどの送信(Tx)と 6Mbytesほどの受信(Rx)があることがわかります。
ciscoasa(config)# show vpn-sessiondb detail anyconnect
--- 略 ---
DTLS-Tunnel:
Tunnel ID : 10.3
Assigned IP : 1.176.100.101 Public IP : 100.0.0.1
Encryption : AES-GCM-256 Hashing : SHA384
Ciphersuite : ECDHE-ECDSA-AES256-GCM-SHA384
Encapsulation: DTLSv1.2 UDP Src Port : 62389
UDP Dst Port : 443 Auth Mode : userPassword
Idle Time Out: 30 Minutes Idle TO Left : 30 Minutes
Client OS : Windows
Client Type : DTLS VPN Client
Client Ver : Cisco AnyConnect VPN Agent for Windows 4.7.04056
Bytes Tx : 392005089 Bytes Rx : 5888313
Pkts Tx : 283106 Pkts Rx : 142874
Pkts Tx Drop : 0 Pkts Rx Drop : 0
DTLSとTLSの利用状況は show vpn-sessiondb detail コマンドで確認できます。以下例の場合、DTLS(=DTLS-Tunnel)を利用するクライアントが1台、TLS (=SSL-Tunnel) を利用するクライアントが1台、合計 2台の AnyConnectクライアントが接続していることがわかります。DTLSを利用するクライアントは バックアップ用に SSLトンネルも保持してるため、SSL-Tunnel にはDTLSを利用するクライアントの数も含まれていることに注意してください。 AnyConnect-Parent は特殊なトンネルで、管理やバックアップ用などに利用されます。
ASA5555# show vpn-session detail
---------------------------------------------------------------------------
VPN Session Summary
---------------------------------------------------------------------------
Active : Cumulative : Peak Concur : Inactive
----------------------------------------------
AnyConnect Client : 2 : 8 : 2 : 0
SSL/TLS/DTLS : 2 : 8 : 2 : 0
Clientless VPN : 0 : 3 : 2
Browser : 0 : 3 : 2
---------------------------------------------------------------------------
Total Active and Inactive : 2 Total Cumulative : 11
Device Total VPN Capacity : 5000
Device Load : 0%
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Tunnels Summary
---------------------------------------------------------------------------
Active : Cumulative : Peak Concurrent
----------------------------------------------
Clientless : 0 : 3 : 2
AnyConnect-Parent : 2 : 8 : 2
SSL-Tunnel : 2 : 8 : 2
DTLS-Tunnel : 1 : 7 : 1
---------------------------------------------------------------------------
Totals : 5 : 26
---------------------------------------------------------------------------
AnyConnect端末側で、接続にDTLS/TLSどちらを利用しているかは、Advanced Window の Statisticsタブから確認できます。 端末が TLSで接続している場合、その端末とASA間の経路のどこかで UDP 443 がブロックされてる可能性があります。
[データ転送で DTLS (UDP443) 利用時]
[データ転送で TLS (TCP443) 利用時]
なお、特に大企業やISPなど多数ユーザがリモートアクセスする環境の場合、一部のエンドユーザの通信環境ではUDP443が許可されていないケース (もしくは UDPを許可し忘れているケース)もあり、DTLSとTLS接続が混在している事も珍しくありません。 全ての接続を DTLS接続のみにすることは困難ですが、DTLSの接続割合を増やすことでパフォーマンス向上を期待できます。
適切なMTUの利用
基本的にパケットサイズが大きいほど、一度に送信できるデータ量が増えるため、良いパフォーマンを得やすくなります。また、通常 1度に送付できるデータ量が多きいほど 交換に必要なパケット数が減るため、各パケットの暗号や解読回数が減り ASAのパフォーマンスも良くなります。しかし、パケットサイズが経路のMTUを上回ると フラグメント(パケット分割)やリアセンブル(パケット再構築)の手間が発生し パフォーマンスが劣化しやすくなります。そのため、ギリギリ分割されないパケットサイズの利用が高パフォーマンスを得やすくなります。
DTLSを利用時、AnyConnect端末間のMTUは自動チューニングされるため、通常 個別のカスタマイズは不要です。DTLSのカプセル化や暗号化のオーバーヘッドは最大94bytes のため、利用するNICのMTUから 94bytes引いた値をAnyConnect端末は利用し、かつ経路のMTUも問題ないか自動チェックや 必要に応じて更にMTUを下げる自動チューニングが行われます。例えば、端末の物理アダプタのMTUが1300の場合、AnyConnectは (1300 - 94) の MTU 1206 をまずは利用しようとし、仮にMTU1206で経路でフラグメントが検知される場合は さらに低いMTUが使われるよう自動調整されます。
TLSを利用時も、MTUの自動チューニングに対応しています。なお、DTLSで接続ができずTLSにフォールバックした場合、AnyConnect MTUによっては DTLS→TLS切り替え時にリコネクト処理が発生することがあります。TLSにフォールバック時の Reconnectを極力避けたい場合は、AnyConnect の MTU について の、「3-1. 接続して約1分後に Reconnect が発生する」や 「1．AnyConnect MTU の基本設定」を参考に、適宜AnyConnect MTUを手動調整するのが有効です。しかし、Reconnectを避けるためAnyConnect MTUを低く設定しすぎると、その分 一回の通信で転送できるパケット最大サイズが小さくなることによるパフォーマンス低下の原因となるため注意してください。
AnyConnect接続は IKEv2にも対応してますが、IKEv2をAnyConnect接続で利用時の場合、MTUの自動チューニングに対応してないため、手動設定が必要となることに注意してください。また、基本的にDTLSを利用したAnyConnect接続を、シスコではお勧めしています。
AnyConnectのMTUと、そのチューニング方法について詳しくは、以下ドキュメントを参照してください。
不要な機能や設定の削減
多くのASA機能はソフトウェア処理のため、利用機能や設定量、その利用頻度(=AnyConnectセッションやコネクション数)が増えるほど、少しずつパフォーマンスは低下します。
例えば、ASAを リモートアクセスVPN終端のみでなく、社内通信のインターネットアクセス用のPAT/Firewall装置として兼用している場合、そのNATやFirewall処理にもASAパフォーマンスが利用されるため、リモートアクセスVPN処理のためのパフォーマンス余力が減ります。逆に、ASAをリモートアクセスVPN終端専用機として利用すると、ASAのリモートアクセスVPN処理のパフォーマンスを最大化することができます。
例えば、AnyConnectのアクセス制御にVPN Filterを利用時は、ACLの設定行が多いほど 接続毎のACLの検査負荷があがります。例えば、「可能な限りIP単位の制御はせず セグメント単位で制御する」「宛先ポートの制御は極力しない」など実施しACL設定量を減らすことで、ACL検査負荷を下げることができます。もしくは、ASAでのアクセス制御はしないか最低限にし、払い出されたIPアドレスに対して 経路上の別の機器(スイッチやルータなど)でACLアクセス制御を行うことで、ASAの処理負荷低減が可能です。
例えば、Dynamic Access Policy (DAP) の利用している場合は、レコード数を多くとも20～30内などにするなど 少なくすること(=複雑にしすぎないこと)で、DAP設定によるパフォーマンス減や トラブル防止に役立ちます。
例えば、Syslog機能を多用している環境の場合、膨大なログを出力するSyslog設定が、Syslog生成処理によるパフォーマンス低下や、Syslogメッセージによる帯域圧迫につながるケースもあります。ロギングを適切なレベルに設定することで、ロギング負荷を下げることができます。 ロギングのチューニング例について詳しくは以下ドキュメントを参照してください。
ACLや DAPなど通信制御機能や、Syslogなど管理機能の処理負荷 1つ1つは小さいです。しかし、特にテレワークによる利用者数の急増に伴い 接続量が急激に増えると、それに伴い 各接続毎にACLやDAPなど制御の膨大な実施や、膨大な通信量のロギングなどが発生すると、その負荷は乗算的に増え、無視できない負荷量になることがあります。 特に多数の接続を収容が必要で パフォーマンス余力があまりない場合は、機器や設定はシンプルに、他の機器でも代用できる機能や設定は 他の機器で実施するなどし、ASAはリモートアクセスVPN接続処理に集中できるよう最適化することで、パフォーマンス余力を上げることができます。
回線や経路の速度と品質
VPNパフォーマンスが出ない理由に、AnyConect端末と ASA終端装置間の通信経路上の機器や回線の、最大速度と品質がボトルネックとなっている事があります。例えば、VPN処理性能が 1GbpsのASAを利用しても、通信経路の回線の最大速度が500Mbps程度の場合、ASAも最大500Mbps程度までしか処理できません。また、回線や経路装置の処理混雑などの影響による遅延やドロップも、パケット再送や通信失敗の原因となり、大きなパフォーマンス低下の原因となることもあります。
回線業者(ISP)や集合住宅設備によっては、UDP443(=DTLS)の通過を拒否していたり、TCPやUDPの速度制限をかけているケースがあり、その結果、パフォーマンスの良いDTLSの利用不可や、想定の速度が得れない結果につながる事があります。
回線や経路機器がボトルネックとなっている場合は、その改善には、速度や品質に優れる回線や設備に切り替えが必要です。
在宅勤務者の自宅回線や通信経路がボトルネックになってるかの簡単な切り分けは、AnyConnectの接続を 自宅回線から、スマートフォンのテザリング経由や 公衆WLANなどの、別の回線・設備経由に切り替え、速度や品質が改善するか確認することです。
通信量の多いユーザの確認や切断
トラフィック量の多いセッションがないか確認し、明らかに過剰な利用のあり全体のパフォーマンスを落とす場合は、トラフィック量の多い利用者に 利用を控えるよう促したり、強制切断も可能です。
1. 通信量の多いAnyConnectセッションの確認
ユーザー名ごとのトラフィック量や接続時間の確認は "show vpn-sessiondb anyconnect | in Username|Bytes|Duration"コマンドの実施が便利です。以下出力例の場合、中村(nakamura)さんは 接続時間が10分ほどで 約5GB(≒5,156,556,220)のデータがASAから送信(Tx)されていること、ciscoさんは 接続時間が1分ほどで 約23MB(≒23,545,802)のデータをASAが受信(Rx)していることを確認できます。
ASAv10(config)# show vpn-sessiondb anyconnect | in Username|Bytes|Duration Username : nakamura Index : 35 Bytes Tx : 5156556220 Bytes Rx : 75519009 Duration : 0h:10m:31s Username : cisco Index : 36 Bytes Tx : 661625 Bytes Rx : 23545802 Duration : 0h:01m:08s ASAv10(config)#
指定ユーザ名のAnyConnectセッションの切断は "vpn-session logoff name <Username>"コマンドで可能です。以下出力例の場合、特に通信量が多い 中村さんを切断しています。
ASAv10(config)# vpn-session logoff name nakamura Do you want to logoff the VPN session(s)? [confirm] INFO: Number of sessions with name "nakamura" logged off : 1
以下は手動切断時のログ抜粋です。なお、切断ログからも送信(xmt)や受信(rcv)のバイト数を確認できます。
Apr 02 2020 13:00:57: %ASA-4-722037: Group <GroupPolicy_AnyConnect-01> User <nakamura> IP <100.0.0.2> SVC closing connection: Administrator Reset. Apr 02 2020 13:00:57: %ASA-6-716002: Group <GroupPolicy_AnyConnect-01> User <nakamura> IP <100.0.0.2> WebVPN session terminated: Administrator Reset. Apr 02 2020 13:00:57: %ASA-4-113019: Group = AnyConnect-01, Username = nakamura, IP = 100.0.0.2, Session disconnected. Session Type: AnyConnect-Parent, Duration: 0h:13m:10s, Bytes xmt: 5306488447, Bytes rcv: 77713985, Reason: Administrator Reset
切断されると、AnyConnect端末側では「The secure gateway has terminated the VPN connection. The following message was received from the secure gateway: Administrator Reset」の切断理由のポップアップします。
なお、切断しても、AnyConnectクライアントはASAに再接続が可能です。そのユーザからの接続を常に拒否したい場合は、そのユーザアカウントの削除や停止などの追加対応が必要となります。
ASDMを利用時の場合は、Monitoring > VPN > VPN Statistics > Sessions から 利用ユーザと通信状態や、指定ユーザの切断(Logout) 操作が可能です。
2. 通信量の多いコネクションとユーザの確認
トラフィック量の多いコネクションを確認したい場合は、以下のドキュメントを参考にしてください。
例えば以下は、トラフィック量が 100Mバイト以上 1Tバイト未満のコネクションの確認例です。1.176.100.101から 1.0.0.1宛に、約500MB (≒532,227,750bytes) ほどの通信が発生中であることを確認できます。
ASAv10(config)# show conn long | in (bytes .........,)|(bytes ..........,)|(bytes ...........,)|(bytes ............,) TCP outside: 1.176.100.101/12056 (1.176.100.101/12056) dmz: 1.0.0.1/10355 (1.0.0.1/10355), flags UxOB , idle 0s, uptime 1m1s, timeout 1h0m, bytes 532227750, xlate id 0x7f12b410c980
アサインされたIPアドレスからユーザー名を探すのは、"show vpn-sessiondb anyconnect filter a-ipaddress <IP Address>"コマンドで可能です。 以下例の場合、通信発生元は 中村さんであり、ASAから総送信バイト数(Tx)は 2.1GBほどであることを確認できます。
ASAv10(config)# show vpn-sessiondb anyconnect filter a-ipaddress 1.176.100.101 Session Type: AnyConnect Username : nakamura Index : 38 Assigned IP : 1.176.100.101 Public IP : 100.0.0.1 Protocol : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel License : AnyConnect Premium Encryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)AES-GCM-256 DTLS-Tunnel: (1)AES256 Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA384 DTLS-Tunnel: (1)SHA1 Bytes Tx : 2159997739 Bytes Rx : 31630830 Group Policy : GroupPolicy_AnyConnect-01 Tunnel Group : AnyConnect-01 Login Time : 13:22:29 UTC Thu Apr 2 2020 Duration : 0h:06m:15s Inactivity : 0h:00m:00s VLAN Mapping : N/A VLAN : none Audt Sess ID : 019600a9000260005e85e715 Security Grp : none
AnyConnect 最大接続可能数の変更
ASAはデフォルトで許可されている最大接続数まで RA VPN接続を受け入れます。しかし、アクセス数が集中し全台が同時に通信したり、一部端末でバースト的なトラフィックが発生すると、全体の1台あたりの利用できるスループットが落ち、ご利用のアプリケーションにもよりますが、業務上 実用に耐えれないスループットとなることもあります。また、同時コネクション数や新規接続レートが高いほど、その管理や処理でもASAの負荷が上昇します。
以下のコマンドで最大接続数を下げることで、接続と通信集中による全体のパフォーマンス低下リスクを抑えることができます。
vpn-sessiondb max-anyconnect-premium-or-essentials-limit [number]
ASDMの場合、以下メニューから AnyConnectの最大セッション数を設定可能です。
Configuration > Remote Access VPN > Advanced > Maximum VPN Sessions
例えばVPNスループット 1Gbpsの製品で、机上で 1台あたり10Mbps程度の通信速度を確保したい場合は、最大接続数を100までにすることで、1台あたりのスループットを確保できます。(ただ実際は、各端末の全員が同時通信するわけではないため、最大接続数はさらに多めで考えてもよいです。)
なお、最大接続可能数を越えた接続は、以下のシスログ出力を伴い拒否されます。 切断されたAnyConnect利用者は、手動で別のリモートアクセスVPNサーバに接続の切り替えが必要です。
Mar 31 2020 13:31:38: %ASA-6-113012: AAA user authentication Successful : local database : user = cisco Mar 31 2020 13:31:38: %ASA-6-113009: AAA retrieved default group policy (GroupPolicy_AnyConnect-01) for user = cisco Mar 31 2020 13:31:38: %ASA-6-113008: AAA transaction status ACCEPT : user = cisco Mar 31 2020 13:31:38: %ASA-4-113029: Group <GroupPolicy_AnyConnect-01> User <cisco> IP <100.0.0.1> Session could not be established: session limit of 1 reached. Mar 31 2020 13:31:38: %ASA-4-113038: Group <GroupPolicy_AnyConnect-01> User <cisco> IP <100.0.0.1> Unable to create AnyConnect parent session.
また、上記の具体的な接続数制限は行わず、まずは SNMPポーリングでVPN接続数の監視を行い、任意の閾値を越えたら ユーザ接続状況の確認や適宜チューニング、増設判断などの対応を検討するのも、有効な運用の１つです。 VPN接続数の SNMPポーリングによる監視方法について詳しくは、ASA/AnyConnect: VPNセッション数の確認と SNMPモニタリング方法 を参照してください。
VPNセッション数のコマンドラインでの確認方法や 評価方法についてより詳しくは、本ドキュメント内の トラブルシューティング - VPNセッション数の確認 も、合わせご確認ください。
ASAvのパフォーマンス最適化
ASAvは仮想アプライアンスであり、ESXiや KVM、AWS、Hyper-vなど仮想基盤の上にデプロイし利用することができます。以下に ASAvのパフォーマンス最適化のためのベストプラクティスと 確認例を紹介します。
1. 高性能な新しめのサーバにASAvをデプロイ
ASAvのVPNパフォーマンスは、利用するCPUコアのClockや DRAM処理速度などの影響を受けます。そのため、性能の高い and/or 新しい世代のIntel CPUや、パフォーマンスの良いメモリや NICを搭載した高性能サーバにASAvをデプロイすることで、ASAvの VPNパフォーマンスを高めることが可能です。
2. ASAバージョン 9.12以降と AnyConnect 4.7以降を利用
AnyConnect 4.7と ASA 9.10 以降で DTLSv1.2が利用可能になりました。なお、ASA9.10は既にEoLがアナウンスされてるため、後継の安定バージョンである9.12やそれ以降の 2桁目が偶数トレインの利用が推奨されます。AnyConnectは最新バージョンの利用が推奨されます。DTLSv1.2は 暗号方式にデフォルトでAES-GCMを利用し、利用CPUによってはAES-GCMの高速処理に対応しており、パフォーマンス向上を期待できます。
3. ASAv10のパフォーマンス比較例
以下は、検証環境での ASAv10のデプロイ先サーバ別の、DTLSv1.0と DTLSv1.2を利用時のパフォーマンス比較です。なお、ASAv10のデータシート上のVPNスループットは 150Mbps です。
以下の試験結果から、CPU世代が新しい場合 (v3は3世代目)、もしくは、CPUコアの周波数が高い場合は、高いパフォーマンスを得やすいことを確認できます。 なお、以下は簡易的な環境・設定での試験結果であり、スループットは設定や機能、環境などによっても変動するまで、あくまで参考レベルで利用ください。
| バージョン | 利用サーバと CPU |
トンネル プロトコル |
暗号方式 | ダウンロード速度 (実測) | ASA CPU 使用率 |
| AnyConnect 4.7 ASAv10 9.12(3)9 |
C240-M4 E5-2683v3 @2.0GHz |
DTLSv1.2 | AES-GCM-256 (デフォルト) |
77Mbps | 22 % |
| AnyConnect 4.6 ASAv10 9.12(3)9 |
C240-M4 E5-2683v3 @2.0GHz |
DTLSv1.0 | AES256 (デフォルト) |
70Mbpos | 31 % |
| AnyConnect 4.7 ASAv10 9.12(3)9 |
C240-M3 E5-2650 @2.0GHz |
DTLSv1.2 | AES-GCM-256 (デフォルト) |
81Mbps | 30 % |
| AnyConnect 4.6 ASAv10 9.12(3)9 |
C240-M3 E5-2650 @2.0GHz |
DTLSv1.0 | AES256 (デフォルト) |
77Mbps | 32 % |
| AnyConnect 4.7 ASAv10 9.12(3)9 |
C240-M3 E5-2680 @2.8GHz |
DTLSv1.2 | AES-GCM-256 (デフォルト) |
80Mbps | 21 % |
| AnyConnect 4.6 ASAv10 9.12(3)9 |
C240-M3 E5-2680 @2.8GHz |
DTLSv1.0 | AES256 (デフォルト) |
77Mbps | 27 % |
試験方法：
- AnyConnect端末と ASAv10間で、DTLSセッションを１つ貼り、FTPサーバから大容量ファイルのダウンロード
- 平均パケットサイズは1,000バイトほど。AnyConnect MTUは 1390バイト
- DTLSv1.2の接続試験は、AnyConnect バージョン 4.7 と、ASAv 9.12(3)9 を利用。デフォルトでDTLSv1.2で自動接続し、暗号方式は AES-GCM-256 が自動使用される
- DTLSv1.2の接続試験は、AnyConnect バージョンを 4.6にさげて実施。 AnyConnect 4.6は DTLSv1.2に対応してないため、トンネルプロトコルは DTLSv1.0に代わる。 DTLSv1.0の場合、暗号方式は AES256 が自動使用される
- 本試験において、AnyConnectのバージョン変更以外は、ASAvや 端末の設定や構成は変えていない
- AnyConnect接続設定は ASA でのスプリット トンネリングによる AnyConnect セキュア モビリティ クライアントの設定 を元に設定した、最もシンプルなリモートアクセスVPN接続設定。スプリットトンネルは未使用
4. ASAvのスループット上限
なお、高性能サーバを利用しても、ASAvは予め指定されたスループット以上のパフォーマンスは出ないことに注意してください。スループットの上限を超えた場合、若干の猶予をもって レートリミット (速度制限) が適用されます。
| モデル | vCPU/RAM | 最大スループット |
| ASAv5（100 M） | 1 vCPU / 1 GB | 100 Mbps |
| ASAv10（1 GB） | 1 vCPU / 2 GB | 1 Gbps |
| ASAv30（2 GB） | 4 vCPU / 8 GB | 2 Gbps |
| ASAv50（10 GB） | 8 vCPU / 16 GB | 10 Gbps |
5. ASAvのネットワークアダプタ
VMwareの場合、割り当てるネットワークアダプタの アダプタタイプが VMXNET3や IXGBE-VFの場合 良好なパフォーマンスを期待できます。利用してるネットワークアダプタは、仮想マシンの設定の編集から確認ができます。以下例の場合、VMXNET3を利用していることがわかります。
もしくは、show interface コマンドでも確認可能です。以下例の場合、E1000を利用していることがわかります。
ciscoasa# show interface m0/0 Interface Management0/0 "management", is up, line protocol is up Hardware is net_e1000_em, BW 1000 Mbps, DLY 1000 usec
| タイプ | 表示例 | 備考 |
| E1000 | net_e1000_em | 旧VMware デフォルト (非推奨) ASAv 9.2(1)以降でサポート |
| VMXnet3 | net_vmxnet3 | VMware デフォルト ASAv 9.9(2)以降でサポート (※利用時はLRO無効化を) |
| IXGBE-VF | net_ixgbe_vf | AWS デフォルト SR-IOVのサポートに必要 ASAv 9.8(1)以降でサポート |
| Virtio | net_virtio | KVM デフォルト ASAv 9.3(2.200)以降でサポート |
なお、VMware版で VMXnet3を利用する場合は、パフォーマンスの最適化のためには LROの無効化が必要です。VMware社のガイドか、ASAvの利用バージョンの設定ガイドを参照してください。以下はASAv 9.14を利用時の設定ガイドのURLとその抜粋です。
Disable LRO for VMware and VMXNET3 Large Receive Offload (LRO) is a technique for increasing inbound throughput of high-bandwidth network connections by reducing CPU overhead. It works by aggregating multiple incoming packets from a single stream into a larger buffer before they are passed higher up the networking stack, thus reducing the number of packets that have to be processed. However, LRO can lead to TCP perfomance problems where network packet delivery may not flow consistently and could be "bursty" in congested networks. Important VMware enables LRO by default to increase overall throughput. It is therefore a requirement to disable LRO for ASAv deployments on this platform.
ハイエンドモデルのパフォーマンス最適化
Note: ハイエンドモデルで AnyConnectの SSL接続を多用する場合は チューニングを検討してください
ASA5545/5555/5585や、FPR4100/9300シリーズ(※)などハイエンドモデルでは、専用の高速処理用の暗号処理エンジンを搭載しており、暗号処理エンジンの処理優先度を、IPsec もしくはSSL もしくは Balancedの何れかに変更が可能です。ASA5545/5555/5585は IPsecがデフォルト、FPR4100/9300シリーズは Balanced がデフォルト値です。
(※FPR4100シリーズの最新モデルである FPR4115/4125/4145と FPR9300モジュールのSM-40/48/56は 当チューニング機能に対応しておらず、サポート予定も御座いません。)
例えば、SSL利用が殆どの環境の場合、"crypto engine accelerator-bias ssl"コマンドを実行することで、暗号処理エンジン内のコアが SSL処理優先の割当に切り替わり、AnyConnectのSSL接続時のパフォーマンスを最大化できます。
例えば、SSLと IPsecの処理負荷が同程度の環境の場合は、"crypto engine accelerator-bias balanced"コマンドを実行することで、暗号処理エンジン内のコアが IPsec処理と SSL処理用で半々となり、バランスよく両方の暗号処理が可能になります。
ご利用の環境で、SSLと IPsec どちらが多く利用されているかは、"show vpn-sessiondb detail" コマンドで確認できます。例えば、以下出力例の場合、全体のVPNセッションの中で、ほぼ100％をSSLが占めており、IKEv1やIPsecは極わずかのため、当利用状態が続く場合は、"crypto engine accelerator-bias ssl"コマンドでSSL処理を優先することが最適であることがわかります。
---------------------------------------------------------------------------
VPN Session Summary
---------------------------------------------------------------------------
Active : Cumulative : Peak Concur : Inactive
----------------------------------------------
AnyConnect Client : 2121 : 12111 : 3086 : 8
SSL/TLS/DTLS : 2121 : 12111 : 3086 : 8
Load Balancing(Encryption) : 1 : 50 : 2
---------------------------------------------------------------------------
Total Active and Inactive : 2130 Total Cumulative : 12151
Device Total VPN Capacity : 10000
Device Load : 21%
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Tunnels Summary
---------------------------------------------------------------------------
Active : Cumulative : Peak Concurrent
----------------------------------------------
IKEv1 : 1 : 10 : 2
IPsec : 1 : 3 : 2
AnyConnect-Parent : 2109 : 12111 : 3086
SSL-Tunnel : 2034 : 25859 : 3055
DTLS-Tunnel : 1496 : 13451 : 2279
---------------------------------------------------------------------------
Totals : 5651 : 51434
---------------------------------------------------------------------------
なお、"crypto engine accelerator-bias [IPsec|balanced|ssl]"コマンドの実行は 通信影響を伴う恐れがあるため、メンテナンス時間か、通信影響の少ない時間帯に実施してください。
コアの割当割合や処理状況は"show crypto accelerator load-balance"コマンドで確認できます。
例えば以下はASA5555でのコマンド実行と確認例です。デフォルトの IPsec優先の場合は コア利用割合が"IPSEC 5, SSL 3"であること、Balancedに変更後は"IPSEC 4, SSL 4"であること、SSLに変更後は"IPSEC 1, SSL 7"である事を確認できます。
ASA5555(config)# show crypto accelerator load-balance ssl
Crypto SSL Load Balancing Stats:
==================================
Engine Crypto Cores SSL Sessions Active Session
Distribution (%)
====== ============== =========================== ================
0 IPSEC 5, SSL 3 Total: 2422 Active: 3 100.0%
--- 略 ---
ASA5555(config)#
ASA5555(config)# crypto engine accelerator-bias ?
configure mode commands/options:
balanced Equally distribute crypto hardware resources
ipsec Allocate crypto hardware resources to favor IPsec/Encrypted Voice (SRTP)
ssl Allocate crypto hardware resources to favor SSL
ASA5555(config)#
ASA5555(config)# crypto engine accelerator-bias ssl
ASA5555(config)#
ASA5555(config)# show crypto accelerator load ssl
Crypto SSL Load Balancing Stats:
==================================
Engine Crypto Cores SSL Sessions Active Session
Distribution (%)
====== ============== =========================== ================
0 IPSEC 4, SSL 4 Total: 2423 Active: 2 100.0%
--- 略 ---
ASA5555(config)#
ASA5555(config)# crypto engine accelerator-bias ssl
ASA5555(config)#
ASA5555(config)# show crypto accelerator load ssl
Crypto SSL Load Balancing Stats:
==================================
Engine Crypto Cores SSL Sessions Active Session
Distribution (%)
====== ============== =========================== ================
0 IPSEC 1, SSL 7 Total: 2426 Active: 4 100.0%
以下は FPR4100シリーズの FPR4150でのコマンド実行と確認例です。FPR4150は暗号処理用のエンジンが２つあり、デフォルトの Balancedの場合は IPSEC 28 : SSL 28、SSL優先処理に切り替えた場合は IPSEC 4 : SSL 52 となることがわかります。 モデルにより暗号処理用のエンジンやコア数が異なり、割り当てられるコア数も異なります。
FPR4150(config)# show crypto accelerator load
Crypto IPSEC Load Balancing Stats:
==================================
Engine Crypto Cores IPSEC Sessions Active Session
Distribution (%)
====== ============== =========================== ================
0 IPSEC 28, SSL 28 Total: 0 Active: 0 0.0%
1 IPSEC 28, SSL 28 Total: 0 Active: 0 0.0%
----- 略 -----
FPR4150(config)#
FPR4150(config)# crypto engine accelerator-bias ssl
FPR4150(config)#
FPR4150(config)# show crypto accelerator load
Crypto IPSEC Load Balancing Stats:
==================================
Engine Crypto Cores IPSEC Sessions Active Session
Distribution (%)
====== ============== =========================== ================
0 IPSEC 4, SSL 52 Total: 0 Active: 0 0.0%
1 IPSEC 4, SSL 52 Total: 0 Active: 0 0.0%
構成変更
既存ASAで、スループットや同時接続数の増大などにより、最適化を実施しても パフォーマンスや処理能力が足りない場合、上位機器へのリプレースや ASA増設などの対応も必要となってきます。以下に構成変更による対応例を紹介します。
1. 上位モデルにアップグレード
既存機器から上位モデルにリプレース・設定を移行することで、設定や構成を大きく変えずに パフォーマンスや最大接続可能数の向上が可能です。最もシンプルで確実な方法です。
2. 複数ASAの運用と サーバリスト機能の利用
ASAを増設し、地域や人数などで接続先を分けることで、簡易的なActive/Active構成として各ASAを運用可能です。
例えば以下の構成のように、関東地区のユーザーは TOKYO-ASA-01を、東海地区のユーザは TOKYO-ASA-02を、関西地区のユーザは OSAKA-ASA を 各プライマリサーバとして利用し、他ASAをバックアップサーバとして指定することで、各ASAで負荷分散と、万が一障害時の冗長性を確保できます。各ASAには パブリックIPアドレスが必要です。
各ASAが独立して動作するため、ASA間の設定やステート同期は行われません。そのため、各ASAは個別管理が必要です。
特に、既に複数ASAをインターネットファイアウォールとして利用している環境の場合、各ASAにリモートアクセスVPNサーバ設定を行えば、比較的楽に当構成を利用できるのがメリットです。
バックアップサーバの指定は AnyConnect Client Profileを用いて可能です。詳しくは以下ドキュメントを参照してください。
3. 複数ASAの運用と VPNロードバランシング機能の利用
ASAを増設し、各ASAでVPNロードバランシングを組むことで、AnyConnect端末は 最も負荷の低いASAに自動接続が可能です。
VPNロードバランシングは以下の特徴があります。
- 2台から最大10台までのASAで組める、VPNアクセス専用の負荷分散用構成
- 異なるモデルも利用可。各機器で同じバージョン利用が推奨
- 1台がMaster機となり、他のBackup機のVPN接続状況を管理
- AnyConnectはまずMaster機の共有仮想IPアドレスに接続する。Master機は 負荷の少ないASAのパブリックIPアドレスを応答する
- 共有仮想IPアドレスと 各ASAのパブリックIPアドレスの、台数分＋１のパブリックIPアドレスが必要 。例えば、ASA 4台でVPNロードバランシングを組む場合、5つのパブリックIPアドレスが必要
- 各機器で設定やステートの同期は行われない
例えば、1台で最大500のVPN終端が可能なASA 2台で VPN Load Balancingを組んだ場合、最大 1000までの終端が可能になります。各機器でリモートアクセスVPN処理負荷が分散されるため、1台に接続が集中しボトルネックになることも回避できます。
なお、各機器で設定やステートの同期は行われないため、仮に1台のASAが故障時は、そのASAが終端していたリモートアクセスVPN接続は最初からやり直す必要があります。そのため、VPN load balancing は、ASAやパブリックIPアドレスに余裕があり、パフォーマンスや同時接続数を特に重視したい環境に向いてます。
VPNロードバランシングについて詳しくは利用バージョンの設定ガイドなどを参照してください。例えば以下は、ASAバージョン9.12の設定ガイド例です。
https://www.cisco.com/c/ja_jp/td/docs/security/asa/asa912/configuration/vpn/asa-912-vpn-config/asa-912-vpn-config_chapter_011.html#ID-2186-000003f0
VPNロードバランシングの機能や導入構成例は以下ドキュメントも参考にしてください。
https://www.cisco.com/c/en/us/td/docs/security/asa/misc/anyconnect-faq/anyconnect-faq.html#Cisco_Reference.dita_41edac65-48a1-4dec-ba68-edcd55629af3
4. 構成変更例の比較
各構成毎にメリット・デメリットが異なります。以下は その比較表です。
| 構成変更例 | 最小Public IPアドレス | 最大同時接続数 | 障害時 切り替え | 負荷分散 |
|
上位モデルに アップグレード |
１つ (既存機から流用) |
1台分のみ |
Failover機能利用時は、 セッション保護あり |
1台分のみ |
|
複数ASAと サーバリスト |
台数分必要 | 各台の総和 |
自動切り替え セッション保護なし |
手動 (端末側で接続先分散) |
|
複数ASAと VPNロードバランシング |
台数分 ＋ １つ* 必要 * 仮想IP用 |
各台の総和 |
自動切り替え セッション保護なし |
自動 (ASA側で接続先分散) |
トラブルシューティング
CPU使用状況の確認
CPU使用率はダイレクトにVPNパフォーマンスに影響を与えます。 CPU使用率は 暗号化や解読処理が増えるほど増加するため、VPNスループットが限界に近い場合、殆どの場合(※) 高いCPU使用率を確認できます。(※ハイエンドモデルの場合は、SSLとIPsecと利用状況に合わせて暗号エンジンの最適化を実施しないと、VPNスループットが低速化し、CPU使用率が期待通りに出ないことがあるので、ハイエンドモデル利用時は注意してください。)
また、同じVPNスループットを発生させても、利用する製品や機能、設定量、同時接続数、トラフィックパターン、利用バージョン、環境など様々な要素の影響を受けCPU使用率は変わります。
CPU使用状況と負荷を確認するのに特に有用なコマンドは以下3つです。なお、以下コマンドは show tech コマンドを取得した場合も含まれてます。
- show cpu usage
- show process cpu-usage non
- show cpu detail
当コマンドを利用してCPU高負荷問題のトラブルシューティング手法について詳しくは以下ドキュメントを参照してください。
CPU全体と各コアの負荷状況は SNMPポーリングで監視も可能です。 SNMPポーリングでの監視方法は 以下ドキュメントを参照してください。なお、各プロセス負荷やCP負荷など細かな確認はコマンドラインから確認する必要があります。
ケーススタディ１： 通信量や接続量が多く過負荷の場合
最も一般的な過負荷ケースです。
以下例の場合、CPU使用率が88%で明らかに過負荷な状態です。CPU 使用率 88%の内訳は、DATAPATHが各 44%と、他に Loggerや ARP、CP Processingなどの処理で僅かにCPU負荷が発生している事を確認できます。DATAPATHは、VPN (SSLやIPsec) や Firewall (ACL/NAT/Routing/Session管理など) などの 比較的 単純な処理をマルチコアで分散し高速で行うプロセスです。つまり、以下例の場合、VPN/Firewallの基本処理で88%のCPU使用があり、過負荷である事を確認できます。
ASA# show cpu usage CPU utilization for 5 seconds = 88%; 1 minute: 88%; 5 minutes: 82% ASA# show processes cpu-usage non-zero PC Thread 5Sec 1Min 5Min Process 0x00000000019da592 0x00007fffd808b040 0.0% 0.0% 0.5% Logger 0x0000000000844596 0x00007fffd807bd60 0.0% 0.0% 0.1% CP Processing 0x0000000000c0dc8c 0x00007fffd8074960 0.1% 0.1% 0.1% ARP Thread - - 43.8% 43.8% 40.3% DATAPATH-0-2209 - - 43.9% 43.8% 40.3% DATAPATH-1-2210
一般的に ASAのCPU使用率が80%以上の場合、通信ドロップや不安定化の原因となり、過負荷といえます。本ドキュメントのチューニングを実施しても、CPU高負荷の改善が難しい場合、機器のアップグレードや増設など構成変更の検討が必要です。上位機種ほど、通常 コア数やCPU数が増加し、より高性能な暗号処理エンジンを搭載しているため、多数コアのデータパスの分散処理によりパフォーマンスが向上します。
ケーススタディ２： CP機能の過剰利用による過負荷の場合
ASAのプロセスは、マルチコア分散処理に対応した VPN/Firewall処理に最適化されたDATAPATHの処理と、"それ以外の処理"(Failover管理や ロギング、SNMP、SSH/Telnet/Console、WebVPNの細かな制御など)に分かれます。 "それ以外の処理"は通常 Control Point (CP) 領域で処理されます。 Control Point の 処理能力は最大1コア分しかありません。なお、CP処理について詳しくは、ASA: show processes cpu-usage を用いた CPU負荷の調査 の "コントロールポイントとは"項を参照してください。
以下例の場合、CPU使用率は9%ですが、CPの処理能力がほぼ限界であり、CPがボトルネックとなり過負荷となっているケースです。show cpu detail コマンドの 括弧内の右の数値を足すことでCP負荷状況は確認でき、以下例の場合 24.4 + 22.6 + 21.0 + 24.8 で、CP負荷が 92%で過負荷である事を確認できます。もしくは、show process cpu-usage コマンドの DATAPATH以外のプロセス負荷の合計を コア数で乗算することでも 求められます。例えば、以下出力例の場合は、(5.3% + 0.2%) x 16 = 約88% のCP負荷である事が分かります。
以下例の場合、WebVPN関係の細かな制御を行う Unicorn Proxy Thread で CP処理能力の 85% (=5.3% x 16)ほど使っている事が分かり、ボトルネックとなっている事が分かります。CPが過負荷になると、CP機能である AnyConnectの接続管理の他、Failoverや VPNロードバランシング管理、SSH/Telnet/Console操作、ロギングやSNMP処理など、広範な機能の遅延や処理失敗、不安定化といった深刻な問題の原因につながります。
CP処理は、ASAの頭脳部にあたるため、ASAの安定性を高く保つには、CP負荷は低く抑えることが重要です。CP処理負荷は、高くとも 30～40%以下に抑えることをお勧めします。
ASA# show cpu usage CPU utilization for 5 seconds = 9%; 1 minute: 7%; 5 minutes: 6% ASA# show cpu detail Break down of per-core data path versus control point cpu usage: Core 5 sec 1 min 5 min Core 0 27.1 (2.6 + 24.4) 16.7 (2.6 + 14.1) 14.9 (2.5 + 12.5) Core 1 3.2 (3.2 + 0.0) 3.3 (3.3 + 0.0) 3.1 (3.1 + 0.0) Core 2 4.0 (4.0 + 0.0) 3.5 (3.5 + 0.0) 3.2 (3.2 + 0.0) Core 3 3.0 (3.0 + 0.0) 3.3 (3.3 + 0.0) 3.2 (3.2 + 0.0) Core 4 25.5 (2.8 + 22.6) 16.3 (2.7 + 13.6) 14.5 (2.5 + 12.0) Core 5 3.2 (3.2 + 0.0) 3.2 (3.2 + 0.0) 3.0 (3.0 + 0.0) Core 6 3.6 (3.6 + 0.0) 3.4 (3.4 + 0.0) 3.2 (3.2 + 0.0) Core 7 3.0 (3.0 + 0.0) 3.2 (3.2 + 0.0) 3.1 (3.1 + 0.0) Core 8 24.0 (3.0 + 21.0) 16.3 (2.7 + 13.6) 14.7 (2.6 + 12.2) Core 9 3.8 (3.8 + 0.0) 3.2 (3.2 + 0.0) 3.1 (3.1 + 0.0) Core 10 3.6 (3.6 + 0.0) 3.3 (3.3 + 0.0) 3.1 (3.1 + 0.0) Core 11 2.8 (2.8 + 0.0) 3.2 (3.2 + 0.0) 3.0 (3.0 + 0.0) Core 12 27.3 (2.4 + 24.8) 16.2 (2.5 + 13.7) 14.7 (2.5 + 12.3) Core 13 3.6 (3.6 + 0.0) 3.3 (3.3 + 0.0) 3.1 (3.1 + 0.0) Core 14 4.0 (4.0 + 0.0) 3.3 (3.3 + 0.0) 3.2 (3.2 + 0.0) Core 15 3.2 (3.2 + 0.0) 3.4 (3.4 + 0.0) 3.2 (3.2 + 0.0) ASA# show process cpu-usage sorted non-zero Hardware: ASA5585-SSP-40 Cisco Adaptive Security Appliance Software Version 9.x(x)x ASLR enabled, text region xxxxxxxxx-xxxxxxxxxx PC Thread 5Sec 1Min 5Min Process 0x00007f5a311dfd8c 0x00007f59f813e640 5.3% 3.2% 2.8% Unicorn Proxy Thread <--- - - 0.3% 0.2% 0.2% DATAPATH-2-2622 - - 0.3% 0.2% 0.2% DATAPATH-14-2634 - - 0.2% 0.2% 0.2% DATAPATH-9-2629 0x00007f5a30bc780d 0x00007f59f8166440 0.2% 0.0% 0.0% ssh <--- - - 0.2% 0.2% 0.2% DATAPATH-6-2626 - - 0.2% 0.2% 0.2% DATAPATH-10-2630 - - 0.2% 0.2% 0.2% DATAPATH-13-2633 - - 0.2% 0.2% 0.2% DATAPATH-1-2621 - - 0.2% 0.2% 0.2% DATAPATH-5-2625 - - 0.2% 0.2% 0.2% DATAPATH-15-2635 - - 0.2% 0.2% 0.2% DATAPATH-7-2627 - - 0.2% 0.2% 0.2% DATAPATH-8-2628 - - 0.2% 0.2% 0.2% DATAPATH-3-2623 - - 0.2% 0.2% 0.2% DATAPATH-4-2624 - - 0.2% 0.2% 0.2% DATAPATH-0-2620 - - 0.2% 0.2% 0.2% DATAPATH-11-2631 - - 0.2% 0.2% 0.2% DATAPATH-12-2632
CP処理の過負荷、多くの場合、誤設定や、セッション数が膨大な状態で 過剰な機能や設定の利用が原因です。利用機能や設定見直しと、適宜機能や設定の削減や無効化で改善できるケースが多いです。
見直しをしても、セキュリティポリシー上 必要な機能や設定で削減が難しいなどの理由により、CP負荷が下がらず CP過負荷により問題が引き起こされる場合は、機器の増設を行い、通信や処理を分散し、CP処理負荷を分散する検討が必要です。 例えば、1台でAnyConect終端をしていたのを、2台で分散しAnyConnect終端にすることで 実質 CP処理能力は約2倍になります。
なお、CP過負荷のシナリオの場合、上位機種へのアップグレードでの CPパフォーマンス改善効果は限定的です。どのモデルもその筐体あたりのCP処理能力は１コアに限られるためです。
VPNセッション数の確認
VPNセッション数の確認と 適正なセッション数の維持が重要である理由は幾つかありますが、最も重要なことは、VPNセッション数が増えればふえるほど、接続ユーザ間でVPNスループットは共用されるため、１ユーザあたりの利用可能なスループットが低下することです。業務にストレスのないスループットを提供できるのが好ましいのですが、VPNアクセスが集中し利用者が増えた場合、その分 1ユーザあたりの利用できるスループットは低下します。しかし、通常、アクセスが極度に集中する条件下でも、各接続ユーザに、遅延やストレスは感じても、業務を遂行するうえで最低限必要なスループットを提供する必要があります。
例えば、VPNスループットが 1Gbpsの製品を利用時、"ストレスなく業務ができる快適なスループットが 10 Mbps以上"、"何とか業務ができる最低限必要なスループットが1 Mbps以上"の場合、同時接続数は 前者が100名まで、後者は1000名までに抑えたほうがいいと考えることができます。（実際は、多数の接続を収容すると、その処理のオーバーヘッドがASAに追加発生するため、数割はASAのパフォーマンス余力を残しておくと良いです。）
また、VPNセッション数が増えるほど、その新規VPNセッション処理負荷や 同時VPNセッション数の管理処理が必要となり、ASAのCPU負荷増加要因となります。
また、同時接続数が増えると、その利用モデルのVPN接続数の上限に達してしまう可能性があります。最大VPN接続可能数に到達した場合、それ以降の新規接続は拒否されます。想定以上の接続数がある場合は、どこから接続があるのか調査と、適宜接続の切断や分散、ASA増設が必要になるかもしれません。
現在のVPNセッション数や ピーク時のセッション数、利用機器のキャパシティなどの確認は、show vpn-sessiondb summary コマンド で可能です。以下例の場合、VPNセッション数(Total Active and Inactive)が4つ、利用機器の最大アクセス可能数(Device Total VPN Capacity)が 250 であるため、VPNセッション数の使用率(Device Load)は 2% であることがわかります。
ASAv10(config)# show vpn-sessiondb summary
---------------------------------------------------------------------------
VPN Session Summary
---------------------------------------------------------------------------
Active : Cumulative : Peak Concur : Inactive
----------------------------------------------
AnyConnect Client : 3 : 36 : 4 : 1
SSL/TLS/DTLS : 3 : 36 : 4 : 1
Clientless VPN : 0 : 2 : 2
Browser : 0 : 2 : 2
---------------------------------------------------------------------------
Total Active and Inactive : 4 Total Cumulative : 38
Device Total VPN Capacity : 250
Device Load : 2%
---------------------------------------------------------------------------
| Active | データを交換中のアクティブセッションの接続数 |
| Cumulative | 過去含めたアクティブセッションの総和 (切断済み含む) |
| Peak Concur | アクティブセッションのピーク時の接続数 |
| Inactive | データ交換できない非アクティブなセッション数 |
| Total Active and Inactive | トータルのVPN接続数 |
| Device Total VPN Capacity | 利用デバイスのVPN接続の最大収納可能数 |
Active数を確認することで、データ交換中のセッションがどの程度 現在あるか確認できます。 Peak Concurを確認することで、ピーク時の AnyConnect 接続数を確認できます。
VPNセッション数のより詳しい確認の仕方や、SNMPポーリングでの監視方法については、以下ドキュメントを参照してください。
トラフィック量と平均パケットサイズの確認
ASAの各インターフェイスのスループットや 平均パケットサイズは、show traffic コマンドで確認できます。
例えば、以下は、AnyConnect端末から ASA経由でファイルサーバーに、UDPで100バイトのデータを 23Mbps程の速度でアップロード時の show traffic コマンドの出力例です。データ転送に DTLS (デフォルト) を利用しています。
ASAv10# show traffic
outside:
received (in 764949.640 secs):
58046368 packets 8402724238 bytes
2 pkts/sec 10002 bytes/sec
transmitted (in 764949.640 secs):
37863434 packets 46137328134 bytes
4 pkts/sec 60005 bytes/sec
1 minute input rate 23069 pkts/sec, 5005932 bytes/sec
1 minute output rate 2 pkts/sec, 1349 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 100 pkts/sec, 111376 bytes/sec
5 minute output rate 1 pkts/sec, 1307 bytes/sec
5 minute drop rate, 0 pkts/sec
dmz:
received (in 764949.640 secs):
42560852 packets 43254954890 bytes
5 pkts/sec 56001 bytes/sec
transmitted (in 764949.640 secs):
57972736 packets 3845145682 bytes
2 pkts/sec 5004 bytes/sec
1 minute input rate 16 pkts/sec, 2092 bytes/sec
1 minute output rate 23075 pkts/sec, 2953414 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 7 pkts/sec, 1545 bytes/sec
5 minute output rate 100 pkts/sec, 102823 bytes/sec
5 minute drop rate, 0 pkts/sec
| 平均スループット (bps) | 平均パケットサイズ (bytes) | |
| 計算式 | ( [input bytes/sec] + [output bytes/sec] ) x 8 | ( [input bytes/sec] + [output bytes/sec] ) ÷ ( [input pkts/sec] + [output pkts/sec] ) |
| Outside側 (DTLS暗号通信) |
(5005932+1349) x 8 = 40,058,248 = 約40Mbps |
(5005932+1349) ÷ (23069+2 ) = 217 bytes |
| DMZ側 (実通信) |
(2092+2953414) x 8 = 23,644,048 = 約23Mbps |
( 2092 + 2953414 ) ÷ ( 16 + 23075 ) = 127 bytes |
上記例の場合、DMZ側 (ファイルサーバー側) は、約23Mbps のトラフィックがあり、平均パケットサイズが 127 bytes であることが、show traffic コマンドからもわかります。また、やり取りする平均パケットサイズが小さい場合、23Mbpsのスループットを得るのに、毎秒 2万3000近くの膨大なパケット交換が必要になることがわかります。処理パケット数が多いほど、ASAとAnyConnect端末 双方に、DTLS暗号化や複合化や処理の手間がかかり、各機器のCPU負荷アップとパフォーマンス低下の原因となります。
Outside側 (インターネット側) は、DTLS暗号化のオーバーヘッドにより、トラフィックが約17Mbps増えており、平均パケットサイズも90バイト 増えていることがわかります。特にやり取りするパケット数が増え、かつ 各パケットサイズが小さくなるほど、回線帯域に占めるDTLSのオーバーヘッド分が増加し、回線帯域を圧迫することになります。
なお、上記はデータ転送に、軽快な「DTLS」を利用時のデータとなります。 仮に経路でUDP443の通過が許可されておらずデータ転送に「TLS」(=TCP443)が利用された場合は、「TLS」はTCPベースのため確認応答やフロー制御などの処理と追加パケットがAnyConnect端末とASA間で増えます。つまり、「TLS」を利用した場合は、回線のオーバーヘッドや AnyConnect端末とASA間のパケット数とその処理負荷がさらに増え、回線や ASA/AnyConnect端末の各パフォーマンス低下の原因となります。「TLS」は低速なため、リモートアクセスVPNのパフォーマンスを最大化するには、「DTLS」をメイン利用し、「TLS」利用するAnyConnect端末は必要最小限にするのがお勧めです。
暗号処理エンジンの負荷確認 (ハイエンドモデルのみ)
暗号処理エンジンのチューニングに対応したハイエンド機を利用時、"show crypto accelerator load-balance ssl"コマンドで、暗号処理用の各エンジンや そのコアの処理負荷バランシング状況を確認できます。各エンジンやコアが分散し処理することで、暗号処理性能を高めています。上位モデルほど暗号処理用のエンジンやコア数が増えます。
例えば以下は、ASA5555とAnyConnect端末間で DTLSセッションを1つ貼り、高負荷通信を発生時のログ例です。ASA5555は暗号処理エンジン (Engine 0)を1つ持ち、暗号コア (Crypto Cores) は 8個あり、そのうち 1個が IPsec用に、7個がSSL処理用に割り当てられていることがわかります。また、SSL処理用に割り当てられた中の Core 7が、そのDTLSセッションの暗号関連の処理を実施中である事を確認できます。
ASA5555(config)# show crypto accelerator load-balance ssl
Crypto SSL Load Balancing Stats:
==================================
Engine Crypto Cores SSL Sessions Active Session
Distribution (%)
====== ============== =========================== ================
0 IPSEC 1, SSL 7 Total: 182 Active: 6 100.0%
--- 略 ---
Encrypted Data 1 second 5 second 60 second
================== ======== ======== =========
Core 1 (load) 0.0% 0.0% 0.0%
Core 2 (load) 0.0% 0.0% 0.0%
Core 3 (load) 0.0% 0.0% 0.0%
Core 4 (load) 0.0% 0.0% 0.0%
Core 5 (load) 0.0% 0.0% 0.0%
Core 6 (load) 0.0% 0.0% 0.0%
Core 7 (load) 100.0% 100.0% 99.9% <--- This
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
