Inhoud

Inleiding

Gebruikte componenten

Logboekverzameling

Logboekanalyse

SNMP-weergaveconfiguratie

Tip voor probleemoplossing

Conclusie

Gerelateerde informatie

Inleiding

Dit document beschrijft een gestructureerde benadering voor probleemoplossing en het oplossen van een hoog CPU-gebruik naar het SNMP-proces op een 9800 draadloze LAN-controller.

Gebruikte componenten

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

- Draadloze controller: C9800-80-K9 met 17.09.03

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.

Logboekverzameling

Het identificeren van CPU-gebruikspatronen Bij het ontvangen van een rapport van hoog CPU-gebruik dat is gekoppeld aan het SNMP-proces, is de eerste manier van handelen om gedetailleerde logbestanden te verzamelen over een gespecificeerd tijdskader. Dit zal helpen bij het vaststellen van een patroon of trend in CPU-gebruik, wat essentieel is om de tijden aan te geven waarop het SNMP-proces het meest actief en bron-intensief is.

Alvorens met de logboekinzameling te beginnen, is het noodzakelijk om specifieke informatie te verzamelen die wordt gebruikt om het proces van het oplossen van problemen te steunen. Begin met het verzamelen van weinig informatie over het probleem.

- Ondervindt het systeem spikes of wordt het altijd veel gebruikt?

- Wat is het benuttingspercentage in beide gevallen?

- Wat is de frequentie van een hoog CPU-gebruik?

- Hoe vaak elke SNMP-server de WLC aan het pollen is?

- Wie zijn de beste talkers?

Verzamel de opdrachtoutput van 9800 WLC met intervallen van twee minuten over een periode van tien minuten. Deze gegevens kunnen worden gebruikt om problemen met een hoog CPU-gebruik te analyseren, met name die welke betrekking hebben op het SNMP-proces.

#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

Logboekanalyse

Na het verzamelen van deze logboeken, moet u ze analyseren om de impact te begrijpen.

Laten we eens kijken naar voorbeelden van CPU-gebruikslogboeken en het SNMP-proces identificeren dat de meeste CPU’s verbruikt.

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

De uitvoer van het cpu van het showproces is gesorteerd | sluit 0.0 uit-opdracht geeft aan dat het SNMP-proces inderdaad een onevenredig aantal CPU-bronnen verbruikt. Met name de SNMP LA Cache per proces is de meest CPU-intensieve, gevolgd door andere SNMP-gerelateerde processen.

De volgende reeks opdrachten zal ons helpen om terug te boren naar het SNMP-proces voor hoog gebruik.

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

De output van de show snmp stats oid opdracht onthult de frequentie waarmee verschillende OIDs worden opgezocht. Een bepaalde OID, bsnAPIfDBNoisePower, valt op door zijn uitzonderlijk hoge aantal verzoeken. Dit suggereert dat agressieve polling van deze OID waarschijnlijk bijdraagt aan het hoge CPU-gebruik zoals waargenomen bij de WLC.

Laten we proberen te begrijpen wat de OID bsnAPIfDBNoisePower doet en zijn data-opslagtijden.

Navigeer naar SNMP Object Navigator en zoek in de OID "bsnAPIfDBNoisePower".

OID-zoekresultaat

Nu begrijp je dat het object bsnAPIfDBNoisePower de ruiskracht van elk kanaal rapporteert zoals gerapporteerd door elke AP. Gezien het grote aantal kanalen en AP's dat door de WLC wordt beheerd, kunnen de SNMP-gegevens die door deze OID worden gegenereerd aanzienlijk zijn. Wanneer WLC een groot aantal APs dient, kan het volume van gegevens die door het krijgen van dit OID worden geproduceerd immens zijn. Dit kan leiden tot een hoog CPU-gebruik omdat de WLC deze uitgebreide SNMP-verzoeken verwerkt.

Op dezelfde manier moet je het gedrag van de specifieke OID begrijpen die agressief wordt gepolled.

De volgende opdracht zal u helpen de SNMP-servers te kennen die de WLC aan het pollen zijn.

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

Deze opdracht geeft een lijst van SNMP-servers, samen met hun verzoektellingen en de laatste tijdstempel van hun opiniepeilingsactiviteit.

Je kunt zien dat er meerdere verschillende servers zijn die de 9800 WLC aan het pollen zijn. Als u kijkt naar de complete logbestanden gegevens verzameld tijdens de laatste 10 minuten kunt u ook hun pollingfrequentie meten.

Nu kunt u naar elke server gaan en zien hoe vaak de beledigende OID wordt opgezocht. In dit voorbeeld wordt de OID om de 30 seconden gepolijst, wat aanzienlijk vaker is dan nodig. Aangezien de WLC RF/RRM gegevens elke 180 seconden ontvangt, resulteert het pollen van de OID elke 30 seconden in onnodige verwerking en draagt bij aan een hoog CPU-gebruik.

Zodra de beledigende OID en de server zijn geïdentificeerd, kunnen we meerdere verschillende oplossingen proberen om de belasting op de WLC te verminderen.

1. Verlaag de opiniefrequentie op de SNMP-server.

2. Als de OID niet nodig is voor het gebruik van de bediening, schakelt u de polling van die OID uit op de SNMP-server.

3. Als u geen controle over de SNMP-server hebt, kunt u de SNMP-weergave gebruiken om de aanstootgevende OID te blokkeren.

SNMP-weergaveconfiguratie

Definieer een nieuwe weergave die de OID uitsluit die u wilt blokkeren. U wilt bijvoorbeeld de OID 1.3.6.1.4.1.14179.2.2.15.1.21 blokkeren, een nieuwe weergave maken en de OID aan de weergave toevoegen.

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.

Tip voor probleemoplossing

- Basisgebruik van CPU’s: documenteer de normale CPU-gebruiksniveaus wanneer het SNMP-proces geen hoog gebruik veroorzaakt.

- SNMP-configuratie: controleer de huidige SNMP-configuratie-instellingen, inclusief community-strings, versie (v2c of v3) en toegangslijsten.

- SNMP Best Practice: Gebruik het best practice-document 9800 WLC en stem zo dicht mogelijk bij de voorgestelde configuratie voor SNMP.

C9800(config)#snmp-server subagent cache

C9800(config)#snmp-server subagent cache timeout ?

<1-100>  cache timeout interval (default 60 seconds)

- Frequentie van SNMP-peiling: Bepaal hoe vaak de WLC wordt opgevraagd door SNMP-vragen, aangezien een hoge frequentie kan bijdragen aan een hogere CPU-belasting.

- Netwerktopologie en SNMP-managers: Begrijp de netwerkinstallatie en identificeer alle SNMP-managers die met de WLC communiceren.

- System Uptime: controleer de tijd die is verstreken sinds de laatste herstart om te zien of er een correlatie is tussen uptime en CPU-gebruik.

- Recente veranderingen: Let op alle recente veranderingen in de WLC-configuratie of het netwerk die kunnen samenvallen met het begin van een hoog CPU-gebruik.

- Met de 9800 WLC is de nadruk gelegd op telemetrie. Telemetrie werkt in een "push"-model waarbij WLC relevante informatie naar de server stuurt zonder dat er vragen hoeven te worden gesteld. Als uw SNMP-vragen WLC CPU-cycli verbruiken en operationele problemen veroorzaken, is het beter om naar Telemetry te gaan.

Conclusie

Door methodisch het analyseren van CPU-gebruiksgegevens en het correleren met SNMP-opinieactiviteiten, kunt u problemen oplossen en oplossen met hoge CPU-gebruiksproblemen die door SNMP-processen worden veroorzaakt op Cisco 9800 WLC. Post-implementatie controle is essentieel om het succes van de probleemoplossing inspanningen te bevestigen en optimale netwerkprestaties te handhaven.

Gerelateerde informatie

- Monitor Catalyst 9800 WLC via SNMP met OID’s

- Catalyst 9800 draadloze controllerserie beheren met Prime-infrastructuur met SNMP V2 en V3 en NetCONF

- Beveiliging van uw eenvoudige netwerkbeheerprotocol

- Beste praktijken voor Cisco Catalyst 9800 Series configuratie