EEM script to run for as long as an interface is down?

[pingduck]

I want to write an EEM script such that it can run every min while an interface state is down. I can't seem to find the trigger for such operation? Can someone please give me some pointer?

[Joe Clarke]

Have a look at How To Introduce Large Delays In EEM Policies .  This approach lets you install a policy that runs periodically (say every minute), and then get removed when the overall condition goes away (say when an interface comes back up).  To monitor for that interface up event, you could either use syslog or enhanced object tracking.

[pingduck]

It kinds of look like a hack. I am concerned that router reloaded in the middle of an EEM execution could cause the wrong state to be saved. Is there a simpler way? I just want something to keep running when an interface is down. That should be quite common?

[Joe Clarke]

The multi-applet approach is quite clean.  It allows you to maintain the event-driven nature of EEM.  By using enhanced object tracking, you can also prevent the applet from running even after the router reloads.

A more hackish approach would be to run the applet every minute regardless of the interface state, and then check the state of the interface within the applet.  If the interface is found to be down, then continue to execute.  That approach would be something like:

event watchdog time 60

track read 1

if $_track_state eq "Up"

 exit 0

end

[pingduck]

Thanks for the tips. I think I have a solution. Please let know if there is any drawbacks.

event manager applet myapplet

event tag 1 track 10 state down

event tag 2 counter name tunnel1down entry-val 1 entry-op ge exit-val 1 exit-op ge

trigger

  correlate event 1 or event 2

action 1 track read 10

action 2 counter name "tunnel1down" op set value 0

action 3 if $_track_state eq "down"

action 4  puts "Do something!"

action 5  wait 10

action 6  counter name "tunnel1down" op inc value 1

action 8 end

[Joe Clarke]

I don't think this will do what you want.  It will trigger when the interface goes down (assuming that's what track 10 is monitoring), but it will not run every minute while the interface is down.  The moment you increment the counter, the policy will execute again (assuming your applet thread count is the default).  So each time through, the policy will run twice in close succession.

This is why I suggested the watchdog approach if you don't want to use the multi-applet approach.  The watchdog approach will allow you to control the execution time.

[pingduck]

The script works well for me. Note that the counter is incremented only after "sleep 10". Base on the syslog, "Do something" is seen every 10s once interface went down and stops after interface came back up.

The trigger is "interface down OR counter >= 1". The first trigger will be the interface down event. The subsequent trigger is count >= 1. I am not sure if the EEM applet must increment the counter again to trigger the applet again.