SNMP:ASN.1 MIB 定义。在表中引用表

发布于 2024-08-27 04:00:32 字数 698 浏览 8 评论 0原文

自从我编写 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(有一些很好的理由取代了对网络管理优雅的需求。所有属性都将仅通过陷阱报告。我认为这是有效的 SNMP MIB 定义,但希望获得一些反馈

Its's been a while since I've written ASN.1 so..

Our data model is comprised of several table definitions within a table. This is not workable in SNMP, so we need to flatten the definitions. The easiest way to do this would be to have the embedded table indexed by the same OID as the parent table. Thus

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

becomes

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

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

The good thing is that in our application there will NEVER be any kind of SET, GET or GET NEXT so no need for SNMP walk (there are some very good reasons for this that supersede the need for network management elegance. All attributes will be reported via traps only. I think this is a valid SNMP MIB definitions but wanted to get some feedback.

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

掐死时间 2024-09-03 04:00:32

听起来你走在正确的轨道上。为了将一个表定义为另一个表的子表,您只需通过父表的索引加上子表的索引对其进行索引(例如,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

It sounds like you're on the right track. In order to define a table as a child of another table, you simply index it by the parent's index plus the child's index (e.g., 0.1.8.23.7.2.42 where 2 is the parent index and 42 is the child index).

For example, you could define a parent like:

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

With a child table defined as:

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

Note that it's not necessary to list parentIndex in the ChildEntry sequence since it's already be declared elsewhere in the MIB.

This method works well and it even responds to snmp walks without issue.

Once you have a MIB that you think accurately defines the structure you want, you can validate it using smilint if you are on a linux machine or have cygwin installed or you can validate it online.

Update

This pattern will work for deeper nesting as well.

A grandchild table could be defined as:

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

The only limit on nesting depth is the maximum OID length (which, I believe, is 127): A column's base OID length plus the number of indices for the table must be less than the maximum OID length.

One other item to note is that at each level there can be multiple siblings.

A second child could be defined as:

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
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文