Khi nào thì bộ đếm Cisco IOS SNMP ifCountDiscContuityTime thời gian thay đổi?

Theo bộ điều hướng đối tượng SNMP của Cisco, bộ ifCounterDiscontinuityTimeđếm (1.3.6.1.2.1.31.1.1.1.19) là giá trị của sysUpTimedịp gần đây nhất mà bất kỳ một hoặc nhiều bộ đếm giao diện này bị gián đoạn. Làm thế nào để gây ra sự gián đoạn này? Tôi đã cố gắng vô hiệu hóa giao diện bộ định tuyến ("tắt máy" và "không tắt máy" trong năm giây), loại bỏ cáp vật lý trong năm giây khỏi cổng bộ định tuyến, nhưng giá trị ifCounterDiscontinuityTimevẫn bằng 0:

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

Tôi thậm chí đã gây ra bộ Counter32đếm loại để bọc, nhưng ifCounterDiscontinuityTimesố không ở lại:

$ 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.1là một bộ chuyển mạch của Cisco và 10107là một SNMP ifIndexcho cổng Gi0 / 7.

Khi nào bộ ifCounterDiscontinuityTimeđếm SNMP thay đổi trong Cisco IOS?

IfCorerDiscContuityTime được kích hoạt khi các giao diện được tự động xóa khỏi thiết bị và sau đó giao diện đó được tự động thêm lại. Tôi đã thử nghiệm điều này bằng giao diện loopback nhưng tôi tin rằng hành vi sẽ giống với giao diện mô-đun mà sự tồn tại của nó sẽ thay đổi dựa trên việc mô-đun có hiện diện hay không. Các bước để tái tạo điều này dưới đây và có một số đọc thêm về chủ đề này trong RFC tại đây: https://tools.ietf.org/html/rfc2863#section-3.1.5

1. Tạo loopback 100 và tìm 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. Kiểm tra giá trị hiện tại của ifCorerDiscContuityTime cho 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. Xóa Loopback100 và kiểm tra giá trị của ifCorerDiscContuityTime

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. Thêm lại Loopback100 và kiểm tra giá trị của ifCorerDiscContuityTime

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

Tôi nghĩ rằng sự gián đoạn đề cập đến một sự bất thường. Tôi tìm thấy cái này

Giá trị của sysUpTime trong dịp gần đây nhất mà tại đó bất kỳ một hoặc nhiều bộ đếm của giao diện này đều bị gián đoạn. Các bộ đếm liên quan là các trường hợp cụ thể được liên kết với giao diện này của bất kỳ đối tượng Counter32 hoặc Counter64 nào có trong ifTable hoặc ifXTable. Nếu không có sự gián đoạn như vậy xảy ra kể từ lần khởi tạo lại cuối cùng của hệ thống con quản lý cục bộ, thì đối tượng này chứa giá trị bằng không.

với tôi, điều đó hàm ý rằng "sự gián đoạn" có liên quan đến rollover bit-size-integ-rollover.

Vì vậy, nếu bạn thấy sự thay đổi của sysTime, bạn biết rằng các bộ đếm hiện đang hiển thị các giá trị được kiểm tra nhỏ hơn so với lần trước, trên thực tế, được bao bọc xung quanh, như thể bạn đã khởi động lại.