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

我有一个供应商提供的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

在供应商的bug报告中包含一个RFC链接将是一件大事

我发现上面写着：

与中的对象类型对应的每个对象描述符 互联网标准MIB应是唯一的、可打印的助记符 一串这促进了人类在需要时使用的共同语言 讨论MIB，还可以简化 用户界面

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

我还发现上面写着：

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

但是SNMP v1代理的MIB是否也必须遵守RFC 2578？SNMP代理 无论出于何种原因，实现MIB只支持SNMP v1。和RFC 2578在标题中有

SMIv2

，其中

2

让我有点担心。但是，MIB本身确实从

SMIv2

FWIW导入

我发现了两个internet引用，它们指出对象名称/描述符在MIB中必须是唯一的，但没有源引用：

在这里这样说：

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

并说：

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

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

示例Foobar.mib 这将

commonName

定义为

：={footentry 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

---

不幸的是，企业可以为所欲为。如果他们想玩得好，建议他们遵守规则。详细信息在

听起来像是一个损坏的MIB文档。假设您需要在另一个MIB文档中引用

commonName

对象，那么MIB解析器/编译器如何知道应该使用该文件中的

commonName

？为了避免这种歧义，RFC文档已经禁止了这种情况，我相信大多数解析器/编译器也应该给出错误。但是，请注意，许多供应商将损坏的MIB文档发送给其客户（甚至Cisco）。主要原因是人们很少阅读每个MIB文档。您可以联系供应商寻求解决方案。您好@LexLi，我听到了。我也觉得它坏了。但是，您是否有任何特定的RFC引用支持“听起来像一个坏了的MIB文档”和“RFC文档禁止这样做”？不幸的是，企业可以随心所欲。如果他们想玩得好，建议他们遵守规则。以最好的方式证明它是一个演示的细节。对使用了两次的名称执行get，这很容易说明不能用唯一的键访问这两个值。@vomi:Sure

snmpget。。。FooBarMib:：commonName

不起作用，但

snmpget。1.3.$做任何事。工作的
snmpget FooBarMib:：commonName
是基于RFC的实际需求吗？（哪个RFC？）供应商可以合理地宣称，
snmpbulkget。。。FooBarMib:：fooTable
和
snmpbulkget。。。FooBarMib:：barTable
工作正常，因此请使用它：-）