Prime Infrastructure 3.1 snmpv3 issues

[bryantsteve]

In the device rediscovery process I'm experiencing inconsistent snmp collection results.  At one time or another
22 devices (3750,3850,4500 switches and 2900 and ASR1001 routers) have been successfully discovered/rediscovered by the PI,
only to later fail snmp collection with no changes in the PI snmp discovery settings
or device configuration, (with ping and CLI/SSH being successful)
 
Here is a representative sample of the device configuration  

snmp-server engineID local 123456789012
snmp-server group campusgroup v3 auth read campusview access 1
snmp-server view campusgroup system included
snmp-server view campusgroup interfaces included
snmp-server trap-source Vlan22
snmp-server enable traps license
!
snmp-server user snmp campusgroup v3 auth sha password1234 priv aes 128 pasword5678 access 1
!
access-list 1 permit 192.168.1.0 0.0.0.255

The PI is configured with a credential profile having  the snmp user name privauth passphrase  and
target is the device subnet 192.168.1.*

Sometimes snmp collection works, sometimes it doesn't, I've deconfigured/ reconfigured snmp on routers,switches, and the PI many time over

Any ideas/suggestions would be greatly appreciated

[terence.frankland]

I thought we had that problem too, but found that someone had put snmp-server engineID local statically in the config and used the same one on multiple devices instead of letting the device to it automatically off the OID and mac of the first interface. I removed that line from the config and put the snmp user in again and it worked. PI was seeing the same engine ID for multiple devices, that is why at one time it would pass snmp and another say it could not talk to it with SNMP.

[didierdebrouwer]

Hi Terence;

This was exactly the issue for inconsistent SNMP connectivity from PRIME. Resolved by running "no snmp-server engineID local" on the polled devices.

Thanks!

[terence.frankland]

Cheers!

[jaa3rd]

I am experiencing a similar issue on PI 3.3

I have added multiple Catalyst 9300's and they all verify snmpv3 correctly, but will lose snmp reachability within 10 mins.

I can bulk select or individually select all units and verify credentials and reachability is restored upon resync. (Then will drop again soon thereafter)

I have a 5520 WLC with snmpv3 that does not experience this issue, which makes me think there's an issue with the 9300 configs.  I verified that the snmp engineID are not set statically on all the switches, and are all different.

Note: This is a brand new installation of PI, and was updated to 3.3 before any inventory was added.  Also, devices on snmpv2c do not have this issue.

Edit:  This seems to be occurring with aes-192 encryption, and not aes-128

Any suggestions?

[muath1987]

I have the same issue exactly, may i know if you are able to resolve it ?

[jaa3rd]

I haven't found a solution.  I ended up just throwing all the affected devices on aes-128 since that seems to work properly.

[muath1987]

Thanks dear, I opened TAC case and they are still working on it.

[rune.jon]

Cisco Prime 3.3 only support AES-128, not AES-192. 

[llewesc11]

See the following Cisco bug (CSCvi21956):

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvi21956/

[llewesc11]

This has been fixed in 3.4:

https://software.cisco.com/download/release.html?mdfid=286317405&catid=268439477&softwareid=284272932&release=3.4.0&relind=AVAILABLE&rellifecycle=&reltype=latest

[Emre Ozel]

Hi all, 
Switch side;

Switch(config)#snmp-server group ( group name ) v3 priv
Switch(config)#snmp-server user (username) ( group name ) v3 aut md5 (password) priv aes 128 (password)

Cisco Prime Side:

[halilmollaoglu]

i was struggling with this for hours, thanks for the info!