>      The way I handle it in my scripts is to poll the device every
> five minutes.  If a counter value is less then the preceeding
> counter value, then I check to see if the preceeding value was
> within approximately 200,000,000 of the wrap point then I assumed
> that it wrapped; otherwise, I assume that it was reset.

This builds an assumption into the post-processor of the polling data
which only works as long as the data rate for the interface is modest.
You'd only need to have a data rate of a little over 5.3Mbit/s for the
assumption above to miss data on a counter wrap (200,000,000 bytes in
5 minutes is only about 5.3Mbit/s).  Also remember that a 32-bit octet
counter will wrap in 5 minutes at approximately 114.5Mbit/s.  I think
that building in assumptions about the expected data rate in a general
SNMP data post-processor is bad.  Instead, the SNMP agent should
indicate when it's counters have been zeroed (and it's re-initialized)
by resetting sysUpTime.0 back to 0, and the poller should use the
discontinuity in sysUpTime.0 to reset it's idea of what the "previous"
counter value was, so that it can compute a reasonable delta.  An SNMP
agent should never zero it's counters without also resetting
sysUpTime.0.

Regards,

- H=E5vard