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:
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:
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:
-
Put interface back up.
-
Generate a syslog message.
-
Open up for telnet administration to the router.
-
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:
This should now list something like this:
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:
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:
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:
and lets check if we are now able to telnet to R1 from R2:
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.