Introduzione
Questo documento descrive il protocollo SNMP (Simple Network Management Protocol) e come testarne la funzionalità su un dispositivo.
Requisiti
Prerequisiti
Cisco raccomanda la conoscenza del protocollo SNMP e delle sue comunicazioni con il server Network Management System (NMS).
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
-
SNMP
-
Cisco WS-C3650-12X48UZ
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Risoluzione degli errori più comuni
1. Messaggio di errore: "%SNMP-3-RESPONSE_DELAYED: elaborazione di GetNext di "Any OID"."
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)
Per risolvere i problemi:
Controllare la configurazione SNMP sul dispositivo. Per SNMPv2, deve avere questo aspetto:
snmp-server community TAC1 RO
snmp-server community TAC2 RO --> If multiple communities are added to device.
Per 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
Immettere la modalità di configurazione del dispositivo e aggiungere una vista alla configurazione SNMP per modificarla.
Per SNMPv2:
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
Alcune righe della modalità di configurazione:
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.
Per SNMPv3:
#snmp-server view TESTV3 internet included
#snmp-server view TESTV3 ciscoMgmt.810 excluded
#snmp-server group TestGroupV3 v3 priv write TESTV3
2. Messaggio di errore "High CPU Utilization due to SNMP Flash Cache" (Utilizzo elevato della CPU dovuto alla cache flash SNMP).
#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
Log SNMP:
%SYS-2-SIGPENDING: più segnali vengono inviati a un processo 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..
Per risolvere il problema:
Il processo di raccolta dei dati MIB Flash è disabilitato per impostazione predefinita. Se viene abilitata con il comando snmp mib flash cache (probabilmente dopo un ricaricamento), in alcuni casi può causare un elevato livello di CPU.
Usare al suo posto il comando #no snmp mib flash cache in modalità di configurazione.
In alternativa, installare lo script 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. Messaggio di errore: "%SNMP-3-INPUT_QFULL_ERR:Packet interrotto a causa di coda di input piena"
Un possibile motivo per un errore di coda completa può essere il polling intenso sul dispositivo o un OID specifico che causa il problema. Per evitare questo problema, verificare innanzitutto se il polling del dispositivo è elevato.
A tale scopo, eseguire questo comando:
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
Per risolvere i problemi:
È necessario modificare le impostazioni del sistema NMS e ridurre gli intervalli di polling per il dispositivo. Una volta ridotto l'intervallo di polling, è necessario ridurre l'errore di coda piena. In caso contrario, è necessario verificare l'OID che causa il problema. Per individuare l'OID che causa il problema e per risolvere il problema, fare riferimento al messaggio di errore 1 precedentemente indicato.
4. Messaggio di errore: "Utilizzo elevato della CPU dovuto a SNMP ENGINE".
Identificare il problema:
Il router ha una CPU alta quando viene sottoposto al polling da parte di un client. Per controllare il problema, usare il comando #show process cpu <sort> quando la CPU è alta. È possibile notare che il processo SNMP Engine utilizza tutte le risorse 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
L'OID problematico rallenta la CPU rispetto alle altre e potrebbe causare un timeout quando il client richiede l'OID. La maggior parte dei metodi tenta di trovare l'OID che fornisce una risposta più lenta. Ciò è dovuto al fatto che è più probabile che causino l'utilizzo di CPU elevate. Una volta identificato l'OID, è possibile bloccarlo per ridurre gli errori.
Nota: se nessuno dei metodi elencati aiuta a identificare un OID che causa il problema, aprire una richiesta con TAC.
Metodo 1. Usare il comando show snmp stats oid.
Il comando show snmp stats oid visualizza l'ultimo OID sottoposto a polling. Visualizza il timestamp in ordine, l'obiettivo è identificare l'OID che ha risposto lentamente. Questo comando è utile anche per individuare i MIB su cui il client esegue il polling con maggiore frequenza.
#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
È possibile notare che Entry.1 ha impiegato 18 secondi per il calcolo, il che suggerisce che la CPU era occupata per il calcolo di questi dati.
Metodo 2. Osservare il client SNMP.
Per individuare l'OID responsabile dell'utilizzo elevato della CPU sul dispositivo, è possibile avviare un collegamento snmpwalk a un dispositivo da un server NMS e osservare l'output. Gli OID che rispondono più lentamente rispetto agli altri OID possono essere responsabili di un elevato utilizzo della CPU.
Per risolvere i problemi:
Controllare la configurazione SNMP sul dispositivo. Per SNMPv2, deve avere il seguente aspetto:
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
Immettere la modalità di configurazione del dispositivo e aggiungere una vista alla configurazione SNMP per modificarla.
snmp-server community TAC1 RO view cutdown RO
snmp-server community TAC2 RO view cutdown RO
Aggiungere le righe seguenti in modalità di configurazione:
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.
Informazioni correlate
Feedback