On 19/02/2008, Philip Mason <[EMAIL PROTECTED]> wrote: > 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.... > > What I would like to know is: is there a recommended way of dealing with > such a system?
The closest parallel within the standard MIBs is probable the Host Resources MIB - in particular the hrDeviceTable and related info. This MIB defines some fairly generic management information which can be reported for "any" type of device (type, description, product ID, status, error count). It then augments this general information with type-specific tables (hrProcessorTable, hrNetworkTable, etc). These values are only reported for devices of the appropriate type. That would seem a suitable model for your slot-based arrangement. Why not define a basic "slotTable" containing general information (slot #, card status, card type, etc), and then have type-specific tables to provide more detailed information about particular types of card. > 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 gets around that problem, as you can define suitable column objects for different types of card. > 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. The agent would only report "complicated" results for complicated cards. If a particular card is very simple, then only the simple bits of the MIB would apply to it. > The other method that I can see is to connect a new subagent each time a > card is plugged in and disconnect it when the card is removed but > "Understanding SNMP MIBs" seems to suggest that once you have registered > an OID you can't change its type or remove it and assign a different > item to that OID. You can't change the OID or meaning of a MIB *object*. So once you've defined an OID for (say) "cardType", then that's what this object means - it's fixed, and you can't change it. But you can create or delete *instances* of this object - "cardType.3" might appear or disappear or change value as the corresponding card is swapped in and out. Similarly, instances in the type-specific tables would also appear or disappear as the card in the system were changed. An instance in the nuclearWarheadTable (nuclearWarheadAmIBluffing.3 = yes(1)) would only be valid if there was a nuclearWarheadController card in that particular slot. If you removed that card, and replaced it with a cuteToyDinosaur card, then that row would disappear from the nuclearWarheadTable, but a new row would appear in the cuteToyDinosaurTable, with a different set of management objects (cuteToyDinosaurColour = "fadedMauve") Note that the OIDs of the MIB objects nuclearWarheadAmIBluffing and cuteToyDinosaurColour would remain fixed. If you needed to change some aspect of one of these MIB objects (e.g to rename the object as cuteToyDinosaurColor), then this would need a new OID. But that's the OID of the *object* - not instances of these objects. Have a play with the hrDeviceTable and related information. This is doing very much what you're looking for. Dave ------------------------------------------------------------------------- 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
