Il 16/10/2012 09:56, Dave Shield ha scritto: > On 16 October 2012 08:32, Giuseppe Modugno <[email protected]> wrote: >> Now I'd like to have an agent that sends a notification for *each* >> parameter: if an alarm occurs, if the user change a setting (even >> through SNMP SET) and so on. >> >> The only approach I know is to define in the MIB a different >> NOTIFICATION-TYPE for each parameter, so I'll have a MIB composed by two >> main trees: one for the parameters and the second for the related >> notifications. Is this approach good? > No. > > Why not simply define a single notification "somethingChanged" > which takes one payload varbind - the OID of the instance that was updated. > > You'd need to define a MIB object for that (with max-access > "accessible-for-notify"), but that's just two definitions - not a whole tree. Good, I suspected there was a better approach! Could you write or refer to an already written MIB where this approach is used?
>> Can you suggest a better approach? Maybe defining a generic trap related >> to a parameter change? In this case, I can add to this generic >> notification a "service parameter" with an OID value: the OID will be >> the parameter that has changed. > Exactly. > >> But how can I add the new value >> of the >> parameter in a generic way (it could be an integer, an octet string and >> so on). > Remember that you can always append additional varbinds to a > notification payload - over and above those listed in the MIB definitions. Really? I thought I was forced to append just the varbinds defined in the MIB. Which is the RFC where I can study the composition of the notification? > So as well as the > somethingChangedOID.0 = theOidThatChanged > > varbind, the notification could also contain a copy of the incoming SET > varbind. i.e: > > somethingChangedOID.0 = theOidThatChanged > theOidThatChanged = theNewValue That's good :-) So I'm not forced to define the exact value type in the MIB. > One thing to bear in mind is how you wish to handle multiple values > being updated in a single SET request. Would that trigger a series > of notifications (one per incoming varbind), or would all the information > be included in the same trap? Oh, it is acceptable to have several traps. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
