Einleitung
In diesem Dokument wird das Simple Network Management Protocol (SNMP) beschrieben, und es wird beschrieben, wie seine Funktionalität auf einem Gerät getestet wird.
Anforderungen
Voraussetzungen
Cisco empfiehlt, dass Sie über Kenntnisse des SNMP-Protokolls und seiner Kommunikation mit dem NMS-Server (Network Management System) verfügen.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
-
SNMP
-
Cisco WS-C3650-12X48UZ
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Fehlerbehebung bei den häufigsten Fehlern
1. Fehlermeldung: "%SNMP-3-RESPONSE_DELAYED: GetNext wird von "Any OID" verarbeitet."
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)
So beheben Sie Probleme:
Überprüfen Sie die SNMP-Konfiguration auf dem Gerät. Für SNMPv2 muss es wie folgt aussehen:
snmp-server community TAC1 RO
snmp-server community TAC2 RO --> If multiple communities are added to device.
Für 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
Wechseln Sie in den Konfigurationsmodus des Geräts, und fügen Sie eine Ansicht zur SNMP-Konfiguration hinzu, um das Gerät zu ändern.
Für SNMPv2:
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
Einige Posten aus dem Konfigurationsmodus:
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.
Für SNMPv3:
#snmp-server view TESTV3 internet included
#snmp-server view TESTV3 ciscoMgmt.810 excluded
#snmp-server group TestGroupV3 v3 priv write TESTV3
2. Fehlermeldung "Hohe CPU-Auslastung aufgrund von 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-Protokolle:
%SYS-2-SIGPENDING: Mehrere Signale werden an einen Prozess 91 -Process= "SNMP Flash Cache", ipl= 0, pid= 91 gesendet.
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..
Problemumgehung:
Der Datenerfassungsprozess von Flash MIB ist standardmäßig deaktiviert. Wenn sie mit dem Befehl "snmp mib flash cache" aktiviert wird (möglicherweise nach einem Neuladen), kann sie in einigen Fällen eine hohe CPU verursachen.
Verwenden Sie stattdessen im Konfigurationsmodus den Befehl #no snmp mib flash cache.
Oder installieren Sie dieses EEM-Skript:
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. Fehlermeldung: "%SNMP-3-INPUT_QFULL_ERR:Paket wegen voller Eingabewarteschlange verworfen"
Ein möglicher Grund für einen Fehler in der Warteschlange "Full" (Vollzugriff) kann ein umfangreiches Polling auf dem Gerät oder eine bestimmte OID sein, die das Problem verursacht. Stellen Sie zunächst sicher, dass das Gerät in hohem Maße abgefragt wird, um den Fehler zu beheben.
Führen Sie dazu den folgenden Befehl aus:
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
So beheben Sie Probleme:
Sie müssen die Einstellungen im NMS ändern und die Abfrageintervalle für das Gerät verkürzen. Sobald das Abfrageintervall reduziert ist, muss der Fehler "queue full" (Warteschlange voll) verringert werden. Ist dies nicht der Fall, müssen Sie nach der OID suchen, die das Problem verursacht. Die OID, die das Problem verursacht, und die entsprechende Fehlerbehebung finden Sie in der zuvor erwähnten Fehlermeldung 1.
4. Fehlermeldung: "Hohe CPU-Auslastung durch SNMP ENGINE".
Identifizieren Sie das Problem:
Der Router hat eine hohe CPU, wenn er von einem Client abgefragt wird, und dies kann mit dem Befehl #show process cpu <sorted> zum Zeitpunkt der hohen CPU überprüft werden. Sie können sehen, dass der SNMP-Modulprozess alle CPU-Ressourcen übernimmt:
#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
Die problematische OID führt dazu, dass die hohe CPU langsamer ist als die anderen, was ebenfalls zu einem Timeout führen kann, wenn der Client diese OID anfordert. Die meisten Methoden versuchen, die OID zu finden, die eine langsamere Antwort liefert. Dies liegt daran, dass sie die Ursache für die hohe CPU am ehesten sind. Sobald die OID identifiziert wurde, können Sie diese OID sperren, um die Fehler zu beheben.
Hinweis: Wenn keine der hier aufgeführten Methoden zur Identifizierung einer OID beiträgt, die das Problem verursacht, erstellen Sie ein Ticket beim TAC.
Methode 1: Verwenden Sie den Befehl show snmp stats oid.
Der Befehl show snmp stats oid zeigt die zuletzt abgefragte OID an. Es zeigt den Zeitstempel in der Reihenfolge, das Ziel ist es, die OID, die langsam reagiert identifizieren. Dieser Befehl ist auch hilfreich, wenn Sie ermitteln möchten, welche MIBs häufiger vom Client abgefragt werden.
#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
Sie sehen, dass Entry.1 18 Sekunden benötigte, um berechnet zu werden. Dies deutet darauf hin, dass die CPU ausgelastet war, um diese Daten zu berechnen.
Methode 2. Beobachten des SNMP-Clients
Um die OID zu finden, die für die hohe CPU-Auslastung auf dem Gerät verantwortlich ist, können Sie von einem NMS-Server eine Verbindung snmpwalk zu einem Gerät initiieren und die Ausgabe beobachten. Die OIDs, die langsamer reagieren als die anderen OIDs, können für eine hohe CPU-Auslastung verantwortlich sein.
So beheben Sie Probleme:
Überprüfen Sie die SNMP-Konfiguration auf dem Gerät. Für SNMPv2 muss es wie folgt aussehen:
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
Wechseln Sie in den Konfigurationsmodus des Geräts, und fügen Sie eine Ansicht zur SNMP-Konfiguration hinzu, um das Gerät zu ändern.
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
Fügen Sie im Konfigurationsmodus die folgenden Posten hinzu:
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.
Zugehörige Informationen
Feedback