Arista EOS Device Health Check

Arista EOS Device Health Check

Structured triage procedure for assessing Arista EOS device health. Produces a prioritized findings report with severity classifications and recommended actions.

EOS runs on a Linux kernel with individual processes (agents) managing each protocol and subsystem. This architecture means Linux-native tools (bash top, bash df, bash dmesg) are valid supplements to EOS show commands. Agent health is a first-class concern — a crashed or stuck agent can silently affect a subsystem even when aggregate device metrics look normal.

The procedure covers core device health first, then extends to MLAG and VXLAN/EVPN for data center deployments.

When to Use

• Device reported as slow, dropping traffic, or unresponsive
• Scheduled health audit of Arista switches (leaf, spine, or border)
• Post-change verification after upgrades, patches, or configuration changes
• Capacity planning data collection for CPU, memory, and link utilization
• Incident response when an Arista switch is suspected as the fault domain
• MLAG inconsistency or split-brain detection in a data center pair
• VXLAN/EVPN overlay health assessment — VTEP reachability, BGP EVPN peering
• Agent crash or restart detected in syslog

Prerequisites

• SSH or console access to the device (privilege 1 minimum)
• EOS 4.28 or later (commands validated against EOS 4.30+)
• Network reachability to management interface confirmed
• Awareness of the device's normal baseline (CPU, memory, traffic patterns)
• For MLAG configurations: access to both MLAG peers for cross-validation
• For VXLAN/EVPN: knowledge of expected VTEP count and BGP EVPN peer list

Procedure

Follow this sequence. Core device health (Steps 1–5) applies to all deployments. Steps 6–7 are data center extensions for MLAG and VXLAN/EVPN — skip if not configured on this device.