skip to content

In SNMP's IF-MIB, how do ifOutDiscards and ifOutErrors differ, and what does a rising discard count on a moderately loaded uplink suggest?

level: middleimportance: should knowfreq 22%

answer

  1. dropped versus damaged
  2. no error was detected
  3. buffer space
  4. averages hide bursts

basics

~20 s

ifOutDiscards counts outbound packets dropped although no error was detected, for example to free buffer space; ifOutErrors counts packets that could not be sent because of errors. Rising discards at moderate average utilisation usually mean bursts overflowing the output buffer.

solid answer

~40 s

RFC 2863 defines `ifOutDiscards` as outbound packets "chosen to be discarded even though no errors had been detected", with freeing buffer space as one possible reason, and `ifOutErrors` as outbound packets that "could not be transmitted because of errors". The inbound pair is the same idea: `ifInDiscards` for good packets dropped, `ifInErrors` for packets that contained errors. So errors point at the link or the transmission path, while discards point at the device choosing to drop, most often congestion. An uplink averaging 35% over five minutes with `ifOutDiscards` climbing is the classic sign of microbursts: for milliseconds the offered load exceeds line rate, the queue fills and packets are dropped, and the average hides it. Judge both as a rate over the same interval, ideally against the packets sent, never as raw totals.

go deeper

for a junior

Recall that IF-MIB counts dropped packets separately from damaged ones: discards for good packets dropped, errors for packets with errors.

for a middle

Explain where each counter sends an engineer, errors to the physical path and discards to queueing, and why both must be read as rates over an interval.

for a senior

Diagnose rising discards on a moderately loaded uplink as bursts overflowing buffers, normalise against packets sent, and rule out restarts and down interfaces first.

for a principal

Decide whether discards call for more capacity, a queueing change or finer measurement, and what drop rate the services on that link can tolerate.

## Four counters, two questions Besides octet counters, every `ifTable` row in IF-MIB (RFC 2863) carries counters for packets that did not make it. They split along two questions: which direction, and whether anything was wrong with the packet. | Object | Direction | RFC 2863 definition, in short | |---|---|---| | `ifInDiscards` | inbound | packets chosen to be discarded even though no errors were detected; freeing buffer space is one possible reason | | `ifInErrors` | inbound | packets that contained errors preventing delivery to a higher-layer protocol | | `ifOutDiscards` | outbound | packets chosen to be discarded even though no errors were detected; freeing buffer space is one possible reason | | `ifOutErrors` | outbound | packets that could not be transmitted because of errors | A related counter, `ifInUnknownProtos`, counts packets discarded because of an unknown or unsupported protocol; it is about what was received, not about health. ## Reading the difference - **Errors** say something was wrong on the transmission path: the packet was damaged, or transmission failed. What counts as an error is defined by the media; on a physical link, rising errors typically lead to the cable, the optic, the connector or the far end. - **Discards** say the packets were fine and the device decided to drop them. The RFC's own example is freeing buffer space, which on an output interface usually means the queue was full. Other local decisions can also land here, depending on the implementation. So the two counters send an engineer to different places: errors to the physical and link layer, discards to queueing and capacity. ## The moderately loaded uplink Take a 10 Gb/s uplink whose octet counters give 35% average utilisation over a 300 s poll while `ifOutDiscards` climbs every interval. 1. The octet counters measure the **mean** rate over 300 s. 2. Traffic is bursty; many senders converging on one egress port can offer more than 10 Gb/s for a few milliseconds. 3. During those milliseconds the output buffer fills and further packets are dropped, which increments `ifOutDiscards`. 4. Seconds later the port is idle again, and the five-minute mean comes out at 35%. With numbers: over one 300 s interval the port was asked to send 450,000,000 packets (the sum of its unicast, multicast and broadcast packet-counter deltas, which RFC 2863 defines to include packets discarded or not sent) and `ifOutDiscards` rose by 90,000. That is a drop rate of 90,000 / 450,000,000 = 0.02%, small on average but concentrated in the bursts, where it hurts loss-sensitive traffic. `ifOutErrors` over the same interval staying flat confirms the path itself is clean. The discards are the direct IF-MIB evidence of these bursts. The usual responses are capacity (more bandwidth or more parallel links), buffering and queueing policy, or finer-grained measurement; which one is a design decision outside the MIB. ## Turning the counters into a signal - Treat them as **rates**: a raw total since boot says nothing, because counters have no defined initial value and restart at re-initialisation and at the times `ifCounterDiscontinuityTime` marks. - Compare against **packets**, not octets: discards per packet sent over the same interval. The packet counters are `ifHCOutUcastPkts`, `ifHCOutMulticastPkts` and `ifHCOutBroadcastPkts`, required in 64-bit form on interfaces at 650 Mb/s and faster; the old combined non-unicast counters are deprecated. - Note the width: IF-MIB defines the error and discard counters only as `Counter32`, with no 64-bit versions, so the usual one-wrap correction applies to them. - Read them with the status objects: an interface that is `down` shows neither traffic nor discards, which is not the same as a healthy one. - Do not look for a queue-depth object here: `ifOutQLen` exists in `ifTable` but RFC 2863 marks it deprecated, so the discard counter is what remains for congestion.

  • ifInErrors climbs on one uplink while its neighbour on the same device stays clean; where do you look first?
    At that link's physical path. `ifInErrors` counts received packets that contained errors preventing delivery, so the damage happened before the packet was accepted: cable, optic, connector, the far end's transmitter. Because the neighbour on the same device is clean, the device's shared resources are a less likely cause than that one link.
  • Why is a raw ifOutDiscards total of 1,200,000 not, on its own, evidence of a problem?
    Counters have no defined initial value, so a single total carries no information: it could be months of rare drops or one bad minute. A difference over a known interval, compared with the packets sent in the same interval, turns it into a drop rate that can be judged and alerted on.

saying these in an interview costs you the question

  • Discards and errors both mean the packet was corrupted
  • Rising ifOutDiscards proves a faulty cable or optic
  • A link averaging 35% utilisation cannot be dropping packets
  • A large raw discard total since boot is enough to raise an alarm
  • ifOutQLen gives the current queue depth to explain discards