SNMP Inspector
EN
Get notified

Switch port errors: ifInErrors, FCS errors and discards explained

· Vladimir Chemeris, the developer of SNMP Inspector

A switch port with 40,000 input errors may have run clean since spring. A port that gains 3 errors per second has a fault right now, and the cable or the optics come first on the suspect list. IF-MIB and EtherLike-MIB hold the counters for both cases, and you tell them apart with two reads of snmpget.

ifInErrors and ifOutErrors

Both counters sit in the interface table of IF-MIB (RFC 2863). ifInErrors counts inbound packets “that contained errors preventing them from being deliverable to a higher-layer protocol”. ifOutErrors counts outbound packets “that could not be transmitted because of errors”.

On an Ethernet-like interface, RFC 3635 defines each one as a sum of EtherLike-MIB counters:

IF-MIB counter Sum of these EtherLike-MIB counters (RFC 3635)
ifInErrors dot3StatsAlignmentErrors, dot3StatsFCSErrors, dot3StatsFrameTooLongs, dot3StatsInternalMacReceiveErrors
ifOutErrors dot3StatsSQETestErrors, dot3StatsLateCollisions, dot3StatsExcessiveCollisions, dot3StatsInternalMacTransmitErrors, dot3StatsCarrierSenseErrors

Input errors describe the receive side: frames reached the port damaged. On the transmit side, RFC 3635 says four of the five components don’t increment in full-duplex mode, so output errors that grow on a switch port point at half duplex first.

IF-MIB has 64-bit versions of the octet and packet counters and none for errors or discards. The four IF-MIB counters here are Counter32.

ifInDiscards vs ifInErrors

RFC 2863 defines ifInDiscards as inbound packets “chosen to be discarded even though no errors had been detected”, and gives one possible reason: “to free up buffer space”. ifOutDiscards uses the same wording for the transmit side. The packets had no errors, and the device dropped them anyway.

Discards point at congestion: a 10G uplink feeding a 1G port, or several ports sending to one at once. Swapping the patch cable won’t move them. Errors point at the physical layer: copper, connectors, optics, the PHY and the duplex setting.

Counter Counts First suspect
ifInErrors Damaged frames received Cable, connector, SFP, far-end NIC, duplex
ifOutErrors Frames the port failed to send Half duplex and collisions
ifInDiscards Intact packets dropped on receive Buffer pressure
ifOutDiscards Intact packets dropped before sending Egress congestion

dot3StatsFCSErrors and the other EtherLike-MIB counters

EtherLike-MIB (RFC 3635) splits Ethernet errors by cause in dot3StatsTable. Its index, dot3StatsIndex, names the same interface as the same value of ifIndex, so dot3StatsFCSErrors.7 and ifInErrors.7 describe one port.

  • dot3StatsFCSErrors counts received frames that have a whole number of octets and fail the FCS check. The FCS is the CRC-32 at the end of each Ethernet frame, and many switch CLIs call this count CRC errors. RFC 3635 adds that coding errors the physical layer detects above 10 Mb/s also fail the FCS check, so a noisy line ends up here too.
  • dot3StatsAlignmentErrors counts received frames that are not a whole number of octets and also fail the FCS check. RFC 3635 says it “does not increment for group encoding schemes greater than 4 bits per group”.
  • dot3StatsSymbolErrors counts carrier events in which the PHY saw an invalid symbol or a receive error, at most once per event. It doesn’t count at 10 Mb/s, and RFC 3635 leaves it out of the ifInErrors sum.
  • dot3StatsLateCollisions counts collisions detected later than one slotTime into a transmission.
  • dot3StatsSingleCollisionFrames and dot3StatsMultipleCollisionFrames count frames that went out after one collision or after several.
  • dot3StatsDuplexStatus reads unknown(1), halfDuplex(2) or fullDuplex(3). unknown means the agent could not determine the current duplex mode.

RFC 3635 says the collision counters don’t increment in full-duplex mode. A collision count that rises tells you the port runs half duplex, whatever the configuration says.

FCS errors sit inside ifInErrors, so a sum of the two counts the same frames twice. SNMP Inspector writes the rule on screen: “Errors, counted once · dot3StatsFCSErrors ⊂ ifInErrors”.

Switch port errors increasing: total or rate

Each counter holds a total since its last discontinuity. RFC 2863 and RFC 3635 name two sources: re-initialization of the management system, and other times that ifCounterDiscontinuityTime marks. A switch 200 days up can show thousands of FCS errors from a patch cable someone replaced in June. That total tells you the port had errors at some point.

The rate tells you whether the fault is live. Read the counter twice, subtract, and divide by the seconds between the reads. A port that gains errors under traffic has a problem now. A port that holds still under traffic stayed clean for that window, whatever its total.

The second half of that rule needs traffic. An idle port gains no errors because no frames cross it, so push traffic through the link during the check or pick a busy hour.

RFC 3635 warns that at 10 Gb/s the 32-bit FCS counter “can roll over in less than 5 minutes” at its maximum rate. For counter wrap, agent restarts and the 64-bit traffic counters, read ifInOctets vs ifHCInOctets.

CRC errors on a switch port: typical causes

An input error on a switch port means a frame reached this port damaged. The damage happened somewhere between the transmitter at the far end and this port’s receiver. In general Ethernet practice, the usual causes are:

  • A damaged copper cable or a bad termination: a crushed run, pairs untwisted too far at the jack, a bad crimp, a run longer than 100 m.
  • A dirty or scratched fiber connector, a fiber patch cord bent too tight, or a failing SFP at either end.
  • A duplex mismatch. One side runs fixed full duplex, the other autonegotiates and falls back to half duplex. The half-duplex side counts late collisions (dot3StatsLateCollisions, inside ifOutErrors), and the full-duplex side counts FCS and alignment errors. Expect it on 10 and 100 Mbit/s links where someone set speed and duplex by hand on one end.
  • Electrical noise on copper laid along power cables.
  • A failing port, NIC or PHY at either end.

Discards stay off this list, since they track congestion.

Field check: read, wait, read again

Find the port’s ifIndex with snmpwalk -v2c -c <community> 192.0.2.10 ifName, then read its counters together with sysUpTime.0 in one request. Port 7 here:

snmpget -v2c -c <community> 192.0.2.10 sysUpTime.0 ifInErrors.7 ifOutErrors.7 ifInDiscards.7 dot3StatsFCSErrors.7 dot3StatsDuplexStatus.7
  1. Run the command and note the values.
  2. Wait 30-60 seconds with traffic on the link and run the same command again. Agents can cache counters for several seconds, so a 2-second gap may show no change.
  3. Subtract each counter and divide by the interval. sysUpTime counts hundredths of a second, so a difference of 6000 means 60 s. A smaller sysUpTime on the second read means the agent restarted: start a new pair of reads.
  4. Reseat or replace the patch cable. On fiber, clean both connectors or swap the SFP.
  5. Repeat steps 1-3 under similar traffic and compare the two rates. The totals still carry the old errors, so they prove nothing about the swap.

A worked example: ifInErrors.7 reads 18,240, then 18,420 sixty seconds later. That makes 180 errors in 60 s, or 3 errors/s. If the rate falls to 0 after the cable swap with traffic flowing, the patch cable or its connectors caused it. If it stays at 3, move on to the cabling run, the far-end device and duplex.

No Such Object and No Such Instance

The developer recorded the output below on 2026-11-11 with snmpget from net-snmp 5.9.4, against two devices on a local network. In the commands, 192.0.2.x stands in for the real addresses and <community> for the community string.

First, RouterOS 7.25 on a MikroTik RB4011. Interface 11 is sfp-sfpplus1, the SFP+ port, with ifHighSpeed at 10000:

$ snmpget -v2c -c <community> 192.0.2.1 ifInErrors.11 ifInDiscards.11 dot3StatsFCSErrors.11
IF-MIB::ifInErrors.11 = Counter32: 0
IF-MIB::ifInDiscards.11 = Counter32: 0
EtherLike-MIB::dot3StatsFCSErrors.11 = No Such Object available on this agent at this OID

Second, net-snmp snmpd on a Linux host running Proxmox VE, interface 2, eno1:

$ snmpget -v2c -c <community> 192.0.2.12 ifName.2 ifInOctets.2 ifHCInOctets.2 dot3StatsFCSErrors.2
IF-MIB::ifName.2 = STRING: eno1
IF-MIB::ifInOctets.2 = Counter32: 0
IF-MIB::ifHCInOctets.2 = Counter64: 0
EtherLike-MIB::dot3StatsFCSErrors.2 = No Such Instance currently exists at this OID

Both commands exit with status 0: the agent answered, and one variable came back without a value. RFC 3416 defines the two exceptions for a GET. noSuchObject means the name matches no object accessible by this request. noSuchInstance means the object exists and this instance doesn’t. RouterOS here serves no dot3StatsFCSErrors to this request: the agent lacks it, or its view hides it. The net-snmp agent knows the column and has no row for interface 2.

Treat both answers as Unknown. In the second block, ifInOctets.2 = Counter32: 0 is a zero the agent read, and dot3StatsFCSErrors.2 has no value. A script that writes 0 for each failed variable reports a clean FCS count with nothing behind it. On a port where ifInErrors grows, you would rule out FCS errors and look past the cable. On the RB4011 port, ifInErrors still answers, so its rate stays your measure there.

Port errors in SNMP Inspector

The port card in SNMP Inspector shows errors per second and marks a port whose errors rise with “Growing now”, as in “2 errors/s · Growing”. If the agent doesn’t serve a counter, the app names the gap in place of a zero (“Error counters unavailable on this agent”, “Unknown: no EtherLike-MIB”), and an unknown duplex stays unknown. For a cable or SFP swap, capture Before and After: each changed port gets a verdict of Fixed, As planned, Worse, Unchanged or Can’t verify, and the app needs at least 1,000 packets to call the link error-free.

Questions

Are CRC errors the same as FCS errors?

Yes. The FCS is a CRC-32 at the end of each Ethernet frame, and dot3StatsFCSErrors counts received frames that fail the check. Many switch CLIs call the same count CRC errors.

What is the difference between ifInDiscards and ifInErrors?

ifInErrors counts frames that arrived damaged. ifInDiscards counts packets with no errors that the device dropped anyway, for example to free buffer space (RFC 2863). Errors point at the cable, the optics or duplex; discards point at congestion.

Why does dot3StatsFCSErrors return No Such Object?

The agent serves no such object to your request: it doesn't implement it, or its view hides it. RouterOS 7.25 on an RB4011 answers this way for its SFP+ port. Watch the rate of ifInErrors instead, and don't record the missing value as 0.

Do input errors mean a bad switch port?

Input errors mean frames reached the port damaged. The cause can sit anywhere from the far-end transmitter to this port: the device's NIC or SFP, the patch cords, the cabling run or the port itself. Swap the cheap parts first and compare the error rate before and after.

How many errors per second are too many?

On a healthy link the FCS count stays flat under traffic. A count that keeps rising means something on that link damages frames, even at 1 error per minute.