Wann ändert sich der Cisco IOS SNMP-Zähler "ifCounterDiscontinuityTime"?

7

Laut Cisco SNMP Object Navigator ifCounterDiscontinuityTimeist der Zähler (1.3.6.1.2.1.31.1.1.1.19) der Wert von sysUpTimebei der letzten Gelegenheit, bei der einer oder mehrere dieser Schnittstellenzähler eine Diskontinuität erlitten haben. Wie kann diese Diskontinuität verursacht werden? Ich habe versucht, die Router-Schnittstelle zu deaktivieren ("Herunterfahren" und "Kein Herunterfahren" für fünf Sekunden) und das physische Kabel für fünf Sekunden vom Router-Port zu entfernen, aber der Wert von ifCounterDiscontinuityTimeist immer noch Null:

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

Ich habe sogar den Counter32Typzähler umbrechen lassen, aber der ifCounterDiscontinuityTimeblieb Null:

$ 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.1ist ein Cisco-Switch und 10107ein SNMP ifIndexfür Port Gi0 / 7.

Wann ändert sich der SNMP- ifCounterDiscontinuityTimeZähler in Cisco IOS?

cisco snmp

— Martin
quelle

Hmm ... ich denke, es ist eher ein Router- oder Verbindungsproblem? Idk ... ich werde das untersuchen, aber sicher ist es eine Zeitüberschreitung, sicher, dass das Signal möglicherweise keine gute Antwort erhalten hat.

— Popscapo

6

Die ifCounterDiscontinuityTime wird ausgelöst, wenn Schnittstellen dynamisch von einem Gerät entfernt und dieselbe Schnittstelle dynamisch neu hinzugefügt wird. Ich habe dies mit einer Loopback-Schnittstelle getestet, aber ich glaube, dass das Verhalten für eine modulare Schnittstelle gleich ist, deren Existenz sich je nachdem ändert, ob das Modul vorhanden ist oder nicht. Die Schritte zur Reproduktion sind unten aufgeführt. Weitere Informationen zu diesem Thema finden Sie im RFC hier: https://tools.ietf.org/html/rfc2863#section-3.1.5

1. Erstellen Sie Loopback 100 und suchen Sie den 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. Überprüfen Sie den aktuellen Wert von ifCounterDiscontinuityTime für 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. Entfernen Sie Loopback100 und überprüfen Sie den Wert von 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. Fügen Sie Loopback100 erneut hinzu und überprüfen Sie den Wert von 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

— Luke Klimasauskas
quelle

Vielen Dank! Ich kann bestätigen, dass zum Beispiel das Entfernen und Einsetzen von WS-X4306-GBoder WS-X4448-GB-RJ45Line-Karten in das WS-C4506Gehäuse ebenfalls ifCounterDiscontinuityTimezu Änderungen führen wird. ifCounterDiscontinuityTimeWird also im Grunde der Zeitstempel protokolliert, als die Schnittstelle für die SNMP-Engine verfügbar wurde? Wenn die Schnittstelle von Anfang an verfügbar war, ifCounterDiscontinuityTimebleibt die 0?

— Martin

1

Wenn ich den RFC richtig verstehe, zeichnet ifCounterDiscontinuityTime den Zeitstempel auf, als die Schnittstelle mit demselben ifIndex wieder vorhanden wurde. Dies hat den Zweck, dass Ihre SNMP-Überwachungssoftware beim Vergleich mit neuen Schnittstellenzählerdaten keine veralteten Schnittstellenzählerdaten verwendet. Der ifCounterDiscontinuityTime-Wert wird nur initialisiert, wenn eine Schnittstelle entfernt und dann mit demselben ifIndex erneut hinzugefügt wird, andernfalls bleibt er Null. Ich hoffe, das hilft.

— Luke Klimasauskas

3

Ich denke, Diskontinuität bezieht sich auf eine Abnormalität. Ich fand diese

Der Wert von sysUpTime bei der letzten Gelegenheit, bei der einer oder mehrere der Zähler dieser Schnittstelle eine Diskontinuität aufwiesen. Die relevanten Zähler sind die spezifischen Instanzen, die dieser Schnittstelle eines in der ifTable oder ifXTable enthaltenen Counter32- oder Counter64-Objekts zugeordnet sind. Wenn seit der letzten Neuinitialisierung des lokalen Verwaltungssubsystems keine derartigen Diskontinuitäten aufgetreten sind, enthält dieses Objekt den Wert Null.

Für mich bedeutet dies, dass "Diskontinuität" mit einem Bit-Size-Integer-Rollover zusammenhängt.

Wenn Sie also die Änderung von sysTime sehen, wissen Sie, dass Zähler, die jetzt Werte anzeigen, die kleiner als das letzte Mal überprüft wurden, tatsächlich so umbrochen wurden, als hätten Sie einen Neustart durchgeführt.

— Craig Constantine
quelle

Danke für die Antwort! Um ehrlich zu sein, ist dies etwas verwirrend. Wenn ich eine sysUpTimeÄnderung auf einen kleineren Wert als die letzte Überprüfung sehe, würde ich denken, dass Zähler, die Werte anzeigen, die kleiner als die zuletzt überprüfte Zeit sind, nicht umbrochen werden, weil das Gerät neu geladen wurde. Oder habe ich dich irgendwie missverstanden? Außerdem habe ich einen Counter32Typzähler eingewickelt , der sich nicht auswirkte ifCounterDiscontinuityTime. Ich habe meinen ersten Beitrag aktualisiert.

— Martin