SNMP的管理信息结构（第二版）

同第一版SMI一样，第二版SNMP的管理信息结构（SMI）定义了第二版的管理信息怎样用ASN.1的一个子集来表示。SMIv2是SNMPv1中所用SMI的一个超集，最初是作为一个建议标准在RFC1442中定义的，其中针对安全SNMP和SMP研究所提出的意见对第一版进行了许多改进。目前（1999年8月）用于实现基于共同体的SNMPv2的SMI草案标准是在RFC1902，第二版简单网络管理协议（SNMPv2）的管理信息结构中定义的。 SMIv2的主要改进是引入了几个新的数据类型；许多新的、扩展了的、定义更为清楚的ASN.1宏；同时还增加了MIB一致性要求和给厂商保留了自行扩展能力。 这一版本使管理信息定义比第一版更“富有表达力”。它是编写新MIB的标准，所有新的IETF标准MIB和许多最新的厂商信息描述块都是用SMIv2编写的。令人惊奇的是，只有Counter64这一个数据类型是第一版协议所不支持的，这使得两个版本间更易于共存和过渡。 因为SMIv2需要定义新的对象，所以给SNMPv2的MIB对象添加了一个新的分支，它就是snmpv2分支。它的OID（对象标识符）是1.3.6.1.6。这一分支目前有3个子分支：snmpDomains子树包括传输域；snmpProxys子树包括传输代理；snmpModules子树有各种模块的对象标识符的清单。 为实现更精确的定义，SMIv2中引入了新的数据类型。计数器和度量器现在按不同比特长度来定义：Counter32，Counter64和Gauge32。无符号32位整数类型现在是Unsigned32。比特现在可用BITS结构表示，它允许按位枚举。在RFC1442中为OSI网络地址定义的NsapAddress类型在草案版本中不再保留，因为实践证明了它是不必要的。注意，第一版中的所有数据类型依旧有效，但Opaque类型不应该再用，Opaque类型只是为了向后兼容而保留的。 在最高层，SMI用于创建信息描述块（information module）。这是一组信息，包含在SNMP网络管理中用到的相关数据。SMI定义了3种主要信息描述块：

? MIB描述块

? 一致性说明（Compliance Statements） ? 能力说明（Capability Statements）

SMI的真正重要性在于用它来创建MIB描述块；这些当然是管理协议操作的相关管理对象的集合。第二版MIB描述块中包括了管理对象的最大集合。一致性说明设置了应该具备的一个最低限度。能力说明允许各厂商描述它的具体实现细节，该细节代表了相应的一致性水平。要注意，在实际使用中信息描述块创建了两种不同的风格：标准描述块和各厂商或企业制定的描述块。

SMIv2定义了5种在SNMPv2信息描述块中使用的结构： ? IMPORTS子句

? OBJECT IDENTIFIER的值定义 ? SEQUENCE的类型定义

? SNMPv2中有限制的ASN.1类型指配 ? SNMPv2的ASN.1宏

SMIv2引入的宏丰富了文档并增强了管理信息的可维护性。牢牢掌握SMIv2中的宏将有助于定义和理解MIB信息描述块和在SNMPv2中遇到的其他符号表示法。

9

SNMPv2的SMI宏： 宏名字 MODULE-IDENTITY OBJECT-IDENTITY OBJECT-TYPE NOTIFICATION-TYPE TEXTUAL-CONVENTION OBJECT-GROUP NOTIFICATION-GROUP MODULE-COMPLIANCE AGENT-CAPABILITIES

宏说明 描述了整个信息描述块的语义规则 把附加的文本关联到OBJECT IDENTIFIER 管理对象的语法和语义 SNMPv2的通知语法 标准数据类型语法的更精确定义 定义相关管理对象集合 定义通知集合 列出了可选择的或必选的MIB模块 说明特定实现的具体细节 RFC 1902 1902 1902 1902 1903 1904 1904 1904 1904 SNMP协议（第一版）

SNMP的第2个核心组成部分是SNMP网络管理协议。SNMP网络管理协议是应用层协议，使网络管理站能够对每个代理进程的MIB中的管理对象进行读（提取、获得、或取回）、写（修改、设置、或存储）操作。它还定义了陷阱机制使代理进程能够根据某些预设的条件主动发送告警报文。协议中定义了命令和响应的报文格式，也描述了高层管理框架所需的授权和鉴别机制。 网络管理站通过协议交换SNMP报文来实现通信。为了确保SNMP协议的简单性目标，UDP被选定为传输协议。出于对SNMP的另外一个目标——可扩充性的考虑，可以使用、实际上也正在使用其他运输服务，但UDP仍然是推荐使用的运输服务，如果可能，应尽可能使用UDP。每个SNMP报文必须能够在单个UDP数据报中传送。标准规定：任何实现不要求接收大于484字节（3872比特）的报文，然而设计时应尽可能考虑接收最大UDP数据报。 网络管理站NMS和代理进程在明确定义的熟知UDP端口161接收除陷阱以外的所有SNMP报文，而Trap-PDU这个SNMP报文则只由网络管理站在明确定义的UDP端口162上接收。

鉴别和授权

SNMP高层管理所关心的是互相通信的网络管理站和代理进程双方之间的合法性鉴别和适当的授权。鉴别就是检查、验证报文发送者身份的过程。授权就是代理进程对收到并经过鉴别的报文的访问权限所进行的检查。 SNMP采用琐细鉴别机制。该技术简单且易于实现，但却提供了对怀有恶意或错误的SNMP报文的最贴身保护。琐细鉴别机制的关键部件是共同体名。共同体名是一个字符串，它表示各网络管理站和代理进程同属于一个公共的并是已知的组。虽然共同体名字可以是任意的字节串，但通常都用可打印的ASCII字符串来表示。在代理进程实现中通常都会设置一个默认的共同体名public。因为有像这样的默认字符串，未知的管理进程也可以“浏览”代理进程的MIB。 代理进程接收到命令，检查共同体字段时，它将存储在自己配置中的共同体名字与接收

10

到的报文中的共同体名字进行字符串比较，若一致，则协议认为报文是可信的，并进行下一步处理。若两个字符串的比较结果是不一致，则接收到的报文被丢弃。注意，字符串的比较操作是要区分大小写的，要通过鉴别，网络管理站和代理进程的共同体名字必须精确的匹配。 大量的研究工作和所提的提议正在为实现更少一些琐细、更安全的鉴别方式而努力，该方式将基于密钥、加密、带密钥的鉴别和其他一些安全机制。 一旦SNMP报文通过鉴别，接下来需要确定访问权限。每个共同体的成员都知道其MIB中的哪些对象可让其他成员访问。这个对象组称作视图。每个视图有两种对象访问方式：只读方式和读-写方式。为这两种访问方式和MIB中给对象定义的访问方式——只读、读写、只写、不可访问——创建一个矩阵，在矩阵中就列出了允许的SNMP操作。这个矩阵称为共同体定义文件： 共同体访问的只读方式 共同体访问的读写方式 MIB对象只读 Get Get-next Tap Get Get-next Trap MIB对象读写 Get Get-next Tap Get，Get-next Set Trap MIB对象只写 不允许操作 MIB对象不可访问 不允许操作 Get，Get-next Set Trap 不允许操作 SNMP的get，get-next，set，以及trap等操作都已嵌入SNMP报文中。

SNMP报文

SNMPv1的报文格式：（注：不包括Trap-PDU报文，Trap-PDU报文格式只在最里面一层有差别，即它的PDU字段值的不是RequestID、ErrorStatus、ErrorIndex、VarBindList，而是企业、代理进程地址、一般陷阱、特定陷阱、时间戳、变量绑定列表）

报文标签 报文长度 SNMP报文数据

PDU 版本号 共同体名

PDU标签 PDU长度 PDU字段值

RequestID Error Status Error Index VarBindList

SNMPv1规定，协议数据单元必须是以下所支持的5种类型之一： ? GetRequest-PDU ? GetNextRequest-PDU ? GetResponse-PDU

11

? SetRequest-PDU ? Trap-PDU

GetRequest报文过程： 网络管理站用GetRequest-PDU从目标代理进程的MIB中提取已知管理对象实例的值。该命令的有效响应是从代理进程方返回的GetResponse-PDU，在提取成功时其中填入了实例的当前值。 网络管理站 互连网 代理进程

GetRequest PDU

（处理请求）

GetResponse PDU

（处理响应） 代理进程处理GetRequest命令并给出响应的处理逻辑是非常直接的。 首先，代理进程核实在命令的变量绑定列表中指定的每个对象确实存在。各对象的访问方式必须兼容：必须都是只读方式或都是读写方式。试图对不可访问的对象进行读操作是不正确的，如对表格名和表格项（行定义）等聚合类对象就是不可访问的。引起提取失败的另一个原因是在执行读取操作的支持例程时发生内部错误。 代理进程一旦遇到某个对象的提取操作不正确，代理进程就构造一个GetResponse-PDU，其中errorStatus和errorIndex字段指向变量绑定列表中第一个发生错误的对象。若代理进程找不到要操作的对象，则errorStatus字段置为noSuchName（没有该对象）。如果对象是聚合类型的，则errorStatus也置为noSuchName。如果是操作支持例程发现错误，则errorStatus置为genErr。ErrorIndex字段设置的偏移量指向第一个导致差错的对象。 代理进程也会检测到另外一个失败状态，即在为一个成功执行的命令构造GetResponse-PDU时所形成的PDU超过了SNMP所允许的最大报文长度。这时，GetResponse-PDU与收到的GetRequest-PDU内容相同，但其中errorStatus字段设置为tooBig，errorIndex字段置为0。 若所有的管理对象都找到并提取了对象值，而且最后所得到的GetResponse-PDU符合长度要求，则errorStatus字段置为noError，errorIndex字段设置为0。 在发出GetReponse-PDU的所有情况中，requestID字段的值都是取自前面收到的GetRequest-PDU中的requestID值。最后将报文发送回发出命令的网络管理站。 应注意，在第一版SNMP中，如果在get或set操作中返回的GetResponse-PDU中标明发生了差错，则变量绑定列表Variable Bindings List中的全部内容都是无效的，不应使用。

GetNextRequest-PDU： 除了代理进程要提取按字典序大于指定管理对象的下一个对象的值以外，GetNextRequest命令与GetRequest很相似。这个命令主要是用于树遍历和确定预先未知的表格元素。它是MIB游走或动态地代理MIB时用到的操作，启动MIB浏览器时看到的就是

12