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:
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.
switch#dir 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 arista-splunk-extension.swix fping-2.4b2-10.fc12.i686.rpm gnuplot.swix
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 switch(config-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:
- 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.
- On-Intf, as seen in the above example, provides an easy access trigger for events induced by some sort of change to an interface.
- On-startup-config, provides an easy way to run verifications or alerts upon configuration changes being applied
- VM-tracer triggers are generated when a VMware VM is migrating (VMotion), appearing or disappearing from the switch downlinks.
- 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:
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.