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
circumstances.
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: 192.168.100.0/24.
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 192.168.100.1 YES manual up up FastEthernet0/1 172.16.0.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 network 192.168.0.0 0.0.255.255 auto-summary 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 192.168.100.2 Fa0/0 13 00:00:11 1 5000 2 0 interface FastEthernet0/0 description LAN-Segment ip address 192.168.100.1 255.255.255.0 ip access-group 110 in duplex auto speed auto end 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:
R2#telnet 192.168.100.1 Trying 192.168.100.1 ... % 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 192.168.100.100 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 "192.168.100.100" 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 R1(config-if)#sh R1(config-if)#^Z R1# *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: 1.2.3.4 : 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:
R2#telnet 192.168.100.1 Trying 192.168.100.1 ... Open User Access Verification Password:
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!