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.

Three companion commands make the physical-layer diagnosis conclusive rather than a guess:

show interfaces status
show interfaces Ethernet1 counters errors
show interfaces Ethernet1 transceiver detail
bash ethtool eth1

show interfaces status gives a one-line-per-port table of link state, speed, duplex and VLAN, which immediately shows a port that negotiated 100 Mbps into a 1 Gbps peer. counters errors separates FCS, alignment, symbol and runts, and the shape of that distribution tells the cause: FCS climbing steadily on one link means an optical or cabling fault, runts plus late collisions mean a duplex mismatch, and a burst of one-off errors that stops after a re-seat is usually a dirty connector. transceiver detail adds the DOM values, so compare receive power against the optic's specified range before spending money on a new module.

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.

To turn a flap into a cause, read the log for the paired events and note whether the transition was administrative:

show logging | grep -i "link.*down"
show logging | grep -i "Ethernet1.*up"
show interfaces Ethernet1 | grep -i "last link"
show interfaces status errdisabled

If the interface is marked errdisabled, EOS has administratively disabled it after a protection mechanism fired — the reason is printed alongside the port and can be cleared with shutdown then no shutdown once the trigger is removed. A port that flaps only when a specific server reboots is not a switch fault at all; a port that flaps on a schedule usually points at a negotiation problem or a marginal optic warmed by a failing PSU.

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.

MAC-table questions split into two families, and the command you need depends on which one you are in. For "is this MAC known, and where", query the table directly. For "where did it move to", watch the moves counter, because a MAC that oscillates between two ports is a loop or a duplicated address:

show mac address-table address 001c.73aa.bbcc
show mac address-table interface Ethernet1
show mac address-table vlan 100
show mac address-table moves
show interfaces Ethernet1 counters mac
show vlan 100

If the MAC is absent from the table entirely, the frame is being dropped before learning: check the port's VLAN membership and mode with show interfaces Ethernet1 switchport, confirm the access VLAN or trunk allowed list includes the expected VLAN, and verify the port is not errdisabled or blocked by STP. If the MAC appears on the wrong port, look at show mac address-table moves, then trace the physical path — a patch panel mislabelled two years ago is a surprisingly common answer. Missing VLANs after a reload remain the single most frequent L2 ticket, and they are always resolved by the same pair of checks: compare show running-config with show startup-config for the VLAN stanza, then run write memory once it is correct.

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

BGP stuck in Active really means "my connect attempts are being rejected, ignored, or never arriving", and the fastest split is to look at the neighbor detail before touching anything:

show ip bgp summary
show ip bgp neighbors 10.0.0.2
show ip bgp neighbors 10.0.0.2 advertised-routes
show ip bgp neighbors 10.0.0.2 received-routes
show ip route 10.0.0.2
show ip bgp neighbors 10.0.0.2 | grep -i "last reset"

The Last reset reason is the single most informative line in that output: no route to peer means the underlay has failed, connection refused means something reached the far end but nothing is listening on 179 (wrong VRF or the peer is shut), and a TCP timeout with no reset at all points at a firewall or an ACL dropping the SYN. Apply the ACL properly on EOS with ip access-list and remember that control-plane filtering is separate from data-plane filtering. When the reason line is unhelpful, the packet capture settles it in seconds: run the capture in the default network namespace and look for SYNs with no SYN-ACK, or for SYNs arriving with an unexpected source address.

OSPF's neighbouring failure modes are equally mechanical. ExStart is an MTU disagreement about which side is master, Init means hellos are being received but the router does not see itself echoed back, and Down with an established link usually means a hello interval, area or authentication mismatch. Check both sides with:

show ip ospf neighbor
show ip ospf interface Ethernet1
show ip ospf neighbor 10.0.0.2 detail

Once the adjacency forms, verify the route actually installed rather than trusting the neighbor state: show ip route ospf and show ip ospf route show the SPF result, and comparing the two catches the case where an adjacency is Full but a duplicate router ID or a route-map is silently discarding the prefix.

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.

A restarting agent is usually a resource problem rather than a software bug, so quantify it before escalating:

show agent logs <AgentName>
bash cat /proc/<pid>/status | grep -i vmsize
bash vmstat 1 5
show processes top once
show version
show core dumps

Look for a resize pattern in the agent log — EOS ProcMgr restarts an agent when its memory grows past a limit, and the same agent restarting every few minutes on a device that just took on more routes is telling you a table got too large. A core dump in show core dumps means an actual crash and should be attached to the TAC case unedited. A SysDB or agent that appears hung with no core file is the case for strace: bash strace -p <pid> -f -tt -o /tmp/agent.trace shows whether it is spinning on a lock or blocked on a device, and that single trace is often what turns an unfixable ticket into a fix. Stale configuration sessions are a related annoyance — an abandoned edit session holds the config lock and blocks everyone else, so clear it deliberately rather than rebooting the switch.

Symptom-to-Command Quick Reference

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.

Attach the right artefacts to the case so the first exchange with support is productive rather than a request for more data. show tech-support collects the full state but is slow and large; for a targeted case, gather the pieces that matter and say so in the ticket:

show version
show interfaces Ethernet1
show logging
show running-config
show tech-support | redirect flash:/tac-$(date +%F).txt

A well-formed Arista case contains the EOS version and platform from show version, the exact commands already run with their output, the time window of the failure in the device's own timezone, and whether the problem is reproducible. Route-flap and BGP issues additionally benefit from show ip bgp neighbors <ip> | grep -i "last reset" and the matching log lines, because those two together usually identify the trigger without further questions. 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. For adjacent scenarios, our MLAG dual-primary and peer-link troubleshooting and native VLAN and trunk troubleshooting guides continue the same command-first approach.

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