Problemen met de basisfunctionaliteit van SNMP oplossen

Inleiding

In dit document worden enkele scenario's beschreven voor het oplossen van problemen met Simple Network Management Protocol (SNMP).

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van:

• SNMPv2c- en SNMPv3-protocolbewerking
• Cisco IOS® XE Command Line Interface (CLI)

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Cisco Catalyst 3650-serie Switch

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Problemen met meest voorkomende fouten oplossen

1. Foutbericht: "%SNMP-3-RESPONSE_DELAYED: verwerking van GetNext van <OID> (<verstreken-time> msecs)"

In dit voorbeeld is ciscoMgmt.810.1.2.1.1 de OID die is gekoppeld aan het vertraagde GetNext-verzoek. Correleer herhaalde berichten met CPU-gebruik, NMS-polling records en release-specifieke defecten voordat u de oorzaak identificeert:

*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)

Problemen oplossen:

Controleer de SNMP-configuratie op het apparaat. Voor SNMPv2c lijkt het op de uitvoer als er meerdere communities aan het apparaat worden toegevoegd:

snmp-server community TAC1 RO

snmp-server community TAC2 RO  --> 

Voor 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

Voer de configuratiemodus van het apparaat in en voeg een weergave toe aan de SNMP-configuratie.

Voor SNMPv2c:

snmp-server community TAC1 RO view cutdown RO

snmp-server community TAC2 RO view cutdown RO

Het idee is om de OID die het probleem veroorzaakt uit te sluiten, maar bekijk alsjeblieft wat de functie van de OID is die kan worden uitgesloten voordat u wijzigingen aanbrengt:

snmp-server view cutdown iso included

snmp-server view cutdown ciscoMgmt.810 excluded -->>> 

Voor SNMPv3 wordt de weergave-uitsluiting toegepast met de opdracht snmp-servergroep:

snmp-server view TESTV3 internet included

snmp-server view TESTV3 ciscoMgmt.810 excluded

snmp-server group TestGroupV3 v3 priv write TESTV3 

2. Foutbericht "Hoog CPU-gebruik door SNMP Flash Cache".

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-logboeken:

 %SYS-2-SIGPENDING: meerdere signalen worden verzonden naar een proces 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..

Om een omweg te maken:

Het SNMP Flash Cache-proces kan een hoge CPU verbruiken wanneer Flash MIB-caching is ingeschakeld. Bevestig de geconfigureerde status met show running-config all | voeg snmp mib flash cache toe en valideer proces CPU voordat u geen snmp mib flash cache toepast.

3. Foutbericht: "%SNMP-3-INPUT_QFULL_ERR: Pakket is gedropt vanwege volledige invoerwachtrij"

Een mogelijke reden voor een volledige wachtrijfout kan zware polling op het apparaat of een specifieke OID zijn die het probleem veroorzaakt. Om dit te verzachten, controleert u eerst of het apparaat zwaar is ondervraagd.

Voer hiervoor het volgende commando uit:

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

Problemen oplossen:

U moet de instellingen op uw NMS wijzigen en de stemintervallen voor het apparaat verminderen. Zodra het steminterval is verminderd, moet de volledige fout in de wachtrij worden beperkt. Zo niet, dan moet u controleren op de OID die het probleem veroorzaakt. Om de OID te vinden die het probleem veroorzaakt en om problemen op dezelfde manier op te lossen, raadpleegt u het eerder genoemde foutbericht 1.

4. Foutmelding: "Hoog CPU-gebruik door SNMP-ENGINE".

Identificeer het probleem:

De router heeft een hoge CPU op het moment dat deze door een client wordt gepolst, en dit kan worden gecontroleerd met de show process cpu <sorted> opdracht op het moment van de hoge CPU. U kunt zien dat het SNMP Engine-proces alle CPU-bronnen in beslag neemt:

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 

De problematische OID zorgt ervoor dat de hoge CPU langzamer is dan de andere, wat ook een time-out kan veroorzaken wanneer de klant deze OID aanvraagt. De meeste methoden proberen de OID te vinden die een langzamer antwoord biedt. Dat komt omdat ze het meest waarschijnlijk de hoge CPU veroorzaken. Zodra de OID is geïdentificeerd, kunt u die respectieve OID vergrendelen om de fouten te beperken.

Opmerking: als geen van de hier vermelde methoden helpt om een OID te identificeren die het probleem veroorzaakt, opent u een zaak met TAC.

Methode 1. Gebruik de opdracht snmp stats oid weergeven.

De opdracht snmp stats oid weergeven geeft de laatste OID weer die is gepolst. Het geeft de tijdstempel in volgorde weer, het doel is om de OID te identificeren die langzaam reageerde. Deze opdracht is ook handig als u wilt vinden welke MIB's vaker door de klant worden ondervraagd.

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

Je kunt zien dat Entry.1 18 seconden nodig had om te worden berekend. Dit suggereert dat de CPU bezig was om deze gegevens te berekenen.

Methode 2. Observeer de SNMP-client.

Om de OID te vinden die verantwoordelijk is voor het hoge CPU-gebruik op het apparaat, kunt u een snapwalk naar een apparaat starten vanaf een NMS-server en de uitvoer observeren. De OID's die langzamer reageren dan de andere OID's, kunnen verantwoordelijk zijn voor een hoog CPU-gebruik.

Problemen oplossen:

Controleer de SNMP-configuratie op het apparaat. Voor SNMPv2 moet het er als volgt uitzien:

snmp-server community TAC1 RO

snmp-server community TAC2 RO

• Voor 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>

Voer de configuratiemodus van het apparaat in en voeg een weergave toe aan de SNMP-configuratie om deze te wijzigen.

• Voor SNMPv2

snmp-server community  TAC1 RO view cutdown RO

snmp-server community TAC2 RO view cutdown RO

Voeg deze regels toe in de configuratiemodus. Het idee is om de OID die het probleem veroorzaakt uit te sluiten, maar lees alstublieft wat de functie van de OID is die u op het punt staat uit te sluiten:

snmp-server view cutdown iso included

snmp-server view cutdown <oid-subtree> excluded 

Gerelateerde informatie

• Configuratiehandleiding: Hoofdstuk: SNMP
• Cisco Technical Support en downloads

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
5.0	17-Aug-2026	hercertificering
4.0	02-Apr-2025	Opmaak bijgewerkt.
3.0	28-Mar-2024	Hercertificering.
2.0	16-Feb-2023	Bijgewerkt formaat. Gecorrigeerde CCW-waarschuwingen. Hercertificering.
1.0	12-Jan-2022	Eerste vrijgave