Most Orion users are aware that we ship a large MIB database (approaching a million OIDS) as part of Network Performance Monitor, but in conversations with users, we’ve noticed that some users are unclear on exactly what the MIB database is and is not used for.
So what is it used for? One of its core uses is to support the Orion SNMP Trap Server that ships as part of NPM. The Trap Server is a “listener” service, which means it waits on the specified port and when a trap is sent on that port, it processes the message. That processing involves looking up the trap in the MIB database to determine how to handle it. Furthermore, if you want to create an SNMP Trap Rule to take some action based on the specific trap, the creation of that rule may involve a lookup in the MIB database, as in the screenshot below.
What else is the MIB database used for? If you try to create a Universal Device Poller (UnDP), you will typically use the MIB database. As part of the UnDP creation process, you must provide the target OID to be polled. Sometimes, you know the OID already. If so, you can type or paste the OID into the UnDP window. When you do so, it will immediately check the MIB database for that OID. If the OID is in the MIB database, it will automatically fill in the name, description, MIB value type, etc., based on the information in the relevant MIB.
One common misconception about the UnDP is that the OID you want to poll must be in the MIB database. Not true. If you have an OID, the UnDP will try to poll it if assigned to a device, regardless of whether it’s in the MIB database or not. What you lose if it isn’t in the MIB database is that you have to fill in the name, description, and other details yourself. That’s it. You can get by without it.
But what if you don’t know the OID you need? For instance, you might know that you want to measure something like temperature on a Cisco router, but you don’t know exact MIB. In this case, you can click “Browse MIB Tree” in the UnDP and you’ll be able to browse Cisco section of the MIB tree. The data for that browsing session is pulled from the MIB database. And if you are really unsure about what you’re looking for, you can click “Search MIBs”, type in a search term, and you’ll get a list of related OIDs to check out, and those OIDs are pulled from the MIB database. If you’re in more of an exploratory mode regarding what to poll about a particular device, this search functionality is a good way to go.
What, then, is the MIB database not used for, even though most people think it is? The most common belief is that the MIB database is used to identify devices. Orion NPM automatically recognizes a very large number of devices automatically, with no configuration. When a new device is added via discovery or via the add-a-node wizard, Orion does an SNMP query, pulls back an OID called the sysobjectID. A reasonable assumption would be that Orion is checking this OID against the MIB database. Reasonable, yet wrong. Orion compares this value with a completely different database to identify the vendor, machine type, etc. Therefore, when you add a device that Orion doesn’t recognize, updating the MIB database won’t help. It’s the sysobjectID database that needs to be updated and that only happens with releases and service packs. It’s not part of the weekly MIB database update.
You might ask why we have two databases. Are we trying to be difficult? Nope. This situation is an accident of product evolution. The sysobjectid database came first, long before Orion had a trap server or a universal device poller. SNMP traps were added in 8.0, and the Universal Device Poller was added in 9.0, and both of these features needed a robust MIB database and the older sysobjectid store wasn’t appropriate. Instead, Orion inherited the existing MIB database from our Engineer’s Toolset. We may well consolidate these two databases at some point, but until then, this post explains the way things work today.