-
Cisco IOS Network Management Configuration Guide, Release 12.2SR
- Basic System Management
- System Monitoring and Logging
- Troubleshooting and Fault Management
- Cisco IOS Scripting with Tcl
- CNS
- Distributed Director Configuration
- Embedded Event Manager (EEM)
- Embedded Resource Manager (ERM)
- Embedded Syslog Manager (ESM)
- HTTP Services
- RMON Support
- SNMP Support
- SNMP MIB
- VPN Device Manager for XSM
- XML-PI
Table Of Contents
Writing Embedded Event Manager Policies Using the Cisco IOS CLI
Prerequisites for Writing EEM Policies Using the Cisco IOS CLI
Information About Writing EEM Policies Using the Cisco IOS CLI
Embedded Event Manager Policies
Embedded Event Manager Built-In Environment Variables Used in EEM Applets
How to Write EEM Policies Using the Cisco IOS CLI
Registering and Defining an Embedded Event Manager Applet
Alphabetical Order of EEM Action Labels
Registering and Defining an Embedded Event Manager Policy to Run Manually
Unregistering Embedded Event Manager Policies
Suspending All Embedded Event Manager Policy Execution
Configuring and Tracking a Stub Object Using Embedded Event Manager
Displaying Embedded Event Manager History Data
Displaying Embedded Event Manager Registered Policies
Configuring Event SNMP Notification
Configuring Multiple Event Support
Setting the Event Configuration Parameters
Configuring EEM Class-Based Scheduling
Holding a Scheduled EEM Policy Event or Event Queue
Resuming Execution of EEM Policy Events or Event Queues
Clearing Pending EEM Policy Events or Event Queues
Modifying the Scheduling Parameters of EEM Policy Events or Event Queues
Verifying Class-Based Scheduled Activities of EEM Policies
Verifying Class-Based Active EEM Policies
Verifying Pending EEM Policies
Configring EEM Applet (Interactive CLI) Support
Reading and Writing Input from the Active Console for Synchronous EEM Applets
Configuring SNMP Library Extensions
SNMP Traps and Inform Requests
How to Configure SNMP Library Extensions
Configuring EEM Applet for SNMP OID Notifications
Configuring Variable Logic for EEM Applets
Configuring Variable Logic for EEM Applets
Specifying a Loop of Conditional Blocks
Specifying if else Conditional Blocks
Specifying foreach Iterating Statements
Incrementing the Values of Variables
Configuring Description of an Embedded Event Manager Applet
Configuration Examples for Writing EEM Policies Using the Cisco IOS CLI
Embedded Event Manager Applet Configuration: Examples
Embedded Event Manager Manual Policy Execution: Examples
Configuring and Tracking a Stub Object Using Embedded Event Manager: Example
Embedded Event Manager Watchdog System Monitor (Cisco IOS) Event Detector Configuration: Example
Configuration SNMP Library Extensions: Examples
SNMP GetID Operations: Examples
Generating SNMP Notifications: Examples
Configuring Variable Logic for EEM Applets: Examples
Configuring Event SNMP-Object: Examples
Configuring Description of an EEM Applet: Examples
Feature Information for Writing EEM Policies Using the Cisco IOS CLI
Writing Embedded Event Manager Policies Using the Cisco IOS CLI
First Published: October 31, 2005Last Updated: Novemeber 20, 2009This module describes how to write Embedded Event Manager (EEM) policies using Cisco IOS command-line interface (CLI) applets to handle Cisco IOS software faults and events. EEM is a distributed and customized approach to event detection and recovery offered directly in a Cisco IOS device. EEM offers the ability to monitor events and take informational, corrective, or any desired action when the monitored events occur or when a threshold is reached. The EEM policy engine receives notifications when faults and other events occur. EEM policies implement recovery on the basis of the current state of the system and the actions specified in the policy for a given event. Recovery actions are triggered when the policy is run.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for Writing EEM Policies Using the Cisco IOS CLI" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for Writing EEM Policies Using the Cisco IOS CLI
•
•
•
•
Prerequisites for Writing EEM Policies Using the Cisco IOS CLI
•
•
•
•
Information About Writing EEM Policies Using the Cisco IOS CLI
To write EEM policies using the Cisco IOS CLI, you should understand the following concepts:
•
•
•
Embedded Event Manager Policies
EEM offers the ability to monitor events and take informational or corrective action when the monitored events occur or a threshold is reached. An EEM policy is an entity that defines an event and the actions to be taken when that event occurs. There are two types of EEM policies: an applet or a script. An applet is a simple form of policy that is defined within the CLI configuration. A script is a form of policy that is written in Tool Command Language (Tcl).
EEM Applet
An EEM applet is a concise method for defining event screening criteria and the actions to be taken when that event occurs. In applet configuration mode, three types of configuration statements are supported. The event commands are used to specify the event criteria to trigger the applet to run, the action commands are used to specify an action to perform when the EEM applet is triggered, and the set command is used to set the value of an EEM applet variable. Currently only the _exit_status variable is supported for the set command.
Only one event configuration command is allowed within an applet configuration. When applet configuration mode is exited and no event command is present, a warning is displayed stating that no event is associated with this applet. If no event is specified, this applet is not considered registered. When no action is associated with this applet, events are still triggered but no actions are performed. Multiple action configuration commands are allowed within an applet configuration. Use the show event manager policy registered command to display a list of registered applets.
Before modifying an EEM applet, be aware that the existing applet is not replaced until you exit applet configuration mode. While you are in applet configuration mode modifying the applet, the existing applet may be executing. It is safe to modify the applet without unregistering it. When you exit applet configuration mode, the old applet is unregistered and the new version is registered.
The action configuration commands are uniquely identified using the label argument, which can be any string value. Actions are sorted in ascending alphanumeric key sequence using the label argument as the sort key, and they are run using this sequence.
The Embedded Event Manager schedules and runs policies on the basis of an event specification that is contained within the policy itself. When applet configuration mode is exited, EEM examines the event and action commands that are entered and registers the applet to be run when a specified event occurs.
EEM Script
Scripts are defined off the networking device using an ASCII editor. The script is then copied to the networking device and registered with EEM. Tcl scripts are supported by EEM.
EEM allows you to write and implement your own policies using Tcl. Writing an EEM policy involves:
•
•
•
Cisco provides enhancements to Tcl in the form of keyword extensions that facilitate the development of EEM policies. The main categories of keywords identify the detected event, the subsequent action, utility information, counter values, and system information. For more details about writing EEM policies using Tcl, see the "Writing Embedded Event Manager Policies Using Tcl" module.
Embedded Event Manager Built-In Environment Variables Used in EEM Applets
EEM built-in environment variables are a subset of the Cisco-defined environment variables and the built-in variables are available to EEM applets only. The built-in variables can be read-only or can be read and write and these variables may apply to one specific event detector or to all event detectors. Table 1 lists the Cisco built-in environment variables that are read-only alphabetically by event detector and subevent.
How to Write EEM Policies Using the Cisco IOS CLI
This section contains the following tasks:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Registering and Defining an Embedded Event Manager Applet
Perform this task to register an applet with Embedded Event Manager and to define the EEM applet using the Cisco IOS CLI event and action commands. Only one event command is allowed in an EEM applet. Multiple action commands are permitted. If no event and no action commands are specified, the applet is removed when you exit configuration mode.
The SNMP event detector and the syslog action commands used in this task are just representing any event detector and action commands. For examples using other event detectors and action commands, see the "Embedded Event Manager Applet Configuration: Examples" section.
EEM Environment Variables
EEM environment variables for EEM policies are defined using the EEM event manager environment configuration command. By convention, all Cisco EEM environment variables begin with "_". In order to avoid future conflict, customers are urged not to define new variables that start with "_".
You can display the EEM environment variables set on your system by using the show event manager environment privileged EXEC command.
For example, you can create EEM policies that can send e-mails when an event occurs. Table 2 describes the e-mail-specific environment variables that can be used in EEM policies.
Alphabetical Order of EEM Action Labels
An EEM action label is a unique identifier that can be any string value. Actions are sorted and run in ascending alphanumeric (lexicographical) key sequence using the label as the sort key. If you are using numbers as labels be aware that alphanumerical sorting will sort 10.0 after 1.0, but before 2.0, and in this situation we recommend that you use numbers such as 01.0, 02.0, and so on, or use an initial letter followed by numbers.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
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.
•
•
Step 3
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 4
event manager environment variable-name string
Example:Router(config)# event manager environment _email_to engineering@example.com
Configures the value of the specified EEM environment variable.
•
Step 5
Repeat Step 4 for all the required environment variables.
Repeat Step 4 to configure all the environment variables required by the policy to be registered in Step 6.
Step 6
event manager applet applet-name
Example:Router(config)# event manager applet memory-fail
Registers the applet with the Embedded Event Manager (EEM) and enters applet configuration mode.
Step 7
event snmp oid oid-value get-type {exact | next} entry-op operator entry-val entry-value [exit-comb {or | and}] [exit-op operator] [exit-val exit-value] [exit-time exit-time-value] poll-interval poll-int-value
Example:Router(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 90
Specifies the event criteria that cause the EEM applet to run.
•
•
Step 8
action label cli command cli-string [pattern pattern-string]
Example:Router(config-applet)# action 1.0 cli command "enable"Router(config-applet)# action 2.0 cli command "clear counters Ethernet0/1" pattern "confirm"Router(config-applet)# action 3.0 cli command "y"Specifies the action of executing a Cisco IOS CLI command when an EEM applet is triggered.
The pattern keyword is optional and is used only when the command string solicits input. The action cli command ends when the solicited prompt as specified in the optional pattern keyword is received. You are required to specify a regular expression pattern that will match the next solicited prompt. Specification of an incorrect pattern will cause the action cli command to wait forever until the applet execution times out due to the maxrun timer expiration.
•
Step 9
action label syslog [priority priority-level] msg msg-text facility string
Example:Router(config-applet)# action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"
Example:Router(config-applet)# action 1.0 syslog priority errors facility EEM-FAC message "TEST MSG"
Specifies the action to be taken when an EEM applet is triggered.
In this example, the action taken is to write a message to syslog.
•
•
•
•
Step 10
action label mail server server-address to to-address from from-address [cc cc-address] subject subject body body-text
Example:Router(config-applet)# action 2.0 mail server 192.168.1.10 to engineering@example.com from devtest@example.com subject "Memory failure" body "Memory exhausted; current available memory is $_snmp_oid_val bytes"
Specifies the action of sending a short e-mail when an EEM applet is triggered.
•
•
•
•
•
Step 11
Add more action commands as required.
—
Step 12
end
Example:Router(config-applet)# end
Exits applet configuration mode and returns to privileged EXEC mode.
Troubleshooting Tips
Use the debug event manager command in privileged EXEC mode to troubleshoot EEM command operations. Use any debugging command with caution as the volume of generated output can slow or stop the router operations. We recommend that this command be used only under the supervision of a Cisco engineer.
Registering and Defining an Embedded Event Manager Policy to Run Manually
There are two ways to manually run an EEM policy. EEM usually schedules and runs policies on the basis of an event specification that is contained within the policy itself. The event none command allows EEM to identify an EEM policy that can be manually triggered. To run the policy, use either the action policy command in applet configuration mode or the event manager run command in privileged EXEC mode.
Perform this task to register an EEM policy to be run manually using the event manager run command. For an example of how to manually run a policy using the action policy command, see the "Embedded Event Manager Manual Policy Execution: Examples" section.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Unregistering Embedded Event Manager Policies
Perform this task to remove an EEM policy from the running configuration file. Execution of the policy is canceled.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
In the following example, the show event manager policy registered privileged EXEC command is used to display the two EEM applets that are currently registered:
Router# show event manager policy registeredNo. Class Type Event Type Trap Time Registered Name1 applet system snmp Off Fri Aug 12 17:42:52 2005 IPSLAping1oid {1.3.6.1.4.1.9.9.42.1.2.9.1.6.4} get-type exact entry-op eq entry-val {1}exit-op eq exit-val {2} poll-interval 90.000action 1.0 syslog priority critical msg "Server IPecho Failed: OID=$_snmp_oid_val"action 1.1 snmp-trap strdata "EEM detected server reachability failure to 10.1.88.9"action 1.2 publish-event sub-system 88000101 type 1 arg1 "10.1.88.9" arg2 "IPSLAEcho"arg3 "fail"action 1.3 counter name _IPSLA1F op inc value 12 applet system snmp Off Thu Sep 15 05:57:16 2005 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 90action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchoverIn the following example, the show event manager policy registered privileged EXEC command is used to show that applet IPSLAping1 has been removed after entering the no event manager policy command:
Router# show event manager policy registeredNo. Class Type Event Type Trap Time Registered Name1 applet system snmp Off Thu Sep 15 05:57:16 2005 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 90action 1.0 syslog priority critical msg Memory exhausted; current available memory is $_snmp_oid_val bytesaction 2.0 force-switchoverSuspending All Embedded Event Manager Policy Execution
Perform this task to immediately suspend the execution of all EEM policies. Suspending policies, instead of unregistering them might be necessary for reasons of temporary performance or security.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring and Tracking a Stub Object Using Embedded Event Manager
Perform this task to create a stub object, set the state of the stub object, and configure an EEM applet to be run when the tracked object changes. Actions are specified within the EEM applet to both set and read the state of the object. This task allows EEM to define an enhanced object tracking (EOT) object that may be manipulated by other EOT clients. An EEM policy can be a trigger for any EOT object including objects defined for other EOT clients or for an object defined by EEM.
Enhanced Object Tracking
Object tracking was first introduced into the Hot Standby Router Protocol (HSRP) as a simple tracking mechanism that allowed you to track the interface line-protocol state only. Enhanced object tracking provides complete separation between the objects to be tracked and the action to be taken by a client when a tracked object changes. Thus, several clients such as EEM, VRRP, or GLBP can register their interest with the tracking process, track the same object, and each take different action when the object changes.
Each tracked object is identified by a unique number that is specified on the tracking command-line interface (CLI). Client processes use this number to track a specific object. The tracking process periodically polls the tracked objects and notes any change of value. The changes in the tracked object are communicated to interested client processes, either immediately or after a specified delay. The object values are reported as either up or down.
The EOT event detector publishes an event when the tracked object changes.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
Examples
In the following example, the show track privileged EXEC command is used to display information about tracked object number 2.
Router# show track 2Track 2Stub-objectState is Up1 change, last change 00:00:04, by UndefinedDisplaying Embedded Event Manager History Data
Perform this optional task to change the size of the history tables and to display EEM history data.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Step 1
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
Enters global configuration mode.
Router# configure terminalStep 3
Use this command to change the size of the EEM event history table or the size of the EEM SNMP trap history table. In the following example, the size of the EEM event history table is changed to 30 entries:
Router(config)# event manager history size events 30Step 4
Exits global configuration mode and returns to privileged EXEC mode.
Router(config)# exitStep 5
Use this command to display detailed information about each EEM event, for example:
Router# show event manager history eventsNo. Time of Event Event Type Name1 Fri Aug13 21:42:57 2004 snmp applet: SAAping12 Fri Aug13 22:20:29 2004 snmp applet: SAAping13 Wed Aug18 21:54:48 2004 snmp applet: SAAping14 Wed Aug18 22:06:38 2004 snmp applet: SAAping15 Wed Aug18 22:30:58 2004 snmp applet: SAAping16 Wed Aug18 22:34:58 2004 snmp applet: SAAping17 Wed Aug18 22:51:18 2004 snmp applet: SAAping18 Wed Aug18 22:51:18 2004 application applet: CustApp1Step 6
Use this command to display the EEM SNMP traps that have been sent either from the EEM server or from an EEM policy. In the following example, the EEM SNMP traps that were triggered from within an EEM policy are displayed.
Router# show event manager history traps policyNo. Time Trap Type Name1 Wed Aug18 22:30:58 2004 policy EEM Policy Director2 Wed Aug18 22:34:58 2004 policy EEM Policy Director3 Wed Aug18 22:51:18 2004 policy EEM Policy Director
Displaying Embedded Event Manager Registered Policies
Perform this optional task to display registered EEM policies.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Step 1
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
Use this command with the time-ordered keyword to display information about currently registered policies sorted by time, for example:
Router# show event manager policy registered time-orderedNo. Type Event Type Time Registered Name1 applet snmp Thu May30 05:57:16 2004 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 90action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchover2 applet syslog Wed Jul16 00:05:17 2004 intf-downpattern {.*UPDOWN.*Ethernet1/0.*}action 1.0 cns-event msg "Interface state change: $_syslog_msg"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-orderedNo. Type Event Type Time Registered Name1 applet syslog Wed Jul16 00:05:17 2004 intf-downpattern {.*UPDOWN.*Ethernet1/0.*}action 1.0 cns-event msg "Interface state change: $_syslog_msg"2 applet snmp Thu May30 05:57:16 2004 memory-failoid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 90action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchoverUse this command with the event-type keyword to display information about currently registered policies for the event type specified in the event-name argument, for example:
Router# show event manager policy registered event-type syslogNo. Type Event Type Time Registered Name1 applet syslog Wed Jul16 00:05:17 2004 intf-downpattern {.*UPDOWN.*Ethernet1/0.*}action 1.0 cns-event msg "Interface state change: $_syslog_msg"
Configuring Event SNMP Notification
Perform this task to configure SNMP notifications.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Multiple Event Support
The multiple event support feature introduced in Cisco IOS Release 12.4(20)T and later releases, adds the ability to register multiple events in the EEM server. The multiple event support involves one or more event occurrences, one or more tracked object states, and a time period for the event to occur. The event parameters are specified in the CLI commands. The data structure to handle multiple events contains multiple event identifiers and correlation logic. This data is used to register multiple events in the EEM Server.
Setting the Event Configuration Parameters
The trigger command enters the trigger applet configuration mode and specifies the multiple event configuration statements for EEM applets. The trigger statement is used to relate multiple event statement using the tag argument specified in each event statement. The events are raised based on the specified parameters.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Examples
In the following example, applet is run if the show bgp all CLI command and any syslog message that contains the string "COUNT" occurred within a period 60 seconds.
event manager applet delay_50event tag 1.0 cli pattern "show bgp all" sync yes occurs 32 period 60 maxrun 60event tag 2.0 syslog pattern "COUNT"trigger occurs 1 delay 50correlate event 1.0 or event 2.0attribute tag 1.0 occurs 1attribute tag 2.0 occurs 1action 1.0 cli command "show memory"action 2.0 cli command "enable"action 3.0 cli command "config terminal"action 4.0 cli command " ip route 192.0.2.0 255.255.255.224 192.0.2.12"action 91.0 cli command "exit"action 99.0 cli command "show ip route | incl 192.0.2.5"Configuring EEM Class-Based Scheduling
To schedule Embedded Event Manager (EEM) policies and set policy scheduling options, perform this task. In this task, two EEM execution threads are created to run applets assigned to the default class.
The EEM policies will be assigned a class using the class keyword when they are registered. EEM policies registered without a class will be assigned to the default class. Threads that have default class, will service the default class when the thread is available for work. Threads that are assigned specific class letters will service any policy with a matching class letter when the thread is available for work.
If there is no EEM execution thread available to run the policy in the specified class and a scheduler rule for the class is configured, the policy will wait until a thread of that class is available for execution. Synchronous policies that are triggered from the same input event should be scheduled in the same execution thread.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Holding a Scheduled EEM Policy Event or Event Queue
To hold a scheduled EEM policy event or event queue in the EEM scheduler, perform this task. In this task, all pending EEM policies are displayed. A policy identified using a job ID of 2 is held in the EEM scheduler, and the final step shows that the policy with a job ID of 2 has changed status from pending to held.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
show event manager policy pending [queue-type {applet | call-home | axp | script} class class-options | detailed]
Example:Router# show event manager policy pending
Displays the pending EEM policies.
Step 3
event manager scheduler hold {all | policy job-id | queue-type {applet | call-home | axp | script} class class-options} [processor {rp_primary | rp_standby}]
Example:Router# event manager scheduler hold policy 2
Holds a scheduled EEM policy event or event queue in the EEM scheduler.
•
Step 4
show event manager policy pending [queue-type {applet | call-home | axp | script} class class-options | detailed]
Example:Router# show event manager policy pending
Displays the status of EEM policy put on hold in Step 3 as held, along with other pending policies.
Examples
The following example shows how to view all pending EEM policies and to hold the EEM policy with a job ID of 2.
Router# show event manager policy pendingno. job id status time of event event type name1 1 pend Thu Sep 7 02:54:04 2006 syslog applet: one2 2 pend Thu Sep 7 02:54:04 2006 syslog applet: two3 3 pend Thu Sep 7 02:54:04 2006 syslog applet: threeRouter# event manager scheduler hold policy 2Router# show event manager policy pendingno. job id status time of event event type name1 1 pend Thu Sep 7 02:54:04 2006 syslog applet: one2 2 held Thu Sep 7 02:54:04 2006 syslog applet: two3 3 pend Thu Sep 7 02:54:04 2006 syslog applet: threeResuming Execution of EEM Policy Events or Event Queues
To resume the execution of specified EEM policies, perform this task. In this task, the policy that was put on hold in the "Holding a Scheduled EEM Policy Event or Event Queue" section is now allowed to resume execution.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
show event manager policy pending
Example:Router# show event manager policy pending
Displays the pending and held EEM policies.
Note
Step 3
event manager scheduler release {all | policy policy-id | queue-type {applet | call-home | axp | script}} class class-options [processor {rp_primary | rp_standby}]
Example:Router# event manager scheduler release policy 2
Resumes execution of specified EEM policies.
•
Step 4
show event manager policy pending
Example:Router# show event manager policy pending
Displays the status of the EEM policy resumed in Step 3 as pending, along with other pending policies.
Note
Examples
The following example shows how to view all pending EEM policies, to specify the policy that will resume execution, and to see that the policy is now back in a pending status.
Router# show event manager policy pendingno. job id status time of event event type name1 1 pend Thu Sep 7 02:54:04 2006 syslog applet: one2 2 held Thu Sep 7 02:54:04 2006 syslog applet: two3 3 pend Thu Sep 7 02:54:04 2006 syslog applet: threeRotuer# event manager scheduler release policy 2Rotuer# show event manager policy pendingno. job id status time of event event type name1 1 pend Thu Sep 7 02:54:04 2006 syslog applet: one2 2 pend Thu Sep 7 02:54:04 2006 syslog applet: two3 3 pend Thu Sep 7 02:54:04 2006 syslog applet: threeClearing Pending EEM Policy Events or Event Queues
Perform this task to clear EEM policies that are executing or pending execution. In this task, the EEM policy with a job ID of 2 is cleared from the pending queue. The show event manager policy pending command is used to display the policies that are pending before and after the policy is cleared.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
show event manager policy pending
Example:Router# show event manager policy pending
Displays the pending EEM policies.
Note
Step 3
event manager scheduler clear {all | policy job-id | queue-type {applet | call-home | axp | script} class class-options} [processor {rp_primary | rp_standby}]
Example:Router# event manager scheduler clear policy 2
Clears EEM policies that are executing or pending execution.
•
Step 4
show event manager policy pending
Example:Router# show event manager policy pending
Displays all the pending EEM policies except the policy cleared in Step 3.
Note
Examples
The following example shows how to clear the EEM policy with a job ID of 2 that was pending execution. The show commands are used to display the policies that are pending before and after the policy is cleared.
Router# show event manager policy pendingno. job id status time of event event type name1 1 pend Thu Sep 7 02:54:04 2006 syslog applet: one2 2 pend Thu Sep 7 02:54:04 2006 syslog applet: two3 3 pend Thu Sep 7 02:54:04 2006 syslog applet: threeRouter# event manager scheduler clear policy 2Router# show event manager policy pendingno. job id status time of event event type name1 1 pend Thu Sep 7 02:54:04 2006 syslog applet: one3 3 pend Thu Sep 7 02:54:04 2006 syslog applet: threeModifying the Scheduling Parameters of EEM Policy Events or Event Queues
To modify the scheduling parameters of the EEM policies, perform this task. The show event manager policy pending command displays policies that are assigned to the B or default class. All the currently pending policies are then changed to class A. After the configuration modification, the show event manager policy pending command shows all policies assigned as class A.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
show event manager policy pending
Example:Router# show event manager policy pending
Displays the pending EEM policies.
Note
Step 3
event manager scheduler modify {all | policy job-id | queue-type {applet | call-home | axp | script} | class class-options} [queue-priority {high | last | low | normal}] [processor {rp_primary | rp_standby}]
Example:Router# event manager scheduler modify all class A
Modifies the scheduling parameters of the EEM policies.
•
Step 4
show event manager policy pending
Example:Router# show event manager policy pending
Displays the EEM policies modified in Step 3 along with other pending policies.
Note
Examples
The following example shows how to modify the scheduling parameters of the EEM policies. In this example, the show event manager policy pending command displays policies that are assigned to the B or default class. All the currently pending policies are then changed to class A. After the configuration modification, the show event manager policy pending command verifies that all policies are now assigned as class A.
Router# show event manager policy pendingno. class status time of event event type name1 default pend Thu Sep 7 02:54:04 2006 syslog applet: one2 default pend Thu Sep 7 02:54:04 2006 syslog applet: two3 B pend Thu Sep 7 02:54:04 2006 syslog applet: threeRouter# event manager scheduler modify all class ARouter# show event manager policy pendingno. class status time of event event type name1 A pend Thu Sep 7 02:54:04 2006 syslog applet: one2 A pend Thu Sep 7 02:54:04 2006 syslog applet: two3 A pend Thu Sep 7 02:54:04 2006 syslog applet: threeVerifying Class-Based Scheduled Activities of EEM Policies
To verify the scheduled activities of the EEM policies, use the show event manager scheduler command.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
DETAILED STEPS
Step 1
This command displays all the EEM execution threads from the scheduler perspective and the details of the running policies. This command includes detailed and queue-type optional keywords. The following is sample output from this command:
Router# show event manager scheduler thread1 Script threads service class defaulttotal: 1 running: 1 idle: 02 Script threads service class range A-Dtotal: 3 running: 0 idle: 33 Applet threads service class defaulttotal: 32 running: 0 idle: 324 Applet threads service class W Xtotal: 5 running: 0 idle: 5To display the details of the running policies using the scheduler threads use the detailed keyword. The following is sample output for this keyword:
Router# show event manager scheduler thread detailed1 Script threads service class defaulttotal: 5 running: 5 idle: 01 job id: 12341, pid: 101, name: loop.tcl2 job id: 12352, pid: 52, name: loop.tcl3 job id: 12363, pid: 55, name: loop.tcl4 job id: 12395, pid: 53, name: loop.tcl5 job id: 12588, pid: 102, name: loop.tcl2 Applet threads service class defaulttotal: 32 running: 5 idle: 271 job id: 15585, pid: 104, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL2 job id: 15586, pid: 105, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL3 job id: 15587, pid: 106, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL4 job id: 15589, pid: 107, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL5 job id: 15590, pid: 80, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPLTo display the scheduler threads of a queue-type use the queue-type keyword. The following are the sample output for this keyword:
Router# show event manager sched thread queue-type applet1 Applet threads service class defaulttotal: 32 running: 7 idle: 25Router# show event manager sched thread queue-type applet detailed1 Applet threads service class defaulttotal: 32 running: 5 idle: 271 job id: 15700, pid: 103, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL2 job id: 15701, pid: 104, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL3 job id: 15703, pid: 106, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL4 job id: 15704, pid: 107, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPL5 job id: 15706, pid: 55, name: WDOG_SYSLG_CNTR_TRACK_INTF_APPLVerifying Class-Based Active EEM Policies
To verify the active or the running EEM policies, use the show event manager policy active command.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SUMMARY STEPS
1.
DETAILED STEPS
Step 1
This command displays only the running EEM policies. This command includes class, detailed and queue-type optional keywords. The following is sample output from this command:
Router# show event manager policy activeno. job id p s status time of event event type name1 12598 N A running Mon Oct29 20:49:37 2007 timer watchdog loop.tcl2 12609 N A running Mon Oct29 20:49:42 2007 timer watchdog loop.tcl3 12620 N A running Mon Oct29 20:49:46 2007 timer watchdog loop.tcl4 12650 N A running Mon Oct29 20:49:59 2007 timer watchdog loop.tcl5 12842 N A running Mon Oct29 20:51:13 2007 timer watchdog loop.tcldefault class - 6 applet eventsno. job id p s status time of event event type name1 15852 N A running Mon Oct29 21:11:09 2007 counter WDOG_SYSLG_CNTR_TRACK_INTF_APPL2 15853 N A running Mon Oct29 21:11:09 2007 counter WDOG_SYSLG_CNTR_TRACK_INTF_APPL3 15854 N A running Mon Oct29 21:11:10 2007 counter WDOG_SYSLG_CNTR_TRACK_INTF_APPL4 15855 N A running Mon Oct29 21:11:10 2007 timer watchdog WDOG_SYSLG_CNTR_TRACK_INTF_APPL5 15856 N A running Mon Oct29 21:11:11 2007 counter WDOG_SYSLG_CNTR_TRACK_INTF_APPL6 15858 N A running Mon Oct29 21:11:11 2007 counter WDOG_SYSLG_CNTR_TRACK_INTF_APPLVerifying Pending EEM Policies
To verify the EEM policies that are pending for execution, use the show event manager policy pending command. In Cisco IOS Release 12.4(22)T, optional keywords were added to this command to specify EEM class-based scheduling options.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or later release.
SUMMARY STEPS
1.
DETAILED STEPS
Step 1
This command displays only the pending policies. This command includes class, detailed and queue-type optional keywords. The following is sample output from this command:
Router# show event manager policy pendingno. job id p s status time of event event type name1 12851 N A pend Mon Oct29 20:51:18 2007 timer watchdog loop.tcl2 12868 N A pend Mon Oct29 20:51:24 2007 timer watchdog loop.tcl3 12873 N A pend Mon Oct29 20:51:27 2007 timer watchdog loop.tcl4 12907 N A pend Mon Oct29 20:51:41 2007 timer watchdog loop.tcl5 13100 N A pend Mon Oct29 20:52:55 2007 timer watchdog loop.tcl
Configring EEM Applet (Interactive CLI) Support
The synchronous applets are enhanced to support interaction with the local console (tty) in Cisco IOS Release 12.4(22)T. Two new commands action gets and action puts are introduced to allow users to enter and display input directly on the console. The output for synchronous applets will bypass the system logger. The local console will be opened by the applets and serviced by the corresponding synchronous Event Detector pty. Synchronous output will be directed to the opened console.
For details on configuring EEM applet interactive CLI support, see the "Reading and Writing Input from the Active Console for Synchronous EEM Applets" section.
Reading and Writing Input from the Active Console for Synchronous EEM Applets
The synchronous applets are enhanced to support interaction with the local console (tty) in Cisco IOS Release 12.4(22)T.
Use the following tasks to implement EEM applet interactive CLI support:
•
•
Reading Input from the Active Console
When a synchronous policy is triggered, the related console is stored in the publish information specification. The policy director will query this information in an event_reqinfo call, and store the given console information for use by the action gets command.
The action gets command reads a line of the input from the active console and stores the input in the variable. The trailing new line will not be returned.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T, or later releases.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
event manager applet applet-name
Example:Router(config)# event manager applet action
Registers the applet with the EEM and enters applet configuration mode.
Step 4
event none
Example:Router(config-applet)# event none
Specifies that an EEM policy is to be registered with the EEM and can be run manually.
Step 5
action label gets variable
Example:Router(config-applet)# action label2 gets input
Gets input from the local console in a synchronous applet and stores the value in the given variable when an EEM applet is triggered.
Step 6
action label syslog [priority priority-level]
msg msg-textExample:Router(config-applet)# action label3 syslog msg "Input entered was \"$input\""
Specifies the action to be taken when an EEM applet is triggered.
•
Step 7
exit
Example:Router(config-applet)# exit
Exits applet configuration mode and returns to privileged EXEC mode.
Example
The following example shows how to get the input from the local tty in a synchronous applet and store the value
Router(config)# event manager applet actionRouter(config-applet)# event noneRouter(config-applet)# action label2 gets inputRouter(config-applet)# action label3 syslog msg "Input entered was \"$input\""
Writing Input to the Active Console
When a synchronous policy is triggered, the related console is stored in the publish information specification. The policy director will query this information in an event_reqinfo call, and store the given console information for use by the action puts command.
The action puts command will write the string to the active console. A new line will be displayed unless the nonewline keyword is specified. The output from the action puts command for a synchronous applet is displayed directly to the console, bypassing the system logger. The output of the action puts command for an asynchronous applet is directed to the system logger.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T, or a later release.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
event manager applet applet-name
Example:Router(config)# event manager applet action
Registers the applet with the EEM and enters applet configuration mode.
Step 4
event none
Example:Router(config-applet)# event none
Specifies that an EEM policy is to be registered with the EEM and can be run manually.
Step 5
action label regexp string-pattern string-input [string-match [string-submatch1] [string-submatch2] [string-submatch3]]
Example:Router(config-applet)# action 1 regexp "(.*) (.*) (.*)" "one two three" _match _sub1
Specifies the action to match the regular expression pattern on an input string when an EEM applet is triggered.
Step 6
action label puts [nonewline] string
Example:Router(config-applet)# action 2 puts "match is $_match"
Specifies the action of printing data directly to the local console when an EEM applet is triggered.
•
Step 7
exit
Example:Router(config-applet)# exit
Exits applet configuration mode and returns to privileged EXEC mode.
Step 8
event manager run applet-name
Example:Router# event manager run action
Manually runs a registered EEM policy.
•
Example
The following example shows how the action puts command prints data directly to the local console:
Router(config-applet)# event manager applet putsRouter(config-applet)# event noneRouter(config-applet)# action 1 regexp "(.*) (.*) (.*)" "one two three" _match _sub1Router(config-applet)# action 2 puts "match is $_match"Router(config-applet)# action 3 puts "submatch 1 is $_sub1"Router# event manager run putsmatch is one two threesubmatch 1 is oneConfiguring SNMP Library Extensions
To configure SNMP Library Extensions for an EEM policy, you must be familiar with the following concepts:
•
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
SNMP Get and Set Operations
With the Cisco IOS Release 12.4(22)T, the SNMP Library Extensions feature extends the EEM applet action info and Tcl sys_reqinfo_snmp commands to include functionality for SNMP get-one, get-next, getid and set-any operations.
SNMP Get Operation
The SNMP event manager performs the SNMP get operation to retrieve one or more variables for the managed objects. Using the action info type snmp oid get-type and action info type snmp getid commands, you can configure the SNMP event manager to send an SNMP get request by specifying the variables to retrieve, and the IP address of the agent.
For example, if you want to retrieve the variable with the OID value of 1.3.6.1.2.1.1.1, you should specify the variable value, that is 1.3.6.1.2.1.1.1. If the specified values do not match, a trap will be generated and an error message will be written to the syslog history.
The action info type snmp oid get-type command specifies the type of the get operation to be performed. To retrieve the exact variable, the get operation type should be specified as exact. To retrieve a lexicographical successor of the specified OID value, the get operation type should be set to next.
Table 3 shows the built-in variables, in which the values retrieved from SNMP get operation are stored.
GetID Operation
The action info type snmp getid command retrieves the following variables from the SNMP entity:
•
•
•
•
•
•
Table 4 shows the built-in variables, in which the values retrieved from the SNMP getID operation are stored.
The get operation requests can be sent to both local and remote hosts.
SNMP Set Operation
All SNMP variables are assigned a default value in the MIB view. The SNMP event manager can modify the value of these MIB variables through set operation. The set operation can be performed only on the system that allows read-write access.
To perform a set operation, you must specify the type of the variable and the value associated with it.
Table 5 shows the valid OID types and values for each OID type.
The set operation can carried out on both local and remote hosts.
SNMP Traps and Inform Requests
Traps are SNMP notifications that alert the SNMP manager or the NMS to a network condition.
SNMP inform requests refer to the SNMP notifications that alert the SNMP manager to a network condition and request for confirmation of receipt from the SNMP manager.
An SNMP event occurs when SNMP MIB object ID values are sampled, or when the SNMP counter crosses a defined threshold. If the notifications are enabled and configured for such events, the SNMP traps or inform messages generated. An SNMP notification event is triggered when an SNMP trap or inform message is received by the event manager server.
To send an SNMP trap or inform message when an Embedded Event Manager (EEM) applet is triggered, the action info type snmp trap and action info type snmp inform commands are used. The CISCO-EMBEDDED-EVENT-MGR-MIB.my is used to define the trap and inform messages.
How to Configure SNMP Library Extensions
This section contains the following tasks:
•
•
Configuring EEM Applet for SNMP Get and Set Operations
While registering a policy with the event manager server, the actions associated with an SNMP event can be configured.
Perform this task to configure EEM applet for SNMP set and get operations.
Prerequisites
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Configuring EEM Applet for SNMP OID Notifications
Perform this task to configure SNMP notifications.
Prerequisites
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Configuring Variable Logic for EEM Applets
The Variable Logic for EEM Applets feature introduced in Cisco IOS Release 12.4(22)T and later releases, adds the ability to apply conditional logic within EEM applets. Before variable logic is introduced, applets have a linear structure where each action is executed in the order in which they are configured when the event is triggered. Conditional logic introduces a control structure that can change the flow of actions within applets depending on conditional expressions. Each control structure can contain a list of applet actions including looping and if/else actions which determine if the structure is executed or not.
The information in applet configuration mode is presented as background to set the context for the action commands.
To provide a consistent user interface between the Tool Command Language (Tcl) and the applet (CLI) based EEM policies, the following criteria are followed:
•
•
Applet configuration mode is entered using the event manager applet command. In applet configuration mode the config prompt changes to (config-applet)#. In applet configuration mode two types of config statements are supported:
•
•
Multiple action applet config commands are allowed within an applet configuration. If no action applet config command is present, a warning is displayed, upon exit, stating no statements are associated with this applet. When no statements are associated with this applet, events get triggered but no action is taken. If no commands are specified in applet configuration mode, the applet will be removed upon exit. The exit applet config command is used to exit from applet configuration mode.
Prerequisites
To use this feature, you must be running Cisco IOS Release 12.4(22)T or a later release.
Configuring Variable Logic for EEM Applets
EEM 3.0 adds new applet action commands to permit simple variable logic within applets.
To configure the variable logic using action commands perform the followng tasks.
•
•
•
•
Specifying a Loop of Conditional Blocks
To specify a loop of a conditional block when an EEM applet is triggered, perform this task. In this task, a conditional loop is set to check if the value of the variable is less than 10. If the value of the variable is less than 10, then the message `i is $_i' is written to the syslog.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Specifying if else Conditional Blocks
To specify the beginning of an if conditional statement followed by an else conditional statement, perform this task. The if or else conditional statements can be used in conjunction with each other or separately. In this task, the value of a variable is set to 5. An if conditional block is then specified, to check if the value of the variable is less than 10. Provided the if conditional block is satisfied, an action command to output the message `x is less than 10' is specified.
Following the if conditional block, an else conditional block is specified. Provided the if conditional block is not satisfied, an action command to output the message `x is greater than 10' is specified.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Specifying foreach Iterating Statements
To specify a conditional statement that iterates over an input string using the delimiter as a tokenizing pattern, perform this task. The foreach iteration statement is used to iterate through a collection to get the desired information. The delimiter is a regular expression pattern string. The token found in each iteration is assigned to the given iterator variable. All arithmetic calculations are performed as long integers with out any checks for overflow. In this task, the value of the variable x is set to 5. An iteration statement is set to run through the input string red, blue, green, orange. For every element in the input string, a corresponding message is displayed on the screen.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Using Regular Expressions
To match a regular expression pattern with an input string, perform this task. Using regular expressions, you can specify the rules for a set of possible strings to be matched. In this task,
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Incrementing the Values of Variables
To increment the value of variables, perform this task. In this task, the value of a variable is set to 20 and then the value is incremented by 12.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Event SNMP Object
Perform this task to register the Simple Network Management Protocol (SNMP) object event for an Embedded Event Manager (EEM) applet that is run by sampling SNMP object.
Prerequisites
To use this feature, you must be running Cisco IOS Release 15.0(1)M or a later release.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Disabling AAA Authorization
Perform this task to allow EEM policies to bypass AAA authorization when triggered.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring Description of an Embedded Event Manager Applet
Perform this task to describe an EEM applet. The description of an applet can be added in any order, before or after any other applet configuration. Configuring a new description for an applet that already has a description overwrites the current description. An applet description is optional.
Perform this task to configure a new description for an applet.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuration Examples for Writing EEM Policies Using the Cisco IOS CLI
This section provides the following configuration examples:
•
•
•
•
•
•
•
Embedded Event Manager Applet Configuration: Examples
The following examples show how to create an EEM applet for some of the EEM event detectors. These examples follow steps outlined in the "Registering and Defining an Embedded Event Manager Applet" section.
Application-Specific Event Detector
The following example shows how a policy named EventPublish_A runs every 20 seconds and publishes an event type numbered 1 to an EEM subsystem numbered 798. The subsystem value of 798 specifies that a publish event has occurred from an EEM policy. A second policy named EventPublish_B is registered to run when the EEM event type 1 occurs with subsystem 798. When the EventPublish_B policy runs, it sends a message to syslog containing data passed as an argument from the EventPublish_A policy.
event manager applet EventPublish_Aevent timer watchdog time 20.0action 1.0 syslog msg "Applet EventPublish_A"action 2.0 publish-event sub-system 798 type 1 arg1 twentyexitevent manager applet EventPublish_Bevent application sub-system 798 type 1action 1.0 syslog msg "Applet EventPublish_B arg1 $_application_data1"CLI Event Detector
The following example shows how to specify an EEM applet to run when the Cisco IOS write memory CLI command is run. The applet provides a notification that this event has occurred via a syslog message. In the example, the sync keyword is configured with the yes argument, and this means that the event detector is notified when this policy completes running. The exit status of the policy determines whether the CLI command will be executed. In this example, the policy exit status is set to one and the CLI command runs.
event manager applet cli-matchevent cli pattern "write mem.*" sync yesaction 1.0 syslog msg "$_cli_msg Command Executed"set 2.0 _exit_status 1The following example shows an applet which matches the cli pattern with the test argument. When show access-list test is entered, the CLI event detector matches the test argument, and the applet is triggered. The debug event manager detector cli output is added to show num_matches is set to one.
!event manager applet EEM-PIPE-TESTevent cli pattern "test" sync yesaction 1.0 syslog msg "Pattern matched!"!*Aug 23 23:19:59.827: check_eem_cli_policy_handler: command_string=show access-lists test*Aug 23 23:19:59.827: check_eem_cli_policy_handler: num_matches = 1, response_code = 4*Aug 23 23:19:59.843: %HA_EM-6-LOG: EEM-PIPE-TEST: Pattern matched!
Note
The following example shows that when show version | include test is entered, the applet fails to trigger because the CLI event detector does not match on characters entered after the pipe (|) character and the debug event manager detector cli output shows num_matches is set to zero.
*Aug 23 23:20:16.827: check_eem_cli_policy_handler: command_string=show version*Aug 23 23:20:16.827: check_eem_cli_policy_handler: num_matches = 0, response_code = 1Counter Event Detector and Timer Event Detector
The following example shows that the EventCounter_A policy is configured to run once a minute and to increment a well-known counter called critical_errors. A second policy—EventCounter_B—is registered to be triggered when the well-known counter called critical_errors exceeds a threshold of 3. When the EventCounter_B policy runs, it resets the counter to 0.
event manager applet EventCounter_Aevent timer watchdog time 60.0action 1.0 syslog msg "EventCounter_A"action 2.0 counter name critical_errors op inc value 1exitevent manager applet EventCounter_Bevent counter name critical_errors entry-op gt entry-val 3 exit-op lt exit-val 3action 1.0 syslog msg "EventCounter_B"action 2.0 counter name critical_errors op set value 0Interface Counter Event Detector
The following example shows how a policy named EventInterface is triggered every time the receive_throttle counter for Fast Ethernet interface 0/0 is incremented by 5. The polling interval to check the counter is specified to run once every 90 seconds.
event manager applet EventInterfaceevent interface name FastEthernet0/0 parameter receive_throttle entry-op ge entry-val 5entry-val-is-increment true poll-interval 90action 1.0 syslog msg "Applet EventInterface"Resource Event Detector
The following example shows how to specify event criteria based on an ERM event report for a policy defined to report high CPU usage:
event manager applet policy-oneevent resource policy cpu-highaction 1.0 syslog msg "CPU high at $_resource_current_value percent"RF Event Detector
The RF event detector is only available on networking devices that contain dual Route Processors (RPs). The following example shows how to specify event criteria based on an RF state change notification:
event manager applet start-rfevent rf event rf_prog_initializationaction 1.0 syslog msg "rf state rf_prog_initialization reached"RPC Event Detector
The RPC event detector allows an outside entity to make a Simple Object Access Protocol (SOAP) request to the router or a switch and invokes a defined EEM policy or script. The following example shows how an EEM applet called Event_RPC is being registered to run an EEM script:
event manager applet Event_RPCevent rpcaction print puts "hello there"The following example shows the format of the SOAP request and reply message:
<?xml version="1.0" encoding="UTF-8"?><SOAP:Envelope xmlns:SOAP="http://www.cisco.com/eem.xsd"><SOAP:Body><run_eemscript><script_name>Event_RPC</script_name></run_eemscript></SOAP:Body></SOAP:Envelope>]]>]]><?xml version="1.0" encoding="UTF-8"?><SOAP:Envelope xmlns:SOAP="http://www.cisco.com/eem.xsd"><SOAP:Body><run_eemscript_response><return_code> 0</return_code><output></output></run_eemscript_response></SOAP:Body></SOAP:Envelope>]]>]] >SNMP Event Detector
The following example shows how to specify an EEM applet to run when the CPU usage is greater than 75 percent. When the EEM applet runs, the CLI commands enable and show cpu processes are run, and an e-mail containing the result of the show cpu processes command is sent to an engineer.
event manager applet snmpcpuge75event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.3.1 get-type exact entry-op ge entry-val 75 poll-interval 10action 1.0 cli command "enable"action 2.0 cli command "show process cpu"action 3.0 mail server "192.168.1.146" to "engineer@cisco.com" from "devtest@cisco.com" subject "B25 PBX Alert" body "$_cli_result"The next example is more complex and shows how to configure an EEM applet that causes a switch to the secondary (redundant) Route Processor (RP) when the primary RP runs low on memory.
This example illustrates a method for taking preventative action against a software fault that causes a memory leak. The action taken here is designed to reduce downtime by switching over to a redundant RP when a possible memory leak is detected.
Figure 1 Dual RP Topology
The commands used to register the policy are shown below.
event manager applet memory-demoevent snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 90action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchoverThe registered applet is displayed using the show event manager policy registered command:
Router# show event manager policy registeredNo. Type Event Type Time Registered Name1 applet snmp Thu Jan30 05:57:16 2003 memory-demooid {1.3.6.1.4.1.9.9.48.1.1.1.6.1} get-type exact entry-op lt entry-val {5120000} poll-interval 90action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchoverFor the purpose of this example, a memory depletion is forced on the router, and a series of show memory commands are executed to watch the memory deplete:
Router# show memoryHead Total(b) Used(b) Free(b) Lowest(b) Largest(b)Processor 53585260 212348444 119523060 92825384 92825384 92365916Fast 53565260 131080 70360 60720 60720 60668Router# show memoryHead Total(b) Used(b) Free(b) Lowest(b) Largest(b)Processor 53585260 212364664 164509492 47855172 47855172 47169340Fast 53565260 131080 70360 60720 60720 60668Router# show memoryHead Total(b) Used(b) Free(b) Lowest(b) Largest(b)Processor 53585260 212369492 179488300 32881192 32881192 32127556Fast 53565260 131080 70360 60720 60720 60668When the threshold is reached, an EEM event is triggered. The applet named memory-demo runs, causing a syslog message to be written to the console and a switch to be made to the secondary RP. The following messages are logged:
00:08:31: %HA_EM-2-LOG: memory-demo: Memory exhausted; current available memory is 4484196 bytes00:08:31: %HA_EM-6-FMS_SWITCH_HARDWARE: fh_io_msg: Policy has requested a hardware switchoverThe following is partial output from the show running-config command on both the primary RP and the secondary (redundant) RP:
redundancymode sso..!event manager applet memory-demoevent snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 90action 1.0 syslog priority critical msg "Memory exhausted; current available memory is $_snmp_oid_val bytes"action 2.0 force-switchoverSNMP Notification Event Detector
The following example shows how to configure the snmp-server community public RW and snmp-server manager commands before event snmp-notification is configured.
snmp-server community public RWsnmp-server managerThe following example shows how an EEM applet called SNMP_Notification is being registered to run an EEM script when the router receives an SNMP notification on destination IP address 192.168.1.1 for object ID 1 whose value equals 10.
event manager applet SNMP_Notificationevent snmp-notification dest_ip_address 192.168.1.1 oid 1 op eq oid-value 10action 1 policy eem_scriptSyslog Event Detector
The following example shows how to specify an EEM applet to run when syslog identifies that Ethernet interface 1/0 is down. The applet sends a message about the interface to syslog.
event manager applet interface-downevent syslog pattern ".*UPDOWN.*Ethernet1/0.*" occurs 4action 1.0 syslog msg "Ethernet interface 1/0 changed state 4 times"Embedded Event Manager Manual Policy Execution: Examples
The following examples show how to use the none event detector to configure an EEM policy (applet or script) to be run manually.
Using the event manager run Command
This example shows how to run a policy manually using the event manager run command. The policy is registered using the event none command under applet configuration mode and then run from global configuration mode using the event manager run command.
event manager applet manual-policyevent noneaction 1.0 syslog msg "Manual-policy triggered"end!event manager run manual-policyUsing the action policy Command
This example shows how to run a policy manually using the action policy command. The policy is registered using the event none command under applet configuration mode, and then the policy is executed using the action policy command in applet configuration mode.
event manager applet manual-policyevent noneaction 1.0 syslog msg "Manual-policy triggered"exit!event manager applet manual-policy-twoevent noneaction 1.0 policy manual-policyend!event manager run manual-policy-twoConfiguring and Tracking a Stub Object Using Embedded Event Manager: Example
This example shows how to create a stub object, set the state of the stub object, and configure an EEM applet to be run when the tracked object changes. The enhanced object tracking (EOT) event detector is used, and actions are specified to both set and read the state of the object. This example allows EEM to define an EOT object that may be manipulated by other EOT clients. An EEM policy can be a trigger for any EOT object including objects defined for other EOT clients or for an object defined by EEM.
track 10 stub-objectdefault-state down!event manager applet track-tenevent track 10 state anyaction 1.0 track set 10 state upaction 2.0 track read 10Embedded Event Manager Watchdog System Monitor (Cisco IOS) Event Detector Configuration: Example
The following example shows how to configure three EEM applets to demonstrate how the Cisco IOS watchdog system monitor (IOSWDSysMon) event detector works.
Watchdog System Monitor Sample1 Policy
The first policy triggers an applet when the average CPU usage for the process named IP Input is greater than or equal to 1 percent for 10 seconds:
event manager applet IOSWD_Sample1event ioswdsysmon sub1 cpu-proc taskname "IP Input" op ge val 1 period 10action 1.0 syslog msg "IOSWD_Sample1 Policy Triggered"Watchdog System Monitor Sample2 Policy
The second policy triggers an applet when the total amount of memory used by the process named Net Input is greater than 100 kb:
event manager applet IOSWD_Sample2event ioswdsysmon sub1 mem-proc taskname "Net Input" op gt val 100 is-percent falseaction 1.0 syslog msg "IOSWD_Sample2 Policy Triggered"Watchdog System Monitor Sample3 Policy
The third policy triggers an applet when the total amount of memory used by the process named IP RIB Update has increased by more than 50 percent over the sample period of 60 seconds:
event manager applet IOSWD_Sample3event ioswdsysmon sub1 mem-proc taskname "IP RIB Update" op gt val 50 is-percent true period 60action 1.0 syslog msg "IOSWD_Sample3 Policy Triggered"The three policies are configured, and then repetitive large pings are made to the networking device from several workstations, causing the networking device to register some usage. This will trigger policies 1 and 2, and the console will display the following messages:
00:42:23: %HA_EM-6-LOG: IOSWD_Sample1: IOSWD_Sample1 Policy Triggered00:42:47: %HA_EM-6-LOG: IOSWD_Sample2: IOSWD_Sample2 Policy TriggeredTo view the policies that are registered, use the show event manager policy registered command:
Router# show event manager policy registeredNo. Class Type Event Type Trap Time Registered Name1 applet system ioswdsysmon Off Fri Jul 23 02:27:28 2004 IOSWD_Sample1sub1 cpu_util {taskname {IP Input} op ge val 1 period 10.000 }action 1.0 syslog msg "IOSWD_Sample1 Policy Triggered"2 applet system ioswdsysmon Off Fri Jul 23 02:23:52 2004 IOSWD_Sample2sub1 mem_used {taskname {Net Input} op gt val 100 is_percent FALSE}action 1.0 syslog msg "IOSWD_Sample2 Policy Triggered"3 applet system ioswdsysmon Off Fri Jul 23 03:07:38 2004 IOSWD_Sample3sub1 mem_used {taskname {IP RIB Update} op gt val 50 is_percent TRUE period 60.000 }action 1.0 syslog msg "IOSWD_Sample3 Policy Triggered"Configuration SNMP Library Extensions: Examples
This section provides the following configuration examples:
•
•
•
SNMP Get Operations: Examples
The following example shows how to send a get request to the local host.
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.2.1.1.1.0 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp oid 1.3.6.1.2.1.1.1.0 get-type exact community publicRouter(config-applet)# action 1.3 info type snmp oid 1.3.6.1.2.1.1.4.0 get-type next community publicThe following log message will be written to the SNMP event manager log:
1d03h:%HA_EM-6-LOG: lg: 1.3.6.1.2.1.1.1.01d04h:%HA_EM-6-LOG: lgn: 1.3.6.1.2.1.1.5.0The following example shows how to send a get request to a remote host.
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.2.1.1.1.0 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp oid 1.3.6.1.2.1.1.4.0 get-type next community public ipaddr 172.17.16.69Router(config-applet)# action 1.3 info type snmp getid 1.3.6.1.2.1.1.1.0 community public ipaddr 172.17.16.69The following log message is written to the SNMP event manager log:
1d03h:%HA_EM-6-LOG: lg: 1.3.6.1.2.1.1.1.01d04h:%HA_EM-6-LOG: lgn: 1.3.6.1.2.1.1.5.0SNMP GetID Operations: Examples
The following example shows how to send a getid request to the local host.
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.2.1.1.1.0 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp getid community publicThe following log message is written to the SNMP event manager log:
1d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysname_oid=1.3.6.1.2.1.1.5.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysname_value=jubjub.cisco.com1d04h:%HA_EM-6-LOG: lgid: _info_snmp_syslocation_oid=1.3.6.1.2.1.1.6.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_syslocation_value=1d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysdescr_oid=1.3.6.1.2.1.1.1.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysobjectid_oid=1.3.6.1.2.1.1.2.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysobjectid_value=products.2221d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysuptime_oid=1.3.6.1.2.1.1.3.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysuptime_oid=101316761d04h:%HA_EM-6-LOG: lgid: _info_snmp_syscontact_oid=1.3.6.1.2.1.1.4.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_syscontact_value=YYYThe following example shows how to send a getid request to a remote host.
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.2.1.1.1.0 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp getid 1.3.6.1.2.1.1.1.0 community public ipaddr 172.17.16.69The following log message is written to the SNMP event manager log:
1d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysname_oid=1.3.6.1.2.1.1.5.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysname_value=jubjub.cisco.com1d04h:%HA_EM-6-LOG: lgid: _info_snmp_syslocation_oid=1.3.6.1.2.1.1.6.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_syslocation_value=1d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysdescr_oid=1.3.6.1.2.1.1.1.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysobjectid_oid=1.3.6.1.2.1.1.2.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysobjectid_value=products.2221d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysuptime_oid=1.3.6.1.2.1.1.3.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_sysuptime_oid=101316761d04h:%HA_EM-6-LOG: lgid: _info_snmp_syscontact_oid=1.3.6.1.2.1.1.4.01d04h:%HA_EM-6-LOG: lgid: _info_snmp_syscontact_value=YYYSet Operations: Examples
The following example shows how to perform a set operation on the local host.
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.2.1.1.1.0 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp oid 1.3.6.1.2.1.1.4.0 set-type integer 5 sysName.0 community publicThe following log message is written to the SNMP event manager log:
1d04h:%HA_EM-6-LOG: lset: 1.3.6.1.2.1.1.4.01d04h:%HA_EM-6-LOG: lset: XXXThe following example shows how to perform a set operation on a remote host.
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.2.1.1.1.0 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp oid 1.3.6.1.2.1.1.4.0 set-type integer 5 sysName.0 community public ipaddr 172.17.16.69The following log message is written to the SNMP event manager log:
1d04h:%HA_EM-6-LOG: lset: 1.3.6.1.2.1.1.4.01d04h:%HA_EM-6-LOG: lset: XXXGenerating SNMP Notifications: Examples
The following example shows how to configure SNMP traps for the sysUpTime.0 variable:
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp var sysUpTime.0 oid 1.3.6.1.4.1.9.9.43.1.1.6.1.3.41 integer 2Router(config-applet)# action 1.4 info type snmp trap enterprise-oid ciscoSyslogMIB.2 generic-trapnum 6 specific-trapnum 1 trap-oid 1.3.6.1.4.1.9.9.41.2.0.1 trap-var sysUpTime.0The following output is generated if the debug snmp packets command is enabled:
Router# debug snmp packets1d04h: SNMP: Queuing packet to 172.69.16.21d04h: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 172.19.rap 1clogHistoryEntry.3 = 4clogHistoryEntry.6 = 99991d04h: SNMP: Queuing packet to 172.19.208.1301d04h: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 172.19.rap 1clogHistoryEntry.3 = 4clogHistoryEntry.6 = 99991d04h: SNMP: Packet sent via UDP to 172.69.16.21d04h: SNMP: Packet sent via UDP to 172.69.16.2infra-view10:Packet Dump:30 53 02 01 00 04 04 63 6f 6d 6d a4 48 06 09 2b06 01 04 01 09 09 29 02 40 04 ac 13 d1 17 02 0106 02 01 01 43 04 00 9b 82 5d 30 29 30 12 06 0d2b 06 01 04 01 09 09 29 01 02 03 01 03 02 01 0430 13 06 0d 2b 06 01 04 01 09 09 29 01 02 03 0106 02 02 27 0fReceived SNMPv1 Trap:Community: commEnterprise: ciscoSyslogMIBNotificationPrefixAgent-addr: 172.19.209.23Enterprise Specific trap.Enterprise Specific trap: 1Time Ticks: 10191453clogHistSeverity = error(4)clogHistTimestamp = 9999The following example shows how to configure SNMP inform requests for the sysUpTime.0 variable:
Router(config)# event manager applet snmpRouter(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 5120000 poll-interval 90Router(config-applet)# action 1.3 info type snmp var sysUpTime.0 oid 1.3.6.1.4.1.9.9.43.1.1.6.1.3.41 integer 2Router(config-applet)# action 1.4 info type snmp inform trap-oid 1.3.6.1.4.1.9.9.43.2.0.1 trap-var sysUpTime.0 community public ipaddr 172.19.209.24The following output is generated if the debug snmp packets command is enabled:
Router# debug snmp packets1d04h: SNMP: Inform request, reqid 24, errstat 0, erridx 0sysUpTime.0 = 10244391snmpTrapOID.0 = ciscoConfigManMIB.2.0.1ccmHistoryEventEntry.3.40 = 11d04h: SNMP: Packet sent via UDP to 172.19.209.24.1621d04h: SNMP: Packet received via UDP from 172.19.209.24 on FastEthernet0/01d04h: SNMP: Response, reqid 24, errstat 0, erridx 01d04h: SNMP: Response, reqid 24, errstat 0, erridx 01d04h: SNMP: Inform request, reqid 25, errstat 0, erridx 0sysUpTime.0 = 10244396snmpTrapOID.0 = ciscoConfigManMIB.2.0.1ccmHistoryEventEntry.3.41 = 21d04h: SNMP: Packet sent via UDP to 172.19.209.24.1621d04h: SNMP: Packet received via UDP from 172.19.209.24 on FastEthernet0/01d04h: SNMP: Response, reqid 25, errstat 0, erridx 01d04h: SNMP: Response, reqid 25, errstat 0, erridx 0Router# debug snmp packets5d04h: SNMP: Packet received via UDP from 172.19.209.23 on FastEthernet0/05d04h: SNMP: Inform request, reqid 24, errstat 0, erridx 0sysUpTime.0 = 10244391snmpTrapOID.0 = ciscoConfigManMIB.2.0.1ccmHistoryEventEntry.3.40 = 15d04h: dest if_index = 15d04h: dest ip addr= 172.19.209.245d04h: SNMP: Response, reqid 24, errstat 0, erridx 05d04h: SNMP: Packet sent via UDP to 172.19.209.23.577485d04h: SNMP: Packet received via UDP from 172.19.209.23 on FastEthernet0/05d04h: SNMP: Inform request, reqid 25, errstat 0, erridx 0Configuring Variable Logic for EEM Applets: Examples
The following sections provide examples on some selected action commands. For information on all the action commands supporting variable logic within applets, see Table 6.
In this example, conditional loops while, if and foreach are used to print data. Other action commands such as action divide, action increment and action puts are used to define the actions to be performed when the conditions are met.
event manager applet printdata
event none
action 100 set colors "red green blue"
action 101 set shapes "square triangle rectange"
action 102 set i "1"
action 103 while $i lt 6
action 104 divide $i 2
action 105 if $_remainder eq 1
action 106 foreach _iterator "$colors"
action 107 puts nonewline "$_iterator "
action 108 end
action 109 puts ""
action 110 else
action 111 foreach _iterator "$shapes"
action 112 puts nonewline "$_iterator "
action 113 end
action 114 puts ""
action 115 end
action 116 increment i
action 117 end
When the event manager applet ex is run, the following output is obtained:
event manager run printdata
red green blue
square triangle rectange
red green blue
square triangle rectange
red green blue
In this example, two environment variables poll_interface and max_rx_rate are set to F0/0 and 3 respectively. Every 30 seconds there is a poll on an interface for rx rate. If the rx rate is greater than the threshold, a syslog message is displayed.
This applet makes use of the foreach conditional statement to poll the interface, the if conditional block to compare the value under RXPS with max_rx_rate that was set in the EEM environment variable.
event manager environment poll_interfaces F0/0
event manager environment max_rx_rate 3
ev man app check_rx_rate
ev timer watchdog name rx_timer time 30
action 100 foreach int $poll_interfaces
action 101 cli command "en"
action 102 cli command "show int $int summ | beg ------"
action 103 foreach line $_cli_result "\n"
action 105 regexp ".*[0-9]+\s+[0-9]+\s+[0-9]+\s+[0-9]+\s+[0-9]+\s+([0-9]+)\s+.*" $line junk rxps
action 106 if $_regexp_result eq 1
action 107 if $rxps gt $max_rx_rate
action 108 syslog msg "Warning rx rate for $int is > than threshold. Current value is $rxps (threshold is $max_rx_rate)"
action 109 end
action 110 end
action 111 end
action 112 end
Example syslog message:
Oct 16 09:29:26.153: %HA_EM-6-LOG: c: Warning rx rate for F0/0 is > than threshold. Current value is 4 (threshold is 3)
The output of show int F0/0 summ is of the format:
#show int f0/0 summ
*: interface is up
IHQ: pkts in input hold queue IQD: pkts dropped from input queue
OHQ: pkts in output hold queue OQD: pkts dropped from output queue
RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
TRTL: throttle count
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
-------------------------------------------------------------------------
* FastEthernet0/0 0 87283 0 0 0 0 0 0 0
Note
Configuring Event SNMP-Object: Examples
The following example shows the SET operation and the value to set is in $_snmp_value and it is managed by the script. The example below saves the oid and its value as contexts to be retrieved later.
event manager applet snmp-object1description "APPLET SNMP-OBJ-1"event snmp-object oid 1.3.6.1.2.1.31.1.1.1.18 type string sync no skip no istable yes default 0 action 1 syslog msg "SNMP-OBJ1:TRIGGERED" facility "SNMP_OBJ"action 2 context save key myoid variable "_snmp_oid"action 3 context save key myvalue variable "_snmp_value"Configuring Description of an EEM Applet: Examples
The following example shows how to add or modify the description for an Embedded Event Manager (EEM) applet that is run by sampling Simple Network Management Protocol (SNMP):
event manager applet testdescription "This applet looks for the word count in syslog messages"event syslog pattern "count"action 1 syslog msg hiWhere to Go Next
•
•
Additional References
The following sections provide references related to writing EEM policies Using the Cisco IOS CLI.
Related Documents
Standards
No new or modified standards are supported, and support for existing standards has not been modified.
—
