ASA 8.4以降: SNMP ポーリングを用いたメモリ監視について

Taisuke Nakamura · ‎2015-06-18

メモリ使用状況の確認のためのOID
システムメモリの確認と監視
メモリの詳細監視(原則使いません)
メモリプールの役割と適切な監視方法について
参考情報

メモリ使用状況の確認のためのOID

システムメモリの確認と監視

ASAバージョン 8.4からのソフトウェアの64bit化に伴い、4GB以上の扱いが可能となりました。SNMP ポーリングでのメモリ使用状況の確認には、OID .1.3.6.1.4.1.9.9.221.1.1.1.1 を利用します。通常、メモリ使用状況の確認には、当OIDを利用します。

ASA5555側出力 (システムメモリの確認)：

Result of the command: "show memory"

Free memory:        7344458522 bytes (86%)
Used memory:        1255282934 bytes (14%)
-------------     ------------------
Total memory:       8589934592 bytes (100%)

snmapwalk出力結果 (システムメモリの監視)：

cisco@ubuntu:~$ snmpwalk -v 2c -c cisco 192.168.0.254 .1.3.6.1.4.1.9.9.221.1.1.1.1 
iso.3.6.1.4.1.9.9.221.1.1.1.1.2.2.1 = INTEGER: 2
iso.3.6.1.4.1.9.9.221.1.1.1.1.3.2.1 = STRING: "System memory"
iso.3.6.1.4.1.9.9.221.1.1.1.1.5.2.1 = INTEGER: 0
iso.3.6.1.4.1.9.9.221.1.1.1.1.6.2.1 = INTEGER: 1
iso.3.6.1.4.1.9.9.221.1.1.1.1.7.2.1 = Gauge32: 1246831814   <--- 旧32bitカウンタ
iso.3.6.1.4.1.9.9.221.1.1.1.1.8.2.1 = Gauge32: 3048135466   <--- 旧32bitカウンタ
iso.3.6.1.4.1.9.9.221.1.1.1.1.17.2.1 = Gauge32: 0
iso.3.6.1.4.1.9.9.221.1.1.1.1.18.2.1 = Counter64: 1246831878  <---- Used Memory
iso.3.6.1.4.1.9.9.221.1.1.1.1.19.2.1 = Gauge32: 1
iso.3.6.1.4.1.9.9.221.1.1.1.1.20.2.1 = Counter64: 7343102714  <---- Free Memory

以下はシステムメモリ監視用の各OIDの詳細とそのオブジェクト名です。

ASA5555# show snmp-server oid | in .1.3.6.1.4.1.9.9.221.1.1.1.1
[666]   1.3.6.1.4.1.9.9.221.1.1.1.1.2.  cempMemPoolType
[667]   1.3.6.1.4.1.9.9.221.1.1.1.1.3.  cempMemPoolName
[668]   1.3.6.1.4.1.9.9.221.1.1.1.1.5.  cempMemPoolAlternate
[669]   1.3.6.1.4.1.9.9.221.1.1.1.1.6.  cempMemPoolValid
[670]   1.3.6.1.4.1.9.9.221.1.1.1.1.7.  cempMemPoolUsed
[671]   1.3.6.1.4.1.9.9.221.1.1.1.1.8.  cempMemPoolFree
[672]   1.3.6.1.4.1.9.9.221.1.1.1.1.17. cempMemPoolUsedOvrflw
[673]   1.3.6.1.4.1.9.9.221.1.1.1.1.18. cempMemPoolHCUsed
[674]   1.3.6.1.4.1.9.9.221.1.1.1.1.19. cempMemPoolFreeOvrflw
[675]   1.3.6.1.4.1.9.9.221.1.1.1.1.20. cempMemPoolHCFree

メモリの詳細監視(原則使いません)

メモリの詳細監視には、OID iso.3.6.1.4.1.9.9.48.1.1.1 も利用可能ですが、当OIDは"System memory"以外のメモリプールの情報 (つまり、DMA Memoryと Global Shared Memoryの情報) も得れてしまい、処理負荷が高いため、システム負荷や不安定化の原因になることがあります。その為、特にTACからの依頼の無い場合は、OID iso.3.6.1.4.1.9.9.48.1.1.1 の利用はしないでください。

snmapwalk出力結果 (NG例)：

cisco@ubuntu:~$ snmpwalk -v 2c -c cisco 192.168.0.254 iso.3.6.1.4.1.9.9.48.1.1.1
iso.3.6.1.4.1.9.9.48.1.1.1.2.1 = STRING: "System memory"
iso.3.6.1.4.1.9.9.48.1.1.1.2.6 = STRING: "MEMPOOL_DMA"
iso.3.6.1.4.1.9.9.48.1.1.1.2.7 = STRING: "MEMPOOL_GLOBAL_SHARED"
iso.3.6.1.4.1.9.9.48.1.1.1.3.1 = INTEGER: 0
iso.3.6.1.4.1.9.9.48.1.1.1.3.6 = INTEGER: 0
iso.3.6.1.4.1.9.9.48.1.1.1.3.7 = INTEGER: 0
iso.3.6.1.4.1.9.9.48.1.1.1.4.1 = INTEGER: 1
iso.3.6.1.4.1.9.9.48.1.1.1.4.6 = INTEGER: 1
iso.3.6.1.4.1.9.9.48.1.1.1.4.7 = INTEGER: 1
iso.3.6.1.4.1.9.9.48.1.1.1.5.1 = Gauge32: 1245180054
iso.3.6.1.4.1.9.9.48.1.1.1.5.6 = Gauge32: 312096208
iso.3.6.1.4.1.9.9.48.1.1.1.5.7 = Gauge32: 114194352
iso.3.6.1.4.1.9.9.48.1.1.1.6.1 = Gauge32: 4294967295
iso.3.6.1.4.1.9.9.48.1.1.1.6.6 = Gauge32: 153172528
iso.3.6.1.4.1.9.9.48.1.1.1.6.7 = Gauge32: 9840720
iso.3.6.1.4.1.9.9.48.1.1.1.7.1 = Gauge32: 152789952
iso.3.6.1.4.1.9.9.48.1.1.1.7.6 = Gauge32: 152789952
iso.3.6.1.4.1.9.9.48.1.1.1.7.7 = Gauge32: 3808

メモリプールの役割と適切な監視方法について

ASAは以下3つのメモリプールを持ちます。システムメモリ内に、Global Shared Poolと DMA Memory Poolがあり、Global Shared Poolは主要アプリケーションが利用するメモリ共有領域です。DMA Memoryは予め固定されたメモリ領域で、高速処理のために利用され、当領域が枯渇することは稀です。なお、各アプリケーションは、メモリ使用後もキャッシュとしてメモリをしばらく保持し続ける事がありますが、メモリの空きが少なくなるとキャッシュは自動で解放されます。これらはシステムが自動的に判断します。

システムメモリの空きメモリが大きく枯渇した場合、システムの不安定化や予期せぬ再起動の原因となります。show memoryコマンドや、OID .1.3.6.1.4.1.9.9.221.1.1.1.1 で確認できる Free Memoryが残り20%より低下すると、メモリ空き容量が少ないと言えます。Free Memory が 0%に近くなるほど、システム不安定化やクラッシュの原因となるため、Free Memory が 0%になるまえに、対象ASAを再起動しメモリを解放してください。Free Memoryが残り20%を切りさらに枯渇が進む場合は、使い終わったメモリが正常に開放されない問題(=メモリリーク)が発生している可能性があるため、ASA 9.x: メモリ高負荷問題のトラブルシューティング方法の 2. ソフトウェア不具合によるメモリ消費 を参考に切り分けやログ取得しサポート部門に支援を依頼することで、メモリリーク原因の調査のサポートを受けることが可能です。

システムメモリ以外のメモリプール (Global Shared Poolや DMA Memory) へのクエリも可能ですが、これら領域は特殊なメモリプールとなり、通常のお客様のメモリ監視では使いません。そのため、エンジニアからの指示なしに、当プール(Global Shared Poolや DMA Memory) のメモリ監視は行わないでください。特にGlobal Shared Poolは広大な領域で処理対象が多い為、Global Shared Poolへのクエリは CPU処理負荷の上昇を伴い、システム不安定化の原因にもなります。これらメモリ領域の監視が必要となるケースは稀です。

また、SNMPポーリングの頻度は、例えば、1時間や20分に1回など、十分な間隔をあけるようにしてください。 1分に1回など、極端に短い間隔でのSNMPポーリングは避けるべきです。 ASAのSNMP処理は、コントロールポイント（CP)での低速な処理となる為、SNMPの監視対象や監視数が増えるほど、ASAの処理負荷が上昇します。運用で利用しないクエリは控え、またポーリング頻度を最低限とする事で、ASAの処理負荷上昇を抑える事ができます。SNMP処理の負荷状況の確認方法について詳しくは、ASA: show processes cpu-usage を用いた CPU負荷の調査を参照してください。

参考情報

ASA: Blockの各SIZEの利用用途と使用状況の確認
https://supportforums.cisco.com/ja/document/12382586

ASA 9.x: メモリ高負荷問題のトラブルシューティング方法
https://supportforums.cisco.com/t5/-/-/ta-p/3166256

ASA9.1: SNMP の設定
http://www.cisco.com/cisco/web/support/JP/docs/SEC/Firewall/ASA5500NextGenerationFire/CG/001/monitor_snmp.html?bid=0900e4b183271d68

ファイアウォールトラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161736

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