#2555 Two MIB files with overlapping OID subtrees, one masks the other


I'm a developer for a device that is configured via SNMP, and I'm writing MIB files to give names to the supported OIDs. I'm currently doing some testing with net-snmp 5.6 on a Mac, but our customers are mostly using Linux and whatever version their distros ship with.

To provide context for this ticket, here's an example entry:

captureMajorVersion OBJECT-TYPE
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Major release number of the capture software"
::= {tsiRevueCapture 1 1}

Some models support duplicate services when there is additional hardware installed. The second-to-last subtree specifies the device number, so this node may optionally be supported:

capture2MajorVersion OBJECT-TYPE
MAX-ACCESS read-only
STATUS current
DESCRIPTION "Major release number of the capture software"
::= {tsiRevueCapture 2 1}

If I put these both in the same MIB file, it works fine. But since the second one is optional, I'd like to put it in a second optional MIB file.

The problem is, if I do this, one of the files overrides the other with regard to the main subtree, and I only get half the names. Right now, I can access capture2MajorVersion, but not captureMajorVersion.

I can imagine other scenarios where vendors would like to provide "MIB overlays" for optional features. It's easier to maintain these in separate MIB files. We can install all of them and then net-snmp should union the entire namespace. Imagine a line of routers that all share the same basic set of OIDs, but more advanced models have more OIDs for more advanced features. For the end user, it doesn't matter if the vendor provides multiple MIBs or a single fat one that contains some entries not always supported. But for the vendor, it would aid revision control to be able to specify new OIDs in a new file, leaving the older MIBs untouched.

A related challenge pertains to the ordering of numbers specifying subtrees. If we'd defined MajorVersion for device 2 as {tsiRevueCapture 1 2} (opposite to above), then from an MIB perspective, it would be a lot easier. I could define tsiRevueCapture.1 for captureMajorVersion in general, and then I'd specify captureMajorVersion.1 and captureMajorVersion.2 for device 1 and device 2. Unfortunately, devices 1 and 2 are managed by separate processes, so the last node number in the OID has to specify the specific variable, not the device number, and I don't know how to get the proxy to forward requests otherwise. Can I use a 0 wildcard anywhere in the OID? However, the software has already been written. In any case, this is another argument for supporting MIB overlays.


  • Niels Baggesen

    Niels Baggesen - 2014-06-16

    I guess that you are talking about the agent that does not respond as you expect, not the tools not translating oid's to names?

    How did you build the agent modules? Did you use use our m2c tool, or did you code by hand?

    Could you possibly provide a simple example that show the problem? It is certainly not meant to work that way.

  • Timothy Miller

    Timothy Miller - 2014-06-21

    No. I'm definitely talking about snmptranslate not properly translating names into numerical OIDs. The simple example is something like:

    snmptranslate -On TECHSOURCE-REVUE-MIB::captureMajorVersion

    If I put those two OBJECT-TYPE entries into the same MIB file, they work fine. If I put them (along with all the proper header info, etc.) into two MIB files, only one of the files is recognized. This is because the OID ranges overlap, and net-snmp programs can't handle that.

    There is no problem getting the agents to respond as expected.

  • Niels Baggesen

    Niels Baggesen - 2014-06-23

    Strange, that is certainly not expected behavior. I am sure others have MIB file with similar structure that works as expected.
    Would you mind sharing the actual MIB files? If you want, you can send them to me privately at nba@users.sourceforge.net.

  • Niels Baggesen

    Niels Baggesen - 2014-06-23
    • assigned_to: Niels Baggesen

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks