Extending the UCD agent - the MIB file
The MIB File
The first file needed is the MIB file that defines the MIB module to be implemented.
Strictly speaking, this is not absolutely necessary, as the agent itself does
not make any direct use of the MIB definitions. However, it is advisable to
start with this for three reasons:
- It provides an initial specification for what is to be implemented.
Code development is always easier if you know what you are meant
to be writing!
- If the new MIB file is read in with the other MIB files,
this lets the applications provided with the suite be used
to test the new agent, and report (hopefully meaningful)
symbolic OIDs and values, rather than the bare numeric forms.
(N.B: Remember to tell the application to load the new MIB.
See the relevant question in the FAQ)
- The tool
mib2c uses this description to produce the
two code files. This is by far the easiest way to develop a new module.
If the intention is to implement a 'standard' MIB module, or a vendor-specific
one, then the construction of this file will have already been done for you.
If the intention is to provide a totally new, private module, then you will need
to write this yourself, in addition to the agent code files.
A description of MIB file format and syntax is beyond the scope of this
document, and most books on SNMP management should provide some information on
this subject. One book which concentrates on this is
Understanding SNMP MIBS
(Perkins & McGinnis, Prentice Hall, ISBN 0-13-437708-7).
This blatant plug is wholly unrelated to the fact that David Perkins is an
active member of the development group, and is regarded as our resident
"protocol guru and policeman". (In fact, this book concentrates on MIB
files in rather more detail than is appropriate in more general SNMP works).
Information on other books covering SNMP and Network Management more generally
is available on the
SimpleWeb site (among other places).
See the FAQ for more details.
Assigned OID numbers
One word of advice - even if you are developing a totally private MIB module,
you will still need to position this somewhere within the overall MIB tree.
Please do NOT simply choose a location "at random". Any such is likely to have
either been assigned to some other organisation, or may be so assigned some time
in the future. However much you may regard your project as a totally internal
affair, such projects have a tendency to exceed their expected scope, both
in terms of lifetime and distribution (not to mention the potential OID clash
if you subsequently need to use elements from the legitimate owner's tree).
It is simple and cheap (i.e. free!) to obtain your own official segment of
the MIB tree (see
http://www.iana.org for
an application form),
and having done so, you then have complete global authority over it.
If you have problems with this, it's worth contacting the development
team (email:
ucd-snmp-coders@ucd-snmp.ucdavis.edu) for advice.
Please do think to the future, and be a good Net
citizen by using a legitimately assigned OID as the root of your new MIB.
MIB division
The next point to consider, whether writing by hand or using
mib2c,
implementing an existing MIB, or writing a
new one, is whether and how to divide up the MIB tree. This is a purely
internal implementation decision, and will not be visible to management
applications querying the agent. A sensible choice of partitioning will
result in a simpler, clearer implementation, which should ease both the initial
development and subsequent maintenance of the module.
Unfortunately, this choice is one of the module-specific decisions, so must be
made on a case-by-case basis. For a simple, self-contained module, it may well
be reasonable to implement the module as a single block (examples include the
SNMP statistics subtree RFC 1907 or the TCP subtree RFC 2011). More complex
and diverse modules (such as the Host Resources MIB - RFC 1514) are more
naturally considered as a number of individual sub-modules.
Some guidelines to bear in mind when deciding on this division:
- A MIB sub-tree consisting purely of scalar objects with a common
OID prefix would
normally be handled in the same implementation module;
- Separate scalar subtrees would normally be in different implementation
modules;
- A table can either be handled within the same implementation module
as related scalar objects in the same subtree, or in a
separate implementation module;
- Variables that rely on the same underlying data structure to
retrieve their values, should probably be in the same
implementation module (and conversely, (though less so)
those that don't, shouldn't).
As an initial rule of thumb, a good initial division is likely to be obtained
by treating each table and each scalar sub-tree separately. This can be seen
in the current agent, where most of the MIB-II modules (RFC 1213) are
implemented in separate files (see the files under
mibgroup/mibII).
Note that many of these combine scalar and table handling in the same file,
though they are implemented using separate routines.
This is also the approach used by
mib2c, which constructs a single pair of code files,
but uses a separate routine for each table (and another for all the scalar
variables).
Ultimately, the final consideration (concerning the underlying data)
is the most important, and should guide the basic division.
For example, the Host Resources Running Software and Running Software
Performance modules, while separate in the MIB tree, use the same underlying
kernel data and so are implemented together.
MIB name
The final requirement at this stage is to choose a name for each
implementation module. This should be reasonably short, meaningful, unique
and unlikely to clash with other (existing or future) modules.
Mib2c uses the label of the
root node of the
MIB sub-tree as this name, and this is a reasonable choice in most cases.
Recent changes to the agent code organisation have introduced the idea of
module groups of related implementation modules. This is used, for
example, to identify the constituent modules of a 'split' MIB (such as the Host
Resources MIB), or those relating to a particular organisation (such as UCD).
As with the division, this naming and grouping is a purely internal matter,
and is really only visible when configuring and compiling the agent.
So much for the MIB file. The next part
considers the C header file.
Copyright 1999 - D.T.Shield.
Not to be distributed without the explicit permission of the author.
[an error occurred while processing this directive]
