F/OSS SNMP tools (was Re: Cacti 0.8.6j Released)

Wed May 9 04:40:37 UTC 2007

You only need to worry about vendor MIBs if you're trying to query/monitor
something vendor-specific.  Standard stuff like ifInOctets and ifDescr are
included in everything.  I like to either read through MIBs by hand, or load
em in a MIB browser (like mbrowse or use vendor C's snmp explorer tool) to
search/dig into a table/value that interests me, then snmpwalk a base OID to
find instances and enter the pattern directly into whatever collector tool
I'm using that week.  If you're trying to use vendor MIBs, you also have to
deal with dependencies and conflicts, so prepare for some hair-pulling hell.

I'm still on the hunt for a decent F/OSS trap receiver that will allow me to
just load up MIBs, and have some simple config/UI method for selecting
trigger actions/notifications, maybe some filtering and unknown-trap
handling etc.  Trying to snag traps with snmptrapd and parsing text output
is uncooperative.  Inconsistent formatting of key/value etc.

On 5/8/07, Matt Palmer <mpalmer at hezmatt.org> wrote:
>
>
> [If people think this is off-topic, please let me know and I'll take it to
> private mail with Travis.]
>
> On Tue, May 08, 2007 at 07:32:18PM -0500, Travis H. wrote:
> > Hey folks, I am following up to an ancient email because I'm curious
> > if anyone has some SNMP-related resources.  Basically, there's a lot
> > of how-to or manpage sort of information, but I'm still unclear on
> > what an MIB actually _is_,
>
> It's an overloaded term.  Technically, I think it's the values which you
> can
> query by OID in an agent, but most people use the term to describe the
> textual description of the OIDs and what they mean, especially when they
> talk about "downloading a MIB".
>
> > what problem ASN.1 actually solves,
>
> How to encode the queries and responses.  Unless you're actually writing
> an
> agent or low-level manager library, ignore it.  Seriously, you don't need
> the headache.
>
> > and
> > more to the point how the whole shebang (I'm using net-snmpd) is
> > typically used.
>
> Agent on device provides values, management app(s) collect data by polling
> (and possibly via traps), sysadmin gets to go home on time for once.
>
> > I believe that what I need to do is get any/all MIBs for all "entities"
> > (typically networking hardware devices) that I want to monitor, and
> import
> > them into the net-snmp configuration somehow, and then software that
> calls
> > on net-snmp can access the information from the devices.
> >
> > Is this accurate?
>
> Kinda-sorta.  You don't actually need a MIB to be able to query a device
> --
> you can, in theory, just walk it from the root and get all the OIDs (and
> their values) that the agent provides.  However, since all you'll get are
> massive quantities of numbers, that'll be fairly useless, and the MIB file
> you refer to will help you (and your agent software) decode the OIDs into
> something more readable.  That being said, if you only want to monitor a
> few
> OIDs, and you know the OIDs already, then the MIB is unnecessary.
>
> Where you put the MIBs to net-snmp can find them depends on where net-snmp
> has been told to look for them.  /usr/share/snmp/mibs is where they go on
> my
> system, but $DEITY knows where they might end up on some Unices.
>
> > Will I need to import MIBs to every net mgmt application?  Should they
>
> If they use different OIDs, and you want to be able to use them easily,
> yes.
> This "using different OIDs" thing is depressingly common -- although there
> are RFC standards for a lot of the "common" types of networking data, a
> combination of "the RFCs don't define all our statistics" and NIH means
> that
> a lot of vendor equipment does it's own SNMP thing.
>
> > be carefully accounted for and synchronized, or can I treat them like
> > a typical configuration file, where it is obvious if I need it and I
> > get them as needed?
>
> They're not critical to the operation of the whole thing, merely the
> comprehensibility, so don't get too obsessed over your MIBs.
>
> - Matt
>
> --
> Just because we work at a University doesn't mean we're surrounded by
> smart
> people.
>                 -- Brian Kantor, in the monastery
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070508/2a4d4f96/attachment.html>