OpenWrt Forum Archive

Topic: snmpd not providing realtime data

The content of this topic has been archived on 17 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I'm running CC r45573 on a Linksys WRT1900AC. Very impressed so far, but I've run into an issue monitoring the router using SNMP.

I installed the snmpd package and the default settings mean that I can see the router as expected. However, I would like to monitor in real time but snmpd currently appears to have a 15 second cache. This results in the monitoring workstation shows a bandwidth spike every 15 seconds.

The precise issue (on a different platform) and the type of chart the I see is shown here:

https://www.fineconnection.com/how_to_s … _interval/

However, I'm not sure how I can take this solution and apply it to my router. I can't see anything obvious that I should change in snmpd.conf

Has anyone been able to get snmpd to respond as expected in realtime?

Cheers
Chippy

Just to update this: the monitoring software I'm using is called PeakHour and they list the same issue on their site - along with the fix for Net-SNMP installations:

http://support3.peakhourapp.com:8090/pa … Id=1671186

I think that snmpd is based on Net-SNMP, but the OpenWRT implementation is clearly different (I don't have the option of using the snmpset command).

All I need to do is set the nsCacheTimeout MIB to 1. Does anyone know how I can do this on snmpd?

ChippyAft wrote:

I'm running CC r45573 on a Linksys WRT1900AC. Very impressed so far, but I've run into an issue monitoring the router using SNMP.

I installed the snmpd package and the default settings mean that I can see the router as expected. However, I would like to monitor in real time but snmpd currently appears to have a 15 second cache. This results in the monitoring workstation shows a bandwidth spike every 15 seconds.

The precise issue (on a different platform) and the type of chart the I see is shown here:

https://www.fineconnection.com/how_to_s … _interval/

However, I'm not sure how I can take this solution and apply it to my router. I can't see anything obvious that I should change in snmpd.conf

Has anyone been able to get snmpd to respond as expected in realtime?

Cheers
Chippy

I have seen this effect as well. I use a tool that makes it easy to re-query a device manually, and if you do it too often, you get zeroes for all the results. Here's some additional troubleshooting:

It appears that the OpenWrt snmpd does not have the net-snmp-agent MIB installed/built-in. At least, I don't get a response when I try to walk that table with this command (I can retrieve the contents of the ifTable, for example):

snmpwalk -c public -v 1 172.30.42.1 1.3.6.1.4.1.8072.1.5.3

Consequently, you won't be able to set nsCacheTimeout as the software is currently built. I don't know if any snmpd experts are reading this forum but perhaps they could help.

Update: I have tested the mini-snmpd implementation, and it does not seem to have this flaw. Because it is a minimal SNMP implementation, it is missing many variables, but it does provide transmit/receive bytes. (For example, it's missing ifSpeed, so it's not possible to calculate %utilization, and it's also missing a lot of other variables...)

To use mini-snmpd:
- Uninstall snmpd and snmpd-utils (if already installed). You may see a warning about leaving the snmpd config file. That's OK.
- Use the LuCI web gui to install mini-snmpd.
- SSH into the router and edit /etc/config/mini-snmpd. Change these lines:
   - option enabled 1
   - option contact 'whatever-you-want-sysContact-to-be'
   - option location 'whatever-you-want-sysLocation-to-be'
   - Note: sysName is set automatically from the Hostname of the main LuCI web page
- Save the changes.
- In the LuCI web interface goto System -> Startup.
   - Click the Disabled button for mini-snmpd to make it say Enabled (this will cause it to start when the router reboots)
   - Click the Restart button to restart mini-snmpd and force it to read the new config file

You can also read the HOWTO page at http://wiki.openwrt.org/doc/uci/mini_snmpd

(Last edited by richbhanover on 26 Apr 2015, 22:30)

For my own education:  why would you need to query an SNMP counter that frequently?  Surely once every 5 minutes should be good enough, or once a minute in extreme cases?

atom wrote:

For my own education:  why would you need to query an SNMP counter that frequently?  Surely once every 5 minutes should be good enough, or once a minute in extreme cases?

Great question. If you're simply tracking trends, then 5 minutes is sufficient. But if you're troubleshooting, or if you need better granularity data, more frequent polling is essential.

I used to spend a lot of time with the InterMapper network monitoring software. Its default polling interval was 30 seconds. Institutions large and small used it to get a good handle on the traffic dynamics across hundreds or thousands of routers/devices.

InterMapper also had a "manual repoll" facility that let you re-query the device to see what's happening *right now*. This was invaluable when you were troubleshooting, and thought that you had fixed a problem. Waiting around for the next five-minute poll is not appealing, so you could re-poll at any time.

atom wrote:

For my own education:  why would you need to query an SNMP counter that frequently?  Surely once every 5 minutes should be good enough, or once a minute in extreme cases?

Fair point. Until a few months ago, I would have agreed wholeheartedly; indeed, in our enterprise environment 5 minutes is our standard polling rate.

However, I recently started to use a product called PeakHour (http://peakhourapp.com) at home, which places a realtime router bandwidth chart in the menu bar of my Mac. I also use iStat Menus, which shows my Mac bandwidth utilization next to it.

When apparent network slowness occurs I can now compare at a glance the bandwidth utilization of my broadband connection and my Mac. This helps me understand whether I'm the sole user of bandwidth in the house (or if the sudden slowdown in performance may be due to Stampy Longnose streaming in HD elsewhere in the house...)

Once you're used to this level of insight, it's difficult to be without it. Definitely overkill in the enterprise but very useful at home. From other conversations, I understand the DD-WRT has no issues (my old Billion 7800N with stock firmware was fine also).

richbhanover wrote:

Consequently, you won't be able to set nsCacheTimeout as the software is currently built.

Agreed. I was pointed in the direction of using the "snmpset" command remotely to change the MIB value but got the following error which appears to confirm your theory...

snmpset -c privatestring -v 1 192.168.1.254 NET-SNMP-AGENT-MIB::nsCacheTimeout.1.3.6.1.2.1.2.2 i 1
Error in packet.
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: NET-SNMP-AGENT-MIB::nsCacheTimeout.1.3.6.1.2.1.2.2

richbhanover wrote:

Update: I have tested the mini-snmpd implementation, and it does not seem to have this flaw.

This sounds exactly what I'm looking for - many thanks for the pointer. However, I'm currently running a Linksys WRT1900AC with OpenWRT CC - which seems to be missing a bunch of packages including mini-snmpd. Unless I'm missing something?

ChippyAft wrote:
richbhanover wrote:

Update: I have tested the mini-snmpd implementation, and it does not seem to have this flaw.

This sounds exactly what I'm looking for - many thanks for the pointer. However, I'm currently running a Linksys WRT1900AC with OpenWRT CC - which seems to be missing a bunch of packages including mini-snmpd. Unless I'm missing something?

Hmmm... I tested mini-snmpd with the BB build on a TP-Link Archer C7... I don't know why it would have been dropped from the CC build.

Hi, I'm having the same issue, but it seems mini-snmp was pulled from my ability to install it with opkg.  Is there another way to do this for a WRT1900AC?

My best advice would be to file a bug at  https://dev.openwrt.org/newticket and ask to have mini-snmpd included in CC builds.

I run snmpd on the 1900ac and it works great... I use a 60 second polling cycle, so there are no problems, but it's good to know there are options if a bump in polling is needed.

Using SNMP there is a plethora of stats, but these are what I'm pulling

CPU%  (Individual Cores as well)
Bandwidth Utilization in Mbps  (In and Out of each interface)
Total Bandwidth Used.. Example being what's used in a month (GBytes Used 30 days.)

There's a bunch of other stats I get as well, but those are done through SSH. Last week I also started monitoring Eth1 firewall drops. This way alerts can be set up if an attack is underway.

(Last edited by davidc502 on 8 Aug 2015, 17:15)

The discussion might have continued from here.