SNMP V3 ISSUE

When I build this out, I usually follow a a sequence of setting up the source interfaces if needed, creating the group, then building the user within the group and lastly setting the host. That does not always make a difference, but for some devices in my past; it made all the difference.

Check your setup with show snmp group & show snmp user - ,make sure the group is setup how you want and that the user is in the group.

The only thing I hang up on here is your Server Host Line;

snmp-server host <SW Server IP> version 3 priv <SNMPUserName>

If the user is not aligning to the group, blow it out and rebuild.

- you should only need to X the User, Group and Host; Traps Enable and source interfaces and views can be left alone for this process.

-CharlesH

Loop1 Systems: SolarWinds Training and Professional Services

• LinkedIN: Loop1 Systems
• Facebook: Loop1 Systems
• Twitter: @Loop1Systems

what do you mean by after some time ? Whats the time gap or time difference in your scenario.

Zabs, This is basically the same thing cahunt said, but with a little bit more detail.  We put use access-lists to limit the systems that can communicate to our networking equipment and my example reflects that.  Simply drop off the access-list information if it's not relevant. Also my example shows SHA/AES 128, simply swap those for your environment.  This configuration will grant Solarwinds Read/Write access so when you load them into Solarwinds be sure to enter the credentials twice, once in the SNMPv3 cred section and again in the Read/Write cred section

     access-list 20 remark Solarwinds

     access-list 20 permit 172.92.163.0 0.0.0.255

     access-list 20 deny   any log

     !

     snmp-server view <VIEWNAME> iso included

     snmp-server group <GROUPNAME> V3 priv write <VIEWNAME> access 20

     snmp-server user <USERNAME> <GROUPNAME> v3 auth SHA <PASSWORD> priv AES 128 <PASSCODE> access 20

     snmp-server host <IP ADDRESS> version 3 auth <USERNAME>

     snmp-server group <GROUPNAME> v3 auth context vlan- match prefix access 20

     snmp-server group <GROUPNAME> v3 priv context vlan- match prefix access 20

     snmp-server trap-source <MANAGED INTERFACE LOOPBACK OR VLAN>

Cahut mentioned testing, this shows what to look for. If you have problems loading a device into SW always do a "sh snmp user" and a "sh snmp group" for troubleshooting it'll show you if something is missing and it will same you lots of stress.

     #sh snmp user

     User name: <USERNAME>                                                                      

     Engine ID: xxxxxxxxxxxxxxxxxxxxxxxx                                                    

     storage-type: nonvolatile        active access-list: 20                                 

     Authentication Protocol: SHA                                                            

     Privacy Protocol: AES128                                                                

     Group-name: <GROUPNAME>

     #sh snmp group

     groupname: <GROUPNAME>                       security model:v3 auth                                        

     contextname: <no context specified>            storage-type: nonvolatile  

     readview : v1default                                       writeview: <no writeview specified>

     notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.F

     row status: active                                                                                                                                                                                                             

     groupname: <GROUPNAME>                       security model:v3 priv

     contextname: <no context specified>            storage-type: nonvolatile

     readview : v1default                                       writeview: <VIEWNAME>

     notifyview: <no notifyview specified> 

     row status: active      access-list: 20                                                                                                                                                                                                                                    

     groupname: <GROUPNAME>                     security model:v3 auth

     contextname: vlan-                                       storage-type: nonvolatile

     readview : v1default                                     writeview: <no writeview specified>

     notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.F

     row status: active      access-list: 20                                                                                                                                                                                                                                  

     groupname: <GROUPNAME>                      security model:v3 priv

     contextname: vlan-                                        storage-type: nonvolatile

     readview : v1default                                      writeview: <VIEWNAME>

     notifyview: <no notifyview specified>   

     row status: active      access-list: 20

Hi bourlis - I used your config above and switched the variables, however when I populate the context: field when adding a node it fails but if I remove the context field's value in this case 'vlan-' it then starts to work?!!

I have gotten this working without specifying a context but I believe it is necessary to have a context defined for MIB walks to complete, so I am trying to achieve having a context defined. Any ideas here? Am I using the wrong name for the context configured? What is your understanding of a context anyway,is it related to the SNMP view? bourlis​

Specifying the context causes it to fail

Removing the context field data allows it to succeed

Any help appreciated!

I will also add that whilst playing around with this I changed the engineID, could this have an effect? This config was already in place before my testing that was fail/success depending on whether I had the context added to the add node fileds so I doubt it has any bearing

User name: SWUser

Engine ID: 1111111111

storage-type: nonvolatile        active access-list: 1

Authentication Protocol: SHA

Privacy Protocol: AES128

Group-name: SWReadGroup

Noobs, correct when discovering you don't have to enter the VLAN- context.

When we first migrated over to SNMPv3 we were having issues with topology mapping and Cisco support said to enter the "v3 auth context vlan- match prefix & v3 priv context vlan- match prefix" commands.  They said that "vlan-" was a wild card used for topology mapping.  Once we entered that command into our setting and rediscovered our devices we instantly saw topology information in our tools. 

Now, in all honestly, that was with an older Cisco IOS version and with a different network management software and it may or may not be needed with Solarwinds.  It's part of our standard configuration and no one has bothered to remove it and to test if those commands are still needed or not.

You are 100% correct, don't use the "vlan-" in the context field, it's not needed for discovery.

I would highly suggest not changing the SNMP Engine ID.  In my experience every SNMP Engine ID has to be 100% unique.