Cisco IOS Embedded Event Manager (EEM)

Embedded Event Manager (EEM) is a technology on Cisco Routers that lets you run scripts or
commands when a certain event happens. It’s probably best just to show you some examples to
see how it works. This is the topology that I will use:

Syslog Events
Syslog messages are the messages that you see by default on your console. Interfaces going up or
down, OSPF neighbors that dissapear and such are all syslog messages. EEM can take action
when one of these messages show up. Let’s start with an example that enables an interface once
it goes down.

Interface Recovery

The applet is called “INTERFACE_DOWN” and the event is a syslog pattern that matches the
text when an interface goes down. When this occurs, we run a number of commands. What
happens is that whenever someone shuts the interface, EEM will do a “no shut” on it.

To demonstrate that this works I’ll enable a debug:

This will show the commands that EEM runs when the event occurs. Let’s do a shut on that interface:

Within a few seconds you will see this:

The interface went down, EEM runs the commands and the interface is up again. Simple but I
think this is a good example to demonstrate how EEM works. Let’s see what else we can do…

OSPF Adjacency Changes

The next example is perhaps useful. Whenever the OSPF adjacency dissapears you will see a
syslog message on your console. We’ll use this message as the event and once it occurs, we
enable OSPF adjacency debugging and send an e-mail:
The event that I used is a syslog message that should look familiar. The first two actions are
executed on the CLI but the third action is for the e-mail. It will send a message to
[email protected] through SMTP-server “smtp.ziggo.nl”.

Let’s give it a try. I have to enable another debug if I want to see the mail action:

Once the OSPF neighbor adjacency is established, I’ll shut the interface on one of the routers so it
breaks:

And this is what you’ll see:

My router isn’t connected to the Internet but you can see it’s trying to contact the SMTP server
and send an e-mail. It also enabled the OSPF adjacency debug thanks to the CLI commands.

CLI Events
The previous two examples used syslog messages as the event but you can also take action based
on commands that are used on the CLI. The example below is a funny one, whenever someone
watches the running-configuration it will exclude all lines with the word “interface” in it:
As you can see above the event is a CLI pattern. the “sync yes” parameter is required, this tells
EEM to run the script before running the “show run” command. When the script is done, it sets
the exit status to 0. Basically this means that whenever someone uses the “show run” command,
the script will run “show run | exclude interface” instead and gives you the output.

Let’s see what the result is…

You will see the output of the running configuration and if you left the debug on, you’ll see what EEM is
doing behind the scenes:

Somewhere further down the running-config you can see that the lines with “interface” in them were
removed:
While this isn’t very useful, I think this is a good example to see what it does. A good real life
scenario might be hiding all lines that have “username” or “enable secret” in them for certain
users.

Interface Events
You have seen syslog and CLI pattern events, but we have some others. What about interface
counters? It might be useful to perform an action when some interface counters have a certain
value. Here’s an example:

Let’s create a script that does something when the interface load hits a certain value. To make this work,
it’s best to change the load interval of the interface first:

By using this command, the router will calculate the load of the interface every 30 seconds, the default
is 5 minutes. Let’s create the script:

This event is a bit harder to read…when the rx load of the interface is above 10/255 then we will
take action. Every 10 seconds we will check if we reached this value or not. When the event
occurs, a syslog message is produced.

To demonstrate this we’ll send some packets from R1 towards R2:

Once the interface rx load is above 10 you’ll see the following message on the console:

Pretty neat right? Sending an e-mail as the action might be a good idea when the interface load is above
60-70%.

Scheduling Events
Instead of launching actions based on syslog or CLI messages we can also use scheduled tasks.
This means that you can run actions every X minutes / hours / days etc. Here’s an example:

This script runs every 60 seconds and runs the “write memory” command. Once it’s done, it will produce
a syslog message. After waiting for 60 seconds we’ll see this:

Other Events and Actions

You have seen a couple of events and actions but EEM has a lot of options. Here’s a list to give
you some ideas:

Some other useful events are changes in the routing table, IP SLA, object tracking and configuration
changes. There is also a big list of possible actions:
R2(config-applet)#action 1.0 ?
add Add
append Append to a variable
break Break out of a conditional loop
cli Execute a CLI command
cns-event Send a CNS event
comment add comment
context Save or retrieve context information
continue Continue to next loop iteration
counter Modify a counter value
decrement Decrement a variable
divide Divide
else else conditional
elseif elseif conditional
end end conditional block
exit Exit from applet run
 force-switchover Force a software switchover
foreach foreach loop
gets get line of input from active tty
handle-error On error action
help Read/Set parser help buffer
if if conditional
increment Increment a variable
info Obtain system specific information
mail Send an e-mail
multiply Multiply
policy Run a pre-registered policy
publish-event Publish an application specific event
puts print data to active tty
regexp regular expression match
reload Reload system
set Set a variable
snmp-trap Send an SNMP trap
string string commands
subtract Subtract
syslog Log a syslog message
track Read/Set a tracking object
wait Wait for a specified amount of time
while while loop

Running CLI commands and sending e-mails are maybe the most important ones but you can
also generate SNMP traps or reload the router.

Anyway that’s the end of this tutorial. If you enjoyed this, please share it with your friends and
colleagues. If you have any other good EEM examples please leave a comment and I’ll add them
here.