Arista EOS event-handler: Automate Actions on Switch Events

Arista EOS event-handler turns the switch into a small event-driven automation platform: instead of polling a monitoring system, you attach a bash action to a trigger and let the switch react the moment something happens. This guide walks through the trigger types that matter in production (boot, interface state change, log patterns and periodic timers), the delay semantics that make the handler safe, and the verification commands that prove the action actually ran. Every example uses real EOS CLI syntax so you can paste it into a lab switch and see the handler fire.

What an event-handler actually consists of

An event handler is three things bound together: a name, a trigger and an action. The trigger defines when, the delay defines how long after, and the action is a bash command or script that runs in the switch's Linux shell. Because the action runs in bash, the ceiling is high — you can send an email, touch a file, call a Python script on flash, restart a service or run another CLI command through Cli -p 15 -c.

switch(config)# event-handler eth_4
switch(config-event-eth_4)# action bash email x@yz.com -s "Et4 $OPERSTATE"
switch(config-event-eth_4)# trigger on-intf ethernet 4 operstatus
switch(config-event-eth_4)# delay 60
switch(config-event-eth_4)# exit
switch(config)#

The trigger above fires when the operational status of Ethernet 4 changes. EOS exports environment variables for the matching interface — $OPERSTATE is one of them — so the bash action can report exactly what happened without re-querying the switch.

Trigger types: boot, interface, logging and timers

on-boot

Use the boot trigger to run a script once the control plane is up. A 60 second delay is the usual choice because the switch needs a moment for protocols to converge before the script inspects them.

switch(config)# event-handler onStartup
switch(config-event-onStartup)# action bash /mnt/flash/startupScript1
switch(config-event-onStartup)# trigger onboot
switch(config-event-onStartup)# delay 60
switch(config-event-onStartup)# exit

on-intf

The interface trigger watches a specific interface and a specific condition, such as operstatus. It pairs well with upstream-facing links: when the uplink drops, the handler can log the current BGP state to flash so the next incident has evidence attached.

on-logging

Log-based triggers match a regular expression against syslog output. This is the classic pattern for "when the switch prints X, collect Y" — for example, capturing interfaces when a MACsec or MLAG message appears. Matching on a pattern rather than a timer avoids running the action on every unrelated message.

Periodic triggers

A time-based handler behaves like a cron job on the switch, but with the same action plumbing: useful for rotating a local log, pushing a config backup or writing a health snapshot every few minutes.

Why the delay statement matters

The delay is not cosmetic. Interface state changes often arrive in bursts (one flapping port can generate several transitions in a few seconds), and a handler without a delay will run its action once per transition. With a delay, EOS schedules the action after the timer expires, so a burst collapses into a single execution. For anything that writes to flash or emits a notification, always set a delay — 30 to 60 seconds is a reasonable starting point.

Verifying that handlers fire

EOS keeps per-handler statistics, which is the fastest way to tell an automation bug from an event that never happened.

switch# show event-handler
Event-handler onStartup
Trigger: onBoot delay 60 seconds
Action: /mnt/flash/startupScript1
Last Trigger Activation Time: 1 minutes 51 seconds ago
Total Trigger Activations: 1
Last Action Time: 51 seconds ago
Total Actions: 1

Read three fields: Total Trigger Activations tells you the event occurred, Total Actions tells you the bash action completed, and Last Action Time timestamps it. If activations climb while actions stay flat, the action itself is failing — test the script manually in bash first, then check file permissions on /mnt/flash.

Design rules worth following

• Keep the action idempotent. A handler can fire twice for the same logical incident; the script should tolerate that.
• Log locally before notifying. If the network is the thing that failed, an email action will fail too — write to flash or to a syslog server first.
• Name handlers after their purpose, not their interface, so the list stays readable as the switch ages.
• Remove handlers you no longer need: no event-handler onStartup deletes the definition cleanly.
• Version the scripts with the rest of your configuration so a replacement switch behaves identically.

Combined with a configuration baseline from the Arista EOS configuration cheat sheet and the interface knowledge in our Arista EOS MLAG configuration guide, event handlers give you a lightweight self-healing layer that costs nothing to run and needs no external orchestration server.

原文链接：https://www.arista.com/en/um-eos/eos-command-line-interface-cli