Cisco’s Embedded Event Manager (EEM) is a powerful tool that can be configured to detect specific events and respond to those events in specific ways.
EEM was introduced in the early 2000s and is one of the earliest attempts at network automation. Even so, it is still used extensively today and remains a versatile tool in the arsenal of the network administrator.
In this article, we’ll explain in more detail what EEM is and how it works, and we’ll take a look at some examples of implementation.
What is Cisco EEM (Embedded Event Manager)?
EEM is a CLI-based facility that detects events and performs preconfigured actions based on those events.
Using EEM you can create what are known as applets that identify a particular event, such as a specific Syslog message appearing on the CLI, a change in the status of an interface, or a change in an OSPF adjacency for example.
The applet can be configured such that once that event is detected, it performs one or more actions, such as running a set of commands, sending an email, or printing specific text on the CLI.
EEM Support
According to Cisco documentation, EEM is available on a wide range of IOS devices including both routers and switches.
Because it is a very mature technology, it has a very large support base, but you should still ensure that your particular IOS platform supports it.
Indeed, the Cisco Community has an extensive amount of information about EEM scripting, and you can find a lot of information there.
In addition, EEM can be used directly from the Cisco IOS command line, or you can use a more advanced command prompt called Tool Command Language (Tcl) for more granular and greater control. For the purposes of this article however, we’ll be sticking to the CLI configuration of EEM.
The latest version of EEM is 4.0 which was released in 2011. Cisco isn’t investing in furthering the development of the framework. Even so, EEM continues to be a relevant and supported feature in Cisco devices to this day.
EEM Operations
EEM supports more than 20 event detectors and over 30 action categories. But enough talk. You won’t really understand what it is unless you see it in action…
EEM Examples
The following examples will help you to understand the logic behind the creation and execution of EEM applets. These are by no means exhaustive but should give you a good idea of how to begin using EEM.
Syslog Events
Let’s start with creating an applet that will detect a particular string from a Syslog event, and respond to that event by issuing some specific commands.
Let’s say that if the GigabitEthernet 0/3 interface goes down, we will bring it back up by issuing the “no shutdown” command in the appropriate interface configuration mode.
To do so, let’s create the following applet:
R1(config)#event manager applet RESTORE_INT
R1(config-applet)#event syslog pattern “Interface GigabitEthernet0/3, changed state to down”
R1(config-applet)#action 1.0 cli command “enable”
R1(config-applet)#action 2.0 cli command “configure terminal”
R1(config-applet)#action 3.0 cli command “interface gigabitethernet0/3”
R1(config-applet)#action 4.0 cli command “no shutdown”
R1(config-applet)#
Let me explain what We’ve done here.
- We entered the event manager applet configuration mode by issuing the “event manager applet“
- We’ve created an applet named RESTORE_INT.
- Using the “event syslog pattern” command, we instruct the applet to match Syslog events that contain the text between the quotes. This text will appear if the Gi0/3 interface goes down.
- When this event is detected, then all of the actions configured are taken. Note that:
- Each action is given a label which can be any text. Here, we used numbers as labels, but those labels can be any string of text.
- The specific actions are CLI commands due to the cli command
- The commands that are to be issued are those in the quotes.
So whenever a Syslog message appears that indicates that Gi0/3 has gone down, the applet will issue the necessary commands to enter the interface configuration mode and bring up the interface. Let’s see this in action by manually shutting down the Gi0/3 interface:
R1(config)#interface gigabitethernet0/3
R1(config-if)#shutdown
R1(config-if)#^z
R1#%LINK-5-CHANGED: Interface GigabitEthernet0/3, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down
%LINK-3-UPDOWN: Interface GiabitEthernet0/3, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up
You can see that as soon as the text (in red) appeared, the event in the applet was matched. Shortly afterward, we see new Syslog messages indicating that the interface is back up. Note that the text that was matched by the EEM script was that in red from the line protocol, and not the link change Syslog message.
Also, note that the commands issued by the EEM script do not actually appear in the CLI. If you want to see them, you can do so by issuing the “debug event manager action cli” debug command, and then have the EEM script run again.
Scheduling Events
You can also create applets that will have scheduled events and respond with actions. These scheduled events can occur periodically at a frequency of your choosing. The following applet runs every hour and issues the “write memory” command, which essentially saves the running configuration to the startup-config.
R1(config)#event manager applet PERIODIC_SAVE
R1(config-applet)#event timer watchdog time 3600
R1(config-applet)#action 1.0 cli command “enable”
R1(config-applet)#action 2.0 cli command “write memory”
R1(config-applet)#action 3.0 syslog priority informational msg “Configuration has been saved”
This applet called PERIODIC_SAVE will run every 3600 or every hour and will save the running-config to the startup-config. It will also produce a Syslog message on the command line stating that the “Configuration has been saved”. When the applet runs, you should see something like this:
%HA_EM-6-LOG: TIMER: Configuration has been saved
EEM Events and Actions
EEM has many options and the only way to really understand how powerful it is and what it is capable of is to experiment. Context-sensitive help is available in the CLI interface, and here you can see all of the event categories that can be used:
R1(config-applet)#event ?
application Application specific event
cli CLI event
config Configuration policy event
counter Counter event
env Environmental event
identity Identity event
interface Interface event
ioswdsysmon IOS WDSysMon event
ipsla IPSLA Event
neighbor-discovery Neighbor Discovery event
nf NF Event
none Manually run policy event
oir OIR event
resource Resource event
rf Redundancy Facility event
routing Routing event
rpc Remote Procedure Call event
snmp SNMP event
snmp-notification SNMP Notification Event
snmp-object SNMP object event
syslog Syslog event
tag event tag identifier
timer Timer event
track Tracking object event
Additionally, the action categories can similarly be examined like so:
R1(config-applet)#action 1.0 ?
add Add
append Append to a variable
break Break out of a conditional loop
cli Execute a CLI command
cns-event Send a CNS event
comment add comment
context Save or retrieve context information
continue Continue to next loop iteration
counter Modify a counter value
decrement Decrement a variable
divide Divide
else else conditional
elseif elseif conditional
end end conditional block
exit Exit from applet run
file file operations
force-switchover Force a software switchover
foreach foreach loop
gets get line of input from active tty
handle-error On error action
help Read/Set parser help buffer
if if conditional
increment Increment a variable
info Obtain system specific information
mail Send an e-mail
multiply Multiply
policy Run a pre-registered policy
publish-event Publish an application specific event
puts print data to active tty
regexp regular expression match
reload Reload system
set Set a variable
snmp-object-value Specify value for the SNMP get request
snmp-trap Send an SNMP trap
string string commands
subtract Subtract
syslog Log a syslog message
track Read/Set a tracking object
wait Wait for a specified amount of time
while while loop
You can see from these lists that EEM is quite sophisticated and can be used to create very complex and intricate network automation.
You can see from these lists that EEM is quite sophisticated and can be used to create very complex and intricate network automation.
Conclusion
Cisco’s EEM has been a pivotal tool in network automation for many years, offering customized monitoring and automation directly within Cisco devices.
However, its future in the rapidly evolving landscape of network management is not clearly defined. The emergence of more inclusive and flexible network automation solutions over the past few years indicates a trend towards platforms that can manage multi-vendor, cloud-connected infrastructures, something for which EEM has not been designed.
Even so, EEM remains a very important part of Cisco’s network automation approach and is expected to remain so for many years to come.
Related Posts
- Monitoring Cisco Network Infrastructure: What to Look for in an Ideal Cisco Monitoring Tool
- How to Reset Cisco Router or Switch to Factory Settings
- Comparison of LLDP vs CDP on Cisco Networking Devices
- Comparison of BGP Confederations vs Route Reflectors
- What are BGP Confederations-Explanation and Discussion (With Cisco Example)