News: This forum is now permanently frozen.
Pages: [1]
Topic: SNMP Uptime Reporting  (Read 3821 times)
« on: October 04, 2012, 18:16:11 »
M *
Posts: 20

The SNMP service reports it's own runtime and not the system uptime. Can the service be configured to report total system uptime like the console & web interface?
« Reply #1 on: October 04, 2012, 19:40:41 »
Fred Grayson *****
Posts: 994

m0n0wall seems to have its own counter for system uptime that does not require the SNMP agent to be running.

The SNMP agent, once started, begins to keep track of system uptime (and others). But these data are reset to zero if the SNMP agent is stopped and then started again from the WebGUI.

--
Google is your friend and Bob's your uncle.
« Reply #2 on: October 05, 2012, 00:20:23 »
M *
Posts: 20

m0n0wall seems to have its own counter for system uptime that does not require the SNMP agent to be running.

The SNMP agent, once started, begins to keep track of system uptime (and others). But these data are reset to zero if the SNMP agent is stopped and then started again from the WebGUI.

Is this typical of the SNMP agents on FreeBSD or unique to m0n0?
« Reply #3 on: October 05, 2012, 00:29:37 »
M *
Posts: 20

Does the SMNP agent pass RAM usage details?
« Reply #4 on: October 05, 2012, 00:37:26 »
Fred Grayson *****
Posts: 994

I don't have an answer for you as to whether this is a m0n0wall limitation or common to snmpd regardless of platform run on.

I do know that if the data had to be persistent, then it would have to be stored somewhere to survive restarts or reboots. And this is something that m0n0wall doesn't do except for its own configuration file.

As to your new question, I only poll from the SNMP agent the following OIDs:

sysUpTime.0
ifInOctets.2
ifOutOctets.2

These are used by the IOG program to gather data to keep track of bandwidth usage, and rebooting m0n0wall can lead to erroneous results for the one hour period when the reboot occurs.

You can use snmpwalk to get a list of the available OIDs and their values from your m0n0wall. If there are OIDs available for RAM usage, they will be in that list.


--
Google is your friend and Bob's your uncle.
« Reply #5 on: October 07, 2012, 14:40:40 »
brushedmoss ****
Posts: 446

the correct oid to use is hrSystemUptime , as this is the host uptime.  this is now in r517

not all the host mib is included

i don't use IOG, but counter resets on reboot is normal, a lot of monitoring apps can handle that and not show a spike.
« Last Edit: October 07, 2012, 14:45:33 by brushedmoss »
« Reply #6 on: October 07, 2012, 14:56:51 »
Fred Grayson *****
Posts: 994

Thanks for the update, I'll change my IOG config file and see what happens. Sometimes IOG handles reboots OK, sometimes it doesn't. The program is no longer maintained though - how's your perl?

http://www.dynw.com/iog/


Edit:

I updated to r517 and used snmpget to verify that the numerical OID for hrSystemUptime (1.3.6.1.2.1.25.1.1.0) worked.

I then edited iog.cfg to use hrSystemUptime but it doesn't work. I then tried the numerical OID, and that failed too.

I'll try looking into the iog executable perl file to see if it can be fixed.

I edited the perl to use the new OID and it now runs without error. It will take a few hours with a reboot or two thrown in to see if it helps with the spikes.

« Last Edit: October 07, 2012, 15:31:04 by Fred Grayson »

--
Google is your friend and Bob's your uncle.
« Reply #7 on: October 07, 2012, 22:20:01 »
brushedmoss ****
Posts: 446

I had a look at the perl, it does do host reset detection, but on sysuptime, which is the start time of snmpd, so if you restart snmpd the perl will think the bandwith is the difference between zero and the current counter, which could be very large

see line 342 in the perl file, this is where it does the maths based on a host reset

so using the new oid should 'fix' this as you suggest
« Reply #8 on: October 07, 2012, 23:09:24 »
Fred Grayson *****
Posts: 994

Thanks for looking at that perl.

--
Google is your friend and Bob's your uncle.
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines