> Message: 7
> Date: Tue, 19 Feb 2008 15:03:26 -0000
> From: "Philip Mason" <[EMAIL PROTECTED]>
> Subject: Using SNMP on highly variable systems.
> The system in question has a number of bays into
> which plug-in cards can
> be inserted at any time. Each card can have a
> completely different set
> of controls and cards can be hot swapped. The
> plug-in cards themselves
> have very limited processing capabilities and can't
> host their own SNMP
> agent
>
> What I would like to know is: is there a recommended
> way of dealing with
> such a system?
>
> I could create a MIB that contains the maximum
> number of controls and
> events but since there is no way of knowing what
> card will be plugged in
> where the control objects will have to be very
> generic (e.g. all being
> integer32) with no allowance being made for the
> properties of the
> control (for example it might be better as an
> enumerated integer). This
> will also mean the MIB is much more complicated than
> necessary as most
> of the cards are very simple but the MIB will have
> to assume the worst
> case.
This approach is the right approach, imo. I have just
implemented an agent that faced exactly the same
issue. My solution was, in the overall design, to
forget for the moment about the many kinds of cards
and instead to consider each *slot* as the target
device. From there, it was easy to assign (in the MIB)
two objects per slot:
1. a card is present/absent; and
2. card type
each of these being available at the device level via
an I/O read of the slot status that I could have
executed for me.
Then I wrote the MIB to describe each characteristic
of each kind of card. That means that the user, at the
NMS, sees displayed all of those characteristics and
possible cards. In my case there was some overlap of
objects among all of the card types, which made it not
quite so formidable.
Then at each access I could check if card present
(return "noModule" if not) and, by looking at the card
type, I could check if the object requested was
supported on this particular card ("notApplicable" or
"noValue" or something if not).
This works (in my case) for hot-swapped cards, which I
had to handle.
That scheme has worked out very well for me: it made
the MIB easy to write; and it made the agent easy to
code and debug.
Just speaking for myself, I definitely recommend
strongly against hooking up a new subagent each time a
new card appears: that way lies madness.
HTH
You might want to try this question on the Usenet
group comp.protocols.snmp. The author of
"Understanding SNMP MIBs" hangs out there along with a
lot of expert SNMP folks.
-- Pete Wilson
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
