Hi,
We are also using SolarWinds NPM, NCM, UDT, etc. We recently switched over to SNMPv3 as we were seeing a large number of SNMP Auth failures on our switch as well. We've run into a few things that can be causing these are we are still trying to find out what is causing them. If you're using SNMPv3 you need to configure a context on the SNMPv3 group for the user. UDT is trying to poll Layer 2 ad Layer 3 information and by default access to these MIBs are not allowed like they are in v2c. You can also disable VRF context polling if your switches do not support it, like our 2960 switches don't. This is done under the UDT polling settings when you edit a node in SolarWinds. Here's an example of what my SNMPv3 group config looks like with contexts for UDT:
snmp-server group GROUPNAME v3 priv access 98
snmp-server group GROUPNAME v3 priv context vlan- match prefix access 98
If you switches do not support the match prefix command you will need to add the vlans manually, like context vlan-150 and so one. We've run into this on some old 2950's we have, but we aren't going to worry about them. Once you've done this you can run the UDT Compatibility Checker on your Orion server our run the SolarWinds snmpwalk utility on your Orion server as well. Try to poll a VLAN configured on the switch by putting something like vlan-150 in the context box. It should be working correctly.
Another thing that we ran into was on all of our switches our SNMP local EngineID was the exact same, I'm not sure how this happened. But we just cleared that out and a new one automatically generated. When doing this you need to wipe out the SNMPv3 user and group and recreate them as the engineID is used when generating the hash value for authentication and encryption. You also need to clear out the credentials for the node in SolarWinds and re-enter them in. I think it saved these hash values in the DB for comparing as well on the SolarWinds side.
One other thing that could be going on could be related to your ACLs. From testing and from reading a blog post somewhere it seems that with just a basic ACL I can still generate SNMP Auth failures with a device that would be denied using SNMPv1 or v2c, even though I don't have any community strings configured anywhere. I'm also able to still generate SNMP Auth failures using a device that is permitted in the ACL, but using v1 or v2c to poll our switch. I'm not sure which comes first, but it seems that the ACL is checked after SNMP requests are processed? Here's an article on this: https://www.routerfreak.com/what-to-do-about-snmp-3-authfail-messages/
I need to actually test this out and I can't find the online resource that I read, but from what I remember you can solve this by using an ACL inbound on the interface that would receive SNMP requests to discard them, I think. You'd want to be careful with this as any SNMP traffic flowing through the switch destined for other switches could potentially be dropped, as well as other legitimate traffic too. I'm not sure how true this is since I can't locate the resource I read and have not tested it out.
The last thing you could do to stop these is just to disable logging of snmp auth failures and stop sending the traps if you'd like. I may just end up doing this since they're noisy and there's some devices in other departments that will auto discover devices on the network by using SNMP and these could generate these too.
