Re: Using SNMP on highly variable systems
Pete Wilson <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <[email protected]> |
> 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