IBM Tivoli Netcool/OMNIbus V8.1

MIB 概念和设计

已定义用于特定设备的所有 SNMP MIB 模块组成了该设备的 MIB。术语 MIB 通常用于描述单个模块定义，但是这在技术上是不正确的。事实上，MIB 是用于管理特定设备（无论该设备与硬件还是软件相关）的所有模块的组合。因此，由供应商或在 RPC 中定义的每个模块的更精确名称为 SNMP MIB 模块。

所有 MIB 模块都是根模块的最终扩展。各个供应商发布的所有 MIB 模块都是从 RFC1155-SMI 中定义的企业对象扩展而来的。因此，所有 SNMP 代理必须支持 RFC1155，并且所有 MIB 模块都是 RFC1155 的扩展。

管理信息结构 (SMI)

为了使 SNMP 管理信息库 (MIB) 可扩展，系统将相关项归入不同的 MIB 模块中，而这些模块组成了一个结构化的层次结构。每个 MIB 模块都在以下构造内定义：

ModuleName DEFINITIONS ::= BEGIN END

模块中的 BEGIN 和 END 标记使得您能够在单个文本文件中定义多个模块。 MIB 编译器应该能够处理单个文件中定义的任意数量的模块，但是这不是必需的。

对于模块内已定义的每个对象，有一些约定。例如，模块名称必须以大写字母字符开头，并且只能包含字母、数字、连字符 (-) 或下划线 (_)。对象名称必须以小写字母字符开头，并且只能包含字母、数字、连字符或下划线。MIB 模块中的注释由两个连续的连字符 (--) 表示，此符号后面的任何行上的任何文本都可以忽略。

MIB 模块便于扩展的设计使得 MIB 能够通过添加附加模块支持任何新功能或设备。当某个模块编写为另一个模块的扩展时，它将包含 IMPORTS 段，此段位于 DEFINITIONS 行下。 IMPORTS 段定义了位于 MIB 层次结构中较高层次的模块所需的对象以及随后在其中定义这些对象的模块。

以下定义来自 RFC1157，指示了从 RFC1155 导入的多个对象。此段与 C 或 Perl 之类的编程语言或者 Netcool 规则文件中的 include 语句类似。此外，为了理解当前 MIB 模块 (RFC1157-SNMP) 中的对象，您必须了解先前 MIB 模块 (RFC1155-SMI) 中的对象。

RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, 
IpAddress, TimeTicks FROM RFC1155-SMI;

输入错误是指定导入的 MIB 名称时最容易犯的错误。例如，可能使用 RFC1212 而非正确的名称 RFC-1212 来指代 MIB 模块。如果 MIB 管理器突出显示解析错误，必须检查 IMPORTS 段以确认 MIB 模块名称是否正确。某些 MIB 模块还包含 EXPORTS 段（也以分号结尾）。此段告诉读程序 MIB 作者希望其他 MIB 模块也使用这些指定的对象。此段的用途与我们无关，因此可以忽略。

已定义的数据类型

SNMP MIB 模块以名为 ASN.13（抽象语法表示法 1）的格式定义。但是，SNMP 只使用 ASN.14 中的一部分。在 ITU-T X.208 和 ISO 8824 中定义了 ASN.1。在 RFC1155 中定义了适用于 SNMP 的 ASN.1。RFC1155 定义了以下有效 SNMP 数据类型：

原语类型：INTEGER、OCTET STRING、OBJECT IDENTIFIER 和 NULL
构造函数类型：SEQUENCE 和 SEQUENCE OF
已定义的类型：NetworkAddress、IpAddress、Counter、Gauge、TimeTicks 和 Opaque

已定义的类型是一种机制，用于指定原语类型或构造函数类型的特定格式。MIB 作者可以使用 TEXTUAL-CONVENTION 构造定义更多类型。

DisplayString 就是已定义类型的一个范例。在 SNMPv2-SMI-v1 MIB 模块中，版本为 V1 的 DisplayString 的定义如下：

DisplayString ::= OCTET STRING (0..255)

在 SNMPv2-TC MIB 模块中，版本为 V2 的 DisplayString 的定义如下：

DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION 
"Represents textual information taken from the NVT ASCII character set, as defined 
in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire 
specifies: - the use of character codes 0-127 (decimal) - the graphics characters 
(32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the 
special meanings specified in RFC 854 - the other 25 codes have no standard 
interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means 
carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on 
the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. 
(Note that this also means that a string may end with either 'CR LF' or 'CR NUL', 
but not with CR.) Any object defined using this syntax may not exceed 255 characters
 in length." SYNTAX OCTET STRING (SIZE (0..255))

以上示例说明了 DisplayString 是一个长度为 0 到 255 个字符的 OCTET STRING。请注意，与因特网标准的 MIB 中的对象类型对应的每个 OBJECT DESCRIPTOR 都必须是唯一的、便于记忆，并且可打印的字符串。

定义对象

编写 MIB 对象时常犯的错误是创建了不唯一的对象名。据称，RFC1155 语句意味着只有单个 MIB 模块中的对象才必须唯一。正如先前讨论的那样，MIB 是一组完整的模块，这些模块组合起来用于管理特定设备。因此，在任何 MIB 模块中定义的所有对象都必须唯一，不仅是在自己的模块中，在任何已导入的模块以及这些模块可能导入的任何模块中的任何其他对象名都必须唯一。常用于确保对象名唯一的机制是使用公司的股票代码或公司名称缩写形式来作为所有模块名称的前缀。

定义对象时，这些对象将映射到与生成树类似的数字层次结构中。每次定义对象时，会将该对象定义为父对象的叶子。 SNMP MIB 树中定义了以下三个根对象：

ccitt（根节点 0）
iso（根节点 1）
joint-iso-ccitt（根节点 2）

MIB 树中的所有其他节点都是这三个根节点的子代。例如，RFC1155-SMI 定义了以下对象：

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::=
 { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER
 ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT 
IDENTIFIER ::= { private 1 }

这些定义指示了对象名、关联的对象类型、每个对象的父代名称（或父代的有序列表），以及此子代在这一个父代或多个父代（也可能有多个）中的叶子编号。从图形上看，这些项呈分层格式。

展开和折叠 MIB 树中的节点可在整个“MIB 树”视图中移动。MIB 树的顶级分支包含 MIB 模块的名称，而包含在每个 MIB 模块分支内的是组成 MIB 的其他元素。当其他模块添加到 MIB 中时，其他对象会添加到 MIB 树中。可以通过对象名或对象标识 (OID) 对每个对象进行引用。最精确的方法是引用 OID。对象的 OID 定义为其编号及其回溯到根节点的每个祖代的编号，它们连接在一起，彼此之间以句点 (.) 分隔。企业对象（节点或叶子）的 OID 为 1.3.6.1.4.1。

许多供应商不能确保其对象名全球唯一，因此来自两个供应商的对象可能同名。这使得使用对象名来标识对象的方法会产生一些混淆。

库 | 支持 |