Arista EOS Interface Error Counters Troubleshooting

Error counters on an Arista switch are easy to read and easy to misread. A single FCS-Err that crept up during a link flap three years ago is not a fault; a counter incrementing a few per second on a 100G link is. This guide shows the EOS commands that separate the two, what each counter family actually points at, and the Layer 1 actions that resolve the overwhelming majority of cases.

The three commands that matter first

switch# show interfaces status
switch# show interfaces counters errors
switch# show interfaces counters discards

# Drill down on the suspect port
switch# show interfaces Ethernet1
switch# show interfaces Ethernet1 transceiver
switch# show interfaces Ethernet1 counters errors

show interfaces counters errors gives you a compact table per port; show interfaces Ethernet1 gives the full picture including runts, giants, late collisions and the last-cleared timestamp. Never analyse counters without clearing them first — otherwise you cannot tell a historic blip from a live problem:

switch# clear counters Ethernet1
# wait 5-10 minutes, then re-read
switch# show interfaces Ethernet1 counters errors

Mapping counters to root cause

The single most useful distinction: CRC/FCS errors point at Layer 1, while input errors without CRC and output discards point at congestion or MTU. Chasing a cable for an output discard problem wastes an afternoon.

Reading the transceiver: the step most people skip

switch# show interfaces Ethernet1 transceiver
switch# show interfaces Ethernet1 transceiver dom

DOM output gives transmit and receive power, temperature, voltage and bias current. Compare receive power against the optics budget for the link: a 100G-LR4 running 3 dB below its expected receive range is a dirty connector or a bend, whatever the error counters say. If Tx power is out of range on the local side, the problem is on the local optic, not the far end.

A repeatable triage order

1. clear counters, wait, re-read — confirm the counter is actually moving.
2. Check link state history: show logging | grep -i Ethernet1 shows flap timestamps. A link that flaps alongside error counters is nearly always physical.
3. Check DOM for both ends. Out-of-range Rx power is a cabling/optics ticket.
4. Check negotiated speed and duplex: show interfaces Ethernet1 | include line protocol|duplex|BW. Hardcode both ends rather than trusting auto-negotiation on a suspect link.
5. Compare against a known-good port in the same bundle, same optic type, same patch panel run.
6. Swap systematically — optic first, then patch lead, then port. Change one variable at a time.

When the counters are clean but the traffic is not

Interface counters only describe Layer 1 and Layer 2. If the counters are quiet and applications still complain, move up the stack:

switch# show interfaces Ethernet1 counters rates
switch# show queue Ethernet1
switch# show platform trident counters drop Ethernet1

# Underlying EOS is Linux - use it
switch# bash
$ ss -tan state established | grep 179
$ sudo tcpdump -i et1 -nn port 179 -c 20

Egress queue drops under a flood, or microbursts that average out over a one-second polling interval, will not show up as CRC errors. That is a capacity and buffer question, and the answer is usually a QoS policy or a wider bundle rather than a replacement cable.

Discipline is what makes this fast: clear counters, classify by counter family, verify optics on both ends, then change exactly one thing at a time.

Related Reading on This Site

• Arista EOS EVPN-VXLAN Symmetric IRB Configuration
• Arista EOS ACLs: IPv4, MAC ACLs and Counters
• Arista EOS TAP Aggregation: Tap and Tool Ports

原文链接：https://rootlog.in/posts/arista-eos-internals-part-9 (rootlog.in - Arista EOS Internals, Part 9)