SNMP 嵌套表定义在父表之下一级答案

【问题标题】：SNMP nested table defined one level below the parent tableSNMP 嵌套表定义在父表之下一级
【发布时间】：2015-06-02 14:11:09
【问题描述】：

如this post 和this note 中所述，可以使用以下结构在 SNMP 中对嵌套表进行建模：

parentTable ... ::= { parentNode 1 } -- using index x
childTable  ... ::= { parentNode 2 } -- using index x and y

即父表和子表注册在同一个节点下（即在同一级别），这是我想要避免的（主要是因为它在该节点上腰围一个 OID，这在我的应用程序中是有问题的处理）。

我的问题是：是否可以完全一样，唯一的区别是我在 parentNode 的子节点中注册子表？它看起来像：

subNode OBJECT IDENTIFIER ::= { parentNode 512 }
parentTable ... ::= { parentNode 1 } -- using index x
childTable  ... ::= { subNode 1 }    -- using index x and y

如果此语法有效，它是否具有与第一个版本相同的属性（删除 parentNode 中的 raw 也会删除 childNode 中的相应 raw )?

【问题讨论】：

我已经尝试编译一个包含如上定义的表的 MIB，它运行良好：childTable 可以定义在一个子节点中（甚至是多个级别的子节点）。

标签： nested snmp

【解决方案1】：

详细解释请参考链接 https://sourceforge.net/p/net-snmp/mailman/message/24158139/

感谢陈亚普引用优秀书籍了解 SNMP MIB（第 277 页）：

SNMP SMI 不允许 MIB 编写器声明一个对象在 table 是一个数组（一个 ASN.1 序列）。这种限制，称为“不表中的表”在 SNMP 社区中，是 SNMP 社区的常见来源让 SNMP MIB 设计者感到沮丧。

【讨论】：

【解决方案2】：

试试吧！您的 MIB 编译器应该告诉您它是否有效。

如果您不使用 MIB 编译器，那么您真的应该使用！将无效的 MIB 文件发布到世界上是非常糟糕的形式，因此您应该采取一切预防措施。（好吧，在这里发布是一个好的开始。）由于 SNMP 不允许您破坏 MIB 的任何用户的向后兼容性，因此如果您的 MIB 已传播给更广泛的受众，即使删除非法结构也会造成麻烦。

当谈到“父”和“子”表索引时，我觉得这就像 SNMP 中通常所说的“增强表”。您必须使用 AUGMENTS 关键字定义childTable。如果不是您想象的情况，请告诉我。 From the WebNMS API documentation:

当一个表的行和另一个表的行之间存在一对一的依赖关系时，就出现了增强表。在这种情况下，一张表是基表，另一张表是增广表。当特定 MIB 导入另一个 MIB 并共享同一个表时，可能会出现这种情况。一个经典的例子是 IF-MIB 导入 RFC 1213-MIB 中定义的组接口，其中 IF-MIB 扩充了 RFC 1213-MIB 中定义的 ifTable。

我的直觉是你的构造是完全合法的。 MIB 树看起来像这样，我已经多次看到类似的树。我认为索引根本不会成为问题，它们真的不重要。

parentNode (1)
|
|-parentTable(1.1)
| |
| |-x(1.1.1)
| \-secondColumn(1.1.2)
\-subNode(1.512)
   |
   \-childTable(1.512.1)
      |
      |-x(1.1.1)
      |-y(1.512.1.1)
      \-someData(1.512.1.2)

关于你的表的语义，是的，增广一个表的意思是当删除parentTable中的一行时，应该从childTable中删除相应的数据。您的 MIB 实现需要确保发生这种情况。

【讨论】：