[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SNMP "bridging"/proxy?

It is fairly easy to extend the snmpd on a Linux host to retrieve data from
non-SNMP sources...  For example:



Anything you can retrieve with a shell script can be turned into a
1-minute-interval cron job that outputs a text file with a number in it,
then the SNMP 'extend' parameter in the snmpd.conf can be used to 'cat' the

For example something from a solar charge controller that only speaks RS485
over an RS485-to-RS232 (or USB) bridge. Or data retrieved via curl and sed.
I use this to graph WSDOT traffic driving times patterns and flows and feed
them into a charting system.

For smaller setups you can have all the shell scripts for data acquisition
on the same host that runs the snmpd.

On Fri, May 20, 2016 at 4:43 PM, Nathan Anderson <nathana at fsr.com> wrote:

> 'lo all,
> Is anybody out there aware of a piece of software that can take data from
> an arbitrary source and then present it, using a MIB or set of OIDs of your
> choosing, as an SNMP-interrogatable device?
> We have some CPE that supports SNMP, but considers it to be a
> mutually-exclusive "remote management" protocol such that if you use
> another supported method for deployment and provisioning (e.g., TR-069),
> you cannot have both that AND SNMP enabled simultaneously.  It's one or the
> other.
> We currently monitor and graph some device stats for these CPE with Cacti,
> but we want to be able to provision using a TR-069 ACS.  The ACS can
> collect some of the same data we are graphing right now, but cannot present
> it in a fashion that is nearly as useful as the way Cacti/RRDtool does (not
> to mention the staff is already used to navigating Cacti).  We know what
> SQL database table the stats are being stored in by the ACS, though, so my
> thought was that there must be some way that we can have a host respond to
> SNMP gets and then have it turn around and collect the value to be returned
> from a database.  Basically, an ODBC -> SNMP proxy.  We'd then point Cacti
> at that IP instead of the individual CPEs.  But I can't seem to find
> anything like this.
> Thanks,
> -- Nathan