On 16 November 2011 15:00, prashant n <[email protected]> wrote:
> 1) How to create a table containing float as its parameters? Can we use
> OCTET STRING as data type?

There are three basic possibilities here:
   a)  If the data would work with a "fixed-point" float
        (e.g. a floating point value with three decimal places)
        then use an INTEGER type, with a suitable DISPLAY-HINT
        to indicate where the decimal point should appear

   b)  Use an octet string, containing a textual representation
        of the floating point number

   c)  Use the (Net-SNMP specific) "NET-SNMP-TC::Float" type
        This relies on an Opaque wrapping (to make it conform to
        the SNMP protocol, using a proposed standard that was
        never widely adopted.
           In principle, this could be used with other SNMP toolkits
        as well, but as far as I know, Net-SNMP is the only toolkit
        to implement this.

Techniques a) and c)  are used in the UCD-SNMP-MIB::laTable
to handle the load average values.



> 2) In general, whenever manager sends set request to  the agent, both the
> parameters in  MIB file in the agent  device(SNMP  installed) and
> parameters in software of the device will get affected or what?


Don't think of the MIB file as a "database" that actually contains the values.
Or even of the agent containing the value itself.

Rather think of the agent as an interface between the management application
and the system being managed.   Whenever the management station makes
a request,  this is received by the agent (in standard SNMP format), and
forwarded to the underlying system (in whatever form is most appropriate).
   Any data that the agent holds itself is essentially a cached copy, and is
purely for efficiency.

The MIB files is effectively the "design document" for how the agent should
represent this underlying data to the SNMP side.


>     If so how?

When the agent receives a SET request, it should update the underlying
system with the appropriate changes.   How this is done is *very* system
dependent - relying both on the MIB object(s) being changed, and the
underlying OS APIs.
   Correct and reliable SET handling is definitely the most challenging
part of implementing a MIB.   I'd suggest you concentrate on getting a
read-only version working first, before worrying about how to handle SETs

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. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to