Arista Networks has carved out a dominant position in cloud and data center networking over the past decade. What started as a niche challenger has evolved into the de facto standard for hyperscale operators, financial institutions, and enterprise data centers running cloud-like infrastructure. Understanding why Arista switches are popular in cloud networking requires a deep look at EOS architecture, programmability, scalability, and the operational model that aligns with how modern infrastructure teams work.
The EOS Advantage: A Single, Consistent Operating System
At the core of Arista's success is the Extensible Operating System (EOS). Unlike traditional network operating systems that bolt features onto a monolithic kernel, EOS runs as a set of independent processes on top of a standard Linux kernel. Each protocol daemon — BGP, OSPF, MSTP — runs as an isolated process communicating through a central state database called SysDB.
This architecture means a crash in one protocol process does not take down the entire control plane. It also makes EOS trivially scriptable: operators can write Python, Go, or bash scripts that read and write directly to SysDB via the eAPI or the native EOS SDK. Every Arista switch from a 1U ToR to a modular chassis runs the same EOS image, eliminating the fragmentation that plagues multi-tier deployments on other platforms.
sw-infrarunbook-01# show version
Arista DCS-7050CX3-32S
Hardware version: 11.00
Serial number: JPE21234567
System MAC address: 2899.3a00.0001
Software image version: 4.32.1F
Architecture: x86_64
Internal build version: 4.32.1F-xxxxxxx
Image format version: 3.0
Uptime: 42 days, 6 hours and 15 minutes
Total memory: 8178904 kB
Free memory: 6432176 kBeAPI: The Gateway to Programmable Networking
Arista's eAPI exposes the full CLI command set over HTTPS as a JSON-RPC interface. Any command available on the CLI is also available programmatically without additional tooling beyond enabling the management API service. Automation platforms — Ansible, Terraform, Salt, or custom Python scripts — use the same mental model as a CLI operator, drastically reducing the learning curve for network automation teams.
sw-infrarunbook-01(config)# management api http-commands
sw-infrarunbook-01(config-mgmt-api-http-cmds)# no shutdown
sw-infrarunbook-01(config-mgmt-api-http-cmds)# protocol https
sw-infrarunbook-01(config-mgmt-api-http-cmds)# vrf MGMTA Python call against the eAPI retrieves structured BGP state data directly:
import jsonrpclib
switch = jsonrpclib.Server(
'https://infrarunbook-admin:Password1@192.168.10.1/command-api'
)
response = switch.runCmds(1, ['show ip bgp summary'])
print(response[0]['vrfs']['default']['peers'])MLAG: High Availability Without Proprietary Stacking
Multi-Chassis Link Aggregation (MLAG) allows two Arista switches to present a single logical LAG to downstream devices. Unlike vendor-proprietary virtual chassis or stacking solutions, MLAG is based on open standards (LACP 802.3ad) and keeps the control planes of both switches fully independent. A failure of one MLAG peer does not require a re-election of control-plane state — the surviving peer continues forwarding without a spanning-tree topology change.
! Peer-link and MLAG configuration on sw-infrarunbook-01
interface Port-Channel10
description MLAG-PEER-LINK
switchport mode trunk
switchport trunk allowed vlan 1-4094
mlag configuration
domain-id INFRARUNBOOK-MLAG
local-interface Vlan4094
peer-address 192.168.254.2
peer-link Port-Channel10
interface Vlan4094
ip address 192.168.254.1/30
no autostateMLAG heartbeat runs over the peer-link itself, with an optional out-of-band management path as a secondary keepalive. Replacing expensive proprietary chassis with two top-of-rack switches running MLAG delivers equivalent redundancy at a fraction of the cost, with no proprietary hardware dependencies at the aggregation layer.
VXLAN and BGP EVPN: The Modern Overlay Fabric
Cloud environments require tenant isolation at scale. VLAN-based segmentation tops out at 4094 segments — nowhere near sufficient for a multi-tenant cloud. VXLAN extends the segment namespace to 16 million VNIs. Arista EOS implements VXLAN with BGP EVPN as the control plane, the industry standard for distributing MAC, IP, and prefix reachability across a leaf-spine fabric without flood-and-learn behavior.
! Underlay BGP on sw-infrarunbook-01 (leaf role)
router bgp 65001
router-id 10.0.0.1
no bgp default ipv4-unicast
neighbor SPINE peer group
neighbor SPINE remote-as 65000
neighbor SPINE send-community extended
neighbor SPINE maximum-routes 12000
neighbor 10.255.0.0 peer group SPINE
neighbor 10.255.0.2 peer group SPINE
!
address-family ipv4
neighbor SPINE activate
network 10.0.0.1/32
!
address-family evpn
neighbor SPINE activate
! VXLAN interface with VNI mappings
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 100 vni 10100
vxlan vlan 200 vni 10200
vxlan learn-restrict any
! Symmetric IRB: L3 VNI per VRF
vrf instance TENANT-A
rd 10.0.0.1:1001
route-target import evpn 65001:1001
route-target export evpn 65001:1001
ip virtual-router mac-address 00:1c:73:00:00:01Symmetric IRB is a key EVPN feature Arista implements natively. Traffic between VLANs within the same VRF is routed at the ingress leaf, tunneled with the L3 VNI, and delivered directly at the egress leaf — eliminating hair-pinning through a centralized gateway and keeping east-west latency within the fabric deterministic.
Leaf-Spine Architecture and ECMP at Scale
Arista's 7050 and 7280 series switches are purpose-built for leaf-spine topologies. With 32x100GbE or 64x400GbE ports in 1U or 2U form factors, a pair of spine switches can service dozens of leaf switches without oversubscription. EOS implements Equal-Cost Multi-Path (ECMP) routing with up to 512 equal paths per destination, ensuring all uplinks are fully utilized simultaneously.
! ECMP load-balancing tuning
ip load-sharing source destination ip-protocol transport
sw-infrarunbook-01# show ip route summary
Number of routes installed : 4523
Static routes : 12
BGP routes (best) : 4456
Connected routes : 55
sw-infrarunbook-01# show ip bgp 10.20.0.0/24
BGP routing table entry for 10.20.0.0/24
Paths: 4 available
65000 65002
10.255.0.0 from 10.255.0.0 (10.0.0.254)
Origin IGP, localpref 100, valid, external
65000 65002
10.255.0.2 from 10.255.0.2 (10.0.0.253)
Origin IGP, localpref 100, valid, external, bestOpenConfig and gNMI: Vendor-Neutral Streaming Telemetry
Modern cloud operators use streaming telemetry rather than polling-based SNMP. Arista EOS has had first-class support for OpenConfig data models and gNMI (gRPC Network Management Interface) since EOS 4.20. Operators subscribe to interface counters, BGP state, LLDP neighbors, and hundreds of other paths at sub-second intervals, feeding data directly into Prometheus, InfluxDB, or Elasticsearch without any vendor-specific collector plugins.
sw-infrarunbook-01(config)# management gnmi
sw-infrarunbook-01(config-gnmi)# transport grpc default
sw-infrarunbook-01(config-gnmi-transport)# ssl profile GNMI-SSL
sw-infrarunbook-01(config-gnmi-transport)# port 6030
sw-infrarunbook-01(config-gnmi-transport)# vrf MGMT
! Verify active gNMI subscriptions
sw-infrarunbook-01# show gnmi active-subscriptions
Subscription handle: 1
Peer: 192.168.10.100:52341
Mode: STREAM
Paths:
/interfaces/interface/state/counters
/network-instances/network-instance/protocols/protocol/bgp/
neighbors/neighbor/state
Sample interval: 10000000000 ns
Suppress redundant: falseUsing OpenConfig models means telemetry pipelines are not Arista-specific. The same gnmic collector pulling data from sw-infrarunbook-01 can pull identical paths from any other OpenConfig-compliant vendor, enabling consistent observability across hybrid environments.
CloudVision: Network-Wide Change Management
CloudVision (CV) is Arista's network management platform that goes far beyond a traditional NMS. CV maintains a real-time graph database of every device state, configuration delta, and topology link in the network. Change management through CV provides rollback at the individual command level — not just config snapshots.
CloudVision implements Change Control workflows where configuration changes are staged, peer-reviewed, and executed in maintenance windows with automatic rollback if a defined health check fails after deployment. For cloud operators pushing configuration changes dozens of times per day, this is a critical risk mitigation capability.
! Register sw-infrarunbook-01 with CloudVision via TerminAttr
sw-infrarunbook-01(config)# daemon TerminAttr
sw-infrarunbook-01(config-daemon-TerminAttr)# exec /usr/bin/TerminAttr \
-cvaddr=192.168.10.50:9910 \
-cvauth=token,/tmp/token \
-cvvrf=MGMT \
-smashexcludes=ale,flexCounter,hardware,kni,pulse,strata \
-ingestexclude=/Sysdb/cell/1/agent,/Sysdb/cell/2/agent \
-taillogs
sw-infrarunbook-01(config-daemon-TerminAttr)# no shutdownBFD: Sub-Second Failure Detection
BGP's default hold-down timer is 90 seconds — unacceptable for cloud workloads. Bidirectional Forwarding Detection (BFD) provides sub-second link and path failure detection. Arista EOS supports hardware-offloaded BFD timers as low as 50ms for BGP, OSPF, static routes, and VXLAN tunnels. When BFD detects a peer failure, BGP immediately withdraws routes and reconverges in milliseconds.
! BFD timer tuning and BGP association
bfd interval 50 min-rx 50 multiplier 3
bfd slow-timer 2000
router bgp 65001
neighbor SPINE bfd
neighbor SPINE bfd-fallback bfd interval 300 min-rx 300 multiplier 3
sw-infrarunbook-01# show bfd peers
VRF name: default
DstAddr MyDisc YourDisc Interface Type LastUp
---------- -------- ---------- ---------- ------ ----------------
10.255.0.0 3942852 2983745 Ethernet1 normal 03/10/26 08:22
10.255.0.2 3942853 2983746 Ethernet2 normal 03/10/26 08:22
LastDown LastDiag State
---------- --------------- -----
- No Diagnostic Up
- No Diagnostic UpAAA and Role-Based Access Control
Enterprise and cloud operators require fine-grained access control and full audit trails. Arista EOS integrates with RADIUS and TACACS+ for AAA, with support for per-command authorization. Every CLI command can be individually permitted or denied based on the authenticated user's role. This satisfies PCI-DSS, SOC2, and other compliance frameworks requiring privileged access audit trails.
! TACACS+ AAA pointing to solvethenetwork.com auth servers
aaa group server tacacs+ NET-OPS
server 192.168.10.20 vrf MGMT
server 192.168.10.21 vrf MGMT
aaa authentication login default group NET-OPS local
aaa authorization exec default group NET-OPS local
aaa authorization commands all default group NET-OPS local
aaa accounting exec default start-stop group NET-OPS
aaa accounting commands all default start-stop group NET-OPS
username infrarunbook-admin privilege 15 role network-admin secret sha512 $6$xxx
! Read-only NOC role — show commands only
role noc-readonly
10 permit command show .*
20 deny command .*Quality of Service for Mixed Workloads
Cloud switches carry a mix of latency-sensitive storage and compute traffic alongside bulk backup and management flows. Arista EOS implements QoS using DSCP/CoS remarking, strict priority queuing, and weighted fair queuing at hardware line rate. The traffic-class map ties DSCP values to hardware queues, and the policy-map enforces scheduling behavior per egress port.
! DSCP to traffic class mapping
traffic-class dscp
dscp 46 traffic-class 7 ! EF — latency sensitive
dscp 34 traffic-class 6 ! AF41 — video
dscp 26 traffic-class 5 ! AF31 — critical data
dscp 0 traffic-class 0 ! BE — best effort
! Scheduling policy applied to uplink
policy-map type qos PM-UPLINK-OUT
class CM-TC7
priority
shape rate 10 percent
class CM-TC6
bandwidth percent 20
class CM-TC5
bandwidth percent 30
class CM-TC0
bandwidth percent 40
interface Ethernet1
service-policy type qos out PM-UPLINK-OUTRoute Maps and Prefix Lists: Traffic Engineering at Scale
In a BGP EVPN fabric, route maps and prefix lists control what routes are advertised and accepted between peers. Arista's implementation supports sequence numbers, match conditions on community strings, AS-path, MED, and local-preference, as well as set actions for traffic engineering and policy enforcement at fabric borders.
! Permit specific tenant subnets only
ip prefix-list PL-TENANT-A-PREFIXES
seq 10 permit 10.100.0.0/16 le 24
seq 20 permit 10.200.0.0/16 le 24
seq 30 deny 0.0.0.0/0 le 32
! Route map: set local-preference and community on inbound prefixes
route-map RM-SPINE-IN permit 10
match ip address prefix-list PL-TENANT-A-PREFIXES
set local-preference 200
set community 65001:100
route-map RM-SPINE-IN permit 20
match community CM-DEFAULT
set local-preference 100
route-map RM-SPINE-IN deny 30
router bgp 65001
neighbor 10.255.0.0 route-map RM-SPINE-IN in
neighbor 10.255.0.2 route-map RM-SPINE-IN inMerchant Silicon Strategy and Hardware ASICs
Arista has embraced merchant silicon — primarily Broadcom's Trident, Tomahawk, and Jericho ASIC families — rather than developing proprietary ASICs. This strategy provides several advantages: merchant silicon is manufactured at scale, keeping per-port costs low; ASIC vendors continuously invest in forwarding table sizes, buffer depths, and telemetry capabilities; and Arista's software layer extracts full value from the underlying silicon with features like hardware-timestamped latency monitoring and hitless software upgrades.
sw-infrarunbook-01# show platform trident forwarding-table partition
Trident Forwarding Table
-------------------------
LEM (L2 Exact Match):
Configured max : 131072
Used : 8432
Available : 122640
LPM (Longest Prefix Match):
IPv4 unicast : 4523
IPv6 unicast : 312
ECMP groups : 245
sw-infrarunbook-01# show platform trident counters
ASIC TxDrops RxDrops TxErrors RxErrors
---- ------- ------- -------- --------
0 0 0 0 0In-Service Software Upgrade (ISSU)
For cloud operators who cannot tolerate maintenance windows, Arista's ISSU capability allows EOS upgrades without dropping forwarding traffic. The data plane continues operating under the current ASIC programming while the new EOS image boots and replays configuration state. ISSU is supported on modular chassis platforms and select fixed-form platforms with redundant supervisors, enabling daytime upgrades without scheduling change windows.
sw-infrarunbook-01# show issu status
ISSU Status: Idle
Current version: EOS-4.32.1F
Staged version : EOS-4.33.0F
sw-infrarunbook-01# install source flash:EOS-4.33.0F.swi now issu
sw-infrarunbook-01# show issu status
ISSU Status: Upgrading (phase 2 of 3)
Data plane : Uninterrupted
Control plane : Restarting BGP processes
Estimated completion: 3m 20sPort Channels and LACP Best Practices
Port channels aggregate physical interfaces into a single logical bundle for increased bandwidth and redundancy. Arista recommends LACP active mode on both ends for dynamic negotiation, with LACP fast timers in environments where sub-second failover is needed at the server attachment layer.
interface Port-Channel1
description SERVER-BOND0
switchport mode trunk
switchport trunk native vlan 100
switchport trunk allowed vlan 100,200,300
spanning-tree portfast
lacp timer fast
interface Ethernet3
description SERVER-NIC1
channel-group 1 mode active
lacp timer fast
interface Ethernet4
description SERVER-NIC2
channel-group 1 mode active
lacp timer fast
sw-infrarunbook-01# show port-channel 1 detail
Port Channel Port-Channel1:
Active Ports : Et3 Et4
Inactive Ports: None
LACP Mode : active
LACP Rate : fast
Minimum links : 0Why This Matters for Cloud Operators
Cloud networking demands automation-first design, massive scale, vendor-neutral telemetry, and zero-downtime operations. Arista's architectural decisions — EOS as a Linux-based modular OS, eAPI and OpenConfig for programmability, BGP EVPN/VXLAN for scalable overlays, merchant silicon for cost efficiency, and CloudVision for change management — address every one of these requirements directly.
Operators running private cloud, co-location facilities, and hybrid cloud edge deployments consistently choose Arista because the operational model matches how software-defined infrastructure teams already work: code reviews for configuration changes, GitOps pipelines for deployment, and observability stacks for monitoring. The switch behaves like a server — and that alignment is precisely what makes Arista the preferred platform for cloud networking.
Key Takeaway: Arista's dominance in cloud networking is not accidental. It is the result of a deliberate architectural philosophy that prioritizes programmability, standards compliance, and operational simplicity over proprietary lock-in.
Frequently Asked Questions
Q: What makes Arista EOS different from other network operating systems?
A: EOS is built on a standard Linux kernel with each protocol daemon (BGP, OSPF, STP) running as an independent process communicating through a central state database called SysDB. A single process crash does not bring down the control plane. EOS also exposes a full JSON-RPC API (eAPI) that mirrors the CLI, making automation native rather than bolted on as an afterthought.
Q: Does Arista support OpenConfig and gNMI for streaming telemetry?
A: Yes. Arista EOS has supported OpenConfig data models and gNMI since version 4.20. Operators subscribe to hundreds of telemetry paths at sub-second intervals using standard gNMI Subscribe RPCs, feeding data directly into Prometheus, InfluxDB, or any gNMI-compatible collector without vendor-specific plugins.
Q: How does MLAG compare to proprietary chassis-based high availability?
A: MLAG uses two independent switches that appear as a single LAG endpoint to downstream devices using standard LACP (802.3ad). Unlike proprietary virtual chassis, each MLAG peer has its own independent control plane. A failure of one peer does not trigger control-plane re-election — forwarding continues on the surviving switch without spanning-tree reconvergence.
Q: What is BGP EVPN and why is it used in Arista leaf-spine fabrics?
A: BGP EVPN is an address-family extension to BGP that distributes MAC, IP, and prefix reachability across a VXLAN underlay fabric using a control plane rather than flood-and-learn. It reduces broadcast traffic, enables per-tenant routing via symmetric IRB with L3 VNIs, and scales to millions of endpoints without centralized state.
Q: Can Arista switches be managed with Ansible or Terraform?
A: Yes. Arista publishes the arista.eos Ansible collection and a dedicated Terraform provider. Both use eAPI under the hood. The Ansible collection includes modules for interface configuration, BGP, VLANs, ACLs, and more. Terraform's Arista provider supports resource-based lifecycle management of EOS configuration objects with full state tracking.
Q: What is CloudVision and is it required to run Arista equipment?
A: CloudVision is Arista's optional network management platform providing real-time topology visualization, configuration change management with rollback, streaming telemetry aggregation, and ZTP device onboarding. It is not required — Arista switches operate fully standalone via CLI, eAPI, NETCONF, or gNMI. CloudVision adds operational value for large-scale deployments where change control and audit trails are compliance requirements.
Q: How does Arista implement VXLAN without a centralized controller?
A: Arista uses BGP EVPN as a distributed control plane for VXLAN. Each leaf switch announces its locally learned MAC and IP bindings as EVPN type-2 routes and advertises its VTEP IP via type-3 routes. All remote leaves receive this state and install forwarding entries locally, eliminating the need for a centralized SDN controller in the data-plane forwarding path.
Q: What is the benefit of BFD in a cloud switching environment?
A: BGP's default hold-down timer is 90 seconds — far too slow for cloud workloads where application reconnect logic may time out in seconds. Hardware-offloaded BFD on Arista detects link and path failures in as little as 50ms. When BFD signals a peer failure, BGP immediately withdraws routes and triggers convergence in milliseconds rather than minutes.
Q: How does Arista handle In-Service Software Upgrades (ISSU)?
A: On supported platforms, Arista ISSU boots the new EOS image while the existing ASIC programming continues to forward traffic. The new control plane processes replay state, re-establish BGP sessions, and synchronize with the forwarding table before old processes are terminated. The result is a software upgrade with zero data-plane packet loss, enabling upgrades during business hours without scheduling downtime.
Q: Is Arista EOS suitable for environments requiring PCI-DSS compliance?
A: Yes. EOS supports TACACS+ and RADIUS with per-command authorization, full accounting logs for every CLI command by every user, role-based access control, SSH key-based authentication, management VRFs for out-of-band access isolation, and TLS-encrypted eAPI and gNMI transports. These features satisfy the access control and audit trail requirements of PCI-DSS, SOC2, and HIPAA compliance frameworks.
Q: Does Arista use proprietary ASICs or merchant silicon?
A: Arista primarily uses merchant silicon from Broadcom (Trident, Tomahawk, Jericho families) and Intel (Tofino for programmable pipeline platforms). This keeps hardware costs competitive since any vendor using the same ASIC faces similar bills of materials. Arista's differentiation is entirely in the EOS software layer that maximizes silicon capabilities — hardware telemetry, ISSU, and deep buffer visibility among them.
Q: What Arista platforms are most common in cloud leaf-spine deployments?
A: The 7050CX3 and 7050TX3 series are popular ToR leaf switches offering 32x100GbE in 1U. The 7280R3 series provides deep buffers suited for spine or border leaf roles. The 7500R3 modular chassis is used for aggregation and super-spine roles in very large fabrics. All platforms run the same EOS image, ensuring consistent operational behavior and a single skills baseline across the entire fabric.