cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1778
Views
0
Helpful
5
Replies

Registering multiple events in Tcl policy

Rupak Chandra
Cisco Employee
Cisco Employee

Hello

I'd like to register for multiple events in Tcl policy (along with "trigger" and "correlate"). However the number of event registrations needed is dynamic, and needs to be driven by an event manager environment variable.

e.g.

# List of interfaces to monitor

event manager environment if_list {ge2/1 c3/1 w4/1}

For each interface in if_list, there need to be 2 event registrations done - e.g. a) event_register_timer b) event_register_track.

Is it possible to achieve this ? I've tried a few different things, including applet chaining but that doesn't seem to help because of the restrictions around event registrations.

Thanks

5 Replies 5

Joe Clarke
Cisco Employee
Cisco Employee

See this discussion:

https://supportforums.cisco.com/thread/2226314?tstart=0

The later part talks about using nested policies to dynamically create the multi-event policy you want.

Hi

The above approach will work, BUT applet nesting creates additonal configs - which I'd like to avoid doing. Also, I'd like the nested applet to be a Tcl policy by itself.

Is there an alternate approach ?

During EEM script policy registration - it allows passing a variable parameter for the event register spec, in the first line of Tcl policy:

e.g $my_event_register_cmd

But this doesn't work either because $my_event_register_cmd cannot seem to handle a multi line string (with more than one event_register specs).

Thanks

No, there is no other approach.  You could do a broader timer-based policy that wakes up then checks CLI our SNMP data to see if more actions need to be run, but that may be less efficient than doing nested policy creation.  Note: you don't need to have your root-level policies stick around.  If the config will be a one-time only thing, they can configure the required policies then unconfigure themselves.

Hello,

Thanks for your suggestions.

Yes, unfortunately, this wont be a one time thing i.e. the configs will stay/will need to regenerated if new interfaces get created/configured. The config could also get saved, and old one (with dynamic applet configs) re-applied

automatically.

If the Tcl script policy was structured such that the event action was kept separate from event specification then we could allow Tcl "evaluation" of the entire script (instead of only $parameter substitution thats allowed today). But this would be an enhancement request :-):

e.g.

foreach if_inst $if_list {

     event_register_timer ..... {

     #timer actions...

     }

     event_register_track .... {

     # track state change actions

     }

     trigger {

     correlate ...

     } {

     # trigger actions

     }

}

You can only have six events in a correlate.  Given that, you might be able to do something clever like:

::cisco::eem::event_register_interface tag e1 name [lindex $if_list 0] ...

::cisco::eem::event_register_interface tag e1 name [eval {if { [llength $if_list] > 1 } { expr {[lindex $if_list 1]} } else { expr {[lindex $if_list 0]} }}] ...

Then correlate all six together with "or".