Cisco IOS Network Management Configuration Guide, Release 12.4T
Writing Embedded Event Manager Policies Using Tcl

Table Of Contents

Writing Embedded Event Manager Policies Using Tcl

Finding Feature Information

Contents

Prerequisites for Writing Embedded Event Manager Policies Using Tcl

Information About Writing Embedded Event Manager Policies Using Tcl

EEM Policies

EEM Policy Tcl Command Extension Categories

General Flow of EEM Event Detection and Recovery

Safe-Tcl

Bytecode Support for EEM 2.4

Registration Substitution

Cisco File Naming Convention for EEM

How to Write Embedded Event Manager Policies Using Tcl

Registering and Defining an EEM Tcl Script

Prerequisites

Examples

Displaying EEM Registered Policies

Unregistering EEM Policies

Examples

Suspending EEM Policy Execution

Examples

Managing EEM Policies

Examples

Modifying History Table Size and Displaying EEM History Data

Displaying Software Modularity Process Reliability Metrics Using EEM

Troubleshooting Tips

Modifying the Sample EEM Policies

Sample EEM Policies

Programming EEM Policies with Tcl

Tcl Policy Structure and Requirements

EEM Entry Status

EEM Exit Status

EEM Policies and Cisco Error Number

Troubleshooting Tips

Creating an EEM User Tcl Library Index

Creating an EEM User Tcl Package Index

Configuration Examples for Writing Embedded Event Manager Policies Using Tcl

Assigning a Username for a Tcl Session: Examples

EEM Event Detector Demo: Examples

Programming Policies with Tcl: Sample Scripts Example

Debugging Embedded Event Manager Policies: Examples

Tracing Tcl set Command Operations: Example

RPC Event Detector: Example

Where to Go Next

Additional References

Related Documents

MIBs

RFCs

Technical Assistance

EEM Policy Tcl Command Extension Reference

EEM Event Registration Tcl Command Extensions

event_register_appl

event_register_cli

event_register_counter

event_register_gold

event_register_interface

event_register_ioswdsysmon

event_register_ipsla

event_register_nf

event_register_none

event_register_oir

event_register_process

event_register_resource

event_register_rf

event_register_routing

event_register_rpc

event_register_snmp

event_register_snmp_notification

event_register_snmp_object

event_register_syslog

event_register_timer

event_register_timer_subscriber

event_register_track

event_register_wdsysmon

EEM Event Information Tcl Command Extension

event_reqinfo

EEM Event Tcl Command Extension

event_completion

event_completion_with_wait

event_publish

event_wait

EEM Multiple Event Support Tcl Command Extensions

trigger

correlate

attribute

EEM Action Tcl Command Extensions

action_policy

action_process

action_program

action_reload

action_script

action_snmp_trap

action_snmp_object_value

action_switch

action_syslog

action_track_read

action_track_set

EEM Utility Tcl Command Extensions

appl_read

appl_reqinfo

appl_setinfo

counter_modify

description

fts_get_stamp

register_counter

register_timer

timer_arm

timer_cancel

unregister_counter

EEM System Information Tcl Command Extensions

sys_reqinfo_cli_freq

sys_reqinfo_cli_history

sys_reqinfo_cpu_all

sys_reqinfo_crash_history

sys_reqinfo_mem_all

sys_reqinfo_proc

sys_reqinfo_proc_all

sys_reqinfo_routername

sys_reqinfo_snmp

sys_reqinfo_syslog_freq

sys_reqinfo_syslog_history

EEM Library Debug Command Extensions

cli_debug

smtp_debug

SMTP Library Command Extensions

smtp_send_email

smtp_subst

CLI Library Command Extensions

cli_close

cli_exec

cli_get_ttyname

cli_open

cli_read

cli_read_drain

cli_read_line

cli_read_pattern

cli_run

cli_run_interactive

cli_write

CLI Library XML-PI Support

xml_pi_exec

xml_pi_parse

xml_pi_read

xml_pi_write

Tcl Context Library Command Extensions

context_retrieve

context_save

Feature Information for Writing Embedded Event Manager Policies Using Tcl


Writing Embedded Event Manager Policies Using Tcl


First Published: October 31, 2005
Last Updated: November 20, 2009

This module describes how software developers can write and customize Embedded Event Manager (EEM) policies using Tool command language (Tcl) scripts to handle Cisco IOS software faults and events. EEM is a policy-driven process by means of which faults in the Cisco IOS software system are reported through a defined application programing interface (API). 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

Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Writing Embedded Event Manager Policies Using Tcl" section.

Use Cisco Feature Navigator to find information about platform support and Cisco IOS, Catalyst OS, and Cisco IOS XE 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 Embedded Event Manager Policies Using Tcl

Information About Writing Embedded Event Manager Policies Using Tcl

How to Write Embedded Event Manager Policies Using Tcl

Configuration Examples for Writing Embedded Event Manager Policies Using Tcl

Where to Go Next

Additional References

EEM Policy Tcl Command Extension Reference

Feature Information for Writing Embedded Event Manager Policies Using Tcl

Prerequisites for Writing Embedded Event Manager Policies Using Tcl

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

If you want to write EEM policies using the command-line interface (CLI) commands, you should be familiar with the "Writing Embedded Event Manager Policies Using the Cisco IOS CLI" module.

Information About Writing Embedded Event Manager Policies Using Tcl

To write EEM policies using Tcl, you should understand the following concepts:

EEM Policies

EEM Policy Tcl Command Extension Categories

EEM Policy Tcl Command Extension Categories

General Flow of EEM Event Detection and Recovery

Safe-Tcl

Bytecode Support for EEM 2.4

Registration Substitution

Cisco File Naming Convention for EEM

EEM Policies

EEM offers the ability to monitor events and take informational or corrective action when the monitored events occur or reach a threshold. 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 command-line interface (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 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.

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 the applet. If no event is specified, the applet is not considered registered. When no action is associated with the 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, because changes are written to a temporary file. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.

Action configuration commands within an applet are uniquely identified using the label argument, which can be any string value. Actions are sorted within an applet in ascending alphanumeric key sequence using the label argument as the sort key, and they are run using this sequence. The same label argument can be used in different applets; the labels must be unique only within one applet.

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.

For more details about writing EEM policies using the Cisco IOS CLI, see the "Writing Embedded Event Manager Policies Using the Cisco IOS CLI" module.

EEM Script

All Embedded Event Manager scripts are written in Tcl. Tcl is a string-based command language that is interpreted at run time. The version of Tcl supported is Tcl version 8.3.4 plus added script support. Scripts are defined using an ASCII editor on another device, not on the networking device. The script is then copied to the networking device and registered with EEM. Tcl scripts are supported by EEM. As an enforced rule, Embedded Event Manager policies are short-lived run time routines that must be interpreted and executed in less than 20 seconds of elapsed time. If more than 20 seconds of elapsed time are required, the maxrun parameter may be specified in the event_register statement to specify any desired value.

EEM policies use the full range of the Tcl language's capabilities. However, Cisco provides enhancements to the Tcl language in the form of Tcl command extensions that facilitate the writing of EEM policies. The main categories of Tcl command extensions identify the detected event, the subsequent action, utility information, counter values, and system information.

EEM allows you to write and implement your own policies using Tcl. Writing an EEM script involves:

Selecting the event Tcl command extension that establishes the criteria used to determine when the policy is run.

Defining the event detector options associated with detecting the event.

Choosing the actions to implement recovery or respond to the detected event.

EEM Policy Tcl Command Extension Categories

There are different categories of EEM policy Tcl command extensions.


Note The Tcl command extensions available in each of these categories for use in all EEM policies are described in later sections in this document.


Table 1 EEM Policy Tcl Command Extension Categories 

Category
Definition

EEM event Tcl command extensions
(three types: event information, event registration, and event publish)

This category is represented by the event_register_xxx family of event-specific commands. There is a separate event information Tcl command extension in this category as well: event_reqinfo. This is the command used in policies to query the EEM for information about an event. There is also an EEM event publish Tcl command extension event_publish that publishes an application-specific event.

EEM action Tcl command extensions

These Tcl command extensions (for example, action_syslog) are used by policies to respond to or recover from an event or fault. In addition to these extensions, developers can use the Tcl language to implement any action desired.

EEM utility Tcl command extensions

These Tcl command extensions are used to retrieve, save, set, or modify application information, counters, or timers.

EEM system information Tcl command extensions

This category is represented by the sys_reqinfo_xxx family of system-specific information commands. These commands are used by a policy to gather system information.

EEM context Tcl command extensions

These Tcl command extensions are used to store and retrieve a Tcl context (the visible variables and their values).


General Flow of EEM Event Detection and Recovery

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, the 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.

When an event or fault is detected, Embedded Event Manager determines from the event publishers—an example would be the OIR events publisher in Figure 1—if a registration for the encountered fault or event has occurred. EEM matches the event registration information with the event data itself. A policy registers for the detected event with the Tcl command extension event_register_xxx. The event information Tcl command extension event_reqinfo is used in the policy to query the Embedded Event Manager for information about the detected event.

Figure 1 Embedded Event Manager Core Event Detectors

Safe-Tcl

Safe-Tcl is a safety mechanism that allows untrusted Tcl scripts to run in an interpreter that was created in the safe mode. The safe interpreter has a restricted set of commands that prevent accessing some system resources and harming the host and other applications. For example, it does not allow commands to access critical Cisco IOS file system directories.

Cisco-defined scripts run in full Tcl mode, but user-defined scripts run in Safe-Tcl mode. Safe-Tcl allows Cisco to disable or customize individual Tcl commands. For more details about Tcl commands, go to http://www.tcl.tk/man/.

The following list of Tcl commands are restricted with a few exceptions. Restrictions are noted against each command or command keyword:

cd—Change directory is not allowed to one of the restricted Cisco directory names.

encoding—The commands encoding names, encoding convertfrom, and encoding convertto are permitted. The encoding system command with no arguments is permitted, but the encoding system command with the ?encoding? keyword is not permitted.

exec—Not permitted.

fconfigure—Permitted.

file—The following are permitted:

file dirname

file exists

file extension

file isdirectory

file join

file pathtype

file rootname

file split

file stat

file tail

file—The following are not permitted:

file atime

file attributes

file channels

file copy

file delete

file executable

file isfile

file link

file lstat

file mkdir

file mtime

file nativename

file normalize

file owned

file readable

file readlink

file rename

file rootname

file separator

file size

file system

file type

file volumes

file writable

glob—The glob command is not permitted when searching in one of the restricted Cisco directories. Otherwise, it is permitted.

load—Only files that are in the user policy directory or the user library directory are permitted to be loaded. Static packages (for example, libraries that consist of C code) are not permitted to be loaded with the load command.

open—The open command is not allowed for a file that is located in one of the restricted Cisco directories.

pwd—The pwd command is not permitted.

socket—The socket command is permitted.

source—The source command is permitted for files that are in the user policy directory or the user library directory.

Bytecode Support for EEM 2.4

In Cisco IOS Release 12.4(20)T, EEM 2.4 introduces bytecode language (BCL) support by accepting files with the standard bytecode script extension .tbc. Tcl version 8.3.4 defines a BCL and includes a compiler that translates Tcl scripts into BCL. Valid EEM policy file extensions in EEM 2.4 for user and system policies are .tcl (Tcl Text files) and .tbc (Tcl bytecode files).

Storing Tcl scripts in bytecode improves the execution speed of the policy because the code is precompiled, creates a smaller policy size, and obscures the policy code. Obfuscation makes it a little more difficult to modify scripts and hides logic to preserve intellectual property rights.

Support for bytecode is being added to provide another option for release of supported and trusted code. We recommend that you only run well understood, or trusted and supported software on network devices. To generate Tcl bytecode for IOS EEM support, use TclPro versions 1.4 or 1.5.

To translate a Tcl script to bytecode you can use procomp, part of Free TclPro Compiler, or Active State Tcl Development Kit. When a Tcl script is compiled using procomp, the code is scrambled and a .tbc file is generated. The bytecode files are platform-independent and can be generated on any operating system on which TclPro is available, including Windows, Linux, and UNIX. Procomp is part of TclPro and available from http://www.tcl.tk/software/tclpro.

Registration Substitution

In addition to regular Tcl substitution, EEM 2.3 (in Cisco IOS Releases 12.2(33)SXH and 12.2(33)SB, and later releases) permits the substitution of an individual parameter in an EEM event registration statement line with an environment variable.

EEM 2.4 in Cisco IOS Release 12.4(20)T introduces the ability to replace multiple parameters in event registration statement lines with a single environment variable.


Note Only the first environment variable supports multiple parameter substitution. Individual parameters can still be specified with additional environment variables after the initial variable.


To illustrate the substitution, a single environment variable, $_eem_syslog_statement is configured as:

::cisco::eem::event_register_syslog pattern COUNT

Using the registration substitution, the $_eem_syslog_statement environment variable is used in the following EEM user policy:

$_eem_syslog_statement occurs $_eem_occurs_val
action_syslog "this is test 3"

Environment variables must be defined before a policy using them is registered. To define the $_eem_syslog_statement environment variable:

Router(config)# event manager environment eem_syslog_statement 
::cisco::eem::event_register_syslog pattern COUNT
Router(config)# event manager environment eem_occurs_val 2

Cisco File Naming Convention for EEM

All Embedded Event Manager policy names, policy support files (for example, e-mail template files), and library filenames are consistent with the Cisco file naming convention. In this regard, Embedded Event Manager policy filenames adhere to the following specification:

An optional prefix—Mandatory.—indicating, if present, that this is a system policy that should be registered automatically at boot time if it is not already registered. For example: Mandatory.sl_text.tcl.

A filename body part containing a two-character abbreviation (see Table 2) for the first event specified; an underscore part; and a descriptive field part that further identifies the policy.

A filename suffix part defined as .tcl.

Embedded Event Manager e-mail template files consist of a filename prefix of email_template, followed by an abbreviation that identifies the usage of the e-mail template.

Embedded Event Manager library filenames consist of a filename body part containing the descriptive field that identifies the usage of the library, followed by _lib, and a filename suffix part defined as .tcl.

Table 2 Two-Character Abbreviation Specification

ap

event_register_appl

cl

event_register_cli

ct

event_register_counter

go

event_register_gold

if

event_register_interface

io

event_register_ioswdsysmon

la

event_register_ipsla

nf

event_register_nf

no

event_register_none

oi

event_register_oir

pr

event_register_process

rf

event_register_rf

rs

event_register_resource

rt

event_register_routing

rp

event_register_rpc

sl

event_register_syslog

sn

event_register_snmp

st

event_register_snmp_notification

so

event_register_snmp_object

tm

event_register_timer

tr

event_register_track

ts

event_register_timer_subscriber

wd

event_register_wdsysmon


How to Write Embedded Event Manager Policies Using Tcl

This section contains the following tasks:

Registering and Defining an EEM Tcl Script

Displaying EEM Registered Policies

Unregistering EEM Policies

Suspending EEM Policy Execution

Managing EEM Policies

Modifying History Table Size and Displaying EEM History Data

Displaying Software Modularity Process Reliability Metrics Using EEM

Modifying the Sample EEM Policies

Programming EEM Policies with Tcl

Creating an EEM User Tcl Library Index

Creating an EEM User Tcl Package Index

Registering and Defining an EEM Tcl Script

Perform this task to configure environment variables and register an EEM policy. EEM schedules and runs policies on the basis of an event specification that is contained within the policy itself. When an EEM policy is registered, the software examines the policy and registers it to be run when the specified event occurs.

Prerequisites

You must have a policy available that is written in the Tcl scripting language. Sample policies are provided—see the details in the "Sample EEM Policies" section to see which policies are available for the Cisco IOS release image that you are using—and these sample policies are stored in the system policy directory.

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 to configure all the environment variables required by the policy to be registered in Step 6.

6. event manager policy policy-filename [type {system | user}] [trap]

7. 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 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 _cron_entry 0-59/2 0-23/1 * * 0-6

Configures the value of the specified EEM environment variable.

In this example, the software assigns a CRON timer environment variable to be set to the second minute of every hour of every day.

Step 5 

Repeat Step 4 to configure all the environment variables required by the policy to be registered in Step 6.

Step 6 

event manager policy policy-filename [type {system | user}] [trap]

Example:

Router(config)# event manager policy tm_cli_cmd.tcl type system

Registers the EEM policy to be run when the specified event defined within the policy occurs.

Use the system keyword to register a Cisco-defined system policy.

Use the user keyword to register a user-defined system policy.

Use the trap keyword to generate an SNMP trap when the policy is triggered.

In this example, the sample EEM policy named tm_cli_cmd.tcl is registered as a system policy.

Step 7 

exit

Example:

Router(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Examples

In the following example, the show event manager environment privileged EXEC command is used to display the name and value of all EEM environment variables.

Router# show event manager environment all

No.  Name                          Value
1    _cron_entry                   0-59/2 0-23/1 * * 0-6
2    _show_cmd                     show ver
3    _syslog_pattern               .*UPDOWN.*Ethernet1/0.*
4    _config_cmd1                  interface Ethernet1/0
5    _config_cmd2                  no shut

Displaying EEM 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 policy-filename]

DETAILED STEPS


Step 1 enable

Enables privileged EXEC mode. Enter your password if prompted.

Router> enable

Step 2 show event manager policy registered [event-type event-name] [time-ordered | name-ordered] [detailed policy-filename]

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-ordered

No.  Type    Event Type          Trap  Time Registered           Name
1    system  timer cron          Off   Wed May11  01:43:18 2005  tm_cli_cmd.tcl
 name {crontimer2} cron entry {0-59/1 0-23/1 * * 0-7}
 nice 0 priority normal maxrun 240

2    system  syslog              Off   Wed May11  01:43:28 2005  sl_intf_down.tcl
 occurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}
 nice 0 priority normal maxrun 90

3    system  proc abort          Off   Wed May11  01:43:38 2005  pr_cdp_abort.tcl
 instance 1 path {cdp2.iosproc}
 nice 0 priority normal maxrun 20

Use 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-ordered

No.  Type    Event Type          Trap  Time Registered           Name
1    system  proc abort          Off   Wed May11  01:43:38 2005  pr_cdp_abort.tcl
 instance 1 path {cdp2.iosproc}
 nice 0 priority normal maxrun 20

2    system  syslog              Off   Wed May11  01:43:28 2005  sl_intf_down.tcl
 occurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}
 nice 0 priority normal maxrun 90

3    system  timer cron          Off   Wed May11  01:43:18 2005  tm_cli_cmd.tcl
 name {crontimer2} cron entry {0-59/1 0-23/1 * * 0-7}
 nice 0 priority normal maxrun 240

Use 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 syslog

No.  Type    Event Type          Time Registered           Name 
1    system  syslog              Wed May11  01:43:28 2005  sl_intf_down.tcl
 occurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}
 nice 0 priority normal maxrun 90

Unregistering EEM 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] [detailed policy-filename]

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] [detailed policy-filename]

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

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 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 three EEM policies that are currently registered:

Router# show event manager policy registered

No.  Type    Event Type          Trap  Time Registered           Name
1    system  timer cron          Off   Tue Oct11  01:43:18 2005 tm_cli_cmd.tcl
 name {crontimer2} cron entry {0-59/1 0-23/1 * * 0-7}
 nice 0 priority normal maxrun 240.000

2    system  syslog              Off   Tue Oct11  01:43:28 2005 sl_intf_down.tcl
 occurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}
 nice 0 priority normal maxrun 90.000

3    system  proc abort          Off   Tue Oct11  01:43:38 2005 pr_cdp_abort.tcl
 instance 1 path {cdp2.iosproc}
 nice 0 priority normal maxrun 20.000

After the current policies are displayed, it is decided to delete the pr_cdp_abort.tcl policy using the no form of the event manager policy command:

Router# configure terminal
Router(config)# no event manager policy pr_cdp_abort.tcl
Router(config)# exit

The show event manager policy registered privileged EXEC command is entered again to display the EEM policies that are currently registered. The policy pr_cdp_abort.tcl is no longer registered.

Router# show event manager policy registered

No.  Type    Event Type          Trap  Time Registered           Name
1    system  timer cron          Off   Tue Oct11  01:45:17 2005 tm_cli_cmd.tcl
 name {crontimer2} cron entry {0-59/1 0-23/1 * * 0-7}
 nice 0 priority normal maxrun 240.000

2    system  syslog              Off   Tue Oct11  01:45:27 2005 sl_intf_down.tcl
 occurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}
 nice 0 priority normal maxrun 90.000

Suspending EEM 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] [detailed policy-filename]

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] [detailed policy-filename]

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 

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.

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 registered

No.  Type    Event Type          Trap  Time Registered           Name
1    system  timer cron          Off   Sat Oct11  01:43:18 2003  tm_cli_cmd.tcl
 name {crontimer2} cron entry {0-59/1 0-23/1 * * 0-7}
 nice 0 priority normal maxrun 240.000

2    system  syslog              Off   Sat Oct11  01:43:28 2003  sl_intf_down.tcl
 occurs 1 pattern {.*UPDOWN.*Ethernet1/0.*}
 nice 0 priority normal maxrun 90.000

3    system  proc abort          Off   Sat Oct11  01:43:38 2003  pr_cdp_abort.tcl
 instance 1 path {cdp2.iosproc}
 nice 0 priority normal maxrun 20.000

The event manager scheduler suspend command is entered to immediately suspend the execution of all EEM policies:

Router# configure terminal
Router(config)# event manager scheduler suspend

*Nov  2 15:34:39.000: %HA_EM-6-FMS_POLICY_EXEC: fh_io_msg: Policy execution has been 
suspended

Managing EEM Policies

Perform this task to specify a directory to use for storing user library files or user-defined EEM policies.


Note This task applies only to EEM policies that are written using Tcl scripts.


SUMMARY STEPS

1. enable

2. show event manager directory user [library | policy]

3. configure terminal

4. event manager directory user {library path | policy path}

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 directory user [library | policy]

Example:

Router# show event manager directory user library

(Optional) Displays the directory to use for storing EEM user library or policy files.

The optional library keyword displays the directory to use for user library files.

The optional policy keyword displays the directory to use for user-defined EEM policies.

Step 3 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 4 

event manager directory user {library path | policy path}

Example:

Router(config)# event manager directory user library disk0:/usr/lib/tcl

Specifies a directory to use for storing user library files or user-defined EEM policies.

Use the path argument to specify the absolute pathname to the user directory.

Step 5 

exit

Example:

Router(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Examples

In the following example, the show event manager directory user privileged EXEC command is used to display the directory, if it exists, to use for storing EEM user library files:

Router# show event manager directory user library

disk0:/usr/lib/tcl

Modifying 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> enable

Step 2 configure terminal

Enters global configuration mode.

Router# configure terminal

Step 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 30

Step 4 exit

Exits global configuration mode and returns to privileged EXEC mode.

Router(config)# exit

Step 5 show event manager history events [detailed] [maximum number]

Use this command to display information about each EEM event that has been triggered.

Router# show event manager history events

No.  Time of Event             Event Type          Name
1    Fri Sep  9 13:48:40 2005  syslog              applet: one 
2    Fri Sep  9 13:48:40 2005  syslog              applet: two 
3    Fri Sep  9 13:48:40 2005  syslog              applet: three 
4    Fri Sep  9 13:50:00 2005  timer cron          script: tm_cli_cmd.tcl 
5    Fri Sep  9 13:51:00 2005  timer cron          script: tm_cli_cmd.tcl

Step 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.

Router# show event manager history traps

No.  Time                      Trap Type           Name
1    Fri Sep  9 13:48:40 2005  server              applet: four 
2    Fri Sep  9 13:57:03 2005  policy              script: no_snmp_test.tcl


Displaying Software Modularity Process Reliability Metrics Using EEM

Perform this optional task to display reliability metrics for Cisco IOS Software Modularity processes. The show event manager metric processes command was introduced in Cisco IOS Release 12.2(18)SXF4 and later releases and is supported only in Software Modularity images.

SUMMARY STEPS

1. enable

2. show event manager metric processes {all | process-name}

DETAILED STEPS


Step 1 enable

Enables privileged EXEC mode. Enter your password if prompted.

Router> enable

Step 2 show event manager metric process {all | process-name}

Use this command to display the reliability metric data for processes. The system keeps a record of when processes start and end, and this data is used as the basis for reliability analysis. In this partial example, the first and last entries showing the metric data for the processes on all the cards inserted in the system are displayed.

Router# show event manager metric process all

=====================================
process name: devc-pty, instance: 1
sub_system id: 0, version: 00.00.0000
--------------------------------
last event type: process start
recent start time: Fri Oct10  20:34:40 2005
recent normal end time: n/a
recent abnormal end time: n/a
number of times started: 1
number of times ended normally: 0
number of times ended abnormally: 0
most recent 10 process start times:
--------------------------
Fri Oct10  20:34:40 2005
--------------------------

most recent 10 process end times and types:

cumulative process available time: 6 hours 30 minutes 7 seconds 378 milliseconds
cumulative process unavailable time: 0 hours 0 minutes 0 seconds 0 milliseconds
process availability:  0.100000000
number of abnormal ends within the past 60 minutes (since reload): 0
number of abnormal ends within the past 24 hours (since reload): 0
number of abnormal ends within the past 30 days (since reload): 0
.
.
.
=====================================
process name: cdp2.iosproc, instance: 1
sub_system id: 0, version: 00.00.0000
--------------------------------
last event type: process start
recent start time: Fri Oct10  20:35:02 2005
recent normal end time: n/a
recent abnormal end time: n/a
number of times started: 1
number of times ended normally: 0
number of times ended abnormally: 0
most recent 10 process start times:
--------------------------
Fri Oct10  20:35:02 2005
--------------------------

most recent 10 process end times and types:
cumulative process available time: 6 hours 29 minutes 45 seconds 506 milliseconds
cumulative process unavailable time: 0 hours 0 minutes 0 seconds 0 milliseconds
process availability:  0.100000000
number of abnormal ends within the past 60 minutes (since reload): 0
number of abnormal ends within the past 24 hours (since reload): 0
number of abnormal ends within the past 30 days (since reload): 0

Troubleshooting Tips

Use the debug event manager command in privileged EXEC mode to troubleshoot EEM command operations. Use any debugging command with caution because the volume of output generated can slow or stop the router operations. We recommend that this command be used only under the supervision of a Cisco engineer.

Modifying the Sample EEM Policies

Perform this task to modify one of the sample policies. Cisco IOS software contains some sample policies in the images that contain the Embedded Event Manager. Developers of EEM policies may modify these policies by customizing the event for which the policy is to be run and the options associated with logging and responding to the event. In addition, developers may select the actions to be implemented when the policy runs.

Sample EEM Policies

Cisco includes a set of sample policies shown in Table 3. You can copy the sample policies to a user directory and then modify the policies, or you can write your own policies. Tcl is currently the only Cisco-supported scripting language for policy creation. Tcl policies can be modified using a text editor such as Emacs. Policies must execute within a defined number of seconds of elapsed time, and the time variable can be configured within a policy. The default is currently 20 seconds.

Table 3 describes the sample EEM policies.

Table 3 Sample EEM Policy Descriptions 

Name of Policy
Description

pr_cdp_abort.tcl

Introduced in Cisco IOS Release 12.2(18)SXF4 Software Modularity images. This policy monitors for cdp2.iosproc process abort events. It will log a message to SYSLOG and send an e-mail with the details of the abort.

pr_crash_reporter.tcl

Introduced in Cisco IOS Release 12.2(18)SXF4 Software Modularity images. This policy monitors for all process abort events. When an event occurs, the policy will send crash information, including the crashdump file, to the specified URL where a CGI script processes the data.

pr_iprouting_abort.tcl

Introduced in Cisco IOS Release 12.2(18)SXF4 Software Modularity images. This policy monitors for iprouting.iosproc process abort events. It will log a message to SYSLOG and send an e-mail with the details of the abort.

sl_intf_down.tcl

This policy runs when a configurable syslog message is logged. It will execute a configurable CLI command and e-mail the results.

tm_cli_cmd.tcl

This policy runs using a configurable CRON entry. It will execute a configurable CLI command and e-mail the results.

tm_crash_history.tcl

Introduced in Cisco IOS Release 12.2(18)SXF4 Software Modularity images. This policy runs at midnight every day and e-mails a process crash history report to a specified e-mail address.

tm_crash_reporter.tcl

Introduced in Cisco IOS Release 12.4(2)T. This policy runs 5 seconds after it is registered. If the policy is saved in the configuration, it will also run each time that the router is reloaded. The policy will prompt for the reload reason. If the reload was due to a crash, the policy will search for the latest crashinfo file and send this information to a specified URL location.

tm_fsys_usage.tcl

Introduced in Cisco IOS Release 12.2(18)SXF4 Software Modularity images. This policy runs using a configurable CRON entry and monitors disk space usage. A syslog message will be displayed if disk space usage crosses configurable thresholds.

wd_mem_reporter.tcl

Introduced in Cisco IOS Release 12.2(18)SXF4 Software Modularity images. This policy reports on low system memory conditions when the amount of memory available falls below 20 percent of the initial available system memory. A syslog message will be displayed and, optionally, an e-mail will be sent.


For more details about the sample policies available and how to run them, see the "EEM Event Detector Demo: Examples" section.

SUMMARY STEPS

1. enable

2. show event manager policy available detailed policy-filename

3. Cut and paste the contents of the sample policy displayed on the screen to a text editor.

4. Edit the policy and save it with a new filename.

5. Copy the new file back to the router flash memory.

6. configure terminal

7. event manager directory user {library path | policy path}

8. event manager policy policy-filename [type {system | user}] [trap]

DETAILED STEPS


Step 1 enable

Enables privileged EXEC mode. Enter your password if prompted.

Router> enable

Step 2 show event manager policy available detailed policy-filename

Displays the actual specified sample policy including details about the environment variables used by the policy and instructions for running the policy. In Cisco IOS 12.2(18)SXF4, the detailed keyword was introduced for the show event manager policy available and the show event manager policy registered commands. In Cisco IOS releases prior to 12.2(18)SXF4, you must copy one of the two Tcl scripts from the configuration examples section in this document (see the "Programming Policies with Tcl: Sample Scripts Example" section). In the following example, details about the sample policy tm_cli_cmd.tcl are displayed on the screen.

Router# show event manager policy available detailed tm_cli_cmd.tcl

Step 3 Cut and paste the contents of the sample policy displayed on the screen to a text editor.

Use the edit and copy functions to move the contents from the router to a text editor on another device.

Step 4 Edit the policy and save it with a new filename.

Use the text editor to modify the policy as a Tcl script. For file naming conventions, see the "Cisco File Naming Convention for EEM" section.

Step 5 Copy the new file back to the router flash memory.

Copy the file to the flash file system on the router—typically disk0:. For more details about copying files, see the "Using the Cisco IOS File System" chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.

Step 6 configure terminal

Enters global configuration mode.

Router# configure terminal

Step 7 event manager directory user {library path | policy path}

Specifies a directory to use for storing user library files or user-defined EEM policies. In the following example, the user_library directory on disk0 is specified as the directory for storing user library files.

Router(config)# event manager directory user library disk0:/user_library 

Step 8 event manager policy policy-filename [type {system | user}] [trap]

Registers the EEM policy to be run when the specified event defined within the policy occurs. In the following example, the new EEM policy named test.tcl is registered as a user-defined policy.

Router(config)# event manager policy test.tcl type user


Programming EEM Policies with Tcl

Perform this task to help you program a policy using Tcl command extensions. We recommend that you copy an existing policy and modify it. There are two required parts that must exist in an EEM Tcl policy: the event_register Tcl command extension and the body. All other sections shown in the "Tcl Policy Structure and Requirements" concept are optional.

Tcl Policy Structure and Requirements

All EEM policies share the same structure, shown in Figure 2. There are two parts of an EEM policy that are required: the event_register Tcl command extension and the body. The remaining parts of the policy are optional: environment must defines, namespace import, entry status, and exit status.

Figure 2 Tcl Policy Structure and Requirements

The start of every policy must describe and register the event to detect using an event_register Tcl command extension. This part of the policy schedules the running of the policy. For a list of the available EEM event_register Tcl command extensions, see the "EEM Event Registration Tcl Command Extensions" section. The following example Tcl code shows how to register the event_register_timer Tcl command extension:

::cisco::eem::event_register_timer cron name crontimer2 cron_entry $_cron_entry maxrun 240

The environment must defines section is optional and includes the definition of environment variables. The following example Tcl code shows how to check for, and define, some environment variables.

# Check if all the env variables that we need exist.
# If any of them does not exist, print out an error msg and quit.
if {![info exists _email_server]} {
    set result \
      "Policy cannot be run: variable _email_server has not been set"
    error $result $errorInfo
}
if {![info exists _email_from]} {
    set result \
      "Policy cannot be run: variable _email_from has not been set"
    error $result $errorInfo
}
if {![info exists _email_to]} {
    set result \
      "Policy cannot be run: variable _email_to has not been set"
    error $result $errorInfo

The namespace import section is optional and defines code libraries. The following example Tcl code shows how to configure a namespace import section.

namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

The body of the policy is a required structure and might contain the following:

The event_reqinfo event information Tcl command extension that is used to query the EEM for information about the detected event. For a list of the available EEM event information Tcl command extensions, see the "EEM Event Information Tcl Command Extension" section.

The action Tcl command extensions, such as action_syslog, that are used to specify EEM specific actions. For a list of the available EEM action Tcl command extensions, see the "EEM Action Tcl Command Extensions" section.

The system information Tcl command extensions, such as sys_reqinfo_routername, that are used to obtain general system information. For a list of the available EEM system information Tcl command extensions, see the "EEM System Information Tcl Command Extensions" section.

Use of the SMTP library (to send e-mail notifications) or the CLI library (to run CLI commands) from a policy. For a list of the available SMTP library Tcl command extensions, see the "SMTP Library Command Extensions" section. For a list of the available CLI library Tcl command extensions, see the "CLI Library Command Extensions" section.

The context_save and context_retrieve Tcl command extensions that are used to save Tcl variables for use by other policies.

The following example Tcl code shows the code to query an event and log a message as part of the body section.

# Query the event info and log a message.
array set arr_einfo [event_reqinfo]
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
        $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result 
}
global timer_type timer_time_sec 
set timer_type $arr_einfo(timer_type)
set timer_time_sec $arr_einfo(timer_time_sec)
# Log a message.
set msg [format "timer event: timer type %s, time expired %s" \
        $timer_type [clock format $timer_time_sec]]
action_syslog priority info msg $msg
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
      $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result 
}

EEM Entry Status

The entry status part of an EEM policy is used to determine if a prior policy has been run for the same event, and to determine the exit status of the prior policy. If the _entry_status variable is defined, a prior policy has already run for this event. The value of the _entry_status variable determines the return code of the prior policy.

Entry status designations may use one of three possible values: 0 (previous policy was successful), Not=0 (previous policy failed), and Undefined (no previous policy was executed).

EEM Exit Status

When a policy finishes running its code, an exit value is set. The exit value is used by the Embedded Event Manager to determine whether or not to apply the default action for this event, if any. A value of zero means do not perform the default action. A value of nonzero means perform the default action. The exit status will be passed to subsequent policies that are run for the same event.

EEM Policies and Cisco Error Number

Some EEM Tcl command extensions set a Cisco Error Number Tcl global variable _cerrno. Whenever _cerrno is set, four other Tcl global variables are derived from _cerrno and are set along with it (_cerr_sub_num, _cerr_sub_err, _cerr_posix_err, and _cerr_str).

For example, the action_syslog command in the example below sets these global variables as a side effect of the command execution:

action_syslog priority warning msg "A sample message generated by action_syslog"
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
        $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result
}

_cerrno: 32-Bit Error Return Values

The _cerrno set by a command can be represented as a 32-bit integer of the following form:

XYSSSSSSSSSSSSSEEEEEEEEPPPPPPPPP

For example, the following error return value might be returned from an EEM Tcl command extension:

862439AE

This number is interpreted as the following 32-bit value:

10000110001001000011100110101110

This 32-bit integer is divided up into the five variables shown in Table 4.

Table 4 _cerrno: 32-Bit Error Return Value Variables 

Variable
Description

XY

The error class (indicates the severity of the error). This variable corresponds to the first two bits in the 32-bit error return value; 10 in the case above, which indicates CERR_CLASS_WARNING:

See Table 5 for the four possible error class encodings specific to this variable.

SSSSSSSSSSSSSS

The subsystem number that generated the most recent error
(13 bits = 8192 values). This is the next 13 bits of the 32-bit sequence, and its integer value is contained in $_cerr_sub_num.

Variable
Description

EEEEEEEE

The subsystem specific error number (8 bits = 256 values). This segment is the next 8 bits of the 32-bit sequence, and the string corresponding to this error number is contained in $_cerr_sub_err.

PPPPPPPP

The pass-through POSIX error code (9 bits = 512 values). This represents the last of the 32-bit sequence, and the string corresponding to this error code is contained in $_cerr_posix_err.


Error Class Encodings for XY

The first variable, XY, references the possible error class encodings shown in Table 5.

:

Table 5 Error Class Encodings

00

CERR_CLASS_SUCCESS

01

CERR_CLASS_INFO

10

CERR_CLASS_WARNING

11

CERR_CLASS_FATAL


An error return value of zero means SUCCESS.

SUMMARY STEPS

1. enable

2. show event manager policy available detailed policy-filename

3. Cut and paste the contents of the sample policy displayed on the screen to a text editor.

4. Define the required event_register Tcl command extension.

5. Add the appropriate namespace under the ::cisco hierarchy.

6. Program the must defines section to check for each environment variable that is used in this policy.

7. Program the body of the script.

8. Check the entry status to determine if a policy has previously run for this event.

9. Check the exit status to determine whether or not to apply the default action for this event, if a default action exists.

10. Set Cisco Error Number (_cerrno) Tcl global variables.

11. Save the Tcl script with a new filename, and copy the Tcl script to the router.

12. configure terminal

13. event manager directory user {library path | policy path}

14. event manager policy policy-filename [type {system | user}] [trap]

15. Cause the policy to execute, and observe the policy.

16. Use debugging techniques if the policy does not execute correctly.

DETAILED STEPS


Step 1 enable

Enables privileged EXEC mode. Enter your password if prompted.

Router> enable

Step 2 show event manager policy available detailed policy-filename

Displays the actual specified sample policy including details about the environment variables used by the policy and instructions for running the policy. In Cisco IOS 12.2(18)SXF4, the detailed keyword was introduced for the show event manager policy available and the show event manager policy registered commands. In Cisco IOS releases prior to 12.2(18)SXF4, you must copy one of the two Tcl scripts from the configuration examples section in this document (see the "Programming Policies with Tcl: Sample Scripts Example" section). In the following example, details about the sample policy tm_cli_cmd.tcl are displayed on the screen.

Router# show event manager policy available detailed tm_cli_cmd.tcl

Step 3 Cut and paste the contents of the sample policy displayed on the screen to a text editor.

Use the edit and copy functions to move the contents from the router to a text editor on another device. Use the text editor to edit the policy as a Tcl script.

Step 4 Define the required event_register Tcl command extension.

Choose the appropriate event_register Tcl command extension from Table 6 for the event that you want to detect, and add it to the policy.

Table 6 EEM Event Registration Tcl Command Extensions 

Event Registration Tcl Command Extensions

event_register_appl

event_register_cli

event_register_counter

event_register_gold

event_register_interface

event_register_ioswdsysmon

event_register_ipsla

event_register_nf

event_register_none

event_register_oir

event_register_process

event_register_resource

event_register_rf

event_register_routing

event_register_rpc

event_register_snmp

event_register_snmp_notification

event_register_snmp_object

event_register_syslog

event_register_timer

event_register_timer_subscriber

event_register_track

event_register_wdsysmon


Step 5 Add the appropriate namespace under the ::cisco hierarchy.

Policy developers can use the new namespace ::cisco in Tcl policies in order to group all the extensions used by Cisco IOS EEM. There are two namespaces under the ::cisco hierarchy, and Table 7 shows which category of EEM Tcl command extension belongs under each namespace.

Table 7 Cisco IOS EEM Namespace Groupings 

Namespace
Category of Tcl Command Extension

::cisco::eem

EEM event registration

EEM event information

EEM event publish

EEM action

EEM utility

EEM context library

EEM system information

CLI library

::cisco::lib

SMTP library



Note Make sure that you import the appropriate namespaces or use the qualified command names when using the above commands.


Step 6 Program the must defines section to check for each environment variable that is used in this policy.

This is an optional step. Must defines are a section of the policy that tests whether any EEM environment variables that are required by the policy are defined before the recovery actions are taken. The must defines section is not required if the policy does not use any EEM environment variables. EEM environment variables for EEM scripts are Tcl global variables that are defined external to the policy before the policy is run. To define an EEM environment variable, use the Embedded Event Manager configuration command event manager environment CLI command. By convention all Cisco EEM environment variables begin with "_" (an underscore). In order to avoid future conflict, customers are urged not to define new variables that start with "_".


Note You can display the Embedded Event Manager environment variables set on your system by using the show event manager environment privileged EXEC command.


For example, Embedded Event Manager environment variables defined by the sample policies include e-mail variables. The sample policies that send e-mail must have the variables shown in Table 8 set in order to function properly.

Table 8 describes the e-mail-specific environment variables used in the sample EEM policies.

Table 8 E-mail-Specific Environmental Variables Used by the Sample Policies 

Environment Variable
Description
Example

_email_server

A Simple Mail Transfer Protocol (SMTP) mail server used to send e-mail.

The e-mail server name can be in any one of the following template formats:

username:password@host

username@host

host

_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 must be copied.

manager@example.com


The following example of a must define section shows how to program a check for e-mail-specific environment variables.

Example 1 Example of Must Defines

if {![info exists _email_server]} {
    set result \
        "Policy cannot be run: variable _email_server has not been set"
    error $result $errorInfo
}
if {![info exists _email_from]} {
    set result \
        "Policy cannot be run: variable _email_from has not been set"
    error $result $errorInfo
}
if {![info exists _email_to]} {
    set result \
        "Policy cannot be run: variable _email_to has not been set"
    error $result $errorInfo
}
if {![info exists _email_cc]} {
    set result \
        "Policy cannot be run: variable _email_cc has not been set"
    error $result $errorInfo
}

Step 7 Program the body of the script.

In this section of the script, you can define any of the following:

The event_reqinfo event information Tcl command extension that is used to query the EEM for information about the detected event.

The action Tcl command extensions, such as action_syslog, that are used to specify EEM specific actions.

The system information Tcl command extensions, such as sys_reqinfo_routername, that are used to obtain general system information.

The context_save and context_retrieve Tcl command extensions that are used to save Tcl variables for use by other policies.

Use of the SMTP library (to send e-mail notifications) or the CLI library (to run CLI commands) from a policy.

Step 8 Check the entry status to determine if a policy has previously run for this event.

If the prior policy is successful, the current policy may or may not require execution. Entry status designations may use one of three possible values: 0 (previous policy was successful), Not=0 (previous policy failed), and Undefined (no previous policy was executed).

Step 9 Check the exit status to determine whether or not to apply the default action for this event, if a default action exists.

A value of zero means do not perform the default action. A value of nonzero means perform the default action. The exit status will be passed to subsequent policies that are run for the same event.

Step 10 Set Cisco Error Number (_cerrno) Tcl global variables.

Some EEM Tcl command extensions set a Cisco Error Number Tcl global variable _cerrno. Whenever _cerrno is set, four other Tcl global variables are derived from _cerrno and are set along with it (_cerr_sub_num, _cerr_sub_err, _cerr_posix_err, and _cerr_str).

For example, the action_syslog command in the example below sets these global variables as a side effect of the command execution:

action_syslog priority warning msg "A sample message generated by action_syslog
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
        $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result
}

Step 11 Save the Tcl script with a new filename, and copy the Tcl script to the router.

Embedded Event Manager policy filenames adhere to the following specification:

An optional prefix—Mandatory.—indicating, if present, that this is a system policy that should be registered automatically at boot time if it is not already registered. For example: Mandatory.sl_text.tcl.

A filename body part containing a two-character abbreviation (see Table 2) for the first event specified; an underscore character part; and a descriptive field part further identifying the policy.

A filename suffix part defined as .tcl.

For more details, see the "Cisco File Naming Convention for EEM" section.

Copy the file to the flash file system on the router—typically disk0:. For more details about copying files, see the "Using the Cisco IOS File System" chapter in the Cisco IOS Configuration Fundamentals Configuration Guide.

Step 12 configure terminal

Enters global configuration mode.

Router# configure terminal

Step 13 event manager directory user {library path | policy path}

Specifies a directory to use for storing user library files or user-defined EEM policies. In the following example, the user_library directory on disk0 is specified as the directory for storing user library files.

Router(config)# event manager directory user library disk0:/user_library 

Step 14 event manager policy policy-filename [type {system | user}] [trap]

Registers the EEM policy to be run when the specified event defined within the policy occurs. In the following example, the new EEM policy named cl_mytest.tcl is registered as a user-defined policy.

Router(config)# event manager policy cl_mytest.tcl type user

Step 15 Cause the policy to execute, and observe the policy.

To test that the policy runs, generate the conditions that will cause the policy to execute and observe that the policy runs as expected.

Step 16 Use debugging techniques if the policy does not execute correctly.

Use the Cisco IOS debug event manager CLI command with its various keywords to debug issues. Refer to the "Troubleshooting Tips" section for details about using Tcl-specific keywords.


Troubleshooting Tips

Use the debug event manager tcl commands CLI command to debug issues with Tcl extension commands. When enabled, this command displays all data that is passed in and read back from the TTY session that handles the CLI interactions. This data helps ensure users that the commands they are passing to the CLI are valid.

The CLI library allows users to run CLI commands and obtain the output of commands in Tcl. Use the debug event manager tcl cli-library CLI command to debug issues with the CLI library.

The SMTP library allows users to send e-mail messages to an SMTP e-mail server. Use the debug event manager tcl smtp_library CLI command to debug issues with the SMTP library. When enabled, this command displays all data that is passed in and read back from the SMTP library routines. This data helps ensure users that the commands they are passing to the SMTP library are valid.

Tcl is a flexible language that allows you to override commands. For example, you can modify the set command and create a version of the set command that displays a message when a scalar variable is set. When the set command is entered in a policy, a message is displayed anytime a scalar variable is set, and this provides a way to debug scalar variables. To view an example of this debugging technique, see the "Tracing Tcl set Command Operations: Example" section.

To view examples of the some of these debugging techniques, see the "Debugging Embedded Event Manager Policies: Examples" section.

Creating an EEM User Tcl Library Index

Perform this task to create an index file that contains a directory of all the procedures contained in a library of Tcl files. This task allows you to test library support in EEM Tcl. In this task, a library directory is created to contain the Tcl library files, the files are copied into the directory, and an index tclIndex) is created that contains a directory of all the procedures in the library files. If the index is not created, the Tcl procedures will not be found when an EEM policy is run that references a Tcl procedure.

SUMMARY STEPS

1. On your workstation (UNIX, Linux, PC, or Mac) create a library directory and copy the Tcl library files into the directory.

2. tclsh

3. auto_mkindex directory_name *.tcl

4. Copy the Tcl library files from Step 1 and the tclIndex file from Step 3 to the directory used for storing user library files on the target router.

5. Copy a user-defined EEM policy file written in Tcl to the directory used for storing user-defined EEM policies on the target router.

6. enable

7. configure terminal

8. event manager directory user library path

9. event manager directory user policy path

10. event manager policy policy-filename [type {system | user}] [trap]

11. event manager run policy-filename

DETAILED STEPS


Step 1 On your workstation (UNIX, Linux, PC, or Mac) create a library directory and copy the Tcl library files into the directory.

The following example files can be used to create a tclIndex on a workstation running the Tcl shell:

lib1.tcl

proc test1 {} {
    puts "In procedure test1"
}
proc test2 {} {
    puts "In procedure test2"
}

lib2.tcl

proc test3 {} {
    puts "In procedure test3"
}

Step 2 tclsh

Use this command to enter the Tcl shell.

workstation% tclsh

Step 3 auto_mkindex directory_name *.tcl

Use the auto_mkindex command to create the tclIndex file. The tclIndex file that contains a directory of all the procedures contained in the Tcl library files. We recommend that you run auto_mkindex inside a directory because there can only be a single tclIndex file in any directory and you may have other Tcl files to be grouped together. Running auto_mkindex in a directory determines which tcl source file or files are indexed using a specific tclIndex.

workstation% auto_mkindex eem_library *.tcl

The following example TclIndex is created when the lib1.tcl and lib2.tcl files are in a library file directory and the auto_mkindex command is run.

tclIndex

# Tcl autoload index file, version 2.0
# This file is generated by the "auto_mkindex" command
# and sourced to set up indexing information for one or
# more commands.  Typically each line is a command that
# sets an element in the auto_index array, where the
# element name is the name of a command and the value is
# a script that loads the command.
set auto_index(test1) [list source [file join $dir lib1.tcl]]
set auto_index(test2) [list source [file join $dir lib1.tcl]]
set auto_index(test3) [list source [file join $dir lib2.tcl]]

Step 4 Copy the Tcl library files from Step 1 and the tclIndex file from Step 3 to the directory used for storing user library files on the target router.

Step 5 Copy a user-defined EEM policy file written in Tcl to the directory used for storing user-defined EEM policies on the target router. The directory can be the same directory used in Step 4.

The directory for storing user-defined EEM policies can be the same directory used in Step 4. The following example user-defined EEM policy can be used to test the Tcl library support in EEM.

libtest.tcl

::cisco::eem::event_register_none
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
global auto_index auto_path
puts [array names auto_index]
if { [catch {test1} result]} {
    puts "calling test1 failed result = $result $auto_path"
}
if { [catch {test2} result]} {
    puts "calling test2 failed result = $result $auto_path"
}

if { [catch {test3} result]} {
    puts "calling test3 failed result = $result $auto_path"
}

Step 6 enable

Enables privileged EXEC mode. Enter your password if prompted.

Router> enable

Step 7 configure terminal

Enables global configuration mode.

Router# configure terminal

Step 8 event manager directory user library path

Use this command to specify the EEM user library directory; this is the directory to which the files in Step 4 were copied.

router(config)# event manager directory user library disk2:/eem_library

Step 9 event manager directory user policy path

Use this command to specify the EEM user policy directory; this is the directory to which the file in Step 5 was copied.

router(config)# event manager directory user policy disk2:/eem_policies

Step 10 event manager policy policy-name [type {system | user} [trap]

Use this command to register a user-defined EEM policy. In this example, the policy named libtest.tcl is registered.

router(config)# event manager policy libtest.tcl

Step 11 event manager run policy-name

Use this command to manually run an EEM policy. In this example, the policy named libtest.tcl is run to test the Tcl support in EEM. The example output shows that the test for Tcl support in EEM was successful.

router(config)# event manager run libtest.tcl

The following output is displayed:

01:24:37: %HA_EM-6-LOG: libtest.tcl: In procedure test1
01:24:37: %HA_EM-6-LOG: libtest.tcl: In procedure test2
01:24:37: %HA_EM-6-LOG: libtest.tcl: In procedure test3


Creating an EEM User Tcl Package Index

Perform this task to create a Tcl package index file that contains a directory of all the Tcl packages and version information contained in a library of Tcl package files. Tcl packages are supported using the Tcl package keyword, and this support was introduced in Cisco IOS Release 12.4(11)T.

Tcl packages are located in either the EEM system library directory or the EEM user library directory. When a package require Tcl command is executed, the user library directory is searched first for a pkgIndex.tcl file. If the pkgIndex.tcl file is not found in the user directory, the system library directory is searched. In this task, a Tcl package directory—the pkgIndex.tcl file—is created in the appropriate library directory using the pkg_mkIndex command to contain information about all of the Tcl packages contained in the directory along with version information. If the index is not created, the Tcl packages will not be found when an EEM policy is run that contains a package require Tcl command.

Using the Tcl package support in EEM, users can gain access to packages such as XML_RPC for Tcl. When the Tcl package index is created, a Tcl script can easily make an XML-RPC call to an external entity.


Note Packages implemented in C programming code are not supported in EEM.


SUMMARY STEPS

1. On your workstation (UNIX, Linux, PC, or Mac) create a library directory and copy the Tcl package files into the directory.

2. tclsh

3. pkg_mkIndex directory_name *.tcl

4. Copy the Tcl package files from Step 1 and the pkgIndex file from Step 3 to the directory used for storing user library files on the target router.

5. Copy a user-defined EEM policy file written in Tcl to the directory used for storing user-defined EEM policies on the target router.

6. enable

7. configure terminal

8. event manager directory user library path

9. event manager directory user policy path

10. event manager policy policy-filename [type {system | user}] [trap]

11. event manager run policy-filename

DETAILED STEPS


Step 1 On your workstation (UNIX, Linux, PC, or Mac) create a library directory and copy the Tcl package files into the directory.

Step 2 tclsh

Use this command to enter the Tcl shell.

workstation% tclsh

Step 3 pkg_mkindex directory_name *.tcl

Use the pkg_mkindex command to create the pkgIndex file. The pkgIndex file contains a directory of all the packages contained in the Tcl library files. We recommend that you run pkg_mkindex inside a directory because there can only be a single pkgIndex file in any directory and you may have other Tcl files to be grouped together. Running pkg_mkindex in a directory determines which Tcl package file or files are indexed using a specific pkgIndex.

workstation% pkg_mkindex eem_library *.tcl

The following example pkgIndex is created when some Tcl package files are in a library file directory and the pkg_mkindex command is run.

pkgIndex

# Tcl package index file, version 1.1
# This file is generated by the "pkg_mkIndex" command
# and sourced either when an application starts up or
# by a "package unknown" script. It invokes the
# "package ifneeded" command to set up package-related
# information so that packages will be loaded automatically
# in response to "package require" commands. When this
# script is sourced, the variable $dir must contain the
# full path name of this file's directory.

package ifneeded xmlrpc 0.3 [list source [file join $dir xmlrpc.tcl]]


Step 4 Copy the Tcl library files from Step 1 and the pkgIndex file from Step 3 to the directory used for storing user library files on the target router.

Step 5 Copy a user-defined EEM policy file written in Tcl to the directory used for storing user-defined EEM policies on the target router. The directory can be the same directory used in Step 4.

The directory for storing user-defined EEM policies can be the same directory used in Step 4. The following example user-defined EEM policy can be used to test the Tcl package support in EEM.

packagetest.tcl

::cisco::eem::event_register_none maxrun 1000000.000
#
# test if xmlrpc available
#
#
# Namespace imports
#
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
#
package require xmlrpc
puts "Did you get an error?"

Step 6 enable

Enables privileged EXEC mode. Enter your password if prompted.

Router> enable

Step 7 configure terminal

Enables global configuration mode.

Router# configure terminal

Step 8 event manager directory user library path

Use this command to specify the EEM user library directory; this is the directory to which the files in Step 4 were copied.

router(config)# event manager directory user library disk2:/eem_library

Step 9 event manager directory user policy path

Use this command to specify the EEM user policy directory; this is the directory to which the file in Step 5 was copied.

router(config)# event manager directory user policy disk2:/eem_policies

Step 10 event manager policy policy-name [type {system | user} [trap]

Use this command to register a user-defined EEM policy. In this example, the policy named packagetest.tcl is registered.

router(config)# event manager policy packagetest.tcl

Step 11 event manager run policy-name

Use this command to manually run an EEM policy. In this example, the policy named packagetest.tcl is run to test the Tcl package support in EEM.

router(config)# event manager run packagetest.tcl


Configuration Examples for Writing Embedded Event Manager Policies Using Tcl

This section contains the following configuration examples:

Assigning a Username for a Tcl Session: Examples

EEM Event Detector Demo: Examples

Programming Policies with Tcl: Sample Scripts Example

Debugging Embedded Event Manager Policies: Examples

Tracing Tcl set Command Operations: Example

RPC Event Detector: Example

Assigning a Username for a Tcl Session: Examples

The following example shows how to set a username to be associated with a Tcl session. 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 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. In the example, the username is yourname, and this is the username that is used whenever a CLI command session is initiated from within an EEM policy.

configure terminal
 event manager session cli username yourname
 end

EEM Event Detector Demo: Examples

This example uses the sample policies to demonstrate how to use Embedded Event Manager policies. Proceed through the following sections to see how to use the sample policies:

EEM Sample Policy Descriptions

Event Manager Environment Variables for the Sample Policies

Registration of Some EEM Policies

Basic Configuration Details for All Sample Policies

Using the Sample Policies

EEM Sample Policy Descriptions

This configuration example features four of the sample EEM policies:

sl_intf_down.tcl—Is run when a configurable syslog message is logged. It executes up to two configurable CLI commands and e-mails the results.

tm_cli_cmd.tcl—Is run using a configurable CRON entry. It executes a configurable CLI command and e-mails the results.

tm_crash_reporter.tcl—Introduced in Cisco IOS Release 12.4(2)T, 12.2(31)SB3, and 12.2(33)SRB. Is run 5 seconds after it is registered and 5 seconds after the router boots up. When triggered, the script attempts to find the reload reason. If the reload reason was due to a crash, the policy searches for the related crashinfo file and sends this information to a URL location specified by the user in the environment variable _crash_reporter_url.

tm_fsys_usage.tcl—Introduced in Cisco IOS Release 12.2(18)SXF4 Cisco IOS Software Modularity images. This policy runs using a configurable CRON entry and monitors disk space usage. A syslog message is displayed if disk space usage crosses configurable thresholds.

Event Manager Environment Variables for the Sample Policies

Event manager environment variables are Tcl global variables that are defined external to the EEM policy before the policy is registered and run. The sample policies require three of the e-mail environment variables to be set (see Table 8 for a list of the e-mail variables); only _email_cc is optional. Other required and optional variable settings are outlined in the following tables.

Table 9 describes the EEM environment variables that must be set before the sl_intf_down.tcl sample policy is run.

Table 9 Environment Variables Used in the sl_intf_down.tcl Policy 

Environment Variable
Description
Example

_config_cmd1

The first configuration command that is executed.

interface Ethernet1/0

_config_cmd2

The second configuration command that is executed. This variable is optional and need not be specified.

no shutdown

_syslog_pattern

A regular expression pattern match string that is used to compare syslog messages to determine when the policy runs.

.*UPDOWN.*FastEthernet0/0.*


Table 10 describes the EEM environment variables that must be set before the tm_cli_cmd.tcl sample policy is run.

Table 10 Environment Variables Used in the tm_cli_cmd.tcl Policy 

Environment Variable
Description
Example

_cron_entry

A CRON specification that determines when the policy will run.

0-59/1 0-23/1 * * 0-7

_show_cmd

The CLI command to be executed when the policy is run.

show version


Table 11 describes the EEM environment variables that must be set before the tm_crash_reporter.tcl sample policy is run.

Table 11 Environment Variables Used in the tm_crash_reporter.tcl Policy 

Environment Variable
Description
Example

_crash_reporter_debug

A value that identifies whether debug information for tm_crash_reporter.tcl will be enabled. This variable is optional and need not be specified.

1

_crash_reporter_url

The URL location to which the crash report is sent.

http://www.example.com/fm/interface_tm.cgi


Table 12 describes the EEM environment variables that must be set before the tm_fsys_usage.tcl sample policy is run.

Table 12 Environment Variables Used in the tm_fsys_usage.tcl Policy 

Environment Variable
Description
Example

_tm_fsys_usage_cron

A CRON specification that is used in the event_register Tcl command extension. If unspecified, the tm_fsys_usage.tcl policy is triggered once per minute. This variable is optional and need not be specified.

0-59/1 0-23/1 * * 0-7

_tm_fsys_usage_debug

When this variable is set to a value of 1, disk usage information is displayed for all entries in the system. This variable is optional and need not be specified.

1

_tm_fsys_usage_
freebytes

Free byte threshold for systems or specific prefixes. If free space falls below a given value, a warning is displayed. This variable is optional and need not be specified.

disk2:98000000

_tm_fsys_usage_percent

Disk usage percentage thresholds for systems or specific prefixes. If the disk usage percentage exceeds a given percentage, a warning is displayed. If unspecified, the default disk usage percentage is 80 percent for all systems. This variable is optional and need not be specified.

nvram:25 disk2:5


Registration of Some EEM Policies

Some EEM policies must be unregistered and then reregistered if an EEM environment variable is modified after the policy is registered. The event_register_xxx statement that appears at the start of the policy contains some of the EEM environment variables, and this statement is used to establish the conditions under which the policy is run. If the environment variables are modified after the policy has been registered, the conditions may become invalid. To avoid any errors, the policy must be unregistered and then reregistered. The following variables are affected:

_cron_entry in the tm_cli_cmd.tcl policy

_syslog_pattern in the sl_intf_down.tcl policy

Basic Configuration Details for All Sample Policies

To allow e-mail to be sent from the Embedded Event Manager, the hostname and ip domain-name commands must be configured. The EEM environment variables must also be set. After a Cisco IOS image has been booted, use the following initial configuration, substituting appropriate values for your network. The environment variables for the tm_fsys_usage sample policy (see Table 12) are all optional and are not listed here:

hostname cpu
ip domain-name example.com
event manager environment _email_server ms.example.net
event manager environment _email_to username@example.net
event manager environment _email_from engineer@example.net
event manager environment _email_cc projectgroup@example.net
event manager environment _cron_entry 0-59/2 0-23/1 * * 0-7
event manager environment _show_cmd show event manager policy registered
event manager environment _syslog_pattern .*UPDOWN.*FastEthernet0/0
event manager environment _config_cmd1 interface Ethernet1/0
event manager environment _config_cmd2 no shutdown
event manager environment _crash_reporter_debug 1
event manager environment _crash_reporter_url 
http://www.example.com/fm/interface_tm.cgi
end

Using the Sample Policies

This section contains the following configuration scenarios to demonstrate how to use the four sample Tcl policies:

Running the sl_intf_down.tcl Sample Policy

Running the tm_cli_cmd.tcl Sample Policy

Running the tm_crash_reporter.tcl Sample Policy

Running the tm_fsys_usage.tcl Sample Policy

Running the sl_intf_down.tcl Sample Policy

This sample policy demonstrates the ability to modify the configuration when a syslog message with a specific pattern is logged. The policy gathers detailed information about the event and uses the CLI library to execute the configuration commands specified in the EEM environment variables _config_cmd1 and, optionally, _config_cmd2. An e-mail message is sent with the results of the CLI command.

The following sample configuration demonstrates how to use this policy. Starting in user EXEC mode, enter the enable command at the router prompt. The router enters privileged EXEC mode, where you can enter the show event manager policy registered command to verify that no policies are currently registered. The next command is the show event manager policy available command to display which policies are available to be installed. After you enter the configure terminal command to reach global configuration mode, you can register the sl_intf_down.tcl policy with EEM using the event manager policy command. Exit from global configuration mode and enter the show event manager policy registered command again to verify that the policy has been registered.

The policy runs when an interface goes down. Enter the show event manager environment command to display the current environment variable values. Unplug the cable (or configure a shutdown) for the interface specified in the _syslog_pattern EEM environment variable. The interface goes down, prompting the syslog daemon to log a syslog message about the interface being down, and the syslog event detector is called.

The syslog event detector reviews the outstanding event specifications and finds a match for interface status change. The EEM server is notified, and the server runs the policy that is registered to handle this event—sl_intf_down.tcl.

enable
show event manager policy registered
show event manager policy available
configure terminal
 event manager policy sl_intf_down.tcl
 end
show event manager policy registered
show event manager environment

Running the tm_cli_cmd.tcl Sample Policy

This sample policy demonstrates the ability to periodically execute a CLI command and to e-mail the results. The CRON specification "0-59/2 0-23/1 * * 0-7" causes this policy to be run on the second minute of each hour. The policy gathers detailed information about the event and uses the CLI library to execute the configuration commands specified in the EEM environment variable _show_cmd. An e-mail message is sent with the results of the CLI command.

The following sample configuration demonstrates how to use this policy. Starting in user EXEC mode, enter the enable command at the router prompt. The router enters privileged EXEC mode where you can enter the show event manager policy registered command to verify that no policies are currently registered. The next command is the show event manager policy available command to display which policies are available to be installed. After you enter the configure terminal command to reach global configuration mode, you can register the tm_cli_cmd.tcl policy with EEM using the event manager policy command. Exit from global configuration mode and enter the show event manager policy registered command to verify that the policy has been registered.

The timer event detector triggers an event for this case periodically according to the CRON string set in the EEM environment variable _cron_entry. The EEM server is notified, and the server runs the policy that is registered to handle this event—tm_cli_cmd.tcl.

enable
show event manager policy registered
show event manager policy available
configure terminal
 event manager policy tm_cli_cmd.tcl
 end
show event manager policy registered

Running the tm_crash_reporter.tcl Sample Policy

This sample policy demonstrates the ability to send an HTTP-formatted crash report to a URL location. If the policy registration is saved in the startup configuration file, the policy is triggered 5 seconds after bootup. When triggered, the script attempts to find the reload reason. If the reload reason was due to a crash, the policy searches for the related crashinfo file and sends this information to a URL location specified by the user in the environment variable _crash_reporter_url. A CGI script, interface_tm.cgi, has been created to receive the URL from the tm_crash_reporter.tcl policy and save the crash information in a local database on the target URL machine.

A Perl CGI script, interface_tm.cgi, has been created and is designed to run on a machine that contains an HTTP server and is accessible by the router that runs the tm_crash_reporter.tcl policy. The interface_tm.cgi script parses the data passed into it from tm_crash_reporter.tcl and appends the crash information to a text file, creating a history of all crashes in the system. Additionally, detailed information on each crash is stored in three files in a crash database directory that is specified by the user. Another Perl CGI script, crash_report_display.cgi, has been created to display the information stored in the database created by the interface_tm.cgi script. The crash_report_display.cgi script should be placed on the same machine that contains interface_tm.cgi. The machine should be running a web browser such as Internet Explorer or Netscape. When the crash_report_display.cgi script is run, it displays the crash information in a readable format.

The following sample configuration demonstrates how to use this policy. Starting in user EXEC mode, enter the enable command at the router prompt. The router enters privileged EXEC mode where you can enter the show event manager policy registered command to verify that no policies are currently registered. The next command is the show event manager policy available command to display which policies are available to be installed. After you enter the configure terminal command to reach global configuration mode, you can register the tm_crash_reporter.tcl policy with EEM using the event manager policy command. Exit from global configuration mode and enter the show event manager policy registered command to verify that the policy has been registered.

enable
show event manager policy registered
show event manager policy available
configure terminal
 event manager policy tm_crash_reporter.tcl
 end
show event manager policy registered

Running the tm_fsys_usage.tcl Sample Policy

This sample policy demonstrates the ability to periodically monitor disk space usage and report through syslog when configurable thresholds have been crossed.

The following sample configuration demonstrates how to use this policy. Starting in user EXEC mode, enter the enable command at the router prompt. The router enters privileged EXEC mode, where you can enter the show event manager policy registered command to verify that no policies are currently registered. The next command is the show event manager policy available command to display which policies are available to be installed. After you enter the configure terminal command to reach global configuration mode, you can register the tm_fsys_usage.tcl policy with EEM using the event manager policy command. Exit from global configuration mode and enter the show event manager policy registered command again to verify that the policy has been registered. If you had configured any of the optional environment variables that are used in the tm_fsys_usage.tcl policy, the show event manager environment command displays the configured variables.

enable
show event manager policy registered
show event manager policy available
configure terminal
 event manager policy tm_fsys_usage.tcl
 end
show event manager policy registered
show event manager environment

Programming Policies with Tcl: Sample Scripts Example

This section contains two of the sample policies that are included as EEM system policies. These two policies were introduced in Cisco IOS Release 12.3(14)T and 12.2(18)SXF5 images. For more details about these policies, see the "EEM Event Detector Demo: Examples" section.

tm_cli_cmd.tcl Sample Policy

sl_intf_down.tcl Sample Policy

tm_cli_cmd.tcl Sample Policy

The following sample policy runs a configurable CRON entry. The policy executes a configurable Cisco IOS CLI command and e-mails the results. An optional log file can be defined to which the output is appended with a timestamp.

::cisco::eem::event_register_timer cron name crontimer2 cron_entry $_cron_entry maxrun 240

#------------------------------------------------------------------
# EEM policy that will periodically execute a cli command and email the
# results to a user.
#
# July 2005, Cisco EEM team
#
# Copyright (c) 2005 by cisco Systems, Inc.
# All rights reserved.
#------------------------------------------------------------------

### The following EEM environment variables are used:
###
### _cron_entry (mandatory)            - A CRON specification that determines
###                                      when the policy will run. See the
###                                      IOS Embedded Event Manager
###                                      documentation for more information
###                                      on how to specify a cron entry.
### Example: _cron_entry                 0-59/1 0-23/1 * * 0-7
###
### _log_file (mandatory without _email_....)
###                                    - A filename to append the output to.
###                                      If this variable is defined, the
###                                      output is appended to the specified
###                                      file with a timestamp added.
### Example: _log_file                   disk0:/my_file.log
###
### _email_server (mandatory without _log_file)
###                                    - A Simple Mail Transfer Protocol (SMTP)
###                                      mail server used to send e-mail.
### Example: _email_server               mailserver.example.com
###
### _email_from (mandatory without _log_file)
###                                    - The address from which e-mail is sent.
### Example: _email_from                 devtest@example.com
###
### _email_to (mandatory without _log_file)
###                                    - The address to which e-mail is sent.
### Example: _email_to                   engineering@example.com
###
### _email_cc (optional)               - The address to which the e-mail must
###                                      be copied.
### Example: _email_cc                   manager@example.com
###
### _show_cmd (mandatory)              - The CLI command to be executed when
###                                      the policy is run.
### Example: _show_cmd                   show version
###

# check if all required environment variables exist
# If any required environment variable does not exist, print out an error msg and quit
if {![info exists _log_file]} {
    if {![info exists _email_server]} {
	set result \
		"Policy cannot be run: variable _log_file or _email_server has not been set"
	error $result $errorInfo
    }
    if {![info exists _email_from]} {
	set result \
		"Policy cannot be run: variable _log_file or _email_from has not been set"
	error $result $errorInfo
    }
    if {![info exists _email_to]} {
	set result \
		"Policy cannot be run: variable _log_file ore _email_to has not been set"
	error $result $errorInfo
    }
    if {![info exists _email_cc]} {
	#_email_cc is an option, must set to empty string if not set.
	set _email_cc ""
    }
}

if {![info exists _show_cmd]} {
    set result \
        "Policy cannot be run: variable _show_cmd has not been set"
    error $result $errorInfo
}


namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

# query the event info and log a message
array set arr_einfo [event_reqinfo]

if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
        $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result
}

global timer_type timer_time_sec
set timer_type $arr_einfo(timer_type)
set timer_time_sec $arr_einfo(timer_time_sec)

# log a message
set msg [format "timer event: timer type %s, time expired %s" \
        $timer_type [clock format $timer_time_sec]]

action_syslog priority info msg $msg
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
	$_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result
}

# 1. execute the command
if [catch {cli_open} result] {
    error $result $errorInfo
} else {
    array set cli1 $result
}
if [catch {cli_exec $cli1(fd) "en"} result] {
    error $result $errorInfo
}
# save exact execution time for command
set time_now [clock seconds]
# execute command
if [catch {cli_exec $cli1(fd) $_show_cmd} result] {
    error $result $errorInfo
} else {
    set cmd_output $result
    # format output: remove trailing router prompt
    regexp {\n*(.*\n)([^\n]*)$} $result dummy cmd_output
}
if [catch {cli_close $cli1(fd) $cli1(tty_id)} result] {
    error $result $errorInfo
}
# 2. log the success of the CLI command
set msg [format "Command \"%s\" executed successfully" $_show_cmd]
action_syslog priority info msg $msg
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
        $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result
}

# 3. if _log_file is defined, then attach it to the file
if {[info exists _log_file]} {
    # attach output to file
    if [catch {open $_log_file a+} result] {
        error $result
    }
    set fileD $result
    # save timestamp of command execution
    #      (Format = 00:53:44 PDT Mon May 02 2005)
    set time_now [clock format $time_now -format "%T %Z %a %b %d %Y"]
    puts $fileD "%%% Timestamp = $time_now"
    puts $fileD $cmd_output
    close $fileD
}

# 4. if _email_server is defined send the email out
if {[info exists _email_server]} {
    set routername [info hostname]
    if {[string match "" $routername]} {
	error "Host name is not configured"
    }

    if [catch {smtp_subst [file join $tcl_library email_template_cmd.tm]} \
	    result] {
	error $result $errorInfo
    }

    if [catch {smtp_send_email $result} result] {
	error $result $errorInfo
    }
}

sl_intf_down.tcl Sample Policy

The following sample policy runs when a configurable syslog message is logged. The policy executes a configurable CLI command and e-mails the results.

::cisco::eem::event_register_syslog occurs 1 pattern $_syslog_pattern maxrun 90
#------------------------------------------------------------------
# EEM policy to monitor for a specified syslog message.
# Designed to be used for syslog interface-down messages.  
# When event is triggered, the given config commands will be run.
#
# July 2005, Cisco EEM team
#
# Copyright (c) 2005 by cisco Systems, Inc.
# All rights reserved.
#------------------------------------------------------------------
### The following EEM environment variables are used:
###
### _syslog_pattern (mandatory)        - A regular expression pattern match string 
###                                      that is used to compare syslog messages
###                                      to determine when policy runs 
### Example: _syslog_pattern             .*UPDOWN.*FastEthernet0/0.* 
###
### _email_server (mandatory)          - A Simple Mail Transfer Protocol (SMTP)
###                                      mail server used to send e-mail.
### Example: _email_server               mailserver.example.com
###
### _email_from (mandatory)            - The address from which e-mail is sent.
### Example: _email_from                 devtest@example.com
###
### _email_to (mandatory)              - The address to which e-mail is sent.
### Example: _email_to                   engineering@example.com
###
### _email_cc (optional)               - The address to which the e-mail must
###                                      be copied.
### Example: _email_cc                   manager@example.com
###
### _config_cmd1 (optional)            - The first configuration command that
###                                      is executed.
### Example: _config_cmd1                interface Ethernet1/0 
###
### _config_cmd2 (optional)            - The second configuration command that
###                                      is executed.
### Example: _config_cmd2                no shutdown
###
# check if all the env variables we need exist
# If any of them doesn't exist, print out an error msg and quit
if {![info exists _email_server]} {
    set result \
        "Policy cannot be run: variable _email_server has not been set"
    error $result $errorInfo
}
if {![info exists _email_from]} {
    set result \
        "Policy cannot be run: variable _email_from has not been set"
    error $result $errorInfo
}
if {![info exists _email_to]} {
    set result \
        "Policy cannot be run: variable _email_to has not been set"
    error $result $errorInfo
}
if {![info exists _email_cc]} {
     #_email_cc is an option, must set to empty string if not set.
     set _email_cc ""
}
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
# 1. query the information of latest triggered eem event
array set arr_einfo [event_reqinfo]
if {$_cerrno != 0} {
    set result [format "component=%s; subsys err=%s; posix err=%s;\n%s" \
      $_cerr_sub_num $_cerr_sub_err $_cerr_posix_err $_cerr_str]
    error $result 
}
set msg $arr_einfo(msg)
set config_cmds ""
# 2. execute the user-defined config commands
if [catch {cli_open} result] {
    error $result $errorInfo
} else {
    array set cli1 $result
} 
if [catch {cli_exec $cli1(fd) "en"} result] {
    error $result $errorInfo
} 
if [catch {cli_exec $cli1(fd) "config t"} result] {
    error $result $errorInfo
} 
if {[info exists _config_cmd1]} {
    if [catch {cli_exec $cli1(fd) $_config_cmd1} result] {
        error $result $errorInfo
    }

    append config_cmds $_config_cmd1
}
if {[info exists _config_cmd2]} {
    if [catch {cli_exec $cli1(fd) $_config_cmd2} result] {
        error $result $errorInfo
    } 
    append config_cmds "\n"
    append config_cmds $_config_cmd2
}
if [catch {cli_exec $cli1(fd) "end"} result] {
    error $result $errorInfo
} 
if [catch {cli_close $cli1(fd) $cli1(tty_id)} result] {
    error $result $errorInfo
} 
after 60000
# 3. send the notification email
set routername [info hostname]
if {[string match "" $routername]} {
    error "Host name is not configured"
}
if [catch {smtp_subst [file join $tcl_library email_template_cfg.tm]} result] {
    error $result $errorInfo
}
if [catch {smtp_send_email $result} result] {
    error $result $errorInfo
}

The following e-mail template file is used with the EEM sample policy above:

email_template_cfg.tm

Mailservername: $_email_server
From: $_email_from
To: $_email_to
Cc: $_email_cc
Subject: From router $routername: Periodic $_show_cmd Output

$cmd_output

Debugging Embedded Event Manager Policies: Examples

The following examples show how to debug the CLI library and the SMTP library.

Debugging the CLI Library

The CLI library allows users to run CLI commands and obtain the output of commands in Tcl. An Embedded Event Manager debug command has been provided for users of this library. The command to enable CLI library debugging is debug event manager tcl cli_library. When enabled, this command displays all data that is passed in and read back from the TTY session that handles the CLI interactions. This data helps ensure users that the commands that they are passing to the CLI are valid.

Example of the debug event manager tcl cli_library Command

This example uses the sample policy sl_intf_down.tcl. When triggered, sl_intf_down.tcl passes a configuration command to the CLI through the CLI library. The command passed in below is show event manager environment. This command is not a valid command in configuration mode. Without the debug command enabled, the output is shown below:

00:00:57:sl_intf_down.tcl[0]:config_cmds are show eve man env 
00:00:57:%SYS-5-CONFIG_I:Configured from console by vty0

Notice that with the output above the user would not know whether or not the command succeeded in the CLI. With the debug event manager tcl cli_library command enabled, the user sees the following:

01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : CTL : cli_open called. 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : nelson>
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : IN  : nelson>enable 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : nelson# 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : IN  : nelson#configure terminal
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : Enter configuration commands, one 
per line.  End with CNTL/Z. 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : nelson(config)# 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : IN  : nelson(config)#show event manager 
environment
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT :                 ^ 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : % Invalid input detected at '^' 
marker. 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : nelson(config)# 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : IN  : nelson(config)#end 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : OUT : nelson# 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : CTL : cli_close called. 
01:17:07: sl_intf_down.tcl[0]: DEBUG(cli_lib) : IN  : nelson#exit 
01:17:07: sl_intf_down.tcl[0]: config_cmds are show event manager environment
01:17:07: %SYS-5-CONFIG_I: Configured from console by vty0

The output above shows that show event manager environment is an invalid command in configuration mode. The IN keyword signifies all data passed in to the TTY through the CLI library. The OUT keyword signifies all data read back from the TTY through the CLI library. The CTL keyword signifies helper functions used in the CLI library. These helper functions are used to set up and remove connections to the CLI.

Debugging the SMTP Library

The SMTP library allows users to send e-mail messages to an SMTP e-mail server. An Embedded Event Manager debug command has been provided for users of this library. The command to enable SMTP library debugging is debug event manager tcl smtp_library. When enabled, this command displays all data that is passed in and read back from the SMTP library routines. This data helps ensure users that the commands that they are passing to the SMTP library are valid.

Example of the debug event manager tcl smtp_library Command

This example uses the sample policy tm_cli_cmd.tcl. When triggered, tm_cli_cmd.tcl runs the command show event manager policy available system through the CLI library. The result is then mailed to a user through the SMTP library. The output will help debug any issues related to using the SMTP library.

With the debug event manager tcl smtp_library command enabled, the users see the following on the console:

00:39:46: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 220 XXXX.example.com ESMTP 
XXXX 1.1.0; Tue, 25 Jun 2002 14:20:39 -0700 (PDT) 
00:39:46: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : HELO XXXX.example.com 
00:39:46: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 250 XXXX.example.com Hello 
XXXX.example.com [XXXX], pleased to meet you 
00:39:46: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : MAIL FROM:<XX@example.com> 
00:39:46: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 250 <XX@example.com>... Sender 
ok 
00:39:46: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : RCPT TO:<XX@example.com> 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 250 <XX@example.com>... 
Recipient ok 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : RCPT TO:<XX@example.com> 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 250 <XX@example.com>... 
Recipient ok 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : DATA 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 354 Enter mail, end with "." 
on a line by itself 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : Date: 25 Jun 2002 14:35:00 UTC 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : Message-ID: 
<20020625143500.2387058729877@XXXX.example.com> 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : From: XX@example.com 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : To: XX@example.com 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : Cc: XX@example.com 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : Subject: From router nelson: 
Periodic show eve man po ava system Output 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : No.  Type    Time Created                  
Name                           
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : 1    system  Fri May3   
20:42:34 2002      pr_cdp_abort.tcl               
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : 2    system  Fri May3   
20:42:54 2002      pr_iprouting_abort.tcl         
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : 3    system  Wed Apr3   
02:16:33 2002      sl_intf_down.tcl               
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : 4    system  Mon Jun24  
23:34:16 2002      tm_cli_cmd.tcl                 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : 5    system  Wed Mar27  
05:53:15 2002      tm_crash_hist.tcl              
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : nelson# 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write :  
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : . 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 250 ADE90179 Message accepted 
for delivery 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_write : QUIT 
00:39:47: tm_cli_cmd.tcl[0]: DEBUG(smtp_lib) : smtp_read  : 221 XXXX.example.com closing 
connection 

Tracing Tcl set Command Operations: Example

Tcl is a flexible language. One of the flexible aspects of Tcl is that you can override commands. In this example, the Tcl set command is renamed as _set and a new version of the set command is created that displays a message containing the text "setting" and appends the scalar variable that is being set. This example can be used to trace all instances of scalar variables being set.

rename set _set
proc set {var args} {
   puts [list setting $var $args]
   uplevel _set $var $args
};

When this is placed in a policy, a message is displayed anytime a scalar variable is set, for example:

02:17:58: sl_intf_down.tcl[0]: setting test_var 1

RPC Event Detector: Example

TCL script (rpccli.tcl):

::cisco::eem::event_register_rpc

namespace import ::cisco::eem::*
namespace import ::cisco::lib::*

proc run_cli { clist } {
    set rbuf ""

    if {[llength $clist] < 1} {
    return -code ok $rbuf
    }

    if {[catch {cli_open} result]} {
        return -code error $result
    } else {
    array set cliarr $result
    }

    if {[catch {cli_exec $cliarr(fd) "enable"} result]} {
        return -code error $result
    }

    if {[catch {cli_exec $cliarr(fd) "term length 0"} result]} {
        return -code error $result
    }

    foreach cmd $clist {
    if {[catch {cli_exec $cliarr(fd) $cmd} result]} {
            return -code error $result
    }

    append rbuf $result
    }

    if {[catch {cli_close $cliarr(fd) $cliarr(tty_id)} result]} {
        puts "WARNING: $result"
    }

    return -code ok $rbuf
}

proc run_cli_interactive { clist } {
    set rbuf ""

    if {[llength $clist] < 1} {
    return -code ok $rbuf
    }

    if {[catch {cli_open} result]} {
        return -code error $result
    } else {
    array set cliarr $result
    }

    if {[catch {cli_exec $cliarr(fd) "enable"} result]} {
        return -code error $result
    }

    if {[catch {cli_exec $cliarr(fd) "term length 0"} result]} {
        return -code error $result
    }

    foreach cmd $clist {
        array set sendexp $cmd

    if {[catch {cli_write $cliarr(fd) $sendexp(send)} result]} {
            return -code error $result
    }

    foreach response $sendexp(responses) {
        array set resp $response

        if {[catch {cli_read_pattern $cliarr(fd) $resp(expect)} result]} {
                return -code error $result
        }

        if {[catch {cli_write $cliarr(fd) $resp(reply)} result]} {
                return -code error $result
        }
    }

    if {[catch {cli_read $cliarr(fd)} result]} {
            return -code error $result
    }

    append rbuf $result
    }

    if {[catch {cli_close $cliarr(fd) $cliarr(tty_id)} result]} {
        puts "WARNING: $result"
    }

    return -code ok $rbuf
}

array set arr_einfo [event_reqinfo]

set args $arr_einfo(argc)

set cmds [list]

for { set i 0 } { $i < $args } { incr i } {
    set arg "arg${i}"
    # Split each argument on the '^' character.  The first element is
    # the command, and each subsequent element is a prompt followed by
    # a response to that prompt.
    set cmdlist [split $arr_einfo($arg) "^"]
    set cmdarr(send) [lindex $cmdlist 0]
    set cmdarr(responses) [list]
    if { [expr ([llength $cmdlist] - 1) % 2] != 0 } {
    return -code 88
    }
    set cmdarr(responses) [list]
    for { set j 1 } { $j < [llength $cmdlist] } { incr j 2 } {
    set resps(expect) [lindex $cmdlist $j]
    set resps(reply) [lindex $cmdlist [expr $j + 1]]
    lappend cmdarr(responses) [array get resps]
    }
    lappend cmds [array get cmdarr]
}

set rc [catch {run_cli_interactive $cmds} output]

if { $rc != 0 } {
    error $output $errorInfo
    return -code 88
}

puts $output

Where to Go Next

For information about EEM overview, go to "Embedded Event Manager Overview" module.

For information about writing EEM policies using the Cisco IOS CLI, go to the "Writing Embedded Event Manager Policies Using the Cisco IOS CLI" module.

Additional References

The following sections provide references related to writing Embedded Event Manager policies using Tcl.

Related Documents

Related Topic
Document Title

Cisco IOS commands

Cisco IOS Master Commands List, All Releases

Network Management commands (including EEM commands): complete command syntax, defaults, command mode, command history, usage guidelines, and examples

Cisco IOS Network Management Command Reference

Embedded Event Manager overview

Embedded Event Manager Overview module.

Embedded Event Manager policy writing using the CLI

Writing Embedded Event Manager Policies Using the Cisco IOS CLI module

Embedded Resource Manager

Embedded Resource Manager module


MIBs

MIB
MIBs Link

CISCO-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:

http://www.cisco.com/go/mibs


RFCs

RFC
Title

No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.


Technical Assistance

Description
Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html


EEM Policy Tcl Command Extension Reference

This section documents the following EEM policy Tcl command extension categories:

EEM Event Registration Tcl Command Extensions

EEM Event Information Tcl Command Extension

EEM Event Tcl Command Extension

EEM Action Tcl Command Extensions

EEM Utility Tcl Command Extensions

EEM System Information Tcl Command Extensions

EEM Library Debug Command Extensions

SMTP Library Command Extensions

CLI Library Command Extensions

Tcl Context Library Command Extensions


Note For all EEM Tcl command extensions, if there is an error, the returned Tcl result string contains the error information.



Note Arguments for which no numeric range is specified take an integer from -2147483648 to 2147483647, inclusive.


The following conventions are used for the syntax documented on the Tcl command extension pages:

An optional argument is shown within square brackets, for example:

[type ?]

A question mark ? represents a variable to be entered.

Choices between arguments are represented by pipes, for example:

priority low|normal|high

EEM Event Registration Tcl Command Extensions

event_register_appl

event_register_cli

event_register_counter

event_register_gold

event_register_interface

event_register_ipsla

event_register_nf

event_register_ioswdsysmon

event_register_none

event_register_oir

event_register_process

event_register_resource

event_register_rf

event_register_routing

event_register_rpc

event_register_snmp

event_register_snmp_notification

event_register_snmp_object

event_register_syslog

event_register_timer

event_register_timer_subscriber

event_register_track

event_register_wdsysmon

event_register_appl

Registers for an application event. Use this Tcl command extension to run a policy when an application event is triggered following another policy's execution of an event_publish Tcl command extension; the event_publish command extension publishes an application event.

In order to register for an application event, a subsystem must be specified. Either a Tcl policy or the internal Embedded Event Manager (EEM) API can publish an application event. If the event is being published by a policy, the sub_system argument that is reserved for a policy is 798.

Syntax

event_register_appl [tag ?] sub_system ? type ? [queue_priority low|normal|high|last] 
[maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

sub_system

(Mandatory) Number assigned to the EEM policy that published the application event. The number is set to 798 because all other numbers are reserved for Cisco use. If this argument is not specified, all components are matched.

type

(Mandatory) Event subtype within the specified event. The sub_system and type arguments uniquely identify an application event. If this argument is not specified, all types are matched. If you specify this argument, you must choose an integer between 1 and 4294967295, inclusive.

There must be a match of component and type between the event_publish command extension and the event_register_appl command extension in order for the publishing and registration to work.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


If multiple conditions exist, the application event will be raised when all the conditions are satisfied.

Result String

None

Set _cerrno

No

event_register_cli

Registers for a CLI event. Use this Tcl command extension to run a policy when a CLI command of a specific pattern is entered based on pattern matching performed against an expanded CLI command.


Note The user can enter an abbreviated CLI command, such as sh mem summary, and the parser will expand the command to show memory summary to perform the matching.



Note The functionality provided in the CLI event detector only allows a regular expression pattern match on a valid IOS CLI command itself. This does not include text after a pipe character when redirection is used.


Syntax

event_register_cli [tag ?] sync yes|no skip yes|no 
[occurs ?] [period ?] pattern ? [default ?] [enter] [questionmark] [tab] [mode]
[queue_priority low|normal|high|last] [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

sync

(Mandatory) A "yes" means that the policy (the event publish) will run synchronously with the CLI command; a "no" means that the event publish will be performed asynchronously with the CLI command. The event detector will be notified when the policy completes running. The exit status of the policy indicates whether or not the CLI command should be executed: if the exit status is zero, which means that the policy is executed successfully, the CLI command will not be executed; otherwise, the CLI command will be executed.

skip

Mandatory if the sync argument is "no" and should not exist if the sync argument is "yes." If the skip argument is "yes," it means that the CLI command should not be executed. If the skip argument is "no," it means that the CLI command should be executed.


Caution When the skip argument is "yes," unintended results may be produced if the pattern match is made for configuration commands because the CLI command that matches the regular expression will not be executed.

occurs

(Optional) The number of occurrences before the event is raised. If this argument is not specified, the event is raised on the first occurrence. If this argument is specified, it must be an integer between 1 and 4294967295, inclusive.

period

(Optional) Specifies a backward looking time window in which all CLI events must occur (the occurs clause must be satisfied) in order for an event to be published (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the most recent event is used.

pattern

(Mandatory) Specifies the regular expression used to perform the CLI command pattern match.

default

(Optional) The time period during which the CLI event detector waits for the policy to exit (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If the default time period expires before the policy exits, the default action will be executed. The default action is to run the command. If this argument is not specified, the default time period is set to 30 seconds.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

enter

(Optional) Specifies to perform the event match when the user presses the Enter key. When this parameter is used, the input string will not be expanded before matching.

questionmark

(Optional) Specifies to perform the event match when the user presses the ? key. When this parameter is used, the input string will not be expanded before matching.

tab

(Optional) Specifies to perform the event match when the user presses the Tab key. When this parameter is used, the input string will not be expanded before matching.

mode

(Optional) Events will only be generated when the parser is in the specified parser mode. The available modes can be listed using the show parser dump CLI command. The mode parameter is checked when any one of the optional parameters—enter, questionmark, or tab— is specified.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


If multiple conditions are specified, the CLI event will be raised when all the conditions are matched.

Result String

None

Set _cerrno

No


Note This policy runs before the CLI command is executed. For example, suppose policy_CLI is registered to run when the copy command is entered. When the copy command is entered, the CLI event detector finds a pattern match and triggers this policy to run. When the policy execution ends, the CLI event detector determines if the copy command needs to be executed according to "sync", "skip" (set in the policy), and the exit status of the policy execution if needed.


event_register_counter

Registers for a counter event as both a publisher and a subscriber. Use this Tcl command extension to run a policy on the basis of a named counter crossing a threshold. This event counter, as a subscriber, identifies the name of the counter to which it wants to subscribe and depends on another policy or another process to actually manipulate the counter. For example, let policyB act as a counter policy, whereas policyA (although it does not need to be a counter policy) uses register_counter, counter_modify, or unregister_counter Tcl command extensions to manipulate the counter defined in policyB.

Syntax

event_register_counter [tag ?] name ? entry_op gt|ge|eq|ne|lt|le entry_val ? 
exit_op gt|ge|eq|ne|lt|le exit_val ? [queue_priority low|normal|high|last]  
[maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

name

(Mandatory) Name of the counter.

entry_op

(Mandatory) Entry comparison operator used to compare the current counter value with the entry value; if true, an event will be raised and event monitoring will be disabled until exit criteria are met.

entry_val

(Mandatory) Value with which the current counter value should be compared to decide if the counter event should be raised.

exit_op

(Mandatory) Exit comparison operator used to compare the current counter value with the exit value; if true, event monitoring for this event will be reenabled.

exit_val

(Mandatory) Value with which the current counter value should be compared to decide if the exit criteria are met.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_gold

Registers for a Generic Online Diagnostic (GOLD) failure event. Use this Tcl command extension to run a policy on the basis of a Generic Online Diagnostic (GOLD) failure event for the specified card and subcard.

Syntax

event_register_gold card all|card_number
[subcard all|subcard_number]
[new_failure TRUE|FALSE]
[severity_major TRUE]
[severity_minor TRUE]
[severity_normal TRUE]
[action_notify TRUE|FALSE]
[testing_type [bootup|ondemand|schedule|monitoring]] 
[test_name [testname]] 
[test_id [testnumber]] 
[consecutive_failure consecutive_failure_number]
[platform_action [action_flag]] 
[maxrun ?] 
[queue_priority low|normal|high|last] 
[nice 0|1]

Arguments

card

(Mandatory) Specifies whether all cards or one card is to be monitored:

card all—Specifies that all cards are to be monitored. This is the default.

card-number—Specifies that the card identified by the number card-number is to be monitored.

This argument must be specified to complete the event_register_gold Tcl command extension.

subcard

(Optional) Specifies that one or more subcards are to be monitored:

subcard all—Specifies that all subcards are to be monitored.

subcard-numberSpecifies that the subcard identified by the number subcard-number is to be monitored.

If this argument is not specified, all subcards are monitored by default.

new_failure

(Optional) Specifies event criteria based on the new test failure information from GOLD:

new_failure TRUE—Specifies that the event criterion for the new test failure is true from GOLD.

new_failure FALSE—Specifies that the event criterion for the new test failure is false from GOLD.

If this argument is not specified, the new test failure information from GOLD is not considered in the event criteria.

severity_major

(Optional) Specifies that the event criteria for diagnostic result matches with the diagnostic major error from GOLD.

severity_minor

(Optional) Specifies that the event criteria for diagnostic result matches with diagnostic minor error from GOLD.

severity_normal

(Optional) Specifies that the event criteria for diagnostic result matches with diagnostic normal from GOLD. This is the default.

action_notify

(Optional) Specifies the event criteria based on the action notify information from GOLD:

action_notify TRUE—Specifies that the event criterion for the action notify is true from GOLD.

action_notify FALSE—Specifies that the event criterion for the action notify is false from GOLD.

If this argument is not specified, the action notify information from GOLD is not considered in the event criteria.

testing_type

(Optional) Specifies the event criteria based on the testing types of the diagnostic from GOLD:

testing_type bootup—Specifies the diagnostic tests that are running on system bootup.

testing_type ondemand—Specifies the diagnostic tests that are running from CLI after the card is online.

testing_type schedule—Specifies the scheduled diagnostic tests.

testing_type monitoring—Specifies the diagnostic tests that are running periodically in the background to monitor the health of the system.

If this argument is not specified, the testing type information from GOLD is not considered in the event criteria and the policy applies to all the diagnostic testing types.

test_name

(Optional) Specifies the event criteria based on the test name:

test_name test-name—Specifies the event criteria based on the test with the name test-name.

If this argument is not specified, the test name information from GOLD is not considered in the event criteria.

test_id

(Optional) Specifies the event criteria based on test ID:

test_id test-idSpecifies the event criteria based on the test with the ID number test-id. The maximum value of test-id is 65535.

Note Because the test ID can be different for the same test on different line cards, usually the test_name keyword should be used instead. If the test ID is specified and conflicts with the specified test name, the test name overwrites the test ID.

If this argument is not specified, test ID information from GOLD is not considered in the event criteria.

consecutive_failure

(Optional) Specifies the event criteria based on consecutive test failure information from GOLD:

consecutive_failure consecutive-failure-number—Specifies that the event criterion is based on the occurrence of consecutive-failure-number consecutive test failures.

If this argument is not specified, consecutive test failure information from GOLD is not considered in the event criteria.

platform_action

(Optional) Specifies whether callback to the platform is needed when all the event criteria are matched. When callback is needed, the platform needs to register a callback function through the provided registry.

platform_action action-flag-numberSpecifies that, when callback to the platform is needed, specific information is specified by the platform-specific action-flag-number value. The maximum value of action-flag-number is 65535.

Note It is up to the platform to determine what action needs to be taken based on the flag.

If this argument is not specified, there is no callback.

maxrun

(Optional) Specifies the maximum runt time of the script.

maxrun max-run-time-number—Specifies that the maximum run time of the script is max-run-time-number seconds. The maximum value of max-run-time-number is 4294967295 seconds.

If this argument is not specified, the default run time is 20 seconds.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

nice

(Optional) Policy run-time priority setting:

nice 0—Specifies that the policy is run at the default run-time priority level.

nice 1—Specifies that the policy is run at a run-time priority that is less than the default priority.

If this argument is not specified, the default run-time priority is used.


Result String

None

Set _cerrno

No

event_register_interface

Registers for an interface counter event. Use this Tcl command extension to generate an event when specified interface counters exceed specified thresholds.

Syntax

event_register_interface [tag ?] name ?
parameter ? entry_op gt|ge|eq|ne|lt|le
entry_val ? entry_val_is_increment TRUE|FALSE
entry_type value|increment|rate
[exit_comb or|and]
[exit_op gt|ge|eq|ne|lt|le]
[exit_val ?] [exit_val_is_increment TRUE|FALSE]
[exit_type value|increment|rate]
[exit_time ?] [poll_interval ?]
[average_factor ?] [queue_priority low|normal|high|last]
[maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

name

(Mandatory) The name of the interface being monitored, for example, Ethernet 0/0. Abbreviations and spaces are not allowed.

parameter

(Mandatory) The name of the counter being compared as follows:

input_errors—Includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also cause the input errors count to be increased, and some datagrams may have more than one error; therefore, this sum may not balance with the sum of enumerated input error counts.

input_errors_crc—Cyclic redundancy checksum generated by the originating LAN station or far-end device does not match the checksum calculated from the data received.

input_errors_frame—Number of packets received incorrectly having 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 that 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.

parameter (continued)

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 enumerated output errors, because some datagrams may have more than one error, and others 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 that 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/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/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/255 is 100 percent).

entry_op

(Mandatory) The comparison operator used to compare the current interface value with the entry value; if true, an event will be raised and event monitoring will be disabled until exit criteria are met.

entry_val

(Mandatory) The value at which the event will be triggered.

entry_val_is_increment

(Mandatory) If TRUE, the entry_val field is treated as an incremental difference and is compared with the difference between the current counter value and the value when the event was last true (the first polled sample if this is a new event). A negative value checks the incremental difference for a counter that is decreasing. If FALSE, the entry_val field is compared against the current counter value.

Note In Cisco IOS Release 12.4(20)T, this keyword is deprecated, and if specified, the syntax is converted into equivalent entry-type keyword syntax.

entry-type

Specifies a type of operation to be applied to the object ID specified by the entry-val argument.

Value is defined as the actual value of the entry-val argument.

Increment uses the entry-val field as an incremental difference and the entry-val is compared with the difference between the current counter value and the value when the event was last triggered (or the first polled sample if this is a new event). A negative value checks the incremental difference for a counter that is decreasing.

Rate is defined as the average rate of change over a period of time. The time period is the average-factor value multiplied by the poll-interval value. At each poll interval the difference between the current sample and the previous sample is taken and recorded as an absolute value. An average of the previous average-factor value samples is taken to be the rate of change.

exit_comb

(Optional) Used to indicate the combination of exit condition tests required to rearm the event trigger; if the and operator is specified, both exit value and exit time tests must be true to cause rearm; if the or operator is specified, either exit value or exit time tests can be true to cause event monitoring to be rearmed.

exit_op

(Optional) The comparison operator used to compare the current interface value with the exit value; if true, event monitoring for this event will be reenabled.

exit_val

(Optional) The value at which the event is rearmed to be monitored again.

exit_val_is_increment

(Optional) If TRUE, the exit_val field is treated as an incremental difference and is compared with the difference between the current counter value and the value when the event was last true. A negative value checks the incremental difference for a counter that is decreasing. If FALSE, the exit_val field is compared against the current counter value.

Note In Cisco IOS Release 12.4(20)T, this keyword is deprecated, and if specified, the syntax is converted into equivalent exit-type keyword syntax.

exit-type

(Optional) Specifies a type of operation to be applied to the object ID specified by the exit-val argument. If not specified, the value is assumed.

Value is defined as the actual value of the exit-val argument.

Increment uses the exit-val field as an incremental difference and the exit-val is compared with the difference between the current counter value and the value when the event was last triggered (or the first polled sample if this is a new event). A negative value checks the incremental difference for a counter that is decreasing.

Rate is defined as the average rate of change over a period of time. The time period is the average-factor value multiplied by the poll-interval value. At each poll interval the difference between the current sample and the previous sample is taken and recorded as an absolute value. An average of the previous average-factor value samples is taken to be the rate of change.

exit_time

(Optional) The time period at which the event is rearmed to be monitored again (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999).

poll_interval

(Optional) The frequency used to collect the samples (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 60 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). The poll interval value must not be less than 1 second. The default is 1 second.

average-factor

(Optional) Number in the range from 1 to 64 used to calculate the period used for rate-based calculations. The average-factor value is multiplied by the poll-interval value to derive the period in milliseconds. The minimum average factor value is 1.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_ioswdsysmon

Registers for an IOSWDSysMon event. Use this Tcl command extension to generate an event when a Cisco IOS task exceeds specific CPU utilization or memory thresholds. A Cisco IOS task is called a Cisco IOS process in native Cisco IOS.

Syntax

event_register_ioswdsysmon [tag ?] [timewin ?] [sub12op and|or] [sub1 ?] [sub2 ?]  
[queue_priority low|normal|high|last] [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

timewin

(Optional) Defines the time window within which all of the subevents must occur in order for an event to be generated (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999).

sub12_op

(Optional) The combination operator for comparison between subevent 1 and subevent 2.

sub1

(Optional) The subevent 1 specification.

sub2

(Optional) The subevent 2 specification.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Subevent Syntax

cpu_proc path ? taskname ? op gt|ge|eq|ne|lt|le val ? [period ?]

mem_proc path ? taskname ? op gt|ge|eq|ne|lt|le val ? [is_percent TRUE|FALSE] [period ?]

Subevent Arguments

cpu_proc

(Mandatory) Specifies the use of a sample collection of CPU statistics.

path

(Mandatory) Software Modularity images only. The pathname of the POSIX process that contains the Cisco IOS scheduler to be monitored. For example, /sbin/cdp2.iosproc.

taskname

(Mandatory) The name of the Cisco IOS task to be monitored.

op

(Mandatory) The comparison operator used to compare the collected usage sample with the specified value; if true, an event will be raised.

val

(Mandatory) The value to be compared.

period

(Optional) The elapsed time period for the collection samples to be averaged (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the most recent sample is used.

mem_proc

(Mandatory) Specifies the use of a sample collection of memory statistics.

is_percent

(Optional) Whether the specified value is a percentage.


Result String

None

Set _cerrno

No

event_register_ipsla

Registers for an event that is triggered by the event ipsla command. Use this Tcl command to publish an event when an IPSLA reaction is triggered. The group ID or the operation ID is required to register the event.

Syntax

event_register_ipsla [tag ?] group_name ? operation_id ? [reaction_type ?]  
[dest_ip_addr ?][queue_priority low|normal|high|last] [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

group_name

(Mandatory) Specifies the IP SLAs group name.

operation_id

(Mandatory) Specifies the IP SLA operation ID. Number must be in the range from 1 to 2147483647.

reaction_type

(Optional) Specifies the reaction to be taken for the specified IP SLAs operation.

Type of IP SLAs reaction—One of the following keywords can be specified: connectionLoss, icpif, jitterAvg, jitterDSAvg, jitterSDAvg, maxOfNegativeDS, maxOfNegativeSD, maxOfPositiveDS, maxOfPositiveSD, mos, packetLateArrival, packetLossDS, packetLossSD, packetMIA, packetOutOfSequence, rtt, timeout or verifyError can be specified.

Type of IP SLAs reaction. One of the following keywords can be specified:

connectionLoss

icpif

jitterAvg

jitterDSAvg

jitterSDAvg

maxOfNegativeDS

maxOfNegativeSD

maxOfPositiveDS

maxOfPositiveSD

mos

packetLateArrival

packetLossDS

packetLossSD

packetMIA

packetOutOfSequence

rtt

timeout

verifyError

dest_ip_address

(Optional) Specifies the destination IP address of the destination port for which the IP SLAs events are monitored.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 31536000, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_nf

Registers for an event when a NetFlow event is triggered by the event nf command. Use this Tcl command to publish an event when an NetFlow reaction is triggered..

Syntax

event_register_nf [tag ?] monitor_name ? event_type create|update|delete  
exit_event_type create|update|delete event1-event4 ? [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

monitor_name

(Mandatory) The name of the NetFlow monitor.

event_type

(Mandatory) The type of event to monitor for the create, update, and delete flow.

exit_event_type

(Mandatory) The event-type (create, delete, update) at which the event is rearmed to be monitored again.

event1- event4

(Mandatory) Specifies the event and its attributes to monitor. Valid values are event1, event2, event3, and event4.

The subevent keywords can be used alone, together, or in any combination with each other, but each keyword can be used only once.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Subevent Syntax

field ? rate_interval ? event1 only entry_value ? entry_op eq|ge|gt|le|lt|wc  
[exit_value ?] [exit_op eq|ge|gt|le|lt|wc] [exit_rate_interval ? event1 only]

Subevent Arguments

field

(Mandatory) Specifies the cache or field attribute to be monitored. One of the following attributes can be specified:

counter {bytes | packets}—Specifies the counter fields.

datalink {dot1q | mac}—Specifies the datalink (layer2) fields.

flow {direction | sampler}—Specifies the flow identifying fields.

interface {input | output}—Specifies the interface fields.

ipv4 field-type—Specifies the IPv4 fields.

ipv6 field-type—IPv6 fields

routing routing-attrributeSpecifies the routing attributes.

timestamp sysuptime {first | last}Specifies the timestamp fields.

transport field-type—Specifies the Transport layer fields.

rate_interval

(Mandatory) Specifies the rate interval value in seconds used to calculate the rate. This field is only valid for event1.

entry_value

(Mandatory) Specifies the field or rate value.

entry_op

(Mandatory) Specifies the field operator.

The comparison operator valid values are:

eq - Equal to

ge - Greater than or equal to

gt - Greater than

le - Less than or equal to

lt - Less than

wc - Wildcard

exit_value

(Optional) The value at which the event is rearmed to be monitored again.

exit_op

(Optional) The comparison operator used to compare the current event field or rate value with the exit value; if true, event monitoring for this event is reenabled.

The comparison operator valid values are:

eq - Equal to

ge - Greater than or equal to

gt - Greater than

le - Less than or equal to

lt - Less than

wc - Wildcard

exit_rate_interval

(Optional) Specifies the exit rate interval value in seconds used to calculate the exit rate value. This field is only valid for event1.


Result String

None

Set _cerrno

No

event_register_none

Registers for an event that is triggered by the event manager run command. These events are handled by the None event detector that screens for this event.

Syntax

event_register_none [tag ?] [queue_priority low|normal|high|last] [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_oir

Registers for an online insertion and removal (OIR) event. Use this Tcl command extension to run a policy on the basis of an event raised when a hardware card OIR occurs. These events are handled by the OIR event detector that screens for this event.

Syntax

event_register_oir [tag ?] [queue_priority low|normal|high|last] [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_process

Registers for a process event. Use this Tcl command extension to run a policy on the basis of an event raised when a Cisco IOS Software Modularity process starts or stops. These events are handled by the System Manager event detector that screens for this event. This Tcl command extension is supported only in Software Modularity images.

Syntax

event_register_process [tag ?] abort|term|start|user_restart|user_shutdown 
[sub_system ?] [version ?] [instance ?] [path ?] [node ?]
[queue_priority low|normal|high|last] [maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

abort

(Mandatory) Abnormal process termination. Process may abort because of exiting with a nonzero exit status, receiving a kernel-generated signal, or receiving a SIGTERM or SIGKILL signal that is not sent because of user request.

term

(Mandatory) Normal process termination.

start

(Mandatory) Process start.

user_restart

(Mandatory) Process termination due to the process restart request from the CLI command.

user_shutdown

(Mandatory) Process termination due to the process kill request from the CLI command.

sub_system

(Optional) Number assigned to the EEM policy that published the process event. Number is set to 798 because all other numbers are reserved for Cisco use.

version

(Optional) Version number of the process assigned by the version manager. Must be of the form major_number.minor_number.level. If specified, each component of the version number must be an integer between 1 and 4294967295, inclusive.

instance

(Optional) Process instance ID. If specified, this argument must be an integer between 1 and 4294967295, inclusive.

path

(Optional) Process pathname (a regular expression string). If the value of the process-name argument contains embedded blanks, enclose it in double quotation marks. Use path ".*" to match all processes.

node

(Optional) The node name is a string that consists of the word "node" followed by two fields separated by a slash character using the following format:

node<slot-number>/<cpu-number>

The slot-number is the hardware slot number. The cpu-number is the hardware CPU number. For example, the SP CPU in a Supervisor card on a Cisco Catalyst 6500 series switch located in slot 0 would be specified as node0/0. The RP CPU in a Supervisor card on a Cisco Catalyst 6500 series switch located in slot 0 would be addressed as node0/1. If the node argument is not specified, the default node specification is always the regular expression pattern match of * representing all applicable nodes.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


If an optional argument is not specified, the event matches all possible values of the argument. If multiple arguments are specified, the process event will be raised when all the conditions are matched.

Result String

None

Set _cerrno

No

event_register_resource

Registers for an Embedded Resource Manager (ERM) event. Use this Tcl command extension to run a policy on the basis of an ERM event report for a specified policy. ERM events are screened by the EEM Resource event detector, allowing an EEM policy to be run when a match occurs for the specified ERM policy.

Syntax

event_register_resource policy policy-name [queue_priority low|normal|high|last] 
[maxrun ?] [nice 0|1]

Arguments

policy

(Mandatory) Specifies the use of a policy.

policy-name

(Mandatory) Name of an ERM policy.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_rf

Registers for a Redundancy Facility (RF) event. Use this Tcl command extension to run a policy when an RF progression or status event notification occurs.

Syntax

event_register_rf [tag ?] event ?
[queue_priority low|normal|high|last]
[maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

event

(Mandatory) Name of the RF progression or status event. Valid values are:

RF_PROG_ACTIVE

RF_PROG_ACTIVE_DRAIN

RF_PROG_ACTIVE_FAST = 200

RF_PROG_ACTIVE_PRECONFIG

RF_PROG_ACTIVE_POSTCONFIG

RF_PROG_EXTRALOAD

RF_PROG_HANDBACK

RF_PROG_INITIALIZATION

RF_PROG_PLATFORM_SYNC

RF_PROG_STANDBY_BULK

RF_PROG_STANDBY_COLD

RF_PROG_STANDBY_CONFIG

RF_PROG_STANDBY_FILESYS

RF_PROG_STANDBY_HOT

RF_PROG_STANDBY_OIR_SYNC_DONE

RF_REGISTRATION_STATUS

RF_STATUS_MAINTENANCE_ENABLE

RF_STATUS_MANUAL_SWACT

RF_STATUS_OPER_REDUNDANCY_MODE_CHANGE

RF_STATUS_PEER_COMM

RF_STATUS_PEER_PRESENCE

RF_STATUS_REDUNDANCY_MODE_CHANGE

RF_STATUS_SWACT_INHIBIT

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_routing

Registers for an event that is triggered by the event routing command. These events are handled by the routing event detector to publish an event when route entries change in Routing Information Base (RIB) infrastructure. Use this Tcl command extension to run a routing policy for this script. The network IP address for the route to be monitored must be specified.

Syntax

event_register_routing [tag ?] network ? length [ge|le|ne] [type add|remove|modify|all] 
[protocol ?] [queue_priority normal|low|high|last] [maxrun ?] [nice {0 | 1}] 

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

network

Specifies the network IP address. The network number can be any valid IP address or prefix.

length

Specifies the length of the network mask in bits. The bit mask can be a number from 0 to 32.

ge—(Optional) Specifies the minimum prefix length to be matched. The ge keyword represents greater than or equal to operator.

le—(Optional) Specifies the maximum prefix length to be matched. The le keyword represents the less than or equal to operator.

ne—(Optional) Specifies the prefix length not to be matched. The ne keyword represents not equal to operator.

When ge, le and ne keywords are not configured, an exact match of network length is processed.

type

(Optional) Specifies the desired policy trigger. The type options are add, remove, modify, and all. The default is all.

protocol

(Optional) Specifies the protocol value for the network being monitored.

One of the following protocols can be used: all, bgp, connected, eigrp, isis, iso-igrp, mobile, odr, ospf, rip, and static. The default is all.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_rpc

Registers for an event that is triggered by the EEM SSH Remote Procedure Call (RPC) command. These events are handled by the RPC event detector that screens for this event. Use this Tcl command extension to run a RPC policy for this script.

Syntax

event_register_rpc [queue_priority {normal | low | high | last}] [maxrun <sec.msec>] [nice 
{0 | 1}] [default <sec.msec>]

Arguments

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.

default

(Optional) The time period during which the CLI event detector waits for the policy to exit (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If the default time period expires before the policy exits, the default action will be executed. The default action is to run the command. If this argument is not specified, the default time period is set to 30 seconds.


Result String

None

Set _cerrno

No

event_register_snmp

Registers for a Simple Network Management Protocol (SNMP) statistics event. Use this Tcl command extension to run a policy when a given counter specified by an SNMP object ID (oid) crosses a defined threshold.

Syntax

event_register_snmp [tag ?] oid ? get_type exact|next
entry_op gt|ge|eq|ne|lt|le entry_val ?
entry_type value|increment|rate
[exit_comb or|and]
[exit_op gt|ge|eq|ne|lt|le] [exit_val ?]
[exit_type value|increment|rate]
[exit_time ?] poll_interval ? [average_factor ?]
[queue_priority low|normal|high|last]
[maxrun ?] [nice 0|1]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

oid

(Mandatory) OID number of data element in SNMP dot notation (for example, 1.3.6.1.2.1.2.1.0). The types of OIDs allowed are:

COUNTER_TYPE

COUNTER_64_TYPE

GAUGE_TYPE

INTEGER_TYPE

OCTET_PRIM_TYPE

OPAQUE_PRIM_TYPE

TIME_TICKS_TYPE

entry_op

(Mandatory) Entry comparison operator used to compare the current OID data value with the entry value; if true, an event will be raised and event monitoring will be disabled until exit criteria are met.

get_type

(Mandatory) Type of SNMP get operation that needs to be applied to the OID specified. If the get_type argument is "exact," the value of the specified OID is retrieved; if the get_type argument is "next," the value of the lexicographical successor to the specified OID is retrieved.

entry_val

(Mandatory) Value with which the current oid data value should be compared to decide if the SNMP event should be raised.

entry-type

Specifies a type of operation to be applied to the object ID specified by the entry-val argument.

Value is defined as the actual value of the entry-val argument.

Increment uses the entry-val field as an incremental difference and the entry-val is compared with the difference between the current counter value and the value when the event was last triggered (or the first polled sample if this is a new event). A negative value checks the incremental difference for a counter that is decreasing.

Rate is defined as the average rate of change over a period of time. The time period is the average-factor value multiplied by the poll-interval value. At each poll interval the difference between the current sample and the previous sample is taken and recorded as an absolute value. An average of the previous average-factor value samples is taken to be the rate of change.

exit_comb

(Optional) Exit combination operator used to indicate the combination of exit condition tests required to decide if the exit criteria are met so that the event monitoring can be reenabled. If it is "and," both exit value and exit time tests must be passed to meet the exit criteria. If it is "or," either exit value or exit time tests can be passed to meet the exit criteria.

When exit_comb is "and," exit_op, and exit_val (exit_time) must exist.
When exit_comb is "or," (exit_op and exit_val) or (exit_time) must exist.

exit_op

(Optional) Exit comparison operator used to compare the current oid data value with the exit value; if true, event monitoring for this event will be reenabled.

exit_val

(Optional) Value with which the current oid data value should be compared to decide if the exit criteria are met.

exit-type

(Optional) Specifies a type of operation to be applied to the object ID specified by the exit-val argument. If not specified, the value is assumed.

Value is defined as the actual value of the exit-val argument.

Increment uses the exit-val field as an incremental difference and the exit-val is compared with the difference between the current counter value and the value when the event was last triggered (or the first polled sample if this is a new event). A negative value checks the incremental difference for a counter that is decreasing.

Rate is defined as the average rate of change over a period of time. The time period is the average-factor value multiplied by the poll-interval value. At each poll interval the difference between the current sample and the previous sample is taken and recorded as an absolute value. An average of the previous average-factor value samples is taken to be the rate of change.

exit_time

(Optional) Number of POSIX timer units after an event is raised when event monitoring will be enabled again. Specified in SSSSSSSSSS[.MMM] format where SSSSSSSSSS must be an integer number representing seconds between 0 and 4294967295, inclusive. MMM represents milliseconds and must be an integer number between 0 and 999.

poll_interval

(Mandatory) Interval between consecutive polls in POSIX timer units. Currently the interval is forced to be at least 1 second (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999).

average-factor

(Optional) Number in the range from 1 to 64 used to calculate the period used for rate-based calculations. The average-factor value is multiplied by the poll-interval value to derive the period in milliseconds. The minimum average factor value is 1.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the "queue_priority_last" argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

maxrun

(Optional) Maximum run time of the script (specified in SSSSSSSSSS[.MMM] format, where SSSSSSSSSS must be an integer representing seconds between 0 and 4294967295, inclusive, and where MMM must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.


Result String

None

Set _cerrno

No

event_register_snmp_notification

Registers for a Simple Network Management Protocol (SNMP) notification trap event. Use this Tcl command extension to run a policy when an SNMP trap with the specified SNMP object ID (oid) is encountered on a specific interface or address. The snmp-server manager CLI command must be enabled for the SNMP notifications to work using Tcl policies.

Syntax

event_register_snmp_notification [tag ?] oid ? oid_val ?
op {gt|ge|eq|ne|lt|le}
[maxrun ?]
[src_ip_address ?] 
[dest_ip_address ?]
[queue_priority {normal|low|high|last}]
[maxrun ?]
[nice {0|1}]
[default ?]
[direction {incoming|outgoing}]
[msg_op {drop|send}]

Arguments

tag

(Optional) String identifying a tag that can be used with the trigger Tcl command extension to support multiple event statements within a Tcl script.

oid

(Mandatory) OID number of the data element in SNMP dot notation (for example, 1.3.6.1.2.1.2.1.0). If the specified OID ends with a dot (.), then all OIDs that start with the OID number before the dot are matched. The types of OIDs allowed are:

COUNTER_TYPE

COUNTER_64_TYPE

GAUGE_TYPE

INTEGER_TYPE

OCTET_PRIM_TYPE

OPAQUE_PRIM_TYPE

TIME_TICKS_TYPE

oid_val

(Mandatory) OID value with which the current OID data value should be compared to decide if the SNMP event should be raised.

op

(Mandatory) Comparison operator used to compare the current OID data value with the SNMP Protocol Data Unit (PDU) OID data value; if this is true, an event is raised.

maxrun

(Optional) Maximum run time of the script (specified in ssssssss[.mmm] format, where ssssssss must be an integer representing seconds between 0 and 31536000, inclusive, and where mmm must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

src_ip_address

(Optional) Source IP address where the SNMP notification trap originates. The default is all; it is set to receive SNMP notification traps from all IP addresses.

dest_ip_address

(Optional) Destination IP address where the SNMP notification trap is sent. The default is all; it is set to receive SNMP traps from all destination IP addresses.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.

queue_priority last—Specifies that the script is to be queued at the lowest priority level.

If more than one script is registered with the queue_priority_last argument set, these scripts will execute in the order in which the events are published.

Note The queue_priority argument specifies the queuing priority, but not the execution priority, of the script being registered.

If this argument is not specified, the default queuing priority is normal.

default

(Optional) Specifies the time period in seconds during which the snmp notification event detector waits for the policy to exit. The time period is specified in ssssssssss[.mmm] format, where ssssssssss must be an integer representing seconds between 0 and 4294967295 and mmm must be an integer representing milliseconds between 0 and 999.

nice

(Optional) Policy run-time priority setting. When the nice argument is set to 1, the policy is run at a run-time priority that is less than the default priority. The default value is 0.

direction

(Optional) The direction of the incoming or outgoing SNMP trap or inform PDU to filter. The default value is incoming.

msg_op

(Optional) The action to be taken on the SNMP PDU (drop it or send it) once the event is triggered. The default value is send.


Result String

None

Set _cerrno

No

event_register_snmp_object

Registers for a Simple Network Management Protocol (SNMP) object event. Use this Tcl command extension to replace the value when an SNMP with the specified SNMP-object ID (OID) is encountered on a specific interface or address.

Syntax

event_register_snmp_object oid ? 
type {int|unit|counter|gauge|ipv4|octect|string}
sync {yes|no}
skip {yes|no}
[istable {yes|no}]
[default ?]
[queue_priority {normal|low|high|last}]
[maxrun ?]
[nice {0|1}]

Arguments

oid

(Mandatory) OID number of the data element in SNMP dot notation (for example, 1.3.6.1.2.1.2.1.0). If the specified OID ends with a dot (.), then all OIDs that start with the OID number before the dot are matched. The types of OIDs allowed are:

COUNTER_TYPE

COUNTER_64_TYPE

GAUGE_TYPE

INTEGER_TYPE

OCTET_PRIM_TYPE

OPAQUE_PRIM_TYPE

TIME_TICKS_TYPE

type

(Mandatory) OID value type.

sync

(Mandatory) A "yes" means that the EEM policy will be notified. If the applet set_exit_status or Tcl return value is 0, then SNMP will handle the request. If the return value is 1, SNMP will use the value provided by the policy for the get request and will not process the set request. A "no" means that EEM will not be notified and SNMP will handle the request.

Only one OID can be associated with a synchronous policy. However, multiple synchronous policies can be registered for the same OID.

skip

Mandatory if the sync argument is "no" and should not exist if the sync argument is "yes." If the skip argument is "yes," it means that SNMP will handle the request. If the skip argument is "no," it means that SNMP will act as if the object does not exist.

istable

(Optional) A value of "no" means the OID is scalar object, and "yes" means the OID is table object.

default

(Optional) The time period during which the SNMP Object event detector waits for the policy to exit (specified in ssssssssss[.mmm] format, where ssssssssss must be an integer representing seconds between 0 and 4294967295, inclusive, and where mmm must be an integer representing milliseconds between 0 and 999). If the default time period expires before the policy exits, the default action will be executed. The default action is to process the set or get request normally by SNMP subsystem. If this argument is not specified, the default time period is set to 30 seconds.

maxrun

(Optional) Maximum run time of the script (specified in ssssssss[.mmm] format, where ssssssss must be an integer representing seconds between 0 and 31536000, inclusive, and where mmm must be an integer representing milliseconds between 0 and 999). If this argument is not specified, the default 20-second run-time limit is used.

queue_priority

(Optional) Priority level at which the script will be queued:

queue_priority low—Specifies that the script is to be queued at the lowest of the three priority levels.

queue_priority normal—Specifies that the script is to be queued at a priority level greater than low priority but less than high priority.

queue_priority high—Specifies that the script is to be queued at the highest of the three priority levels.