Table Of Contents
Prerequisites for Embedded Event Manager 2.1
Information About Embedded Event Manager 2.1
Embedded Event Manager Actions
Embedded Event Manager Environment Variables
Embedded Event Manager Policies
How to Configure Embedded Event Manager 2.1
Registering and Defining an Embedded Event Manager Applet
Registering and Defining an Embedded Event Manager Policy to Run Manually
Displaying Embedded Event Manager Registered Policies
Unregistering Embedded Event Manager Policies
Suspending Embedded Event Manager Policy Execution
Modifying History Table Size and Displaying EEM History Data
Configuration Examples for Embedded Event Manager 2.1
Embedded Event Manager Applet Configuration: Examples
Embedded Event Manager Manual Policy Execution: Examples
Embedded Event Manager Watchdog System Monitor Event Detector Configuration: Example
event manager scheduler suspend
event manager scheduler script
event manager session cli username
show event manager directory user
show event manager environment
show event manager history events
show event manager history traps
show event manager policy available
show event manager policy pending
show event manager policy registered
show event manager session cli username
Embedded Event Manager 2.1
Embedded Event Manager (EEM) is a distributed and customized approach to event detection and recovery offered directly in a Cisco IOS device. EEM offers the ability to monitor events and take informational, corrective, or any desired action when the monitored events occur or when a threshold is reached. An EEM policy is an entity that defines an event and the actions to be taken when that event occurs.
EEM 2.1 introduces some new event detectors and actions, some new functionality to allow EEM policies to be run manually, and the ability to run multiple concurrent policies. Support for Simple Network Management Protocol (SNMP) event detector rate-based events is provided as is the ability to create policies using Tool Command Language (Tcl).
History for the Embedded Event Manager Feature
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for Embedded Event Manager 2.1
•
Information About Embedded Event Manager 2.1
•
How to Configure Embedded Event Manager 2.1
•
Configuration Examples for Embedded Event Manager 2.1
Prerequisites for Embedded Event Manager 2.1
•
If the action cns-event command is used, access to a CNS Event gateway must be configured.
•
If the action force-switchover command is used, a secondary processor must be configured on the device.
•
If the action snmp-trap command is used, the snmp-server enable traps event-manager command must be enabled to permit SNMP traps to be sent from the Cisco IOS device to the SNMP server. Other relevant snmp-server commands must also be configured; for details see the action snmp-trap command page.
Information About Embedded Event Manager 2.1
To configure Embedded Event Manager, you should understand the following concepts:
•
Embedded Event Manager Actions
•
Embedded Event Manager Environment Variables
•
Embedded Event Manager Policies
Embedded Event Manager
Event tracking and management has traditionally been performed by devices external to the networking device. Embedded Event Manager (EEM) has been designed to offer event management capability directly in Cisco IOS devices. The on-device, proactive event management capabilities of EEM are useful because not all event management can be done off router because some problems compromise communication between the router and the external network management device. Capturing the state of the router during such situations can be invaluable in taking immediate recovery actions and gathering information to perform root-cause analysis. Network availability is also improved if automatic recovery actions are performed without the need to fully reboot the routing device.
EEM is a flexible, policy-driven framework that supports in-box monitoring of different components of the system with the help of software agents known as event detectors. Figure 1 shows the relationship between the EEM server, core event publishers (event detectors), and the event subscribers (policies). Basically, event publishers screen events and publish them when there is a match on an event specification that is provided by the event subscriber. Event detectors notify the EEM server when an event of interest occurs. The EEM policies that are configured using the Cisco IOS command-line interface (CLI) then implement recovery on the basis of the current state of the system and the actions specified in the policy for the given event.
Figure 1 Embedded Event Manager Core Event Detectors
EEM offers the ability to monitor events and take informational or corrective action when the monitored events occur or when a threshold is reached. An EEM policy is an entity that defines an event and the actions to be taken when that event occurs. There are two types of EEM policies: an applet or a script. An applet is a simple form of policy that is defined within the CLI configuration. A script is a form of policy that is written in Tool Command Language (Tcl).
EEM Applet
An EEM applet is a concise method for defining event screening criteria and the actions to be taken when that event occurs. In applet configuration mode, three types of configuration statements are supported. The event commands are used to specify the event criteria to trigger the applet to run, the action commands are used to specify an action to perform when the EEM applet is triggered, and the set command is used to set the value of an EEM applet variable. Currently only the _exit_status variable is supported for the set command.
Only one event configuration command is allowed within an applet configuration. When applet configuration mode is exited and no event command is present, a warning is displayed stating that no event is associated with this applet. If no event is specified, this applet is not considered registered. When no action is associated with this applet, events are still triggered but no actions are performed. Multiple action configuration commands are allowed within an applet configuration. Use the show event manager policy registered command to display a list of registered applets.
Before modifying an EEM applet, be aware that the existing applet is not replaced until you exit applet configuration mode. While you are in applet configuration mode modifying the applet, the existing applet may be executing. It is safe to modify the applet without unregistering it. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.
The action configuration commands are uniquely identified using the label argument, which can be any string value. Actions are sorted in ascending alphanumeric key sequence using the label argument as the sort key, and they are run using this sequence.
The Embedded Event Manager schedules and runs policies on the basis of an event specification that is contained within the policy itself. When applet configuration mode is exited, EEM examines the event and action commands that are entered and registers the applet to be run when a specified event occurs.
EEM Script
Scripts are defined off the networking device using an ASCII editor. The script is then copied to the networking device and registered with EEM. Tcl scripts are supported by EEM.
EEM allows you to write and implement your own policies using Tcl. Writing an EEM policy involves:
•
Selecting the event for which the policy is run.
•
Defining the event detector options associated with logging and responding to the event.
•
Choosing the actions to be followed when the event occurs.
Cisco provides enhancements to Tcl in the form of keyword extensions that facilitate the development of EEM policies. The main categories of keywords identify the detected event, the subsequent action, utility information, counter values, and system information. For more details about writing EEM policies using Tcl, see the "Writing Embedded Event Manager Policies Using Tcl" module.
Embedded Event Manager 2.1
EEM 2.1 is supported in Cisco IOS Release 12.3(14)T and 12.2(28)SB and later releases, and introduced some new features. EEM 2.1 introduces the following new event detectors:
•
CLI—The CLI event detector screens command-line interface (CLI) commands for a regular expression match.
•
None—The none event detector publishes an event when the Cisco IOS event manager run CLI command executes an EEM policy.
•
OIR—The online insertion and removal (OIR) event detector publishes an event when a particular hardware insertion or removal event occurs.
EEM 2.1 introduces the following actions:
•
Executing a Cisco IOS command-line interface (CLI) command.
•
Requesting system information when an event occurs.
•
Sending a short e-mail.
•
Manually running an EEM policy.
EEM 2.1 also permits multiple concurrent policies to be run using the new event manager scheduler script command. Support for Simple Network Management Protocol (SNMP) event detector rate-based events is provided as is the ability to create policies using Tool Command Language (Tcl).
Event Detectors
Embedded Event Manager (EEM) uses software programs known as event detectors to determine when an EEM event occurs. Event detectors are separate systems that provide an interface between the agent being monitored, for example Simple Network Management Protocol (SNMP), and the EEM policies where an action can be implemented. EEM 2.1 contains the following event detectors.
Application-Specific Event Detector
The application-specific event detector allows any Embedded Event Manager policy to publish an event. When an EEM policy publishes an event it must use an EEM subsystem number of 798 with any event type. If an existing policy is registered for subsystem 798 and a specified event type, a second policy of the same event type will trigger the first policy to run when the specified event is published.
CLI Event Detector
The CLI event detector screens command-line interface (CLI) commands for a regular expression match. When a match is found, an event is published. The match logic is performed on the fully expanded CLI command after the command is successfully parsed and before it is executed. The CLI event detector supports three publish modes:
•
Synchronous publishing of CLI events—The CLI command is not executed until the EEM policy exits, and the EEM policy can control whether the command is executed.
•
Asynchronous publishing of CLI events—The CLI event is published, and then the CLI command is executed.
•
Asynchronous publishing of CLI events with command skipping—The CLI event is published, but the CLI command is not executed.
Counter Event Detector
The counter event detector publishes an event when a named counter crosses a specified threshold. There are two or more participants that affect counter processing. The counter event detector can modify the counter, and one or more subscribers define the criteria that cause the event to be published. After a counter event has been published, the counter monitoring logic can be reset to start monitoring the counter immediately or it can be reset when a second threshold—called an exit value—is crossed.
Interface Counter Event Detector
The interface counter event detector publishes an event when a generic Cisco IOS interface counter for a specified interface crosses a defined threshold. A threshold can be specified as an absolute value or an incremental value. If the incremental value is set to 50, for example, an event would be published when the interface counter increases by 50.
After an interface counter event has been published, the interface counter monitoring logic is reset using two methods. The interface counter is reset either when a second threshold—called an exit value—is crossed or when an elapsed period of time occurs.
None Event Detector
The none event detector publishes an event when the Cisco IOS event manager run CLI command executes an EEM policy. EEM schedules and runs policies on the basis of an event specification that is contained within the policy itself. An EEM policy must be identified and registered to be permitted to be run manually before the event manager run command will execute
OIR Event Detector
The online insertion and removal (OIR) event detector publishes an event when one of the following hardware insertion or removal events occurs:
•
A card is removed.
•
A card is inserted.
•
The software on an inserted card becomes fully operational.
Route processors (RPs), line cards, or feature cards can be monitored for OIR events.
SNMP Event Detector
The SNMP event detector allows a standard SNMP MIB object to be monitored and an event to be generated when the object matches specified values or crosses specified thresholds.
Syslog Event Detector
The syslog event detector allows for screening syslog messages for a regular expression pattern match. The selected messages can be further qualified, requiring that a specific number of occurrences be logged within a specified time. A match on a specified event criteria triggers a configured policy action.
Timer Event Detector
The timer event detector publishes events for the following four different types of timers:
•
An absolute-time-of-day timer publishes an event when a specified absolute date and time occurs.
•
A countdown timer publishes an event when a timer counts down to zero.
•
A watchdog timer publishes an event when a timer counts down to zero and then the timer automatically resets itself to its initial value and starts to count down again.
•
A CRON timer publishes an event using a UNIX standard CRON specification to indicate when the event is to be published. A CRON timer never publishes events more than once per minute.
Watchdog System Monitor Event Detector
The Cisco IOS watchdog system monitor event detector publishes an event when one of the following occurs:
•
CPU utilization for a Cisco IOS process crosses a threshold.
•
Memory utilization for a Cisco IOS process crosses a threshold.
Two events may be monitored at the same time, and the event publishing criteria can be specified to require one event or both events to cross their specified thresholds.
Embedded Event Manager Actions
The CLI-based corrective actions that are taken when event detectors report events enable a powerful on-device event management mechanism. EEM 2.1 supports the following actions:
•
Executing a Cisco IOS command-line interface (CLI) command.
•
Generating a CNS event for upstream processing by Cisco CNS devices.
•
Setting or modifying a named counter.
•
Switching to a secondary processor in a fully redundant hardware configuration.
•
Requesting system information when an event occurs.
•
Sending a short e-mail.
•
Manually running an EEM policy.
•
Publishing an application-specific event.
•
Reloading the Cisco IOS software.
•
Generating an SNMP trap.
•
Generating prioritized syslog messages.
Embedded Event Manager Environment Variables
EEM allows environment variables to be used in EEM policies (applets and scripts). Tool Command Language (Tcl) permits global variables—called environment variables—to be defined for use within an EEM policy. There are three different types of environment variables associated with Embedded Event Manager:
•
User-defined—Defined by you if you create an environment variable in a policy that you have written.
•
Cisco-defined—Defined by Cisco for a specific sample policy.
•
Cisco built-in—Defined by Cisco and can be read only or read/write. The read only variables are set by the system before an applet starts to execute. The single read/write variable, _exit_status, allows you to set the exit status at policy exit for policies triggered from synchronous events.
Cisco-defined environment variables (see Table 1) may apply to one specific event detector or to all event detectors. Environment variables that are user-defined or defined by Cisco in a sample policy are set using the event manager environment command. Variables that are used in the EEM policy must be defined before you register the policy. A Tcl policy contains a section called "Environment Must Define" that can be defined to check that any required environment variables are defined before the policy runs.
Cisco built-in environment variables (see Table 2) are a subset of the Cisco-defined environment variables and the built-in variables are available to EEM applets only. The built-in variables can be read-only or can be read and write, and these variables may apply to one specific event detector or to all event detectors.
Note
Cisco-defined environment variables begin with an underscore character (_). We strongly recommend that customers avoid the same naming convention to prevent naming conflicts.
Table 1 describes the Cisco-defined variables used in the sample EEM policies. Some of the environment variables do not have to be specified for the corresponding sample policy to run and these are marked as optional.
Table 2 describes the Cisco built-in environment variables.
Embedded Event Manager Policies
EEM is a policy driven process in which the EEM policy engine receives notifications when faults and other events occur in the Cisco IOS software system. Embedded Event Manager policies implement recovery based on the current state of the system and the actions specified in the policy for a given event. Recovery actions are triggered when the policy is run.
Although there are some EEM CLI configuration and show commands, EEM is implemented through the creation of policies. An EEM policy is an entity that defines an event and the actions to be taken when that event occurs. There are two types of EEM policies: an applet or a script. An applet is a simple form of policy that is defined within the CLI configuration. A script is a form of policy that is written in Tcl.
The creation of an EEM policy involves:
•
Selecting the event for which the policy is run.
•
Defining the event detector options associated with logging and responding to the event.
•
Defining the environment variables, if required.
•
Choosing the actions to be performed when the event occurs.
There are two ways to create an EEM policy. The first method is to write applets using CLI commands, and the second method is to write Tcl scripts. Cisco provides enhancements to Tcl in the form of Tcl command extensions that facilitate the development of EEM policies. Scripts are defined off the networking device using an ASCII editor. The script is then copied to the networking device and registered with EEM. When a policy is registered with the Embedded Event Manager, the software examines the policy and registers it to be run when the specified event occurs. Policies can be unregistered or suspended. Both types of policies can be used to implement EEM in your network.
For details on writing EEM policies using the Cisco IOS CLI, see the "How to Configure Embedded Event Manager 2.1" section.
For details on writing EEM policies using Tcl and running the sample policies, see the "Writing Embedded Event Manager Policies Using Tcl" module.
How to Configure Embedded Event Manager 2.1
This section contains the following tasks:
•
Registering and Defining an Embedded Event Manager Applet
•
Registering and Defining an Embedded Event Manager Policy to Run Manually
•
Displaying Embedded Event Manager Registered Policies
•
Unregistering Embedded Event Manager Policies
•
Suspending Embedded Event Manager Policy Execution
•
Modifying History Table Size and Displaying EEM History Data
Registering and Defining an Embedded Event Manager Applet
Perform this task to register an applet with Embedded Event Manager and to define the EEM applet using the Cisco IOS CLI event and action commands. Only one event command is allowed in an EEM applet. Multiple action commands are permitted. If no event and no action commands are specified, the applet is removed when you exit configuration mode.
The SNMP event detector and the syslog action commands used in this task are just representing any event detector and action commands. For examples using other event detectors and action commands, see the "Embedded Event Manager Applet Configuration: Examples" section.
Note
For details about how to register and define an Embedded Event Manager Tcl script, see the "Writing Embedded Event Manager Policies Using Tcl" module.
EEM Environment Variables
EEM environment variables for EEM policies are defined using the EEM event manager environment configuration command. By convention, all Cisco EEM environment variables begin with "_". In order to avoid future conflict, customers are urged not to define new variables that start with "_".
You can display the EEM environment variables set on your system by using the show event manager environment privileged EXEC command.
For example, you can create EEM policies that can send e-mails when an event occurs. Table 3 describes the e-mail-specific environment variables that can be used in EEM policies.
SUMMARY STEPS
1.
enable
2.
show event manager environment [all | variable-name]
3.
configure terminal
4.
event manager environment variable-name string
5.
Repeat Step 4 for all the required environment variables.
6.
event manager applet applet-name
7.
event snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-time exit-time-value] poll-interval poll-int-value
8.
action label syslog [priority priority-level] msg msg-text
9.
Repeat Step 8.
10.
end
DETAILED STEPS
Command or Action PurposeStep 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Step 2
show event manager environment [all | variable-name]
Example:Router# show event manager environment all
(Optional) Displays the name and value of EEM environment variables.
•
The optional all keyword displays all the EEM environment variables.
•
The optional variable-name argument displays information about the specified environment variable.
Step 3
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 4
event manager environment variable-name string
Example:Router(config)# event manager environment _email_to engineering@yourdomain.com
Configures the value of the specified EEM environment variable.
•
In this example, the environment variable that holds the e-mail address to which e-mail is sent is set to engineering@yourdomain.com.
Step 5
Repeat Step 4 for all the required environment variables.
Repeat Step 4 to configure all the environment variables required by the policy to be registered in Step 6.
Step 6
event manager applet applet-name
Example:Router(config)# event manager applet memory-fail
Registers the applet with the Embedded Event Manager (EEM) and enters applet configuration mode.
Step 7
event snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-time exit-time-value] poll-interval poll-int-value
Example:Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10
Specifies the event criteria that cause the EEM applet to run.
•
In this example, an EEM event is triggered when free memory falls below the value of 5120000.
•
Exit criteria are optional, and if not specified, event monitoring is reenabled immediately.
Step 8
action label syslog [priority priority-level] msg msg-text
Example:Router(config-applet)# action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"
Specifies the action to be taken when an EEM applet is triggered.
•
In this example, the action to be taken is to write a message to syslog.
•
The optional priority keyword specifies the priority level of the syslog messages. If selected, the priority-level argument must be defined.
•
The msg-text argument can be character text, an environment variable, or a combination of the two.
Step 9
Repeat Step 8.
Example:Router(config-applet)# action 2.0 force-switchover
(Optional) Repeat Step 8 to add other action CLI commands to the applet.
Step 10
end
Example:Router(config-applet)# end
Exits applet configuration mode and returns to privileged EXEC mode.
Troubleshooting Tips
Use the debug event manager command in privileged EXEC mode to troubleshoot EEM command operations. Use any debugging command with caution as the volume of generated output can slow or stop the router operations. We recommend that this command be used only under the supervision of a Cisco engineer.
Registering and Defining an Embedded Event Manager Policy to Run Manually
There are two ways to manually run an EEM policy. EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event none command allows EEM to identify an EEM policy that can be manually triggered. To run the policy, use either the action policy command in applet configuration mode or the event manager run command in privileged EXEC mode.
Perform this task to register an EEM policy to be run manually using the event manager run command. For an example of how to manually run a policy using the action policy command, see the "Embedded Event Manager Manual Policy Execution: Examples" section.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
event manager applet applet-name
4.
event none
5.
action label syslog [priority priority-level] msg msg-text
6.
end
7.
event manager run policy-filename
DETAILED STEPS
Displaying Embedded Event Manager Registered Policies
Perform this optional task to display EEM registered policies.
SUMMARY STEPS
1.
enable
2.
show event manager policy registered [event-type event-name] [time-ordered | name-ordered]
DETAILED STEPS
Step 1
enable
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
show event manager policy registered [event-type event-name] [time-ordered | name-ordered]
Use this command with the time-ordered keyword to display information about currently registered policies sorted by time, for example:
Router# show event manager policy registered time-orderedNo. Type Event Type Time Registered Name1 applet snmp Thu May30 05:57:16 2004 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 10action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchover2 applet syslog Wed Jul16 00:05:17 2004 intf-downpattern {.*UPDOWN.*Ethernet1/0.*}action 1.0 cns-event msg Interface state change: $_syslog_msgUse this command with the name-ordered keyword to display information about currently registered policies sorted by name, for example:
Router# show event manager policy registered name-orderedNo. Type Event Type Time Registered Name1 applet syslog Wed Jul16 00:05:17 2004 intf-downpattern {.*UPDOWN.*Ethernet1/0.*}action 1.0 cns-event msg Interface state change: $_syslog_msg2 applet snmp Thu May30 05:57:16 2004 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 10action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchoverUse this command with the event-type keyword to display information about currently registered policies for the event type specified in the event-name argument, for example:
Router# show event manager policy registered event-type syslogNo. Type Event Type Time Registered Name1 applet syslog Wed Jul16 00:05:17 2004 intf-downpattern {.*UPDOWN.*Ethernet1/0.*}action 1.0 cns-event msg Interface state change: $_syslog_msg
Unregistering Embedded Event Manager Policies
Perform this task to remove an EEM policy from the running configuration file. Execution of the policy is canceled.
SUMMARY STEPS
1.
enable
2.
show event manager policy registered [event-type event-name] [system | user] [time-ordered | name-ordered]
3.
configure terminal
4.
no event manager policy policy-filename [type {system | user}] [trap]
5.
exit
6.
Repeat Step 2 to ensure that the policy is removed.
DETAILED STEPS
Command or Action PurposeStep 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Enter your password if prompted.
Step 2
show event manager policy registered [event-type event-name] [system | user] [time-ordered | name-ordered]
Example:Router# show event manager policy registered
(Optional) Displays the EEM policies that are currently registered.
•
The optional system or user keyword displays the registered system or user policies.
•
If no keywords are specified, EEM registered policies for all event types are displayed in time order.
Step 3
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 4
no event manager policy policy-filename [type {system | user}] [trap]
Example:Router(config)# no event manager policy pr_cdp_abort.tcl
Removes the EEM policy from the configuration, causing the policy to be unregistered.
•
In this example, the no form of the command is used to unregister a specified policy.
Step 5
exit
Example:Router(config)# exit
Exits global configuration mode and returns to privileged EXEC mode.
Step 6
Repeat Step 2 to ensure that the policy is removed.
Example:Router# show event manager policy registered
—
Examples
In the following example, the show event manager policy registered privileged EXEC command is used to display the two EEM applets that are currently registered:
Router# show event manager policy registeredNo. Class Type Event Type Trap Time Registered Name1 applet system snmp Off Fri Aug 12 17:42:52 2005 IPSLAping1oid {1.3.6.1.4.1.9.9.42.1.2.9.1.6.4} get-type exact entry-op eq entry-val {1}exit-op eq exit-val {2} poll-interval 5.000action 1.0 syslog priority critical msg "Server IPecho Failed: OID=$_snmp_oid_val"action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"action 1.2 publish-event sub-system 88000101 type 1 arg1 "10.1.88.9" arg2 "IPSLAEcho"arg3 "fail"action 1.3 counter name _IPSLA1F op inc value 12 applet system snmp Off Thu Sep 15 05:57:16 2005 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 10action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchoverIn the following example, the show event manager policy registered privileged EXEC command is used to show that applet IPSLAping1 has been removed after entering the no event manager policy command:
Router# show event manager policy registeredNo. Class Type Event Type Trap Time Registered Name1 applet system snmp Off Thu Sep 15 05:57:16 2005 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 10action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchoverSuspending Embedded Event Manager Policy Execution
Perform this task to immediately suspend the execution of all EEM policies. Suspending instead of unregistering policies might be necessary for reasons of temporary performance or security.
SUMMARY STEPS
1.
enable
2.
show event manager policy registered [event-type event-name] [system | user] [time-ordered | name-ordered]
3.
configure terminal
4.
event manager scheduler suspend
5.
exit
DETAILED STEPS
Examples
In the following example, the show event manager policy registered privileged EXEC command is used to display all the EEM registered policies:
Router# show event manager policy registeredNo. Type Event Type Trap Time Registered Name1 system timer cron Off Sat Oct11 01:43:18 2003 tm_cli_cmd.tclname {crontimer2} cron entry {0-59/1 0-23/1 * * 0-7}nice 0 priority normal maxrun 240.02 system syslog Off Sat Oct11 01:43:28 2003 sl_intf_down.tcloccurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}nice 0 priority normal maxrun 90.0Modifying History Table Size and Displaying EEM History Data
Perform this optional task to change the size of the history tables and to display EEM history data.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
event manager history size {events | traps} [size]
4.
exit
5.
show event manager history events [detailed] [maximum number]
6.
show event manager history traps {server | policy}
DETAILED STEPS
Step 1
enable
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
configure terminal
Enters global configuration mode.
Router# configure terminalStep 3
event manager history size {events | traps} [size]
Use this command to change the size of the EEM event history table or the size of the EEM SNMP trap history table. In the following example, the size of the EEM event history table is changed to 30 entries:
Router(config)# event manager history size events 30Step 4
exit
Exits global configuration mode and returns to privileged EXEC mode.
Router(config)# exitStep 5
show event manager history events [detailed] [maximum number]
Use this command to display detailed information about each EEM event, for example:
Router# show event manager history eventsNo. Time of Event Event Type Name1 Fri Aug13 21:42:57 2004 snmp applet: SAAping12 Fri Aug13 22:20:29 2004 snmp applet: SAAping13 Wed Aug18 21:54:48 2004 snmp applet: SAAping14 Wed Aug18 22:06:38 2004 snmp applet: SAAping15 Wed Aug18 22:30:58 2004 snmp applet: SAAping16 Wed Aug18 22:34:58 2004 snmp applet: SAAping17 Wed Aug18 22:51:18 2004 snmp applet: SAAping18 Wed Aug18 22:51:18 2004 application applet: CustApp1Step 6
show event manager history traps {server | policy}
Use this command to display the EEM SNMP traps that have been sent either from the EEM server or from an EEM policy. In the following example, the EEM SNMP traps that were triggered from within an EEM policy are displayed.
Router# show event manager history traps policyNo. Time Trap Type Name1 Wed Aug18 22:30:58 2004 policy EEM Policy Director2 Wed Aug18 22:34:58 2004 policy EEM Policy Director3 Wed Aug18 22:51:18 2004 policy EEM Policy Director
Configuration Examples for Embedded Event Manager 2.1
This section contains the following configuration examples:
•
Embedded Event Manager Applet Configuration: Examples
•
Embedded Event Manager Manual Policy Execution: Examples
•
Embedded Event Manager Watchdog System Monitor Event Detector Configuration: Example
Embedded Event Manager Applet Configuration: Examples
The following examples show how to create an EEM applet for some of the EEM event detectors. These examples follow steps outlined in the "Registering and Defining an Embedded Event Manager Applet" section.
Application-Specific Event Detector
The following example shows how a policy named EventPublish_A runs every 20 seconds and publishes an event type numbered 1 to an EEM subsystem numbered 798. The subsystem value of 798 specifies that a publish event has occurred from an EEM policy. A second policy named EventPublish_B is registered to run when the EEM event type 1 occurs with subsystem 798. When the EventPublish_B policy runs, it sends a message to syslog containing data passed as an argument from the EventPublish_A policy.
event manager applet EventPublish_Aevent timer watchdog time 20.0action 1.0 syslog msg "Applet EventPublish_A"action 2.0 publish-event sub-system 798 type 1 arg1 twentyexitevent manager applet EventPublish_Bevent application sub-system 798 type 1action 1.0 syslog msg "Applet EventPublish_B arg1 $_application_data1"CLI Event Detector
The following example shows how to specify an EEM applet to run when the Cisco IOS write memory CLI command is run. The applet provides a notification that this event has occurred via a syslog message. In the example, the sync keyword is configured with the yes argument, and this means that the event detector is notified when this policy completes running. The exit status of the policy determines whether the CLI command will be executed. In this example, the policy exit status is set to one and the CLI command runs.
event manager applet cli-matchevent cli pattern "write mem.*" sync yesaction 1.0 syslog msg "$_cli_msg Command Executed"set 2.0 _exit_status 1Counter Event Detector and Timer Event Detector
The following example shows that the EventCounter_A policy is configured to run once a minute and to increment a well-known counter called critical_errors. A second policy—EventCounter_B—is registered to be triggered when the well-known counter called critical_errors exceeds a threshold of 3. When the EventCounter_B policy runs, it resets the counter to 0.
event manager applet EventCounter_Aevent timer watchdog time 60.0action 1.0 syslog msg "EventCounter_A"action 2.0 counter name critical_errors op inc value 1exitevent manager applet EventCounter_Bevent counter name critical_errors entry-op gt entry-val 3 exit-op lt exit-val 3action 1.0 syslog msg "EventCounter_B"action 2.0 counter name critical_errors op set value 0Interface Counter Event Detector
The following example shows how a policy named EventInterface is triggered every time the receive_throttle counter for Fast Ethernet interface 0/0 is incremented by 5. The polling interval to check the counter is specified to run once every 10 seconds.
event manager applet EventInterfaceevent interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5entry-val-is-increment true poll-interval 10action 1.0 syslog msg "Applet EventInterface"Syslog Event Detector
The following example shows how to specify an EEM applet to run when syslog identifies that Ethernet interface 1/0 is down. The applet sends a message about the interface to syslog.
event manager applet interface-downevent syslog pattern ".*UPDOWN.*Ethernet1/0.*" occurs 4action 1.0 syslog msg "Ethernet interface 1/0 changed state 4 times"SNMP Event Detector
The following example shows how to configure an EEM applet that causes a switch to the secondary (redundant) Route Processor (RP) when the primary RP runs low on memory.
This example illustrates a method for taking preventative action against a software fault that causes a memory leak. The action taken here is designed to reduce downtime by switching over to a redundant RP when a possible memory leak is detected.
Figure 2 Dual RP Topology
The commands used to register the policy are shown below.
event manager applet memory-demoevent snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchoverThe registered applet is displayed using the show event manager policy registered command:
Router# show event manager policy registeredNo. Type Event Type Time Registered Name1 applet snmp Thu Jan30 05:57:16 2003 memory-demooid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 10action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchoverFor the purpose of this example, a memory depletion is forced on the router, and a series of show memory commands are executed to watch the memory deplete:
Router# show memoryHead Total(b) Used(b) Free(b) Lowest(b) Largest(b)Processor 53585260 212348444 119523060 92825384 92825384 92365916Fast 53565260 131080 70360 60720 60720 60668Router# show memoryHead Total(b) Used(b) Free(b) Lowest(b) Largest(b)Processor 53585260 212364664 164509492 47855172 47855172 47169340Fast 53565260 131080 70360 60720 60720 60668Router# show memoryHead Total(b) Used(b) Free(b) Lowest(b) Largest(b)Processor 53585260 212369492 179488300 32881192 32881192 32127556Fast 53565260 131080 70360 60720 60720 60668When the threshold is reached, an EEM event is triggered. The applet named memory-demo runs, causing a syslog message to be written to the console and a switch to be made to the secondary RP. The following messages are logged:
00:08:31: %HA_EM-2-LOG: memory-demo: Memory exhausted; current available memory is 4484196 bytes00:08:31: %HA_EM-6-FMS_SWITCH_HARDWARE: fh_io_msg: Policy has requested a hardware switchoverConfiguration for the Primary RP and Secondary RP
The following is partial output from the show running-config command on both the primary RP and the secondary (redundant) RP:
redundancymode sso...!event manager applet memory-demoevent snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchoverEmbedded Event Manager Manual Policy Execution: Examples
The following examples show how to use the none event detector to configure an EEM policy (applet or script) to be run manually.
Using the event manager run Command
This example shows how to run a policy manually using the event manager run command. The policy is registered using the event none command under applet configuration mode and then run from global configuration mode using the event manager run command.
event manager applet manual-policyevent noneaction 1.0 syslog msg "Manual-policy triggered"end!event manager run manual-policyUsing the action policy Command
This example shows how to run a policy manually using the action policy command. The policy is registered using the event none command under applet configuration mode, and then the policy is executed using the action policy command in applet configuration mode.
event manager applet manual-policyevent noneaction 1.0 syslog msg "Manual-policy triggered"exit!event manager applet manual-policy-twoevent noneaction 1.0 policy manual-policyend!event manager run manual-policy-twoEmbedded Event Manager Watchdog System Monitor Event Detector Configuration: Example
The following example shows how to configure three EEM applets to demonstrate how the watchdog system monitor event detector works.
Watchdog System Monitor Sample1 Policy
The first policy triggers an applet when the average CPU usage for the process named "IP Input" is greater than or equal to 1 percent for 10 seconds:
event manager applet IOSWD_Sample1event ioswdsysmon sub1 cpu-proc taskname "IP Input" op ge val 1 period 10action 1.0 syslog msg "IOSWD_Sample1 Policy Triggered"Watchdog System Monitor Sample2 Policy
The second policy triggers an applet when the total amount of memory used by the process named "Net Input" is greater than 100 Kb:
event manager applet IOSWD_Sample2event ioswdsysmon sub1 mem-proc taskname "Net Input" op gt val 100 is-percent falseaction 1.0 syslog msg "IOSWD_Sample2 Policy Triggered"Watchdog System Monitor Sample3 Policy
The third policy triggers an applet when the total amount of memory used by the process named "IP RIB Update" has increased by more than 50 percent over the sample period of 60 seconds:
event manager applet IOSWD_Sample3event ioswdsysmon sub1 mem-proc taskname "IP RIB Update" op gt val 50 is-percent true period 60action 1.0 syslog msg "IOSWD_Sample3 Policy Triggered"The three policies are configured, and then repetitive large pings are made to the networking device from several workstations, causing the networking device to register some usage. This will trigger policies 1 and 2, and the console will display the following messages:
00:42:23: %HA_EM-6-LOG: IOSWD_Sample1: IOSWD_Sample1 Policy Triggered00:42:47: %HA_EM-6-LOG: IOSWD_Sample2: IOSWD_Sample2 Policy TriggeredTo view the policies that are registered, use the show event manager policy registered command:
Router# show event manager policy registeredNo. Class Type Event Type Trap Time Registered Name1 applet system ioswdsysmon Off Fri Jul 23 02:27:28 2004 IOSWD_Sample1sub1 cpu_util {taskname {IP Input} op ge val 1 period 10.000 }action 1.0 syslog msg IOSWD_Sample1 Policy Triggered2 applet system ioswdsysmon Off Fri Jul 23 02:23:52 2004 IOSWD_Sample2sub1 mem_used {taskname {Net Input} op gt val 100 is_percent FALSE}action 1.0 syslog msg IOSWD_Sample2 Policy Triggered3 applet system ioswdsysmon Off Fri Jul 23 03:07:38 2004 IOSWD_Sample3sub1 mem_used {taskname {IP RIB Update} op gt val 50 is_percent TRUE period 60.000 }action 1.0 syslog msg "IOSWD_Sample3 Policy Triggered"Where to Go Next
For more details about other network management technologies, see the Cisco IOS Configuration Fundamentals and Network Management Configuration Guide, Release 12.3.
Additional References
The following sections provide references related to Embedded Event Manager 2.1.
Related Documents
Related Topic Document TitleEEM commands: complete command syntax, defaults, command mode, command history, usage guidelines, and examples
Cisco IOS Configuration Fundamentals and Network Management Command Reference, Release 12.3T
Embedded Event Manager policy writing using Tcl
CNS event agent
CNS Event Agent feature document, Release 12.2(2)T
CNS Configuration Engine
Cisco CNS Configuration Registrar: Installing and Configuring the IE2100
Standards
Standard TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
MIB MIBs LinkCISCO-EMBEDDED-EVENT-MGR-MIB
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
RFC TitleNo new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Command Reference
This section documents new and modified commands only.
•
event manager scheduler suspend
•
event manager scheduler script
•
event manager session cli username
•
show event manager directory user
•
show event manager environment
•
show event manager history events
•
show event manager history traps
•
show event manager policy available
•
show event manager policy pending
•
show event manager policy registered
•
show event manager session cli username
action cli
To specify the action of executing a Cisco IOS command-line interface (CLI) command when an Embedded Event Manager (EEM) applet is triggered, use the action cli command in applet configuration mode. To remove the action of executing a CLI command, use the no form of this command.
action label cli command cli-string
no action label cli command cli-string
Syntax Description
Command Default
No CLI commands are executed when an EEM applet is triggered.
Command Modes
Applet configuration
Command History
Examples
The following example shows how to specify an EEM applet to run when the Cisco IOS interface loopback CLI command is configured three times. The applet executes the no shutdown command to ensure that the loopback interfaces are operational.
Router(config)# event manager applet cli-matchRouter(config-applet)# event cli pattern {.*interface loopback*} sync yes occurs 3Router(config-applet)# action 1.0 cli command "no shutdown"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
action cns-event
To specify the action of sending a message to the CNS Event Bus when an Embedded Event Manager (EEM) applet is triggered, use the action cns-event command in applet configuration mode. To remove the action of sending a message to the CNS Event Bus, use the no form of this command.
action label cns-event msg msg-text
no action label cns-event msg msg-text
Syntax Description
Command Default
No messages are sent to the CNS Event Bus.
Command Modes
Applet configuration
Command History
Examples
The following example shows how to specify a message to be sent to the CNS Event Bus when the memory-fail applet is triggered:
Router(config)# event manager applet memory-failRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10Router(config-applet)# action 1.0 cns-event msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
action counter
To specify the action of setting or modifying a named counter when an Embedded Event Manager (EEM) applet is triggered, use the action counter command in applet configuration mode. To restore the default value to the counter, use the no form of this command.
action label counter name counter-name value counter-value op {dec | inc | nop | set}
no action label counter name counter-name value counter-value op {dec | inc | nop | set}
Syntax Description
Command Default
No counter values are set or modified.
Command Modes
Applet configuration
Command History
Usage Guidelines
Use the action counter command when an event occurs periodically and you want an action to be implemented after a specified number of occurrences of that event. When the action counter command completes, the $_counter_value_remain environment variable is updated.
Use the event counter command with the action counter command when an event occurs periodically and you want an action to be implemented after a specified number of occurrences of the event.
Examples
The following example shows an EEM applet called IPSLAping1 being registered to run when there is an exact match on the value of a specified SNMP object ID that represents a successful IP SLA ICMP echo operation (this is equivalent to a ping command). Four actions are triggered when the echo operation fails, and event monitoring is disabled until after the second failure. A message saying that the ICMP echo operation to a server failed is sent to syslog, an SNMP trap is generated, EEM publishes an application-specific event, and a counter called IPSLA1F is incremented by a value of one.
Router(config)# event manager applet IPSLAping1Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.4 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5Router(config-applet)# action 1.0 syslog priority critical msg "Server IP echo failed: OID=$_snmp_oid_val"Router(config-applet)# action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"Router(config-applet)# action 1.2 publish-event sub-system 88000101 type 1 arg1 10.1.88.9 arg2 IPSLAEcho arg3 failRouter(config-applet)# action 1.3 counter name _IPSLA1F value 1 op incThe following example shows a policy—EventCounter_A—that is configured to run once a minute and to increment a well-known counter called critical_errors. A second policy—EventCounter_B—is registered to be triggered when the well-known counter called critical_errors exceeds a threshold of 3. When policy EventCounter_B runs, it resets the counter back to 0.
Router(config)# event manager applet EventCounter_ARouter(config-applet)# event timer watchdog time 60.0Router(config-applet)# action 1.0 syslog msg "EventCounter_A"Router(config-applet)# action 2.0 counter name critical_errors value 1 op incRouter(config-applet)# exitRouter(config)# event manager applet EventCounter_BRouter(config-applet)# event counter name critical_errors entry-op gt entry-val 3 exit-op lt exit-val 3Router(config-applet)# action 1.0 syslog msg "EventCounter_B"Router(config-applet)# action 2.0 counter name critical_errors value 0 op setRelated Commands
action force-switchover
To specify the action of switching to a secondary processor in a fully redundant environment when an Embedded Event Manager (EEM) applet is triggered, use the action force-switchover command in applet configuration mode. To remove the action of switching to a secondary processor, use the no form of this command.
action label force-switchover
no action label force-switchover
Syntax Description
Command Default
A switch to a secondary processor is not made.
Command Modes
Applet configuration
Command History
Usage Guidelines
Before using the action force-switchover command, you must install a backup processor in the device. If the hardware is not fully redundant, the switchover action will not be performed.
Examples
The following example shows how to specify a switch to the secondary Route Processor (RP) when the memory-fail applet is triggered:
Router(config)# event manager applet memory-failRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10Router(config-applet)# action 2.0 force-switchoverRelated Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
action info
To specify the action of obtaining system information when an Embedded Event Manager (EEM) applet is triggered, use the action info command in applet configuration mode. To remove the action info command from the configuration, use the no form of this command.
action label info type {cli frequency | cli history | syslog frequency | syslog history | router-name | snmp oid oid-value get-type {exact | next}}
no action label info type {cli frequency | cli history | syslog frequency | syslog history | router-name | snmp oid oid-value get-type {exact | next}}
Syntax Description
Command Default
No system information is requested.
Command Modes
Applet configuration
Command History
Usage Guidelines
Use the action info command when an event occurs and you want to request some system information.
When the snmp oid keyword is used, an error message is returned when the OID is not one of the defined types.
Examples
The following example shows how to specify an EEM applet to run when the Cisco IOS interface loopback CLI command is configured three times. The applet runs the no shutdown command to ensure that the loopback interfaces are operational, and a request to obtain information about the frequency of recent CLI commands is sent to the EEM.
Router(config)# event manager applet cli-matchRouter(config-applet)# event cli pattern {.*interface loopback*} sync yes occurs 3Router(config-applet)# action 1.0 cli command "no shutdown"Router(config-applet)# action 1.1 info type cli frequencyRelated Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
action mail
To specify the action of sending a short e-mail when an Embedded Event Manager (EEM) applet is triggered, use the action mail command in applet configuration mode. To remove the action mail command from the configuration, use the no form of this command.
action label mail server server-address to to-address from from-address [cc cc-address] subject subject body body-text
no action label mail server server-address to to-address from from-address [cc cc-address] subject subject body body-text
Syntax Description
Command Default
No e-mails are sent.
Command Modes
Applet configuration
Command History
Usage Guidelines
Use the action mail command when an event occurs about which you want to send an e-mail message, such as informing an administrator about the event.
Examples
The following example shows how to send an e-mail when an EEM applet executes. The applet named EventInterface is triggered every time the receive_throttle counter for the Fast Ethernet interface 0/0 is incremented by 5. The polling interval to check the counter is specified to run once every 10 seconds. When the applet is triggered, a syslog message and an e-mail are sent.
Router(config)# event manager applet EventInterfaceRouter(config-applet)# event interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5 entry-val-is-increment true poll-interval 10Router(config-applet)# action 1.0 syslog msg "Applet EventInterface"Router(config-applet)# action 1.1 mail server mailserver.cisco.com to engineering@cisco.com from devtest@cisco.com cc manager@cisco.com subject "Receive_throttle counter incremented" body "Receive_throttle counter for FastEthernet0/0 interface has incremented by 5"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
action policy
To specify the action of manually running an Embedded Event Manager (EEM) policy when an EEM applet is triggered, use the action policy command in applet configuration mode. To remove the action policy command from the configuration, use the no form of this command.
action label policy policy-filename
no action label policy policy-filename
Syntax Description
Command Default
No EEM policies are run.
Command Modes
Applet configuration
Command History
Usage Guidelines
EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event none command allows EEM to identify an EEM policy that can be run manually or when an EEM applet is triggered. To run the policy, use either the action policy command in applet configuration mode or the event manager run command in global configuration mode.
Examples
The following example shows how to register a policy named policy-manual to be run manually and then to execute the policy:
Router(config)# event manager applet policy-manualRouter(config-applet)# event none policy-manualRouter(config-applet)# action label1 policy policy-manualRelated Commands
action publish-event
To specify the action of publishing an application-specific event when the event specified for an Embedded Event Manager (EEM) applet is triggered, use the action publish-event command in applet configuration mode. To remove the action of publishing an application-specific event, use the no form of this command.
action label publish-event sub-system sub-system-id type event-type arg1 argument-data
[arg2 argument-data] [arg3 argument-data] [arg4 argument-data]no action label publish-event
Syntax Description
Command Default
No application-specific events are published.
Command Modes
Applet configuration
Command History
Examples
The following example shows how a policy named EventPublish_A runs every 20 seconds and publishes an event to a well-known EEM event type numbered 1. A second policy named EventPublish_B is registered to run when the well-known EEM event type of 1 occurs. When policy EventPublish_B runs, it outputs a message to syslog containing the argument 1 argument data passed from EventPublish_A.
Router(config)# event manager applet EventPublish_ARouter(config-applet)# event timer watchdog time 20.0Router(config-applet)# action 1.0 syslog msg "Applet EventPublish_A"Router(config-applet)# action 2.0 publish-event sub-system 798 type 1 arg1 twentyRouter(config-applet)# exitRouter(config)# event manager applet EventPublish_BRouter(config-applet)# event application sub-system 798 type 1Router(config-applet)# action 1.0 syslog msg "Applet EventPublish_B arg1 $_application_data1"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
action reload
To specify the action of reloading the Cisco IOS software when an Embedded Event Manager (EEM) applet is triggered, use the action reload command in applet configuration mode. To remove the action of reloading the Cisco IOS software, use the no form of this command.
action label reload
no action label reload
Syntax Description
Command Default
No reload of the Cisco IOS software is performed.
Command Modes
Applet configuration
Command History
Usage Guidelines
Before configuring the action reload command, you should ensure that the device is configured to reboot the software version that you are expecting. Use the show startup-config command and look for any boot system commands.
Examples
The following example shows how to reload the Cisco IOS software when the memory-fail applet is triggered:
Router(config)# event manager applet memory-failRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10Router(config-applet)# action 3.0 reloadRelated Commands
action snmp-trap
To specify the action of generating a Simple Network Management Protocol (SNMP) trap when an Embedded Event Manager (EEM) applet is triggered, use the action snmp-trap command in applet configuration mode. To remove the action of generating an SNMP trap, use the no form of this command.
action label snmp-trap [intdata1 integer] [intdata2 integer] [strdata string]
no action label snmp-trap [intdata1 integer] [intdata2 integer] [strdata string]
Syntax Description
Command Default
No SNMP traps are generated when an EEM applet is triggered.
Command Modes
Applet configuration
Command History
Usage Guidelines
Before configuring this command, you must enable the snmp-server enable traps event-manager command to permit SNMP traps to be sent from the Cisco IOS device to the SNMP server. Other relevant snmp-server commands must also be configured.
This command generates an asynchronous message that is sent from the Cisco IOS device to the SNMP agent. The SNMP agent can be coded to understand customized data such as the optional integer and string data that can be sent in the SNMP trap message.
The SNMP trap that is generated uses the EEM MIB, CISCO-EMBEDDED-EVENT-MGR-MIB.my. Details about the MIB can be found using Cisco MIB Locator found at the following URL:
Examples
The following example shows an EEM applet called IPSLAping1 being registered to run when there is an exact match on the value of a specified SNMP object ID that represents a successful IP SLA ICMP echo operation (this is equivalent to a ping command). Four actions are triggered when the echo operation fails, and event monitoring is disabled until after the second failure. A message saying that the ICMP echo operation to a server failed is sent to syslog, an SNMP trap is generated, EEM publishes an application-specific event, and a counter called IPSLA1F is incremented by a value of one.
Router(config)# event manager applet IPSLAping1Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.4 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5Router(config-applet)# action 1.0 syslog priority critical msg "Server IP echo failed: OID=$_snmp_oid_val"Router(config-applet)# action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"Router(config-applet)# action 1.2 publish-event sub-system 88000101 type 1 arg1 10.1.88.9 arg2 IPSLAEcho arg3 failRouter(config-applet)# action 1.3 counter name _IPSLA1F value 1 op incRelated Commands
action syslog
To specify the action of writing a message to syslog when an Embedded Event Manager (EEM) applet is triggered, use the action syslog command in applet configuration mode. To remove the syslog message event criteria, use the no form of this command.
action label syslog [priority priority-level] msg msg-text
no action label syslog [priority priority-level] msg msg-text
Syntax Description
Command Default
No messages are written to syslog.
Command Modes
Applet configuration
Command History
Examples
The following example shows how to specify a message to be sent to syslog when the memory-fail applet is triggered:
Router(config)# event manager applet memory-failRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10Router(config-applet)# action 4.0 syslog msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
debug event manager
To turn on the debugging output of Embedded Event Manager (EEM) processes, use the debug event manager command in privileged EXEC mode. To turn off debugging output, use the no form of this command or the undebug command.
debug event manager {action cli | action cns | action mail | all | api calls | api errors | detector all | detector application | detector cli | detector counter | detector interface | detector ioswdsysmon | detector none | detector snmp | detector syslog | detector timer | metricdir | policydir | server events | server scheduling | tcl cli_library | tcl commands | tcl smtp_library}
no debug event manager {action cli | action cns | action mail | all | api calls | api errors | detector all | detector application | detector cli | detector counter | detector interface | detector ioswdsysmon | detector none | detector snmp | detector syslog | detector timer | metricdir | policydir | server events | server scheduling | tcl cli_library | tcl commands | tcl smtp_library}
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug event manager command to troubleshoot EEM command operations.
CautionUse any debugging command with caution because the volume of generated output can slow or stop the router operations. We recommend that this command be used only under the supervision of a Cisco engineer.
Examples
The following example turns on debugging messages about EEM server events and then configures an applet to write a message—Test message—to syslog. The debug output that follows displays the various EEM operations that occur as the applet is processed.
Router# debug event manager server eventsDebug Embedded Event Manager server events debugging is onRouter# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# event manager applet timer-testRouter(config-applet)# event timer countdown time 20Router(config-applet)# action label1 syslog msg "Test message"Router(config-applet)# endRouter#03:46:55: fh_server: fh_io_msg: received msg 6 from client jobid 1103:46:55: fh_server: fh_io_msg: handling event register with esid = 2303:46:55: fh_msg_send_to_fd: receive a reply msg, minor: 503:46:55: fh_server: fh_io_msg: received msg 26 from client jobid 1103:46:55: fh_msg_send_to_fd: receive a reply msg, minor: 503:46:55: %SYS-5-CONFIG_I: Configured from console by console03:47:15: fd_pulse_hndlr: received a pulse from /dev/fm/fd_timer03:47:15: fh_msg_send_to_fd: receive a reply msg, minor: 503:47:15: fd_pulse_hndlr: received FH_MSG_EVENT_PUBLISH03:47:15: fh_schedule_callback: fh_schedule_callback: cc=632C0B68 prev_epc=0; epc=63A4167003:47:15: fh_io_msg: received FH_MSG_API_INIT; jobid=13, processid=82, client=3, job name=EEM Callback Thread03:47:15: fh_server: fh_io_msg: received msg 10 from client jobid 1303:47:15: %HA_EM-6-LOG: timer-test: Test message03:47:15: fh_server: fh_io_msg: received msg 62 from client jobid 1303:47:15: fh_schedule_callback: fh_schedule_callback: cc=632C0B68 prev_epc=63A41670; epc=003:47:15: fh_server: fh_io_msg: received msg 1 from client jobid 1303:47:15: fh_io_msg: received FH_MSG_API_CLOSE client=3
Table 4 describes some of the significant fields shown in the display.
event application
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of an event raised through the EEM Event Publish application programming interface (API), use the event application command in applet configuration mode. To remove the application event criteria, use the no form of this command.
event application subsystem subsystem-id type event-type
no event application subsystem subsystem-id type event-type
Syntax Description
Command Default
No EEM event criteria are specified.
Command Modes
Applet configuration
Command History
Usage Guidelines
An EEM event is triggered when an application calls the EEM Event Publish API with an event specification that matches the subsystem ID and application event type.
When an event is published by an EEM policy, the subsystem-id reserved for the policy is 798.
Examples
The following example shows how a policy named EventPublish_A runs every 20 seconds and publishes an event to a well-known EEM event type numbered 1. A second policy named EventPublish_B is registered to run when the well-known EEM event type of 1 occurs. When policy EventPublish_B runs, it outputs a message to syslog containing data passed as an argument from EventPublish_A.
Router(config)# event manager applet EventPublish_ARouter(config-applet)# event timer watchdog time 20.0Router(config-applet)# action 1.0 syslog msg "Applet EventPublish_A"Router(config-applet)# action 2.0 publish-event sub-system 798 type 1 arg1 twentyRouter(config-applet)# exitRouter(config)# event manager applet EventPublish_BRouter(config-applet)# event application subsystem 798 type 1Router(config-applet)# action 1.0 syslog msg "Applet EventPublish_B arg1 $_application_data1"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event cli
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run by matching a Cisco IOS command-line interface (CLI) command, use the event cli command in applet configuration mode. To remove the CLI command event criteria, use the no form of this command.
event cli pattern regular-expression sync {yes | no {skip {yes | no}}} [occurs num-occurrences] [period period-value]
no event cli pattern regular-expression sync {yes | no {skip {yes | no}}} [occurs num-occurrences] [period period-value]
Syntax Description
Command Default
No EEM events are triggered on the basis of a match with a Cisco IOS CLI command.
Command Modes
Applet configuration
Command History
Usage Guidelines
Use the event cli command to set up event criteria against which CLI commands are matched. CLI commands are compared against a specified regular expression. After a specified number of matches occurs within a specified time period, an EEM event is triggered. If multiple conditions exist, the EEM event is triggered when all the conditions are met.
When the sync keyword is used, the event detector is notified when the policy completes running. The exit status of the policy determines whether the CLI command will be executed. If the policy exit status is zero—the policy ran successfully—the CLI command is not executed; otherwise the CLI command runs.
Examples
The following example shows how to specify an EEM applet to run when the Cisco IOS write memory CLI command is run. The applet provides a notification via a syslog message this event has occurred.
Router(config)# event manager applet cli-matchRouter(config-applet)# event cli pattern "write mem.*" sync yesRouter(config-applet)# action 1.0 syslog msg "$_cli_msg Command Executed"Router(config-applet)# set 2.0 _exit_status 1Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event counter
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of a named counter crossing a threshold, use the event counter command in applet configuration mode. To remove the counter event criteria, use the no form of this command.
event counter name counter-name entry-op operator entry-val entry-value [exit-op operator] [exit-val exit-value]
no event counter name counter-name entry-op operator entry-val entry-value [exit-op operator] [exit-val exit-value]
Syntax Description
Command Default
No EEM events are triggered on the basis of a named counter crossing a threshold.
Command Modes
Applet configuration
Command History
Usage Guidelines
An EEM event is triggered when the value of a specified counter crosses a defined threshold. Depending on the operator, the threshold may be crossed when the value is greater than the threshold or when the value is less than the threshold.
Use the event counter command with the action counter command when an event occurs periodically and you want an action to be implemented after a specified number of occurrences of the event.
Exit criteria are optional. If exit criteria are not specified, event monitoring will be reenabled immediately. If exit criteria are specified, event monitoring is not reenabled until the criteria are met.
Examples
The following example shows that policy EventCounter_A is configured to run once a minute and to increment a well-known counter called critical_errors. A second policy—EventCounter_B—is registered to be triggered when the well-known counter called critical_errors exceeds a threshold of 3. When policy EventCounter_B runs, it resets the counter to 0.
Router(config)# event manager applet EventCounter_ARouter(config-applet)# event timer watchdog time 60.0Router(config-applet)# action 1.0 syslog msg "EventCounter_A"Router(config-applet)# action 2.0 counter name critical_errors value 1 op incRouter(config-applet)# exitRouter(config)# event manager applet EventCounter_BRouter(config-applet)# event counter name critical_errors entry-op gt entry-val 3 exit-op lt exit-val 3Router(config-applet)# action 1.0 syslog msg "EventCounter_B"Router(config-applet)# action 2.0 counter name critical_errors value 0 op setRelated Commands
event interface
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of a generic interface counter crossing a threshold or reaching exit criteria, use the event interface command in applet configuration mode. To remove the interface event criteria, use the no form of this command.
event interface name interface-type interface-number parameter counter-name entry-op operator entry-val entry-value entry-val-is-increment {true | false} [exit-comb {or | and}] [exit-op operator exit-val exit-value] [exit-val-is-increment {true | false}] [exit-time exit-time-value] poll-interval poll-int-value
no event interface name interface-type interface-number parameter counter-name entry-op operator entry-val entry-value entry-val-is-increment {true | false} [exit-comb {or | and}] [exit-op operator exit-val exit-value] [exit-val-is-increment {true | false}] [exit-time exit-time-value] poll-interval poll-int-value
Syntax Description
Command Default
No EEM events are triggered on the basis of a generic interface counter crossing a threshold or reaching exit criteria.
Command Modes
Applet configuration
Command History
Usage Guidelines
An EEM event is triggered when one of the fields specified by an interface counter crosses a defined threshold.
Exit criteria are optional. If exit criteria are not specified, event monitoring will be reenabled immediately. If exit criteria are specified—on the basis of values or time periods—event monitoring is not reenabled until the criteria are met.
Supported values for the counter-name argument are the following:
•
input_errors—Includes runts, giants, no buffer, cyclic redundancy checksum (CRC), frame, overrun, and ignored counts. Other input-related errors can also cause the input errors count to be increased. Some datagrams may have more than one error.
•
input_errors_crc—Number of packets with a CRC generated by the originating LAN station or remote device that do not match the checksum calculated from the data received.
•
input_errors_frame—Number of packets received incorrectly that have a CRC error and a noninteger number of octets.
•
input_errors_overrun—Number of times the receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver's ability to handle the data.
•
input_packets_dropped—Number of packets dropped because of a full input queue.
•
interface_resets—Number of times an interface has been completely reset.
•
output_buffer_failures—Number of failed buffers and number of buffers swapped out.
•
output_buffer_swappedout—Number of packets swapped to DRAM.
•
output_errors—Sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this may not balance with the sum of the output errors because some datagrams may have more than one error and other datagrams may have errors that do not fall into any of the specifically tabulated categories.
•
output_errors_underrun—Number of times that the transmitter has been running faster than the router can handle.
•
output_packets_dropped—Number of packets dropped because of a full output queue.
•
receive_broadcasts—Number of broadcast or multicast packets received by the interface.
•
receive_giants—Number of packets that are discarded because they exceed the maximum packet size of the medium.
•
receive_rate_bps—Interface receive rate, in bytes per second.
•
receive_rate_pps—Interface receive rate, in packets per second.
•
receive_runts—Number of packets that are discarded because they are smaller than the minimum packet size of the medium.
•
receive_throttle—Number of times the receiver on the port was disabled, possibly because of buffer or processor overload.
•
reliability—Reliability of the interface, as a fraction of 255 (255 out of 255 is 100 percent reliability), calculated as an exponential average over 5 minutes.
•
rxload—Receive rate of the interface, as a fraction of 255 (255 out of 255 is 100 percent).
•
transmit_rate_bps—Interface transmit rate, in bytes per second.
•
transmit_rate_pps—Interface transmit rate, in packets per second.
•
txload—Transmit rate of the interface, as a fraction of 255 (255 out of 255 is 100 percent).
When you use the entry-op keyword or the optional exit-op keyword, the operator argument takes one of the following values:
•
gt—Greater than.
•
ge—Greater than or equal to.
•
eq—Equal to.
•
ne—Not equal to.
•
lt—Less than.
•
le—Less than or equal to.
When the exit-comb keyword is used, the following criteria must be met:
•
If the or operator is specified, an exit comparison operator and an exit object ID value, or an exit time value must exist.
•
If the and operator is specified, an exit comparison operator, an exit object ID value, and an exit time value must exist.
When the entry-val-is-increment keyword is used, the following occurs:
•
If the true keyword is specified, the entry-value is an increment and the interface event is raised whenever the increment value occurs.
•
If the false keyword is specified, the entry-value is an absolute value and the interface event is raised whenever the absolute value occurs. This is the default.
When the optional exit-val-is-increment keyword is used, the following occurs:
•
If the true keyword is specified, the exit-value is an increment and the event monitoring is reenabled whenever the increment value occurs.
•
If the false keyword is specified, the exit-value is an absolute value and the event monitoring is reenabled whenever the absolute value occurs. This is the default.
Examples
The following example shows how a policy named EventInterface is triggered every time the receive_throttle counter for the Fast Ethernet interface 0/0 is incremented by 5. The polling interval to check the counter is specified to run once every 10 seconds.
Router(config)# event manager applet EventInterfaceRouter(config-applet)# event interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5 entry-val-is-increment true poll-interval 10Router(config-applet)# action 1.0 syslog msg "Applet EventInterface"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event ioswdsysmon
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of Cisco IOS system monitor counters crossing a threshold, use the event ioswdsysmon command in applet configuration mode. To remove the event criteria, use the no form of this command.
event ioswdsysmon sub1 subevent1 [timewin timewin-value] [sub12-op {and | or | andnot}
sub2 subevent2]no event ioswdsysmon sub1 subevent1 [timewin timewin-value] [sub12-op {and | or | andnot} sub2 subevent2]
Subevent Syntax (for the subevent1 and subevent2 Arguments) for Cisco IOS Images
cpu-proc taskname task-name op operator val value [period period-value]
mem-proc taskname task-name op operator val value [is-percent {true | false}] [period period-value]
Syntax Description
Command Default
No EEM events are triggered on the basis of Cisco IOS system monitor counters.
Command Modes
Applet configuration
Command History
Usage Guidelines
An EEM event is triggered when one of the Cisco IOS system monitor counters crosses a defined threshold. Depending on the operator, the threshold may be crossed when the value is greater than the threshold or when the value is less than the threshold.
If a match is found when the op keyword is used, a subevent is triggered.
Examples
The following example shows how to configure a policy to trigger an applet when the total amount of memory used by the process named "IP RIB Update" has increased by more than 50 percent over the sample period of 60 seconds:
Router(config)# event manager applet IOSWD_Sample3Router(config-applet)# event ioswdsysmon sub1 mem-proc taskname "IP RIB Update" op gt val 50 is-percent true period 60Router(config-applet)# action 1 syslog msg "IOSWD_Sample3 Policy Triggered"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event manager applet
To register an applet with the Embedded Event Manager (EEM) and to enter applet configuration mode, use the event manager applet command in global configuration mode. To remove the applet command from the configuration file, use the no form of this command.
event manager applet applet-name
no event manager applet applet-name
Syntax Description
Command Default
No EEM applets are registered.
Command Modes
Global configuration
Command History
Usage Guidelines
An EEM applet is a concise method for defining event screening criteria and the actions to be taken when that event occurs.
Only one event configuration command is allowed within an applet configuration. When applet configuration submode is exited and no event command is present, a warning is displayed stating that no event is associated with this applet. If no event is specified, this applet is not considered registered and the applet is not displayed. When no action is associated with this applet, events are still triggered but no actions are performed. Multiple action applet configuration commands are allowed within an applet configuration. Use the show event manager policy registered command to display a list of registered applets.
Before modifying an EEM applet, use the no form of this command to unregister the applet because the existing applet is not replaced until you exit applet configuration mode. While you are in applet configuration mode modifying the applet, the existing applet may be executing. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.
Action configuration commands are uniquely identified using the label argument, which can be any string value. Actions are sorted in ascending alphanumeric key sequence using the label argument as the sort key and are run using this sequence.
The EEM schedules and runs policies on the basis of an event specification that is contained within the policy itself. When applet configuration mode is exited, EEM examines the event and action commands that are entered and registers the applet to be run when a specified event occurs.
Examples
The following example shows an EEM applet called IPSLAping1 being registered to run when there is an exact match on the value of a specified SNMP object ID that represents a successful IP SLA ICMP echo operation (this is equivalent to a ping command). Four actions are triggered when the echo operation fails, and event monitoring is disabled until after the second failure. A message saying that the ICMP echo operation to a server failed is sent to syslog, an SNMP trap is generated, EEM publishes an application-specific event, and a counter called IPSLA1F is incremented by a value of one.
Router(config)# event manager applet IPSLAping1Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.4 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5Router(config-applet)# action 1.0 syslog priority critical msg "Server IP echo failed: OID=$_snmp_oid_val"Router(config-applet)# action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"Router(config-applet)# action 1.2 publish-event sub-system 88000101 type 1 arg1 10.1.88.9 arg2 IPSLAEcho arg3 failRouter(config-applet)# action 1.3 counter name _IPSLA1F value 1 op incRelated Commands
Command Descriptionshow event manager policy registered
Displays registered Embedded Event Manager policies.
event manager directory user
To specify a directory to use for storing user library files or user-defined Embedded Event Manager (EEM) policies, use the event manager directory user command in global configuration command. To disable use of a directory for storing user library files or user-defined EEM policies, use the no form of this command.
event manager directory user {library path | policy path}
no event manager directory user {library path | policy path}
Syntax Description
Command Default
No directory is specified for storing user library files or user-defined EEM policies.
Command Modes
Global configuration
Command History
Usage Guidelines
The user library directory is needed to store user library files associated with authoring EEM policies. If you have no plans to author EEM policies, you need not create a user library directory.
Modular Cisco IOS software supports policy files created by using the Tool Command Language (Tcl) scripting language. Tcl is provided in the Modular Cisco IOS software image when the EEM is installed on the network device. Files with the .tcl extension can be EEM policies, Tcl library files, or a special Tcl library index file named "tclindex." The tclindex file contains a list of user function names and the library files that contain the user functions. The EEM searches the user library directory when Tcl starts up to process the tclindex file.
To create the user library directory before identifying it to the EEM, use the mkdir command in privileged EXEC mode. After creating the user library directory, you can use the copy command to copy .tcl library files into the user library directory.
The user policy directory is needed to store user-defined policy files. If you have no plans to author EEM policies, you need not create a user policy directory. The EEM searches the user policy directory when you enter the event manager policy policy-filename type user command.
To create the user policy directory before identifying it to the EEM, use the mkdir command in privileged EXEC mode. After creating the user policy directory, you can use the copy command to copy policy files into the user policy directory.
Examples
The following example shows how to specify disk0:/user_library as the directory to use for storing user library files:
Router(config)# event manager directory user library disk0:/user_libraryRelated Commands
Command Descriptioncopy
Copies any file from a source to a destination.
event manager policy
Registers an EEM policy with the EEM.
mkdir
Creates a new directory in a Class C flash file system.
event manager environment
To set an Embedded Event Manager (EEM) environment variable, use the event manager environment command in global configuration mode. To disable an EEM environment variable, use the no form of this command.
event manager environment variable-name string
no event manager environment variable-name
Syntax Description
variable-name
Name assigned to the EEM environment variable.
string
Series of characters, including embedded spaces, to be placed in the environment variable variable-name.
Command Default
No EEM environment variables are set.
Command Modes
Global configuration
Command History
Usage Guidelines
By convention, the names of all environment variables defined by Cisco begin with an underscore character to set them apart: for example, _show_cmd.
To support embedded white spaces in the string argument, the current implementation of this command interprets everything after the variable-name argument to the end of the line to be part of the string argument.
To display the name and value of all EEM environment variables after you have configured them, use the show event manager environment command.
Examples
The following example of the event manager environment command defines a set of EEM environment variables:
Router(config)# event manager environment _cron_entry 0-59/2 0-23/1 * * 0-7Router(config)# event manager environment _show_cmd show versionRelated Commands
Command Descriptionshow event manager environment
Displays the name and value of all EEM environment variables.
event manager history size
To change the size of Embedded Event Manager (EEM) history tables, use the event manager history size command in global configuration mode. To restore the default history table size, use the no form of this command.
event manager history size {events | traps} [size]
no event manager history size {events | traps}
Syntax Description
Command Default
The size of the history table is 50 entries.
Command Modes
Global configuration
Command History
Examples
The following example of the event manager history size command changes the size of the SNMP trap history table to 30 entries:
Router(config)# event manager history size traps 30Related Commands
Command Descriptionshow event manager history events
Displays the EEM events that have been triggered.
show event manager history traps
Displays the EEM SNMP traps that have been sent.
event manager policy
To register an Embedded Event Manager (EEM) policy with the EEM, use the event manager policy command in global configuration mode. To remove the event manager policy command from the configuration file, use the no form of this command.
event manager policy policy-filename [type {system | user}] [trap]
no event manager policy policy-filename
Syntax Description
Command Default
No EEM policies are registered.
Command Modes
Global configuration
Command History
Usage Guidelines
The EEM schedules and runs policies on the basis of an event specification that is contained within the policy itself. When the event manager policy command is invoked, the EEM examines the policy and registers it to be run when the specified event occurs.
If you enter the event manager policy command without specifying the optional type keyword, the EEM first tries to locate the specified policy file in the system policy directory. If the EEM finds the file in the system policy directory, it registers the policy as a system policy. If the EEM does not find the specified policy file in the system policy directory, it looks in the user policy directory. If the EEM locates the specified file in the user policy directory, it registers the policy file as a user policy. If the EEM finds policy files with the same name in both the system policy directory and the user policy directory, the policy file in the system policy directory takes precedence and is registered as a system policy.
Examples
The following example of the event manager policy command registers a system-defined policy named tm_countdown_ios.tcl located in the system policy directory:
Router(config)# event manager policy tm_countdown_ios.tcl type systemThe following example of the event manager policy command registers a user-defined policy named cron.tcl located in the user policy directory:
Router(config)# event manager policy cron.tcl type userRelated Commands
event manager run
To manually run a registered Embedded Event Manager (EEM) policy, use the event manager run command in global configuration mode.
event manager run policy-filename
Syntax Description
Command Default
No registered EEM policies are run.
Command Modes
Global configuration
Command History
Usage Guidelines
EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event manager run command allows policies to be run manually. Before this command is used, the event none command must be configured in applet configuration for the specified policy to indicate to EEM that the policy is to be run manually.
This command does not have a no form.
Examples
The following example of the event manager run command manually runs an EEM policy named policy_manual.tcl:
Router(config)# event manager run policy-manual.tclRelated Commands
event manager scheduler suspend
To immediately suspend Embedded Event Manager (EEM) policy scheduling execution, use the event manager scheduler suspend command in global configuration mode. To resume EEM policy scheduling, use the no form of this command.
event manager scheduler suspend
no event manager scheduler suspend
Syntax Description
This command has no arguments or keywords.
Command Default
Policy scheduling is active.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the event manager scheduler suspend command to suspend all policy scheduling requests and do no scheduling until you enter the no form of the command. The no form of the command resumes policy scheduling and executes any pending policies.
You might want to suspend policy execution immediately instead of unregistering policies one by one for the following reasons:
•
For security—if you think the security of your system has been compromised.
•
For performance—if you want to suspend policy execution temporarily to make more CPU cycles available for other functions.
Examples
The following example of the event manager scheduler suspend command disables policy scheduling:
Router(config)# event manager scheduler suspendMay 19 14:31:22.439: fm_server[12330]: %HA_EM-6-FMS_POLICY_EXEC: fh_io_msg: Policy execution has been suspendedThe following example of the event manager scheduler suspend command enables policy scheduling:
Router(config)# no event manager scheduler suspendMay 19 14:31:40.449: fm_server[12330]: %HA_EM-6-FMS_POLICY_EXEC: fh_io_msg: Policy execution has been resumedRelated Commands
event manager scheduler script
To set the Embedded Event Manager (EEM) script scheduling options, use the event manager scheduler script command in global configuration mode. To remove the EEM script scheduling options and restore the default value, use the no form of this command.
event manager scheduler script thread class default number default-number
no event manager scheduler script thread class default number default-number
Syntax Description
Command Default
Only one EEM policy can be run at a time.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the event manager scheduler script command if you want more than one EEM policy to run concurrently.
Examples
The following example shows how to specify two script execution threads to run concurrently:
Router(config)# event manager scheduler script thread class default number 2event manager session cli username
To associate a username with Embedded Event Manager (EEM) policies that use the command-line interface (CLI) library, use the event manager session cli username command in global configuration mode. To remove the username association with EEM policies that use the CLI library, use the no form of this command.
event manager session cli username username
no event manager session cli username username
Syntax Description
Command Default
No username is associated with EEM CLI sessions.
Command Modes
Global configuration
Command History
Usage Guidelines
Use the event manager session cli username command to assign a username for EEM policy CLI sessions when TACACS+ is used for command authorization.
If you are using authentication, authorization, and accounting (AAA) security and implement authorization on a command basis, you should use the event manager session cli username command to set a username to be associated with a Tool Command Language (Tcl) session. The username is used when a Tcl policy executes a CLI command. TACACS+ verifies each CLI command using the username associated with the Tcl session that is running the policy. Commands from Tcl policies are not usually verified because the router must be in privileged EXEC mode to register the policy.
Examples
The following example of the event manager session cli username command associates the username eemuser with EEM CLI sessions initiated by EEM policies:
Router(config)# event manager session cli username finance1Related Commands
Command Descriptionshow event manager session cli username
Displays the username associated with CLI sessions initiated by EEM policies that use the EEM CLI library.
event none
To specify that an Embedded Event Manager (EEM) policy is to be registered with the EEM and can be run manually, use the event none command in applet configuration mode. To remove the event none command from the configuration file, use the no form of this command.
event none
no event none
Syntax Description
This command has no arguments or keywords.
Command Default
No EEM policies are specified to be run manually.
Command Modes
Applet configuration
Command History
Usage Guidelines
EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event none command allows EEM to identify an EEM policy that can either be run manually or be run when an EEM applet is triggered. To run the policy, use either the action policy command in applet configuration mode or the event manager run command in global configuration mode.
Examples
The following example shows how to register a policy named manual-policy to be run manually and then how to execute the policy:
Router(config)# event manager applet manual-policyRouter(config-applet)# event noneRouter(config-applet)# exitRouter(config)# event manager run manual-policyRelated Commands
event oir
To specify that an Embedded Event Manager (EEM) applet be run on the basis of an event raised when a hardware card online insertion and removal (OIR) occurs, use the event oir command in applet configuration mode. To remove the event oir command from the configuration, use the no form of this command.
event oir
no event oir
Syntax Description
This command has no arguments or keywords.
Command Default
No EEM applets are run on the basis of an OIR event.
Command Modes
Applet configuration
Command History
Examples
The following example shows how to configure an EEM applet to be run on the basis of an OIR event:
Router(config)# event manager applet oir-eventRouter(config-applet)# event oirRouter(config-applet)# exitRelated Commands
Command Descriptionevent manager applet
Registers an EEM applet with EEM and enters applet configuration mode.
event snmp
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run by sampling Simple Network Management Protocol (SNMP) object identifier values, use the event snmp command in applet configuration mode. To remove the SNMP event criteria, use the no form of this command.
event snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value [entry-type {value | increment | rate}] [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-type {value | increment | rate}] [exit-time exit-time-value] [exit-event
{true | false}] [average-factor average-factor-value] poll-interval poll-int-valueno event snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value [entry-type {value | increment | rate}] [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-type {value | increment | rate}] [exit-time exit-time-value] [exit-event
{true | false}] [average-factor average-factor-value] poll-interval poll-int-valueSyntax Description
Command Default
No EEM events are triggered on the basis of SNMP object identifier values.
Command Modes
Applet configuration
Command History
Usage Guidelines
An EEM event is triggered when one of the fields specified by an SNMP object ID crosses a defined threshold. If multiple conditions exist, the SNMP event will be triggered when all the conditions are met.
Exit criteria are optional. If exit criteria are not specified, event monitoring will be reenabled immediately. If exit criteria are specified—on the basis of values or time periods—event monitoring is not reenabled until the criteria are met.
An OID is defined as a type in the associated MIB, CISCO-EMBEDDED-EVENT-MGR-MIB, and each type has an object value. Monitoring of some OID types is supported. When the oid keyword is used, an error message is returned if the OID is not one of the following:
•
INTEGER_TYPE
•
COUNTER_TYPE
•
GAUGE_TYPE
•
TIME_TICKS_TYPE
•
COUNTER_64_TYPE
•
OCTET_PRIM_TYPE
•
OPAQUE_PRIM_TYPE
When the entry-op keyword is used and there is a match, an event is triggered and event monitoring is disabled until the exit criteria are met.
When the exit-op keyword is used and there is a match, an event is triggered and event monitoring is reenabled.
The operator argument takes one of the following values:
•
gt—Greater than.
•
ge—Greater than or equal to.
•
eq—Equal to.
•
ne—Not equal to.
•
lt—Less than.
•
le—Less than or equal to.
Rate is defined as the sum of the incremental difference for the sample taken at each poll interval compared to the previous sample divided by the period. The period is defined as the average factor times the poll interval. An event is triggered or event monitoring is reenabled based on a comparison of the derived rate value.
The increment and rate types are supported only for the following OID types: INTEGER_TYPE, COUNTER_TYPE, and COUNTER_64_TYPE.
Examples
The following example shows how an EEM applet called memory-fail will run when there is an exact match on the value of a specified SNMP object ID that represents the amount of current process memory. A message saying that process memory is exhausted and noting the current available memory will be sent to syslog.
Router(config)# event manager applet memory-failRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 10Router(config-applet)# action 1.0 syslog msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"The following example shows an EEM applet called IPSLAping1 being registered to run when there is an exact match on the value of a specified SNMP object ID that represents a successful IP SLA ICMP echo operation (this is equivalent to a ping command). Four actions are triggered when the echo operation fails, and event monitoring is disabled until after the second failure.
A message saying that the ICMP echo operation to a server failed is sent to syslog, an SNMP trap is generated, EEM publishes an application-specific event, and a counter called IPSLA1F is incremented by a value of one.
Router(config)# event manager applet IPSLAping1Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.4 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5Router(config-applet)# action 1.0 syslog priority critical msg "Server IP echo failed: OID=$_snmp_oid_val"Router(config-applet)# action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"Router(config-applet)# action 1.2 publish-event sub-system 88000101 type 1 arg1 10.1.88.9 arg2 IPSLAEcho arg3 failRouter(config-applet)# action 1.3 counter name _IPSLA1F value 1 op incRelated Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event syslog
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run by matching syslog messages, use the event syslog command in applet configuration mode. To remove the syslog message event criteria, use the no form of this command.
event syslog pattern regular-expression [occurs num-occurrences] [period period-value] [priority priority-level] [severity-level]
no event syslog pattern regular-expression [occurs num-occurrences] [period period-value] [priority priority-level] [severity-level]
Syntax Description
Command Default
No EEM events are triggered on the basis of matches with syslog messages.
Command Modes
Applet configuration
Command History
Usage Guidelines
Use the event syslog command to set up event criteria against which syslog messages are matched. Syslog messages are compared against a specified regular expression. After a specified number of matches occurs within a specified time period, an EEM event is triggered. If multiple conditions exist, the EEM event is triggered when all the conditions are met.
Valid levels for the priority-level argument are as follows (enter the keyword or number, if available):
•
all—All priorities are considered when log messages are screened.
•
{0 | emergencies}—System is unusable.
•
{1 | alerts}—Immediate action is needed.
•
{2 | critical}—Critical conditions.
•
{3 | errors}—Error conditions.
•
{4 | warnings}—Warning conditions.
•
{5 | notifications}—Normal but significant conditions.
•
{6 | informational}—Informational messages.
•
{7 | debugging}—Debugging messages.
The severity-level argument may be one or more of the following keywords:
•
severity-critical—Critical conditions.
•
severity-debugging—Debugging messages.
•
severity-fatal—Fatal conditions.
•
severity-major—Major conditions.
•
severity-minor—Minor conditions.
•
severity-normal—Normal conditions.
•
severity-notification—Significant conditions.
•
severity-warning—Warning conditions.
Examples
The following example shows how to specify an EEM applet to run when syslog identifies that Ethernet interface 1/0 is down. The applet sends a message about the interface to syslog.
Router(config)# event manager applet interface-downRouter(config-applet)# event syslog pattern {.*UPDOWN.*Ethernet1/0.*} occurs 4Router(config-applet)# action 1.0 syslog msg "Ethernet interface 1/0 is down"Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
event timer
To specify the event criteria for an Embedded Event Manager (EEM) applet that is run on the basis of time-specific events, use the event timer command in applet configuration mode. To remove the time-specific event criteria, use the no form of this command.
event timer {absolute time time-value | countdown time time-value | cron cron-entry cron-entry | watchdog time time-value} [name timer-name]
no event timer {absolute time time-value | countdown time time-value | cron cron-entry cron-entry | watchdog time time-value} [name timer-name]
Syntax Description
Command Default
No EEM events are triggered on the basis of time-specific events.
Command Modes
Applet configuration
Command History
Usage Guidelines
For the cron-entry argument, the following special strings also are allowed in syntax:
•
Range of numbers—The specified range is inclusive, and a hyphen separates the numbers. For example, 8-11 after the hour field specifies execution of a CRON timer event at hours 8, 9, 10, and 11.
•
Asterisk (*)—Indicates that a field is not specified and can be any value.
•
List—A list is a set of numbers or ranges separated by a comma but no space. For example, 1,2,5,9 or 0-4,8-12.
•
Step value in conjunction with a range—Following a range with /number specifies skips of the number value through the range. For example, 0-23/2 in the hour field specifies that an event is triggered every second hour. Steps are permitted after an asterisk, for example */2 means every two hours.
Instead of the five fields of a UNIX crontab entry for the cron-entry argument, one of the following seven special strings can be entered:
•
@yearly—An event is triggered once a year. This is the equivalent of specifying 0 0 1 1 * for the first five fields.
•
@annually—Same as @yearly.
•
@monthly—An event is triggered once a month. This is the equivalent of specifying 0 0 1 * * for the first five fields.
•
@weekly—An event is triggered once a week. This is the equivalent of specifying 0 0 * * 0 for the first five fields.
•
@daily—An event is triggered once a day. This is the equivalent of specifying 0 0 * * * for the first five fields.
•
@midnight—Same as @daily.
•
@hourly—An event is triggered once an hour. This is the equivalent of specifying 0 * * * * for the first five fields.
A CRON timer may not produce the intended result if the time-of-day clock is not set to the correct time. Network Time Protocol (NTP) services can be used to facilitate keeping an accurate time-of-day clock setting. For more details on NTP configuration, see the "Performing Basic System Management" chapter of the Cisco IOS Configuration Fundamentals and Network Management Configuration Guide,
Release 12.4.When the time keyword and time-value argument are used and only milliseconds are specified, use the format 0.mmm.
Examples
The following example shows how to specify that an event is triggered one time after five hours:
Router(config)# event manager applet timer-absoluteRouter(config-applet)# event timer absolute time 18000The following example shows how to specify that an event is triggered once after six minutes and six milliseconds:
Router(config)# event manager applet timer-setRouter(config-applet)# event timer countdown time 360.006 name six-minutesThe following example shows how to specify that an event is triggered at 1:01 a.m. on January 1 each year:
Router(config)# event manager applet timer-cron1Router(config-applet)# event timer cron cron-entry 1 1 1 1 * name Jan1The following example shows how to specify that an event is triggered at noon on Monday through Friday of every week:
Router(config)# event manager applet timer-cron2Router(config-applet)# event timer cron cron-entry 0 12 * * 1-5 name MonFriThe following example shows how to specify that an event is triggered at midnight on Sunday every week:
Router(config)# event manager applet timer-cron3Router(config-applet)# event timer cron cron-entry @weekly name SundayThe following example shows how to specify that an event is triggered every five hours:
Router(config)# event manager applet timer-watchRouter(config-applet)# event timer watchdog time 18000Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
set (EEM)
To set the value of a local Embedded Event Manager (EEM) applet variable, use the set command in applet configuration mode. To remove the value of an EEM applet variable, use the no form of this command.
set label _exit_status exit-value
no set label _exit_status exit-value
Syntax Description
Defaults
No EEM applet variable values are set.
Command Modes
Applet configuration
Command History
Usage Guidelines
In EEM applet configuration mode, three types of configuration statements are supported. The event commands are used to specify the event criteria to trigger the applet to run, the action commands are used to specify an action to perform when the EEM applet is triggered, and the set command is used to set the value of an EEM applet variable. Currently only the _exit_status variable is supported for the set command.
Examples
The following example shows how to set the _exit_status variable to represent a successful status after an event has occurred three times and an action has been performed:
Router(config)# event manager applet cli-matchRouter(config-applet)# event cli pattern {.*interface loopback*} sync yes occurs 3Router(config-applet)# action 1.0 cli command "no shutdown"Router(config-applet)# set 1.0 _exit_status 0Related Commands
Command Descriptionevent manager applet
Registers an event applet with the Embedded Event Manager and enters applet configuration mode.
show event manager directory user
To display the directory to use for storing user library files or user-defined Embedded Event Manager (EEM) policies, use the show event manager directory user command in privileged EXEC mode.
show event manager directory user [library | policy]
Syntax Description
Command Default
The directories for both user library and user policy files are displayed.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the event manager directory user command to specify the directory to use for storing user library or user policy files.
Examples
The following example shows the /usr/fm_policies folder on disk 0 as the directory to use for storing EEM user library files:
Router# show event manager directory user librarydisk0:/usr/fm_policiesRelated Commands
Command Descriptionevent manager directory user
Specifies a directory to use for storing user library files or user-defined EEM policies.
show event manager environment
To display the name and value of Embedded Event Manager (EEM) environment variables, use the show event manager environment command in privileged EXEC mode.
show event manager environment [all | variable-name]
Syntax Description
all
(Optional) Displays information for all environment variables. This is the default.
variable-name
(Optional) Displays information about the specified environment variable.
Command Default
If no argument or keyword is specified, information for all environment variables is displayed.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the show event manager environment command:
Router# show event manager environmentNo. Name Value1 _cron_entry 0-59/1 0-23/1 * * 0-72 _show_cmd show version3 _syslog_pattern .*UPDOWN.*Ethernet1/0.*4 _config_cmd1 interface Ethernet1/05 _config_cmd2 no shutdownTable 5 describes the significant fields shown in the display.
Related Commands
show event manager history events
To display the Embedded Event Manager (EEM) events that have been triggered, use the show event manager history events command in privileged EXEC mode.
show event manager history events [detailed] [maximum number]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the show event manager history events command to track information about the EEM events that have been triggered.
Examples
The following is sample output from the show event manager history events command showing that two types of events, Simple Network Management Protocol (SNMP) and application, have been triggered.
Router# show event manager history eventsNo. Time of Event Event Type Name1 Fri Aug13 21:42:57 2004 snmp applet: SAAping12 Fri Aug13 22:20:29 2004 snmp applet: SAAping13 Wed Aug18 21:54:48 2004 snmp applet: SAAping14 Wed Aug18 22:06:38 2004 snmp applet: SAAping15 Wed Aug18 22:30:58 2004 snmp applet: SAAping16 Wed Aug18 22:34:58 2004 snmp applet: SAAping17 Wed Aug18 22:51:18 2004 snmp applet: SAAping18 Wed Aug18 22:51:18 2004 application applet: CustApp1Table 6 describes the significant fields shown in the display.
Related Commands
show event manager history traps
To display the Embedded Event Manager (EEM) Simple Network Management Protocol (SNMP) traps that have been sent, use the show event manager history traps command in privileged EXEC mode.
show event manager history traps {server | policy}
Syntax Description
server
Displays SNMP traps that were triggered from the EEM server.
policy
Displays SNMP traps that were triggered from within an EEM policy.
Command Modes
Privileged EXEC
Command History




