How to handle interface counter update delay? - SNMP
This is a discussion on How to handle interface counter update delay? - SNMP ; Hello,
Testing with Cisco hardware and net-snmp on Linux reveals that
interface counters -- if[HC]{Out,In}Octets -- are not updated in real
time. Repeatedly polling coutners and noting when they change shows
that counter updates can be from 5 to over ...
-
How to handle interface counter update delay?
Hello,
Testing with Cisco hardware and net-snmp on Linux reveals that
interface counters -- if[HC]{Out,In}Octets -- are not updated in real
time. Repeatedly polling coutners and noting when they change shows
that counter updates can be from 5 to over 30 seconds apart, with
longer intervals the more traffic is going through the interface.
For billing purposes, I need to determine the average usage at five
minute intervals: the 95th percentile of input and output is then
calculated from that. The uneven counter update interval poses a
problem for this because the polling interval isn't necessarily a
multiple of the counter update interval.
This means that sometimes a polling sample covers (approx.) 300
seconds of clock time, but only, say, 233 seconds of actual traffic
stats, because the counters hadn't been updated when I polled. This
produces a false dip in the data. The extra 27 seconds of stats could
be included in the next sample, producing a false spike. 95th
percentile billing cannot be correct unless these spikes can be
prevented or accounted for.
The problem is resolvable with net-snmp -- I could just edit the code
and make it update in real time -- but that isn't an option with Cisco
equipment: and it's actually Cisco routers I need to monitor.
What I need is:
1. A timestamp OID which is updated whenever the counters for an
interface are updated. This would enable me to "backdate" the sample
to the time it actually represents. (Note that ifLastChange doesn't do
this.); or
2. A method for correcting the gathered statistics; or
3. A way to make a Cisco router update its stats with a specific
interval which is a factor of 300; or
4. A way to make a Cisco router update its stats in real time. (This
is least preferable since, due to the way the routers work, I don't
see any way to do this without stalling the polled port(s) whilst the
SNMP request is being processed.)
I've asked about this elsewhere and been advised to use MRTG or Cacti:
these are not solutions to this problem.
-
Re: How to handle interface counter update delay?
On Thu, 29 May 2008 07:27:12 -0700 (PDT), nathan.baum@c4l.co.uk wrote:
> Hello,
>
> Testing with Cisco hardware and net-snmp on Linux reveals that
> interface counters -- if[HC]{Out,In}Octets -- are not updated in real
> time. Repeatedly polling coutners and noting when they change shows
> that counter updates can be from 5 to over 30 seconds apart, with
> longer intervals the more traffic is going through the interface.
>
> For billing purposes, I need to determine the average usage at five
> minute intervals: the 95th percentile of input and output is then
> calculated from that. The uneven counter update interval poses a
> problem for this because the polling interval isn't necessarily a
> multiple of the counter update interval.
>
Yes it gives jitter i graphs.
But do it give a significant different result when measured over
a week/month?
(Have a guess of how many 95% accounting are done on this type of
interfaces, many not aware of it and/or dont care :-)
Sooner or later you will find problems on interface counters
that are more serious that this.
> What I need is:
>
> 1. A timestamp OID which is updated whenever the counters for an
> interface are updated. This would enable me to "backdate" the sample
> to the time it actually represents. (Note that ifLastChange doesn't do
> this.); or
I considered doing this reading ipMRouteHCOctets that are only updated
approx. every 70 sec. But the coresponding ipMRouteUpTime runs
continuously!!
/hjj
-
Re: How to handle interface counter update delay?
On 1 Jun, 18:33, Hans Jørgen Jakobsen wrote:
> On Thu, 29 May 2008 07:27:12 -0700 (PDT), nathan.b...@c4l.co.uk wrote:
> > Hello,
>
> > Testing with Cisco hardware and net-snmp on Linux reveals that
> > interface counters -- if[HC]{Out,In}Octets -- are not updated in real
> > time. Repeatedly polling coutners and noting when they change shows
> > that counter updates can be from 5 to over 30 seconds apart, with
> > longer intervals the more traffic is going through the interface.
>
> > For billing purposes, I need to determine the average usage at five
> > minute intervals: the 95th percentile of input and output is then
> > calculated from that. The uneven counter update interval poses a
> > problem for this because the polling interval isn't necessarily a
> > multiple of the counter update interval.
>
> Yes it gives jitter i graphs.
> But do it give a significant different result when measured over
> a week/month?
Define significant. With up to 30-second updates and a 300 second
polling interval, the spikes can be up to 10% of the actual bandwidth.
I'd say that's significant.
> (Have a guess of how many 95% accounting are done on this type of
> interfaces, many not aware of it and/or dont care :-)
None of them that are me. The fact that other people do it wrong,
whether out of ignorance or apathy, isn't sufficient justification for
me to do it wrong.
> Sooner or later you will find problems on interface counters
> that are more serious that this.
Now imagine you're a customer who just got told that.
