CA Spectrum can now model devices with duplicate engineid

[Jason Meader]

It's here!  Functionality has been added to Spectrum 10.2.0 and 10.2.1 to allow the modeling of devices with duplicate engine ids.  The code has been enhanced via patches to internally cache v3 information by IP and engine id.  Previously the code would store the v3 information by engine id only, so when duplicate engine ids were used, the values returned could have been for either entry.  This was making it so users could not create the v3 model or if the model was created there may be Management Agent Lost Alarms.

 

 I have written the following tech doc that outlines the change and the solution.

 

https://support.ca.com/us/knowledge-base-articles.tec1760995.html

 

The fix is tentatively scheduled to be included in the next GA release of Spectrum as well.

 

Please let me know if you have any questions.
Thank you!

Jay

[Legacy User]

This now makes Spectrum non-compliant with RFC 3414.  The tech note indicates no SNMPv3 security is impacted, but how is this the case when the the snmpEngineID is required to be unique as an inherent part of the SNMPv3 security model.  I understand certain vendors are violating this, but doesn't this patch simply make the situation worse.  Maybe, an approach that lets the customer choose whether to enable this feature or not, either on a model basis or possibly globally, would be better.  We certainly prefer to see the Duplicate EngineID errors and address these as configuration issues.

[Jason Meader]

Hi Blaine,

 

The RFC states:

A non-authoritative SNMP engine must keep local notions of these 
values (snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime)
for each authoritative SNMP engine with which it wishes to
communicate. Since each authoritative SNMP engine is uniquely and
unambiguously identified by its value of snmpEngineID, the
non-authoritative SNMP engine may use this value as a key in order to
cache its local notions of these values.

As you noted, vendors are in violation of this. As Spectrum is the non authoritative SNMP engine, Spectrum isn’t in violation of the RFC as the RFC doesn’t state the non authoritative SNMP engine needs to maintain a unique engine id for the authoritative SNMP engine.

 

Spectrum still uses the engineid as a part of the key for the cache, but with the patch we also add the IP to the key. This allows Spectrum to uniquely identify the agent, even though there are duplicate engineIDs.

We have received so many cases from customers that are unable to model devices because of the same engineids and they are unable to change them for various reasons. We kept Spectrum within compliance of the RFC and now allow customers to be able to manage those devices appropriately.

 

I understand your concern about the alarms. The alarms were removed due to feedback by the customers that tested the solution for us.

 

Please let me know if you have any questions.
Thank you!
Jay

[Legacy User]

Hi Jay,

 

Thanks for the clarifications.

 

I understand the issues CA and the user base has faced with the duplicate EngineIDs.  I guess consideration for those users who would wish to still have the old functionality via a config setting would be appreciated.

[Jason Meader]

Understood…sorry it wasn’t designed that way.

 

While it’s not ideal, (especially if you have thousands of v3 devices on the same SS) you could run an all devices search and put the SNMP Engine ID column to show and put it in order of SNMP Engine ID.  Do a quick glance down through and check for duplicates.

 

Cheers

Jay