Arista EOS Troubleshooting Cookbook: Interfaces to BGP

Most network outages are diagnosed at the wrong layer. This Arista EOS troubleshooting cookbook, distilled from the EOS Internals series, gives you a symptom-first playbook: for each common production issue — flapping interfaces, FCS errors, missing MACs, BGP sessions stuck in Active, OSPF neighbors stuck in ExStart, crashing agents, locked config sessions — it tells you exactly which show command to run first and what the output means. It also explains how to use the Linux-native tools inside EOS for deep debugging when the CLI alone is not enough.

Physical Layer Issues

For an interface that is down, check the cable type, negotiated speed/duplex, and the SFP in one pass:

show interfaces Ethernet1
show interfaces Ethernet1 transceiver

A non-zero FCS error count means the switch is receiving frames with bad checksums. Almost always the cause is a bad cable, a bad SFP, or a duplex mismatch (one end auto, the other hard-coded). Replace the faulty component or align speed/duplex on both ends.

Interface Flapping and Link Status Changes

show interfaces Ethernet1 counters
show interfaces Ethernet1 transceiver
show logging | grep -i Ethernet1

Check the link status changes counter and correlate timestamps in the logs. The usual causes are a bad cable, bad SFP, or the far end going through its own restart.

L2 Issues: MAC Not Learned or VLAN Missing

When a MAC address is not learned, verify the source interface, the VLAN, and the port's switchport config:

show mac address-table address <mac>
show vlan
show interfaces Ethernet1 switchport

A classic after-reboot problem is a VLAN that exists in running-config but not startup-config — it was never saved. Check both and fix with write memory.

L3 Issues: BGP and OSPF

For a BGP session stuck in Active (trying to connect but failing): check reachability, the neighbor config, TCP port 179, and capture packets:

ping <neighbor>
show ip bgp neighbors
bash ss -tan state established | grep 179
bash tcpdump -i eth1 -n -vv port 179
show ip interface brief

For OSPF stuck in ExStart, the neighbors cannot agree on master/slave — almost always an MTU mismatch. Compare IP MTU on both ends and standardize (typically 1500 or your jumbo size):

interface Ethernet2
   mtu 1500

Control Plane and Agent Issues

If an agent keeps restarting, check the PID:

bash ps aux | grep <AgentName>

Root causes are crashes (segfault/assertion), out of memory, or config errors. For a stuck SysDB, strace the process to see whether it is blocked on I/O (read/write), lock contention (futex), or just waiting (epoll_wait). A locked config session can be found with show configuration sessions.

Top Production Issues and Escalation

The most common issues are: BGP down because the interface is down; OSPF stuck due to MTU; high CPU from a route flap; slow SSH from a full ARP table; interface errors from a bad SFP; VLAN missing because write memory was skipped. When escalating to TAC, always prepare device identification, problem description, steps taken, and log snippets. For related Arista material, see our EOS VLAN, trunk and port-channel configuration guide, the EOS MLAG explainer, and the Cisco-to-Arista command cheat sheet.

原文链接：https://rootlog.in/posts/arista-eos-internals-part-9