When working with SNMP discovery in ServiceNow, the goal is simple: ensure the MID Server can ask a network device the right questions and understand the answers it receives.

In an ideal world, every device would respond using well-known, standard SNMP values. In reality, network devices, appliances, printers, switches, firewalls, UPS devices, and vendor-specific hardware often expose their useful information through proprietary OIDs.

This is where OIDs and MIBs come in.

This article walks through what OIDs are, what MIBs are, why they matter to ServiceNow Discovery, and how to add MIB files so they can be used by a MID Server.

The Scenario

I am working with SNMP-enabled infrastructure that needs to be discovered or queried by ServiceNow through a MID Server.

The MID Server can reach the device, the SNMP credentials are correct, and basic SNMP polling works. However, some of the useful device data is exposed through vendor-specific SNMP objects.

To solve this, I need a way for ServiceNow and the MID Server to:

1. Identify the correct SNMP Object Identifiers for the device.
2. Understand what those OIDs represent.
3. Load any required vendor MIB files.
4. Use those definitions during SNMP discovery or custom SNMP queries.

Once this is configured properly, SNMP discovery becomes far easier to troubleshoot and extend.

What is an OID?

An Object Identifier, usually shortened to OID, is a numeric address used by SNMP to identify a specific value on a device.

Think of it as the exact path to a piece of information.

For example, an OID might represent:

• Device name
• Device description
• Serial number
• Interface status
• CPU usage
• Memory usage
• Fan status
• Power supply status
• Vendor-specific hardware information

An OID is normally written as a dotted numeric string, such as:

1.3.6.1.2.1.1.1

This OID is commonly associated with sysDescr, which returns a description of the SNMP-enabled device.

On its own, the numeric OID works, but it is not especially friendly to read. That is where MIBs help.

What is a MIB?

A Management Information Base, usually shortened to MIB, is a definition file that explains what SNMP OIDs mean.

In simple terms, a MIB is the dictionary that translates numeric OIDs into readable names.

For example:

1.3.6.1.2.1.1.1 = sysDescr

Instead of only seeing a long numeric path, the MIB allows tools and platforms to understand the friendly object name, structure, and meaning behind the value.

So the relationship is straightforward:

• OID: The numeric address of a value on an SNMP device.
• MIB: The file that describes and names those OIDs.

Why This Matters in ServiceNow

ServiceNow Discovery uses the MID Server to communicate with infrastructure inside the network. For SNMP-based devices, the MID Server sends SNMP requests and processes the responses.

ServiceNow already includes many common MIB definitions. For standard network discovery, this is often enough.

However, vendor-specific devices often expose important data through their own private OID trees. Without the correct MIB files, you may still be able to query a numeric OID directly, but ServiceNow may not understand the friendly name or structure associated with that object.

This can become important when working with:

• Network switches and routers
• Firewalls
• Load balancers
• UPS devices
• Printers
• Storage appliances
• Environmental monitoring hardware
• Vendor-specific SNMP patterns or probes

Adding the correct MIB files gives the MID Server the definitions it needs to interpret vendor-specific SNMP data more effectively.

When Would You Add a MIB?

You normally add a MIB file when the out-of-the-box definitions are not enough.

Common examples include:

• A device is not classifying correctly during Discovery.
• A custom SNMP pattern needs to query a vendor-specific OID.
• A third-party SNMP walk tool can see the data, but ServiceNow cannot resolve the object name.
• The vendor has supplied MIB files for the hardware being discovered.
• The required OID sits under a private enterprise branch.

In my experience, the important part is not just getting the right MIB, but also getting any dependent MIBs that it imports.

Vendor MIB files often rely on other MIB files. Loading only one file from a vendor bundle can result in missing dependency errors.

Before You Start

Before uploading anything into ServiceNow, it is worth confirming the basics.

1. SNMP is enabled on the target device.
2. The correct SNMP version is being used.
3. The community string or SNMPv3 credentials are valid.
4. The MID Server can reach the target device on UDP 161.
5. The device responds to an SNMP walk from the MID Server host.
6. The required MIB is not already available in ServiceNow.
7. Any dependent MIB files are available.

This avoids chasing a MIB problem when the real issue is network access, credentials, or SNMP configuration on the device.

Adding a MIB File for MID Server Use

The process for adding MIB files is managed from the ServiceNow instance, not by manually copying files onto the MID Server filesystem.

The records are managed in the MID Server MIB File table, which is exposed through the SNMP MIBs module.

Step 1: Get the MIB Files from the Vendor

Start by downloading the MIB files from the device vendor.

Where possible, download the full MIB bundle for the device family or software version. This is usually safer than downloading a single file, because the main MIB may import definitions from other files in the same bundle.

Step 2: Review the MIB Dependencies

Open the MIB file in a text editor and look for an IMPORTS section.

This section tells you whether the MIB depends on other MIB files.

For example, a vendor MIB may import definitions from standard MIBs or other vendor-specific files. If those dependencies are missing, the MIB may not load or resolve correctly.

Step 3: Navigate to the SNMP MIBs Module

In ServiceNow, use the application navigator to go to:

MID Server > SNMP MIBs

This opens the list of MIB files available to MID Servers.

Step 4: Create a New MIB Record

Select New and create a new SNMP MIB record.

Attach the MIB file to the record and save it.

The MIB is stored in the MID Server MIB File [ecc_agent_mib] table.

Step 5: Upload Any Dependent MIBs

If the MIB has dependencies, upload those as well.

This is a common gotcha. The main vendor MIB may look correct, but if it imports definitions from another file that is missing, the MID Server may not be able to use it properly.

Step 6: Check File Extension Behaviour

ServiceNow notes that MIB files are stored without a file extension after they are loaded.

If your instance restricts attachment file types using the glide.attachment.extensions system property, you may need to ensure that the MIB file extension is allowed before upload.

Once loaded, ServiceNow handles the file appropriately for use by the MID Server.

Step 7: Restart the MID Server if Needed

If the new MIB definitions are not picked up immediately, restart the relevant MID Server service.

This helps ensure the MID Server reloads the latest MIB definitions from the instance.

Validating the Setup

Once the MIB has been added, test the result.

A good validation path is:

1. Run an SNMP walk from the MID Server host.
2. Confirm the target device responds.
3. Check that the expected OID returns a value.
4. Run Discovery again.
5. Review the Discovery log and MID Server log.

For example, a basic test against the standard device description OID would use:

1.3.6.1.2.1.1.1

If this does not return from the MID Server host, the issue is unlikely to be the MIB file. Start with connectivity, firewall rules, SNMP configuration, or credentials.

Common Issues

The MIB Does Not Load

Check whether the file extension is allowed by the instance. Also confirm that the file is a valid MIB file and not a compressed archive, HTML download page, or vendor documentation file.

The OID Still Is Not Recognised

Confirm that all dependent MIBs have been uploaded. Also check that the OID actually exists in the MIB file and is supported by the target device.

The Device Responds in an SNMP Tool but Not in ServiceNow

Test from the MID Server host, not from your local machine. If the test works locally but fails from the MID Server, the problem is likely network path, routing, firewall, or ACL related.

Discovery Still Does Not Classify the Device

MIB files help ServiceNow understand OID definitions, but they do not automatically guarantee classification. Check the relevant SNMP classifier, pattern, probe, and returned OID values.

Best Practice

Treat MIB files as part of your Discovery configuration, not as random uploads.

• Keep a record of the vendor and device model the MIB relates to.
• Upload the full dependency set where required.
• Test SNMP from the MID Server host before changing Discovery logic.
• Avoid uploading duplicate or unnecessary MIB files.
• Restart the MID Server if new MIB definitions are not recognised.
• Document any custom OIDs used by probes, patterns, or identification logic.

The Takeaway

OIDs are the numeric paths SNMP uses to retrieve values from a device. MIBs are the dictionaries that explain what those paths mean.

For standard devices, ServiceNow will often have enough MIB information already available. For vendor-specific hardware, adding the correct MIB files can make SNMP discovery easier to understand, extend, and troubleshoot.

The important thing is to validate the full chain:

1. The device exposes the OID.
2. The MID Server can reach the device.
3. The SNMP credentials work.
4. The required MIB and dependencies are loaded.
5. Discovery or the SNMP pattern is using the expected value.

Once that chain is in place, a vendor-specific SNMP object becomes much less mysterious and far more useful inside ServiceNow.