簡介
本檔案介紹簡易網路管理通訊協定(SNMP)以及如何在裝置上測試其功能。
需求
必要條件
Cisco建議您瞭解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.錯誤消息「由於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
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並對其進行故障排除，請參閱前面提到的錯誤消息1。
4.錯誤消息：「由於SNMP ENGINE導致CPU使用率高」。
確定問題：
當客戶端輪詢路由器時，該路由器的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使用率較高的OID。
要排除故障，請執行以下操作：
檢查裝置上的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.
相關資訊
意見