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.