We need to prevent any SNMP OID Classifications being added with a Net-SNMP module OID starting 188.8.131.52.4.1.8072.3.2. to avoid mis-Classification and wrong Model names
Those OIDs belong to the free Net-SNMP Module (http://www.net-snmp.org/), which is used to implement SNMP in many networked devices, however sometimes manufacturers fail to replace the default template System OID with their own specific to the Manufacturer's Model.
If an OID record has been entered with one of these - e.g. a specific Printer - and another device is scanned - e.g. a Router - then that router CI will end up in the Printer table. That record will always override the automatic classification, and make/model code.
The following OIDs need to be blocked from being entered in the OID table in the instance. They all start 184.108.40.206.4.1.8072.3.2.
Devices known to use one of these OIDs, usually the linux one 220.127.116.11.4.1.8072.3.2.10, include:
- Riverbed Technology, SteelCentral Flow Gateway/User Interface Module
- Aruba Network, CP-HW-5K IP Router
- Dell, iDRAC7 Remote Access Controller / Out-of-band SNMP Agent for Remote Access
- ExtraHop, Discover 8100
- Intermec, PM43 Printer
- IBM, ISAM Server
- Barracuda, SPAM Firewall
- Brocade, Virtual Traffic Manager
- Check Point Smart-1 3050 Firewall
- Blue Coat DLP2700
- SourceFire Intrusion Detection
- RSA Token Server
- Netgear ReadyNAS
- A10 Load Balancers
- McAfee Email Gateway
- Peplink Balance
- Sophos UTM Firewall
Steps to Reproduce
- Add an OID 18.104.22.168.4.1.8072.3.2.10 for "Intermec PM43" Printer, for Printer Classifier, and Printer class
- Discover a Aruba Network, CP-HW-5K IP Router, which also uses this OID
- A Printer CI will be created
This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this form to be notified when more information will become available.
There is no way to use these OIDs for Classification, as they are not unique. If experiencing this issue, then the solution is to delete the OID record so that it isn't used, and so can't cause problems with mis-classification or assigning the wrong Model. The friendly model name entered in the OID record will then not be used.
SNMP with then have to fall back to other sources of data to classify the device and set Model information, which should still work if the SNMP implementation is fairly standard. If those model names generated by that process need to use the friendly model name that had been in the OID record, then Field Normalization could be used to update/normalize those model names instead.
If the device still cannot be classified, then a new SNMP Classification can be created that checks for data that will be there for this specific device, such as a string in sysDesc.
Related Problem: PRB1349444