SNMP: определения ASN.1 MIB. Ссылка на таблицу внутри таблицы - PullRequest
Новая
       25

SNMP: определения ASN.1 MIB. Ссылка на таблицу внутри таблицы

13 голосов
/ 24 марта 2010

Прошло много времени с тех пор, как я написал ASN.1, так что ...

Наша модель данных состоит из нескольких определений таблиц в таблице. Это не работает в SNMP, поэтому нам нужно сгладить определения. Самый простой способ сделать это - проиндексировать встроенную таблицу по тому же OID, что и у родительской таблицы. Таким образом 

someTableEntry ::= SEQUENCE {
   someTableIndex
        Integer32,
   someTableDomain
        Integer32,
   someTableFooTable
        SEQUENCE OF SomeTableFooTable
}

становится 

    someTableEntry ::= SEQUENCE {
       someTableIndex
            Integer32,
       someTableDomain
            Integer32,
    } 

someTableFooTable ::= SEQUENCE {
    someTableIndex
       Integer32,
....
}

Хорошо, что в нашем приложении НИКОГДА не будет никаких SET, GET или GET NEXT, поэтому нет необходимости в обходе SNMP (есть несколько очень веских причин, которые заменяют необходимость элегантности управления сетью. будет сообщено только через ловушки. Я думаю, что это правильные определения SNMP MIB, но хотел получить некоторую обратную связь.

Заранее спасибо.

1 Ответ

20 голосов
/ 24 марта 2010

Похоже, вы на правильном пути. Чтобы определить таблицу как дочерний элемент другой таблицы, вы просто индексируете ее по индексу родителя плюс индекс дочернего элемента (например, 0.1.8.23.7.2.42, где 2 - родительский индекс, а 42 - дочерний индекс).

Например, вы можете определить родителя как: 

parentTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF parentEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Parent table"
    ::= { example 1 }

parentEntry OBJECT-TYPE
    SYNTAX       ParentEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Parent table"
    INDEX        { parentIndex }
    ::= { parentTable 1 }

ParentEntry ::= SEQUENCE {
    parentIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the parent table

С дочерней таблицей, определенной как: 

childTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF childEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Child table"
    ::= { example 2 }

childEntry OBJECT-TYPE
    SYNTAX       ChildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Child table"
    INDEX        { parentIndex,
                   childIndex }
    ::= { childTable 1 }

ChildEntry ::= SEQUENCE {
    childIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the child table

Обратите внимание, что нет необходимости указывать parentIndex в последовательности ChildEntry, поскольку он уже объявлен в другом месте в MIB.

Этот метод работает хорошо и даже без проблем реагирует на прогулки по snmp.

Если у вас есть MIB, который, по вашему мнению, точно определяет желаемую структуру, вы можете проверить его, используя smilint, если вы работаете на машине с Linux или у вас установлен Cygwin, или вы можете проверить это онлайн .

Update

Этот шаблон будет работать и для более глубокого вложения.

Таблица внука может быть определена как: 

grandChildTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF grandChildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Grandchild table"
    ::= { example 3 }

grandChildEntry OBJECT-TYPE
    SYNTAX       GrandChildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Grandchild table"
    INDEX        { parentIndex,
                   childIndex,
                   grandChildIndex }
    ::= { grandChildTable 1 }

grandChildEntry ::= SEQUENCE {
    grandChildIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the grandChild table

Единственным ограничением глубины вложения является максимальная длина OID (которая, как мне кажется, составляет 127): базовая длина OID столбца плюс количество индексов для таблицы должны быть меньше максимальной длины OID.

Еще один момент, на который следует обратить внимание: на каждом уровне может быть несколько братьев и сестер.

Второй ребенок может быть определен как: 

secondchildTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF secondchildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Second child table"
    ::= { example 4 }

secondchildEntry OBJECT-TYPE
    SYNTAX       SecondchildEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION  "Entry in Second child table"
    INDEX        { parentIndex,
                   secondchildIndex }
    ::= { secondchildTable 1 }

SecondchildEntry ::= SEQUENCE {
    secondchildIndex            Unsigned32,
    -- other columns in the table
    }

-- define the columns in the second child table
...