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.

Step 1: Establish Baseline Context

CODEBLOCK0

Record: hostname, EOS version, uptime, hardware model, total memory, current time.
Short uptime indicates a recent reload or crash — check show reload cause for
the trigger. Note the hardware platform — Arista's 7050X, 7280R, 7500R, and
720X series have different memory and CPU profiles.

Step 2: CPU and Memory Assessment

EOS reports CPU and memory through both EOS commands and Linux-native tools.

CODEBLOCK1

Linux-native alternative (provides more granularity):
CODEBLOCK2

INLINECODE4 shows per-process CPU and memory similar to Linux top.
EOS CPU is typically consumed by agents — each protocol has its own process.

Key agents to watch:

• - Stp — Spanning Tree: high CPU indicates topology instability
• Rib — Routing Information Base: route churn or large table operations
• Ebra — EOS Bridge Agent: L2 forwarding, MAC learning storms
• IpRib — IP RIB agent: routing table processing
• Bgp — BGP agent: peer negotiations, route processing
• Fap-sobek / Sand — ASIC agents: forwarding plane, hardware programming

EOS memory: show version includes total and free memory. Free memory below
20% of total is warning. Linux free -m provides buffer/cache detail — EOS
uses Linux page cache aggressively, so "used" memory includes reclaimable cache.

Step 3: Agent and Daemon Health

EOS runs each subsystem as an independent agent. A crashed or stuck agent
affects its subsystem silently — device-level metrics may look normal while
one protocol is completely inoperative.

CODEBLOCK3

INLINECODE8 lists all EOS agents with their PID, state, and uptime.

Healthy state: all agents show running with uptimes matching device uptime.
Red flags:

• - Agent with shorter uptime than device → it crashed and restarted
• Agent in crashed or not running state → subsystem is down
• Multiple agent restarts in logs → recurring instability

If an agent shows recent restart, check its logs: show agent [name] logs.
Common restart causes: memory exhaustion, uncaught exception, watchdog timeout.

Step 4: Interface Health

CODEBLOCK4

For interfaces with errors:
CODEBLOCK5

Error classification:

• - CRC / FCS errors → Layer 1 (cabling, optics, SFP seating)
• Input errors without CRC → buffer overruns, MTU mismatch
• Alignment errors → duplex mismatch or L1 issue
• Output discards → egress congestion; check QoS or link capacity
• Late collisions → duplex mismatch (should not occur on modern links)

Optics DOM: show interfaces transceiver provides Tx/Rx power, temperature,
voltage. Low Rx power (below -10 dBm for most 10G SFP+) indicates fiber or
optic degradation.

Step 5: Environment and Platform

CODEBLOCK6

Check: all temperature sensors within limits, all power supplies OK, all
fans operational. show environment all is a comprehensive single command.

INLINECODE15 — if the device recently reloaded, this explains why.
Expected causes: user-initiated, software upgrade. Unexpected causes:
kernel panic, watchdog timeout, power loss.

Review syslog for tracebacks, panics, or agent crashes. EOS logs are also
accessible via bash cat /var/log/messages | tail 50.

Step 6: MLAG Health (Data Center Extension)

Skip this step if MLAG is not configured. MLAG state is often the single most
important health indicator in an Arista data center deployment — a degraded
MLAG pair can cause traffic black-holes or asymmetric forwarding.

CODEBLOCK7

MLAG state assessment:

Field	Healthy Value	Problem Indicator
state	active	disabled, inactive
negotiation status

connected | connecting, disconnected |
| peer-link status | up | down, errdisabled |
| local-interface status | up | down |
| config-sanity | consistent | inconsistent |

INLINECODE17 provides:

• - Peer address and peer-link interface status
• Heartbeat interval and status — lost heartbeats indicate control plane

reachability issues between peers

• - Reload delay timers — critical for preventing traffic loss during boot

INLINECODE18 checks for configuration mismatches between peers.
Inconsistencies can cause traffic loops or black-holes. Address any inconsistent
result before continuing other triage.

INLINECODE20 — verify all MLAG interfaces show active-full on both
sides. active-partial means one side is down — reduced redundancy.
disabled means the MLAG interface is administratively or operationally down.

Step 7: VXLAN/EVPN Health (Data Center Extension)

Skip this step if VXLAN/EVPN is not configured. This assesses overlay fabric
health for VXLAN deployments using BGP EVPN as the control plane.

CODEBLOCK8

VXLAN health checks:

• - show vxlan vtep — verify expected VTEP count. Missing VTEPs indicate

underlay reachability or BGP EVPN peering issues.

• - show interfaces vxlan 1 — VTEP source interface must be up. Flood list

should match expected remote VTEPs (for flood-and-learn) or be empty
(for BGP EVPN with ingress replication).

• - show vxlan address-table — MAC learning across the overlay. Stale or

missing entries indicate control plane issues.

BGP EVPN peering:

• - show bgp evpn summary — all EVPN peers must be in Established state.

Peers in Active/Connect state have transport or configuration issues.

• - Compare EVPN route count to baseline — significant deviation indicates

route withdrawal or redistribution problems.

For L3 VXLAN (symmetric IRB):
CODEBLOCK9

Verify: VRF route counts match expectations, no unexpected route withdrawals,
EVPN type-5 routes present for inter-VRF routing.

Threshold Tables

Reference: references/threshold-tables.md for detailed per-parameter thresholds.

Parameter	Normal	Warning	Critical	Notes
CPU 5-min avg	< 40%	40–70%	> 70%	Per-agent breakdown in INLINECODE29
Memory free

> 30% | 20–30% | < 20% | Linux page cache is reclaimable |
| Agent state | All running | Agent restarted | Agent crashed/not running | Check show agent |
| Interface error rate | < 0.01% | 0.01–0.1% | > 0.1% | |
| Output discards/hr | < 100 | 100–1000 | > 1000 | |
| MLAG state | active/connected | config inconsistency | peer-link down | |
| VXLAN VTEP count | Matches expected | Missing VTEPs | Vxlan1 interface down | |
| Temperature | Within spec | 5°C of max | At/above max | Per-sensor |

Decision Trees

Primary Triage

CODEBLOCK10

MLAG State Triage

CODEBLOCK11

Escalation Criteria

Escalate to senior engineer or Arista TAC when:

• - CPU sustained > 90% for 15+ minutes with no identifiable cause
• Memory below 15% free with no recent change to explain consumption
• Agent in crashed state that does not recover after restart
• Multiple agents crashing or restarting within a short period
• Traceback or kernel panic in logs (show logging, bash dmesg)
• Any environmental alarm (power, fan, temperature)
• More than 3 routing neighbor state changes in the last hour
• MLAG peer-link failure with no clear physical cause
• MLAG config-sanity inconsistencies that cannot be resolved
• VXLAN overlay losing more than 10% of expected VTEPs

Report Template

CODEBLOCK12

Troubleshooting

Device Unresponsive to SSH

Try console access. If console is also unresponsive, check power and environment
via out-of-band management. After recovery: show reload cause for the trigger,
bash dmesg | tail 50 for kernel messages, show logging last 50 for pre-crash
syslog. EOS stores crash data in /var/log/ — accessible via bash ls -la /var/log/.

Agent Crash and Recovery

If show agent shows an agent as crashed or with uptime shorter than the device:

1. 1. Check agent logs: INLINECODE40
2. Check syslog: INLINECODE41
3. Linux-level: INLINECODE42
4. If the agent is not running, attempt: agent [name] shutdown then

no agent [name] shutdown in configuration mode (note: this is a config change)

Agent crashes are the most common EOS-specific failure mode. Collect logs before
restarting — the crash data is needed for TAC investigation.

CPU Spikes During Health Check

EOS show commands can briefly spike CPU on the management plane. Wait 30 seconds
after connecting before collecting CPU data. Use show processes top once rather
than interactive top (which holds a session) for scripted checks.

MLAG Split-Brain Detection

If both peers report MLAG state active but negotiation shows disconnected,
this is a split-brain condition. Both peers believe they are the primary. Causes:
peer-link physical failure, peer-link VLAN issue, or heartbeat network partition.
Immediate action: verify physical peer-link connectivity. If peer-link is
physically up but MLAG reports disconnected, check VLAN trunking on the
peer-link and the heartbeat network (usually the management VRF).

Linux-Native Diagnostics

EOS's Linux foundation means standard Linux tools work from bash:

• - bash top -bn1 — process-level CPU and memory (more granular than EOS top)
• INLINECODE52 — memory with buffer/cache detail
• INLINECODE53 — filesystem usage (important for /mnt/flash and /var/log)
• INLINECODE54 — kernel messages (hardware errors, driver issues)
• INLINECODE55 — load averages
• INLINECODE56 — detailed memory breakdown

These supplement EOS show commands when deeper investigation is needed.
Prefix all commands with bash from the EOS CLI, or enter bash for a shell.

Inconsistent Memory Readings

EOS's Linux page cache uses available memory for file caching. show version
may report low free memory while actual memory pressure is low. Use
bash free -m and check the available column (not free) for the real
available memory. The available column accounts for reclaimable cache and
buffers.