When does the Cisco IOS SNMP "ifCounterDiscontinuityTime" counter change?

Question

According to Cisco SNMP object navigator, ifCounterDiscontinuityTime(1.3.6.1.2.1.31.1.1.1.19) counter is the value of sysUpTime on the most recent occasion at which any one or more of this interfaces counters suffered a discontinuity. How to cause this discontinuity? I have tried to disable router interface("shutdown" and "no shutdown" for five seconds), removing physical cable for five seconds from router port, but still the value of ifCounterDiscontinuityTime is zero:

# snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.31.1.1.1.19
iso.3.6.1.2.1.31.1.1.1.19.1 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.31.1.1.1.19.2 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.31.1.1.1.19.3 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.31.1.1.1.19.4 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.31.1.1.1.19.5 = Timeticks: (0) 0:00:00.00
# 

I even caused Counter32 type counter to wrap, but the ifCounterDiscontinuityTime stayed zero:

$ snmpwalk -v 2c -c public 192.168.1.1 ifInOctets.10107
IF-MIB::ifInOctets.10107 = Counter32: 4278115545
$ snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.31.1.1.1.19.10107
IF-MIB::ifCounterDiscontinuityTime.10107 = Timeticks: (0) 0:00:00.00
$ snmpwalk -v 2c -c public 192.168.1.1 ifInOctets.10107
IF-MIB::ifInOctets.10107 = Counter32: 18656065
$ snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.31.1.1.1.19.10107
IF-MIB::ifCounterDiscontinuityTime.10107 = Timeticks: (0) 0:00:00.00
$ 

192.168.1.1 is a Cisco switch and 10107 is a SNMP ifIndex for port Gi0/7.

When does the SNMP ifCounterDiscontinuityTime counter change in Cisco IOS?

Answer 1

The ifCounterDiscontinuityTime is triggered when interfaces are dynamically removed from a device and then that same interface is dynamically re-added. I tested this using a loopback interface but I believe the behavior would be the same for modular interface whose existence would change based on whether or not the module was present. The steps to reproduce this are below and there is some further reading on this topic in the RFC here: https://www.rfc-editor.org/rfc/rfc2863#section-3.1.5

1. Create loopback 100 and find it's ifindex

router1#conf t
router1(config)#int loopback100
router1(config-if)#end

---

[user@host logs]$ snmpwalk -v 2c -c $COMMUNITY router1 .1.3.6.1.2.1.2.2.1.2 | grep Loopback
IF-MIB::ifDescr.67 = STRING: Loopback100

2. Check the current value of ifCounterDiscontinuityTime for Loopback100

[user@host logs]$ snmpwalk -v 2c -c $COMMUNITY router1 1.3.6.1.2.1.31.1.1.1.19.67
IF-MIB::ifCounterDiscontinuityTime.67 = Timeticks: (0) 0:00:00.00

3. Remove Loopback100 and check the value of ifCounterDiscontinuityTime

router1(config)#no int loopback 100

---

[user@host logs]$ snmpwalk -v 2c -c $COMMUNITY router1 1.3.6.1.2.1.31.1.1.1.19.67
IF-MIB::ifCounterDiscontinuityTime.67 = No Such Instance currently exists at this OID

4. Re-add Loopback100 and check the value of ifCounterDiscontinuityTime

router1(config)#int loopback 100

[user@host logs]$ snmpwalk -v 2c -c $COMMUNITY router1 1.3.6.1.2.1.31.1.1.1.19.67
IF-MIB::ifCounterDiscontinuityTime.67 = Timeticks: (111308186) 12 days, 21:11:21.86

Answer 2

I think discontinuity refers to an abnormality. I found this

The value of sysUpTime on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the ifTable or ifXTable. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value.

to me, that implies that "discontinuity" is related to bit-size-integer-rollover.

So if you see the sysTime change, you know that counters that are now showing smaller-than-last-time-checked values have, in fact, wrapped around, as if you had rebooted.