On 23 June 2011 08:05, Giuseppe Modugno <[email protected]> wrote: > I thought a MIB file is associated to a product.
That's one approach, certainly. And a number of manufacturers do indeed adopt this way of thinking. But it's the exact opposite of how SNMP was originally designed. Think about how things look from the point of view of the network operators for a moment. If each product has its own dedicated MIB, then every time you want to check something on a bit of network kit, you've first got to remember what type of box it is, and then what the management objects are for that particular box. If all of your kit uses standard MIBs, then things get much easier. If you want to check the temperature sensors, then you can use the same set of OIDs, regardless of which box you are interested in. (or ideally even which vendor supplied it). It also makes it much easier to write software to monitor and manage your network. The Web wouldn't have been as successful as it is, if you needed different web browsers to query different web sites! > I think it's impossible to create a MIB file that can work with everything. It's impossible to create one MIB file that covers *everything* - sure. But it's fairly straightforward to create a MIB that covers one particular aspect of behavious, without getting tied into the particular configuration of a given piece of kit. There's nothing inherent in the idea of temperature sensors that is specific to your particular kit. So it's very shortsighted (and/or selfish!) to tie the management information to one product-specific MIB. > And if I have to create a new MIB file for a new product, I can simply > modify it to increase/decrease the number of sensors, the new functionality > parameters and so on. > What is wrong in my words? It means that everyone using your kit has to learn a new set of OIDs every time they buy a new box, re-write any programs they have writted to use the new OIDs, etc, etc. >> In fact - rather than defining your own MIB tables, I'd >> actually suggest that you look at using the existing >> sensor tables. >> Have a look at LM-SENSORS-MIB.txt > Is LM-SENSORS-MIB.txt defined in a RFC? Is it standard? No - it's a Net-SNMP specific MIB There is a standard MIB (ENTITY-SENSOR-MIB), defined in RFC 3433, which we should really try to support as well. But this relies on elements from the Entity MIB, which we don't implement either. It's on a ToDo list, but I wouldn't hold your breath. What I would say is that if you look at supporting your kit using the existing sensor code, then you would automatically benefit if/when support for this MIB was added. Dave ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
