Sommario

Introduzione

Componenti usati

Raccolta registri

Analisi dei log

SNMP View Configuration

Suggerimento

Conclusioni

Informazioni correlate

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 versione 17.09.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 | exclude 0.0 indica che il processo SNMP utilizza 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.

1. Ridurre la frequenza di polling sul server SNMP.

2. Se l'OID non è necessario per l'utilizzo dell'operazione, disattivare il polling di tale OID dal server SNMP.

3. 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: Documentare 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, tra cui 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 suggerita per il protocollo SNMP sia la 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 di polling SNMP: Determinare la frequenza di polling del WLC da parte delle query SNMP, in quanto una frequenza elevata potrebbe contribuire a un aumento del carico della CPU.

- Gestori della topologia di rete e SNMP: 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 qualsiasi modifica recente apportata alla configurazione o alla rete WLC che possa essere coincisa 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

- Monitoraggio di Catalyst 9800 WLC tramite SNMP con OID

- Gestione dei controller wireless Catalyst serie 9800 con Prime Infrastructure con SNMP V2 e V3 e NetCONF

- Protocollo SCEP (Simple Network Management Protocol)

- Best practice per la configurazione di Cisco Catalyst serie 9800