Discovery Issue: SNMP - Classify: 0 OIDs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-10-2014 08:57 AM
Greetings !!
An interesting discovery issue has arisen in Dublin that i have not seen before. As we discover a particular router device, we achieve authentication via SNMP community string without a problem, but the OID information returned for classification is...zero OIDs !
Some facts to note:
- Device is a Cisco 2911 (1.3.6.1.4.1.9.1.1045)
- OID has been added to SNMP OID's and appears on the classifier appropriately
- Device can be walked using MobaXTerm using a particular community string
- Credential settings in ServiceNow have the community string being used before all others (order = 2; all others 90+)
- The fact that i get "SNMP - Classify: 0 OIDs" in the ECC queue tells me that i am at least authenticating...
The (continued) result:
Could this be a problem with SNMP v2 vs. SNMP v3?
Will a Eureka upgrade resolve this? (we are upgrading soon)...
Thanks guys !
John
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-10-2014 09:20 AM
The only thing i can think of to resolve the issue is to add the SNMP mid files for Cisco 2911. If you go that route please try first on sandbox or DEV. (See the link below or you can see in community how to add the SNMP mibs).
Thanks, Faisal Dadabhoy

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-10-2014 01:47 PM
I hope you are using v2c as currently v3 is not supported.
Did you happen to scan the port? Try nmap and check the state of the port. If filtered, try to remove the filter and run discovery again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-29-2014 01:48 PM
RESOLVED:
The issue was with firewall rules where SNMP return traffic was not properly mapped for all devices for all mid-servers. We were trying to discover the devices from mid servers that did not have the correct routes.
To resolve we:
Workaround: moved devices to functional mid servers
Root Cause Resolution: modified routing rules for all mid servers across all firewalls for consistency.
Cheers !
John Duchock
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2024 04:51 AM
Hi John,
Could you give a little insight on how to modify routing rules on mid servers? I am facing similar issue.