- New and Changed Information
- Preface
- Overview
- Using the CFS Infrastructure
- Configuring System Message Logging
- Configuring Callhome
- Scheduling Maintenance Jobs
- Monitoring System Processes and Log
- Configuring Embeddded Event Manager
- Configuring RMON
- Configuring Generic Online Diagnostics
- Configuring SNMP
- Configuring Domain Parameters
- Monitoring Network Traffic Using SPAN
- Configuring Fabric Configuration Servers
- Configuring Port Pacer
Configuring the Embedded Event Manager
This chapter describes how to configure the EEM to detect and handle critical events on a device.
Information About EEM
Embedded Event Manager monitors events that occur on your device and takes action to recover or troubleshoot these events, based on your configuration.
This section includes the following topics:
- EEM Overview
- Policies
- Event Statements
- Action Statements
- VSH Script Policies
- Environment Variables
- High Availability
EEM Overview
EEM consists of three major components:
- Event statements—Events to monitor from another Cisco NX-OS component that may require some action, workaround, or notification.
- Action statements —Actions that EEM can take, such as sending an e-mail, or disabling an interface, to recover from an event.
- Policies—A combination of an event statement and an action statement. When the specified event occurs, the configured action is executed.
Policies
An EEM policy consists of an event statement and one or more action statements. The event statement defines the event to look for as well as the filtering characteristics for the event. The action statement defines the action EEM takes when the event occurs.
Figure 7-1 shows the two basic statements in an EEM policy.
Figure 7-1 EEM Policy Statements
You can configure EEM policies using the CLI or using a VSH script.
Note
EEM policy matching is not supported on MDS switches.
EEM maintains event logs on the supervisor.
Cisco NX-OS has a number of preconfigured system policies. These system policies define many common events and actions for the device. System policy names begin with two underscore characters (__).
The following are some of the preconfigured system policies available in Cisco MDS 9000 Series Switches and all the three policies are over-ridable:
– __zone_dbsize_max_per_vsan: Syslog warning when Zone database size exceeds the maximum limit for a vsan.
– __zone_members_max_per_sw: Syslog warning when Zone member count exceeds the maximum limit for the switch.
– __zone_zones_max_per_sw: Syslog warning when Zone count exceeds the maximum limit for the switch.
– __zone_zonesets_max_per_sw : Syslog warning when Zoneset count exceeds the maximum limit for the switch.
– __flogi_fcids_max_per_switch: Syslog warning when the number of flogis in the switch exceeds maximum limit.
– __flogi_fcids_max_per_module: Syslog warning when the number of flogis in the module exceeds maximum limit.
– __flogi_fcids_max_per_intf: Syslog warning when the number of flogis on the interface exceeds maximum limit.
Note During an In Service Software Upgrade (ISSU), EEM syslog messages for FLOGI are not printed in the terminal.
– __fcns_entries_max_per_switch : Configuring max limit for Name server entries verified across all VSANs per switch.
Note User should not configure an event for a different component's policy.
You can create user policies to suit your network. Actions defined by the user policies are executed along with the actions defined by the system policies. To configure a user policy, see the “Defining a User Policy Using the CLI” section.
You can also override some system policies. The override policies replace the system policies. You can override the event or the actions.
Use the show event manager system-policy command to view the preconfigured system policies and determine which policies that you can override.
To configure an overriding policy, see the “Overriding a Policy” section.
Note ● You should use the show running-config eem command to check the configuration of each policy. An override policy that consists of an event statement and no action statement triggers no action and no notification of failures.
- Your override policy should always include an event statement. An override policy without an event statement overrides all possible events in the system policy.
Event Statements
An event is any device activity for which some action, such as a workaround or a notification, should be taken. In many cases, these events are related to faults in the device such as when an interface or a fan malfunctions.
EEM defines event filters so only critical events or multiple occurrences of an event within a specified time period trigger an associated action.
Figure 7-2 shows events that are handled by EEM.
Event statements specify the event that triggers a policy to run. You can configure only one event statement per policy.
EEM schedules and runs policies on the basis of event statements. EEM examines the event and action commands and runs them as defined.
Action Statements
Action statements describe the action triggered by a policy. Each policy can have multiple action statements. If no action is associated with a policy, EEM still observes events but takes no actions.
EEM supports the following actions in action statements:
- Execute any CLI commands.
- Update a counter.
- Log an exception.
- Force the shut down of any module.
- Reload the device.
- Shut down specified modules because the power is over budget.
- Generate a syslog message.
- Generate a Call Home event.
- Generate an SNMP notification.
- Use the default action for the system policy.
Note If you want to allow the triggered event to process the default actions also, you must explicitly configure an EEM action with event-default or policy-default, based on the type of policy. For example, if you match a CLI command in a match statement, you must add the event-default action statement to the EEM policy. If the event-default action statement is not added, EEM will not allow the CLI command to execute.
Note Verify that your action statements within your user policy or overriding policy do not negate each other or adversely affect the associated system policy.
VSH Script Policies
You can also write policies in a VSH script, using a text editor. These policies have an event statement and action statement(s) just as other policies, and these policies can either augment or override system polices. After you write your script policy, copy it to the device and activate it. To configure a policy in a script, see the “Defining a Policy Using a VSH Script” section.
Environment Variables
You can define environment variables for EEM that are available for all policies. Environment variables are useful for configuring common values that you can use in multiple policies. For example, you can create an environment variable for the IP address of an external e-mail server.
You can use an environment variable in action statements by using the parameter substitution format.
Example 7-1 shows a sample action statement to force a module 1 shutdown, with a reset reason of “EEM action.”
If you define an environment variable for the shutdown reason, called default-reason, you can replace that reset reason with the environment variable, as shown in Example 7-2.
Example 7-2 Action Statement with Environment Variable
You can reuse this environment variable in any policy. For more information on environment variables, see the “Defining an Environment Variable” section.
EEM Event Correlation
Beginning with Cisco NX-OS Release 5.2, you can trigger an EEM policy based on a combination of events. First, you use the tag keyword to create and differentiate multiple events in the EEM policy. Then using a set of boolean operators ( and, or, andnot), along with the count and time, you can define a combination of these events to trigger a custom action.
High Availability
Cisco NX-OS supports stateless restarts for EEM. After a reboot or supervisor switchover, Cisco NX-OS applies the running configuration.
Licensing Requirements for EEM
The following table shows the licensing requirements for this feature:
|
|
|
|---|---|
EEM requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. |
Prerequisites for EEM
Guidelines and Limitations
EEM has the following configuration guidelines and limitations:
- Action statements within your user policy or overriding policy should not negate each other or adversely affect the associated system policy.
- If you want to allow the triggered event to process the default actions also, you must explicitly configure an EEM action with event-default or policy-default, based on the type of policy. For example, if you match a CLI command in a match statement, you must add the event-default action statement to the EEM policy or EEM will not allow the CLI command to execute.
- An override policy that consists of an event statement and no action statement triggers no action and no notification of failures.
- An override policy without an event statement overrides all possible events in the system policy.
- When more than one event statement is included in an EEM policy, each event statement must have a tag keyword with a unique tag argument.
- Although multiple overriding is blocked at application-level (FCNS/zone/FLOGI), blank applets can saved by overriding the system policy.
Default Settings
Table 7-1 lists the default settings for EEM parameters.
|
|
|
|---|---|
Configuring EEM
This section includes the following topics:
- Defining a User Policy Using the CLI
- Defining a Policy Using a VSH Script
- Registering and Activating a VSH Script Policy
- Overriding a Policy
Defining a User Policy Using the CLI
Detailed Steps
To define a user policy using the CLI, follow these steps:
|
|
|
|
|---|---|---|
Registers the applet with EEM and enters applet configuration mode. The applet-name can be any case-sensitive alphanumeric string up to 29 characters. |
||
(Optional) Configures a descriptive string for the policy. The string can be any alphanumeric string up to 80 characters. Enclose the string in quotation marks. |
||
Configures the event statement for the policy. See the “Configuring Event Statements” section. |
||
tag tagname1 { and | andnot | or } tagname2 [{ and | andnot | or } tagname3 [{ and | andnot | or } tagname4 ]] happens occurs in seconds |
(Optional) Correlates multiple events in the policy. The range for occurs is from 1 to 4294967295. The range for seconds is from 0 to 4294967295 seconds. |
|
Configures an action statement for the policy. See the “Configuring Action Statements” section. |
||
(Optional) Displays information about the configured policy. |
||
Configuring Event Statements
Detailed Steps
To configure an event statement, use one the following commands in EEM configuration mode:
Configuring Action Statements
Detailed Steps
To configure action statements, use the following commands in EEM configuration mode:
Note If you want to allow the triggered event to process the default actions also, you must explicitly configure an EEM action with event-default or policy-default, based on the type of policy. For example, if you match a CLI command in a match statement, you must add the event-default action statement to the EEM policy or EEM will not allow the CLI command to execute. You can bypass all CLI-based EEM policies using terminal event-manager bypass command. To revert use terminal no event-manager bypass command.
Defining a Policy Using a VSH Script
Detailed Steps
To define a policy using a VSH script, follow these steps:
Step 1 In a text editor, list the CLI commands that define the policy.
Step 2 Name the text file and save it.
Step 3 Copy the file to the following system directory:
bootflash://eem/user_script_policies
Registering and Activating a VSH Script Policy
Detailed Steps
To register and activate a policy defined in a VSH script, follow these steps:
Overriding a Policy
Detailed Steps
To override a system policy, follow these steps:
|
|
|
|
|---|---|---|
(Optional) Displays information about the system policy that you want to override, including thresholds. Use the show event manager system-policy command to find the system policy names. |
||
[ no ] event manager applet applet-name override system-policy |
Overrides a system policy and enters applet configuration mode. The applet-name can be any case-sensitive alphanumeric string up to 29 characters. The system-policy must be one of the existing system policies. |
|
(Optional) Configures a descriptive string for the policy. The string can be any alphanumeric string up to 80 characters. Enclose the string in quotation marks. |
||
Configures the event statement for the policy. See the “Configuring Event Statements” section. Using the no keyword deletes the overridden event, if any.
Note ● |
||
Configures an action statement for the policy. See the “Configuring Action Statements” section. Repeat Step 6 for multiple action statements.
Note ● |
||
(Optional) Displays information about the configured policy. |
||
Note Multiple overrides for Zone, FLOGI, and FCNS EEM policies are not allowed.
Defining an Environment Variable
Detailed Steps
To define a variable to serve as a parameter in an EEM policy, follow these steps:
Verifying the EEM Configuration
To display EEM configuration information, perform one of the following tasks:
Configuration Examples for EEM
This example overrides the __lcm_module_failure system policy by changing the threshold for just module 3 hitless upgrade failures. This example also sends a syslog message. The settings in the system policy, __lcm_module_failure, apply in all other cases.
event manager applet example2 override __lcm_module_failure
event module-failure type hitless-upgrade-failure module 3 count 2
action 1 syslog priority errors msg module 3 “upgrade is not a hitless upgrade!”
This example modifies an overridden policy by changing the number of FCNS database entries to 1500. It also generates both the configured and the default syslog messages of the default system policy.
This example deletes the event of an overridden policy:
This example creates an EEM policy that allows the CLI command to execute but triggers an SNMP notification when a user enters configuration mode on the device:
Note You must add the event-default action statement to the EEM policy or EEM will not allow the CLI command to execute.
Additional References
For additional information related to implementing EEM, see the following section:
MIBs
|
|
|
|---|---|
To locate and download MIBs, go to the following URL: http://www.cisco.com/en/US/products/ps5989/prod_technical_reference_list.html |
Feature History for EEM
Table 7-2 lists the release history for this feature. Only features that were introduced or modified in Release 3.x or a later release appear in the table.
Feedback