cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 7

my nexus core switches are not communicating witn SNMP

snmp-server user is configured correctly with authentication and privacy and still snmp is failing - no ACL blocking. The switch and the solarwinds server can ping each other. Anybody has any idea what this could be? Thanks for your help!

0 Kudos
5 Replies
Level 9

@jaguemon 

 

I posted a long list of possibilities, but it disappeared twice. Instead of re-posting those possible issues, can we narrow down the issue some more.
1. Are you familiar with setting up a NX-OS for SNMP communications, if not, I'll post all the config settings needed for current NX-OS.

2. Is it actually saying it failed, or does it just spin and spin trying to find resources, if spinning, its a bug, I think my post kept getting deleted as I posted their fix for it, basically dll's need to be recopied.

3. Is your NX-OS old, and are you using AAA; if old you may need to ensure that the AAA server is sending the correct responce, some old NX-OS want to see roles = Network-Operator or similar instead of Priv 15.

Let us know.

0 Kudos

The issue is now resolved. I removed the read/write SNMPv3 credentials and kept only SNMPv3 credentials and it worked. Thanks to ALL for your assistance.

Respectfully!

0 Kudos
Level 9

@jaguemon 

Several issues come to mind since the statement seems a little broad to me, so tried to address 3 possible issues.

------------------------------------------------------------------

1. Are you familiar with the settings for Nexus compared to Cisco?
Depending on your NX-OS Versions the commands below can be different, here is an obfuscated version of mine.

snmp-server user MYSNMPRO network-operator auth sha 0xHASH_REMOVED priv aes-128 0xHASH_REMOVED localizedkey
snmp-server user MYSNMPRW network-admin auth sha 0xHASH_REMOVED priv aes-128 0xHASH_REMOVED localizedkey
snmp-server user MYSNMPRO use-ipv4acl SNMP
snmp-server user MYSNMPRW use-ipv4acl SNMP

snmp-server host 10.x.x.x traps version 3 priv MYSNMPRO
snmp-server host 10.x.x.x traps version 3 priv MYSNMPRO


tacacs-server host x.x.x.x key 7 "KEYREMOVED"

aaa group server tacacs+ ClearPass
server 10.x.x.x

ip access-list SNMP
10 permit ip 10.x.x.x/32 any log
20 permit ip 10.x.x.x/32 any log

I'm using the Mgmt/OoBM interface, if you are using an VLAN/SVI or L3 interface you will not need these.
And since you said you can ping, you have a route so assume the below is not needed

vrf context management
ip route 0.0.0.0/0 10.x.x.x
snmp-server source-interface traps mgmt0

------------------------------------------------------------------

2. Could be the way you have AAA setup or the AAA server.
Ensure the AAA server sends the correct response level, older NXOS devices didn't understand a AAA response of Priv 15, and required Network-Admin, or Network-Operator, newer NXOS I think support both.

------------------------------------------------------------------

3. Is it actually saying incorrect credentials, or does it just spin and spin looking for resources, if the latter its a bug. Fix is below:


Stop all Orion Services on the main server or the affected AWS.
Copy the files from the path below:
Root Folder C:\Program Files (x86)\SolarWinds\Orion\VDC
SolarWinds.Orion.DeviceContext.Strings.dll 8.1.0.135

Root Folder C:\Program Files (x86)\SolarWinds\Orion\VDC\de
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135

Root Folder C:\Program Files (x86)\SolarWinds\Orion\VDC\ja
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135


Paste the files to Inetpub/Solarwinds folder:
Root Folder C:\InetPub\SolarWinds\bin\
SolarWinds.Orion.DeviceContext.Strings.dll 8.1.0.135

Root Folder C:\InetPub\SolarWinds\bin\de
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135

Root Folder C:\InetPub\SolarWinds\bin\ja
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135
Open command prompt (Run as Admin) then perform IISreset
Start all the Solarwinds services.

 

Hope this helps.

0 Kudos
Level 9

@jaguemon 

If it just spins and spins without saying the credentials are incorrect, it's a bug we have had to correct twice putting in a ticket with SolarWinds, only impacted our Cisco Nexus devices.

- To solve this error message we followed this steps:

Stop all Orion Services on the main server or the affected AWS.
Copy the files from the path below:
Root Folder C:\Program Files (x86)\SolarWinds\Orion\VDC
SolarWinds.Orion.DeviceContext.Strings.dll 8.1.0.135

Root Folder C:\Program Files (x86)\SolarWinds\Orion\VDC\de
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135

Root Folder C:\Program Files (x86)\SolarWinds\Orion\VDC\ja
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135


Paste the files to Inetpub/Solarwinds folder:
Root Folder C:\InetPub\SolarWinds\bin\
SolarWinds.Orion.DeviceContext.Strings.dll 8.1.0.135

Root Folder C:\InetPub\SolarWinds\bin\de
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135

Root Folder C:\InetPub\SolarWinds\bin\ja
SolarWinds.Orion.DeviceContext.Strings.resources.dll 8.1.0.135
Open command prompt (Run as Admin) then perform IISreset
Start all the Solarwinds services.

0 Kudos
Level 10

Hi @jaguemon,

 

Try the credentials with the SNMP Walk tool.  If you’re receiving an SNMP error “Unknown user name”, but you’re certain that the username is correct, the other aspects that may be causing it are:

  • SNMP Permitted Managers
    This aspect is like an ACL.  It indicates which managers the agent will reply to.
  • VACM
    This aspect configures the OIDs that the managers may request.

I’m not a Nexus guy, so I’m not fluent in configuration on those types of systems.

 

Beyond SNMP walk you could also decrypt the traffic in Wireshark.  If you set up a capture filter for the one node you’re testing from the polling engine you’re attempting to add the node to, or run the walk from, you can also add the SNMP credentials in Wireshark and look at the responses to get an idea of the cause of the error.

 

Plain text responses on auth errors are:

  • 1.3.6.1.6.3.15.1.1.3.0, value = unknown username (or the above issues related)
  • 1.3.6.1.6.3.15.1.1.5.0, value = 18: wrong authentication password
  • 1.3.6.1.6.3.15.1.1.5.0, value = 18: wrong authentication protocol

 

If the packet returns encrypted but Wireshark couldn’t decrypt it, then there is a problem with the Privacy (aka Encryption) protocol or password.

0 Kudos