Cisco IOS XE EEM Applets: Event-Driven Automation

Embedded Event Manager turns a router into something that can defend itself during the minutes before a human logs in. An EEM applet pairs a trigger - a syslog pattern, an SNMP OID, an interface state change or a timer - with a sequence of actions such as running CLI commands, writing to syslog, sending email or invoking a Tcl policy. This guide covers the applet syntax used on IOS and IOS XE, the action vocabulary you will actually use in production, variable handling and the verification commands that prove the applet fired.

Anatomy of an applet

Every applet is registered with event manager applet and needs at least one event statement plus one or more numbered action statements. Actions execute in label order, and labels can be decimal so that new steps can be inserted later.

event manager applet LINK-FLAP-REPORT
 event syslog pattern "%LINK-3-UPDOWN"
 action 1.0 syslog msg "Interface event detected"
 action 2.0 cli command "enable"
 action 3.0 cli command "show interfaces | include line protocol"

Useful event triggers

• event syslog pattern "REGEX" - fires when a matching syslog message appears. The most common production trigger.
• event interface name GigabitEthernet0/1 parameter rx_crc - fires on interface counter changes.
• event snmp oid ... - reacts to an SNMP object crossing a threshold.
• event timer with count and period - periodic or one-shot scheduled execution.
• event none - no trigger; the applet runs only when invoked manually with event manager run, which is how you test before wiring a real trigger.
• event cli pattern "..." - fires when a matching CLI command is entered, useful for auditing configuration changes.

Actions: CLI, syslog, mail, special values

action 1.0 syslog priority warnings msg "CRC errors on $interface"
action 2.0 cli command "clear counters $interface"
action 3.0 mail server "10.1.1.20" to "noc@example.net" from "r1@example.net" \\
  subject "Link event" body "Interface $interface changed state"

Environment variables are referenced with a dollar sign. IOS populates a large set of built-in variables for each event type - $_event_pub_time, $_syslog_msg, $_interface_name - and you can define your own with event manager environment so that thresholds and mail targets are not hard-coded inside the policy.

Reading command output inside an applet

When you need to branch on CLI output, capture it into a variable and test it:

event manager applet CHECK-BGP
 event timer watchdog time 300
 action 1.0 cli command "enable"
 action 2.0 cli command "show ip bgp summary | include 10.0.0.1"
 action 3.0 set peers "$_cli_result"
 action 4.0 regexp " ([0-9]+)" "$peers" match prefixes
 action 5.0 if $_regexp_result eq 0
 action 6.0  syslog msg "BGP peer missing"
 action 7.0 end

That pattern - capture, regex, branch - is the backbone of almost every useful applet, and it is also the most error-prone. Test each step with event manager run and inspect show event manager history events between iterations.

Testing and troubleshooting

Router(config)# event manager applet TEST
Router(config-applet)# event none
Router(config-applet)# action 1.0 syslog msg "manual-policy triggered"
Router# event manager run TEST
Router# show event manager policy registered
Router# show event manager history events

If an applet never fires, check in this order: is the policy registered (show event manager policy registered), did the trigger pattern actually appear in the log, and did an earlier action fail silently. Applets run with the privileges configured for their policy, so a missing enable action is a frequent cause of "nothing happened".

EEM pairs well with other model-driven tooling. Compare approaches in gNMI streaming telemetry on IOS XE and Ansible Jinja2 templating for network devices.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/netmgmt/configuration/guide/Convert/Emb_EventMgr_xe/nm_eem_policy_cli_xe.html