About EEM
EEM monitors events that occur on your device and takes action to recover or troubleshoot these events, based on your configuration.
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—An action that EEM can take, such as executing CLI commands, sending an email through the use of Smart Call Home feature, and disabling an interface to recover from an event.
-
Policies—An event that is paired with one or more actions to troubleshoot or recover from the event.
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.
This figure shows the two basic statements in an EEM policy.
You can configure EEM policies using the command-line interface (CLI) or a VSH script.
EEM gives you a device-wide view of policy management. You configure EEM policies on the supervisor, and EEM pushes the policy to the correct module based on the event type. EEM takes any actions for a triggered event either locally on the module or on the supervisor (the default option).
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 (__).
You can create user policies to suit your network. If you create a user policy, any actions in your policy occur after EEM triggers any system policy actions that are related to the same event as your policy.
You can also override some system policies. The overrides that you configure take the place of the system policy. 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.
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. |
Note |
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.
This figure shows events that are handled by EEM.
Event statements specify the event that triggers a policy to run. You can configure multiple event triggers.
EEM schedules and runs policies on the basis of event statements. EEM examines the event and action commands and runs them as defined.
Note |
If you want to allow the triggered event to process any default actions, you must configure the EEM policy to allow the event default action statement. |
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 shutdown 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 |
EEM can only process a complete action cli list of up to 1024 characters in total. If more actions are required, you must define them as a new redundant applet with same trigger. |
Note |
If you want to allow the triggered event to process any default actions, you must configure the EEM policy to allow the default action. 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. |
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 policies. After you write your VSH script policy, copy it to the device and activate it.
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 email server.
You can use an environment variable in action statements by using the parameter substitution format.
This example shows a sample action statement to force a module 1 shutdown, with a reset reason of "EEM action."
switch (config-eem-policy)# action 1.0 forceshut module 1 reset-reason “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 the following example.
switch (config-eem-policy)# action 1.0 foreshut module 1 reset-reason $default-reason
You can reuse this environment variable in any policy.
EEM Event Correlation
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.
Virtualization Support
Not all actions or events are visible. You must have network-admin privileges to configure policies.