"Input and CRC errors — what do they actually mean?" is a permanent fixture of r/networking and Juniper KB. The counters in show interfaces extensive tell a precise story if you know which line points where. This guide walks every counter you will meet on MX, EX and SRX and gives the isolation method that ends the cable-vs-optic-vs-config argument.

Input Errors vs Input Drops — the First Distinction

These two counters have completely different meanings and are constantly confused:

  • Input errors — frames that arrived but were damaged (bad CRC, framing). Physical or data-link layer problem: cable, optic, transceiver, or electrical noise.
  • Input drops — intact frames the switch had no resources to receive (buffer overrun). Congestion or burst-absorption problem, not a media fault.

Rising input errors = repair the physical path. Rising input drops = rethink buffering, shaping or the burst profile. Chasing a cable for an input-drop problem wastes hours.

The Receive-Side Counters, One by One

  • CRC/align errors — frame checksum failures. The classic Layer-1 signature: dirty fiber, a failing optic, a kinked copper cable, or a duplex and speed mismatch.
  • Framing errors — the frame boundaries themselves are garbled; usually accompanies CRC and points at the same physical causes.
  • Runts — frames below minimum size, typically from collisions-era devices or severe electrical noise.
  • Policed discards — frames dropped because a firewall filter or policer rejected them. Configuration, not media.
  • L3 incompletes — frames discarded because the hardware could not parse an expected header (often IPv4/IPv6 mismatch with filters).
  • L2 channel errors and mismatch timeouts — the port received frames for a different link-layer protocol than configured (for example, trunk mismatch).
  • FIFO errors — the receive buffer overran internally; on some platforms these indicate a failing PIC or port ASIC, and Juniper TAC treats persistent FIFO growth as hardware-replacement evidence.
  • Resource errors — hardware resource exhaustion for receive processing.
  • Output errors — transmit-side failures, usually local hardware or media on your egress.
  • Output drops — frames dropped for lack of egress buffering: queue tuning or shaping problem.
  • Carrier transitions — the link went up and down. A high count with clean error counters means a flaky connector, aggressive energy-efficient-ethernet, or a far-end device rebooting. This counter explains many "mystery flaps" in routing protocols.

Check the Optics Before You Swap Anything

show interfaces diagnostics optics ge-0/0/0

Compare TX power (should be near the optic's nominal, typically -1 to -6 dBm for LR optics), RX power (must be within the receiver's spec — above the low-warning threshold), and module temperature. A slowly-degrading RX power predicts failure weeks before errors become visible. If DOM data is absent or implausible, suspect the optic itself.

The Isolation Method That Ends Debates

clear interfaces statistics ge-0/0/0
# wait 5-10 minutes under real traffic
show interfaces ge-0/0/0 extensive | match "errors|drops|CRC"

Zero the counters, measure the rate of growth, then change exactly one component and re-measure: swap the patch cable first (cheapest), then the optic, then move the transceiver to a different port. If errors follow the cable or optic, you have your answer. If they stay with the port, the hardware is guilty. If errors exist only on one side of the link, focus there — CRC is counted where corruption is received.

Why This Matters Beyond Layer 1

Corrupted frames do not just disappear — they break routing protocols in confusing ways. Large protocol packets (OSPF DBDs, BGP updates) are the first casualties, which is why our OSPF-stuck-in-ExStart guide and BGP-stuck guide both tell you to rule out interface errors before blaming the protocol. On EVPN fabrics, silent CRC corruption produces the same "sometimes it pings, sometimes not" chaos described in the overlay troubleshooting method.