>> >OK, so discarded packets are fine as `if_iqdrops'. Otherwise, a kernel w/o
>> >vlan (or netatalk, carp, ...) compiled in will show:
>>
>> Yes, I think that we need the distinction between discard and drop...
>> Or we should just not count discard...
>
> Another option may be if_noproto.
Exactly!
It is probably a good idea to look at the Interfaces MIB from the
SNMP world and see what conditions give rise to an increment in
which counter, so that it doesn't become needlessly difficult to
implement an SNMP agent which can implement the Interfaces MIB
without standing on it's head, trying to undo what can't be
undone because events which should be counted separately are
counted as part of the same counter.
Many years ago I was involved in a dispute with one of our
vendors over exactly this issue. They used to count what they
refer to as "L3 incompletes" as input errors. "L3 incompletes"
just means "unrecognized layer-3 protocol", and does not fall
under the definition of what constitutes an "input error" in the
Interfaces MIB definition, ref.:
ifInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from being
deliverable to a higher-layer protocol. For character-
oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them
from being deliverable to a higher-layer protocol.
Having e.g. a Cisco device configured to do CDP on its interfaces
connected to such a box would produce a steady stream of "input
errors" which is bad since it would potentially mask out the
detection of actual transmission errors which *should* be counted
in this counter.
Since the vendor had done the counting this way for ages, and
was unwilling to change the default behaviour, this dispute ended
up with the additional feature of the "ignore-l3-incompletes"
configuration option, and for obvious reasons it's now in all our
templates for configuring such equipment. Not sure they are
reliably implementing the ifInUnknownProtos counter, though;
that's of marginal practical interest to us.
I'll also note that ifInDiscards and ifInUnknownProtos are
diferent counters with different semantics in the Interfaces MIB:
ifInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"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. One
possible reason for discarding such a packet could be to
free up buffer space.
...
ifInUnknownProtos OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of packets
received via the interface which were discarded because of
an unknown or unsupported protocol. For character-oriented
or fixed-length interfaces that support protocol
multiplexing the number of transmission units received via
the interface which were discarded because of an unknown or
unsupported protocol. For any interface that does not
support protocol multiplexing, this counter will always be
0.
which further supports the suggestion to use if_noproto for the
stated condition.
Best regards,
- Håvard
