• Introduction to Managing EOS Devices – Automation and Extensibility

Print Friendly, PDF & Email

Note: This article is part of the Introduction to Managing EOS Devices series:




5) Automation and Extensibility


The Arista EOS facilitates task automation, provisioning, and extending capabilities on the Arista switches. The following features are available on all the platforms:

  • Managing extensions and applications
  • AEM: Event Manager
  • AEM: CLI Scheduler



5.1) Managing EOS Extensions


The most simple and efficient way to make the most of the extensibility on which EOS is built is through the use of extensions.  An extension is a pre-packaged optional feature or set of scripts in an RPM or SWIX format.  A variety of extensions are available from the EOS Central page found at http://eos.arista.com.


1) First download the desired extension and copy it onto the device’s flash.

Directory of flash:/

      -rwx   479183792           Jun 23 09:46  EOS-4.13.3F.swi
      -rwx    21280296            Feb 6 16:48  arista-splunk-extension.swix
      -rwx          27           Jun 23 10:08  boot-config
      drwx        4096           Sep 26  2012  schedule
      -rwx        1481           Jun 27 05:54  startup-config


2) Next, copy the file from flash to the extensions partition.

switch#copy flash:arista-splunk-extension.swix extension:
Copy completed successfully.


3) Next, install the extension:

switch#extension arista-splunk-extension.swix
If this extension modifiers the behavior of the Cli, any running Cli sessions will
need to be reset in order for the Cli modifications to take effect.


4) Finally run the extension

As the CloudVision extension adds additional CLI commands to EOS the CLI session must be restarted in order from them to appear.  To achieve this, close the ssh/telnet session and establish a new one.

To verify the extension has been installed correctly use the ‘show extensions’ command.

switch#show extensions
Name                                       Version/Release           Status extension
------------------------------------------ ------------------------- ------ ----
EosSdk-1.2.1-fl.boca-1943435.i686.rpm      1.2.1/1943435.flbocaeossd A, NI     1
arista-splunk-extension.swix               0.95/1498976.2013ltdsplun A, I      2
fping-2.4b2-10.fc12.i686.rpm               2.4b2/10.fc12             A, I      1
gnuplot.swix                               1.10.0/1.fc14             A, I     16
splunkforwarder-5.0.9-213964.i386.rpm      5.0.9/213964              A, NI     1

A: available | NA: not available | I: installed | NI: not installed | F: forced


By default the extension will not persist between reloads.  If extension persistence is required the extension must also be copied into the boot-extensions partition.

switch#copy installed-extensions boot-extensions

In order to determine which extensions are currently enabled for boot persistence the ‘show boot extensions’ command can be used.

switch#show boot-extensions

In order to uninstall an extension use the ‘no’ form of the extension command, then push the installed-extensions to the boot-extensions list.

switch#no extension fping-2.4b2-10.fc12.i686.rpm
switch#show extensions
Name                                       Version/Release           Status extension
------------------------------------------ ------------------------- ------ ----
EosSdk-1.2.1-fl.boca-1943435.i686.rpm      1.2.1/1943435.flbocaeossd A, NI     1
arista-splunk-extension.swix               0.95/1498976.2013ltdsplun A, I      2
fping-2.4b2-10.fc12.i686.rpm               2.4b2/10.fc12             A, NI     1
gnuplot.swix                               1.10.0/1.fc14             A, I     16
splunkforwarder-5.0.9-213964.i386.rpm      5.0.9/213964              A, NI     1

A: available | NA: not available | I: installed | NI: not installed | F: forced


5.2) Advanced Event Management

Proactive tools include Event Manager and the Scheduler; which focus on automation.  Both tools enable scripted actions to take place in response to a pre-defined trigger.  When leveraged alongside SYSDB and the wealth of Linux tools that can be run on an the EOS platform, the user is offered the capability to trigger actions on virtually any aspect of system state, all without the requirement for real time user input !


5.2.1) Event Manager

Event Manager provides a platform to enable automation of actions in response to pre-defined event triggers.  It allows the creation of an event, the definition of under which circumstances the event should trigger and what action should occur in such a situation, for example:


Event – PIM DR & VRRP Active Failover

Trigger – If the uplinks go down,

Action – Call a bash script stored in flash that reduces the PIM and VRRP priority so the impacted device is no longer the DR/Active Forwarder.


switch(config)#event-handler PIM-VRRP-SWITCH
 action        Define event-handler action
 asynchronous  Set the action to be non-blocking
 delay         Configure event-handler delay
 timeout       Set the expected time the action should finish in
 trigger       Configure event trigger condition

switch(config-handler-PIM-VRRP-SWITCH)#trigger ?
 on-boot            trigger condition occurs on system boot
 on-intf            trigger condition occurs on specified interface changes
 on-startup-config  trigger condition occurs on startup config changes
 vm-tracer          trigger condition occurs on VmTracer events

switch(config-handler-PIM-VRRP-SWITCH)#trigger on-intf Et1 operstatus
switch(config-handler-PIM-VRRP-SWITCH)#action DRchange.sh
switch# dir
Directory of flash:/
-rwx1170Oct 9 22:15DRchange.sh


Advanced Event Manager contains different triggers:

  1. On-Boot which triggers an action upon the device bootup.  Typically this can be used to copy, or start extensions, or to call or daemonize python scripts.  OnBoot represents the most powerful trigger mechanism, as the script or binary you call can be run as a daemon, then call eAPI/SDK instruction, allowing you to trigger based on essentially any value or attribute.
  2. On-Intf, as seen in the above example, provides an easy access trigger for events induced by some sort of change to an interface.
  3. On-startup-config, provides an easy way to run verifications or alerts upon configuration changes being applied
  4. VM-tracer triggers are generated when a VMware VM is migrating (VMotion), appearing or disappearing from the switch downlinks.
  5. Additionally, Arista propose an extension that allow customers to generate custom triggers, based on any pattern detected in Syslog messages.


Once an event has been triggered the configured action will be executed, this action will be initiated natively from the Linux bash shell, which means the action is not limited by the EOS CLI syntax, but rather any function or action achievable natively in the Linux bash shell.  Typical examples of actions would be to call a file, call a script, execute a native bash command or even EOS CLI commands, for example:

  • Call a bash script – action bash /mnt/flash/EmailOnLinkDown
  • Call a python script to run as a daemon – action bash daemonize /mnt/flash/IntfMonitor
  • Execute a single CLI command, which sends an IM to all Network admins – action bash FastCli -p15 -c ‘xmpp send NetworkAdmins command Interface Ethernet1 is down’
  • Execute a series of CLI commands, which bring down a particular interface – action bash FastCli -p15 -c $’conf\n interface ethernet2\n shut’


Due to the ability to trigger on virtually anything, and carry out virtually any action, the use cases for event-manager are incredibly vast, providing a serious option for automating a huge range of proactive tasks, or reactive actions.


A more in-depth look at event-handler can be found in the following EOS article:

Email client configuration in EOS


5.2.2) Scheduler

While the Advance Event Manager enables actions based on complex triggers, the scheduler provides a similar functionality to repetitive time based triggers. The major addition to the Scheduler is that it captures the standard output of an action to a gzipped file in flash, and enables the user to configure how many of these files they wish to keep at any one time.

To create a scheduled job, a user simply defines how often a task should run, how many log files it should store, and what the job should be. Optionally the user can also define a time and/or date when the scheduled task should run for the first time, enabling post dated or synchronous execution of tasks over multiple devices.

schedule tech-support [at <hh:mm:ss> <mm:dd:yyy>] interval <minutes> max-log-files <qty> command <command to execute>


Unlike Event-manager, this command is executed natively in EOS, however by prepending the ‘bash’ argument   we can execute bash commands and call scripts, for example ‘command bash /mnt/flash/ConfigBackup’.

By default EOS has a scheduled task configured to collect a show tech every 60 minutes and store up to 100 instances of the show tech, ensuring that following an issue we have both the pre and post issue data that we need to assist with analysis.

switch#show run all | grep schedule
schedule tech-support interval 60 max-log-files 100 command show tech-support

If it is not required for the scheduled task to collect any form of output, selecting a max-log-files of 1 allows the scheduler to function as a standard Cron job.



Get every new post on this blog delivered to your Inbox.

Join other followers: