Introduzione
Questo documento descrive un approccio strutturato per risolvere i problemi e l'elevato utilizzo della CPU nel processo SNMP su un controller LAN wireless 9800.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- Controller wireless: C9800-80-K9 con esecuzione il 17.9.03
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.
Raccolta registri
Identificazione dei modelli di utilizzo della CPU Dopo aver ricevuto un report sull'utilizzo elevato della CPU collegato al processo SNMP, la prima azione da eseguire consiste nella raccolta di registri dettagliati in un intervallo di tempo specificato. Ciò aiuterà a stabilire un modello o una tendenza nell'uso della CPU, essenziale per individuare i momenti in cui il processo SNMP è più attivo e ad uso intensivo delle risorse.
Prima di iniziare la raccolta dei log, è essenziale raccogliere informazioni specifiche utilizzate per supportare il processo di risoluzione dei problemi. Iniziare raccogliendo alcune informazioni relative al problema.
- Il sistema presenta picchi o un utilizzo elevato e costante?
- Qual è la percentuale di utilizzo in entrambi i casi?
- Qual è la frequenza di utilizzo elevato della CPU?
- Con quale frequenza ogni server SNMP esegue il polling sul WLC?
- Chi sono i migliori oratori?
Raccogli l'output del comando da 9800 WLC a intervalli di due minuti in un intervallo di dieci minuti. Questi dati possono essere utilizzati per analizzare i problemi di utilizzo elevato della CPU, in particolare quelli relativi al processo SNMP.
#terminal length 0
#show clock
#show process cpu sorted | exclude 0.0
#show process cpu history
#show processes cpu platform sorted | exclude 0.0
#show snmp stats oid
#show snmp stats hosts
Analisi dei log
Dopo aver raccolto questi log, è necessario analizzarli per comprenderne l'impatto.
Esaminiamo un esempio di log relativi all'utilizzo della CPU e identifichiamo il processo SNMP che utilizza la maggior parte della CPU.
WLC#show process cpu sorted | exclude 0.0
CPU utilization for five seconds: 96%/7%; one minute: 76%; five minutes: 61%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
250 621290375 58215467 10672 58.34% 39.84% 34.11% 0 SNMP LA Cache pr <-- High utilization
93 167960640 401289855 418 14.50% 11.88% 9.23% 0 IOSD ipc task
739 141604259 102242639 1384 8.57% 6.95% 7.21% 0 SNMP ENGINE
763 7752 34896 222 4.00% 3.41% 1.83% 5 SSH Process
648 6216707 181047548 34 0.72% 0.37% 0.31% 0 IP SNMP
376 3439332 51690423 66 0.40% 0.36% 0.25% 0 SNMP Timers
143 3855538 107654825 35 0.40% 0.35% 0.23% 0 IOSXE-RP Punt Se
108 6139618 17345934 353 0.40% 0.30% 0.34% 0 DBAL EVENTS
Output della CPU del processo di visualizzazione ordinato | Il comando exclude 0.0 indica che il processo SNMP sta effettivamente utilizzando una quantità sproporzionata di risorse CPU. In particolare, il processo SNMP LAN Cache per è quello che comporta il maggior utilizzo di CPU, seguito da altri processi correlati a SNMP.
Il prossimo gruppo di comandi ci aiuterà a eseguire il drill-down nel processo SNMP ad alto utilizzo.
WLC#show snmp stats oid
time-stamp #of times requested OID
11:02:33 Austral Jun 8 2023 27698 bsnAPIfDBNoisePower <-- Frequently polled OID
11:02:23 Austral Jun 8 2023 1 sysUpTime
11:02:23 Austral Jun 8 2023 17 cLSiD11SpectrumIntelligenceEnable
11:02:23 Austral Jun 8 2023 1 cLSiD11SpectrumIntelligenceEnable
11:02:23 Austral Jun 8 2023 6 cLSiD11Band
11:02:23 Austral Jun 8 2023 1 cLSiD11Band
11:02:23 Austral Jun 8 2023 1 cLSiD11Band
11:02:23 Austral Jun 8 2023 1 cLSiD11Band
11:02:19 Austral Jun 8 2023 24 clcCdpApCacheApName
11:02:19 Austral Jun 8 2023 1 clcCdpApCacheDeviceIndex
11:02:19 Austral Jun 8 2023 9 cLApCpuAverageUsage
11:02:19 Austral Jun 8 2023 1315 cLApCpuCurrentUsage
11:02:19 Austral Jun 8 2023 2550 bsnAPIfDBNoisePower
L'output del comando show snmp stats oid visualizza la frequenza di polling dei vari OID. Un particolare OID, bsnAPIfDBNoisePower, si distingue per il numero eccezionalmente elevato di richieste. Ciò suggerisce che il polling aggressivo di questo OID contribuisce probabilmente all'elevato utilizzo della CPU osservato sul WLC.
Cerchiamo di comprendere le funzioni di OID bsnAPIfDBNoisePower e i relativi tempi di archiviazione dei dati.
Passare a SNMP Object Navigator e cercare l'OID "bsnAPIfDBNoisePower".
Risultato ricerca OID
A questo punto è possibile comprendere che l'oggetto bsnAPIfDBNoisePower indica la potenza di rumore di ogni canale in base a quanto segnalato da ogni punto di accesso. Dato il numero elevato di canali e access point gestiti dal WLC, i dati SNMP generati da questo OID possono essere sostanziali. Quando il WLC serve un numero elevato di access point, il volume di dati generato dal polling di questo OID può essere immenso. Ciò può portare a un elevato utilizzo della CPU, poiché il WLC elabora queste richieste SNMP estese.
Analogamente, è necessario comprendere il comportamento dell'OID specifico oggetto di polling aggressivo.
Il comando successivo consente di conoscere i server SNMP su cui viene eseguito il polling del WLC.
WLC#show snmp stats hosts
Request Count Last Timestamp Address
77888844 00:00:00 ago 10.10.10.120
330242 00:00:08 ago 10.10.10.150
27930314 00:00:09 ago 10.10.10.130
839999 00:00:36 ago 10.10.10.170
6754377 19:45:34 ago 10.10.10.157
722 22:00:20 ago 10.10.10.11
Questo comando fornisce un elenco di server SNMP con il numero di richieste e l'ultimo timestamp dell'attività di polling.
Potete vedere che ci sono diversi server che eseguono il polling del WLC 9800. Se si esaminano i dati completi dei log raccolti negli ultimi 10 minuti, è possibile misurare anche la frequenza di polling.
A questo punto è possibile passare a ciascun server e verificare la frequenza con cui viene eseguito il polling dell'OID che causa il problema. In questo caso di esempio, il polling dell'OID viene eseguito ogni 30 secondi, con una frequenza notevolmente superiore al necessario. Poiché il WLC riceve i dati RF/RRM ogni 180 secondi, il polling dell'OID ogni 30 secondi genera un'elaborazione non necessaria e contribuisce all'elevato utilizzo della CPU.
Una volta identificati l'OID che causa il problema e il server, possiamo provare diverse soluzioni per ridurre il carico sul WLC.
- Ridurre la frequenza di polling sul server SNMP.
- Se l'OID non è necessario per l'utilizzo dell'operazione, disattivare il polling di tale OID dal server SNMP.
- Se non si ha il controllo del server SNMP, è possibile utilizzare la visualizzazione SNMP per bloccare l'OID in conflitto.
SNMP View Configuration
Definite una nuova vista che escluda l'OID da bloccare. Ad esempio, si desidera bloccare OID 1.3.6.1.4.1.14179.2.2.15.1.21, creare una nuova vista e collegare l'OID alla vista.
snmp-server view blockOIDView 1.3.6.1.4.1.14179.2.2.15.1.21 excluded <-- This is the OID of bsnAPIfDBNoisePower
snmp-server community TAC view blockOIDView RO <-- This command assigns the blockOIDView to the community myCommunity with read-only (RO) access.
snmp-server group TAC v3 priv read blockOIDView <-- This command assigns the blockOIDView to the group myGroup with the priv security level for SNMPv3.
Suggerimento per la risoluzione dei problemi
- Utilizzo CPU di base: documenta i normali livelli di utilizzo della CPU quando il processo SNMP non causa un utilizzo elevato.
- Configurazione SNMP: rivedere le impostazioni di configurazione SNMP correnti, incluse le stringhe della community, la versione (v2c o v3) e gli elenchi degli accessi.
- Best Practice SNMP: utilizzare il documento sulle best practice del WLC 9800 e verificare che la configurazione consigliata per il protocollo SNMP sia il più simile possibile.
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- Frequenza del polling SNMP: determinare la frequenza con cui il WLC viene sottoposto a polling da query SNMP, in quanto una frequenza elevata potrebbe contribuire a un aumento del carico della CPU.
- Network Topology and SNMP Manager: comprendere la configurazione della rete e identificare tutti i manager SNMP che interagiscono con il WLC.
- Tempo di attività del sistema: controllare il tempo trascorso dall'ultimo riavvio per verificare se esiste una correlazione tra il tempo di attività e l'utilizzo della CPU.
- Modifiche recenti: prendere nota di eventuali modifiche recenti apportate alla configurazione o alla rete WLC che possono aver coinciso con l'inizio di un elevato utilizzo della CPU.
- Con 9800 WLC, l'attenzione è stata posta sulla telemetria. La telemetria funziona in un modello "push" in cui il WLC invia informazioni rilevanti al server senza che sia necessario interrogarlo. Se le query SNMP utilizzano cicli della CPU WLC e causano problemi operativi, è preferibile passare alla telemetria.
Conclusioni
Analizzando metodicamente i dati sull'utilizzo della CPU e correlandoli con le attività di polling SNMP, è possibile risolvere i problemi di utilizzo elevato della CPU causati dai processi SNMP sul Cisco 9800 WLC. Il monitoraggio successivo all'implementazione è essenziale per confermare il successo delle operazioni di risoluzione dei problemi e per mantenere prestazioni di rete ottimali.
Informazioni correlate