Category: EEM

The IOS documentation claims that the quiet mode the router enters after a series of login failures blocks all telnet (or ssh) sessions as well as HTTP requests. Unfortunately the latter is wrong; you can execute any HTTP request on the router during the quiet mode.

If you want to block HTTP requests during the quiet mode, you can use EEM applets to change the HTTP server configuration when the quiet mode is started and completed.

Testing Embedded Event Manager (EEM) Tcl policies is a convoluted process:

• Source file is usually edited on a general-purpose workstation.
• The file has to be downloaded to router's local storage (EEM does not register non-local policies).
• The new version of the EEM policy has to be registered with EEM with event manager policy configuration command
• After all these steps, the new policy can be tested.

While you can use EEM applet to automate this process, slightly more flexible approach (you can specify the policy name to be replaced) can be implemented with Tcl script:

If you want to execute IOS show commands periodically (for example, to monitor router status or take snapshots of routing tables), you can combine new output redirection features introduced in IOS release 12.2T in an Embedded Event Manager (EEM) applet. For example, to store the brief interface status into a file on an FTP server, use the following EEM applet:

event manager applet SaveInterfaceStatus
 event timer watchdog name SaveIfStat time 60
 action 1.0 cli command "show ip interface brief | redirect ftp://username@password:host/path"
 action 2.0 syslog msg "Interface status saved"

Notes:

One of my readers asked an interesting question: „why do the commands executed within a EEM Tcl policy fail with Command authorization fails message?“ The short answer is simple: If you use AAA command authorization (which you can only do if you're using a TACACS+ server), you have to specify the username under which the EEM will execute its CLI commands with the event manager session cli username user configuration command.

Sometimes, parts of router configuration get lost during the reload process: although the configuration commands are saved in NVRAM, they are not processed after the reload and thus do not appear in the running configuration. Re-entering these commands manually solves the problem ... but it's obviously not a reliable solution.

Embedded Event Manager (EEM) solves this issue as well. You just configure an applet that triggers on syslog message SYS-5-RESTART and reapplies the necessary configuration commands.

Sometimes you'd like to automate execution of command sequences or create a command alias that would trigger a series of commands. One way of achieving this is by creating an EEM applet. For example, to clear IP routing table and reset BGP neighbors, define the following EEM applet:

event manager applet ClearAll
 event none
 action 1.0 cli command "clear ip route *"
 action 2.0 cli command "clear ip bgp *"

You can trigger this applet with the event manager run ClearAll command or you could configure a command alias, for example alias exec cleanup event manager run ClearAll.

One of my readers has asked an interesting question: can you reload a router when pinging a specific IP address from it fails? While there are other ways of dealing with stuck interfaces or routing processes, sometimes such a drastic measure is the only workaround, so here's how you do it:

You might have wondered what happens with output produced by Tcl procedures (for example, with the puts command) when you use Tcl in Embedded Event Manager (EEM) or Embedded Syslog Manager (ESM). If the Tcl procedure executes in context of a line (console or virtual terminal), the output is sent straight to the attached line, otherwise it's processed by the logging manager (resulting in a syslog message).

There are two scenarios where Tcl would execute in context of a line: if you start a Tcl procedure with the tclsh command or if it's an EEM policy registered with the event_register_cli with sync parameter set to yes.

Someone has recently asked an interesting question - can you disable the reload command? Although I would strongly discourage you from doing that (after all, every router I've ever worked on since a venerable MGS running IOS 10.0 had to be reloaded every now and then), here's what you can do:

• define an alias for the reload command that does something else. For example, alias exec reload show ip interface brief. While this would remind a careless operator, it would still not prevent someone using an abbreviation like relo to reload the device.
• Use TACACS+ command accounting and disable the reload command on the TACACS+ server. The benefit of this approach is that you can do it on user-by-user basis ... but of course you need TACACS+ server, RADIUS will not do.
• Disable the reload command with the Embedded Event Manager applet.

Developing Embedded Event Manager (EEM) Tcl policies is "a bit" tedious task. Usually you would edit the source file on an external workstation, then you have to download it into the router (IOS will not read EEM policy from an external source), re-register it with EEM (when you register a policy it gets copied from the source file into system:lib/tcl/eem_registered_scripts directory) and test it. To automate this process, I've written a small EEM applet that does the tedious steps automatically.