Question

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

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

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

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

@Retention(RetentionPolicy.RUNTIME)
@Target([ElementType.TYPE, ElementType.FIELD])
public @interface AnnotExample {
    String name()
}

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

Answer 1

试试吧！您的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的实施需要确保这一点。

Answer 2

请参阅链接以获取详细说明 https://sourceforge.net/p/net-snmp/mailman/message/24158139/

对chenyapu的信用优秀书籍了解SNMP MIB （第277页）的引用：

SNMP SMI不允许MIB编写器声明某个对象 table是一个数组（ASN.1序列）。这种限制，被称为＆＃34;没有表中的表＆＃34;在SNMP社区中，是一个经常来源对于初学SNMP MIB设计人员感到沮丧。

SNMP嵌套表定义在父表下一级

2 个答案: