内容

はじめに

使用するコンポーネント

ログ収集

ログ分析

SNMPビューの設定

トラブルシューティング情報

結論

関連情報

はじめに

このドキュメントでは、9800ワイヤレスLANコントローラ(WLC)のSNMPプロセスに対する高いCPU使用率をトラブルシューティングし、解決するための構造化されたアプローチについて説明します。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

- ワイヤレスコントローラ：17.09.03を実行するC9800-80-K9

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

ログ収集

CPU使用率のパターンの特定SNMPプロセスにリンクされているCPU使用率が高いというレポートを受信した場合、最初のアクションは、指定されたタイムフレームに渡って詳細なログを収集することです。これは、CPU使用率のパターンや傾向を確立するのに役立ちます。これは、SNMPプロセスが最もアクティブでリソースを大量に消費する時間を特定するために不可欠です。

ログ収集を開始する前に、トラブルシューティングプロセスをサポートするために使用される特定の情報を収集することが不可欠です。まず、問題に関する情報をいくつか収集します。

- システムでスパイクが発生しているか、使用率が一貫して高いか。

- どちらの場合も、使用率は何パーセントですか。

- CPU使用率が高い頻度は何ですか。

- 各SNMPサーバがWLCをポーリングする頻度はどのくらいですか。

- トップトーカーは誰ですか。

10分のスパンで2分間隔で9800 WLCからのコマンド出力を収集します。このデータは、特にSNMPプロセスに関連するCPU高使用率の問題の分析に使用できます。

#terminal length 0

#show clock

#show process cpu sorted | exclude 0.0

#show process cpu history

#show processes cpu platform sorted | exclude 0.0

#show snmp stats oid

#show snmp stats hosts

ログ分析

これらのログを収集した後、その影響を理解するためにログを分析する必要があります。

CPU使用率ログの例を見て、CPUを最も消費しているSNMPプロセスを特定してみましょう。

WLC#show process cpu sorted | exclude 0.0

CPU utilization for five seconds: 96%/7%; one minute: 76%; five minutes: 61%

PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process

250   621290375    58215467      10672 58.34% 39.84% 34.11%   0 SNMP LA Cache pr  <-- High utilization

93   167960640   401289855        418 14.50% 11.88%  9.23%   0 IOSD ipc task

739   141604259   102242639       1384  8.57%  6.95%  7.21%   0 SNMP ENGINE

763        7752       34896        222  4.00%  3.41%  1.83%   5 SSH Process

648     6216707   181047548         34  0.72%  0.37%  0.31%   0 IP SNMP

376     3439332    51690423         66  0.40%  0.36%  0.25%   0 SNMP Timers

143     3855538   107654825         35  0.40%  0.35%  0.23%   0 IOSXE-RP Punt Se

108     6139618    17345934        353  0.40%  0.30%  0.34%   0 DBAL EVENTS

show process cpu sortedの出力 | exclude 0.0コマンドは、SNMPプロセスが不均衡な量のCPUリソースを実際に消費していることを示しています。特に、SNMP LA Cache prプロセスはCPUに最も大きな負荷をかけており、その後に他のSNMP関連のプロセスが続きます。

次の一連のコマンドは、SNMPの高使用率プロセスを詳しく調べるのに役立ちます。

WLC#show snmp stats oid

time-stamp               #of times requested             OID

11:02:33 Austral Jun 8 2023      27698                   bsnAPIfDBNoisePower  <-- Frequently polled OID

11:02:23 Austral Jun 8 2023      1                       sysUpTime

11:02:23 Austral Jun 8 2023      17                      cLSiD11SpectrumIntelligenceEnable

11:02:23 Austral Jun 8 2023      1                       cLSiD11SpectrumIntelligenceEnable

11:02:23 Austral Jun 8 2023      6                       cLSiD11Band

11:02:23 Austral Jun 8 2023      1                       cLSiD11Band

11:02:23 Austral Jun 8 2023      1                       cLSiD11Band

11:02:23 Austral Jun 8 2023      1                       cLSiD11Band

11:02:19 Austral Jun 8 2023      24                      clcCdpApCacheApName

11:02:19 Austral Jun 8 2023      1                       clcCdpApCacheDeviceIndex

11:02:19 Austral Jun 8 2023      9                       cLApCpuAverageUsage

11:02:19 Austral Jun 8 2023      1315                    cLApCpuCurrentUsage

11:02:19 Austral Jun 8 2023      2550                    bsnAPIfDBNoisePower

show snmp stats oidコマンドの出力は、さまざまなOIDがポーリングされている頻度を明らかにします。bsnAPIfDBNoisePowerという特定のOIDは、要求の数が非常に多いため、際立っています。これは、このOIDのアグレッシブポーリングがWLCで観察される高いCPU使用率の一因である可能性があることを示唆しています。

ここでは、OID bsnAPIfDBNoisePowerの動作とそのデータ格納時間について説明します。

SNMPオブジェクトナビゲータに移動し、OID「bsnAPIfDBNoisePower」を検索します。

OID検索結果

これで、bsnAPIfDBNoisePowerオブジェクトが、各APから報告された各チャネルのノイズ出力を報告することについて理解できました。WLCによって管理される多数のチャネルとAPを考えると、このOIDによって生成されるSNMPデータは大量になる可能性があります。WLCが多数のAPにサービスを提供する場合、このOIDのポーリングによって生成されるデータの量は膨大になる可能性があります。これは、WLCがこれらの大量のSNMP要求を処理する際に、高いCPU使用率につながる可能性があります。

同様に、積極的にポーリングされる特定のOIDの動作を理解する必要があります。

次のコマンドは、WLCをポーリングしているSNMPサーバを確認するのに役立ちます。

WLC#show snmp stats hosts

Request Count    Last Timestamp  Address

77888844          00:00:00 ago   10.10.10.120

330242            00:00:08 ago   10.10.10.150

27930314          00:00:09 ago   10.10.10.130

839999            00:00:36 ago   10.10.10.170

6754377           19:45:34 ago   10.10.10.157

722               22:00:20 ago   10.10.10.11

このコマンドは、SNMPサーバのリストと、その要求カウントおよびポーリングアクティビティの最終タイムスタンプを表示します。

9800 WLCをポーリングしている複数の異なるサーバがあることがわかります。最後の10分間に収集されたログの完全なデータを見ると、ポーリング頻度も測定できます。

これで、各サーバに移動して、問題のOIDがポーリングされる頻度を確認できます。この例では、OIDは30秒ごとにポーリングされ、必要以上に頻繁にポーリングされます。WLCはRF/RRMデータを180秒ごとに受信するため、OIDを30秒ごとにポーリングすると不要な処理が発生し、CPU使用率が高くなります。

問題のOIDとサーバが特定されたら、複数の異なるソリューションを試してWLCの負荷を軽減できます。

1. SNMPサーバでのポーリング頻度を減らす。

2. 操作にOIDが必要ない場合は、SNMPサーバからのOIDのポーリングを無効にします。

3. SNMPサーバを制御できない場合は、SNMPビューを使用して問題のOIDをブロックできます。

SNMPビューの設定

ブロックするOIDを除外する新しいビューを定義します。たとえば、OID 1.3.6.1.4.1.14179.2.2.15.1.21をブロックして新しいビューを作成し、そのビューにOIDをアタッチするとします。

snmp-server view blockOIDView 1.3.6.1.4.1.14179.2.2.15.1.21 excluded  <-- This is the OID of bsnAPIfDBNoisePower

snmp-server community TAC view blockOIDView RO <-- This command assigns the blockOIDView to the community myCommunity with read-only (RO) access.

snmp-server group TAC v3 priv read blockOIDView <-- This command assigns the blockOIDView to the group myGroup with the priv security level for SNMPv3.

トラブルシューティングのヒント

- ベースラインCPU使用率：SNMPプロセスによって高い使用率が発生していないときの通常のCPU使用率レベルを文書化します。

- SNMP設定：コミュニティストリング、バージョン（v2cまたはv3）、アクセスリストなど、現在のSNMP設定を確認します。

- SNMPのベストプラクティス：9800 WLCのベストプラクティスドキュメントを使用し、SNMPの推奨設定にできる限り近いものと一致させてください。

C9800(config)#snmp-server subagent cache

C9800(config)#snmp-server subagent cache timeout ?

<1-100>  cache timeout interval (default 60 seconds)

- SNMPポーリングの頻度：頻度を高くするとCPU負荷が増加する可能性があるため、SNMPクエリによってWLCがポーリングされる頻度を決定します。

- ネットワークトポロジとSNMPマネージャ：ネットワーク設定を理解し、WLCと対話しているすべてのSNMPマネージャを特定します。

- システムアップタイム：最後のリブートからの経過時間をチェックして、アップタイムとCPU使用率に相関関係があるかどうかを確認します。

- 最近の変更：WLCの設定またはネットワークに対する最近の変更で、CPU使用率が高くなる時期と一致する可能性のあるものに注意してください。

- 9800 WLCでは、テレメトリに重点が置かれています。テレメトリは「プッシュ」モデルで動作します。このモデルでは、WLCはクエリーを実行することなく関連情報をサーバに送信します。SNMPクエリがWLCのCPUサイクルを消費し、操作の問題を引き起こしている場合は、テレメトリに移行することをお勧めします。

結論

CPU使用率データを系統的に分析し、それをSNMPポーリングアクティビティと関連付けることで、Cisco 9800 WLC上のSNMPプロセスが原因で発生するCPU高使用率の問題をトラブルシューティングして解決できます。実装後のモニタリングは、トラブルシューティング作業の成功を確認し、最適なネットワークパフォーマンスを維持するために不可欠です。

関連情報

- OIDを使用したSNMPによるCatalyst 9800 WLCのモニタ

- SNMP V2、V3、およびNetCONFを使用したPrime InfrastructureによるCatalyst 9800ワイヤレスコントローラシリーズの管理

- 簡易ネットワーク管理プロトコルの保護

- Cisco Catalyst 9800シリーズ設定のベストプラクティス