對象名稱/描述符在 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是在同一個 MIB 中的fooTable和barTable下定義的（參見下面我的示例Foobar.mib ）。

這會混淆 Net::SNMP，因為FooBarMib::commonName現在可以表示兩個不同的 OID。

在供應商的錯誤報告中包含指向 RFC 的鏈接會很棒。

我發現RFC 1155 - 基於 TCP/IP 的互聯網管理信息的結構和標識說：

對應於 Internet 標准 MIB 中的對象類型的每個 OBJECT DESCRIPTOR 應是唯一的、但助記的、可打印的字符串。 這促進了人們在討論 MIB 時使用的通用語言，也促進了用戶界面的簡單表映射。

這是否僅適用於“互聯網標准 MIB”，因此不適用於供應商 MIB？

我還發現RFC 2578 - Structure of Management Information Version 2 (SMIv2)說：

對於出現在一個信息模塊中的所有描述符，描述符必須是唯一的和助記符，並且長度不能超過64個字符。

但是 SNMP v1 代理的 MIB 是否也必須遵守 RFC 2578？ 無論出於何種原因，實現 MIB 的 SNMP 代理僅支持 SNMP v1。 並且 RFC 2578 的標題中有SMIv2 ，其中2有點讓我擔心。 但是 MIB 本身確實從SMIv2 FWIW 導入。

我發現兩個 Internet 引用說對象名稱/描述符在 MIB 中必須是唯一的，但沒有源引用：

安德魯科米金在“帶有非唯一節點名稱的 SNMP OID”中說：

MIB 對象名稱在整個 MIB 文件中必須是唯一的。

Net::SNMP 郵件列表上的 Dave Shield說：

在給定的 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://tools.ietf.org/html/rfc2578#section-3