SNMP: ASN.1 MIB定义。在一个表格中引用另一个表格。

16

我已经有一段时间没有写过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 walk(有一些非常好的理由超越了对网络管理的优雅性的需求)。所有属性都将仅通过trap进行报告。我认为这是有效的SNMP MIB定义,但希望得到一些反馈。

提前致谢。

1个回答

25

听起来你走在了正确的道路上。为了将一个表定义为另一个表的子表,你只需要使用父表的索引加上子表的索引作为索引(例如: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

请注意,在ChildEntry序列中不必列出parentIndex,因为它已在MIB的其他地方声明过。
这种方法运行良好,甚至可以回应SNMP遍历而没有问题。
一旦您拥有您认为准确定义所需结构的MIB,您可以使用smilint进行验证(如果您在Linux机器上或安装了cygwin),或者您可以在线验证更新 该模式也适用于更深层次的嵌套。
子表可以被定义为:
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

1
这个原则是否适用于第三张表,也就是说它会有3个索引,还是在层次结构变深时有更好的管理方法? - TheJuice
3
@TheJuice:是的,该原则适用于儿童表格,最多深度为最大 OID 长度(我认为是127)。正如你所猜测的那样,每增加一个级别就会有另一个索引。我将编辑我的答案以包含一个示例。我不知道管理更深层次的层次结构是否有更好的方法。 - lostriebo
1
当你说“父节点的索引(p)加上子节点的索引(c)”时,它是指 xxx.p.c 还是 xxx.(p+c)?这可能听起来像一个新手问题,但...那就是我;)(虽然前者对我来说更有意义,但经验多次证明我的感觉与“MIB感觉”不同) - Matthieu
1
@Matthieu 应该是 xxx.p.c,就像你所怀疑的那样。我已经更新了答案中的解释,并包括了一个示例。感谢您提出了一个很好的澄清问题! - lostriebo

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接