On Sat, 12 Apr 2003, Martin Husemann wrote:

> On Sat, Apr 12, 2003 at 01:30:32PM -0700, Bill Studenmund wrote:
> > > Havard Eidnes <he@netbsd.org> writes:
> > > > If this does what I think it does (after browsing the code, I think it
> > > > does), zeroing the packet statistics will break the monotonous
> > > > increase of counters restriction imposed on SNMP agents
> > So what do other *BSDs do? I figure we need to come up with a new
> > read-stats ioctl that will get the monotonic value. What name(s) are in
> > use now?
>
> Why bloat the kernel more instead of having the SNMP daemon take care of it?
> Or root?

Because how can SNMP take care of it?

If you can come up with a workable alternative (even in concept), I'd like
to hear it.

The only way I can tell to make it so that SNMP _can_ "take care of it" is
to send a message to snmpd (and whomever else needs monotonic counters)
every time the counters get reset, listing their current counts.

So that means: 1) another message socket, 2) new messages to send on said
socket, 3) non-trivial changes to snmpd to get it to use the above. Note
that an snmpd might not be plummed so that adding an arbitrary socket is
easy.

> The counters will wrap anyway, if not reset. Why should root (who might know
> this machine is not running any SNMP stuff) not be allowed to reset this
> counters?

Why does root care?

Note: I thought it was clear that I expect that ifconfig, netstat, etc.
would use the "resetable" ioctls. So root can reset the counters s/he sees
in netstat & friends. Why doe s/he care how the kernel represents that?

So one method is to add parallel counters that contain "last reset"
values. This doubles the storage, and common counter read operations now
require a subtraction. The alternative involves adding some new messaging
system (either a socket or maybe a kqueue message) that tells snmpd when
counters got reset, and plumming snmpd to deal with ^^.

I think it's much easier to just have snmp use different ioctls that get
the non-resetable values.

Also note that counter wrap has already been taken care of in SNMP. If you
ever read a counter value less than you last read, the protocol dictates
that that means the counter wrapped. Also, there are two different counter
types, 32-bit and 64-bit. You use the 32-bit one unless you will
reasonably overflow the counter in one minute. i.e. if a management
station polling once a minute may get the number of wraps wrong. If the
value goes that fast, then you have to use a 64-bit counter.

The point is that (apparent) counter wraps have protocol meaning in SNMP.
So if we don't have strictly-monotonic counters available (one way or
another), we are going to totally ruin us for SNMP.

Take care,

Bill