SNMPの基本機能のトラブルシューティング

はじめに

このドキュメントでは、Simple Network Management Protocol(SNMP)のトラブルシューティングシナリオについて説明します。

前提条件

要件

以下について十分に理解しておくことをお勧めします。

• SNMPv2cおよびSNMPv3プロトコルの動作
• Cisco IOS® XEコマンドラインインターフェイス(CLI)

使用するコンポーネント

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

• Cisco Catalyst 3650 シリーズ スイッチ

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

最も一般的なエラーのトラブルシューティング

1. エラーメッセージ：「%SNMP-3-RESPONSE_DELAYED: processing GetNext of <OID> (<elapsed-time> msecs)」

この例では、ciscoMgmt.810.1.2.1.1が遅延GetNext要求に関連付けられたOIDです。根本原因を特定する前に、繰り返しメッセージをCPU使用率、NMSポーリングレコード、およびリリース固有の不具合と関連付けます。

*May 24 01:30:48.463: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24008 msecs)

*May 24 01:31:12.477: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24012 msecs)

*May 24 01:31:36.486: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.2.1.1 (24008 msecs)

*May 24 01:32:00.503: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24016 msecs)

*May 24 01:32:24.515: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24012 msecs)

*May 24 01:32:48.528: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24012 msecs)

*May 24 01:33:12.537: %SNMP-3-RESPONSE_DELAYED: processing GetNext of ciscoMgmt.810.1.3.1.1 (24008 msecs)

解決するには、以下を実行します。

デバイスのSNMP設定をチェックします。 SNMPv2cの場合は、複数のコミュニティがデバイスに追加された場合の出力に似ています。

snmp-server community TAC1 RO

snmp-server community TAC2 RO  --> 

SNMPv3の場合：

snmp-server view TESTV3 iso include

snmp-server group TestGroupV3 v3 auth read TESTV3

snmp-server user cisco TestGroupV3 v3 auth md5 ciscorules priv des56 cisco123

デバイスのコンフィギュレーションモードを開始し、SNMP設定にビューを追加します。

SNMPv2cの場合：

snmp-server community TAC1 RO view cutdown RO

snmp-server community TAC2 RO view cutdown RO

問題の原因となっているOIDを除外するという考えですが、変更を適用する前に、除外できるOIDの機能を確認してください。

snmp-server view cutdown iso included

snmp-server view cutdown ciscoMgmt.810 excluded -->>> 

SNMPv3では、ビューの除外はsnmp-server groupコマンドで適用されます。

snmp-server view TESTV3 internet included

snmp-server view TESTV3 ciscoMgmt.810 excluded

snmp-server group TestGroupV3 v3 priv write TESTV3 

2. エラーメッセージ「High CPU Utilization due to SNMP Flash Cache」

Device#show processes cpu sorted

CPU utilization for five seconds: 99%/0%; one minute: 22%; five minutes: 18%

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

447    561399          143012       3925       0.00%         1.58%    1.83%     0     Snmp Flash Cache

SNMPログ：

 %SYS-2-SIGPENDING：プロセス91 -Process= "Snmp Flash Cache", ipl= 0, pid= 91に複数のシグナルが送信されます。

888888888888888888888888888888888888888888888898878889

625424254283314655456532533533772205363424335694492379

  100                                              *      *

  90 * *    *  *    *** ***  *  *  **  * *      ***    **

  80 ******************************************************

  70 ******************************************************

  60 ******************************************************

  50 ******************************************************

  40 ######################################################

  30 ######################################################

  20 ######################################################

  10 ######################################################

   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..

回避策は次のとおりです。

フラッシュMIBキャッシングが有効になっていると、SNMPのFlash CacheプロセスによってCPUの使用率が高くなる可能性があります。show running-config all | include snmp mib flash cacheを使用して設定状態を確認し、no snmp mib flash cacheを適用する前にプロセスCPUを検証します。

3. エラーメッセージ：「%SNMP-3-INPUT_QFULL_ERR:Packet dropped due to input queue full」

「queue full」エラーの考えられる原因は、デバイスでの過度のポーリングか、問題を引き起こす特定のOIDです。これを軽減するには、まず、デバイスが過度にポーリングされているかどうかを確認します。

これを行うには、次のコマンドを実行します。

Device#show snmp stats oid

time-stamp                                #of times requested            OID

15:40:19 BKK Dec 27 2019        11180008                           ifAlias

15:40:19 BKK Dec 27 2019        44018183                        dot1dBasePortEntry.4

15:40:19 BKK Dec 27 2019        44018212                        dot1dBasePortEntry.3

15:40:19 BKK Dec 27 2019        45216156                        ipNetToPhysicalEntry.4

15:40:19 BKK Dec 27 2019        44018059                        dot1dBasePortEntry.5

15:40:19 BKK Dec 27 2019        44578303                        dot1dBasePortEntry.1

15:40:19 BKK Dec 27 2019        6011756                        dot3StatsEntry.19

15:40:19 BKK Dec 27 2019        11095925                        ifSpeed

15:40:19 BKK Dec 27 2019        12879927                        dot1dTpFdbEntry.3

15:40:19 BKK Dec 27 2019        84535                              vmMembershipSummaryEntry.2

15:40:19 BKK Dec 27 2019        3241107                          vmMembershipSummaryEntry.3

15:40:19 BKK Dec 27 2019        45208908                        ipNetToMediaEntry.2

15:40:19 BKK Dec 27 2019        45223410                        ipNetToPhysicalEntry.6

15:40:19 BKK Dec 27 2019        44018324                        dot1dBasePortEntry.2

解決するには、以下を実行します。

NMSの設定を変更し、デバイスのポーリング間隔を短くする必要があります。ポーリング間隔を短くすると、キューがいっぱいになったエラーを軽減する必要があります。 そうでない場合は、問題を引き起こしているOIDを確認する必要があります。問題の原因となるOIDを特定し、そのOIDをトラブルシューティングするには、前述のエラーメッセージ1を参照してください。

4. エラーメッセージ：「High CPU utilization due to SNMP ENGINE」

問題の特定:

ルータでは、クライアントによってポーリングされる際に高いCPU使用率が発生します。これは、高いCPU使用率が発生する際にshow process cpu <sorted>コマンドを使用してチェックできます。SNMPエンジンプロセスがすべてのCPUリソースを使用していることがわかります。

Device#show processes cpu sorted

CPU utilization for five seconds: 99%/0%; one minute: 22%; five minutes: 18%

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

189     1535478456      697105815    2202    88.15%        13.40%            8.74%    0     SNMP ENGINE 

問題のあるOIDがあると、CPUの使用率が他のOIDよりも高くなり、クライアントがこのOIDを要求したときにタイムアウトが発生する可能性があります。ほとんどのメソッドは、より遅い応答を提供するOIDを見つけようとします。これは、CPUの使用率が高くなる原因となる可能性が最も高いためです。OIDを特定したら、エラーを軽減するために、そのOIDをロックできます。

注：ここに記載されているどの方法でも問題を引き起こすOIDを特定できない場合は、TACでサービスリクエストをオープンしてください。

方式 1.show snmp stats oidコマンドを使用します。

show snmp stats oid コマンドでは、ポーリングされた最後のOIDが表示されます。タイムスタンプを順番に表示します。目標は、応答が遅いOIDを特定することです。このコマンドは、クライアントによってポーリングされる頻度が高いMIBを見つける場合にも役立ちます。

Device#show snmp stats oid

time-stamp #of times     requested   OI

14:34:38 CET Oct 25 2020 24       atEntry.2

14:34:29 CET Oct 25 2020 40       atEntry.1

14:34:11 CET Oct 25 2020  11       ifOutErrors

14:34:07 CET Oct 25 2020 10       ifOutDiscards

14:34:06 CET Oct 25 2020 10       ifOutUcastPkts

14:34:06 CET Oct 25 2020 10      ifOutOctets

14:34:05 CET Oct 25 2020 10      ifInUnknownProtos

Entry.1の計算に18秒かかったことがわかります。これは、このデータを計算するためにCPUがビジーだったことを示します。

方式 2.SNMPクライアントを確認します。

デバイスの高いCPU使用率の原因となっているOIDを見つけるには、NMSサーバからデバイスへのsnmpwalkを開始し、出力を確認します。他のOIDよりも応答が遅いOIDは、高いCPU使用率の原因となる可能性があります。

解決するには、以下を実行します。

デバイスのSNMP設定をチェックします。 SNMPv2の場合は、次のように表示される必要があります。

snmp-server community TAC1 RO

snmp-server community TAC2 RO

• SNMPv3の場合

snmp-server view TESTV3 iso include

snmp-server group TestGroupV3  v3 auth read TESTV3

snmp-server user <username> TestGroupV3 v3 auth sha <auth-secret> priv aes 128 <priv-secret>

デバイスの設定モードに入り、SNMP設定にビューを追加して変更します。

• SNMPv2の場合

snmp-server community  TAC1 RO view cutdown RO

snmp-server community TAC2 RO view cutdown RO

コンフィギュレーションモードで次の行を追加します。問題の原因となるOIDを除外するという考えですが、除外しようとしているOIDの機能を確認してください。

snmp-server view cutdown iso included

snmp-server view cutdown <oid-subtree> excluded 

関連情報

• コンフィギュレーションガイド：章：SNMP
• シスコのテクニカルサポートとダウンロード

更新履歴

改定	発行日	コメント
5.0	17-Aug-2026	再認定
4.0	02-Apr-2025	更新された書式。
2.0	16-Feb-2023	フォーマットを更新。CCWアラートを修正。再認定
1.0	12-Jan-2022	初版