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@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