Category Archives: Embedded Event Manager

Using TFTP to change external IP address remotely

Here’s  a quick update to using EEM to change external IP adresses remotely on a router. While I’ve had success with that method, it has also failed miserably on me (thanks to my stupid typos).  EEM is a format all it’s own, and I often will fat-finger the order of statements. So I’ve discovered another, more reliable method. Here it is:

Router# copy tftp startup
Address or name of remote host []? 10.0.0.1
Source filename[]? newconfig.txt
Destination filename [startup-config]?
Accessing tftp://10.0.0.1/newconfig.txt...
Loading newconfig.txt from 10.0.0.1: !
[OK - 6105 bytes]
[OK]
6105 bytes copied in 2.620 secs (2330 bytes/sec)
Router#

Copy the existing config to notepad, make the necessary changes, and quadruple-check them.  Then tftp or ftp or scp the new config back to the startup-config file. Reboot. If you’ve got the config correct, you’re back in business with just one reboot. It doesn’t show your panache or swagger like EEM does. But don’t worry about that – save it for Swashbuckling School.

This is plain old common and boring and unsexy. But it just works. And that’s what you want.

Advertisements

Using EEM to change external IP addresses remotely

Have you ever had to remotely change the external IP address of router? How about a router that can’t be easily replaced?

It’s a bit of challenge, and hard to do without someone there to help you, or an out-of-band connection. Once you change the IP address itself  or no-out the default gateway, your connection drops.  If you’ve got an assistant, you can give them login credentials, and walk them through the rest (though this gets problematic, depending on the assistant).

Aside from an intriguing technical challenge, there’s significant business value in solving the problem also. In my case, this router was located in a border city in Mexico, and shipping a newly configured router really wasn’t an option. If we shipped a second router, the original invoice (not a copy), matched to the new routers’ serial number had to go with it, else it would be confiscated. Additionally, the original router would be held for three weeks before being returned to our field office. Re-configuring the original router would save the company roughly 5 days of site downtime while the second router was in transit, as well as the additional hardware and paperwork expense.

Our field technicians are general experienced in electrical engineering, not IT. If possible, I’d rather avoid putting them on the command line. So, in my search for better solution, I discovered the Cisco EEM (Embedded Event Manager). Of course, the EEM can do all sorts of magic as an embedded scripting engine on routers, but this little script was all it took to got the job done:

event manager applet AddressChange
 event syslog occurs 1 pattern "%SYS-5-RESTART: System restarted"
 action 001 cli command "enable"
 action 002 cli command "config terminal"
 action 003 cli command "int f4"
 action 004 cli command "ip add dhcp"
 action 005 cli command "exit"
 action 006 cli command "no ip route 0.0.0.0 0.0.0.0 x.x.x.x"
 action 007 cli command "no ip default-gateway x.x.x.x"

Happily, it even works. There are a couple of caveats though:

First, you’ve got the reload the router to invoke the EEM applet. It’s the syslog  message  “%SYS-5-RESTART: System restarted” that triggers the applet. Second, it’s best if you can reach the router before running the applet, to gather the correct ip route and ip default-gateway value. Not sure if a router will pass traffic correctly with two default routes (though it’s a good future experiment).

The applet can also be tuned to run by calling the applet manually.  Just replace

 event syslog occurs 1 pattern "%SYS-5-RESTART: System restarted"

with

 event none

and call the applet from the cmdline:

event manager run AddressChange

In this case, the power of the applet is that it runs internally, and continues to execute even if called from a TTY session, and that TTY gets disconneted.