6.4EEM and orchestration

Automation comes in two families—what runs entirely inside the device and what governs devices from outside—and ENCOR covers both. The flagship of the former is EEM, whose defining trait is that the device itself holds a rule saying "when this event occurs, run this," operating with no external server or human in the loop. It shines exactly where a human cannot stand by, such as capturing information about a fault that flares for a moment at 3 a.m. and vanishes. The latter family is configuration management, where the design fork you are tested on is whether or not an agent resides on the target. Neither is merely a "handy tool"; treat both as choices driven by requirements—does it need autonomy, large-scale standardization, or is installing software on the device even possible?

6.4.1EEM applets: pairs of event and action

• EEM (Embedded Event Manager) is an automation facility built into IOS/IOS XE, with applets defined by event manager applet <name>. The body always consists of a pair—event (when it fires) and action (what it does)—and each action carries a number (a label setting execution order), executed in ascending order, so you write action 1.0, then action 2.0. Its defining strength is that it completes on the device alone, with no external server.
• There are three representative triggers (event). event syslog pattern "..." fires the moment a syslog message matching the given regular expression appears (e.g., an interface going down, or a lost adjacency). event timer cron/event timer watchdog fires at a time or interval (suited to periodic data collection). event cli pattern "..." fires when a specific CLI command is entered (for recording or suppressing dangerous commands). Choose among the three by "what should serve as the trigger."
• Representative actions include action 1.0 cli command "..." (running CLI on the device—gathering information with show or pushing configuration), action 2.0 syslog msg "..." (writing your own log), and action 3.0 mail ... (notification). To run configuration-changing CLI you must write the steps in order as actions—elevating with cli command "enable" and entering configure terminal—and you must also account for execution privileges, such as event manager session cli username <user>.

6.4.2External configuration management: agent-based vs. agentless

• Agent-based tools (Puppet, Chef) install a resident agent (software) on each managed target, and the agent periodically asks the master for configuration (a pull model). Being resident, it readily detects drift from the desired state continuously and self-heals (state convergence), but it presupposes deploying and maintaining an agent on every device.
• Agentless tooling (Ansible) installs nothing on the target, connecting from a control node over SSH (or APIs for network gear) to push configuration (a push model). It fits network devices where an agent cannot or should not be installed and is light to adopt, but since execution happens only when the control node runs, continuous drift detection must be supplied by scheduling.
• EEM and configuration-management tools are not competitors but play different roles. EEM excels at autonomous, immediate reaction to events on that device (working even when external systems are down), whereas Ansible and peers excel at rolling out and verifying one standard configuration across many devices at once. The decision axis is "do you need immediate response within one device, or horizontal rollout across many?"

At a branch router, the WAN-facing interface goes down for a few seconds and self-recovers during the small hours, several times a week. By morning a show reveals nothing—the device is already healthy and no clue remains. The operations team proposes "have someone stay awake every night," but this is the textbook case for EEM. Design begins with "what should be the trigger." Since the event emits a syslog message when the interface drops, you create event manager applet WAN-FLAP and trigger on a log match with event syslog pattern "%LINK-3-UPDOWN.*GigabitEthernet0/1.*down". Choosing event timer cron here would be wrong: because the fault occurs at unpredictable times, a periodic run cannot capture the moment it happens (it would collect only unrelated healthy-state data). For the actions, the goal is preserving the state at that instant, so action 1.0 syslog msg "WAN flap detected - collecting" marks the start of the record, action 2.0 cli command "enable" elevates privilege, and action 3.0 cli command "show interface GigabitEthernet0/1" and action 4.0 cli command "show logging | last 50" gather information in order. Because actions run in ascending numeric order, putting enable at a later number makes the commands requiring privilege fail first—the point most often tested in applet diagnosis is that the number is not a mere label but the execution order itself. If you thought "if a syslog can be the trigger, why not just monitor externally with Ansible," you would be missing EEM's essential advantage: because EEM completes inside the device, it still operates when the WAN is down and the external control node is unreachable. In precisely this kind of link-failure scenario, an external push mechanism cannot arrive at that moment. On the other hand, if a separate requirement arises to distribute the same applet to all 200 branch routers, that is where a configuration-management tool belongs. Since network devices typically cannot or should not host a resident agent, the natural fit is Ansible's agentless approach, pushing to each device over SSH, with a light footprint. Conversely, for something like a server fleet where agents can be installed and you want continuous self-healing whenever state drifts from the desired configuration, the pull model in which Puppet's or Chef's resident agent periodically fetches from the master is the better fit. To summarize: EEM = autonomous, immediate reaction to events within one device; Ansible = one-shot push of standard configuration to many; Puppet/Chef = continuous state convergence via a resident agent—three things that do not replace one another but combine per requirement.

6.4.3Section summary

• Read an EEM applet as a pair of event (trigger) and action (work), with actions executing in ascending numeric order—put prerequisites such as enable at a lower number
• Pick the trigger among event syslog pattern (immediate on a log match), event timer (time or interval), and event cli pattern (command entry), and never use a timer for a transient event with unpredictable timing
• For configuration management, Ansible is agentless, pushing over SSH, while Puppet/Chef use a resident agent that pulls and converges state; EEM's essential difference is that it completes on the device and works even when external systems are unreachable