目錄

簡介

需求

必要條件

採用元件

慣例

對最常見的錯誤進行故障排除

相關資訊

簡介

本檔案介紹簡易網路管理通訊協定(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，可以啟動  snmpwalk 從NMS伺服器連線到裝置並觀察輸出。響應速度慢於其他OID的OID可能是導致CPU使用率較高的OID。

要排除故障，請執行以下操作：

檢查裝置上的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

- 思科技術支援與下載