排除SNMP基本功能故障
簡介
本檔案介紹一些簡易網路管理通訊協定(SNMP)疑難排解案例。
必要條件
需求
思科建議您瞭解：
- SNMPv2c和SNMPv3協定操作
- Cisco IOS® XE命令列介面(CLI)
採用元件
本文中的資訊係根據以下軟體和硬體版本：
-
Cisco Catalyst 3650系列交換器
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
對最常見的錯誤進行故障排除
1.錯誤消息：%SNMP-3-RESPONSE_DELAYED:正在處理<OID>（<elapsed-time>毫秒）的GetNext
在本示例中，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.錯誤消息「由於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
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快閃記憶體快取進程可能會佔用高CPU。使用show running-config all確認已配置狀態 | include snmp mib flash cache and validate process CPU before applying no snmp mib flash cache。
3.錯誤消息："%SNMP-3-INPUT_QFULL_ERR：由於輸入隊列已滿而丟棄的資料包"
隊列滿錯誤的可能原因可能是裝置上的大量輪詢或導致問題的特定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並對其進行故障排除，請參閱前面提到的錯誤消息1。
4.錯誤消息：「由於SNMP引擎而導致CPU使用率高」。
確定問題：
當客戶端輪詢路由器時，該路由器的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以緩解錯誤。
方法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伺服器啟動到裝置的掃描，並觀察輸出。響應速度慢於其他OID的OID可能是導致CPU使用率較高的OID。
要排除故障，請執行以下操作：
檢查裝置上的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>
附註：使用符合組織憑據策略的唯一機密。確認SHA和AES語法以及所記錄的Cisco IOS XE版本的支援。
進入裝置的配置模式並將檢視新增到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
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
5.0 |
17-Aug-2026
|
重新認證 |
4.0 |
02-Apr-2025
|
更新的格式。 |
3.0 |
28-Mar-2024
|
重新認證。 |
2.0 |
16-Feb-2023
|
已更新格式。已更正CCW警報。重新認證。 |
1.0 |
12-Jan-2022
|
初始版本 |
意見