[ First - *please* don't mail me privately, without copying
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]

2008/4/30 ntwrkd :
> Hey David,
> Thank you for these helpful tips.
> I have one question about your response:
> > The simplest way would probably be to use the "extend" mechanism
> > to run a suitable command, which would report the information you
> > are interested in.
> > That would allow you to retrieve this information, without having
> > to define and implement a MIB.

> If I can extend the agent without redefining the MIB, why would I need
> to have a MIB at all?

If you are using the extend (or exec) mechanisms, then the results
are structured to match the MIB definitions for these two formats.
In particular, all output is reported as string values (even if they are
actually numbers)
The onus is on your client-side tools to interpret this standard
structure in a way that is appropriate for the data that you are
working with.

If the "client side tool" is a person, then this isn't typically a problem,
since such applications are incredibly sophisticated :-)
But if you want to do automated processing of the results, then
this standard framework can sometimes prove an obstacle.
That tends to be where defining and implementing a more
dedicated MIB can be helpful, since the structure can more closely
match the characteristics of the data.

> Are MIB's intended to work with extending the agent?

MIBs essentially describe the information being reported, in a standard
manner. They act as a design document for both the agent and the
client tools, and help ensure that the two sides agree about what
information is actually being worked with.

> Or to create a MIB, my application would have to have a copy of the
> default IETF OID tree with my own extensions included?

No - your extensions would typically be defined as a (more-or-less)
self-contained MIB. Your application would only need access to
those MIB definitions that were relevant to what it actually needs
to do - it can safely ignore anything else.

Note that this "access to MIB definitions" doesn't have to be the
actual MIB file. It's equally as valid to have the relevant MIB OIDs
hard-wired into the application code. The MIB file definitions can be
used at the design stage (to know which OIDs to work with),
as well as/instead of at run time.


This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
Net-snmp-coders mailing list