Network-Engineering | 7 min read

Arista – EOS Programmability

ngworx Team
December 2020
written by Francesco Vestri
Senior Network Engineer

Learn about Arista EOS Programmability and how it can make your life easier.


In the previous blog, we introduced the Arista EOS (Extensible Operative System) as the foundation of Arista Switches. We discussed that the EOS CLI is a familiar environment to manage the switch and it is enriched by the Bash Shell to fully access the underlying OS.

Both CLI and Bash Shell provide on-box access to the switch with a direct connection to the appliance accepting commands via an interactive interface.

In this article, we want to explore how EOS supports off-box access to the operative system, allowing management by an external software platform in an automated and harmonized manner. We will describe how the Arista switches were designed from the beginning with the concept of programmability in mind, and how this is obtained using both open protocols and customized frameworks. Finally, we will introduce CloudVision as the turnkey solution by Arista to leverage all this potential with an easily deployable and highly integrated platform.

Architected for Programmability

Arista Switches are devised from the ground up to be fully programmable. This level of programmability can be as simple as a Python script, or as complex as an SDK environment to compile C++ software embedded with the platform. On the intermediate level, we have modern and standardized ways to communicate with EOS on a software level: OpenConfig, eAPI, gRPC.

The main aspects where Arista focuses to deliver this level of programmability are:

  1. Single image delivery
  2. State Oriented approach
  3. True Linux Core

Arista EOS Programmability

Single Image delivery

Different models of Arista switches share the same binary image, meaning, a particular release and its installation files are adequate for all switch models deployed in an Arista solution. Having a single image running on multiple devices allows DevOps teams to write code once and test it on a single release, without further adaptation required for the rest of the infrastructure.
This saves implementation and testing times and leverages economies of scale.

State-Oriented approach

The approach adopted with EOS is to use a single, shared database, for all processes running on the switch to store and retrieve information: the NetDB. Running agents are never allowed to interact directly with each other, but they can communicate only by accessing common sections of the NetDB.

Arista EOS Programmability

This idea, together with a complete separation between the Forwarding and the Control Plane, leads to several benefits:

  • Stability: Crash of any individual process running on EOS has minimal, or no impact, on the rest of the platform. When the service comes back online, it can find the previously recorded state in the NetDB and resume its activity from there, without having to reinitialize and cause a network reconvergence.
  • Upgrade. A control plane service can be stopped, for example, to be replaced, and the new release started individually without the need to reboot the platform. As described above, upon restart, the new instance will read the state left by its predecessor in the NetDB and immediately resume operation without having to reinitialize and reinstruct the data plane.
  • ISSU. Similarly, the entire OS can be upgraded to a new release without having to take the box out of service. Once the forwarding plane is initialized and no reconverge event occurs on the network, the control plane can completely be taken out of service and reloaded with a new version of the OS. As seen before, the NetDB will maintain the appliance status unaltered and upon reloading, the various services will pick up where left off and without the need to reinitialize and cause a network reconvergence.
  • Programmability. With state of a process, NetDB also includes its configuration, that is, how the process is supposed to respond to initial and changing events. As a consequence, if we want to reprogram or change the way a process is currently working, we can act on the NetDB rather than on the process itself, and this is how Arista adopts off-box programmability.

True Linux Core

The foundation of the platform is an already familiar environment, known by an increasing number of programmers around the world and constantly updated by the community. New libraries and tools can be uploaded onto EOS to accommodate programming needs. Further, full access to the underlying Operative System removes any limitation to the appliance programmability.

Off-Net Programmability

One of the ways the NetDB enhances the programmability aspect of the switch is in the application of configuration changes. This is an advantage used internally by the Arista EOS programmability functions in the way they apply configuration changes directly to the NetDB, rather than communicating individually to each interested process. The advantages reflected back to the user by this adoption are multiple. In one way, we can always have the assurance that the configuration was applied the way we intended: by looking back at the new state of the NetDB, the application can immediately have a validation of the newly applied configuration. Another reflection of this approach is that the new change is applied en-bloc to the device.  Therefore, we don’t need to worry about applying the configuration following a specific sequence, but we can simply communicate the intention to the device in a declarative way and the whole block of configuration will be written on the NetDB to make system processes behave accordingly.

For Off-Net programmability, EOS-support includes standard data modelling-based APIs. In addition, EOS supports a specific approach known as Extensible API or eAPI.

Compared to a traditional API, the advantage of this approach is to use the same input format used by the CLI. For example, to read the code version of the platform using a Python script, we could simply use the command we already know from the CLI:

import pyeapi
import pprint

Arista1 = pyeapi.client.connect(

eapi = pyeapi.client.Node(Arista1)
version_info = eapi.run_commands(['show version',])

Notice the straightforward utilization of “show version” to instruct the switch on our intentions, and the output reflecting the same CLI experience of the “show version | json” command:

[{'architecture': 'i686',
  'bootupTimestamp': 1602756428.0,
  'configMacAddress': '00:00:00:00:00:00',
  'hardwareRevision': '',
  'hwMacAddress': '00:00:00:00:00:00',
  'internalBuildId': 'ab5c5f59-8afa-4250-a8c7-c645ba7cd7ed',
  'internalVersion': '4.25.0FX-LDP-RSVP-18741113.4250FXLDPRSVP',
  'isIntlVersion': False,
  'memFree': 1212344,
  'memTotal': 2014548,
  'mfgName': '',
  'modelName': 'vEOS',
  'serialNumber': '',
  'systemMacAddress': '50:00:00:d5:5d:c0',
  'uptime': 10020.84,
  'version': '4.25.0FX-LDP-RSVP'}]

The utilization of CLI commands within the eAPI has a tremendous advantage. It practically offers complete control of the platform by an external API tool. We are no longer limited by the available data models to configure our switch, but whatever function is possible via the standard CLI. It is also doable via software.


The purpose of this article on  Arista EOS Programmability was to elaborate further on the potential and flexibility offered by EOS with particular focus on its programmability aspects. But we could not do this without describing the fundamental concept at the base of EOS represented by the NetDB, a central repository of information providing stability, visibility and control. The idea of splitting state and compute is what makes these platforms so flexible and allows for tight integration with external tools. We explained how Arista bases their solutions on open protocol and this means, that this tight integration can be achieved using third party or custom-built software, but for users wanting a ready-made, turnkey platform, CloudVision offers an out of box application to bring automation into the network. Of course, CloudVision is much more than this, and we will continue to expand on this powerful tool. Here, we wanted to describe what makes all this possible: a uniform code, a powerful NetDB concept and an open underlying OS.

Feel free to message us if you have any further questions about Arista EOS Programmability.

ngworx Team
December 2020
written by Francesco Vestri
Senior Network Engineer

Most Popular

Network-Engineering | 8 min read

Junos upgrade – filesystem is full

Not enough storage during Junos upgrade (EX2300 and EX3400). An extension of Juniper's article…

Read more