Following the implementation of ZBX-24989, Zabbix 7.0 performs a periodic snmp_cache_reload every 24 hours on both the Zabbix Server and Zabbix Proxies. This behavior is not present in Zabbix 6.0 and is not documented in the Zabbix 7.0 release notes or official documentation.

In SNMPv3, message freshness is enforced via time window validation using the msgAuthoritativeEngineTime and msgAuthoritativeEngineBoots fields. This mechanism is defined in RFC 3414, Section 3.2.7:

7) If the securityLevel indicates an authenticated message, then the
local values of snmpEngineBoots, snmpEngineTime and
latestReceivedEngineTime corresponding to the value of the
msgAuthoritativeEngineID field are extracted from the Local
Configuration Datastore.

a) If the extracted value of msgAuthoritativeEngineID is the same
as the value of snmpEngineID of the processing SNMP engine
(meaning this is the authoritative SNMP engine), then if any
of the following conditions is true, then the message is
considered to be outside of the Time Window:

• the local value of snmpEngineBoots is 2147483647;

• the value of the msgAuthoritativeEngineBoots field differs
  from the local value of snmpEngineBoots; or,

• the value of the msgAuthoritativeEngineTime field differs
  from the local notion of snmpEngineTime by more than +/- 150
  seconds.

If the message is considered to be outside of the Time Window
then the usmStatsNotInTimeWindows counter is incremented and
an error indication (notInTimeWindow) together with the OID,
the value of the incremented counter, and an indication that

Blumenthal & Wijnen Standards Track [Page 28]

RFC 3414 USM for SNMPv3 December 2002

the error must be reported with a securityLevel of authNoPriv,
is returned to the calling module

b) If the extracted value of msgAuthoritativeEngineID is not the
same as the value snmpEngineID of the processing SNMP engine
(meaning this is not the authoritative SNMP engine), then:

1) if at least one of the following conditions is true:

• the extracted value of the msgAuthoritativeEngineBoots
  field is greater than the local notion of the value of
  snmpEngineBoots; or,

• the extracted value of the msgAuthoritativeEngineBoots
  field is equal to the local notion of the value of
  snmpEngineBoots, and the extracted value of
  msgAuthoritativeEngineTime field is greater than the
  value of latestReceivedEngineTime,

then the LCD entry corresponding to the extracted value of
the msgAuthoritativeEngineID field is updated, by setting:

• the local notion of the value of snmpEngineBoots to the
  value of the msgAuthoritativeEngineBoots field,

• the local notion of the value of snmpEngineTime to the
  value of the msgAuthoritativeEngineTime field, and

• the latestReceivedEngineTime to the value of the value of
  the msgAuthoritativeEngineTime field.

2) if any of the following conditions is true, then the
message is considered to be outside of the Time Window:

• the local notion of the value of snmpEngineBoots is
  2147483647;

• the value of the msgAuthoritativeEngineBoots field is
  less than the local notion of the value of
  snmpEngineBoots; or,

• the value of the msgAuthoritativeEngineBoots field is
  equal to the local notion of the value of snmpEngineBoots
  and the value of the msgAuthoritativeEngineTime field is
  more than 150 seconds less than the local notion of the
  value of snmpEngineTime.

Blumenthal & Wijnen Standards Track [Page 29]

RFC 3414 USM for SNMPv3 December 2002

If the message is considered to be outside of the Time
Window then an error indication (notInTimeWindow) is
returned to the calling module.

Note that this means that a too old (possibly replayed)
message has been detected and is deemed unauthentic.

Note that this procedure allows for the value of
msgAuthoritativeEngineBoots in the message to be greater
than the local notion of the value of snmpEngineBoots to
allow for received messages to be accepted as authentic
when received from an authoritative SNMP engine that has
re-booted since the receiving SNMP engine last
(re-)synchronized.

https://datatracker.ietf.org/doc/html/rfc3414#section-3.2

This condition causes the message to be considered "outside of the Time Window" and it is therefore discarded.

When SNMPv3 devices do not fully comply with RFC 3414 - particularly with respect to maintaining consistent snmpEngineTime values - metrics will stop being collected once the drift exceeds the protocol’s acceptance threshold.

The automatic SNMP cache reload resets the internal engineID and time state, temporarily allowing metric collection to resume for such devices. This can effectively mask protocol violations and lead to intermittent data collection from non-compliant devices.

As a result, items on these devices may appear to start working again every 24 hours, which can confuse administrators and make it harder to identify the real issue.