Learning EEM (Embedded Event Manager).

Awesome. Got alot of EEM ground covered today.

Seems like a very powerful scripting engine that stands out, by having the ability to be triggered under certain


Lets check out an example using the topology below:

EEM Topology

R1 is connected to an ethernet segment. Imagine that on this ethernet segment we have multiple things running.
In order to test things out, imagine that R2 is our NMS.
The ethernet segment is using the following subnet:
Imagine that R1 is tracking an interface which is directly connected to a segment that contains your SQL cluster.
If for some reason this interface goes down, you want to be alerted immediately.
In addition to this, R1 is locked down pretty tight, only allowing incomming routing information and nothing else.
Here’s some configuration snippets from R1:

R1(config-if)#do sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0     YES manual up                    up
FastEthernet0/1        YES manual up                    up
R1(config-if)#do sh int descr
Interface                      Status         Protocol Description
Fa0/0                          up             up       LAN-Segment
Fa0/1                          up             up       SQL-Cluster-Segment
R1(config-router)#do sh run | sec eigrp
router eigrp 100
 R1(config-router)#do sh ip ei nei
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
 (sec)         (ms)       Cnt Num
0           Fa0/0             13 00:00:11    1  5000  2  0
interface FastEthernet0/0
 description LAN-Segment
 ip address
 ip access-group 110 in
 duplex auto
 speed auto
R1(config)#do sh access-list
Extended IP access list 110
 10 permit eigrp any any (36 matches)

As you can see, we have our interfaces defined, they are in an up state, we have EIGRP working, we have an access-list applied,

which is denying anything else than EIGRP.

Lets make sure that we cannot access R1 from R2 in a normal situation:

Trying ...
% Destination unreachable; gateway or host down

Alright, so everything is in a stable state.

So the task is, if the Fa0/1 interface on R1 goes down, we want to try and put the interface back up. In addition to this

we want to send an email to the administrator, generate a syslog message (i know this can be done by other means) and

allow access to the router for telnet administration. So three things:

1) Put interface back up.

2) Generate a syslog message.

3) Open up for telnet administration to the router.

4) Email the administrator.

Lets setup some things we need to utilize in our EEM applet.

First off, lets setup a tracking object to track the interface to the SQL Cluster Segment:

track 1 interface f0/1 line-protocol

This should now list something like this:

R1#sh track
Track 1
 Interface FastEthernet0/1 line-protocol
 Line protocol is Up
 9 changes, last change 00:21:27

With this, we are now actively tracking the interface toward the SQL Cluster.

Now to create the access-list we want implemented in case the interface goes down:

access-list 120 permit tcp any any eq telnet
access-list 120 permit tcp host any
access-list 120 permit eigrp any any

This states, that in addition to the EIGRP that was originally allowed, it is now possible to use telnet to access R1. We are also allowing traffic from the SMTP server.

We now have things in place to create the EEM applet:

event manager applet OUR-APP
 event track 1 state down
 action 2.0 syslog msg "Oh dear. The interface has gone down."
 action 3.0 cli command "enable"
 action 3.1 cli command "conf t"
 action 3.2 cli command "int f0/1"
 action 3.3 cli command "no sh"
 action 4.0 cli command "int f0/0"
 action 4.1 cli command "ip access-group 120 in"
 action 5.0 mail server "" to "admin@local" from "R1@local" subject "SQL Cluster Segment down" body "SQL Cluster Segment is down. I have tried putting the interface back up, and i have now allowed you telnet access."

Lets analyse this a bit further.

We will use an event that tells the applet to track the number 1 tracking object. Only if this tracking object is in a down state, do we want to execute this applet.

Things are then executed in order.

The 2.0 action, sends a syslog message.

The 3.x actions performs some CLI tasks, that will try and put the f0/1 interface back into an up state.

The 4.x actions also performs CLI tasks, going into the f0/0 interface and applies a different ACL to allow access through telnet.

Finally the 5.0 action sends a mail to the administrator through a certain SMTP server (relaying and all that assumed to be working).

Thats basically all there is to it!

Now to verify it all. We will shut down the f0/1 interface and see what happens:

R1(config)#int f0/1
*Mar  1 00:56:28.155: %TRACKING-5-STATE: 1 interface Fa0/1 line-protocol Up->Down
*Mar  1 00:56:28.223: %HA_EM-6-LOG: OUR-APP: Oh dear. The interface has gone down.
*Mar  1 00:56:28.299: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:56:28.439: %TRACKING-5-STATE: 1 interface Fa0/1 line-protocol Down->Up
*Mar  1 00:56:30.151: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 00:56:40.711: %HA_EM-3-FMPD_SMTP: Error occured when sending mail to SMTP server: : error in connecting to SMTP server
*Mar  1 00:56:40.711: %HA_EM-3-FMPD_ERROR: Error executing applet OUR-APP statement 5.0

and lets check if we are now able to telnet to R1 from R2:

Trying ... Open
User Access Verification

Great! we can now access the router and perform further troubleshooting. Note in the output above, that we do log a syslog message. Also note

that we try and send an email, but since i dont have any SMTP server on that network, it wont work.

Task performed. Hope it helped clear up some stuff on when and how to use this feature!

Take care!