Interface Errors & Discards

When Solarwinds NPM shows Interface Errors & Discards, the Monitoring team is pleased that the tool is
able to do a good job. This actually turns out to be a nightmare for the Network engineers who are trying
to figure out the cause of these red marks on their already full plate.

Where does Solarwinds pick this information from – very obviously SNMP. To be specific – from the
Interface MIB (IF-MIB) OID’s of which the 4 OID’s that are picked up to represent the above dashboard
are -

Object Name Object Identifier (OID) Description

ifInDiscards 1.3.6.1.2.1.2.2.1.13 The number of inbound packets which were chosen to be
discarded even though no errors had been detected to
prevent their being deliverable to a higher-layer protocol.
ifInErrors 1.3.6.1.2.1.2.2.1.14 The number of inbound packets that contained errors
preventing them from being deliverable to a higher-layer
protocol.
ifOutDiscards 1.3.6.1.2.1.2.2.1.19 The number of outbound packets which were chosen to
be discarded even though no errors had been detected to
prevent their being transmitted.
ifOutErrors 1.3.6.1.2.1.2.2.1.20 The number of outbound packets that could not be
transmitted because of errors.
 • Do check the device specifically for 32 bit or 64 bit counters and the SNMP version. Many devices,
including Cisco will support 32 bit or 64 bit counters depending on IOS version and SNMP version.
• SNMP counters are never cleared, even if the interfaces are cleared.
• SNMP counters and Interface counters should generally be the same, if SNMP is enabled since
boot time.
• Errors most definitely need to be investigated, while discards may need investigation if extremely
high.

For details, refer a Cisco article on SNMP counters

• https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-
snmp/26007-faq-snmpcounter.html

Cause for Discards (both Receive and Transmit):

• Device needs to free up buffer space for that interface, indicating that the interface could be
receiving or sending bursts of traffic that consume up buffers
• Discards could be caused by Unknown VLAN’s - usually from inappropriate VLANs spanning a
trunk port. The majority of discards will be from VLANs being improperly tagged across ports.
• Frequent Spanning Tree protocol changes that would typically cause a flood of BPDU’s. The
device would be sending the BPDU’s informing of the topology change
• Auto-negotiation failures at both ends of the interface could lead to a high numbers of discards
• High latency to the point of timeouts can cause discards.
• Output drops will occur if QoS is configured and it is not providing enough bandwidth to certain
class of packets.

Cause for Errors (both Receive and Transmit):

• IFInErrors is a sum of 3 types of Errors – Frame Check Sequence or Cyclic Redundancy Check errors,
Alignment errors and Giant errors.
o FCS or CRC errors – Cable problems, poor connections, or faulty interfaces can cause CRC
errors. If you detect such errors, it is time to utilize some Layer 1/Layer 2 test equipment,
such as a cable tester, to determine whether the cables and connections are up to
specification.
o Alignment errors – The frame does not have an integer number of octets and does have
a bad frame check sequence. These errors indicate a faulty transmitter or a cable
problem.
o Giant Errors – A "giant" is just any frame received above your MTU size. This could be
caused by misconfigured MTU sizes, Jumbo frames at one end and not at the other, can
also be caused by simple Trunking protocols like 802.1q or maybe a faulty NIC connected
to that port.
• IfOutErrors
o These packets could not be transmitted due to one or more various data-link layer errors.
The root cause of these errors is usually undefined. In order to more accurately research
these types of errors, you should deploy a packet analyzer on this interface to track the
specific errors.