How are counter wraps/rollovers handled?

Hi,

The simple explanation is that we check if the latest polled value is less than the previous.

Depending on your Counter Rollover setting:

Method 1:

if it is we check if the device has rebooted and reset it's counters to 0, in which case we use 0 as the last value.

Otherwise, if it is due to rollover, we take the maximum value of the 32 or 64 bit number and take the difference between the max and the last polled value and add it to the current polled value:

(MaxValue - LastPolledValue) + CurrentPolledValue

Method 2:

Wait to poll the interface again and then calculate Bps from the next value.

------------

Please let me know if I can clarify any of these points.

Thanks

Thanks, this is exactly what I was hoping to hear!

KARLO - May I ask a question here?

How do you know when it is best to turn on 64bit counters since this is enabled at the node level? Does having a Point-to-Point drive this usage and would this counter provide any benefit for non-Cisco devices like a VMware or Windows?

Hi,

These counters are specifically for interface traffic.  So depending if your device/interface supports 1.3.6.1.2.1.2.2.1.10. (32 bit) or
1.3.6.1.2.1.31.1.1.1.6. (64 bit), then that will ultimately determine if we can use the 64 bit counters.

The support of these OIDs is really on a device by device basis and I am not 100% sure of what devices and OSes support the 64 bit version.  I do know that many Cisco devices support these but I am not sure if anything else does.  Perhaps the community would know better than me on this.

The advice we give in the documentation is to try it and if you are seeing problems, go back to the 32 bit counters:

http://www.solarwinds.com/support/Orion/docs/OrionAdministratorGuide.pdf

Hope this helps.

We have just finished polulating our Orion install v9.1 SP5 and have related issues.  So far it's only affected TenGig interfaces where the utilization is being under-reported.  I have several questions:

1) Should we select all nodes and enable 64-bit support as the above implies?  Or should we query all devices first to see if they support the 64-bit OID mentioned above (but I guess we wouldn't need to if it falls back to 32-bit).  Or should we enable 64-bit for each type of device we have and confirm that the measurements are accurate before enabling across the board for those device types?

2) I enabled 64-bit support for one of our nodes (a Cisco 6509 VSS cluster) and though the Node view showed 64 bit support, the individual interfaces view did not and the utilization remained inaccurate.  I had to remove the device and re-add it before the interfaces would show 64-bit support and the data became accurate.  Is it required to remove/re-add device when changing the 64-bit support option?  Or do we need to disable and enable the interfaces?  The 120min rediscovery interval did not seem to update it.

3) After re-adding the device, the xmit and rec values are accurate, but the interface BW is being reported as 4.3 Gbps instead of 10 Gbps on these TenGig interfaces.  Is this a known issue?

Thanks,

Matt

Hi,

1) I would not do this in a bulk update.  I would try it on one of your devices.  We have seen historically where the enabling of the 64 bit feature is bad for some devices.  Once you are sure your device is fine, then I would feel more comfortable applying this to more of your devices.  Testing if the 64 bit OID is supported is a great first step.

2) This sounds like a bug.  I think we should be picking up this change, so if you wouldn't mind opening up a support ticket, we can track this.

3) Again, this is something we can look at from the support side, perhaps we need to look at your diagnostics.  You could check what your device is responding to 1.3.6.1.2.1.2.2.1.5 and 1.3.6.1.2.1.31.1.1.1.15 to see what the number we are getting back for ifSpeed.  We report accurately according to the information from most devices, so this would not be considered a known issue.

Thanks

This was resolved a few weeks ago but I forgot to update this.  The main problem we were running into was that our 1000+ nodes were added using Network Discovery and via seedfiles.  This resulted in all of them being added as SNMPv1 nodes instead of SNMPv2, which is a min requirement for using 64-bit counters (at least for Cisco).  Some related threads:

SNMP version not defined in seed file

Updating SNMP version on multiple nodes

Updating Allow64BitCounters

Anyway, we did some testing and then made some bulk SNMP and 64-bit Counter changes while we were still running v9.1.  I do not know if anything has changed with v9.5 concerning Network Discovery's default SNMP version or default 64-bit support.