If this is causing major stoppages or doesn't get resolved, open a support ticket to let support know.
When you open a support ticket, would you:
--Reference this thread to Support.
--Post back here with a case number.
--Post any solutions you get from Support.
Please check your discovery setting in "Network Sonar Discovery" page. You probably have a device setup to be discovered with invalid credentials.
As for the extra IP address contained in the trap varbinds, this is a Cisco proprietary varbind which basically tells you the address of the host from which snmp-agent has received a SNMP message that has failed to authenticate.
Did you find out what the issue was?
I have the exact same problem and the interesting part is the IP address reported!
cExtSnmpTargetAuthInetAddr = 22.214.171.124 <-- Same subnet
cExtSnmpTargetAuthInetType = 1
authAddr = 10.72.74.9 <-- not NPM IP
snmpTrapOID = SNMPv2-MIB:authenticationFailure
sysUpTime = 2567747435
Over here i'm receiving thousands of similar messages per day. Is this an attack?
I have been getting the same traps. Your post led me to the same conclusion that it started when UDT was installed.
Based on that I uninstalled UDT and the problem has been solved. See my note to SW tech support below.....
I just confirmed, without a doubt in my mind, that the cause of these authentication failures is the new User Device Tracker.
We were getting these traps consistently throughout our network every few seconds.
We uninstalled UDT, and voila, the authfailure traps ceased completely. A user’s post with similar symptoms on THWACK led us to uninstall UDT.
I have to say I am very dissatisfied with the product and the apparent “rush to market” before being vetted internally. It has caused me and others in my group many lost man hours.
This and the fact that SW tech support has not responded to my open case #273862 since 9/23/11 (last email exchange attached…also regarding a problem with UDT), leads me to be very wary of updates and new services from SW.
I'm sorry to hear about everyone's frustration here. There was a previous post where we discussed this issues with some work arounds.
Please see this post and let me know if that solves the problem or if you continue to have issues.
I can also say that this is caused by other SW products but I can say which. We are getting pounded by this problem and we have never installed UDT as a trial product on any boxes at all anywhere in the district.
Would really like to see SW evaluate the problem beyond the workarounds list in the link above. It doesn't apply to us because of never having installed UDT.
Extremely frustrating the amount of time we have spent on this problem to track it back to SW products. All of the open source NMS systems that poll our switches do not cause this problem.
If I need to open a trouble ticket then ok but this is something more fundamental than tweaking settings.
I do love SW products by the way. Just need to get SW to investigate.
Network engineer GISD
Unfortunately we are not able to reproduce this issue in our lab. These other cases were related to UDT so if you don't have that installed I would very much like to get additional information about what is going on in your environment.
What other open source monitoring tools are you using? It could be due to how we use SNMP. Each value has a unique snmp-get request. This is something that will be changed soon and if you are experiencing this problem, I recommend you upgrade to the latest NPM 10.2 RC to see if the problem goes away.
Either way, openening a case with support so we can determine the root cause would be very helpful.
Was there ever a resolution to this? We recently installed UDT as well and we are experiencing the same issue.
In UDT 2.0 we changed how we queried devices to make it more efficient. This should alleviate some of the issues where too many SNMP requests were being sent to the switches. I haven't recieved confirmation in the RC period whether this resolved this specific issue.
If anyone else in this thread is running the 2.0 RC, it would be great to get confirmation from the community if this is still happening or not.
I'm following up from an earlier post in this thread from me in regards to this problem not being unique to UDT. I haven't had time to open a formal ticket and more than willing during the next two following weeks to work with you on this problem during the school district shutdown period. We have this same problem and have never installed UDT in production boxes or as a trial installation. I think UDT just makes the problem more visible but I think this is an issue closer to core code than the UDT module.
I'm more than willing to webex you onto our SW servers and let you gather all of the data you need.
Sad to say, in 2019, running UDT 3.3.2, I am currently having the same issue described here.
cExtSnmpTargetAuthInetAddr = 126.96.36.199
The reason for this strange address is because your Solarwinds' poller's address begins with "10.7".
After examining the specification of 188.8.131.52.184.108.40.206.4220.127.116.11.0 (.iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoSnmpTargetExtMIB.ciscoSnmpTargetExtMIBObjects.cExtSnmpTargetAuthAddr.cExtSnmpTargetAuthInetAddr.0) OID in the Trap, it seems that Solarwinds’ Traps viewer is misinterpreting the value – its value (0x31302e37<redacted>) is a string, “10.7<redacted>", yet, Solarwinds is interpreting its as a Binary quad-tuple (0x31302e37), 18.104.22.168!!