はじめに
このドキュメントでは、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」
「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エンジンプロセスがすべての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.
関連情報
フィードバック