Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
We need to prevent any SNMP OID Classifications being added with a Net-SNMP module OID starting 1.3.6.1.4.1.8072.3.2. to avoid mis-Classification and wrong Model names - Known Error
  • >
  • Knowledge Base
  • >
  • Known Error (Knowledge Base)
  • >
  • We need to prevent any SNMP OID Classifications being added with a Net-SNMP module OID starting 1.3.6.1.4.1.8072.3.2. to avoid mis-Classification and wrong Model names
KB0751287

We need to prevent any SNMP OID Classifications being added with a Net-SNMP module OID starting 1.3.6.1.4.1.8072.3.2. to avoid mis-Classification and wrong Model names


10090 Views Last updated : May 8, 2025 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Description

We need to prevent any SNMP OID Classifications being added with a Net-SNMP module OID starting 1.3.6.1.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 1.3.6.1.4.1.8072.3.2.

1.3.6.1.4.1.8072.3.2.1 hpux9
1.3.6.1.4.1.8072.3.2.2 sunos4
1.3.6.1.4.1.8072.3.2.3 solaris
1.3.6.1.4.1.8072.3.2.4 osf
1.3.6.1.4.1.8072.3.2.5 ultrix
1.3.6.1.4.1.8072.3.2.6 hpux10
1.3.6.1.4.1.8072.3.2.7 netbsd
1.3.6.1.4.1.8072.3.2.8 freebsd
1.3.6.1.4.1.8072.3.2.9 irix
1.3.6.1.4.1.8072.3.2.10 linux
1.3.6.1.4.1.8072.3.2.11 bsdi
1.3.6.1.4.1.8072.3.2.12 openbsd
1.3.6.1.4.1.8072.3.2.13 win32
1.3.6.1.4.1.8072.3.2.14 hpux11
1.3.6.1.4.1.8072.3.2.15 aix
1.3.6.1.4.1.8072.3.2.16 macosx
1.3.6.1.4.1.8072.3.2.255 unknown

Devices known to use one of these OIDs, usually the linux one 1.3.6.1.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

  1. Add an OID 1.3.6.1.4.1.8072.3.2.10 for "Intermec PM43" Printer, for Printer Classifier, and Printer class
  2. Discover a Aruba Network, CP-HW-5K IP Router, which also uses this OID
  3. A Printer CI will be created

Workaround

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

Potentially Seen In

There is no data to report.

Fixed In

New York Patch 9
Orlando Patch 3
Paris

The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.