Hi,
We're running a set of 5010 switches and in preparation for some soak testing embarked on setting up our usual snmp based monitoring. After letting the graphs settle we started to see wild results in terms of the amount of traffic claiming to traverse all of the interfaces. A 10G switch it may be but with not much running behind it graphs claiming up to 15G were a little strange to say the least!
Anyways digging further and trawling for similar issues we came across an issue with versions < 4.1(3)N(2a) not supporting 64 bit counters for physical interfaces - these threads alluded that this version fixes the problem and we are infact currently running 4.1(3)N(1)
However we've seen a slight difference in this behaviour whereby both the 32 bit and 64 bit counters exist but claim to be reporting the same value - which is incorrect.
[root@poller1 ~]# snmpget x.x.x.x -c blahblah -v2c ifHCInOctets.436215808
IF-MIB::ifHCInOctets.436215808 = Counter64: 407787321
IF-MIB::ifHCInOctets.436215808 = Counter64: 407787321
IF-MIB::ifHCInOctets.436215808 = Counter64: 407787321
[root@poller1 ~]# snmpget x.x.x.x -c blahblah -v2c ifInOctets.436215808
IF-MIB::ifInOctets.436215808 = Counter32: 407787321
There are no references to any physical interfaces in the ifHCInOctet tree yet a value is still returned; and furthermore we see huge disparities in the value returned; peaks suggesting a huge spike in traffic, which as the number is no longer accumulative is playing havoc with our monitoring system's calculations
IF-MIB::ifHCInOctets.436215808 = Counter64: 130822020033
root@poller1 ~]# snmpget x.x.x.x -c blahblah -v2c ifHCInOctets.436215808
IF-MIB::ifHCInOctets.436215808 = Counter64: 130822020033
root@poller1 ~]# snmpget x.x.x.x -c blahblah -v2c ifHCInOctets.436215808
IF-MIB::ifHCInOctets.436215808 = Counter64: 407517806 BACK TO NORMAL??
root@poller1 ~]# snmpget x.x.x.x -c blahblah -v2c ifHCInOctets.436215808
IF-MIB::ifHCInOctets.436215808 = Counter64: 407517806
Clearly something isn't right and my next course of action is to upgrade to try and circumvent the problem.
To put our minds at rest is this a common bug and has it been solved in version 4.2? Resolved caveats doesnt mention this, or the other issues
Many thanks,
Ed
