ahRadioTxAirtime ahRadioRxAirtime snmp 32-bit counters

  • 1
  • Question
  • Updated 3 years ago
The ah_interface_mib.txt mib defines ahRadioTxAirtime and ahRadioRxAirtime as having snmp 64-bit counters:
SYNTAX          Counter64
The accumulative [transmit/receive] time in microseconds (us)
                        from the given Radio.

But snmp query shows they're 32-bit counters - the oids return:
[root@centos60 snmp_queries]# snmpwalk -v 2c -c hivecommunity 10.1.1.90 .1.3.6.1.4.1.26928.1.1.1.2.1.3.1.22
SNMPv2-SMI::enterprises.26928.1.1.1.2.1.3.1.22.10 = Counter32: 378033878
SNMPv2-SMI::enterprises.26928.1.1.1.2.1.3.1.22.11 = Counter32: 119807266
[root@centos60 snmp_queries]# snmpwalk -v 2c -c hivecommunity 10.1.1.90 .1.3.6.1.4.1.26928.1.1.1.2.1.3.1.23
SNMPv2-SMI::enterprises.26928.1.1.1.2.1.3.1.23.10 = Counter32: 9692329
SNMPv2-SMI::enterprises.26928.1.1.1.2.1.3.1.23.11 = Counter32: 3786704

Query of mib-2 shows the software does have some 64-bit counters, just not the ones in question:
[root@centos60 snmp_queries]# snmpwalk -v 2c -c hivecommunity 10.1.1.90
1.3.6.1.2.1.31.1.1.1.10.6
IF-MIB::ifHCOutOctets.6 = Counter64: 126650278


The APs are on HiveOS 6.4r1d.2111
Is the mib incorrect or the code?
Typical management software (Nagios, Cacti, MRTG) default polling is @ 5 minutes which works fine for 64-bit counters.  32-bit counters on a heavily-loaded interface could cycle if not polled @1 minute.  Very few of the counters described in the mib are 64-bit.

Also, if no clients are on a radio, the counters do not increment.  Does the time in microseconds reflect only traffic to clients, not time spent on management traffic?
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Good question/point of interest.

The 64-bit counters that don't have wrapping issues came with SNMP v2c so 32-bit counters should never be offered/used these days.

If it is the case that 32-bit values are being used, that would be a bug IMO and they should be changed, backwards compatibility be damned! :P

This is something that you should open a support case on therefore.

Nick
(Edited)
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
Support case opened awhile back - Cacti template posted just now.
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
Just in from Aerohive - this is being addressed as a documentation bug, i.e. the mib is incorrect.  The code is not being changed to be 64-bit counters.  The Cacti templates I posted should be fine but polling fairly often to avoid having the32-bit counters roll.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Dianne,

As you know, we cannot use 32-bit counters sensibly in the modern world, they overflow really easily in high usage scenarios.

Expecting a regular, high frequency poll is poor from an engineering standpoint to detect a counter wrapping.

That said, changing the behaviour now of the existing counter could lead to compatibility issues with existing consumers.

The SNMP implementation in HiveOS needs a much larger overhaul so I would realistically expect something to be done about this at that point where it's not possible now. Mike Kouri suggested that overhaul would be considered for a major release, something akin to HiveOS 7.

There is a chance then to get all the 'ducks in a row' from a compatibility impact perspective to switch to a pure play 64-bit counter.

Regards,

Nick
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Just a thought, were you told if engineering considered adding the high order bits in to another counter as a temporary workaround?

This does have downsides if there are future plans to redo the whole feature as you'll get people taking a dependency on something you ultimately intend to get rid of. No quick and easy answer!

An ahRadioTxAirtimeHigh and ahRadioRxAirtimeHigh could be added and this would have no compatibility implications whatsoever. Both counter pairs could be retrieved via a single SNMP request for atomicity.

It's easy to combine the two 32-bit valus in code, pasting something that's from a much larger C# project that I wrote and is to hand (copes with wrapping with 32-bit only and combining where it's 64-bit):
/// <summary>Gets the 64-bit value.</summary>
/// <param name="previousValue">The previous value.</param>
/// <param name="lowValue">The low order 32-bit value.</param>
/// <param name="highValue">The high order 32-bit value.</param>
/// <returns>The 64-bit value.</returns>
private static ulong GetUInt64(ulong previousValue, uint lowValue, uint? highValue)
{
    if (highValue == null)
    {
        ulong previousHighValue = previousValue & 0xFFFFFFFF00000000UL;
        if ((uint)previousValue > lowValue)
        {
            return (previousHighValue + 0x100000000UL) | lowValue;
        }
        return previousHighValue | lowValue;
    }
    return ((ulong)highValue.Value << 32) | lowValue;
}
RADIUS accounting, by spec, originally had the same issue and solved it by adding new attributes to hold the high order bits of a 64-bit value.

The 32-bit Acct-Input-Gigawords and Acct-Output-Gigawords were added to compliment the 32-bit Acct-Input-Octets and Acct-Output-Octets.
(Edited)