内容

概要

要件

前提条件

使用するコンポーネント

表記法

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

関連情報

概要

このドキュメントでは、Simple Network Management Protocol（SNMP；簡易ネットワーク管理プロトコル）とその機能をデバイスでテストする方法について説明します。

要件

前提条件

SNMPプロトコルおよびネットワーク管理システム(NMS)サーバとの通信に関する知識があることが推奨されます。

使用するコンポーネント

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

- SNMP

- Cisco WS-C3650-12X48UZ

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

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

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

1.エラーメッセージ： "%SNMP-3-RESPONSE_DELAYED: "Any OID"のGetNextを処理しています。"

GetNext of ciscoMgmt.810.1.2.1.1 (24004 msecs)

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

---> In this scenario ciscoMgmt.810.1.2.1.1 is the OID causes the issue.

*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設定をチェックします。 SNMPv2では、次のように表示する必要があります。

snmp-server community TAC1 RO

snmp-server community TAC2 RO  --> If multiple communities are added to device.

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設定にビューを追加して変更します。

SNMPv2の場合

snmp-server community  TAC1 RO view cutdown RO

snmp-server community TAC2 RO view cutdown RO

コンフィギュレーションモードの一部の行を次に示します。

snmp-server view cutdown iso included

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

The Idea is to exclude the OID causes the issue, however,

please read out what is the function of the OID that that is excluded.

SNMPv3の場合

#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」

#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..

回避策：

Flash MIBデータ収集プロセスは、デフォルトでは無効になっています。snmp mib flash cacheコマンドを使用して（おそらくリロード後に）イネーブルにすると、場合によってはCPUの使用率が高くなる可能性があります。

その代わりに コンフィギュレーションモードで#no snmp mib flash cacheコマンドを使用します。

または、次のEEMスクリプトをインストールします。

event manager applet SNMP authorization bypass

event syslog pattern "SYS-5-RESTART"

action 11 cli command "enable"

action 12 cli command "conf t"

action 13 cli command "no snmp mib flash cache"

action 14 cli command "end"

3.エラーメッセージ：「%SNMP-3-INPUT_QFULL_ERR：入力キューがいっぱいになったためにパケットがドロップされました」

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

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

B02#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リソースを使用していることがわかります。

#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は、他のOIDよりも高いCPU使用率を引き起こし、クライアントがこのOIDを要求したときにタイムアウトが発生する可能性があります。ほとんどのメソッドは、応答が遅いOIDを見つけようとします。これは、CPU使用率が高くなる可能性が最も高いためです。OIDが特定されたら、エラーを軽減するために、それぞれのOIDをロックできます。

注：問題の原因となるOIDを特定するのに役立つ方法がいずれも表示されない場合は、TACでサービスリクエストをオープンしてください。

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

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

#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を見つけるには、  snmpwalk NMSサーバからデバイスに送信し、出力を確認します。他のOIDよりも応答が遅いOIDは、高いCPU使用率を引き起こす可能性があります。

トラブルシューティング：

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

snmp-server community TAC1 RO

snmp-server community TAC2 RO --> If multiple communities are added to snmp.

- 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設定にビューを追加して変更します。

- SNMPv2の場合

snmp-server community  TAC1 RO view cutdown RO

snmp-server community TAC2 RO view cutdown RO

コンフィギュレーションモードで次の行を追加します。

snmp-server view cutdown iso included

snmp-server view cutdown OID _causes_the issue_is _to_excluded  excluded

-->>> The Idea is to exclude the OID causes the issue, however,

please read out what is the function of the OID that  we are about to exclude.

関連情報

- SNMP

- シスコテクニカルサポートおよびダウンロード