¿Cuándo cambia el contador de Cisco IOS SNMP "ifCounterDiscontinuityTime"?

Según el navegador de objetos SNMP de Cisco, el ifCounterDiscontinuityTimecontador (1.3.6.1.2.1.31.1.1.1.19) es el valor de sysUpTimela ocasión más reciente en la que uno o más de estos contadores de interfaz sufrieron una discontinuidad. ¿Cómo causar esta discontinuidad? He intentado deshabilitar la interfaz del enrutador ("apagado" y "no apagar" durante cinco segundos), quitando el cable físico durante cinco segundos del puerto del enrutador, pero el valor de ifCounterDiscontinuityTimees cero:

# 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
# 

Incluso hice que el Counter32contador de tipo se ajustara, pero el ifCounterDiscontinuityTimecero se mantuvo:

$ 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.1es un conmutador Cisco y 10107es un SNMP ifIndexpara el puerto Gi0 / 7.

¿Cuándo ifCounterDiscontinuityTimecambia el contador SNMP en Cisco IOS?

IfCounterDiscontinuityTime se activa cuando las interfaces se eliminan dinámicamente de un dispositivo y luego esa misma interfaz se vuelve a agregar dinámicamente. Probé esto usando una interfaz de bucle invertido, pero creo que el comportamiento sería el mismo para la interfaz modular cuya existencia cambiaría en función de si el módulo estaba presente o no. Los pasos para reproducir esto están a continuación y hay algunas lecturas adicionales sobre este tema en el RFC aquí: https://tools.ietf.org/html/rfc2863#section-3.1.5

1. Cree el loopback 100 y descubra que es 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. Compruebe el valor actual de ifCounterDiscontinuityTime para 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. Elimine Loopback100 y verifique el valor de 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. Vuelva a agregar Loopback100 y verifique el valor de 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

Creo que la discontinuidad se refiere a una anormalidad. Encontre esto

El valor de sysUpTime en la ocasión más reciente en la que uno o más de los contadores de esta interfaz sufrieron una discontinuidad. Los contadores relevantes son las instancias específicas asociadas con esta interfaz de cualquier objeto Counter32 o Counter64 contenido en ifTable o ifXTable. Si no se han producido tales discontinuidades desde la última reinicialización del subsistema de gestión local, este objeto contiene un valor cero.

para mí, eso implica que la "discontinuidad" está relacionada con la conversión de enteros de tamaño de bit.

Entonces, si ve el cambio de sysTime, sabe que los contadores que ahora muestran valores comprobados más pequeños que la última vez, de hecho, se han ajustado, como si hubiera reiniciado.