ACE Module SNMP limits

[jason.nadeau]

I am monitoring an ACE module using snmp. The values returned from certain OIDs are graphed using Cacti. I found the 64 bit counters on interfaces for the ACE wrap at 10,000,000,000 instead of 2^64. Now that I have configured cacti to expect the wrap at 10 billion, I am concerned about the 32 bit counters. I am querying this snmp oid to get L7 connection counter

cslbxStatsL7PolicyConns

1.3.6.1.4.1.9.9.254.1.1.1.1.8

Should I expect this counter to wrap at 2^32 or a lower value?

[chrhiggi]

Hello Jason!

OID 1.3.6.1.4.1.9.9.254.1.1.1.1.8 is actually a 32 bit counter.  You can check it with our OID lookup tool located here:

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.9.9.254.1.1.1.1.8&translate=Translate&submitValue=SUBMIT

Where did you see it noted as a 64 bit counter?

Regards,

Chris

[jason.nadeau]

Hi Chris,

You are correct ...1.1.8 is a 32-bit counter. That OID is supposed to count the number of layer 7 connections. My question is will the maximum counter value be 2^32?

The reason I ask is the 64-bit counter for interface octets on the Cisco ACE. I have never seen the value higher than 200,000,000,000 before it resets to 0. The way I understand it is the 64-bit counter should reach 2^64 which is a much larger value.

If the ...1.1.8 counter does wrap at a lower number it could cause issues with Cacti when monitoring it.

[chrhiggi · Accepted solution]

The maximum value for a 32bit OID should be 4294967296, I do have a value in my lab that is above 1 billion for that counter, so I wouldn't think there is an issue immediately. One common issue - when you clear stats manually, the counter will reset to 0. As well, I found an internal bug that that suggested some pocket case within the code could have cleared stats incorrectly, but it has never been seen since. There is a guess that someone logged into the test bed and cleared it without permission, but it was not able to be verified. Hence the bug was created to investigate the code, turned up nothing, and was junked accordingly.

What you might want to do is keep a sharp eye on the counter. When it looks like it rolls, login to the context you are polling and take a look at the accounting log. If you find that someone cleared the logging, that answers the question. If not - log a TAC case and we can replicate your exact configuration/code version in our lab to see if there what the deviation is that causes it to clear. A bug would be logged and fixed.

Regards,

Chris Higgins

[jason.nadeau]

Chris,

I was digging through release notes for A2(2.4) and I found this under Open Caveats. This sounds like what I am experiencing but instead of unicast bytes input counter I am seeing it on oubound octets. My module is still running A1 code and I am going to updates it soon and see if that fixes my problem, but I just wanted to provide addtional feedback.

CSCtf44818—ACE module  sometimes looses its count on interface unicast bytes input counter.  This can cause problems for SNMP tracking the traffic, which in turn  shows ~50Gbps flowing through the ACE. Workaround: SNMP application can  be configured so it ignores the counter increases above some value.

Jason