I am opening another support case on this, but figured I'd throw this out to see if others have seen it.
I recently noticed a lot of “authenticationfailed” SNMP traps from SNMP managed devices. I have tracked most of them to Orion main poller or APEs querying Cisco devices. The reason the device sends the authenticationfailed trap is due to Orion using an incorrect community string. This community string is partially correct, but has extra characters tacked on the end. I find “@1004” or similar strings at the end of the correct string, but it seems to vary. I believe this to be UDT related because the authentication issues occur at the same time interval as the Layer 2 jobs in UDT. They initially occurred at 35 minute intervals which matched my UDT Layer 2 jobs, so I changed them all to 40 minutes, and now I am seeing these issues at 40 minute intervals.
The SNMP requests are always for the same OID 1.3.6.1.2.1.17.1.4. Sometimes they are get-next, and sometimes get-bulk requests. An example packet is below. GOOD is the correct community string that Orion uses without issue on the devices most of the time. Of course, the queried device never responds to the request since the community string is wrong, and just sends an authentication trap to the trap server.
Anyone seen anything like this?
“Frame 296: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) on interface \Device\NPF_{67AC6121-B826-445E-9948-2DDDE738AF48}, id 0
Ethernet II, Src: VMware_bd:6e:c4 (00:50:56:12:23:34), Dst: All-HSRP-routers_00 (00:00:0c:07:ac:00)
Internet Protocol Version 4, Src: 10.10.10.10, Dst: 10.215.10.215
User Datagram Protocol, Src Port: 58648, Dst Port: 161
Simple Network Management Protocol
version: v2c (1)
community: GOOD@1002
data: get-next-request (1)
get-next-request
request-id: 58853
error-status: noError (0)
error-index: 0
variable-bindings: 1 item
1.3.6.1.2.1.17.1.4: Value (Null)
Object Name: 1.3.6.1.2.1.17.1.4 (iso.3.6.1.2.1.17.1.4)
Value (Null)