In order to deal with overflown octet in/out counters, the plugin checks if the counters that were currently retrieved from the device have a value lower than the ones stored in the file from the previous run(s).
But the same thing will happen (i.e. retrieved counters are lower than previously stored ones) in case of a device reboot. So the plugin will assume a reset of the counters as an overflow and will report erroneous interface utilization (way over 100%). In case warning/critical thresholds have been specified, the plugin will also report warning/critical result.
Obviously the best way to solve this would be to introduce an extra check for the device uptime.
A good workaround though, that requires much less changes in the plugin code, is to check if both octet-in and -out counters have "overflown" at the same run.
It is extremely rare that a simultaneous in/out counter overflown would have happened in real world interface traffic conditions, so I think this workaround is a pretty safe to assume.
If you agree I can create a pull request that implements this workaround.
In order to deal with overflown octet in/out counters, the plugin checks if the counters that were currently retrieved from the device have a value lower than the ones stored in the file from the previous run(s). But the same thing will happen (i.e. retrieved counters are lower than previously stored ones) in case of a device reboot. So the plugin will assume a reset of the counters as an overflow and will report erroneous interface utilization (way over 100%). In case warning/critical thresholds have been specified, the plugin will also report warning/critical result.
Obviously the best way to solve this would be to introduce an extra check for the device uptime. A good workaround though, that requires much less changes in the plugin code, is to check if both octet-in and -out counters have "overflown" at the same run. It is extremely rare that a simultaneous in/out counter overflown would have happened in real world interface traffic conditions, so I think this workaround is a pretty safe to assume.
If you agree I can create a pull request that implements this workaround.
Thank you.