Re: if_ethersubr.c: if_ierrors -> if_iqdrops?

[Havard Eidnes <he%NetBSD.org@localhost>]

>> >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