Re: help with interfaces group (long)

[Anil Rijsinghani <[e-mail]>]

Here are some answers.  By the way, the [e-mail] mailing list
would be a better place to ask these questions.

> 1) My chip set vendor is listed in RFC 1398, but not the particular
> chip set(s) I use.  Is anyone providing a central registry for new
> dot3ChipSets or do I have to use an enterprise-specific value?

Inform Frank Kastenholz ([e-mail]), the editor of the MIB.
Maybe it can be accomodated at the next advancement stage.  In any
case, you can use an OID from your own enterprise space.

> 2) Should packets that are counted in ifInUnknownProtos also be
> included in either ifInUcastPkts or ifInNUcastPkts?  (In other words,
> do ifInUcastPkts and ifInNUcastPkts count packets that would have been
> delivered to a higher-level protocol, had the protocol existed in my
> device, or do they count only packets actually delivered to a protocol
> implemented in my device?)

Yes, ifInUnknownProtos packets should be part of the ucast/nucast count.

> 3) Should ill-formed packets be included in ifInErrors as well as
> the appropriate dot3Stats counter (e.g. dot3StatsFCSErrors)?

Yes.

> 4) Should the same ill-formed packets be included in ifInOctets?

It would be advisable to include it.  The primary use of this counter
is utilization.  However since the errors are a negligible part of
actual traffic, it's not that important.  (and if they were, then the
manager would hopefully be spending more time on finding the problem
than looking at utilization.)

> 5) My hardware has a separate counter for "runt" (under-minimum-length)
> packets.  Should I include these packets in dot3StatsFCSErrors (since
> they also fail the FCS test) or somewhere else (so they can be
> distinguished from normal-length frames with FCS errors)?

Runts with bad FCS, yes.  (It's possible to get runts with good FCS,
eg when external loopback is exercised on a LANCE.)

> 6) My hardware truncates packets with alignment errors to a byte
> boundary before verifying the FCS.  Thus, packets with "dribble bits"
> (as generated by many older interfaces) are received correctly if
> there is no other problem.  Should such frames be included in
> dot3StatsAlignmentErrors, or is this counter only for packets
> which fail the FCS test after truncation?

Only for packets which fail FCS.

> 7) My hardware uses a hash table for multicast address filtering.  The
> filter occasionally lets a packet through even though it's not addressed
> to my station or one of my multicast receive addresses.  Should such a
> packet be counted in:
>	7a) ifInOctets
>	7b) ifExtnsXXXXReceivedOks
>	7c) ifInErrors
>	7d) IfInDiscards ?

Interesting that you didn't include inucast/innucast frames in the list.
I wouldn't get too excited about this either way since it's such a
rare occurence.. ideally it should be not counted.

> 8) Although the MIB says that ifInOctets should include "framing characters",
> my hardware doesn't provide any indication of the length of the received
> preamble.  Should I ignore the preamble or add an estimate (8 bytes per
> packet) to the total count?

Don't include preamble.

> 9) Should packets which are counted in, for example,
> dot3StatsExcessiveCollisions also be  counted in ifOutErrors?

Yes.  Any error that prevents the packet from making it out should be
included there.

> 10) My hardware reports "packet transmitted with one or more collisions" but
> doesn't distinguish between one collision and multiple collisions (up to
> the "excessive collisions" limit).  Should I count these packets in
> dot3StatsSingleCollisionFrames or dot3StatsMultipleCollisionFrames?

This is a sticky one, since technically whichever one you do would be
misleading given the MIB definitions.  Counting them in multiple collisions
would probably be better, with documentation indicating this for your
product.

Anil