> On Fri, Mar 31, 2006 at 02:13:53PM -0500, matthew sporleder wrote:
> > This is a very convenient feature even in production.  These counte=
rs
> > are reset when the system is rebooted anyway, so it's just as well =
to
> > allow them to be reset without that power cycle.  I don't see how t=
his
> > adversely affect SNMP monitoring at all.  It simply eases
> > troubleshooting.
>
> SNMP will obtain the system boot time (or similar) and use that to
> know when the counters are reset.
> Counter wrapping can be assumed to happen at the power of 2 above the=

> last reading.

In fact, if the uptime of the agent (as returned by sysUpTime.0)
doesn't decrease, a management station *has to* assume that the
counter wrapped at the maximal counter value if the next reading
is smaller than the previous one.  When the in-kernel counters
are reset, this will introduce a quite noticeable and artificial
spike in any derived statistics on the management station.

I can understand the convenience to those who don't run SNMP and
who just fixed a problem and want to se "what does it look like
now" or "let's leave it for a few hours to see how it does after
that", and not having to reboot to reset the statistics.

"Real" routers where statistics is normally collected using SNMP
and who also have this "clear counters" function do this IMO the
right way, i.e. by checkpointing the base level for the counters
and only displaying the difference compared to this base level
when commands equivalent to "netstat" are run.

I'm not sure what I think of the "add a sysctl to prevent
accidental resetting of the counters" idea.  As has been noted it
would only prevent accidentall resetting, and is more of a
stopgap because people for some reason or other balk at the
"checkpoint base level to diff against for the user interface"
solution.  "Bloat" might be an argument against this solution.

Regards,

- H=E5vard