6.6 Construct an EEM applet to automate configuration, troubleshooting, or data collection

Embedded Event Manager, usually called EEM, lets a Cisco device react to events locally.

That word locally matters. Ansible or Python runs outside the device. EEM runs on the device. It can watch for a syslog message, timer, CLI pattern, object tracking event, SNMP threshold, or other event, then run actions such as CLI commands or syslog messages.

For ENCOR, you should be able to construct a small applet for configuration, troubleshooting, or data collection.

EEM applet anatomy

A basic EEM applet has three parts:

event manager applet NAME
event <trigger>
action <number> <action>
action <number> <action>

Example:

event manager applet LOG_INTERFACE_DOWN
event syslog pattern "LINEPROTO-5-UPDOWN.*GigabitEthernet1.*down"
action 1.0 syslog msg "EEM noticed GigabitEthernet1 went down"

Read it in English:

• create an applet named LOG_INTERFACE_DOWN;
• trigger when a matching syslog message appears;
• write a new syslog message.

Event and action

This is the core exam idea.

The event is what starts the applet.

The action is what the applet does.

Common event examples:

event syslog pattern "..."
event timer watchdog time 300
event track 10 state down
event cli pattern "show running-config" sync no skip no

Common action examples:

action 1.0 syslog msg "message"
action 2.0 cli command "enable"
action 3.0 cli command "show clock | append flash:file.txt"
action 4.0 cli command "show ip interface brief | append flash:file.txt"

EEM event
action pipeline:
syslog pattern match --
register applet → syslog / cli / mail / ...
timer watchdog --
fire on schedule → ordered until list ends
track state change --
react to up/down → often starts with enable
cli pattern --
watch operator cmd → log or block (careful)

ENCOR-safe event
action patterns:
OSPF-5-ADJCHG.*Down
collect neighbor, route, log (no config change)
LINEPROTO.*down
collect interface + ip brief to flash
track N state down
optional recovery (loopback, description)
cli pattern "reload"
syslog who ran it (guardrail, not remediation)

Safe applet for data collection

This applet collects basic output when an OSPF neighbor goes down.

conf t
event manager applet OSPF_NEIGHBOR_DOWN_COLLECT
event syslog pattern "OSPF-5-ADJCHG.*Down"
action 1.0 syslog msg "EEM: OSPF neighbor down detected; collecting data"
action 2.0 cli command "enable"
action 3.0 cli command "terminal length 0"
action 4.0 cli command "show clock | append flash:ospf_down.txt"
action 5.0 cli command "show ip ospf neighbor | append flash:ospf_down.txt"
action 6.0 cli command "show ip route ospf | append flash:ospf_down.txt"
action 7.0 cli command "show logging | include OSPF | append flash:ospf_down.txt"
end

This is a good ENCOR-style applet because it automates troubleshooting without making a risky configuration change.

Safe applet for periodic collection

A watchdog timer runs repeatedly.

conf t
event manager applet PERIODIC_INTERFACE_SNAPSHOT
event timer watchdog time 300
action 1.0 cli command "enable"
action 2.0 cli command "show clock | append flash:interface_snapshot.txt"
action 3.0 cli command "show ip interface brief | append flash:interface_snapshot.txt"
action 4.0 syslog msg "EEM: interface snapshot saved"
end

This runs every 300 seconds.

Use this carefully. Periodic applets can fill flash if they append too much data for too long.

Applet for simple configuration

This example brings up a loopback when a tracked object goes down.

conf t
track 10 interface GigabitEthernet1 line-protocol
!
event manager applet TRACK_10_DOWN_LOOPBACK
event track 10 state down
action 1.0 syslog msg "EEM: track 10 down; enabling Loopback100"
action 2.0 cli command "enable"
action 3.0 cli command "configure terminal"
action 4.0 cli command "interface Loopback100"
action 5.0 cli command "description Enabled by EEM when track 10 went down"
action 6.0 cli command "ip address 192.0.2.100 255.255.255.255"
action 7.0 cli command "no shutdown"
end

This shows how EEM can automate configuration. In production, be careful with applets that change config automatically. They can help recovery, but they can also hide root causes or create loops.

Applet for command guardrail

This example catches a reload command and logs it. Do not blindly use command-blocking applets in production without approval; they can surprise operators.

conf t
event manager applet LOG_RELOAD_ATTEMPT
event cli pattern "reload" sync no skip no
action 1.0 syslog msg "EEM: reload command entered by $_cli_username"
end

EEM variables such as $_cli_username depend on the event detector and platform. Know the concept, not every variable.

Authorization and execution identity

CLI actions run under an execution context on the device. If AAA command authorization is enabled, the applet still needs enough privilege for the commands it runs. A policy can register and trigger but fail during an action if the execution identity is not authorized for configure terminal, show, file writes, or other commands.

Common pattern:

username eem-runner privilege 15 secret STRONG_EEM_SECRET
event manager session cli username eem-runner

Treat that user like any other privileged automation identity: use least privilege where supported, protect the secret, and keep accounting enabled.

When you verify an applet, prove three things:

Verification proof chain:
  show event manager policy registered
  lab trigger (shutdown / syslog / track change)
  show event manager history events
  show logging | include EEM
  flash:file.txt or expected config side effect

Verification commands

Useful checks:

show event manager policy registered
show event manager history events
show event manager environment
show running-config | section event manager
show logging | include EEM

Debugging:

debug event manager detector syslog
debug event manager action cli

Disable debugging when done:

undebug all

EEM design rules

Keep applets safe and small.

• Prefer data collection before automatic remediation.
• Include a syslog action so you can see that EEM ran.
• Avoid applets that repeatedly trigger themselves.
• Avoid long-running commands.
• Be careful with configure terminal actions.
• Do not append endlessly to flash without a cleanup plan.
• Test in a lab before production.

Use maxrun for applets that might take time, and keep the limit deliberate:

event manager applet OSPF_NEIGHBOR_DOWN_COLLECT maxrun 60
event syslog pattern "OSPF-5-ADJCHG.*Down"
action 1.0 syslog msg "EEM: OSPF neighbor down detected; collecting data"

Also avoid matching on a syslog message that the applet itself creates, and avoid automatic config changes that retrigger the same event. That is how a helpful applet turns into a loop.

Lab: collect data when an interface goes down

Goal

Create an EEM applet that collects interface data when a lab interface changes state to down.

Topology

One IOS XE router or switch. Use an interface that you can safely shut/no shut in a lab.

Task 1: create the applet

Adjust the interface name to match your lab.

conf t
event manager applet GI1_DOWN_COLLECT
event syslog pattern "LINEPROTO-5-UPDOWN.*GigabitEthernet1.*down"
action 1.0 syslog msg "EEM: GigabitEthernet1 down; collecting interface data"
action 2.0 cli command "enable"
action 3.0 cli command "terminal length 0"
action 4.0 cli command "show clock | append flash:gi1_down.txt"
action 5.0 cli command "show interfaces GigabitEthernet1 | append flash:gi1_down.txt"
action 6.0 cli command "show ip interface brief | append flash:gi1_down.txt"
end

Task 2: verify registration

show event manager policy registered
show running-config | section event manager

Task 3: trigger the event

conf t
interface GigabitEthernet1
 shutdown
 end

Task 4: verify output

show logging | include EEM
more flash:gi1_down.txt
show event manager history events

Task 5: restore the interface

conf t
interface GigabitEthernet1
 no shutdown
 end

Cleanup

conf t
no event manager applet GI1_DOWN_COLLECT
end
delete flash:gi1_down.txt

Exam traps

• An applet needs an event. Without an event, it has no trigger.
• Actions run in numeric order.
• CLI actions often need enable before privileged commands.
• EEM can collect data or change config, but changing config is riskier.
• event syslog pattern matches syslog text, so the pattern must match what the device actually logs.
• A timer applet can run forever and consume storage if poorly written.
• AAA command authorization can block EEM CLI actions unless the applet has a valid execution identity.

What to memorize

event manager applet NAME
event syslog pattern "PATTERN"
action 1.0 syslog msg "MESSAGE"
action 2.0 cli command "enable"
action 3.0 cli command "show ... | append flash:file.txt"

Also know:

show event manager policy registered
show event manager history events
show running-config | section event manager

Exam-ready summary

EEM is local device automation. Build the applet by choosing an event, then adding ordered actions. For ENCOR, focus on safe use cases: logging, data collection, simple troubleshooting, and controlled configuration changes. Always verify that the policy registered and that the expected syslog or file output exists.

Sources used

• Cisco ENCOR 350-401 v1.2 exam topics: https://learningcontent.cisco.com/documents/marketing/exam-topics/350-401-ENCORE-v1.2.pdf
• Cisco IOS XE EEM CLI applet configuration guide: https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/syst-mgmt/b-system-management/m_eem-policy-cli.html
• Cisco EEM best practices and useful scripts: https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xe-16/216091-best-practices-and-useful-scripts-for-ee.html