Discovery SNMPv3 Error "Message processing model 3 returned error: Unknown security name"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2019 12:27 PM
Weird issue happening when trying to discover a network device using a schedule. The schedule has no behaviors and no other restrictions. Both the schedule and quick discovery are using the same MID server.
- We have a schedule of 118 IP address, many of which have a result of “Active, couldn’t classify”
- This is typically not an issue and can be resolved fairly easily
- When I narrow the focus to 1 IP, a small subset of the SNMP OIDs are returned 9 (sometimes 0) out of about 7270
- The error that is returned in the discovery log is “Message processing model 3 returned error: Unknown security name”
- Doing a quick discovery on 1 IP has a successful discovery and a CI is created/updated
- Looking at the SNMP OIDs, about 7270 are returned
- No errors in log
I have re-created the scheduled with the same result. When doing a scheduled scan it doesn’t classify, but when doing a quick discovery it discovers just fine. Any help on this would be greatly appreciated.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2019 12:33 PM
Not sure about the SNMPv3 message but if you are getting 0 OID's returned then I would suggest extending your MID Server's mid.snmp.request.timeout and mid.snmp.session.timeout values as they are timing out before you get all the responses back. Try starting at 6000 and 2000 respectively.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2019 12:38 PM
Wouldn't I see the same behavior when doing quick discovery?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2019 12:43 PM
Typically, but I was wondering if it could be behaving a little differently due to the schedule "load", while the Quick Discovery is running faster.
My recent findings while testing out Eaton UPS discovery has shown that a 0 OID return is usually a timeout; or an issue with the SNMP community password not being correct (v1/v2). I haven't done anything with v3 at this time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-15-2019 12:59 PM
Changing the parameters seem to have a better result, but still getting having the same issue. I am going to try to increase a bit more and see what happens.
