Cisco Embedded Event Manager (EEM) is a feature included in Cisco's IOS operating system (and some other Cisco OSes such as IOS-XR, IOS-XE, and NX-OS) that allow programmability and automation capabilities inside the device. EEM allows the behavior of a Cisco device to adapt to specific user requirements by allowing scripting, thresholding, proactive actions, data collection and event management inside the Cisco device itself. Using EEM, problems can be identified and resolved automatically in advance by setting event triggers (called Event Detectors) to watch for specific types of situations or thresholds, or run a set of actions periodically.
Cisco embedded management family
EEM is a member of a family of embedded management technologies in Cisco IOS including SNMP, NetFlow, IP SLA, Web Services Management Agent, Syslog, ESM (Embedded Syslog Manager), ERM (Embedded Resource Manager), EMM (Embedded Menu Manager), Tcl and Service Diagnostics.
When a situation is detected by EEM, it uses policies to invoke actions based on the type of event and the configured policy. EEM currently supports three different types of programming actions (see Programming Capabilities below).
About
With EEM, users can capture complex network events and run sophisticated programs on Cisco devices. The version of EEM on most Cisco devices is version 2.1, or version is 3.0 which was introduced in IOS 12.4(22)T. The latest version is version 4.0, which was released November 2011, targeting IOS releases 12.2SR, 12.2SB, 12.4, and 12.4T, 15.0M, 12.2SG, 12.2SE, Cisco IOS XE, and future versions. EEM consists of three areas; event detectors, policies and programming languages.
Event detectors
The brains of EEM are event detectors. These event detectors are built-in capabilities to watch for specific situations or conditions. Newer versions of EEM have more event detectors than older ones.
Programmatic applets, Netflow, IP SLA, Routing EDs
X
Example
There are four steps to setting up an EEM system. In this example, we will get an email of the status of the system when the HSRP state changes. This example defines an applet action rather than Tcl.
event manager environment _email_server 172.27.121.177<-- define the environment variable
event manager environment _email_to EMAIL_ADDRESS<-- define the address to which email will be sent
event manager environment _email_from EMAIL_ADDRESS<-- define the address from which the email will be sent
event manager applet email_hsrp_state_change<-- set up the policy
event syslog pattern ".*%HSRP-5-STATECHANGE.*"<-- define the trigger
action 1.0 info type routername<-- obtain the current device hostname and place it in the $_info_routername variable
action 1.1 cli command "enable"<-- actions such as writing to flash, making config changes, etc. require enable privilege
append flash:hsrp_state_change.txt"<-- write some debugging output to flash
flash:append hsrp_state_change.txt"<-- more debugging output
action 1.5 mail server "$_email_server" to "$_email_to" from "$_email_from" subject "HSRP_STATE_CHANGE Alert from $_info_routername: $_syslog_msg" body "$_cli_result"<-- send an email with the result of the last CLI command in the body of the message