Должны ли имена / дескрипторы объектов быть уникальными в модуле SNMP MIB? - PullRequest
Новая
       18

Должны ли имена / дескрипторы объектов быть уникальными в модуле SNMP MIB?

0 голосов
/ 07 января 2020

У меня есть предоставленный поставщиком файл 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 * 1011. * в том же MIB (см. ниже в моем примере Foobar.mib).

Это сбивает с толку Net :: SNMP, поскольку FooBarMib::commonName теперь может означать два разных OID.

Было бы замечательно включить ссылку на RF C в отчет об ошибках для поставщика.

Я обнаружил, что RF C 1155 - Структура и идентификация информации управления для интернет-сетей на основе TCP / IP говорит:

Каждый ОПИСАТЕЛЬ ОБЪЕКТА, соответствующий типу объекта в MIB * -стандартном rnet, должен быть уникальным, но mnemoni c для печати строка. Это продвигает общий язык, который люди могут использовать при обсуждении MIB, а также упрощает простые сопоставления таблиц для пользовательских интерфейсов.

Это относится только к "inte rnet -стандартным MIB" и, следовательно, не продавцу MIB?

Я также нашел RF C 2578 - Структура информации управления Версия 2 (SMIv2) , которая гласит:

Для всех дескрипторы, появляющиеся в информационном модуле, дескриптор должен быть уникальным и иметь мнемону c и не должен превышать 64 символа в длину.

Но MIB для агента SNMP v1 также должен придерживаться RF C 2578? Агент SNMP, реализующий MIB, поддерживает только SNMP v1 по любой причине. А в RFC 2578 в названии стоит SMIv2, где 2 меня немного беспокоит. Однако сам MIB импортирует из SMIv2 FWIW.

Я обнаружил две ссылки inte rnet, которые говорят, что имена / дескрипторы объектов должны быть уникальными в MIB, но без ссылки на источник:

Эндрю Комиагин в "SNMP OID с неуникальными именами узлов" здесь, на SO, говорит:

MIB * Имена объектов должны быть уникальными в пределах весь файл MIB.

и Дэйв Шилд в списке рассылки Net :: SNMP говорит:

В пределах данного модуля MIB все имена объектов должны быть уникальными. Как объекты, определенные в этой MIB, так и объекты явно ИМПОРТИРОВАННЫЕ. У вас не может быть двух объектов с одинаковыми именами, на которые ссылаются в одной и той же MIB.

Я бы хотел получить ссылку на стандарт / RF C для любого из этих двух эквивалентных операторов.

Пример 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

1 Ответ

1 голос
/ 13 января 2020

К сожалению, предприятия могут делать все, что хотят. Если они хотят хорошо играть, им советуют придерживаться правил. Подробности на https://tools.ietf.org/html/rfc2578#section -3

...