[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: snmpconf A non-trivial policyAction example



Title: RE: snmpconf A non-trivial policyAction example

-----Original Message-----
From: Steve Waldbusser [mailto:waldbusser@nextbeacon.com]
Sent: Thursday, November 9, 2000 13:35
To: snmpconf@snmp.com
Subject: Re: snmpconf A non-trivial policyAction example


Juergen Schoenwaelder wrote:

> proc create_hlMatrixControlEntry {s ifIndex} {
>
>     if {[catch {setRowStatus hlMatrixControlStatus} index]} {
>         return
>     }
>
>     lappend vbl [list hlMatrixControlDataSource.$index ifIndex.$ifIndex]
>     lappend vbl [list hlMatrixControlNlMaxDesiredEntries.$index 1000]
>     lappend vbl [list hlMatrixControlAlMaxDesiredEntries.$index 1000]
>     lappend vbl [list hlMatrixControlOwner.$index "policy manager"]
>     lappend vbl [list hlMatrixControlStatus.$index 1]
>
>     $s set $vbl
> }

This API won't work in our environment because agents don't have MIB
compilers and therefore don't know the type of a variable. For example, in
the maxDesiredEntries varbinds above, it's not clear whether to send the
integer 1000 or the 4 character string "1000".
[gww] Actually, a MIB compiler is not needed by the agent - just the output from the MIB compiler. The output tends to be one or more files that could easily used by an agent (at least in systems I have used and designed in the past). Also, if the agent does have access to the compiled MIB the agent would have access to the type (e.g.: string, integer, etc.) information of the objects.

I'm definitely interested in continuing to work on the API/language to make
scripts shorter and easier to write.

> This example makes it very obvious to me that actions will be complex
> over time and that a mechanism is needed to write "procedures" (like
> the one above) which you can call and reuse in actions. (I can easily
> imagine cases where a policy rule action instantiates many rows and
> the hlMatrixControlEntry is just one of them.)

Interesting, I had the opposite reaction. I was struck by the fact that the
function was well within a manageable size and that no functional
decomposition seemed obvious.

> Steve> Here's the complete example. The new code is lines 4-9 and 18:
>
> [...]
>
> The fix is flawed as well since the oid in the scratchpad does not say
> which SNMP agent the action is executed on.

This is handled automatically by the execution environment which knows the
address of "this element".

> I am also
> concerned about the error handling - what happens if e.g. snmpsend(0,
> 5, OP_SET); fails with an SNMP error? Will the policy repeat in a loop
> to fire this action regularily??

Yes, and I think this is desired behavior. A policy is trying to enforce a
certain behavior. If the enforcement fails temporarily I think that it
should continue to try. In this case, the maxLatency won't be too high
(maybe run once per hour) and the (computational/operational) cost of
failing is low. In another circumstance where the cost of failing was high,
we could set something in the scratchpad to disable enforcement on this
interface.


Steve
/gww