There are a number of EEM use cases that call for a policy to wait for an extended amount of time before taking a particular action. For example, one might want to ensure a link is stable again before failing back to it, or ensure a steady or idle state before taking the desired action. In these cases, the intended wait time is longer than the maximum runtime of 20 seconds. While one can increase the maxrun timer, this is sub-optimal as the policy will remain active on the device and occupy a thread in the EEM server.
A better solution is to use EEM policy nesting. Nesting means that one policy is nested within another. That is, one policy will configure the second. This second, nested, policy is typically a timer policy that will countdown the desired wait time in seconds.
Let's look at example that uses Enhanced Object Tracking as the main event trigger. In this example, assume that tracked object 1 is monitoring an IPSLA collector that is checking for overall path availability. The intent is to wait for five minutes (300 seconds) after the tracked object comes back up before failing back over to the main interface. The environment variable "q" will be used to stand for a double quote (") so we can embed the quotes necessary for our nested policy. Typical '\' escaping does not work due to a bug. The environment variable approach is our workaround.
event manager environment q "
!
event manager applet track-up
event track 1 state up
action 001 cli command "enable"
action 002 cli command "config t"
action 003 cli command "event manager applet track-timer"
action 004 cli command "event timer countdown time 300"
action 005 cli command "action 1.0 cli command enable"
action 006 cli command "action 2.0 cli command $q config t$q"
action 007 cli command "action 3.0 cli command $q int cell0$q"
action 008 cli command "action 4.0 cli command $q shut$q"
action 009 cli command "action 5.0 cli command $q no event manager applet track-timer$q"
action 010 cli command "action 6.0 cli command end"
When the up policy runs, you will notice the following appears in the running configuration.
event manager applet track-timer
event timer countdown time 300
action 1.0 cli command "enable"
action 2.0 cli command " config t"
action 3.0 cli command " int cell0"
action 4.0 cli command " shut"
action 5.0 cli command " no event manager applet track-timer"
action 6.0 cli command "end"
In this case, you may be thinking, "how does the nested policy know that the link has been stable for those 300 seconds?" Let's have a look at the down policy now. Hopefully that will make things clear.
event manager applet track-down
event track 1 state down
action 001 cli command "enable"
action 002 cli command "config t"
action 003 cli command "no event manager applet track-timer"
action 004 cli command "int cell0"
action 005 cli command "no shut"
action 006 cli command "end"
Here you see that one of the actions within the down policy removes the timer policy. So, if the tracked object goes down again within the 300 second countdown, then the down policy will remove the countdown, and thus the backup link will remain up.
Using this same method, you can introduce an arbitrary delay in any desired workflow.
