This article will discuss the Embedded Event Manager (EEM) feature present on Cisco devices. EEM allows the user to monitor events and take actions if the monitored events happen or when the threshold configured is reached.

An event that is defined along with the action to be taken when that event happens is called an EEM policy. We will discuss about this later in the article.

CCNA Training – Resources (Intense)

EEM is implemented directly in Cisco IOS software. It works through event detectors and actions. An event detector is a software routine which is used to determine when an event occurs. An action is a CLI action which is taken when an event detector reports an event.

There are multiple EEM versions and they are available in different IOS releases. The difference between EEM versions is that new event detectors and actions were added to more recent releases. Also some of the EEM versions introduced enhancements to the already available event detectors.

Some of the events detectors and actions are available in every Cisco IOS release.

There are multiple event detectors and probably one of the most used is the Syslog Event Detector. This event detector parses the syslog messages looking for a regular expression or a string. Once there is a match, an action is triggered based on how the EEM policy is configured.

Also, there are many actions available. Some of the most used ones are: executing a CLI command, sending a SNMP trap, generating a syslog message and sending an email.

So let’s use EEM with some event detectors and some actions in EEM policies.

This is our topology:

For reachability purposes, OSPF is running on all three routers and the hosts have connectivity.

Also, OSPF on R1 has been configured in such way that the traffic between PC_1 and PC_2 will go through R3 (not the optimal path, but it will serve our testing purposes):

tc@PC_1:~$ traceroute 10.10.2.100
traceroute to 10.10.2.100 (10.10.2.100), 30 hops max, 38 byte packets
1 10.10.1.1 (10.10.1.1) 208.306 ms 16.402 ms 10.407 ms
2 10.10.13.3 (10.10.13.3) 106.734 ms 17.606 ms 18.615 ms
3 10.10.23.2 (10.10.23.2) 45.663 ms 27.014 ms 28.856 ms
4 10.10.2.100 (10.10.2.100) 123.719 ms 64.594 ms 85.154 ms
tc@PC_1:~$

Let’s configure an EEM policy that will accomplish the following: if the OSPF adjacency between R3 and R2 goes down, then shutdown F1/0 on R3. Let’s say that you want to do this because R3 is acting only as a transit router and if one of its OSPF adjacencies is down, there is no point in keeping the other one up.

The EEM policy will need a syslog detector, which means that the log messages will be monitored for a specific string/regex. If that string is detected, then an action will be applied. In this case, the actions will be a CLI command and a syslog generated message.

This is the EEM policy configuration:

event manager applet OSPF_CHECK
event syslog pattern "Nbr 10.10.23.2 on FastEthernet1/0 from FULL to DOWN"
action 1.0 cli command "enable"
action 1.5 cli command "config t"
action 2.0 cli command "interface fa1/0"
action 2.5 cli command "shutdown"
action 3.0 cli command "end"
action 3.5 syslog msg "Interface F1/0 disabled by EEM"

Once this is configured, you can check the status of the EEM policies (i.e. what kind of detectors are used, when they were configured) by using the command ‘show event manager policy registered’:

R3#show event manager policy registered
No. Class Type Event Type Trap Time Registered Name
1 applet user syslog     Off Fri Mar 1 04:13:56 2002 OSPF_CHECK
pattern {Nbr 10.10.23.2 on FastEthernet1/0 from FULL to DOWN}
action 1.0 cli command "enable"
action 1.5 cli command "config t"
action 2.0 cli command "interface fa1/0"
action 2.5 cli command "shutdown"
action 3.0 cli command "end"
action 3.5 syslog msg "Interface disabled by EEM"

R3#

So, let’s see this in action. I will shutdown F2/0 on R2 to make the OSPF adjacency between R2 and R3 go down and generate the log on R3:

R2#conf t

*Mar 1 04:51:23.114: %SYS-5-CONFIG_I: Configured from console by console
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface f2/0
R2(config-if)#shutdown
R2(config-if)#end
R2#

And once we see this on R3:

*Mar 1 04:52:26.730: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.23.2 on FastEthernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired

The EEM policy will detect the log entry and apply the actions.

For additional detail, I enabled EEM policy debug for CLI actions using ‘debug event manager action cli’.

This is the result of the debug operation:

*Mar 1 04:52:26.786: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : CTL : cli_open called.
*Mar 1 04:52:26.886: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT :
*Mar 1 04:52:26.886: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : R3>
*Mar 1 04:52:26.886: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : IN : R3>enable
*Mar 1 04:52:26.918: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT :
*Mar 1 04:52:26.918: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : R3#
*Mar 1 04:52:26.922: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : IN : R3#config t
*Mar 1 04:52:26.954: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT :
*Mar 1 04:52:26.954: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
*Mar 1 04:52:26.954: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : R3(config)#
*Mar 1 04:52:26.954: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : IN : R3(config)#interface fa1/0
*Mar 1 04:52:26.994: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT :
*Mar 1 04:52:26.994: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : R3(config-if)#
*Mar 1 04:52:26.994: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : IN : R3(config-if)#shutdown
*Mar 1 04:52:27.058: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT :
*Mar 1 04:52:27.062: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : R3(config-if)#
*Mar 1 04:52:27.062: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : IN : R3(config-if)#end
*Mar 1 04:52:27.086: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:OSPF_CHECK)
*Mar 1 04:52:27.186: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT :
*Mar 1 04:52:27.186: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : OUT : R3#
*Mar 1 04:52:27.186: %HA_EM-6-LOG: OSPF_CHECK: Interface disabled by EEM

*Mar 1 04:52:27.186: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : IN : R3#exit
*Mar 1 04:52:27.186: %HA_EM-6-LOG: OSPF_CHECK : DEBUG(cli_lib) : : CTL : cli_close called.

Right away after the debug output, I could see the log saying that F1/0 was administratively shutdown:

R3#

*Mar 1 04:52:29.002: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down
*Mar 1 04:52:30.002: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down

R3#

The debug output is more than self-explanatory.

Let’s check if interface F1/0 was shutdown:

R3#show interface f1/0

FastEthernet1/0 is administratively down, line protocol is down
Hardware is AmdFE, address is cc14.1e84.0010 (bia cc14.1e84.0010)
Internet address is 10.10.23.3/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255

You can also check when the event detector of the EEM policy triggered the action using the command ‘show event manager history events detailed’:

R3#show event manager history events detailed

No. Time of Event Event Type Name
1 Fri Mar 1 04:28:54 2002 syslog applet: OSPF_CHECK
msg {*Mar 1 04:28:54.926: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.23.2 on FastEthernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired}
2 Fri Mar 1 04:52:26 2002 syslog applet: OSPF_CHECK
msg {*Mar 1 04:52:26.730: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.23.2 on FastEthernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired}

R3#

As you can see, there were two occurrences of the string in the syslog, which means that the OSPF between R2 and R3 went down twice since I configured the EEM policy.

Let’s take another example. Let’s say that you would like to shutdown an interface and bring it back up every day at specific times, for Windows maintenance for instance.

Let’s create two policies that will do this. They are already configured so let’s check them:

R1#show event manager policy registered

No. Class Type Event Type Trap Time Registered Name
1 applet user timer cron      Off Thu Jul 24 20:53:05 2014 SHUTDOWN
name {SHUTDOWN} cron entry {55 20 * * *}
maxrun 20.000
action 0.5 cli command "enable"
action 1.0 cli command "configure terminal"
action 1.5 cli command "interface f1/0"
action 2.0 cli command "shutdown"
action 2.5 cli command "end"
action 3.0 syslog msg "EEM SHUTDOWN - f1/0 shutdown"

2 applet user timer cron      Off Thu Jul 24 20:53:07 2014 NO_SHUTDOWN
name {NO_SHUTDOWN} cron entry {56 20 * * *}
maxrun 20.000
action 0.5 cli command "enable"
action 1.0 cli command "configure terminal"
action 1.5 cli command "interface f1/0"
action 2.0 cli command "no shutdown"
action 2.5 cli command "end"
action 3.0 syslog msg "EEM SHUTDOWN - f1/0 no shutdown"

R1#

Let’s check the clock on the router:

R1#show clock

*20:53:13.786 UTC Thu Jul 24 2014

R1#

This line from the EEM policy says that the SHUTDOWN policy will take action at 20:55:

name {SHUTDOWN} cron entry {55 20 * * *}

And this one says that the NO_SHUTDOWN policy will take action at 20:56:

name {NO_SHUTDOWN} cron entry {56 20 * * *}

After the EEM debug was activated, this is seen at 20:55:

*Jul 24 20:55:00.034: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : CTL : cli_open called.
*Jul 24 20:55:00.050: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT : R1>
*Jul 24 20:55:00.054: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : IN : R1>enable
*Jul 24 20:55:00.082: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT : R1#
*Jul 24 20:55:00.082: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : IN : R1#configure terminal
*Jul 24 20:55:00.126: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
*Jul 24 20:55:00.130: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT : R1(config)#
*Jul 24 20:55:00.130: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : IN : R1(config)#interface f1/0
*Jul 24 20:55:00.170: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT : R1(config-if)#
*Jul 24 20:55:00.174: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : IN : R1(config-if)#shutdown
*Jul 24 20:55:00.210: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT :

R1# R1(config-if)#

*Jul 24 20:55:00.214: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : IN : R1(config-if)#end
*Jul 24 20:55:00.262: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:SHUTDOWN)
*Jul 24 20:55:00.290: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : OUT : R1#
*Jul 24 20:55:00.294: %HA_EM-6-LOG: SHUTDOWN: EEM SHUTDOWN - f1/0 shutdown
*Jul 24 20:55:00.294: %HA_EM-6-LOG: SHUTDOWN : DEBUG(cli_lib) : : CTL : cli_close called.
*Jul 24 20:55:00.310:
*Jul 24 20:55:00.314: tty is now going through its death sequence

And one minute later, the same interface is brought back and the OSPF adjacency with R3 is up again:

*Jul 24 20:56:00.070: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : CTL : cli_open called.
*Jul 24 20:56:00.106: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : OUT : R1>
*Jul 24 20:56:00.110: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : IN : R1>enable
*Jul 24 20:56:00.234: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : OUT : R1#
*Jul 24 20:56:00.238: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : IN : R1#configure terminal
*Jul 24 20:56:00.290: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line. End with CNTL/Z.
*Jul 24 20:56:00.294: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : OUT : R1(config)#
*Jul 24 20:56:00.298: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : IN : R1(config)#interface f1/0
*Jul 24 20:56:00.434: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : OUT : R1(config-if)#
*Jul 24 20:56:00.438: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : IN : R1(config-if)#no shutdown
*Jul 24 20:56:00.718: %HA_EM-6-LOG: NO

R1#_SHUTDOWN : DEBUG(cli_lib) : : OUT : R1(config-if)#

*Jul 24 20:56:00.726: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : IN : R1(config-if)#end
*Jul 24 20:56:00.754: %SYS-5-CONFIG_I: Configured from console by on vty0 (EEM:NO_SHUTDOWN)
*Jul 24 20:56:00.858: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : OUT : R1#
*Jul 24 20:56:00.866: %HA_EM-6-LOG: NO_SHUTDOWN: EEM SHUTDOWN - f1/0 no shutdown
*Jul 24 20:56:00.870: %HA_EM-6-LOG: NO_SHUTDOWN : DEBUG(cli_lib) : : CTL : cli_close called.
*Jul 24 20:56:01.010:
*Jul 24 20:56:01.010: tty is now going through its death sequence

R1#

*Jul 24 20:56:02.614: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up

R1#

*Jul 24 20:56:03.614: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up

R1#

*Jul 24 20:56:08.774: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.13.3 on FastEthernet1/0 from LOADING to FULL, Loading Done

R1#

And with this being said, we reached the end of the article.

I hope you found this article very interesting. What I have discussed and shown in this article is just a glimpse of what you can accomplish with EEM.

Basically the only limitation is your imagination. Of course if you don’t know the features, then you won’t know that you can use them. That’s why I advise you to check the references below in order to learn more about EEM.

References: