Introduction to Arista EOS
Arista Extensible Operating System (EOS) is the network operating system powering all Arista switches and routers. First introduced in 2008, EOS was engineered from the ground up with a fundamentally different philosophy than traditional network operating systems like Cisco IOS. Where IOS was designed in an era when network devices were purpose-built appliances with tightly coupled hardware and software, EOS was built on a modular, Linux-based architecture that treats the network OS as a distributed application rather than a monolithic firmware image.
This article examines the core architecture of Arista EOS, its operational model, and how it compares to Cisco IOS across key dimensions including CLI syntax, process isolation, programmability, upgrade procedures, and operational tooling. Whether you are migrating from a Cisco environment or evaluating platforms for a greenfield data center deployment, understanding these architectural differences is essential for operating EOS-based networks correctly.
The Foundation: Linux vs. Monolithic Architecture
Cisco IOS and its successors — IOS-XE, IOS-XR, and NX-OS — all have roots in a monolithic or semi-monolithic architecture. Traditional IOS runs as a single process image, meaning all subsystems including routing protocols, SNMP, CLI, and spanning tree share the same memory space and execution context. A memory corruption bug in one subsystem can destabilize the entire platform. IOS-XE made progress by running the IOS daemon on top of a Linux kernel, but the internal coupling between subsystems still reflects legacy design constraints.
Arista EOS, by contrast, is built entirely on a standard Linux kernel. The underlying OS is a hardened Linux distribution, and every EOS component — including the CLI shell, routing protocol daemons, telemetry agents, and ASIC hardware drivers — runs as an independent Linux process. This is not a marketing abstraction. You can drop into a Linux bash shell directly on an EOS device, inspect running processes with
ps aux, install Python packages, write systemd unit files, or tail logs in
/var/log/. The device is a Linux server with a network forwarding ASIC attached to it.
SysDB: The Central State Database
The single most architecturally significant feature of EOS is SysDB (System Database). SysDB is an in-memory, publish-subscribe state store that serves as the single source of truth for all system state on the device. Every agent in EOS — whether it is the BGP daemon, the spanning tree process, the interface manager, or a custom user-written daemon — reads from and writes to SysDB. No agent communicates directly with another agent. All inter-process communication happens exclusively through SysDB.
In Cisco IOS, subsystems communicate through shared memory regions, direct function calls, and proprietary IPC mechanisms. This tight coupling means that if the routing process crashes or corrupts shared memory, it can cascade and destabilize the entire system. In EOS, because every agent is isolated and communicates only through SysDB, a crashed agent can be restarted independently without affecting any other component. The hardware forwarding state programmed into the ASIC remains intact even while a control-plane daemon restarts.
Key insight: SysDB is the architectural reason EOS can perform hitless software upgrades, in-service restarts of individual routing daemons, and non-disruptive agent updates — capabilities that are either absent from traditional IOS or require specific dual-supervisor hardware and complex SSO configuration to approximate.
CLI Comparison: EOS vs. IOS Syntax
For engineers coming from a Cisco background, the EOS CLI feels immediately familiar. Arista deliberately designed the command syntax to mirror IOS as closely as practical, reducing the retraining burden for Cisco-trained staff. However, several differences will cause problems if you assume the CLIs are identical.
Interface Configuration
On Cisco IOS, configuring an interface with an IP address looks like this:
interface GigabitEthernet0/1
description uplink-to-core
ip address 10.10.10.1 255.255.255.0
no shutdownOn Arista EOS (sw-infrarunbook-01), the equivalent configuration is:
sw-infrarunbook-01(config)# interface Ethernet1
sw-infrarunbook-01(config-if-Et1)# description uplink-to-core
sw-infrarunbook-01(config-if-Et1)# ip address 10.10.10.1/24
sw-infrarunbook-01(config-if-Et1)# no shutdownTwo differences stand out immediately. First, EOS uses CIDR prefix notation (10.10.10.1/24) rather than dotted-decimal subnet masks. Second, the interface prompt abbreviates to the short name (Et1). Most importantly, EOS interface names use Ethernet regardless of physical speed — a 100G port is still Ethernet49, not HundredGigabitEthernet49. Speed is a property of the transceiver, not encoded in the interface name.
VLAN Configuration
VLAN configuration follows the same two-step model as IOS but with slightly cleaner syntax:
sw-infrarunbook-01(config)# vlan 100
sw-infrarunbook-01(config-vlan-100)# name servers-prod
sw-infrarunbook-01(config-vlan-100)# state active
sw-infrarunbook-01(config)# interface Ethernet5
sw-infrarunbook-01(config-if-Et5)# switchport mode access
sw-infrarunbook-01(config-if-Et5)# switchport access vlan 100
sw-infrarunbook-01(config)# interface Ethernet10
sw-infrarunbook-01(config-if-Et10)# switchport mode trunk
sw-infrarunbook-01(config-if-Et10)# switchport trunk allowed vlan 100,200,300BGP Configuration
EOS BGP syntax diverges more noticeably from IOS, particularly around address-family activation. Here is an iBGP peering on sw-infrarunbook-01 establishing a session with a route reflector at 10.0.0.1:
sw-infrarunbook-01(config)# router bgp 65001
sw-infrarunbook-01(config-router-bgp)# router-id 10.0.1.1
sw-infrarunbook-01(config-router-bgp)# neighbor 10.0.0.1 remote-as 65001
sw-infrarunbook-01(config-router-bgp)# neighbor 10.0.0.1 description rr-spine-01
sw-infrarunbook-01(config-router-bgp)# neighbor 10.0.0.1 update-source Loopback0
sw-infrarunbook-01(config-router-bgp)# neighbor 10.0.0.1 send-community extended
sw-infrarunbook-01(config-router-bgp)# address-family evpn
sw-infrarunbook-01(config-router-bgp-af)# neighbor 10.0.0.1 activateEVPN is a native, first-class address family in EOS. There is no need for separate feature flags or image licensing to enable it. On Cisco NX-OS, enabling EVPN requires
nv overlay evpnand
feature bgpalongside explicit
l2vpn evpnaddress-family configuration — a multi-step process spread across different configuration stanzas.
Process Model: Agents vs. IOS Subsystems
Every functional component in EOS is an agent — an independent Linux process registered with SysDB. You can inspect all running agents and their resource usage with the
show agentcommand:
sw-infrarunbook-01# show agent
Agent Version CPU% Memory Status
-------- ------- ---- -------- -------
Bgp 4.29.0F 0.3 148.6 MB running
Isis 4.29.0F 0.1 91.2 MB running
Mlag 4.29.0F 0.1 66.8 MB running
Stp 4.29.0F 0.0 43.1 MB running
Lldp 4.29.0F 0.0 39.7 MB running
Snmp 4.29.0F 0.0 54.3 MB running
EventMon 4.29.0F 0.0 31.2 MB running
TerminAttr 1.19.2 0.1 72.4 MB runningIn Cisco IOS, these subsystems are compiled into the same monolithic image and share the same process memory. You cannot restart the BGP subsystem without potentially disrupting other components or the CLI itself. In EOS, you can restart the BGP agent on demand:
sw-infrarunbook-01# agent Bgp restartThe forwarding plane continues operating uninterrupted during the restart. BGP sessions drop briefly as the agent reinitializes, but hardware FIB entries programmed into the ASIC are not flushed. Traffic already being forwarded via existing FIB entries continues to flow. This is fundamentally different from Cisco's SSO model, which requires dedicated supervisor redundancy hardware and explicit configuration of NSF (Non-Stop Forwarding) and NSR (Non-Stop Routing).
Programmability: Python, eAPI, and OpenConfig
Arista EOS has had native Python support since EOS 4.13. Because the platform runs standard Linux, Python scripts execute directly on the device, interact with EOS state via the PyEAPI library, and can use any Python package installable via pip.
eAPI: JSON-RPC Over HTTP
EOS exposes a JSON-RPC API called eAPI that accepts any EOS CLI command and returns structured JSON output. Enable it on sw-infrarunbook-01 with:
sw-infrarunbook-01(config)# management api http-commands
sw-infrarunbook-01(config-mgmt-api-http-cmds)# protocol https
sw-infrarunbook-01(config-mgmt-api-http-cmds)# no shutdown
sw-infrarunbook-01(config-mgmt-api-http-cmds)# vrf managementOnce active, any automation host can query the device using a simple HTTP POST. Here is an example using curl from a jump host at 10.0.0.5, targeting the switch management IP at 10.0.0.10:
curl -s -k -u infrarunbook-admin:P@ssw0rd \
-H "Content-Type: application/json" \
-X POST https://10.0.0.10/command-api \
-d '{
"jsonrpc": "2.0",
"method": "runCmds",
"params": {
"version": 1,
"cmds": ["show version", "show ip bgp summary"],
"format": "json"
},
"id": "infrarunbook-query-01"
}'Cisco IOS-XE offers RESTCONF over YANG models and NETCONF, but these require understanding device-specific YANG model paths and encoding structured payloads. Arista eAPI simply accepts CLI strings and returns the same data your terminal would display, structured as JSON — dramatically lowering the barrier for automation scripting.
OpenConfig and gNMI Streaming Telemetry
EOS has native support for OpenConfig YANG data models and the gNMI (gRPC Network Management Interface) protocol, enabling vendor-neutral streaming telemetry and configuration management. Enable gNMI on EOS with:
sw-infrarunbook-01(config)# management api gnmi
sw-infrarunbook-01(config-mgmt-api-gnmi)# transport grpc default
sw-infrarunbook-01(config-mgmt-api-gnmi)# vrf managementThis enables tools like Telegraf, Grafana, and any OpenConfig-compliant NMS to subscribe to telemetry streams using the standardized gNMI Subscribe RPC. EOS ships with TerminAttr, Arista's dedicated streaming telemetry agent, which pushes device state to CloudVision or any external gNMI collector at sub-second intervals. Cisco has added gNMI to IOS-XE and NX-OS, but the breadth of OpenConfig path support in EOS and the maturity of the TerminAttr agent give Arista a meaningful operational advantage for telemetry-driven observability stacks.
MLAG: Multi-Chassis Link Aggregation
MLAG (Multi-Chassis Link Aggregation Group) is Arista's implementation of active-active switch redundancy — analogous to Cisco vPC on Nexus platforms or VSS on Catalyst. MLAG allows two physical switches to present as a single logical aggregation endpoint to downstream devices, eliminating blocked uplinks from Spanning Tree while providing hardware-level redundancy.
A baseline MLAG configuration on sw-infrarunbook-01 paired with a second peer switch:
sw-infrarunbook-01(config)# vlan 4094
sw-infrarunbook-01(config-vlan-4094)# trunk group mlag-peer
sw-infrarunbook-01(config)# interface Vlan4094
sw-infrarunbook-01(config-if-Vl4094)# description mlag-peer-heartbeat
sw-infrarunbook-01(config-if-Vl4094)# ip address 169.254.0.1/30
sw-infrarunbook-01(config)# mlag configuration
sw-infrarunbook-01(config-mlag)# domain-id infrarunbook-mlag-domain
sw-infrarunbook-01(config-mlag)# local-interface Vlan4094
sw-infrarunbook-01(config-mlag)# peer-address 169.254.0.2
sw-infrarunbook-01(config-mlag)# peer-link Port-Channel1
sw-infrarunbook-01(config-mlag)# reload-delay mlag 300
sw-infrarunbook-01(config-mlag)# reload-delay non-mlag 330Unlike Cisco vPC, MLAG does not require a separate out-of-band keepalive link — the MLAG heartbeat runs over the peer-link VLAN itself. MLAG is also considerably simpler to configure than Cisco VSS, which requires physical stacking cables and a more complex chassis synchronization protocol that effectively merges two switches into one logical supervisor domain.
Zero Touch Provisioning
EOS supports ZTP (Zero Touch Provisioning) natively. When a factory-fresh EOS device boots without a startup configuration, it enters ZTP mode, obtains network parameters via DHCP, and downloads its provisioning artifact from the URL specified in DHCP option 67. That artifact can be a static EOS startup-config file or an executable Python script that performs complex, dynamic provisioning logic.
# ISC DHCP server snippet — DHCP option 67 for EOS ZTP
subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.1;
option domain-name-servers 10.0.0.2;
option bootfile-name "http://10.0.0.5/ztp/provision-sw.py";
}A ZTP Python script running on sw-infrarunbook-01 at first boot can query a CMDB API by MAC address, generate a device-specific configuration, write it to the flash startup-config, register the device in DNS at solvethenetwork.com, and send an alert notification — all before the device becomes operational. Cisco AutoInstall supports downloading a startup-config via TFTP, but it does not support executable scripts, making Arista ZTP dramatically more powerful for large-scale, automated provisioning workflows.
Software Upgrades and the EOS Image Model
Cisco IOS uses a monolithic image model: upgrading the OS means replacing the entire running image binary and performing a full reload. EOS uses a different approach — the EOS image is a self-contained package mounted as a read-only filesystem overlay. On supported hardware platforms, EOS supports ISSU (In-Service Software Upgrade) with dual supervisors. On single-supervisor platforms, upgrades still require a reload, but the image staging and verification process is cleaner and more predictable.
To stage a new EOS image on sw-infrarunbook-01 and set it as the boot target:
sw-infrarunbook-01# copy scp://infrarunbook-admin@10.0.0.5/images/EOS-4.29.2F.swi flash:
sw-infrarunbook-01# boot system flash:EOS-4.29.2F.swi
sw-infrarunbook-01# show boot-extensions
sw-infrarunbook-01# show version
sw-infrarunbook-01# reloadEOS also supports extension packages — separate software modules installable on top of the base EOS image without touching the core OS. This allows you to deploy monitoring daemons, custom event handlers, and third-party integrations as RPM packages that survive across OS upgrades when pinned correctly.
CloudVision: Centralized State and Automation Platform
Arista's CloudVision Platform (CVP) is the centralized management, streaming telemetry, and network automation platform for EOS environments. Unlike Cisco DNA Center, which focuses primarily on intent-based policy abstraction, CVP provides a network-wide state database — architecturally analogous to SysDB on a per-device level — that stores the full configuration and telemetry history of every device in the fabric.
CVP integrates with EOS through a persistent streaming telemetry connection using TerminAttr and gNMI, giving you real-time visibility into device state without SNMP polling cycles. Every configuration change, BGP state transition, interface event, and ASIC counter is captured, timestamped, and indexed in CVP's time-series database. This enables network-wide root-cause analysis that compares the timeline of events across all devices simultaneously — a capability that requires significant third-party tooling to replicate in a Cisco environment relying on syslog aggregation and SNMP traps.
BGP EVPN and VXLAN: Native Data Center Fabric Support
Both EOS and Cisco IOS-XE support BGP EVPN with VXLAN for building scalable Layer 2 and Layer 3 data center fabrics. However, EOS treats EVPN as a native, first-class BGP address family with tightly integrated VXLAN data-plane support. Here is a complete MAC-VRF and VTEP configuration for VLAN 100 on sw-infrarunbook-01:
sw-infrarunbook-01(config)# router bgp 65001
sw-infrarunbook-01(config-router-bgp)# vlan 100
sw-infrarunbook-01(config-macvrf-100)# rd 10.0.1.1:100
sw-infrarunbook-01(config-macvrf-100)# route-target both 65001:100
sw-infrarunbook-01(config-macvrf-100)# redistribute learned
sw-infrarunbook-01(config)# interface Vxlan1
sw-infrarunbook-01(config-if-Vx1)# vxlan source-interface Loopback1
sw-infrarunbook-01(config-if-Vx1)# vxlan udp-port 4789
sw-infrarunbook-01(config-if-Vx1)# vxlan vlan 100 vni 10100
sw-infrarunbook-01(config-if-Vx1)# vxlan learn-restrict anyThe per-VLAN MAC-VRF stanza directly under
router bgpis clean and self-contained. The equivalent Cisco NX-OS configuration requires separate
evpnstanzas,
nv overlay evpnglobal configuration, and
fabric forwarding anycast-gatewayfor distributed gateway — spread across multiple configuration sections that are harder to audit as a single unit.
Conclusion
Arista EOS represents a fundamental rethinking of what a network operating system can be. Its Linux-based foundation, SysDB-centric process isolation model, native Python environment, eAPI, first-class OpenConfig and gNMI support, and production-grade BGP EVPN implementation place it in a different architectural category from Cisco IOS and even IOS-XE. The CLI surface area is intentionally familiar to reduce migration friction, but the underlying engineering enables operational capabilities — hitless agent restarts, Python-driven ZTP, sub-second streaming telemetry, and unified CloudVision state management — that require significant additional tooling complexity to achieve on Cisco platforms.
For infrastructure engineers building modern spine-leaf data center fabrics or managing large-scale campus networks, understanding these architectural differences is not just academic. It determines how you design upgrade procedures, how you build automation pipelines, how you troubleshoot production incidents, and how you scale your operational team's capabilities. EOS rewards engineers who invest in understanding its architecture with a platform that is simultaneously easier to automate and more transparent to debug.
Frequently Asked Questions
Q: What does EOS stand for in Arista networking?
A: EOS stands for Extensible Operating System. The name reflects its core design principle: the OS is built from independently extensible agents, each running as a separate Linux process, rather than as a single monolithic firmware image.
Q: Is Arista EOS CLI compatible with Cisco IOS commands?
A: EOS CLI syntax is deliberately modeled after Cisco IOS to reduce the learning curve for Cisco-trained engineers. Most interface, VLAN, and routing commands will be recognizable. Key differences include CIDR notation for IP addresses, the use of Ethernet instead of GigabitEthernet in interface names, and some BGP address-family syntax variations.
Q: What is SysDB in Arista EOS and why does it matter?
A: SysDB is EOS's in-memory, publish-subscribe state database. Every agent reads from and writes to SysDB instead of communicating directly with other processes. This isolation means a crashing daemon can be restarted independently without affecting the forwarding plane or other control-plane components — a significant reliability advantage over monolithic IOS architectures.
Q: Can I run Python scripts directly on an Arista EOS switch?
A: Yes. EOS runs on a standard Linux kernel, so you can execute Python scripts natively on the device, use the PyEAPI library to read and modify device state, and install additional Python packages via pip from the bash shell. This enables on-box automation, custom event handlers via EEM equivalents, and integration with external APIs.
Q: How does MLAG in Arista EOS compare to Cisco vPC on Nexus?
A: Both provide active-active dual-homed uplink aggregation, but MLAG is simpler to configure and does not require a dedicated out-of-band keepalive link — the MLAG heartbeat runs over the peer-link VLAN. Cisco vPC requires separate peer-keepalive and peer-link connections, domain configuration, and peer-gateway settings for ARP/proxy-ARP scenarios that EOS handles more transparently.
Q: What is Arista eAPI and how is it different from Cisco RESTCONF?
A: Arista eAPI is a JSON-RPC HTTP interface that accepts any EOS CLI command string and returns structured JSON output. This means automation scripts can issue the same commands a human would type and parse the results without knowing YANG model paths. Cisco RESTCONF requires encoding structured requests against specific YANG model hierarchies, which has a steeper learning curve for engineers without data-modeling background.
Q: Does Arista EOS support OpenConfig and gNMI streaming telemetry?
A: Yes. EOS has native support for OpenConfig YANG models and gNMI, including the Subscribe RPC for push-based streaming telemetry. The TerminAttr agent handles telemetry streaming to CloudVision or external collectors like Telegraf. This enables vendor-neutral, sub-second telemetry pipelines using tools like the TIG stack (Telegraf, InfluxDB, Grafana).
Q: How does Zero Touch Provisioning work on Arista EOS?
A: When an EOS device boots without a startup configuration, it enters ZTP mode and uses DHCP to obtain network parameters and a provisioning URL from option 67. The device downloads and executes the provisioning artifact, which can be a static config file or a Python script. Python ZTP scripts can query external CMDBs, dynamically generate device-specific configurations, and trigger downstream automation workflows — far beyond what Cisco AutoInstall supports.
Q: What is Arista CloudVision and how does it differ from Cisco DNA Center?
A: CloudVision (CVP) is Arista's centralized network management, streaming telemetry, and automation platform. It maintains a network-wide state database fed by persistent gNMI streams from every EOS device, giving operators a timestamped history of all configuration changes and telemetry events. Cisco DNA Center focuses primarily on intent-based policy abstraction and SD-Access fabric automation, but lacks the depth of time-series state history and multi-device event correlation that CVP provides natively.
Q: Can I use Ansible to manage Arista EOS switches?
A: Yes. Arista maintains the official
arista.eosAnsible collection, which includes modules for interface configuration, VLAN management, BGP, MLAG, and more. The collection uses eAPI as its transport, meaning no SSH-based CLI screen-scraping — all operations are structured JSON-RPC calls against the management API endpoint.
Q: How do EOS software upgrades compare to Cisco IOS upgrades?
A: EOS upgrades follow the same basic stage-and-reload workflow as IOS on single-supervisor platforms. However, EOS images are self-contained package files with consistent naming and verification checksums, making the process more predictable. On dual-supervisor platforms, EOS supports ISSU for hitless upgrades. EOS also supports extension packages that can be updated independently of the base OS image, reducing upgrade frequency for minor feature additions.
Q: Does Arista EOS support EIGRP?
A: No. EIGRP is a Cisco-proprietary protocol and is not supported on Arista EOS. EOS supports OSPF (v2 and v3), IS-IS, BGP (including EVPN), RIP, and static routing for IP reachability. For data center fabrics, the standard deployment model on EOS is BGP in an eBGP spine-leaf topology, which provides equivalent or superior convergence characteristics to EIGRP without vendor lock-in.