Wireless Access

im trying to get the CPU load from a controller (6xx, 3xxx) via SNMP but can't find the correct OID

via the CLI i can get this: #show cpuload
user 3.3%, system 0.3%, idle 96.4%

but via SNMP the only thing i can find a table with several CPUs and a load which is always 0

example from a 650:

.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.2.1 = STRING: "Supervisor Card CPU"
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.2.3 = STRING: "Network Processor CPU3"
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.2.4 = STRING: "Network Processor CPU4"
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.2.5 = STRING: "Network Processor CPU5"
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.2.6 = STRING: "Network Processor CPU6"
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.2.7 = STRING: "Network Processor CPU7"
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.3.1 = INTEGER: 0
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.3.3 = INTEGER: 0
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.3.4 = INTEGER: 0
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.3.5 = INTEGER: 0
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.3.6 = INTEGER: 0
.1.3.6.1.4.1.14823.2.2.1.1.1.9.1.3.7 = INTEGER: 0

is there a nice OID which gives me access to a single value, or am i stuck with the table? as for the table do the Network Processor CPUs have anything to do with the device load? or is it just the Supervisor Card CPU?

Not sure about the OID...but according to our MIB guide and MIB file, the CPU utilization is as follows.  Can you search using a MIB tree or something else for the value "wlsxSysExtCpuUsedPercent" to decipher the OID?

wlsxSysExtCpuUsedPercent OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The CPU used percent of the switch"
::= { wlsxSystemExtGroup 30 }

oh the horrors of getting an OID from a MIB file ;) luckily i had to do that a few times now and with the help of a tool (paessler mib importer) this is the OID: 1.3.6.1.4.1.14823.2.2.1.2.1.30.0

only the value doesn't match the output from show cpuload

 #show cpuload
user 2.5%, system 0.3%, idle 97.2%

.1.3.6.1.4.1.14823.2.2.1.2.1.30.0 = Gauge32: 1

or even more fun

#show cpuload
user 0.8%, system 0.3%, idle 98.9%

.1.3.6.1.4.1.14823.2.2.1.2.1.30.0 = Gauge32: 100

the second one is on a 3400 which also reports an uptime that is larger then the device has been in service and is missing its memory info so that might be a bug with SNMP on 3xxx in general on this ArubaOS. ill add the OID and see if i can see some trend the coming days.

hi boneyard

let me try to answer some of your questions around the processorLoad OIDs and then the wlsxSysExtCpuUsedPercent OID.

For the processorLoad OIDs, here is a sample from my lab 620 while running a backup flash just to make it busy and show some significant value.

root@bt:/home/mibs# snmpwalk -v2c -mALL -M./6.1.3.0 -c public c620 1.3.6.1.4.1.14823.2.2.1.2.1.13
WLSX-SYSTEMEXT-MIB::sysExtProcessorDescr.1 = STRING: Supervisor Card CPU
WLSX-SYSTEMEXT-MIB::sysExtProcessorDescr.2 = STRING: Network Processor CPU2
WLSX-SYSTEMEXT-MIB::sysExtProcessorDescr.3 = STRING: Network Processor CPU3
WLSX-SYSTEMEXT-MIB::sysExtProcessorLoad.1 = INTEGER: 60
WLSX-SYSTEMEXT-MIB::sysExtProcessorLoad.2 = INTEGER: 0
WLSX-SYSTEMEXT-MIB::sysExtProcessorLoad.3 = INTEGER: 0

Let's address the network processor (a.k.a. NPU) OIDs first. These correspond to the number of CPU cores being used for the datapath which essentially means user traffic processing. You can review the utilisation of these NPUs via the CLI command show datapath utilization. The number of CPU cores used for datapath varies based on platform, as you see above for my lab 620 there are just 2 cores being used, however in your 650 you see 5 cores. In a 3600 as a final example, you will find 24 cores allocated to NPU.

The Supervisor Card CPU (SC CPU) is an aggregate of the remaining cores which are dedicated to running ArubaOS. Note that the naming is based on the legacy SC1 chassis based "supervisor cards". In the case of the example above, the NPU's start at CPU2, hence cpu 0+1 are being used for SC CPU. In the case of your lab 650 you can see there are 4 cores (0~3) being used  and again for the 3600 as a final example, you would see 8 cores assigned to SC CPU.

As such, when you display that single value OID (and even the show cpuload cli command) a number of CPUs are being represented. Here is the show cpuload (equivalent) taken during that time where I was running backup flash to drive up the CPU:

Cpu(s): 50.6%us,  3.5%sy,  0.0%ni, 45.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

The numbers don't exactly match since the SNMP OID is a 60 second average and the output of the command which I took that cpuload from updates every 5 seconds. However, the point here is that the numbers do approximately match and are an accurate representation of the overall load across all CPU cores that are considered SC CPU cores.

Let's consider the same 620 allowed to become idle (removing the NPUs from output):

root@bt:~# snmpwalk -v2c -mALL -M./6.1.3.0 -c public c620 1.3.6.1.4.1.14823.2.2.1.2.1.13
iso.3.6.1.4.1.14823.2.2.1.2.1.13.1.2.1 = STRING: "Supervisor Card CPU"
iso.3.6.1.4.1.14823.2.2.1.2.1.13.1.3.1 = INTEGER: 1
root@bt:~#

(sg-620) #show cpuload
user 0.7%, system 0.7%, idle 98.7%
(sg-620) #

both outputs are showing around 1% load (occasionally the rounding to integer sends the SNMP value back to 0%, but it generally shows 1% for idle)

With regards to wlsxSysExtCpuUsedPercent - the value is meant to be determined as such:

wlsxSysExtCpuUsedPercent = 100 - cpu_idle

where cpu_idle is the idle % value as shown in output of show cpuload (which is updated every 10 seconds)

I am not sure if there is a bug with this OID, it's implementation seems quite straightforward - can you try to monitor the value of the SNMP OID compared to the show cpuload output wihin a couple of seconds of each other ?

regards

-jeff

at first thank you for the extensive explanation.

by now it seems that wlsxSysExtCpuUsedPercent is working fine for the 650s we use, only issue is that often it doesn't show anything, seems like the getSNMP times out, where other values get read during the same time (i.e. used memory).

for the 3400 wlsxSysExtCpuUsedPercent is always 100, this doesn't change, the show cpu load does show idle values.

im starting to monitor sysExtProcessorLoad.1 / iso.3.6.1.4.1.14823.2.2.1.2.1.13.1.3.1 now to see what the effect there is.

---

@boneyard wrote:

at first thank you for the extensive explanation.

 

by now it seems that wlsxSysExtCpuUsedPercent is working fine for the 650s we use, only issue is that often it doesn't show anything, seems like the getSNMP times out, where other values get read during the same time (i.e. used memory).

 

>> [-jeff] that's kind of odd, they shouldnt really be handled any differently. are you getting it or walking it, and if you are walking it, what top OID are you using ?

 

for the 3400 wlsxSysExtCpuUsedPercent is always 100, this doesn't change, the show cpu load does show idle values.

>> [-jeff] i'll check this out in my lab next week - what exact version are you using ?

getting it (i believe), it is a monitoring system (zabbix 2.0.6) which shows the gaps for the one but not the other, quite strange

im using 6.2.0.1 (there is a case open for an SNMP issue with this 3400 were i provided the flash image, 1439929).

attaching three files:

650-wlsxSysExtCpuUsedPercent-3hours.png - 3 hours of wlsxSysExtCpuUsedPercent (OID 1.3.6.1.4.1.14823.2.2.1.2.1.30.0) monitoring, notice the gaps, some upto 5 minutes (5 measurements) no data. we got like 10 650s which all show this behaviour.

650-sysExtProcessorLoad-3hours.png - 3 hours of sysExtProcessorLoad (OID 1.3.6.1.4.1.14823.2.2.1.2.1.13.1.3.1) monitoring, same device, no gaps.

3400-wlsxSysExtCpuUsedPercent-7days.png - 7 days of wlsxSysExtCpuUsedPercent (OID 1.3.6.1.4.1.14823.2.2.1.2.1.30.0) monitoring, straight 100% line.

ack that - I will take a look in the coming few days and contact you via your email in the ticket if anything needs clarification. Once we know what's going on, will update this thread again.