CA Spectrum SNMP Profile Management

Idea created by mcorvin on Aug 2, 2013
    Not planned
    Score3
    • mcorvin
    • Hari.Saligommula
    • NCloutter
    CATEGORY:  CA Spectrum Device Based Suite

    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.
    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
    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.
    E.g.,
    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.
    2) SNMP Profile editor UI treats each SNMP version the same, 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.