网络协议篇之SNMP协议（二）—— 管理信息库MIB及OID

       上篇文章提到一套完整的SNMP系统主要包括管理信息库（MIB）、管理信息结构（SMI）及SNMP报文协议。

       本篇我们来学习管理信息库（MIB）

一、管理信息库MIB

       任何一个被管理的资源都表示成一个对象，称为被管理的对象。MIB是被管理对象的集合。它定义了被管理对象的一系列属性：对象的名称、对象的访问权限和对象的数据类型等。每个SNMP设备（Agent）都有自己的MIB。MIB也可以看作是NMS（网管系统）和Agent之间的沟通桥梁。它们之间的关系如图所示：

        MIB文件中的变量使用的名字取自ISO和ITU管理的对象标识符（object identifier）名字空间。它是一种分级树的结构。

        如下图所示，第一级有三个节点：ccitt、iso、iso-ccitt。低级的对象ID分别由相关组织分配。一个特定对象的标识符可通过由根到该对象的路径获得。一般网络设备取iso节点下的对象内容。如名字空间ip结点下一个名字为ipInReceives的MIB变量被指派数字值3，因而该变量的名字为：

       iso.org.dod.internet.mgmt.mib.ip.ipInReceives

相应的数字表示（对象标识符OID，唯一标识一个MIB对象）为：

        1.3.6.1.2.1.4.3

         当网络管理协议在报文中使用MIB变量时，每个变量名后还要加一个后缀，以作为该变量的一个实例。如ipInReceives的实例数字表示为：1.3.6.1.2.1.4.3.0.

         需要注意的是，MIB中的管理对象的OID有些需要动态确定，如IP路由表，为了指明地址202.120.86.71的下一站路由(next hop)，我们可以引用这样的实例：

         iso.org.dod.internet.mgmt.mib.ip. ipRouteTable.ipRouteEntry.ipRouteNextHop.202.120.86.71,

        相应的数字表示为：1.3.6.1.2.1.4.21.1.7.202.120.86.71

        对于这种动态对象标识的实例，由于无法转换为预先指定的Readkey名称，与飞邻的产品架构冲突（需要动态生成可变Readkey），暂不考虑支持。

二、管理信息库mib-2

        在Internet结点下面的第二个结点是mgmt（管理），标号是2。再下面是管理信息库，原先的结点名是mib。1991年定义了新的版本MIB-II，故结点名现改为mib-2，其标识为{1.3.6.1.2.1}，或{Internet(1) .2.1}。这种标识为对象标识符。

        最初的结点mib将其所管理的信息分为8个类别(上图展示了7个)。现在de mib-2所包含的信息类别已超过40个

         应当指出，MIB的定义与具体的网络管理协议无关，这对于厂商和用户都有利。厂商可以在产品（如路由器）中包含SNMP代理软件，并保证在定义新的MIB项目后该软件仍遵守标准。用户可以使用同一网络管理客户软件来管理具有不同版本的MIB的多个路由器。当然，一个没有新的MIB项目的路由器不能提供这些项目的信息。

         这里要提一下MIB中的对象{1.3.6.1.4.1}，即enterprises（企业），其所属结点数已超过3000。例如IBM为11.3.6.1.4.1.2}，Cisco为{1.3.6.1.4.1.9}，Novell为{1.3.6.1.4.1.23}，Huawei为{1.3.6.1.4.1.2011}。世界上任何一个公司、学校只要用电子邮件发往[e-mail]进行申请即可获得一个结点名。这样各厂家就可以定义自己的产品的被管理对象名，使它能用SNMP进行管理。

三、OID

        OID(对象标识符），是SNMP代理提供的具有唯一标识的键值。MIB（管理信息基）提供数字化OID到可读文本的映射。

1、OID

      OID的编写规则和习惯

      SNMP OID是用一种按照层次化格式组织的、树状结构中的唯一地址来表示的，它与DNS层次相似。与其他格式的寻址方式类型，OID以两种格式加以应用：全名和先对名（有时称为“相关”）

      完全验证格式从root根开始，并且向外移到某个设备的独立的质上。例如一个完整验证的地址为:

      该OID可用人们可读的方式重写为：

      所有完全验证OID都有 .iso.org.dod.internet.private 开始，数字表达为: .1.3.6.4. 。几乎所有的OID都会跟上企业(.1)和由IANA（互联网编号分配中心分配的）唯一的厂商标号。例如OID 789表示Network Appliance格式的厂商编号( NetApp ）。厂商编号后面的是基于厂商实现的功能，并且各不相同。请注意，在iso.前面的 . ` ，与DNS中的后点相似，正确验证的OID是有一个表示根的前缀 `. 开始的。

      OID的相对格式，从企业值开始，略过所有的隐含地址。因此，我们可以用相对地址 enterprises.netapp.netappl.raid.diskSUmmary.diskSpaceCount.0 来表示上述的OID，或者用数字格式 .1.789.6.4.8.0 .

       写OID的常用格式是用MIB名称和在MIB中定义的唯一键值。例如，我们可以用简写的格式重写上述OID

       NETWORK-APPLIANCE-MIB::diskSpareCount.0

       MIB中OID的书写格式规则为：:MIB Name::唯一键值.instance.

       某些唯一键值，可用多个实例表示，这样所有的OID都以实例值结尾。这就是为什么你得注意到大多数OID都是以一个 .0 结尾的。

四、MIB内部结构

       MIB的内部结构刚开始时会让人感觉有些奇怪和不好理解，不过它的结构非常好，你可以在不懂的情况下一个一个看进去。MIB的结构来源于IETF RFC1155和2578定义的管理信息结构。如果你想要修改或编写自己的MIB，在动手前理解SMI非常有帮助。

      为了更好地理解他们是怎样工作的，我们先来看看MIB的头:

-- PowerNet-MIB {iso org(3) dod(6) internet(1) private(4)-- enterprises(1) apc(318) }PowerNet-MIB DEFINITIONS ::= BEGINIMPORTSenterprises, IpAddress, Gauge, TimeTicks FROM RFC1155-SMIDisplayString FROM RFC1213-MIBOBJECT-TYPE FROM RFC-1212TRAP-TYPE FROM RFC-1215;apc OBJECT IDENTIFIER ::= { enterprises 318 }products OBJECT IDENTIFIER ::= { apc 1 }apcmgmt OBJECT IDENTIFIER ::= { apc 2 }Comments can be inserted into a MIB by prepending them with two dashes. In the header the declaration BEGIN starts off the MIB. Imports can be used to pull information from other MIBs, typically those mandated by the MIB-II standard.

可以用行开头为 -- 的方法在MIB中加入注释。

在头部用 BEGIN`声明来开始MIB的定义。 

`Imports 可用来从其他MIB中提取信息,通常用它来提取MIB-II规范要求的内容。

MIB放置从enterprise值开始的OID地址的结构。

       在此，enterprise值是318, 对应 "apc" (相对地址为 .1.318）。 通常之后会定义几个类别。注意在花括号间定义的两个值,其父地址后面跟一个它自己的地址。因此产品标识符有apc标识符表示，其父为enterprise标识符，以此类推。类别和自类别的类型通常跟在MIB头的后面，并且把有用的键值分割为子组。通过分段，各种值分别被列出，这样可用的值更容易浏览。

MIB的真正好处在于对象类型的描述。以下是一个整形键值的例子:

upsBasicOutputStatus OBJECT-TYPESYNTAX INTEGER {   unknown(1),   onLine(2),   onBattery(3),   onSmartBoost(4),   timedSleeping(5),   softwareBypass(6),   off(7),   rebooting(8),   switchedBypass(9),   hardwareFailureBypass(10),   sleepingUntilPowerReturn(11),   onSmartTrim(12)}ACCESS read-onlySTATUS mandatoryDESCRIPTION   "The current state of the UPS. If the UPS is unable    to determine the state of the UPS this variable is set    to unknown(1)."::= { upsBasicOutput 1 }

      因此，在这里真正需要注意的是，MIB其实只是提供给我们一张我们想从某个SNMP代理中获得的可用OID的各种值的地图。一个MIB描述了在哪里找某个值、以及返回结果是什么。我们可以不用MIB与设备进行交互，只不过在理获得'Up'的返回值，要比‘1’的返回值要简单的多。通过利用Net-SNMP命令行工具，你可以决定你希望返回结果的输出样式（这种方式下使用“Up"这样的格式更好），或者你用脚本调用工具时（这种方式下使用”1“的格式就更好）。