13 Replies Latest reply on Nov 12, 2019 1:13 AM by alexferen

    SNMP v2 Authentication Failure


      I have installed UDT eval - looks VERY interesting so far; experiencing a couple of router issues and such that other folks are commenting on and have an open case.

      One odd thing I have noticed that started virtually the minute UDT became active is SNMP authentication failures - we capture these in NPM via traps.  What is interesting is that they appear to be coming from my orion server and attempt to communicate via SNMP to any device in the network; whether or not they are in UDT (they are in NPM).  Even more interesting is the extra IP address contained in the trap - see bold below:

      snmpTrapEnterprise = RAPID-CITY-MIB:snmpTraps 
      experimental.1057.1 = [*local switch address*]
      cExtSnmpTargetAuthInetAddr = 
      cExtSnmpTargetAuthInetType = 1 
      authAddr = [*local Orion server address*] 
      snmpTrapOID = SNMPv2-MIB:authenticationFailure 
      sysUpTime = 3618379348 

      Has anyone else seen this or know what it could be coming from?  Again, this started immediately after UDT was installed.



        • Re: SNMP v2 Authentication Failure


          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.

          Many thx,


          • Re: SNMP v2 Authentication Failure



            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.





            • Re: SNMP v2 Authentication Failure

              Hello Dave,

              Did you find out what the issue was?


              I have the exact same problem and the interesting part is the IP address reported!

              cExtSnmpTargetAuthInetAddr = <-- Same subnet
              cExtSnmpTargetAuthInetType = 1 
              authAddr = <-- not NPM IP
              snmpTrapOID = SNMPv2-MIB:authenticationFailure 
              sysUpTime = 2567747435


              Over here i'm receiving thousands of similar messages per day. Is this an attack?





              • Re: SNMP v2 Authentication Failure

                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.




                  • Re: SNMP v2 Authentication Failure

                    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.

                    SNMP Queue Failures



                      • Re: SNMP v2 Authentication Failure

                        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.

                        Brian Sullivan

                        Network engineer GISD

                          • Re: SNMP v2 Authentication Failure


                            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.


                      • Re: SNMP v2 Authentication Failure

                        cExtSnmpTargetAuthInetAddr =


                        The reason for this strange address is because your Solarwinds' poller's address begins with "10.7".


                        After examining the specification of (.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),!!