Согласно RFC3414 SNMP engine должен заниматься ведение двух счётчиков snmpEngineBoots и snmpEngineTime. snmpEngineTime это секунды с последней загрузки и ведётся он верно. snmpEngineBoots это счетчик перезагрузок с момента установки EngineID и в DES-1210-10/ME он почемуто всегда равен нулю, по RFC клиент который опрашивает SNMP engine также должен вести свои snmpEngineBoots и snmpEngineTime для защиаты от replay-атак и при не совпадении snmpEngineTime длжен проверять не увеличилось ли snmpEngineBoots если да то увеличивает счетчик у себя и синхронизирует своё время по новой snmpEngineTime если иначе то даные snmpEngineTime игнорируется. То что DES-1210-10/MЕ не ведёт snmpEngineBoots не сказывается на работе одноразовых утилит типа snmp-walk и т.п. котрые не ведут счетчики и при каждом новом запросе заново синхрнизируются . Но проявляется в при работе процессов которые хранят состояние согласно RFC (например zabbix) получается что по SNMPv3 DES-1210-10/MЕ мониторится только до первой перезагрузки. После перезагрузки snmpEngineTime обнуляется, а snmpEngineBoots не увеличивается и попрежнему в SNMP ответах передаётся ноль, поэтому ситема мониторинга начинает игнорировать snmpEngineTime присланные коммутатором и в запросах продолжает полагаться на свой счётчик snmpEngineTime (срабатывает защиат от replay-атак) в результате получается рассинхронизация времени и коммутатор не отдаёт данные выдавая ошибку usmStatsNotInTimeWindows (при расхождение времени более 150 секунд по RFC). Как результат SNMPv3 использовать не нельзя в системах мониторинга где соблюдаются RFC.
Пробовал самые последние прошивки поведение аналогичное.
Известна ли эта ошибка и если извеснва то есть ли планы по устранению?

После переписки и продолжительного ожидания пришёл ответ от D-Link:

По уточненной в штаб-квартире информации snmpEngineBoots не поддерживается на наших коммутаторах.

Жаль.