はじめに
このドキュメントでは、Simple Network Management Protocol（SNMP；簡易ネットワーク管理プロトコル）とその機能をデバイスでテストする方法について説明します。
要件
前提条件
SNMPプロトコルと、ネットワーク管理システム(NMS)サーバとの通信に関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
-
SNMP
-
Cisco WS-C3650-12X48UZ
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
表記法
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
最も一般的なエラーのトラブルシューティング
1.エラーメッセージ：「%SNMP-3-RESPONSE_DELAYED: processing GetNext of "Any OID".」
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..
次の方法で回避できます。
フラッシュ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:Packet dropped due to input queue full」
キューフルエラーの原因としては、デバイスでの過度のポーリング、または問題を引き起こす特定の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 Engineプロセスがすべての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があると、CPU使用率が他のOIDよりも高くなり、クライアントがこの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を見つけるには、NMSサーバからデバイス snmpwalk への接続を開始し、出力を確認します。他のOIDよりも応答が遅いOIDは、高いCPU使用率を引き起こす可能性があります。
トラブルシューティング：
デバイスのSNMP設定をチェックします。 SNMPv2では、次のように表示される必要があります。
snmp-server community TAC1 RO
snmp-server community TAC2 RO --> If multiple communities are added to snmp.
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設定に追加して変更します。
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.
関連情報
フィードバック