对象名称/描述符在 SNMP MIB 模块中必须是唯一的吗？

Question

我有一个供应商提供的 MIB 文件，其中在同一个 MIB 的两个不同表中定义了相同的对象名称/描述符。不幸的是，我认为 MIB 是专有的，不能在此处完整发布。因此，我创建了一个类似的示例 Foobar.mib 文件，我已将其包含在本文末尾。

我的问题是：这样的 MIB 是否合法或可以被视为有效？

Net::SNMP 可以打印它的树，它看起来像这样：

+--foobar(12345678)
   |
   +--foo(1)
   |  |
   |  +--fooTable(1)
   |     |
   |     +--fooEntry(1)
   |        |  Index: fooIndex
   |        |
   |        +-- -R-- INTEGER   fooIndex(1)
   |        +-- -R-- String    commonName(2)
   |
   +--bar(2)
      |
      +--barTable(1)
         |
         +--barEntry(1)
            |  Index: barIndex
            |
            +-- -R-- INTEGER   barIndex(1)
            +-- -R-- String    commonName(2)

注意现在commonName 在fooTable 和barTable 下定义 完全相同的 MIB（请参阅下面的示例 Foobar.mib）。

这让 Net::SNMP 感到困惑，因为 FooBarMib::commonName 现在可以表示两个不同的 OID。

在供应商的错误报告中包含指向 RFC 的链接将是很棒的。

我发现RFC 1155 - Structure and identification of management information for TCP/IP-based internets 说：

每个对象描述符对应一个对象类型 互联网标准 MIB 应是唯一的，但有助记的，可打印的 细绳。这促进了人类在何时使用的通用语言 讨论 MIB 并促进简单的表映射 用户界面。

这是否仅适用于“互联网标准 MIB”，因此不适用于供应商 MIB？

我还发现 RFC 2578 - Structure of Management Information Version 2 (SMIv2) 说：

对于信息模块中出现的所有描述符，描述符应具有唯一性和助记性，长度不得超过64个字符。

但是 SNMP v1 代理的 MIB 是否也必须遵守 RFC 2578？ SNMP 代理 无论出于何种原因，实施 MIB 仅支持 SNMP v1。和 RFC 2578 的标题中有SMIv2，而2 让我有点担心。但是 MIB 本身确实从 SMIv2 FWIW 导入。

我发现两个 Internet 参考表明对象名称/描述符在 MIB 中必须是唯一的，但没有源参考：

Andrew Komiagin in "SNMP OID with non-unique node names" 在这里说：

MIB 对象名称​​在整个 MIB 文件中必须是唯一的。

和Dave Shield on the Net::SNMP mailing list 说：

在给定的 MIB 模块中，所有对象名称必须是唯一的。 该 MIB 中定义的对象和显式对象 进口的。你不能有两个同名的对象， 都在同一个 MIB 中引用。

我很想获得这两个等效语句中的任何一个的标准/RFC 参考。

示例 Foobar.mib

这将commonName 定义为::={ fooEntry 2 } 并进一步向下定义为::={ barEntry 2 }：

-- I've changed the MIB module name.
FooBarMib DEFINITIONS ::= BEGIN

IMPORTS sysName, sysLocation FROM SNMPv2-MIB;
IMPORTS enterprises, OBJECT-TYPE FROM SNMPv2-SMI;

-- I've provided a fake name and enterprise ID here

foobar OBJECT IDENTIFIER::= {enterprises 12345678}

foo OBJECT IDENTIFIER::={ foobar 1 }

fooTable OBJECT-TYPE
        SYNTAX SEQUENCE OF FooEntry
        MAX-ACCESS not-accessible
        STATUS current
::={ foo 1 }

fooEntry OBJECT-TYPE
        SYNTAX FooEntry
        MAX-ACCESS not-accessible
        STATUS current
        INDEX { fooIndex }
::={ fooTable 1 }

FooEntry ::= SEQUENCE{
        fooIndex INTEGER,
        commonName OCTET STRING,
        -- other leaves omitted
}

fooIndex OBJECT-TYPE
        SYNTAX INTEGER
        MAX-ACCESS read-only
        STATUS current
::={ fooEntry 1 }

commonName OBJECT-TYPE
        SYNTAX OCTET STRING
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
        "Label for the commonEntry"
::={ fooEntry 2 }

bar OBJECT IDENTIFIER::={ foobar 2 }

barTable OBJECT-TYPE
        SYNTAX SEQUENCE OF BarEntry
        MAX-ACCESS not-accessible
        STATUS current
::={ bar 1 }

barEntry OBJECT-TYPE
        SYNTAX BarEntry
        MAX-ACCESS not-accessible
        STATUS current
        INDEX { barIndex }
::={ barTable 1 }

BarEntry ::= SEQUENCE{
        barIndex INTEGER,
        commonName OCTET STRING,
        -- other leaves omitted
}

barIndex OBJECT-TYPE
        SYNTAX INTEGER
        MAX-ACCESS read-only
        STATUS current
::={ barEntry 1 }

commonName OBJECT-TYPE
        SYNTAX OCTET STRING
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
        "Label for the commonEntry"
::={ barEntry 2 }

END

Answer 1

不幸的是，企业可以为所欲为。如果他们想打得好，建议他们遵守规则。详情https://www.rfc-editor.org/rfc/rfc2578#section-3