Table Of Contents

Writing Embedded Event Manager Policies Using the Cisco IOS CLI

Contents

Prerequisites for Writing EEM Policies Using the Cisco IOS CLI

Information About Writing EEM Policies Using the Cisco IOS CLI

Embedded Event Manager Policies

EEM Event Detectors Available by Cisco IOS Release

EEM Actions Available by Cisco IOS Release

Embedded Event Manager Built-In Environment Variables Used in EEM Applets

How to Write EEM Policies Using the Cisco IOS CLI

Registering and Defining an Embedded Event Manager Applet

EEM Environment Variables

Alphabetical Order of EEM Action Labels

Troubleshooting Tips

Registering and Defining an Embedded Event Manager Policy to Run Manually

Unregistering Embedded Event Manager Policies

Examples

Suspending Embedded Event Manager Policy Execution

Configuring and Tracking a Stub Object Using Embedded Event Manager

Enhanced Object Tracking

Examples

Displaying Embedded Event Manager History Data

Displaying Embedded Event Manager Registered Policies

Configuration Examples for Writing EEM Policies Using the Cisco IOS CLI

Embedded Event Manager Applet Configuration: Examples

Embedded Event Manager Manual Policy Execution: Examples

Configuring and Tracking a Stub Object Using Embedded Event Manager: Example

Embedded Event Manager Watchdog System Monitor (Cisco IOS) Event Detector Configuration: Example

Where to Go Next

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Feature Information for Writing EEM Policies Using the Cisco IOS CLI

Writing Embedded Event Manager Policies Using the Cisco IOS CLI

---

First Published: October 31, 2005

Last Updated: February 28, 2007

This module describes how to write Embedded Event Manager (EEM) policies using Cisco IOS command-line interface (CLI) applets to handle Cisco IOS software faults and events. 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. The EEM policy engine receives notifications when faults and other events occur. EEM policies implement recovery on the basis of 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.

Finding Feature Information in This Module

Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for Writing EEM Policies Using the Cisco IOS CLI" section.

Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Contents

•Prerequisites for Writing EEM Policies Using the Cisco IOS CLI

•Information About Writing EEM Policies Using the Cisco IOS CLI

•How to Write EEM Policies Using the Cisco IOS CLI

•Configuration Examples for Writing EEM Policies Using the Cisco IOS CLI

•Where to Go Next

•Additional References

•Feature Information for Writing EEM Policies Using the Cisco IOS CLI

Prerequisites for Writing EEM Policies Using the Cisco IOS CLI

•Before writing EEM policies, you should be familiar with the concepts explained in the "Embedded Event Manager Overview" module.

•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 Writing EEM Policies Using the Cisco IOS CLI

To write EEM policies using the Cisco IOS CLI, you should understand the following concepts:

•Embedded Event Manager Policies

•EEM Event Detectors Available by Cisco IOS Release

•EEM Actions Available by Cisco IOS Release

•Embedded Event Manager Built-In Environment Variables Used in EEM Applets

Embedded Event Manager Policies

EEM offers the ability to monitor events and take informational or corrective action when the monitored events occur or 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.

EEM Event Detectors Available by Cisco IOS Release

EEM uses software programs known as event detectors to determine when an EEM event occurs. Some event detectors are available on every Cisco IOS release, but most event detectors have been introduced in a specific release. Use Table 1 to determine which event detectors are available in your specific Cisco IOS release. A blank entry (—) indicates that the event detector is not available: the text "Yes" indicates that the event detector is available. The event detectors shown in Table 1 are supported in later releases of the same Cisco IOS release train. For more details on each event detector, see the Event Detectors concept in the "Embedded Event Manager Overview" module.

Table 1 Availability of Event Detectors by Cisco IOS Release 

Event Detector	12.0(26)S 12.3(4)T	12.2(25)S	12.3(14)T 12.2(18)SXF5 12.2(28)SB 12.2(33)SRA	12.4(2)T 12.2(31)SB3 12.2(33)SRB	12.2(18)SXF4 Cisco IOS Software Modularity
Application-Specific	—	Yes	Yes	Yes	Yes
CLI	—	—	Yes	Yes	Yes
Counter	—	Yes	Yes	Yes	Yes
Enhanced Object Tracking	—	—	—	Yes	—
GOLD	—	—	—	—	Yes
Interface Counter	—	Yes	Yes	Yes	Yes
None	—	—	Yes	Yes	Yes
OIR	—	—	Yes	Yes	Yes
Resource	—	—	—	Yes	Yes
RF	—	—	—	Yes	Yes
SNMP	Yes	Yes	Yes	Yes	Yes
Syslog	Yes	Yes	Yes	Yes	Yes
System Manager	—	—	—	—	Yes
Timer	—	Yes	Yes	Yes	Yes
IOSWDSysMon (Cisco IOS watchdog)	—	Yes	Yes	Yes	Yes
WDSysMon (Cisco IOS Software Modularity watchdog)	—	—	—	—	Yes

EEM Actions Available by Cisco IOS Release

The CLI-based corrective actions that are taken when event detectors report events enable a powerful on-device event management mechanism. Some actions are available in every Cisco IOS release, but most actions have been introduced in a specific release. Use Table 2 to determine which actions are available in your specific Cisco IOS release. A blank entry (—) indicates that the action is not available; the text "Yes" indicates that the action is available. The actions shown in Table 2 are supported in later releases of the same Cisco IOS release train. For more details on each action, see the Embedded Event Manager Actions concept in the "Embedded Event Manager Overview" module.

Table 2 Availability of Actions by Cisco IOS Release 

Action	12.0(26)S 12.3(4)T	12.2(25)S	12.3(14)T 12.2(18)SXF5 12.2(28)SB 12.2(33)SRA	12.4(2)T 12.2(31)SB3 12.2(33)SRB	12.2(18)SXF4 Cisco IOS Software Modularity
Execute a CLI command	—	—	Yes	Yes	Yes
Generate a CNS event	Yes	Yes	Yes	Yes	Yes
Set or modify a named counter	—	Yes	Yes	Yes	Yes
Switch to a secondary RP	Yes	Yes	Yes	Yes	Yes
Request system information	—	—	Yes	Yes	Yes
Send a short e-mail	—	—	Yes	Yes	Yes
Manually run an EEM policy	—	—	Yes	Yes	Yes
Publish an application-specific event	—	Yes	Yes	Yes	Yes
Reload the Cisco IOS software	Yes	Yes	Yes	Yes	Yes
Generate an SNMP trap	—	Yes	Yes	Yes	Yes
Generate a prioritized syslog message	Yes	Yes	Yes	Yes	Yes
Read the state of a tracked object	—	—	—	Yes	—
Set the state of a tracked object	—	—	—	Yes	—

Embedded Event Manager Built-In Environment Variables Used in EEM Applets

EEM built-in environment variables 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. Table 3 lists the Cisco built-in environment variables that are read-only alphabetically by event detector and subevent.

Table 3 EEM Built-in Environment Variables (Read Only) 

Environment Variable	Description
All Events
_event_pub_time	The time at which the event type was published.
_event_type_string	The event type that triggered the event.
Application-Specific Event Detector
_application_component_id	The event application component identifier.
_application_data1	The value of an environment variable, character text, or a combination of the two to be passed to an application-specific event when the event is published.
_application_data2	The value of an environment variable, character text, or a combination of the two to be passed to an application-specific event when the event is published.
_application_data3	The value of an environment variable, character text, or a combination of the two to be passed to an application-specific event when the event is published.
_application_data4	The value of an environment variable, character text, or a combination of the two to be passed to an application-specific event when the event is published.
_application_sub_system	The event application subsystem number.
_application_type	The type of application.
CLI Event Detector
_cli_msg	The fully expanded message that triggered the CLI event.
_cli_msg_count	The number of times that a message match occurred before the event was published.
Counter Event Detector
_counter_name	The name of the counter.
_counter_value	The value of the counter.
Enhanced Object Tracking Event Detector
_track_number	The number of the tracked object.
_track_state	The state of the tracked object; down or up.
GOLD Event Detector
_gold_card	The card on which a GOLD failure event was detected.
_gold_sub_card	The subcard on which a GOLD failure event was detected.
Interface Counter Event Detector
_interface_is_increment	A value to indicate whether the current interface counter value is an absolute value (0) or an increment value (1).
_interface_name	The name of the interface to be monitored.
_interface_parameter	The name of the interface counter to be monitored.
_interface_value	A value with which the current interface counter value is compared.
OIR Event Detector
_oir_event	A value of 1 indicates an insertion event; a value of 2 indicates a removal event.
_oir_slot	The slot number for the OIR event.
Resource Event Detector
_resource_configured_threshold	The configured ERM threshold.
_resource_current_value	The current value reported by ERM.
_resource_dampen_time	The ERM dampen time, in nanoseconds.
_resource_direction	The ERM event direction. The event direction can be one of the following: up, down, or no change.
_resource_level	The ERM event level. The four event levels are normal, minor, major, and critical.
_resource_notify_data_flag	The ERM notify data flag.
_resource_owner_id	The ERM resource owner ID.
_resource_policy_id	The ERM policy ID.
_resource_policy_violation_flag	The ERM policy violation flag; either false or true.
_resource_time_sent	The ERM event time, in nanoseconds.
_resource_user_id	The ERM resource user ID.
RF Event Detector
_rf_event	A value of 0 indicates that this is not an RF event; a value of 1 indicates an RF event.
SNMP Event Detector
_snmp_exit_event	A value of 0 indicates that this is not an exit event; a value of 1 indicates an exit event.
_snmp_oid	The SNMP object ID that caused the event to be published.
_snmp_oid_delta_val	The SNMP object ID delta value when the event was published.
_snmp_oid_val	The SNMP object ID value when the event was published.
Syslog Event Detector
_syslog_msg	The syslog message that caused the event to be published.
System Manager (Process) Event Detector
_process_dump_count	The number of times that a Posix process was dumped.
_process_exit_status	The status of the Posix process at exit.
_process_fail_count	The number of times that a Posix process failed.
_process_instance	The instance number of the Posix process.
_process_last_respawn	The Posix process that was last respawned.
_process_node_name	The node name of the Posix process.
_process_path	The path of the Posix process.
_process_process_name	The name of the Posix process.
_process_respawn_count	The number of times that a Posix process was respawned.
Timer Event Detector
_timer_remain	The time available before the timer expires. Note This environment variable is not available for the CRON timer.
_timer_time	The time at which the last event was triggered.
_timer_type	The type of timer.
Watchdog System Monitor (IOSWDSysMon) Event Detector
_ioswd_node	The slot number for the Route Processor (RP) reporting node.
_ioswd_num_subs	The number of subevents present.
All Watchdog System Monitor (IOSWDSysMon) Subevents
_ioswd_sub1_present _ioswd_sub2_present	A value to indicate whether subevent 1 or subevent 2 is present. A value of 1 means that the subevent is present; a value of 0 means that the subevent is not present.
_ioswd_sub1_type _ioswd_sub2_type	The event type, either cpu_proc or mem_proc.
Watchdog System Monitor (IOSWDSysMon) cpu_proc Subevents
_ioswd_sub1_path _ioswd_sub2_path	A process name of subevents.
_ioswd_sub1_period _ioswd_sub2_period	The time period, in seconds and optional milliseconds, used for measurement in subevents.
_ioswd_sub1_pid _ioswd_sub2_pid	The process identifier of subevents.
_ioswd_sub1_taskname _ioswd_sub2_taskname	The task name of subevents.
_ioswd_sub1_value _ioswd_sub2_value	The CPU utilization of subevents measured as a percentage.
Watchdog System Monitor (IOSWDSysMon) mem_proc Subevents
_ioswd_sub1_diff _ioswd_sub2_diff	A percentage value of the difference that triggered the event. Note This variable is set only when the _ioswd_subx_is_percent variable contains a value of 1.
_ioswd_sub1_is_percent _ioswd_sub2_is_percent	A number that identifies whether the value is a percentage. A value of 0 means that the value is not a percentage; a value of 1 means that the value is a percentage.
_ioswd_sub1_path _ioswd_sub2_path	The process name of subevents.
_ioswd_sub1_pid _ioswd_sub2_pid	The process identifier of subevents.
_ioswd_sub1_taskname _ioswd_sub2_taskname	The task name of subevents.
_ioswd_sub1_value _ioswd_sub2_value	The CPU utilization of subevents measured as a percentage.
Watchdog System Monitor (WDSysMon) Event Detector
_wd_sub1_present _wd_sub2_present	A value to indicate whether subevent 1 or subevent 2 is present. A value of 1 means that the subevent is present; a value of 0 means that the subevent is not present.
_wd_num_subs	The number of subevents present.
_wd_sub1_type _wd_sub2_type	The event type: cpu_proc, cpu_tot, deadlock, dispatch_mgr, mem_proc, mem_tot_avail, or mem_tot_used.
Watchdog System Monitor (WDSysMon) cpu_proc Subevents
_wd_sub1_node _wd_sub2_node	The slot number for the subevent RP reporting node.
_wd_sub1_period _wd_sub2_period	The time period, in seconds and optional milliseconds, used for measurement in subevents.
_wd_sub1_procname _wd_sub2_procname	The process name of subevents.
_wd_sub1_value _wd_sub2_value	The CPU utilization of subevents measured as a percentage.
Watchdog System Monitor (WDSysMon) cpu_tot Subevents
_wd_sub1_node _wd_sub2_node	The slot number for the subevent RP reporting node.
_wd_sub1_period _wd_sub2_period	The time period, in seconds and optional milliseconds, used for measurement in subevents.
_wd_sub1_value _wd_sub2_value	The CPU utilization of subevents measured as a percentage.
Watchdog System Monitor (WDSysMon) deadlock Subevents
_wd_sub1_entry_[1-N]_b_node _wd_sub2_entry_[1-N]_b_node	The slot number for the subevent RP reporting node.
_wd_sub1_entry_[1-N]_b_pid _wd_sub2_entry_[1-N]_b_pid	The process identifier of subevents.
_wd_sub1_entry_[1-N]_b_procname _wd_sub2_entry_[1-N]_b_procname	The process name of subevents.
_wd_sub1_entry_[1-N]_b_tid _wd_sub2_entry_[1-N]_b_tid	The time identifier of subevents.
_wd_sub1_entry_[1-N]_node _wd_sub2_entry_[1-N]_node	The slot number for the subevent RP reporting node.
_wd_sub1_entry_[1-N]_pid _wd_sub2_entry_[1-N]_pid	The process identifier of subevents.
_wd_sub1_entry_[1-N]_procname _wd_sub2_entry_[1-N]_procname	The process name of subevents.
_wd_sub1_entry_[1-N]_state _wd_sub2_entry_[1-N]_state	The time identifier of subevents.
_wd_sub1_entry_[1-N]_tid _wd_sub2_entry_[1-N]_tid	The time identifier of subevents.
_wd_sub1_num_entries _wd_sub2_num_entries	The number of subevents.
Watchdog System Monitor (WDSysMon) dispatch manager Subevents
_wd_sub1_node _wd_sub2_node	The slot number for the subevent RP reporting node.
_wd_sub1_period _wd_sub2_period	The time period, in seconds and optional milliseconds, used for measurement in subevents.
_wd_sub1_procname _wd_sub2_procname	The process name of subevents.
_wd_sub1_value _wd_sub2_value	The CPU utilization of subevents measured as a percentage.
Watchdog System Monitor (WDSysMon) mem_proc Subevents
_wd_sub1_diff _wd_sub2_diff	A percentage value of the difference that triggered the event. Note This variable is set only when the _wd_subx_is_percent variable contains a value of 1.
_wd_sub1_is_percent _wd_sub2_is_percent	A number that identifies whether the value is a percentage. A value of 0 means that the value is not a percentage; a value of 1 means that the value is a percentage.
_wd_sub1_node _wd_sub2_node	The slot number for the subevent RP reporting node.
_wd_sub1_period _wd_sub2_period	The time period, in seconds and optional milliseconds, used for measurement in subevents.
_wd_sub1_pid _wd_sub2_pid	The process identifier of subevents.
_wd_sub1_procname _wd_sub2_procname	The process name of subevents.
_wd_sub1_value _wd_sub2_value	The CPU utilization of subevents measured as a percentage.
Watchdog System Monitor (WDSysMon) mem_tot_avail and mem_tot_used Subevents
_wd_sub1_avail _wd_sub2_avail	The memory available for subevents.
_wd_sub1_diff _wd_sub2_diff	A percentage value of the difference that triggered the event. Note This variable is set only when the _wd_subx_is_percent variable contains a value of 1.
_wd_sub1_is_percent _wd_sub2_is_percent	A number that identifies whether the value is a percentage. A value of 0 means that the value is not a percentage; a value of 1 means that the value is a percentage.
_wd_sub1_node _wd_sub2_node	The slot number for the subevent RP reporting node.
_wd_sub1_period _wd_sub2_period	The time period, in seconds and optional milliseconds, used for measurement in subevents.
_wd_sub1_value _wd_sub2_value	The CPU utilization of subevents measured as a percentage.
_wd_sub1_used _wd_sub2_used	The memory used by subevents.

How to Write EEM Policies Using the Cisco IOS CLI

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

•Unregistering Embedded Event Manager Policies

•Suspending Embedded Event Manager Policy Execution

•Configuring and Tracking a Stub Object Using Embedded Event Manager

•Displaying Embedded Event Manager History Data

•Displaying Embedded Event Manager Registered Policies

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.

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 4 describes the e-mail-specific environment variables that can be used in EEM policies.

Table 4 EEM E-mail-Specific Environmental Variables 

Environment Variable	Description	Example
_email_server	A Simple Mail Transfer Protocol (SMTP) mail server used to send e-mail.	mailserver.example.com
_email_to	The address to which e-mail is sent.	engineering@example.com
_email_from	The address from which e-mail is sent.	devtest@example.com
_email_cc	The address to which the e-mail is copied.	manager@example.com

Alphabetical Order of EEM Action Labels

An EEM action label is a unique identifier that can be any string value. Actions are sorted and run in ascending alphanumeric (lexicographical) key sequence using the label as the sort key. If you are using numbers as labels be aware that alphanumerical sorting will sort 10.0 after 1.0, but before 2.0, and in this situation we recommend that you use numbers such as 01.0, 02.0, and so on, or use an initial letter followed by numbers.

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. action label mail server server-address to to-address from from-address [cc cc-address] subject subject body body-text

10. Add more action commands as required.

11. end

DETAILED STEPS

	Command or Action	Purpose
Step 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@example.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@example.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 90	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	action label mail server server-address to to-address from from-address [cc cc-address] subject subject body body-text Example: Router(config-applet)# action 2.0 mail server 192.168.1.10 to engineering@example.com from devtest@example.com subject "Memory failure" body "Memory exhausted; current available memory is $_snmp_oid_val bytes"	Specifies the action of sending a short e-mail when an EEM applet is triggered. •The server-address argument specifies the fully qualified domain name of the e-mail server to be used to forward the e-mail. •The to-address argument specifies the e-mail address where the e-mail is to be sent. •The from-address argument specifies the e-mail address from which the e-mail is sent. •The subject argument specifies the subject line content of the e-mail as an alphanumeric string. •The body-text argument specifies the text content of the e-mail as an alphanumeric string.
Step 10	Add more action commands as required.	—
Step 11	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 applet-name

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	event manager applet applet-name Example: Router(config)# event manager applet manual-policy	Registers the applet with the Embedded Event Manager and enters applet configuration mode.
Step 4	event none Example: Router(config-applet)# event none	Specifies that an EEM policy is to be registered with the EEM and can be run manually.
Step 5	action label syslog [priority priority-level] msg msg-text Example: Router(config-applet)# action 1.0 syslog msg "Manual-policy triggered"	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 6	end Example: Router(config-applet)# end	Exits applet configuration mode and returns to privileged EXEC mode.
Step 7	event manager run applet-name Example: Router# event manager run manual-policy	Manually runs a registered EEM policy.

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

5. exit

6. Repeat Step 2 to ensure that the policy has been removed.

DETAILED STEPS

	Command or Action	Purpose
Step 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 and user keywords display the registered system and 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 Example: Router(config)# no event manager policy IPSLAping1	Removes the EEM policy from the configuration, causing the policy to be unregistered.
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 has been 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 registered

No.  Class   Type    Event Type          Trap  Time Registered           Name

1    applet  system  snmp                Off   Fri Aug 12 17:42:52 2005  IPSLAping1

 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 90.000

 action 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 1

2    applet  system  snmp                Off   Thu Sep 15 05:57:16 2005  memory-fail

 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 90 

 action 1.0 syslog priority critical msg Memory exhausted; current available memory is 
$_snmp_oid_val bytes 

 action 2.0 force-switchover

In 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 registered

No.  Class   Type    Event Type          Trap  Time Registered           Name

1    applet  system  snmp                Off   Thu Sep 15 05:57:16 2005  memory-fail

 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 90 

 action 1.0 syslog priority critical msg Memory exhausted; current available memory is 
$_snmp_oid_val bytes 

 action 2.0 force-switchover

Suspending Embedded Event Manager Policy Execution

Perform this task to immediately suspend the execution of all EEM policies. Suspending policies, instead of unregistering them 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

	Command or Action	Purpose
Step 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 and user keywords display the registered system and 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	event manager scheduler suspend Example: Router(config)# event manager scheduler suspend	Immediately suspends the execution of all EEM policies.
Step 5	exit Example: Router(config)# exit	Exits global configuration mode and returns to privileged EXEC mode.

Configuring and Tracking a Stub Object Using Embedded Event Manager

Perform this task to create a stub object, set the state of the stub object, and configure an EEM applet to be run when the tracked object changes. Actions are specified within the EEM applet to both set and read the state of the object. This task allows EEM to define an enhanced object tracking (EOT) object that may be manipulated by other EOT clients. An EEM policy can be a trigger for any EOT object including objects defined for other EOT clients or for an object defined by EEM.

Enhanced Object Tracking

Object tracking was first introduced into the Hot Standby Router Protocol (HSRP) as a simple tracking mechanism that allowed you to track the interface line-protocol state only. Enhanced object tracking provides complete separation between the objects to be tracked and the action to be taken by a client when a tracked object changes. Thus, several clients such as EEM, VRRP, or GLBP can register their interest with the tracking process, track the same object, and each take different action when the object changes.

Each tracked object is identified by a unique number that is specified on the tracking command-line interface (CLI). Client processes use this number to track a specific object. The tracking process periodically polls the tracked objects and notes any change of value. The changes in the tracked object are communicated to interested client processes, either immediately or after a specified delay. The object values are reported as either up or down.

The EOT event detector publishes an event when the tracked object changes.

SUMMARY STEPS

1. enable

2. configure terminal

3.