cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2163
Views
0
Helpful
1
Replies

Contradicting ifInErrors counter numbers.

prakashrj
Level 1
Level 1

Hi Guys,

Why is the switch reporting 2 different values for number of inbound packets that contain errors? snmpwalk still reports old error packet count after clearing counters.

> snmpwalk -v2c -c SNMP_READ switch.cisco.com ifInErrors |

grep 1055804

IF-MIB::ifInErrors.295 = Counter32: 1055804

> (enable) sh counters 7/42 | in ifInErrors

6 ifInErrors = 0

Please let me know what I am missing here.

Thanks,

Prakash.

1 Reply 1

glen.grant
VIP Alumni
VIP Alumni

Not positive but I don't think the snmp counters are the same table as when you do a "show interface" command. You might find your answer here http://cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800b69ac.shtml#QC

Basically is says this

Q. Why don't SNMP counters return the same number as CLI show commands?

A. An SNMP object defined as a Counter must abide by RFC1155 leaving cisco.com :

"3.2.3.3. Counter

This application-wide type represents a non-negative integer which monotonically increases until it reaches a maximum value, when it wraps around and starts increasing again from zero. This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for counters."

There are no methods to reset an SNMP counter to zero short of reloading the device.

The counter output from a CLI show command can be reset on interfaces since the SNMP restrictions are not present.

The original interface counters defined in MIB-2 are 32-bit counters. For a 10 Mbps interface, a 32-bit counter could theoretically wrap in 57 minutes. Avoiding discontinuities is easy with such a long period. But for 100 Mbps, the minimum theoretical wrap time is 5.7 minutes. For 1 Gbps interfaces, it falls to 34 seconds. Granted these times are for transmission of back-to-back full-sized packets, a theoretical ideal. Even so, the higher the interface speed, the harder it becomes to avoid missing a counter wrap. As a solution to this problem, SNMPv2 SMI defined a new object type -- counter64 -- for 64-bit counters. Therefore, there are several new 64-bit counters defined in the extension interface table (ifxTable) defined in RFC 1573 leaving cisco.com (later superceded by

RFC 2233 leaving cisco.com ). These are from the IF-MIB-V1SMI.my.

ifHCInOctets (.1.3.6.1.2.1.31.1.1.1.6) ifHCOutOctets (1.3.6.1.2.1.31.1.1.1.10)

ifHCInUcastPkts (.1.3.6.1.2.1.31.1.1.1.7) ifHCOutUcastPkts (.1.3.6.1.2.1.31.1.1.1.11)

ifHCInMulticastPkts (.1.3.6.1.2.1.31.1.1.1.8) ifHCOutMulticastPkts (.1.3.6.1.2.1.31.1.1.1.12)

ifHCInBroadcastPkts (.1.3.6.1.2.1.31.1.1.1.9) ifHCOutBroadcastPkts (.1.3.6.1.2.1.31.1.1.1.13)

Although basic support for 64-bit counters was written into Cisco IOS software in version 11.3, starting from Cisco IOS software release 12.0, only ifHCInOctets (.1.3.6.1.2.1.31.1.1.1.6) and ifHCOutOctets (1.3.6.1.2.1.31.1.1.1.10) have been implemented for ATM LANE LEC sub-interfaces only. For Catalyst workgroup switches, 64-bit counter support has been implemented in version 3.1.

Note: You must use SNMPv2c or SNMPv3 protocol to retrieve any counter64 objects.