This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Trouble adding Cisco to NPM

I have a Cisco 2960S running SW Version 15.0(2)SE6 and I'm trying to add it to NPM using SNMPv3. Every time I edit the node properties and add the SNMP credentials it shows test failure. The configs I put into the switch are as follows (group, user and password changed):

snmp-server group SOLARGroup v3 auth access 98

snmp-server user SOLARUser SOLARGroup v3 auth sha SOLARPwrd priv aes 256 SOLARPwrd

snmp-server host X.X.X.X version 3 auth SOLARUser

Here is an image of how I'm putting the credentials into SolarWinds:

SolarWinds.jpg

SNMPv2 works however, we are required to use SNMPv3 due to our security baselines. I'm just wondering if anyone has had this issue before and if there is a solution. I'm not sure if I'm missing a config in the switch or something is wrong in solarwinds. Please, if anyone can assist with this issue it would be greatly appreciated.

  • Do these SNMPv3 credentials work via SNMPwalk from poller?  If not, are you seeing any log entries indicating an issue?

    Also, from my experience, valid credentials seemed never to work after the first click of the 'TEST' button.  I don't believe additional tests accomplish anything.  Seems I always had to navigate away from page and retry.  Can anyone confirm?

  • I use NCM and NPM to manage those same brand/model switches via snmp-v3 successfully, so you should be able to as well.  We retired all the 15.0 code due to security vulnerabilities or bugs; it's always possible you've got a Cisco bug that's preventing something from working correctly with your snmp-v3 deployment, and I'll assume you've investigated this (possibly with TAC?) and eliminated it as a possibility.

    I'd bet there's a typo somewhere, some difference between what your switches are configured to accept and what you've set your Orion product to use for them.

    Go through and compare them with a fine-toothed comb; if you find that tiny difference and correct it, you'll be all set.

    Also, for your security policy, seek advice about using snmp read-write strings.  NPM and NCM can do all the work I need for 47,000 devices without requiring snmp read-write privileges, and that helps reduce the exposure of not knowing who issued what command (via NPM or NCM) that may have made a change via snmp-v3 that ended up causing problems.  It's enough for those products to have read-only access--for my environment.

    Instead of using snmp-v3 read-write credentials to make changes to your switches and routers, you could leverage an Active Directory service account for NCM, and then let NCM manage those devices via SSH v2.  Better still, use TACACS and you'll have a complete history of who logged into the device, whether they had permission to issue a given command, what that command was, and when they did it.  AAA provides all that info, plus Orion tracks who told it to issue that command via the service account.

    If you have serious need to use snmp-v3 for read-write purposes, OK.  Just make sure you have great tracking on it, so you're not surprised unpleasantly when it's used to make configuration changes that might have negative results.

  • Fill in EITHER the read only credentials OR read/write.  Both are not required.

    Also as rschroeder​ mentions, reconsider using read/write.

  • As folks are pointing out, using both read and read/write can confound your troubleshooting efforts.  Get one working and determine what the issue was (remove the other from the credentials for the node).  Potentially same issue affecting the other.  They would both have to be right for the test button to pass.  I can see read/write being useful if you have Engineer's Toolset and the nature of your issue precludes SSH access.  It can be used to regain SSH access, or to make config changes that need to be made until SSH access is possible.  But perhaps not ideal for normal operations.