Hope you don't mind the thread bump, but have the 64 bit traffic counters made any progress?
I understand there are other things that need working on more importantly, but if not, is there anything you'd recommend for a fairly lightweight SNMP client to lag/graph traffic? Ideally something I could run either inside Smallwall or on another headless system.
Something able to produce an output like this would be great (I believe this is from pfSense), to get an idea of usage per month as I currently have no real way of logging it: i.imgur.com/V9PtFTV.png
Router reboots cause very large negative values to be injected into the IOG database for the one hour period where the router reboot happened. This has the effect of spoiling the output for that hour, that day, and even the entire month if the the monthly total up to that point was small compared to the magnitude of the erroneous data.
I contacted the author about this and he didn't seem terribly interested in fixing it. The code hasn't been updated in nearly 13 years, and the last update was supposed to solve this problem, but apparently not.
MRTG has a similar problem, but it is possible to make adjustments to its database to at least mitigate the damage to be barely noticeable.
I'm not sure if the problem has a similar cause but I've noticed if I'm watching the m0n0/smallwall interface traffic graph when it crosses the ~4GB rollover point it shows a huge negative value for throughput.
Thanks for the heads-up though I'll be sure to keep an eye out for it.
Ooops... I get what you are saying now. With the newly supported 64bit counters in SmallWall we no longer get the counter wraps that we used to, but we still do get reboot resets. But if you set the bandwidth counter to never allow a negative value, it will only spike to zero.
The problem with negative values is that they are not entirely illegitimate and can not be just ignored in all cases. They can show up when a counter does legitimately wrap when the calculated difference between the current reading and last reading could properly be negative. This says that a counter did wrap, or the device was rebooted. But it can't say how many times it wrapped or rebooted. Thus an assumption has to be made. This is one of the reasons this problem has never been really solved, and likely won't be solved unless wraps and reboots are tracked and recorded elsewhere (off device).
MRTG's database can be told to ignore overly large values, but doing so can also hurt accuracy if discarded values were in fact legitimate.
No idea why IOG is still broken, even after allegedly being fixed. Maybe a perl wizzard can look it over. The author seemed disinterested.