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 01:32 PM
Doesn't seem to have any effect after increasing the value.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-16-2019 04:36 AM
I know you said there was no errors in the log, but was there a "details" entry under Issues in the Devices tab?
Also, there should have been some sort of entry in the Discovery Log tab of the Discovery Status record.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-14-2019 11:34 AM
Did you ever figure this out? I'm getting the same error even though the payload XML says I have OID's (SNMP - Classify: 12 OIDs). Oddly enough, I am getting "Active, couldn't classify", but the SnmpObjectId is correct and it is in the SNMP OID Classifications table used within the Standard Network Switch classifier.
Any pointers here would be super helpful. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-14-2019 11:41 AM
We did not fully figure it out. The client was doing several hundred network devices at one time. Fix was to split them into several schedules, but in reality this was not how the client would end up running schedules.
Are you running scans on just network devices? If so, how many?
It was definitely strange, they only thing I could think of would be QoS on the network and discovery timing out.
However, the client is now running larger scans by subnet and we haven't seen any issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-14-2019 12:54 PM
We're just running discovery on network devices in the schedule that had this error come up, and there were only 60 active IP's.
I did rerun discovery a short time ago, and this time it was successful. Very odd for sure. It does seem like QoS, or just a timeout of some kind. I have been adjusting the following parameters, and that does seem to help, but in my case a few minutes ago, I didn't make any changes to these: (values are set quite high from the defaults)
mid.snmp.session.timeout
mid.snmp.request.timeout
mid.sa.snmp.walk_timeout_sec (see pattern failure message below regarding this one)
mid.sa.snmp.table_size_limit
"FAILED", "message" : "Identification sections in pattern failed: section: discovery, error: SNMP table query failed on host x.xx.x.x. SNMP walk timeout expired. Operation aborted. Row count: 320. "
I'm running another schedule right now on a different range, so we'll see how that turns out over the next few hours.
Thanks for the quick reply BTW, especially on a weekend!