Duplicate SNMPv3 Engine IDs detected in Spectrum

book

Article ID: 185753

calendar_today

Updated On:

Products

CA Spectrum CA eHealth

Issue/Introduction

Ever since upgrading to version 10.4.0.0.95 we are constantly receiving alarms for DUPLICATE SNMPv3 ENGINE IDS DETECTED

This is occurring hundreds of times a day on some devices.
We've tried deleting the devices and recreating them, clearing SNMPv3 cache on the server, resetting SNMPv3 authentication, and disabling IP redundancy. 

Events show Engine IDs are changing on devices:
The following error has been reported by the SNMP stack : usmStatsUnknownEngineIDs - EngineID is changed from yyyyyy to zzzzzz on Device IP "a.a.a.a". System     0x1003a

Another scenario with events that shows

The following error has been reported by the SNMP stack : usmstatsnotintimewindows- snmpEngineBoots is changed from 0 to 14 on Device IP "172.96.10.24". System     0x1003a

Cause

A sniffer trace showed the engineID from the device change from one packet to the next. These ids matches the events seen on the device in Spectrum.

Environment

Release : 10.4

Resolution

Run a sniffer trace.

This is what should happen:

Spectrum sends a get-request to the device with a blank engineid, engineboots, enginetime, and username. 
This is what should happen:

Spectrum sends a get-request to the device with a blank engineid, engineboots, enginetime, and username. 

The device then responds with a “report” packet informing Spectrum of the engineid, engineboots and enginetime along with an uknownengineid varbind.

Spectrum then uses the v3 profile that was set in the modeling and responds back using that v3 profile username, auth and priv.

 

Review the sniffer trace

If the engine id changes, Spectrum will generate the alarm.

If the device responds to the initial report packet with a value of zero for engineboots or enginetime, Spectrum will generate the alarm.

 

These are device issues, as seen from the sniffer trace.  Please consult the device vendor about this problem.