ASA: show processes cpu-usage を用いた CPU負荷の調査

Taisuke Nakamura · ‎2015-06-30

はじめに
show processes cpu-usage non-zero コマンドについて
主要プロセス一覧
データパスとは
コントロールポイントとは
マルチコア時のデータパスとコントロールポイントの処理の違い
その他 CPU高負荷時の調査に役立つ情報
トラブルシューティングケーススタディ
ASAのパフォーマンスの問題の監視とトラブルシューティング
マルチコンテキストモードを利用時
非常に大きなACLを利用し、データパス負荷が高い場合
シングルフローの通信試験時にパフォーマンスが出ない場合
参考情報

はじめに

ASAは柔軟で多様なセキュリティ制御のため、CPUによるソフトウェアベースの通信制御を行います。その為、CPUの処理負荷が90-100%など極めて高い場合、パケットドロップを引き起こし、それに伴う ASAを経由する通信の、スループット低下やコネクション切断の原因となりえます。

このCPU高負荷問題のトラブルシューティングには、まず何が原因でCPU使用率が高騰しているかの調査が必要です。この時、show proc cpu-usage non-zeroコマンドは、このCPU高負荷を引き起こしているプロセスの調査に大変役立ちます。

show proc cpu-usage non-zeroコマンドは、ASAのCPU高負荷問題の調査の上で最も重要なコマンドの1つであり、ASAバージョン9.4(1)以降でshow techコマンドにも当出力が含まれるようになりました。

本ドキュメントでは、当コマンド取得例と、取得時に確認できる主要プロセスとその高負荷時の対処例について紹介します。　　　　　

show processes cpu-usage non-zero コマンドについて

5秒/1分/5分毎の、ゼロ以外の、各プロセスのCPU使用率を表示します。

asa# show proc cpu-u non
PC         Thread       5Sec     1Min     5Min   Process
0x00000000019bd596   0x00007fffec5c62e0     0.0%     0.1%     0.0%   telnet/ci
0x000000000199db42   0x00007fffec72b040     0.2%     0.2%     0.2%   Logger
0x000000000082d2c6   0x00007fffec71c4a0     3.8%     3.8%     1.8%   CP Processing
0x000000000082ce21   0x00007fffec71b9c0     0.1%     0.1%     0.1%   CP ARP Processing
0x0000000000bebedc   0x00007fffec715440     0.1%     0.1%     0.1%   ARP Thread
   -          -        31.2%    28.4%    14.6%   DATAPATH-0-1575

上記は、通信処理量の比較的多いASAで取得した結果です。データパス(i.e.DATAPATH-0-1575)の負荷が高く、応じてコントロールポイント(i.e.CP Processing)の負荷が上昇していることがわかります。

データパス以外の殆どのプロセスはコントロールポイントで処理されます。

当コマンドの出力は、CPUのコア数に関係なく、トータルでCPU使用率 100%が最大になります。例えば、show process cpu-usageの各プロセスの負荷の合計が100%であった場合は、マルチコアの各コアのCPU負荷が100%であることとほぼ同義となります。当コマンド出力の見方についてより詳しくは、当ドキュメントの"マルチコア時のデータパスとコントロールポイントの処理の違い"項を参照してください。

Tips:
CPU高負荷問題の調査時は、定期的に調査用コマンドを実行し、それら出力を比較分析する事が重要です。以下は分析例です。
・ 10秒毎に、取得と比較を繰り返し、瞬間的 or 継続的な負荷か分析
・ 数時間毎に、取得・比較を繰り返し、時間帯による傾向性があるか分析

高負荷のプロセスとその時間帯が判明したら、より深い原因調査を行います。以下は調査例です。
・ データパス高負荷時は、通信処理量が過大でないか調査。詳しくは後述
・ ARPプロセスが高負荷時は、ARPフラッドが発生していないか調査

・ Loggerプロセスが高負荷時は、ロギング対象の通信が膨大にないか調査を。合わせ、ロギング出力が細かすぎくないか確認 (デバッグ無効化し忘れ、など)
・ SNMPプロセスが高負荷時は、ポーリングやトラップの頻度が過大でないか調査
・ tmach compile threadプロセスが高負荷時は、ACL/NATコンパイル処理に時間がかかっている可能性があり、ACL/NAT設定量が機器パフォーマンスに比べ過大でないか調査。なお、当プロセス負荷が高い場合は、データパスの高負荷も併発しやすい。より詳しくは、ASA: インターフェイスACLの最大設定数と推奨設定数についてを参照

・ CP Processingプロセスが高負荷時は、アプリケーションインスペクション対象の通信が多数流れていないか確認を。FTPやESMTPなどのアプリケーションインスペクションは処理負荷が高いため、非NAT環境などで当処理が不要な通信は ASA: MPFを用いたサービスポリシーの設定例と動作確認を参照しインスペクション対象から除外の検討を

主要プロセス一覧

プロセス名	説明
aaa	AAAに関する主要プロセス
ARP Thread	ARP処理の主要プロセス
arp_timer	ARPキャッシュの監視とクリアを行うARPタイマー
ci/console	コンソールセッション
CP Processing	データパスからコントロールポイント宛の、イベント・パケット処理を行う主要スレッド主にアプリケーションインスペクションや Syslog負荷が高いときに負荷上昇
DATAPATH-X-YYY	データパス処理における主要スレッド。各コア(X)毎に異なるスレッドが動作
Dispatch Unit	シングルコアモデルの、データパス処理における主要スレッド
PTHREAD	仮想ASAのデータパス処理スレッド
emweb/https	SSL VPNなどで利用するHTTPSサーバのスレッド
fover_FSM_thread	フェイルオーバー状態の監視スレッド
IKE Daemon	IKE処理における主要スレッド
Logger	Syslog, console, buffer, monitorなどのSyslogスレッド
Session Manager	VPNセッションデータベースのタイマースレッド
snmp	SNMPポーリングの受信と処理を行うスレッド
SNMP Notify Thread	SNMPトラップを送付するスレッド
ssh	SSHセッションに関するスレッド
telnet/ci	Telnetセッションに関するスレッド
tmatch compile thread	ACL/NAT変更後、ACL/NAT処理の高速化のためのコンパイルスレッド
Unicorn Admin Handler	ASDMセッションに関するスレッド
Unicorn Proxy Thread	WebVPNの処理に関連したスレッド
aaa_shim_thread	WebVPNのDAPや dACLで使われるスレッド
vpnfol_thread_msg	VPNフェイルオーバー関係のメインスレッド

データパスとは

Firewallとしてベーシックな機能である以下処理などを行います。これら処理は最適化されています。

ACLチェック
NATチェックと適用
コネクション生成と管理
TCPセキュリティチェック
ルーティング、スイッチング
フラグメントパケットの再構築
パケットキャプチャなど

　　　
プロセス DATAPATH-X-YYYや Dispatch Unit の負荷が高い場合、データパスの高負荷を示します。多くの場合、トラフィック過多やコネクション数過多が原因です。他、ACLやNATの設定量が過多の場合、このデータパス負荷をさらに押し上げる時があります。

一時的な高負荷の場合はネットワークの帯域を占有するクライアントやアプリケーションがないか、DOS攻撃やトラフィックループの発生がないか、などを確認します。

慢性的な高負荷の場合は、利用のネットワークシステムに対し、ASAの処理パフォーマンスが適切か確認を行います。ASAのデータシートを確認する場合、最大パフォーマンスではなく、実環境でのパフォーマンス目安に近いマルチプロトコルのパフォーマンスを参考にするようにしてください。

なお、多数のフラグメントパケットの処理時や、過去に有効化した複数パケットキャプチャコマンドの無効化し忘れ、などがデータパス高負荷原因の１つとなる事もあります。

フラグメントパケットの処理数確認例
- Assembled = フラグメントパケットの再構築に成功した回数
- 複数回当コマンドを実行しカウンタ上昇が非常に多い場合、ASAや周囲機器、端末やサーバのMTUの設定が適切か確認を

asa# show fragment
Interface: outside
    Size: 200, Chain: 24, Timeout: 5, Reassembly: virtual
    Queue: 0, Assembled: 207392, Fail: 2035, Overflow: 1937
Interface: dmz
    Size: 200, Chain: 24, Timeout: 5, Reassembly: virtual
    Queue: 0, Assembled: 0, Fail: 0, Overflow: 0

キャプチャ有効状況の確認例
- キャプチャコマンドが有効のままだと、常にキャプチャ処理負荷が発生し続けます
- キャプチャ無効化し忘れを確認時は、no capture <capname> コマンドで削除

ASA# show capture 
capture IN type raw-data interface inside [Buffer Full - 523562 bytes]
  match tcp host 192.168.30.1 host 173.37.145.84 eq www 

capture OUT type raw-data interface outside [Buffer Full - 523562 bytes]
 match tcp host 1.100.100.1 host 173.37.145.84 eq www

ASA# no capture IN       <--- 未使用Captureの削除
ASA# no capture OUT      <--- 未使用Captureの削除

コントロールポイントとは

データパスは ACLやNATチェックや、コネクション新規生成やルックアップと管理、切断といった、Firewallとしての基本的な処理を高速に実行することを目的としています。逆にコントロールポイントはデータパスで処理の高速化が難しい、複雑な処理を主に実施しています。

以下はInterfaceからパケット受信時のデータパスとコントロールポイントの処理のアーキテクチャ概要です。

以下はパケット処理フローの詳細です。単純に高速で処理可能なところはデータパスで、高度な処理が必要なところはコントロールポイントで分けて処理することで、処理速度やパフォーマンスとCPU処理負荷の最適化を行っています。

データパスの分散処理に対応した機能は show asp multiprocessor accelerated-featuresコマンドで確認可能です。 IPsec/SSLのデータパス処理や、Syslogサーバーへのメッセージ送付(Syslogging)、QoSやNetflow、一部のアプリケーションインスペクション(DNSやICMP)もデータパスの分散処理に対応しています。逆に以下コマンドで出力のない処理(例えばSyslogメッセージ原文の生成や分散処理に対応してないアプリケーションインスペクション、SSHやTelnetでのコマンド操作など)は基本コントロールポイントでの低速処理となります。

FPR2K# show asp multiprocessor accelerated-features
MultiProcessor accelerated feature list:
        Access Lists
        DNS Guard
        Failover Stateful Updates
        Flow Operations(create, update, and tear-down)
        Inspect HTTP URL Logging
        Inspect HTTP (AIC)
        Inspect IPSec Pass through
        Inspect ICMP and ICMP error
        Inspect RTP/RTCP
        IP Audit
        IP Fragmentation & Re-assembly
        IPSec data-path
        MPF L2-L4 Classify
        Multicast forwarding
        NAT/PAT
        Netflow using UDP transport
        Non-AIC Inspect DNS
        Packet Capture
        QOS
        Resource Management
        Routing Lookup
        Shun
        SSL data-path
        Syslogging using UDP transport
        TCP Intercept
        TCP Security Engine
        TCP Transport
        Threat Detection
        Unicast RPF
        WCCP Re-direct
Above list applies to routed, transparent, single and multi mode

マルチコア時のデータパスとコントロールポイントの処理の違い

2019年現在 ASAの殆どのモデルはマルチコアのCPUを搭載し分散処理を行う事で処理の高速化を行っています。

マルチコアの場合、Firewall処理を行うプロセスであるデータパスは各コア毎に稼働し分散処理されます。例えば 4コアモデルを利用の場合 4個のデータパスプロセスが稼働し、各コア上で稼働するデータパスのCPU使用率最大は 25%程(=100÷4)となります。

マルチコアの場合、Control Pointのプロセス処理は、殆どがマルチコアの分散/高速処理に対応していないため、原則 1コア分のCPU使用率が最大となります。例えば 4コアモデルを利用の場合、Control Pointの全プロセスの合計のCPU使用率最大は 25%程(=100÷4)となります。 Control Pointの処理は、各コアでフロートアラウンドで順番に行うことで、特定コアにControl Pointの処理負荷が偏るのを避け、複数コアにControl Pointの処理を分散する実装となっております。

各コアのデータパスとControl Point処理の負荷状況は、show cpu detailコマンドで確認できます。当コマンドと show process cpu-usageを比較し分析することで、各プロセスの負荷状況と、データパスとコントロールポイントの負荷状況を把握しやすくなります。

以下は、4コアモデルで CPU負荷65%ほどの負荷試験時の、show process cpu-usageコマンドと show cpu detailコマンドの出力比較です。以下スライド例の場合、データパス負荷は各コア 50%程度で処理余力ありますが、コントロールポイント負荷は約80%近くでCP処理能力は非常に高いことがわかります。CP処理負荷が極めて高いと、CP処理の各種機能の遅延や処理失敗の原因になります。

以下は、各コアでのDPとCPの処理の説明図となります。

なお、ASAバージョン 9.6(1)以降のバージョンで、コア数の特に多いモデル(例：ASA5585や Firepower4100/9300など)は、CPの処理効率化のため、全てのコアでCP処理を行わず、ランダムで選ばれた2～4コアのみでCP処理が実施されるように実装が変わりました。CP処理中のコアは、show cpu detailコマンドで確認できます。

その他 CPU高負荷時の調査に役立つ情報

トラブルシューティングケーススタディ

以下ドキュメントの「CPU使用状況の確認」に、show processes cpu-usage コマンドを活用したトラブルシューティング例があるため、あわせて参考にしてください。

https://community.cisco.com/t5/-/-/ta-p/4061565#toc-hId-359921112

ASAのパフォーマンスの問題の監視とトラブルシューティング

パフォーマンス問題のトラブルシューティング時に有用なコマンドとTIPSが多数紹介されています
https://www.cisco.com/c/ja_jp/support/docs/security/asa-5500-x-series-next-generation-firewalls/113185-asaperformance.html

マルチコンテキストモードを利用時

どのContextのCPU負荷が高いかの調査に、"show cpu context all"コマンドが有用です。また、各Contextのリソース利用状況は "show resource usage all" コマンドで確認できます。本ドキュメントの "show process cpu-usage" コマンドと合わせて、トラブルシューティングで活用してください。

ASA/pri/act# show cpu context all
 5 sec  1 min  5 min  Context Name
  3.2%   0.4%   0.5%  system
  0.0%   0.0%   0.0%  admin
  0.0%   0.0%   0.0%  TAC-test-01  
 
ASA/pri/act# show resource usage all
Resource Current Peak Limit Denied Context
Conns 4 7 unlimited 0 admin
Hosts 4 7 unlimited 0 admin

非常に大きなACLを利用し、データパス負荷が高い場合

以下ドキュメントを確認し、ACL設定量のチューニングなどを検討してください。

https://community.cisco.com/t5/-/-/ta-p/3375913

シングルフローの通信試験時にパフォーマンスが出ない場合

2018年現在リリースの殆どのモデルがマルチコアであり、各コアで分散処理することによって高パフォーマンスを実現しています。各コア毎に１つのデ―タパスが稼働し、各データパスは割り当てられた1つのコネクションの継続処理を担当するため、シングルフローの場合、1つのコアの処理能力の最大分しかパフォーマンスは出ません。ご利用モデルのASAのパフォーマンスを最大限引き出すには、マルチコアモデルの場合、コア数 x 4つ 以上の、Protocolと送信元/宛先IP、送信元/宛先Portの異なる複数コネクションを発生させることが目安になります。例えば、show cpu detailコマンドで確認できるコア数が8個のモデルの場合は、8 x 4 = 32個以上のコネクションが発生時に最大パフォーマンスを得やすくなります。

参考情報

ファイアウォールトラブルシューティング
https://supportforums.cisco.com/ja/document/12725841

Firepower System and FTDトラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161733

VPN トラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161734