SNMP:ASN.1 MIB 定义。在表中引用表
自从我编写 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
听起来你走在正确的轨道上。为了将一个表定义为另一个表的子表,您只需通过父表的索引加上子表的索引对其进行索引(例如,
0.1.8.23.7.2.42
,其中2
是父索引,42
是子索引)。例如,您可以定义一个父表,如下所示:
将子表定义为:
请注意,不必在 ChildEntry 序列中列出parentIndex,因为它已在 MIB 中的其他位置声明。
这种方法效果很好,甚至可以毫无问题地响应 snmp 遍历。
一旦您拥有了您认为准确定义了所需结构的 MIB,您就可以使用
smilint
如果您使用的是 Linux 计算机或安装了 cygwin,或者您可以 在线验证。更新
此模式也适用于更深的嵌套。
孙表可以定义为:
嵌套深度的唯一限制是最大 OID 长度(我认为是 127):列的基本 OID 长度加上表的索引数量必须小于最大 OID 长度。
另一件需要注意的事项是,每个级别都可以有多个兄弟姐妹。
第二个孩子可以定义为:
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
where2
is the parent index and42
is the child index).For example, you could define a parent like:
With a child table defined as:
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:
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: