Introduction
Arista Networks has redefined what a network operating system can look like at scale. Built on a hardened Linux kernel, EOS (Extensible Operating System) runs across every Arista platform — from compact access switches to ultra-high-density spine chassis handling terabits of traffic per second. Unlike legacy vendor stacks, EOS ships as a single binary image across all hardware SKUs, exposes the full Linux environment for native scripting and tooling, and supports industry-standard interfaces including OpenConfig, gNMI, NETCONF, eAPI, and RESTCONF.
This article covers the most impactful real-world deployments of Arista switches in production environments, from BGP EVPN VXLAN data center fabrics to campus security enforcement to fully automated provisioning pipelines. Each use case includes working EOS configuration examples using RFC 1918 addressing, with devices named according to solvethenetwork.com infrastructure standards.
Use Case 1: BGP EVPN VXLAN Spine-Leaf Fabric
The spine-leaf BGP EVPN VXLAN architecture is the definitive design for modern data center networks. VXLAN (RFC 7348) provides MAC-in-UDP encapsulation that stretches Layer 2 segments across a Layer 3 routed underlay. BGP EVPN (RFC 7432) serves as the control plane, distributing MAC and IP reachability information between VTEP devices and completely eliminating flood-and-learn behavior.
In a standard two-tier design, Arista spine switches act as BGP route reflectors and the underlay runs eBGP with point-to-point /31 links. Leaf switches are VTEPs — they originate EVPN Type-2 (MAC/IP) and Type-3 (inclusive multicast) routes, and terminate VXLAN tunnels sourced from loopback interfaces.
Underlay eBGP Configuration on sw-infrarunbook-01 (Leaf)
router bgp 65001
router-id 10.0.0.1
no bgp default ipv4-unicast
maximum-paths 4 ecmp 4
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
network 10.0.1.1/32EVPN Overlay BGP Session (Leaf to Spine Route Reflector)
router bgp 65001
neighbor EVPN-SPINE peer group
neighbor EVPN-SPINE remote-as 65000
neighbor EVPN-SPINE update-source Loopback0
neighbor EVPN-SPINE ebgp-multihop 3
neighbor EVPN-SPINE send-community extended
neighbor 10.0.255.1 peer group EVPN-SPINE
neighbor 10.0.255.2 peer group EVPN-SPINE
!
address-family evpn
neighbor EVPN-SPINE activateVXLAN Interface and VNI-to-VLAN Mapping
interface Vxlan1
vxlan source-interface Loopback1
vxlan udp-port 4789
vxlan vlan 100 vni 10100
vxlan vlan 200 vni 10200
vxlan vrf PROD vni 50000The vrf PROD vni 50000 entry enables symmetric IRB (Integrated Routing and Bridging) — inter-subnet traffic routes through the L3 VNI at the remote VTEP, preserving tenant isolation at Layer 3 without requiring a centralized routing gateway per segment. This is the backbone of multi-tenant data center designs at scale.
Use Case 2: MLAG for Dual-Homed High Availability
Multi-chassis Link Aggregation (MLAG) allows two Arista switches to appear as a single LACP partner to any downstream device — server, storage array, or another switch. Both uplinks from the downstream device carry traffic simultaneously with zero blocked ports, and when one MLAG peer fails, the other inherits all traffic without spanning tree reconvergence.
MLAG requires a peer-link (a high-capacity LAG between the two peers) to synchronize MAC tables, ARP and ND tables, and STP state. A separate peer-keepalive path — typically the out-of-band management network — is used for split-brain arbitration.
MLAG Domain Configuration on sw-infrarunbook-01 (Primary Peer)
mlag configuration
domain-id INFRARUNBOOK-MLAG
local-interface Vlan4094
peer-address 192.168.100.2
peer-link Port-Channel999
reload-delay mlag 300
reload-delay non-mlag 330
interface Vlan4094
description MLAG-Peer-SVI
ip address 192.168.100.1/30
no autostate
interface Port-Channel999
description MLAG-Peer-Link
switchport mode trunk
switchport trunk allowed vlan 1-4094MLAG Port-Channel Toward a Dual-Homed Server
interface Port-Channel10
description APP-SERVER-01-BOND
switchport mode trunk
switchport trunk allowed vlan 100,200
mlag 10
interface Ethernet3
channel-group 10 mode activeIn VXLAN EVPN fabrics, two MLAG peers share the same anycast VTEP IP (sourced from a secondary address on Loopback1), making the pair appear as a single VTEP to the rest of the fabric. This allows active-active server multi-homing all the way through the VXLAN overlay.
Use Case 3: Zero Touch Provisioning (ZTP)
Arista ZTP eliminates manual switch provisioning entirely. When a switch boots without a startup configuration, EOS sends a DHCP request on the management interface. The DHCP server returns a pointer to a bootstrap script hosted on an HTTP server. EOS downloads and executes this script, which can pull device-specific configs keyed on serial number, install the target EOS version, and register the device with CloudVision — all before a technician ever touches a terminal.
ISC DHCP Scope for ZTP Boot File Delivery
subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.100 192.168.10.200;
option routers 192.168.10.1;
option domain-name-servers 192.168.10.2;
option bootfile-name "http://192.168.10.5/ztp/bootstrap";
}ZTP Bootstrap Python Script
#!/usr/bin/env python3
# ZTP Bootstrap — solvethenetwork.com fabric provisioning
import urllib.request
CONFIG_SERVER = "http://192.168.10.5/configs"
SERIAL = open("/mnt/flash/fullrecover").read().strip()
def fetch_config():
url = f"{CONFIG_SERVER}/{SERIAL}.cfg"
urllib.request.urlretrieve(url, "/mnt/flash/startup-config")
print(f"[ZTP] Startup config applied for serial: {SERIAL}")
if __name__ == "__main__":
fetch_config()ZTP scales linearly. Adding a new switch to a fabric is a matter of racking and cabling. The device self-identifies via serial number, retrieves its personalized configuration, and joins the managed network without requiring CLI access from the provisioning engineer.
Use Case 4: CloudVision for Centralized Network Operations
Arista CloudVision Portal (CVP) is a full-lifecycle network management platform. It provides centralized device provisioning, change management with automated rollback, network-wide topology visualization, streaming telemetry aggregation, and configuration compliance auditing. Every configuration change is staged as a controlled task, reviewed, and deployed through a pipeline — replacing ad-hoc SSH sessions with auditable, repeatable workflows.
The TerminAttr daemon runs natively on EOS and maintains a persistent gRPC stream to CloudVision, delivering real-time device state including interface counters, BGP session attributes, VXLAN tunnel status, hardware TCAM utilization, and hardware error counters.
TerminAttr Daemon Configuration on sw-infrarunbook-01
daemon TerminAttr
exec /usr/bin/TerminAttr \
-cvaddr=192.168.20.10:9910 \
-cvauth=token,/tmp/cvp-token \
-cvvrf=MGMT \
-smashexcludes=ale,flexCounter,hardware,kni,pulse,strata \
-ingestexclude=/Sysdb/cell/1/agent,/Sysdb/cell/2/agent \
-taillogs
no shutdownOnce integrated, CloudVision continuously reconciles device state against intended configuration. Configuration drift — whether from an emergency manual change or an unplanned reboot — triggers an alert and can be automatically remediated through CVP's reconciliation engine.
Use Case 5: Quality of Service for Mixed Data Center Workloads
Modern data center fabrics carry heterogeneous traffic types: NVMe-oF and iSCSI storage replication requiring lossless delivery, real-time video conferencing requiring bounded sub-millisecond latency, and bulk ETL pipeline jobs that can tolerate congestion drops. Arista EOS implements hardware-based QoS with DSCP classification, traffic class mapping, and strict-priority or weighted-round-robin queue scheduling — all enforced at line rate in the forwarding ASIC.
DSCP-Based Traffic Policy Classification
traffic-policies
traffic-policy FABRIC-QOS
match ROCE dscp 26
actions
set traffic-class 4
match VOIP dscp 46
actions
set traffic-class 6
match DEFAULT ip
actions
set traffic-class 0
interface Ethernet1
traffic-policy input FABRIC-QOSTX Queue Scheduler Binding
qos profile PROD-FABRIC
tx-queue 6
bandwidth percent 20
priority strict
tx-queue 4
bandwidth percent 45
no priority
tx-queue 0
bandwidth percent 35
no priorityFor RoCE (RDMA over Converged Ethernet) workloads, Priority Flow Control (PFC) is enabled on the storage traffic class to pause individual 802.1p priority lanes on congested links, preventing packet drops without affecting other queue classes.
Use Case 6: LACP Port-Channels for Server and Uplink Aggregation
Link Aggregation with LACP (IEEE 802.3ad) is foundational to every Arista deployment. It bonds multiple physical ports into a single logical interface, delivering both additional bandwidth and link-level redundancy for servers, storage arrays, and inter-switch connections. Arista EOS supports up to 128 port-channel interfaces with configurable LACP timers, hashing algorithms, and fallback modes.
LACP Port-Channel Toward a Dual-NIC Application Server
interface Port-Channel5
description APP-SERVER-01
switchport mode access
switchport access vlan 100
spanning-tree portfast
interface Ethernet5
channel-group 5 mode active
lacp timer fast
interface Ethernet6
channel-group 5 mode active
lacp timer fastThe
lacp timer fastdirective sends PDUs at 1-second intervals instead of the default 30 seconds, collapsing failure detection from a worst-case 90 seconds down to approximately 3 seconds — a critical improvement for workloads that cannot tolerate prolonged link outages.
Use Case 7: BGP Route Maps and Prefix Lists for WAN Policy
Route maps and prefix lists are the primary instruments for implementing routing policy in Arista EOS. They control which prefixes are advertised or accepted, manipulate BGP path attributes including local preference, MED, and community strings, and provide a structured framework for multi-homed WAN and inter-DC routing designs. Named prefix lists keep policy readable and reusable across multiple BGP neighbor statements.
Prefix List Anchoring RFC 1918 Aggregates
ip prefix-list PL-RFC1918 seq 10 permit 10.0.0.0/8 le 32
ip prefix-list PL-RFC1918 seq 20 permit 172.16.0.0/12 le 32
ip prefix-list PL-RFC1918 seq 30 permit 192.168.0.0/16 le 32Route Map for Outbound WAN Advertising
route-map RM-WAN-EXPORT permit 10
match ip address prefix-list PL-RFC1918
set community 65001:200 additive
set metric 100
route-map RM-WAN-EXPORT deny 999
router bgp 65001
neighbor 10.100.0.1 remote-as 65100
neighbor 10.100.0.1 route-map RM-WAN-EXPORT outThe explicit deny 999 at the bottom of the route map ensures only explicitly permitted prefixes are ever advertised outbound — a critical safety control that prevents accidental BGP transit routing when new internal prefixes are added.
Use Case 8: ACLs for Security Policy Enforcement
Arista EOS supports named IPv4 and IPv6 ACLs processed entirely in the forwarding ASIC at line rate, with no performance penalty for large ACL tables. ACLs can be applied inbound or outbound on Layer 3 interfaces, SVIs, and management surfaces. Locking down management-plane access to a dedicated NOC subnet is a baseline security requirement in any production environment.
Management Plane Protection ACL on sw-infrarunbook-01
ip access-list MGMT-RESTRICT
10 permit tcp 192.168.50.0/24 any eq 22
20 permit tcp 192.168.50.0/24 any eq 443
30 permit udp 192.168.50.0/24 any eq 161
40 permit icmp 192.168.50.0/24 any
50 deny ip any any log
management ssh
ip access-group MGMT-RESTRICT in
management api http-commands
protocol https
ip access-group MGMT-RESTRICT in
no shutdownThe
logkeyword on the final deny clause sends ACL hit records to syslog for every unauthorized connection attempt, giving security operations teams visibility into reconnaissance activity without disrupting legitimate management traffic from the 192.168.50.0/24 NOC segment.
Use Case 9: BFD for Sub-Second Failure Detection
Bidirectional Forwarding Detection (BFD) is a lightweight hello protocol that detects forwarding-plane failures in milliseconds — far faster than any routing protocol's native hold timer. Arista supports BFD for BGP, OSPF, IS-IS, PIM, and static routes. When BFD declares a session down, it immediately signals the associated routing protocol to withdraw affected routes and begin reconvergence, without waiting for protocol-level timers to expire.
BFD Enabled on BGP Neighbors of sw-infrarunbook-01
router bgp 65001
neighbor 10.255.1.1 bfd
neighbor 10.255.1.1 fall-over bfd
neighbor 10.255.1.2 bfd
neighbor 10.255.1.2 fall-over bfd
bfd slow-timer 2000BFD-Tracked Static Default Route
ip route 0.0.0.0/0 10.100.0.1 bfd 10.100.0.1 interval 300 min_rx 300 multiplier 3The 300ms interval with a 3x multiplier produces a 900ms detection window for the static default route. This is especially important on links traversing optical WDM transponders or third-party carrier circuits where physical link-down signals can be masked by intermediate hardware — BFD is the only reliable forwarding-plane liveness check in those scenarios.
Use Case 10: OpenConfig and gNMI for Streaming Telemetry
Arista EOS provides one of the most complete native implementations of OpenConfig data models and the gNMI (gRPC Network Management Interface) protocol available in the industry. This enables integration with any standards-compliant automation or observability platform — Telegraf, Prometheus, OpenTelemetry, or custom Python tooling — without relying on screen-scraping, CLI parsing, or legacy SNMP polling.
Enabling gNMI Transport on sw-infrarunbook-01
management api gnmi
transport grpc default
ssl profile GNMI-TLS
port 6030
provider eos-native
no shutdown
management security
ssl profile GNMI-TLS
certificate gnmi-cert.pem key gnmi-key.pemPython gNMI Subscribe for Real-Time Interface Counters
from pygnmi.client import gNMIclient
target = ("192.168.1.10", 6030)
with gNMIclient(target=target,
username="infrarunbook-admin",
password="vault-managed-secret",
insecure=False) as gc:
result = gc.subscribe2(
subscribe={
"subscription": [{
"path": "openconfig-interfaces:interfaces/interface"
"[name=Ethernet1]/state/counters",
"mode": "sample",
"sample_interval": 10_000_000_000
}],
"mode": "stream",
"encoding": "json_ietf"
}
)
for notification in result:
print(notification)Streaming telemetry via gNMI Subscribe delivers per-second or sub-second interface counters, BGP session attribute changes, FIB programming events, and hardware TCAM consumption — feeding directly into time-series databases and dashboards that give operations teams immediate visibility into fabric health.
Use Case 11: STP Hardening in Campus and Access Deployments
While routed access designs dominate new data center builds, campus and enterprise branch networks still rely on Spanning Tree Protocol for loop prevention. Arista EOS supports MSTP (802.1s), RSTP (802.1w), and all major STP protection primitives. Properly hardened STP prevents rogue or misconfigured devices from injecting topology changes that could black-hole traffic across an entire VLAN.
spanning-tree mode mstp
spanning-tree mst 0 priority 4096
interface Ethernet10
description WORKSTATION-ACCESS-PORT
switchport mode access
switchport access vlan 150
spanning-tree portfast
spanning-tree bpduguard enable
interface Ethernet1
description UPLINK-TO-DISTRIBUTION
spanning-tree guard rootPortFast with BPDU Guard is the standard configuration for any port directly connected to an endpoint. The moment a BPDU is received on a BPDU-Guard-enabled port, EOS immediately places that port into an error-disabled state, containing any accidental or malicious loop insertion at the source interface.
Use Case 12: Centralized AAA with TACACS+
Managing per-device local credentials across a fleet of hundreds of switches is operationally unsustainable and creates compliance gaps in audit trails. Arista EOS natively integrates with TACACS+ and RADIUS for centralized authentication, per-command authorization, and full session accounting. Every command issued by every operator is logged against a unique identity in the TACACS+ accounting stream — providing the audit trail required by SOC 2, PCI-DSS, and most enterprise security frameworks.
aaa authentication login default group TACACS local
aaa authorization commands all default group TACACS local
aaa accounting commands all default start-stop group TACACS
tacacs-server host 192.168.50.10 key 7 <encrypted>
tacacs-server host 192.168.50.11 key 7 <encrypted>
tacacs-server timeout 5
aaa group server tacacs+ TACACS
server 192.168.50.10
server 192.168.50.11
username infrarunbook-admin privilege 15 role network-admin secret sha512 <hash>The local infrarunbook-admin account is the break-glass fallback for use only when both TACACS+ servers are unreachable during a network incident. Combining TACACS+ accounting with CloudVision's change management pipeline means every operator action — CLI session or CVP-driven change — is recorded, attributed, and auditable from a single control plane.
Frequently Asked Questions
Q: What operating system do Arista switches run, and what makes it different from other vendors?
A: Arista switches run EOS (Extensible Operating System), a single Linux-based OS binary shared across all Arista hardware platforms. Unlike traditional vendor stacks that run a proprietary kernel with limited access, EOS exposes a full Linux shell, supports native Python scripting, and provides multiple northbound interfaces including CLI, eAPI (JSON-RPC over HTTP/HTTPS), NETCONF, RESTCONF, OpenConfig, and gNMI. This consistency means a script or automation workflow written for one Arista model runs unchanged on any other.
Q: What is the difference between MLAG and a standard single-chassis port-channel?
A: A standard port-channel bundles physical links on a single switch into one logical interface. MLAG extends this across two separate physical switches, allowing a downstream device to bond links to both switches into a single LACP port-channel. From the downstream perspective, the two MLAG peers appear as one logical switch. This eliminates spanning tree blocking on dual-homed uplinks and provides chassis-level redundancy — if one MLAG peer completely loses power, the other takes over without a spanning tree topology change.
Q: How does BGP EVPN differ from traditional VLAN trunking for multi-site Layer 2 extension?
A: Traditional VLAN trunking extends Layer 2 domains over physical trunk links, which is operationally fragile at scale and does not traverse routed Layer 3 boundaries without tunneling. BGP EVPN uses a standards-based control plane to distribute MAC and IP reachability information as BGP route updates, while VXLAN provides the encapsulation to carry the actual data frames across a routed IP underlay. The result is a scalable, loop-free, multi-tenant overlay network where MAC learning is driven by BGP route distribution rather than flooding and data-plane learning.
Q: Can Arista EOS be managed using vendor-neutral tools instead of Arista-specific CLIs?
A: Yes. Arista EOS supports OpenConfig YANG models natively, enabling full configuration and state retrieval through gNMI Get and gNMI Set operations using any compliant client library. Telemetry can be streamed via gNMI Subscribe in both sample and on-change modes. Tools such as Ansible (arista.eos collection), Nornir, Terraform (arista provider), and pyGNMI work directly with EOS without requiring any Arista-specific SDK.
Q: When should Zero Touch Provisioning be used versus manual configuration?
A: ZTP should be used any time you need to deploy more than a handful of switches, operate a distributed network with remote sites, or enforce configuration consistency across a large fleet. ZTP eliminates per-device manual work, reduces human error during initial provisioning, and ensures every device gets the correct EOS version and startup config the moment it powers on. Manual configuration is appropriate only for one-off test scenarios or break-glass recovery situations where the automation infrastructure itself is unavailable.
Q: How does BFD improve network convergence compared to relying on routing protocol hello timers?
A: BGP's default hold timer is 90 seconds — meaning a forwarding failure that does not produce a physical link-down event (such as a one-way fiber cut or a failing transponder) can go undetected for up to 90 seconds before BGP withdraws the affected routes. BFD operates independently of the routing protocol and can detect forwarding failures in as little as 50–300 milliseconds. When BFD declares a session down, it immediately notifies the routing protocol, triggering route withdrawal and reconvergence without waiting for the hold timer to expire.
Q: What is the role of CloudVision in a large Arista deployment?
A: CloudVision Portal serves as the single pane of glass for managing a fleet of Arista devices at scale. It provides centralized provisioning with staged change workflows, real-time streaming telemetry via TerminAttr, configuration compliance monitoring, network topology visualization, and automated rollback when changes cause devices to become unreachable. For large deployments, CloudVision transforms network operations from reactive break-fix to proactive, pipeline-driven change management with full auditability.
Q: How are hardware ACLs applied in Arista EOS, and do they affect forwarding performance?
A: Arista EOS programs ACLs directly into the forwarding ASIC's TCAM (Ternary Content-Addressable Memory), meaning packets are matched against ACL rules at the same line rate as any other forwarded packet — with no CPU involvement and no performance degradation. ACLs can be applied inbound or outbound on Layer 3 interfaces, SVIs, management interfaces, and the control-plane interface. The only constraint is TCAM capacity, which varies by hardware platform and can be monitored via
show hardware tcam profile.
Q: Is it possible to run both EVPN and non-EVPN VXLAN simultaneously on an Arista switch?
A: Yes. Arista EOS supports mixed-mode VXLAN deployments where some VNIs use BGP EVPN for MAC and IP distribution while others use static VXLAN flood-and-learn or head-end replication lists. This is useful during phased migrations from legacy flood-and-learn overlays to a full EVPN control plane, allowing traffic continuity while individual VNIs are migrated to EVPN-signaled operation.
Q: What VXLAN encapsulation format does Arista EOS use, and is it interoperable with other vendors?
A: Arista EOS uses standard RFC 7348 VXLAN encapsulation with UDP destination port 4789. The BGP EVPN control plane follows RFC 7432 and RFC 8365, which are the same standards implemented by other major vendors. Arista has documented interoperability with multiple other vendors in BGP EVPN VXLAN fabrics, though specific feature parity (such as EVPN multihoming vs. MLAG implementation details) should be validated for the specific combination of platforms and EOS versions in production.
Q: How does Arista handle QoS for lossless storage traffic such as RoCE?
A: Arista EOS supports Priority Flow Control (PFC, IEEE 802.1Qbb) for lossless storage traffic. PFC pauses individual 802.1p priority lanes on a congested port without affecting other traffic classes. For RoCE v2, DSCP 26 is typically mapped to a high-priority traffic class, PFC is enabled on that class, and Explicit Congestion Notification (ECN) is configured to signal back-pressure to endpoints before buffers fill completely. This combination of PFC and ECN, known as DCQCN, delivers the lossless fabric behavior required by NVMe-oF and RDMA workloads.
Q: What is the recommended approach for managing Arista switch credentials in a large enterprise?
A: The recommended approach is TACACS+ or RADIUS for authentication and authorization, with local accounts reserved strictly as break-glass fallbacks. TACACS+ provides per-command authorization granularity that RADIUS does not, making it the preferred choice for organizations with strict role-based access requirements. Credentials for local break-glass accounts such as infrarunbook-admin should be stored in a secrets management system (HashiCorp Vault, CyberArk, or equivalent) and rotated on a defined schedule, with access logged and audited independently of the switch itself.