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

Re: snmpconf A non-trivial policyAction example

>>>>> Steve Waldbusser writes:


Steve> Enough RMON2 background, here's the script:


Steve> It's pretty straightforward. Basically it uses setRowStatus to
Steve> find and reserve an unused row, and then creates a single PDU
Steve> with all of the column values filled in and sends the SET.

FYI, here is the same script in Tcl using the Tnm extension as you can
run and execute it today.

proc create_hlMatrixControlEntry {s ifIndex} {

    if {[catch {setRowStatus hlMatrixControlStatus} index]} {

    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 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.)

Steve> This is useful to illustrate how reasonable it is to do some
Steve> fairly complex stuff, but it has a flaw which I'll identify and
Steve> then fix.  Scripts run periodically so that they can re-assert
Steve> whatever state the policy is expected to enforce. The script
Steve> above would create a control entry for every iteration.

Steve> The fix is to see if a control entry already exists and, if so,
Steve> exit. The first time we create an entry we store the dataSource
Steve> in the scratchpad and then every time we execute, we retrieve
Steve> it from the scratchpad (if it's there), check to see if it
Steve> still represents a matrix on "this" interface, and if so,
Steve> return immediately.

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. If you want to use the
action on multiple RMON2 boxes, bad things will happen. 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??


Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>