CA Spectrum SNMP Profile Management

Idea created by mcorvin on Aug 2, 2013
    Under review

    (Note: related ideas are: Add a SNMP v3 administration capabilities into oneClick, SNMP Profile settings show clear text password)



    Configuration and management of all SNMP profiles, especially SNMPv3, in CA Spectrum should be improved. We have found that it currently is manually intensive, requires duplicate entry, is difficult to audit/verify, and has no way to be automated.
    Hiding of the SNMP profiles also is inconsistent, with the 'community string' (e.g. "#v3/P:<authpassword>:<privpassword>/<userid>") in clear text on the Spectrum Modeling pane (when viewed as admin) while the passwords are hidden (and cannot be revealed for review) in the SNMP v3 profile editing UI, even as admin.
    In systems that have to managed dozens or hundreds of SNMP v3 profiles across multiple landscapes in a distributed architecture this will be an operational burden.  Some of the issues include:
    1) There is no way to bulk import/export SNMP profiles (e.g. via modelinggateway or web services).
    2) Profiles have to be entered for discovery/model creation via the profile UI, entering userid and passwords individually, and then re-entered,  using the 'community string' markup, in the VNM auto discovery area. The profile 'name' only applies to SNMPv3 profiles.
    3) The profile 'name' configured in the discovery SNMP profile UI is lost  when discovery creates a model (or when one creates a single model manually), and  that model then has a unique SNMP community string that is disconnected from  the 'named' profile.  Therefore, if a profile gets changed on modeled  devices, all the corresponding models have to be updated individually (or all  the devices have to be rediscovered - but that interrupts monitoring and  history).
    4) When importing discovery configurations via the modelinggateway the  'community string' must already exist as one of the 'named' profiles configured via the UI for v3 to work. The discovery configuration xml markup used with the modelinggateway export/import does not include the profile 'name', just the profile itself using the 'community string' markup.
    It would be a great improvement if SNMP profile management were consolidated and made consistent so that all SNMP operations reference, by name, a common set of named SNMP  profiles (database objects; models), for all versions of SNMP, and that these could be managed programmatically  (import/export/update), e.g., via CLI, modeling gateway or the web services interface.
    1) Bulk import/export/update of named SNMP profiles for all SNMP versions  using an extension of the current 'markup' in a text file and/or in an xml file format. (Currently, modelinggateway export appears to dump out the SNMP profile in encrypted form -?).
    2) SNMP Profile editor UI treats each SNMP version the same (v1, v2c, v3), as a named profile, and for v3 an admin user can show the passwords for review/debugging.
    3) Discovery configurations, single model creation, created models, and the autodiscovery configuration all use SNMP profile(s) specified by name referring to a profile (model) the defined SNMP profile database.
    4) Device models use the referenced SNMP profile rather than a disconnected 'community string'.  This way, if SNMP credentials get rolled (e.g., periodically per security requirements), updating the single, named profile updates all the models that use it.  If a model requires a unique SNMP profile, it is created as another full SNMP profile object in the database rather than a 'community string' text parameter on the model.
    As networks move to more widespread use of SNMPv3 and dynamic credential management for security purposes, such enhanced SNMP profile management would greatly ease the administrative overhead when using Spectrum.