第4章 SNMP网络管理体系结构

Love The Way You Lie 2024-02-17 22:06 28阅读 0赞

本文摘自： [http://blog.csdn.net/clevise/article/details/5101243][http_blog.csdn.net_clevise_article_details_5101243]

以下内容转自某论坛的高人回复，看了很有收获，特贴于此。

第4章 SNMP网络管理体系结构  
　　CMIP网络管理体系结构对系统模型、信息模型和通信协议几个方面都提出了比较完备和理想的解决方案，为其他网络管理体系结构建立了理想参考标准。SNMP网络管理体系结构是为了管理基于TCP/IP协议的网络而提出的，与TCP/IP协议与OSI协议的关系类似，SNMP与CMIP相比，突出的特点是简单。这一特点使SNMP得到了广泛的支持和应用，特别是在Internet上的成功应用，使得它的重要性越来越突出，目前已经成为CMIP之外的最重要的网络管理体系结构。  
4.1 SNMP体系结构  
4.1.1 TCP/IP网络管理的发展  
　　在TCP/IP的早期开发中，网络管理问题并未得到太大的重视。直到70年代，还一直没有网络管理协议，只有互联网络控制信息协议(ICMP)可以作为网络管理的工具。ICMP提供了从路由器或其它主机向主机传送控制信息的方法，可用于所有支持IP的设备。从网络管理的观点来看，ICMP最有用的特性是回声(echo)和回声应答(echo reply)消息对。这个消息对为测试实体间能否通信提供了一个机制。echo消息要求其接收者在echo reply消息中返回接收到的内容。另一个有用的消息对是时间戳(timestamp)和时间戳应答(timestamp reply)，这个消息对为测试网络延迟特性提供了机制。  
　　与各种IP头选项结合，这些ICMP消息可用来开发一些简单有效的管理工具。典型的例子是广泛应用的分组互联网络探索(PING)程序。利用ICMP加上另外的选项如请求间隔和一个请求的发送次数，PING能够完成多种功能。包括确定一个物理网络设备能否寻址，验证一个网络能够寻址，和验证一个主机上的服务器操作。  
　　PING在一些工具的配合下满足了TCP/IP网络初期的管理要求。但是到了80年代后期，当互联网络的发展呈指数增加时，人们感到需要开发比PING功能更强并易于普通网络管理人员学习和使用的标准协议。因为当网络中的主机数量上百万，独立网络数量上千的时候，已不能只依靠少数网络专家解决管理问题了。  
　　1987年11月发布了简单网关监控协议(SGMP)，成为提供专用网络管理工具的起点。SGMP提供了一个直接监控网关的方法。随着对通用网络管理工具需求的增长，出现了3个有影响的方法。  
　　1.高层实体管理系统(HEMS)：主机监控协议(HMP)的一般化。  
　　2.简单网络管理协议(SNMP)：SGMP的升级版。  
　　3.TCP/IP上的CMIP(CMOT)：最大限度地与OSI标准的CMIP、服务以及数据库结构保持一致。  
　　1988年，互联网络活动会议(IAB)确定了将SNMP作为近期解决方案进一步开发，而把CMOT作为远期解决方案的策略。当时普遍认为：TCP/IP不久将会过渡到OSI，因而不应在TCP/IP的应用层协议和服务上花费太多的精力。SNMP开发速度快，并能为网络管理经验库的开发提供一些基本的工具，可用来满足眼前的需要。  
　　为了强化这一策略，IAB要求SNMP和CMOT使用相同的被管对象数据库。即在任何主机、路由器、网桥以及其它管理设备中，两个协议都以相同的格式使用相同的监控变量。因此，两个协议有一个公共的管理信息结构(SMI)，和一个管理信息库MIB。  
　　但是，人们很快发现这两个协议在对象级的兼容是不现实的。在OSI的网络管理中，被管对象是很成熟的，它具有属性、相关的过程、通报以及其它一些与面向对象有关的复杂的特性。而SNMP为了保持简单性，没有这样复杂的概念。实际上，SNMP的对象在面向对象的概念下根本就不能称为对象，它们只是带有一些如数据类型、读写特性等基本特性的变量。因此IAB最终放松了公共SMI/MIB的条件，并允许SNMP独立于CMOT发展。  
　　从对OSI的兼容性的束缚中解脱后，SNMP取得了迅速的发展，很快被众多的厂商设备所支持，并在互联网络中活跃起来。而且，普通用户也选择了SNMP作为标准的管理协议。  
　　SNMP最重要的进展是远程监控(RMON)能力的开发。RMON为网络管理者提供了监控整个子网而不是各个单独设备的能力。除了RMON，还对基本SNMP MIB进行了扩充。有些扩充采用标准的网络接口，例如令牌环(token ring)和光纤分布数据接口(FDDI)，这种扩充是独立于厂商的。  
　　但是，单靠定义新的或更细致的MIB扩充SNMP是有限的。当SNMP被用于大型或复杂网络时，它在安全和功能方面的不足就变得明显了。为了弥补这些不足，1992年7月发表了3个增强SNMP安全性的文件作为建议标准。增强版与原来的SNMP是不兼容的，它需要改变外部消息句柄及一些消息处理过程。但实际定义协议操作并包含SNMP消息的协议数据单元(PDU)保持不变，并且没有增加新的PDU。目的是尽量实现向SNMP的安全版本的平滑过渡。  
　　但是这个增强版受到了另一个方案的冲击。同样是在1992年7月，四名SNMP的关键人物提出一个称为SMP的SNMP新版本。并实现了四个可互操作的方案。两个是商业产品，两个是公开软件。SMP在功能和安全性两方面提高了SNMP，特别是SMP增加了一些PDU。所有的消息头和安全功能都与提议的安全性增强标准相似。最终SMP被接受为定义第二代SNMP即SNMPv2的基础。1993年安全版SNMPv2发布。  
经过几年试用以后，IETF(Internet Engineering Task Force) 决定对SNMPv2进行修订。1996年发布了一组新的RFC (Request For Comments)，在这组新的文档中，SNMPv2的安全特性被取消了，消息格式也重新采用SNMPv1的基于“共同体(community)”概念的格式。  
删除SNMPv2中的安全特性是SNMPv2发展过程中最大的失败。主要原因是厂商和用户对1993版的SNMPv2的安全机制不感兴趣，同时IETF要求的修订时间也非常紧迫，设计者们来不及对安全机制进行改善，甚至来不及对存在的严重缺陷进行修改。因此不得不在1996年版的SNMPv2中放弃了安全特性。  
1999年4月IETF SNMPv3工作组提出了RFC2571～RFC2576，形成了SNMPv3的建议。目前，这些建议正在进行标准化。SNMPv3提出了SNMP管理框架的一个统一的体系结构。在这个体系结构中，采用User-based安全模型和View-based访问控制模型提供SNMP网络管理的安全性。安全机制是SNMPv3的最具特色的内容。  
4.1.2 SNMP基本框架  
1) 网络管理体系结构  
　　SNMP的网络管理模型包括以下关键元素：管理站、代理者、管理信息库、网络管理协议。管理站一般是一个分立的设备，也可以利用共享系统实现。管理站被作为网络管理员与网络管理系统的接口。它的基本构成为：  
　　・一组具有分析数据、发现故障等功能的管理程序；  
　　・一个用于网络管理员监控网络的接口；  
　　・将网络管理员的要求转变为对远程网络元素的实际监控的能力；  
　　・一个从所有被管网络实体的MIB中抽取信息的数据库。  
　　网络管理系统中另一个重要元素是代理者。装备了SNMP的平台，如主机、网桥、路由器及集线器均可作为代理者工作。代理者对来自管理站的信息请求和动作请求进行应答，并随机地为管理站报告一些重要的意外事件。  
　　与CMIP体系相同，网络资源也被抽象为对象进行管理。但SNMP中的对象是表示被管资源某一方面的数据变量。对象被标准化为跨系统的类，对象的集合被组织为管理信息库（MIB）。MIB作为设在代理者处的管理站访问点的集合，管理站通过读取MIB中对象的值来进行网络监控。管理站可以在代理者处产生动作，也可以通过修改变量值改变代理者处的配置。  
　　管理站和代理者之间通过网络管理协议通信，SNMP通信协议主要包括以下能力：  
　　Get：管理站读取代理者处对象的值；  
　　Set：管理站设置代理者处对象的值；  
　　Trap：代理者向管理站通报重要事件。  
　　在标准中，没有特别指出管理站的数量及管理站与代理者的比例。一般地，应至少要有两个系统能够完成管理站功能，以提供冗余度，防止故障。另一个实际问题是一个管理站能带动多少代理者。只要SNMP保持它的简单性，这个数量可以高达几百。  
2) 网络管理协议体系结构  
　　SNMP为应用层协议，是TCP/IP协议族的一部分。它通过用户数据报协议(UDP)来操作。在分立的管理站中，管理者进程对位于管理站中心的MIB的访问进行控制，并提供网络管理员接口。管理者进程通过SNMP完成网络管理。SNMP在UDP、IP及有关的特殊网络协议(如，Ethernet, FDDI, X.25)之上实现。  
　　每个代理者也必须实现SNMP、UDP和IP。另外，有一个解释SNMP的消息和控制代理者MIB的代理者进程。  
  
图4.1 SNMP的协议环境  
  
　　图4.1描述了SNMP的协议环境。从管理站发出3类与管理应用有关的SNMP的消息GetRequest、GetNextRequest、SetRequest。3类消息都由代理者用GetResponse消息应答，该消息被上交给管理应用。另外，代理者可以发出Trap消息，向管理者报告有关MIB及管理资源的事件。  
　　由于SNMP依赖UDP，而UDP是无连接型协议，所以SNMP也是无连接型协议。在管理站和代理者之间没有在线的连接需要维护。每次交换都是管理站和代理者之间的一个独立的传送。  
3) 陷阱引导轮询(Trap-directed polling)  
　　如果管理站负责大量的代理者，而每个代理者又维护大量的对象，则靠管理站及时地轮询所有代理者维护的所有可读数据是不现实的。因此管理站采取陷阱引导轮询技术对MIB进行控制和管理。  
　　所谓陷阱引导轮询技术是：在初始化时，管理站轮询所有知道关键信息(如接口特性、作为基准的一些性能统计值，如发送和接收的分组的平均数)的代理者。一旦建立了基准，管理站将降低轮询频度。相反地，由每个代理者负责向管理站报告异常事件。例如，代理者崩溃和重启动、连接失败、过载等。这些事件用SNMP的trap消息报告。  
　　管理站一旦发现异常情况，可以直接轮询报告事件的代理者或它的相邻代理者，对事件进行诊断或获取关于异常情况的更多的信息。  
　　陷阱引导轮询可以有效地节约网络容量和代理者的处理时间。网络基本上不传送管理站不需要的管理信息，代理者也不会无意义地频繁应答信息请求。  
4) 代管(Proxies)  
　　利用SNMP需要管理站及其所有代理者支持UDP和IP。这限制了在不支持TCP/IP协议的设备(如网桥、调制解调器)上的应用。并且，大量的小系统(PC、工作站、可编程控制器)虽然支持TCP/IP协议，但不希望承担维护SNMP、代理者软件和MIB的负担。  
　　为了容纳没有装载SNMP的设备，SNMP提出了代管的概念。在这个模式下，一个SNMP的代理者作为一个或多个其他设备的代管人。即，SNMP代理者为托管设备(proxied devices)服务。  
　　图4.2显示了常见的一类协议体系结构。管理站向代管代理者发出对某个设备的查询。代管代理者将查询转变为该设备使用的管理协议。当代理者收到对一个查询的应答时，将这个应答转发给管理站。类似地，如果一个来自托管设备的事件通报传到代理者，代理者以陷阱消息的形式将它发给管理站。  
  
  
图4.2 SNMP协议体系结构  
4.2 SNMP 管理信息  
与CMIP体系相同，SNMP的基础是包含被管元素信息的被称为MIB的数据库。每个被管资源由对象来表示，MIB是这些对象的有结构的集合。在SNMP中，MIB本质上是一个树型的数据库结构。网络中每个的系统都（工作站、服务器、路由器、网桥等）拥有一个反映系统中被管资源状态的MIB。网络管理实体可以通过提取MIB中的对象值监测系统中的资源，也可以通过修改这些对象值来控制资源。  
4.2.1 管理信息结构  
SNMP的规范SMI（structure of management information）为定义和构造MIB提供了一个通用的框架。同时也规定了可以在MIB中使用的数据类型，说明了资源在MIB中怎样表示和命名。SMI的基本指导思想是追求MIB的简单性和可扩充性。因此，MIB只能存储简单的数据类型：标量和标量的二维矩阵。我们将看到SNMP只能提取标量，包括表中的单独的条目。  
SMI避开复杂的数据类型是为了降低实现的难度和提高互操作性。但在MIB中不可避免地包含厂家建立的数据类型，如果对这样的数据类型的定义没有严格的限制，互操作性也会受到影响。  
为了提供一个标准的方法来表示管理信息，SMI必须：  
l 提供一个标准的技术定义MIB的具体结构;  
l 提供一个标准的技术定义各个对象，包括句法和对象值;  
l 提供一个标准的技术对对象值进行编码。  
1) MIB结构  
SNMP中的所有的被管对象都被排列在一个树型结构之中。处于叶子位置上的对象是实际的被管对象，每个实际的被管对象表示某些被管资源、活动或相关信息。树型结构本身定义一个将对象组织到逻辑上相关的集合之中的方法。  
MIB中的每个对象类型都被赋予一个对象标识符(OBJECT IDENTIFIER)，以此来命名对象。另外，由于对象标识符的值是层次结构的，因此命名方法本身也能用于确认对象类型的结构。  
对象标识符是能够唯一标识某个对象类的符号。它的值由一个整数序列构成。被定义的对象的集合具有树型结构，树根是引用ASN.1标准的对象。从对象标识符树的树根开始，每个对象标识符成分的值指定树中的一个弧。从树根开始，第一级有3个节点:iso、ccitt、joint-iso-ccitt。在iso节点下面有一个为“其他组织”使用的子树，其中有一个美国国防部的子树(dod)。SNMP在dod之下设置一个子树用于Internet的管理。如下所示:  
internet OBJECT IDENTIFIER :: = \{ iso (1) org (3) dod (6) 1\}  
因此，internet节点的对象标识符的值是1.3.6.1。这个值作为internet子树的下级节点标识符的前缀。  
SMI在internet节点之下定义了4个节点:  
l directory 为与OSI的directory相关的将来的应用保留的节点  
l mgmt 用于在IAB批准的文档中定义的对象  
l experimental 用于标识在Internet实验中应用的对象  
l private 用于标识单方面定义的对象  
mgmt子树包含IAB已经批准的管理信息库的定义。现在已经开发了两个版本的MIB，mib-1和和它的扩充版mib-2。二者子树中的对象标识符是相同的，因为在任何配置中，只有一个MIB。  
MIB中的mib-1或mib-2以外的对象可以用以下方法定义:  
l 由一个全新的修订版(如mib-3)来扩充或取代mib-2。  
l 可以为特定的应用构造一个实验MIB。这样的对象随后会被移到mgmt子树之下。例如定义包含各种传输媒体的MIB(例如为令牌环局域网定义的MIB)。  
l 专用的扩充可以加在private子树之下。  
private子树目前只定义了一个子节点enterprises，用于厂商加强对自己设备的管理，与用户及其他厂商共享信息。在enterprises子树下面，每个注册了enterprise对象标识符的厂商有一个分支。  
internet节点之下分为4个子树的做法为MIB的进化提供了很好的基础。通过对新对象的实验，厂商能够在其被接受为mgmt的标准之前有效地获得大量的实际知识。因此这样的MIB既是对管理符合标准的对象直接有效的，对适应技术和产品的变化也是灵活的。这一点也反映了TCP/IP协议的如下特性：协议在成为标准之前进行大量的实验性的使用和调测。  
图4.3 对象标识符树型结构  
2) 对象句法  
SNMP MIB中的每个对象都由一个形式化的方法定义，说明对象的数据类型、取值范围以及与MIB中的其他对象的关系。各个对象以及MIB的整体结构都由ASN.1描述法定义。为了保持简单，只利用了ASN.1的元素和特征的一个有限的子集。  
UNIVERSAL类型:ASN.1的UNIVERSAL类由独立于应用的通用数据类型组成。其中只有以下数据类型被允许用于定义MIB对象:  
l integer (UNIVERSAL 2)  
l octetstring (UNIVERSAL 4)  
l null (UNIVERSAL 5)  
l object identifier (UNIVERSAL 6)  
l sequence, sequence-of (UNIVERSAL 16)  
前3个是构成其他对象类型的基本类型。  
object identifier唯一标识对象的符号，由一个integer序列组成，序列中的integer被称为子标识符。对象标识符的integer序列从左到右，定义了对象在MIB树型结构中的位置。  
sequence 和sequence-of 用于构成表。  
APPLICATION-WIDE 类型:ASN.1的APPLICATION类由与特定的应用相关的数据类型组成。每个应用，包括SNMP,负责定义自己的APPLICATION数据类型。在SNMP中已经定义了以下数据类型:  
l networkaddress: 该类型用CHOICE结构定义，允许从多个协议族的地址格式中进行选择。目前，只定义了IpAddress一种地址格式。  
l ipaddress: IP格式的32位地址。  
l counter: 只能做增值不能做减值运算的非负整数。最大值被设为232 ?1，当达到最大值时，再次从0开始增加。  
l gauge: 可做增值也可做减值运算的非负整数。最大值被设为232 ?1，当达到最大值时被锁定，直至被复位(reset)。  
l timeticks: 从某一参照时间开始以百分之一秒为单位计算经历的时间的非负整数。当MIB中定义的某个对象类用到这个数据类型时，参照时间在该对象类的定义中指出。  
l opaque: 该数据类型提供一个传递任意数据的能力。数据在传输时被作为OCTET STRING编码。被传递的数据本身可以是由ASN.1或其他句法定义的任意的格式。  
3) 定义对象  
管理信息库由一个对象的集合构成，每个对象都有一个型和一个值。型是对被管对象种类的定义，因此型的定义是一个句法描述。对象的实例是某类对象的一个具体实现，具有一个确定的值。  
怎样定义MIB中的对象呢？ASN.1是将被使用的描述法。ASN.1中包含一些预定义的通用类型，也规定了通过现有类型定义新类型的语法。定义被管对象的一个可选方法是定义一个被称为Object的新类型。这样，MIB中所有的对象都将是这种类型的。这个方法在技术上是可行的，但会产生定义不便于应用的问题。我们需要多种值的类型，包括counter、gauge等等。另外，MIB支持二维表格或矩阵的定义。因此，一个通用的对象类型必须包含参数来对应所有这些可能性和选择性。  
另一个更有吸引力的方法，并且也是被SNMP所实际采用的方法是利用宏（macro）对在被管对象定义中相互关联的类型进行集合定义。一个宏的定义给出相关类型集合的句法，而宏的实例定义一个特定的类型。因此定义被分为以下等级：  
l 宏：定义合法的宏实例，即说明相关集合类型的句法  
l 宏实例：通过为宏定义提供实际参数生成实例，即说明一个特定的类型  
l 宏实例值：用一个特定的值来表示一个特定的实体  
图4.4是OBJECT-TYPE宏的定义(引自RFC 1212)。  
  
图4.4 被管对象宏  
其中的主要项目是:  
l SYNTAX: 对象类的抽象句法，该句法必须从SMI的对象句法类型中确定一种类型。  
l ACCESS: 定义通过SNMP或其他协议访问对象实例的方法。Access子句定义该对象类型支持的最低等级。可选的等级有:read-only、read-write、write-only和not-accessible。  
l STATUS: 指出该对象在实现上的要求。要求可以是:mandatory(必须)、optional(可选)、deprecated(恳求―必须实现的对象，但很可能在新版MIB中被删除)和obsolete(废除―不再需要被管系统实现的对象)。  
l DescrPart: 对象类型语义的文本描述。该子句是可选的。  
l ReferPart: 对定义在在其他MIB模块中的某个对象的文本型交叉引用。该子句是可选的。  
l IndexPart: 用于定义表。该子句只是在对象类型对应表中的”行”时才出现。  
l DefValPart: 定义一个默认值，用于建立对象实例。该子句是可选的。  
l VALUE NOTATION: 指出通过SNMP访问该对象时使用的名字。  
由于应用OBJECT-TYPE宏的MIB的完整的定义包含在MIB的冗长的文档中，因此，人们并不常使用它们。比较常用的是更简捷的方法―基于树型结构和对象特性的表格表示的方法。  
4) 定义表格  
SMI只支持一种数据结构化方法:标量值条目的二维表格。表格的定义用到ASN.1的sequence和sequence of两个类型和OBJECT-TYPE宏中的IndexPart。  
表格定义方法可以通过实例进行说明。考虑对象类型tcpConnTable，这个对象包含由相应的被管实体维护的TCP connections的信息。对于每个这样的connection，以下信息在表中存储:  
l state: TCP connection的状态  
l local address: 该connection的本端的IP地址  
l local port: 该connection的本端的TCP端口  
l remote address: 该connection的另一端的IP地址  
l remote port: 该connection的另一端的TCP端口  
需要注意的是，tcpConnTable是存放在某个被管系统维护的MIB中。因此，tcpConnTable中的一个条目对应被管系统中的一个connection的状态信息。TCP connection的状态信息有22个项目，按照tcpConnTable的定义，只有上述5个项目对网络管理者来说是可见的。这也体现了SNMP强调保持网络管理简单性的特点。即，在被管对象中，只包含相对应的被管实体的有限的和有用的信息。  
图4.5给出了tcpConnTable的定义(引自RFC1213)。  
图4.5 TCP connection Table  
在图4.5中，可以看到sequence 和sequence of 在定义表格时的应用:  
l 整个表由一个SEQUENCE OF TcpConnEntry构成。ASN.1的结构SEQUENCE OF由一个或多个相同的元素构成，在本例中(在所有的SNMP SMI的情况下)每个元素是表中的一行。  
l 每一行由一个指定了5个标量元素的SEQUENCE构成。ASN.1的结构SEQUCECE由固定数目的元素组成，元素的类型可以是多种。尽管ASN.1允许这些元素是可选的，但SMI限制这个结构只能使用“mandatory”元素。在本例中，每一行所包含的元素的类型是INTEGER, IpAddress, INTEGER, IpAddress, INTERGE。  
tcpConnEntry定义中的INDEX成分确定哪个对象值将被用于区分表中的各行。在TCP中，一个socket (IP地址，TCP端口)可以支持多个connection，而任意一对sockets之间同时只能有一个connection。因此为了明确地区分各行，每行中的后4个元素是必要的，也是充分的。  
4.2.2 MIB-II  
在TCP/IP网络管理的建议标准中，提出了多个相互独立的MIB，其中包含为Internet的网络管理而开发的MIB-II。鉴于它在说明标准MIB的结构、作用和定义方法等方面的重要性和代表性，有必要对其进行比较深入的讨论。  
MIB-II是在MIB-I的基础之上开发的，是MIB-I的一个超集。mib-2组被分为以下分组:  
l system:关于系统的总体信息;  
l interface:系统到子网接口的信息;  
l at (address translation):描述internet到subnet的地址映射;  
l ip:关于系统中IP的实现和运行信息;  
l icmp:关于系统中ICMP的实现和运行信息;  
l tcp:关于系统中TCP的实现和运行信息;  
l udp:关于系统中UDP的实现和运行信息;  
l egp:关于系统中EGP的实现和运行信息;  
l dot3(transmission):有关每个系统接口的传输模式和访问协议的信息。  
l snmp:关于系统中SNMP的实现和运行信息。  
1) system 组  
system组提供有关被管系统的总体信息。表4.1列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.1 system组中的对象  
Object Syntax Access Description  
sysDescr DisplayString (SIZE(0 … 255)) RO 对实体的描述，如硬件、操作系统等  
sysObjectID OBJECT IDENTIFIER RO 实体中包含的网络管理子系统的厂商标识  
sysUpTime TimeTicks RO 系统的网络管理部分本次启动以来的时间  
sysContect DisplayString (SIZE(0 … 255)) RW 该被管节点负责人的标识和联系信息  
sysName DisplayString (SIZE(0 … 255)) RW 该被管节点被赋予的名称  
sysLocation DisplayString (SIZE(0 … 255)) RW 该节点的物理地点  
sysService INERGER(0 … 127) RO 指出该节点所提供的服务的集合，7个bit对应7层服务  
  
2) interfaces 组  
interfaces组包含实体物理接口的一般信息，包括配置信息和各接口中所发生的事件的统计信息。表4.2列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.2 interfaces组中的对象  
Object Syntax Access Description  
ifNumber INTEGER RO 网络接口的数目  
ifTable SEQUENCE OF ifEntry NA 接口条目清单  
ifEntry SEQUENCE NA 包含子网及其以下层对象的接口条目  
ifIndex INTEGER RO 对应各个接口的唯一值  
ifDescr DisplayString (SIZE(0 … 255)) RO 有关接口的信息，包括厂商、产品名称、硬件接口版本  
ifType INTEGER RO 接口类型，根据物理或链路层协议区分  
ifMtu INERGER RO 接口可接收或发送的最大协议数据单元的尺寸  
ifSpeed Gauge RO 接口当前数据速率的估计值  
ifPhysAddress PhysAddress RO 网络层之下协议层的接口地址  
ifAdminStatus INTEGER RW 期望的接口状态 (up(1), down(2), testing(3))  
ifOperStatus INTEGER RO 当前的操作接口状态 (up(1), down(2), testing(3))  
ifLastChange TimeTicks RO 接口进入当前操作状态的时间  
ifInOctets Counter RO 接口收到的8元组的总数  
ifInUcastPkts Counter RO 递交到高层协议的子网单播的分组数  
ifInNUcastPkts Counter RO 递交到高层协议的非单播的分组数  
ifInDiscards Counter RO 被丢弃的进站分组数  
ifInErrors Counter RO 有错的进站分组数  
ifInUnkownProtos Counter RO 由于协议未知而被丢弃的分组数  
ifOutOctets Counter RO 接口发送的8元组的总数  
ifOutUcastPkts Counter RO 发送到子网单播地址的分组总数  
ifOutNUcastPkts Counter RO 发送到非子网单播地址的分组总数  
ifOutDiscards Counter RO 被丢弃的出站分组数  
ifOutErrors Counter RO 不能被发送的有错的分组数  
ifOutQLen Gauge RO 输出分组队列长度  
ifSpecific OBJECT IDENTIFIER RO 参考MIB对实现接口的媒体的定义  
3) address translation 组  
address translation组由一个表构成，表中的每一行对应系统中的一个物理接口，提供网络地址向物理地址的映射。一般情况下，网络地址是指系统在该接口上的IP地址，而物理地址决定于实际采用的子网情况。例如，如果接口对应的是LAN，则物理地址是接口的MAC地址，如果对应X.25分组交换网，则物理地址可能是一个X.121地址。表4.3列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.3 address translation组中的对象  
Object Syntax Access Description  
atTable SEQUENCE OF AtEntry NA 包含网络地址对物理地址的映射  
atEntry SEQUENCE NA 包含一个网络地址、物理地址对  
atIfIndex INTEGER RW 表格条目的索引  
atPhysAddress PhysAddress RW 依赖媒体的物理地址  
atNetAddress NetworkAddress RW 对应物理地址的网络地址  
实际上，address translation组包含在MIB-II中只是为了与MIB-I兼容，MIB-II的地址转换信息在各个网络协议组中提供。  
4) ip 组  
ip组包含有关节点上IP实现和操作的信息，如有关IP层流量的一些计数器。ip组中包含3个表，ipAddrTable、ipRouteTalbe和ipNetToMediaTable。  
ipAddrTable包含分配给该实体的IP地址的信息，每个地址被唯一地分配给一个物理地址。  
ipRouteTable包含用于互联网路由选择的信息。该路由表中信息是比较原本地从一些协议的路由表中抽取而来的。实体当前所知的每条路由都有一个条目，表格由ipRouteDest索引。ipRouteTable中的信息可用于配置的监测，并且由于表中的对象是read-write的，因此也可被用于路由控制。  
ipNetToMediaTable是一个提供IP地址和物理地址之间对应关系的地址转换表。除了增加一个指示映射类型的对象ipNetToMediaType之外，表中所包含的信息与address translation组相同。  
此外，ip组中还包含一些用于性能和故障监测的标量对象。  
表4.4列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.4 ip组中的对象  
Object Syntax Access Description  
ipForwarding INTEGER RW 是否作为IP网关（1/0）  
ipDefaultTTL INTEGER RW 插入到该实体生成的数据报的IP头中Time-To-Live字段中的默认值  
ipInReceives Counter RO 接口收到的输入数据报的总数  
ipInHdrErrors Counter RO 由于IP头错被丢弃的输入数据报总数  
ipInAddrErrors Counter RO 由于IP地址错被丢弃的输入数据报总数  
ipForwDatagrams Counter RO 转发的输入数据报数  
ipInUnknownProtos Counter RO 由于协议未知被丢弃的输入数据报数  
ipInDiscards Counter RO 无适当理由而被丢弃的输入数据报数  
ipInDelivers Counter RO 成功地递交给IP用户协议的输入数据报数  
ipOutRequests Counter RO 本地IP用户协议要求传输的IP数据报总数  
ipOutNoRoutes Counter RO 由于未找到路由而被丢弃的IP数据报数  
ipReasmTimeOut INTEGER RO 重组接收到的碎片可等待的最大秒数  
ipReasmReqds Counter RO 接收到的需要重组的IP碎片数  
ipReasmOKs Counter RO 成功重组的IP数据报数  
ipRaesmFails Counter RO 由IP重组算法检测到的重组失败的数目  
ipFragsOk Counter RO 成功拆分的IP数据报数  
ipFragsFails Counter RO 不能成功拆分而被丢弃的IP数据报数  
ipFragsCreates Counter RO 本实体产生的IP数据报碎片数  
ipAddrTable SEQUENCE OF IpAddrEntry NA 本实体的IP地址信息(表内对象略)  
ipRouteTable SEQUENCE OF IpRouteEntry NA IP 路由表(表内对象略)  
ipNetToMediaTable SEQUENCE OF IpNetToMedis Entry NA 用于将IP 映射到物理地址的地址转换表(表内对象略)  
IpRouting Discards Counter RO 被丢弃的路由选择条目  
  
5) icmp 组  
ICMP (Internet Control Message Protocol)是TCP/IP协议族中的一部分，所有实现IP协议的系统都提供ICMP。ICMP提供从路由器或其他主机向主机传递消息的手段，它的基本作用是反馈通信环境中存在的问题，例如:数据报不能到达目的地，路由器没有缓冲区容量来转发数据报。  
icmp组包含有关一个节点的ICMP的实现和操作的信息，具体地讲，icmp组由节点接收和发送的各种ICMP消息的计数器所构成由一个表构成。表4.5列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.5 icmp组中的对象  
Object Syntax Access Description  
icmpInMsgs Counter RO 收到的ICMP消息的总数  
icmpInErrors Counter RO 收到的有错的ICMP的消息数  
icmpInDestUnreachs Counter RO 收到的目的地不可到达的消息数  
icmpInTimeExcds Counter RO 收到的超时的消息数  
icmpInParmProbs Counter RO 收到的有参数问题的消息数  
icmpInSrcQuenchs Counter RO 收到的源有问题的消息数  
icmpInRedirects Counter RO 收到的重定向的消息数  
icmpInEchos Counter RO 收到的要求echo的消息数  
icmpInEchoReps Counter RO 收到的应答echo的消息数  
icmpInTimestamps Counter RO 收到的要求Timestamp的消息数  
icmpInTimestampReps Counter RO 收到的应答Timestamp的消息数  
icmpInAddrMasks Counter RO 收到的要求Address Mask的消息数  
icmpInAddrMaskReps Counter RO 收到的应答Address Mask的消息数  
icmpOutMsgs Counter RO 发出的ICMP消息的总数  
icmpOutErrors Counter RO 发出的有错的ICMP的消息数  
icmpOutDestUnreachs Counter RO 发出的目的地不可到达的消息数  
icmpOutTimeExcds Counter RO 发出的超时的消息数  
icmpOutParmProbs Counter RO 发出的有参数问题的消息数  
icmpOutSrcQuenchs Counter RO 发出的源有问题的消息数  
icmpOutRedirects Counter RO 发出的重定向的消息数  
icmpOutEchos Counter RO 发出的要求echo的消息数  
icmpOutEchoReps Counter RO 发出的应答echo的消息数  
icmpOutTimestamps Counter RO 发出的要求Timestamp的消息数  
icmpOutTimestampReps Counter RO 发出的应答Timestamp的消息数  
icmpOutAddrMasks Counter RO 发出的要求Address Mask的消息数  
icmpOutAddrMaskReps Counter RO 发出的应答Address Mask的消息数  
  
6) tcp 组  
tcp组包含有关一个节点的TCP的实现和操作的信息，图4.5定义的tcpConnTable包含在这个组中。表4.6列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.6 tcp组中的对象  
Object Syntax Access Description  
tcpRtoAlgorithm INTEGER RO 重传时间  
tcpRtoMin INTEGER RO 重传时间的最小值  
tcpRtoMax INTEGER RO 重传时间的最大值  
tcpMaxConn INTEGER RO 实体支持的TCP连接数的上限  
tcpActiveOpens Counter RO 实体已经支持的主动打开的数量  
tcpPassiveOpens Counter RO 实体已经支持的被动打开的数量  
tcpAttemptFails Counter RO 已经发生的试连失败的次数  
tcpEstabResets Counter RO 已经发生的复位的次数  
tcpCurrEstab Gauge RO 当前状态为established的TCP连接数  
tcpInSegs Counter RO 收到的segments总数  
tcpOutSegs Counter RO 发出的segments总数  
tcpRetranSegs Counter RO 重传的segments总数  
tcpConnTable SEQUENCE OF TcpConnTntry NA 包含TCP各个连接的信息(表内对象略，参考图4.5)  
tcpInErrors Counter RO 收到的有错的segments的总数  
tcpOutRsts Counter RO 发出的含有RST标志的segments数  
  
7) udp 组  
udp组包含有关一个节点的UDP的实现和操作的信息。除了有关发送和接收的数据报的信息之外，这个组中还包含一个udpTable表，该表中包含UDP端点的管理信息。所谓UDP端点是指正在支持本地应用接收数据报的UDP进程。udpTable表中包含每个UDP端点用户的IP地址和UDP端口。表4.7列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.7 udp组中的对象  
Object Syntax Access Description  
udpInDatagrams Counter RO 递交该UDP用户的数据报的总数  
udpNoPorts Counter RO 收到的目的端口上没有应用的数据报总数  
udpInErrors Counter RO 收到的无法递交的数据报数  
udpOutDatagrams Counter RO 该实体发出的UDP数据报总数  
udpTable SEQUENCE OF UdpEntry NA 包含UDP的用户信息  
udpTable SEQUENCE NA 某个当前UDP用户的信息  
udpLocalAddress IpAddress RO UDP用户的本地IP地址  
udpLocalPort INTEGER RO UDP用户的本地端口号  
  
8) egp 组  
egp组包含有关一个节点的EGP(External Gateway Protocol)的实现和操作的信息。除了有关发送和接收的EGP消息的信息之外，这个组中还包含一个egpNeighTable表，该表中包含有关相邻网关的信息。表4.8列出了该组中各个对象的名称、句法、访问权限和对象描述。  
表4.8 egp组中的对象  
Object Syntax Access Description  
egpInMsgs Counter RO 收到的无错的EGP消息数  
egpInErrors Counter RO 收到的有错的EGP消息数  
egpOutMsgs Counter RO 本地产生的EGP消息总数  
egpOutErrors Counter RO 由于资源限制没有发出的本地产生的EGP消息数  
egpNeighTable SEQUENCE OF EgpNeighEntry NA 相邻网关的EGP表(表内的对象略)  
egpAs INTEGER RO 本EGP实体的自治系统数  
  
4.3 简单网络管理协议(SNMP)  
4.3.1 SNMP支持的操作  
SNMP只支持对变量的检查和修改的操作，具体地，可以对标量对象进行以下三种操作：  
l Get：管理站从被管理站提取标量对象值。  
l Set：管理站更新被管理站中的标量对象值。  
l Trap：被管理站向管理站主动地发送一个标量对象值。  
MIB的结构不能通过增加或减少对象实例被改变，并且，访问只能对对象标识树中的叶子对象进行。这些限制大大简化了SNMP的实现，但同时也限制了网络管理系统的能力。  
4.3.2 共同体和安全控制  
网络管理是一种分布式的应用。与其他分布式的应用相同，网络管理中包含由一个应用协议支持的多个应用实体的相互作用。在SNMP网络管理中，这些应用实体就是采用SNMP的管理站应用实体和被管理站的应用实体。  
SNMP网络管理具有一些不同于其他分布式应用的特性，它包含一个管理站和多个被管理站之间一对多的关系。即，管理站能够获取和设置各管理站的对象，能够从各被管理站中接收陷阱信息。因此，从操作或控制的角度来看，管理站管理着多个被管理站。同时，系统中也可能有多个管理站，每个管理站都管理所有的或一部分被管理站。  
反过来，我们也要看到SNMP网络管理中还包含另外一种一对多的关系―一个被管理站和多个管理站之间的关系。每个被管理站控制着自己的本地MIB，同时必须能够控制多个管理站对这个本地MIB的访问。这里所说的控制有以下三个方面:  
l 认证服务:将对MIB的访问限定在授权的管理站的范围内;  
l 访问策略:对不同的管理站给予不同的访问权限;  
l 代管服务:一个被管理站可以作为其他一些被管理站(托管站)的代管，这就要求在这个代管系统中实现为托管站服务的认证服务和访问权限。  
以上这些控制都是为了保证网络管理信息的安全，即被管系统需要保护它们的MIB不被非法地访问。SNMP通过共同体(community)的概念提供了初步的和有限的安全能力。  
SNMP用共同体来定义一个代理者和一组管理者之间的认证、访问控制和代管的关系。共同体是一个在被管系统中定义的本地的概念。被管系统为每组可选的认证、访问控制和代管特性建立一个共同体。每个共同体被赋予一个在被管系统内部唯一的共同体名，该共同体名要提供给共同体内的所有的管理站，以便它们在get和set操作中应用。代理者可以与多个管理站建立多个共同体，同一个管理站可以出现在不同的共同体中。  
由于共同体是在代理者处本地定义的，因此不同的代理者处可能会定义相同的共同体名。共同体名相同并不意味者共同体有什么相似之处，因此，管理站必须将共同体名与代理者联系起来加以应用。  
认证服务  
认证服务是为了保证通信是可信的。在SNMP消息的情况下，认证服务的功能是保证收到的消息是来自它所声称的消息源。SNMP只提供一种简单的认证模式:所有由管理站发向代理者的消息都包含一个共同体名，这个名字发挥口令的作用。如果发送者知道这个口令，则认为消息是可信的。  
通过这种有限的认证形式，网络管理者可以对网络监控(set、trap)特别是网络控制(set)操作进行限制。共同体名被用于引发一个认证过程，而认证过程可以包含加密和解密以实现更安全的认证。  
访问策略  
通过定义共同体，代理者将对它的MIB的访问限定在了一组被选择的管理站中。通过使用多个共同体，代理者可以为不同的管理站提供不同的MIB访问控制。访问控制包含两个方面:  
l SNMP MIB 视图:MIB中对象的一个子集。可以为每个共同体定义不同的MIB视图。视图中的对象子集可以不在MIB的一个子树之内。  
l SNMP 访问模式:READ-ONLY 或 READ-WRITE。为每个共同体定义一个访问模式。  
MIB视图和访问模式的结合被称为SNMP共同体轮廓(profile)。即，一个共同体轮廓由代理者处MIB的一个子集加上一个访问模式构成。SNMP访问模式统一地被用于MIB视图中的所有对象。因此，如果选择了READ-ONLY访问模式，则管理站对视图中的所有对象都只能进行read-only操作。  
事实上，在一个共同体轮廓之内，存在两个独立的访问限制―MIB对象定义中的访问限制和SNMP访问模式。这两个访问限制在实际应用中必须得到协调。表4.9给出了这两个访问限制的协调规则。注意，对象被定义为write-only，SNMP也可以对其进行read操作。  
  
表4.9 MIB对象定义中的ACCESS限制与SNMP访问模式的关系  
MIB对象定义中的ACCESS限制 SNMP访问模式  
READ-ONLY READ-WRITE  
read-only get和trap操作有效  
read-write get和trap操作有效 get，set和trap操作有效  
Write-only get和trap操作有效，但操作值与具体实现有关 get，set和trap操作有效，但操作值与具体实现有关  
not-accessible 无效  
  
在实际应用中，一个共同体轮廓要与代理者定义的某个共同体联系起来，便构成了SNMP的访问策略(access policy)。即SNMP的访问策略指出一个共同体中的MIB视图及其访问模式。  
代管服务  
共同体的概念对支持代管服务也是有用的。如前所述，在SNMP中，代管是指为其他设备提供管理通信服务的代理者。对于每个托管设备，代管系统维护一个对它的访问策略，以此使代管系统知道哪些MIB对象可以被用于管理托管设备和能够用何种模式对它们进行访问。  
  
4.3.3 实例标识  
我们已经看到，MIB中的每个对象都有一个由其在树型结构的MIB中所处的位置所定义的唯一的对象标识符。但是，应该注意到，MIB树型结构给出的对象标识符在一些情况下只是对象类型的标识符，不能唯一地标识对象的实例。例如表格的对象标识符不能标识表格中各个条目。由于对MIB的访问是对对象实例的访问，因此各个对象实例都必须有唯一标识的方法。  
纵列对象  
表中的对象被称为纵列对象。纵列对象标识符不能独自标识对象实例，因为表中的每一行都有纵列对象的一个实例。为了实现这类对象实例的唯一标识，SNMP实际定义了两种技术:顺序访问技术和随机访问技术。顺序访问技术是通过利用辞典编排顺序实现的。而随机访问技术是通过利用索引对象值实现的。下面首先讨论随机访问技术。  
一个表格是由零到多个行(条目)构成的，每一行都包含一组相同的标量对象类型，或称纵列对象。每个纵列对象都有一个唯一的标识符。但由于纵列对象可能有多个实例，因此纵列对象标识符并不能唯一标识它的各个实例。然而，在定义表格时，一般包含一个特殊的纵列对象INDEX，即索引对象，它的每个实例都具有不同的值，可以用来标识表中的各行。因此，SNMP采用将索引对象值连接在纵列对象标识符之后的方法来标识纵列对象的实例。  
作为例子，我们看一下interfaces组中的ifTable。表中有一个索引对象ifIndex，它的值是一个1到ifNumber之间的整数，对应每个接口，ifIndex有一个唯一的值。现在假设要获取系统中第2个接口的接口类型ifType。ifType的对象标识符是1.3.6.1.2.1.2.2.1.3。而第2个接口的ifIndex值是2。因此对应第2个接口的ifType的实例的标识符便为1.3.6.1.2.1.2.2.1.3.2。即将这个ifIndex的值作为实例标识符的最后一个子标识符加到ifType对象标识符之后。  
表格及行对象  
对于表格和行对象，没有定义它们的实例标识符。这是因为表格和行不是叶子对象，因而不能由SNMP访问。在这些对象的MIB定义中，它们的ACCESS特性被设为not-accessible。  
标量对象  
在标量对象的场合，用对象类型标识符便能唯一标识它的实例，因为每个标量对象类型只有一个对象实例。但是，为了与表格对象实例标识符的约定保持一致，也为了区分对象的类型和对象实例，SNMP规定标量对象实例的标识符由其对象类型标识符加0组成。  
  
4.3.4 辞典编纂式排序  
对象标识符是反映该对象在MIB中的树型结构的一个整数序列。给出一个MIB的树型结构，跟踪从root开始到某个特定对象的路径，便可以得到该对象的对象标识符。  
由于对象标识符是一个整数序列，因此，可以把它们看作是某本书的内容在书中的章节排序。总排序可以通过遍历MIB中的对象标识符树来生成。利用这个总排序，也可以对对象实例进行唯一的标识。  
因为网络管理站对代理者提供MIB视图的构成不一定完全清楚，因此，它需要一种不必提供对象名称而能访问对象的方法。在这种情况下，对象及其实例的排序就是非常重要的。利用这个排序，管理站可以有效地遍历一个MIB的结构。因为管理站只要提供树型结构的任意一点上的一个对象实例的标识符，就可以顺序地对其后继的对象实例进行访问。  
  
4.3.5 SNMP消息格式  
管理站和代理者之间以传送SNMP消息的形式交换信息。每个消息包含一个指示SNMP版本号的版本号，一个用于本次交换的共同体名，和一个指出5种协议数据单元之一的消息类型。图4.6描述了这种结构。表4.10对其中的元素进行了说明。  
  
(a) GetRequest PDU, GetNextRequest PDU, SetRequest PDU  
  
(b) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU  
  
(c) Response PDU  
  
(d) Trap PDU  
  
(e) Variable-bindings  
图4.6 SNMP消息格式  
  
表4.10 SNMP消息字段  
字 段 描 述  
version SNMP版本  
community 共同体的名字用作SNMP认证消息的口令  
request-id 为每个请求赋予一个唯一的标识符  
error-status noError(0),tooBig(1),noSuchName(2),badValue(3),readOnly(4),genErr(5)  
error-index 当error-status非0时，可以进一步提供信息指出哪个变量引起的问题  
variable-bindings 变量名及其对应值清单  
enterprise 生成trap的对象的类型  
agent-addr 生成trap的对象的地址  
generic-trap 一般的trap类型:coldStart(0),warmStart(1),linkDown(2),linkUp(3), authentication-Failure(4),egpNeighborLoss(5),enterprise-Specific(6)  
secific-triap 特定的Trap代码  
time-stamp 网络实体从上次启动到本trap生成所经历的时间  
  
SNMP消息的发送  
一般情况下，一个SNMP协议实体完成以下动作向其他SNMP实体发送PDU:  
l 构成PDU。  
l 将构成的PDU、源和目的传送地址以及一个共同体名传给认证服务。认证服务完成所要求的变换，例如进行加密或加入认证码，然后将结果返回。  
l SNMP协议实体将版本字段、共同体名以及上一步的结果组合成为一个消息。  
l 用基本编码规则(BER)对这个新的ASN.1的对象编码，然后传给传输服务。  
SNMP消息的接收  
一般情况下，一个SNMP协议实体完成以下动作接收一个SNMP消息  
l 进行消息的基本句法检查，丢弃非法消息  
l 检查版本号，丢弃版本号不匹配的消息  
l SNMP协议实体将用户名、消息的PDU部分以及源和目的传输地址传给认证服务。如果认证失败，认证服务通知SNMP协议实体，由它产生一个trap并丢弃这个消息;如果认证成功，认证服务返回SNMP格式的PDU。  
l 协议实体进行PDU的基本句法检查，如果非法，丢弃该PDU，否则利用共同体名选择对应的SNMP访问策略，对PDU进行相应处理。  
变量绑定  
在SNMP中，可以将多个同类操作(get、set、trap)放在一个消息中。如果管理站希望得到一个代理者处的一组标量对象的值，它可以发送一个消息请求所有的值，并通过获取一个应答得到所有的值。这样可以大大减少网络管理的通信负担。  
为了实现多对象交换，所有的SNMP的PDU都包含了一个变量绑定字段。这个字段由对象实例的一个参考序列及这些对象的值构成。某些PDU只需给出对象实例的名字，如get操作。对于这样的PDU，接收协议实体将忽略变量绑定字段中的值。  
  
4.3.6 GetRequest PDU  
SNMP实体应网络管理站应用程序的请求发出GetRequest PDU。发送实体将以下字段包含在PDU之中:  
l PDU类型:指出GetRequest PDU类型。  
l request-id:Request-id能够使SNMP应用将得到的各个应答与发出的各个请求一一对应起来。同时也可以使SNMP实体能够处理由于传输服务的问题而产生的重复的PDU。  
l variablebindings:要求获取值的对象实例清单。  
GetRequest PDU 的SNMP接收实体用包含相同request-id的GetResponse PDU进行应答。GetRequest操作是原子操作―要么所有的值都提取回来，要么一个都不提取。  
GetRequst 操作不成功的原因有对象名不匹配(noSuchName)、返回结果太长(tooBig)以及其他原因(genErr)。  
SNMP只允许提取MIB树中的叶子对象的值。因此不能只提供一个表或一个条目的名字来获取整个表或整行的对象值。但是可以将表中每行的各个对象包含在变量绑定中，来一次获取一行的对象值。  
4.3.7 GetNextRequest PDU  
GetNextRequest PDU几乎与GetRequest PDU相同。它们具有相同交换模式和相同的格式。唯一的不同是:在GetRequest PDU中，变量绑定字段中列出的是要取值的对象实例名本身，而在GetNextRequest PDU中，变量绑定字段列出的是要取值的对象实例的“前一个”对象实例名。与GetRequest相同，GetNextRequest也是原子操作。  
虽然与GetRequest的外在差异不大，但是GetNextRequest却有GetRequest无法替代的用途。它能够使网络管理站去动态地发现一个MIB视图的结构。它也为查找不知其条目的表提供了一个有效的机制。  
简单对象值的提取  
假设网络管理站希望从某个代理者处提取udp组中的所有简单对象，则它可以发出一个如下的PDU:  
GetRequest(udpInDatagrams.0，udpNoPorts.0,udpInError.0,udpOutDatagrams.0)  
如果代理者支持所有这些对象，则将返回一个包含这4个对象值的GetResponse PDU:  
GetResponse((udpInDatagrams.0 = 100), (udpNoPorts.0 = 1), (udpInErrors.0 = 2),  
(udpOutDatagrams.0 = 200))  
这里，100，1，2和200分别是这4个对象的值。然而，只要有一个对象不被支持，则代理者将返回一个含有错误码NoSuchName的GetResponse PDU，而不返回任何其他值。为了确保得到所有可用的对象值，管理站必须分别发出4个GetRequest PDU。  
现在考虑应用GetNextRequest PDU的情况:  
GetNextRequest (udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams)  
其中，udpInDatagrams = 1.3.6.1.2.1.7.1, udpNoPorts = 1.3.6.1.2.1.7.2, udpInErrors = 1.3.6.1.2.1.7.3, udpOutDatagrams = 1.3.6.1.2.1.7.4。  
在这种情况下，代理者将返回清单中每个标识符的“下一个”对象实例的值。假设4个对象都被支持，则代理者返回一个如下的GetResponse PDU:  
GetResponse((udpInDatagrams.0 = 100), (udpNoPorts.0 = 1), (udpInErrors.0 = 2),  
(udpOutDatagrams.0 = 200))  
这与前面的情况相同。假设udpNoPorts在本视图中是不存在(不可见)的，则代理者的应答为:  
GetResponse((udpInDatagrams.0 = 100), (udpInErrors.0 = 2), (udpInErrors.0 = 2),  
(udpOutDatagrams.0 = 200))  
由于udpNoPorts.0 = 1.3.6.1.2.1.7.2.0在本MIB视图中是不存在的标识符，因此udpNoPorts的“下一个”对象实例便成了udpInError.0 = 1.3.6.1.2.1.7.3.0。  
通过对比可知，GetNextRequest在提取一组对象值时比GetRequest效率更高，更灵活。  
提取未知对象  
GetNextRequest要求代理者提取所提供的对象标识符的下一个对象实例的值，因此，发送这类PDU时，并不要求提供MIB视图中实际存在的对象或对象实例的标识符。利用这一特点，管理站可以使用GetNextRequest PDU去探查一个MIB视图，并搞清它的结构。在我们上面的例子中，如果管理站发出一个GetNextRequest(udp) PDU，则将获得 Response(udpInDatagrams.0 = 100) 的应答。管理站因此便知道了在这个MIB视图中第一个被支持的对象是udpInDatagrams，并且知道了它的当前值。  
4.3.8 SetRequest PDU  
SNMP实体应网络管理站应用程序的请求发出SetRequest PDU。它与GetRequest PDU具有相同的交换模式和相同的格式。但是，SetRequest 是被用于写对象值而不是读。因而，变量绑定清单中既包含对象实例标识符，也包含每个对象实例将被赋予的值。  
SetRequest PDU 的SNMP接收实体用包含相同request-id的GetResponse PDU进行应答。SetRequest操作是原子操作―要么变量绑定中的所有变量都被更新，要么一个都不被更新。如果应答实体能够更新变量绑定中的所有变量，则GetResponse PDU中包含提供给各个变量的值的变量绑定字段。只要有一个变量值不能成功地设置，则无变量值返回，也无变量值被更新。在GetRequest操作中可能返回的错误―noSuchName、tooBig和genErr也是SetRequest可能返回的错误。另外一个可能返回的错误是badValue，只要SetRequest中有一个变量名和变量值不一致的问题，就会返回这个错误。所谓不一致可能是类型的问题，也可能是长度的问题，还可能是提供的实际的值有问题。  
利用SetRequest不仅可以对叶子对象实例进行值的更新，也可以利用变量绑定字段进行表格的行增加和行删除操作。  
除此之外，SetRequest还可被用于完成某种动作。SNMP没有提供一种命令代理者完成某种动作的机制，它的全部能力就是在一个MIB视图内get和set对象值。但是利用set的功能可以间接地发布完成某种动作的命令。某个对象可以代表某个命令，当它被设置为特定值时，就执行特定的动作。例如代理者可以设一个初始值为0的对象reBoot，如果管理站将这个对象值置1，则代理者系统被重新启动，reBoot的值也被重新置0。  
4.3.9 Trap PDU  
SNMP实体应网络管理代理者应用程序的请求发出Trap PDU。它被用于向管理站异步地通报某个重要事件。它的格式与其他的SNMP PDU完全不同。所包含的字段有:  
l PDU类型:指出Trap PDU类型  
l enterprise:标识产生本Trap的网络管理子系统(用System组中的sysObjectId值)  
l agent-addr:产生本Trap的对象的IP地址  
l generic-trap:一种预定义的trap  
l specific-trap:更明确地指出trap特性的代码  
l time-stamp:发出trap的网络实体从上次重启到产生本trap所经历的时间  
l variablebindings:有关trap的附加信息(本字段的意义有具体实现有关)  
4.3.10 传输层的支持  
SNMP需要利用传输层的服务来传递SNMP消息，但是它并未假定传输层的服务是可靠的还是非可靠的，是无连接的还是面向连接的。  
但是实际上，在TCP/IP体系中，SNMP的实现几乎都是使用无连接协议用户数据报(UDP)。UDP头中包含源和目的端口字段，允许应用层协议，如SNMP填写地址。它还包含一个可选的覆盖UDP头和用户数据的校验和(checksum)。如果校验和有问题，UDP片段(segment)被丢弃。两个端口号给SNMP应用，用于代理者侦听GetRequest, GetNextRequest和SetRequest命令的161端口和用于管理站侦听Trap命令的162端口。  
由于UDP是非可靠的，因此SNMP的消息可能被丢失。SNMP本身也不保证消息的可靠传递，因此，处理消息丢失问题的负担只能由SNMP的用户自己承担。  
如何处理SNMP消息的丢失没有标准的方法，只能凭通常的感觉处理。在GetRequest和GetNextRequest的场合，如果在规定的时间内得不到应答，管理站可以认为或者是发出的命令消息被丢失，或者是代理者返回的应答被丢失。管理站可以再次或多次重发请求，直至成功或最终放弃。由于相同的请求具有相同的request-id，因此重发可能会使接收者收到多个相同的消息，但这并不会引起问题，因为接收者可以简单地将收到的重复的消息丢弃。  
在SetRequest的场合，如果在规定的时间内得不到应答，为了确认操作是否成功，可以用GetRequest操作进行确认。如果确认set操作没被执行，可以重发SetRequest。  
由于SNMP的Trap没有应答消息，因此没有简单的方法去检验Trap的传递。在SNMP中，Trap一般用于提供重要事件的早期告警，作为后备方法，管理站还要定期地轮询代理者获取相关的状态。  
  
4.4 SNMPv2  
4.4.1 SNMPv2对SNMPv1的改进  
1993年，SNMP的改进版SNMPv2开始发布，从此，原来的SNMP便被称为SNMPv1。最初的SNMPv2最大的特色是增加了安全特性，因此被称为安全版SNMPv2。但不幸的是，经过几年试用，没有得到厂商和用户的积极响应，并且也发现自身还存在一些严重缺陷。因此，在1996正式发布的SNMPv2中，安全特性被删除。这样，SNMPv2对SNMPv1的改进程度便受到了很大的削弱。  
总的来说，SNMPv2的改进主要有以下3个方面：  
l 支持分布式管理；  
l 改进了管理信息结构；  
l 增强了管理信息通信协议的能力。  
SNMPv1采用的是集中式网络管理模式。网络管理站的角色由一个主机担当。其他设备(包括代理者软件和MIB)都由管理站监控。随着网络规模和业务负荷的增加，这种集中式的系统已经不再适应需要。管理站的负担太重，并且来自各个代理者的报告在网上产生大量的业务量。而SNMPv2不仅可以采用集中式的模式，也可以采用分布式模式。在分布式模式下，可以有多个顶层管理站，被称为管理服务器。每个管理服务器可以直接管理代理者。同时，管理服务器也可以委托中间管理者担当管理者角色监控一部分代理者。对于管理服务器，中间管理器又以代理者的身份提供信息和接受控制。这种体系结构分散了处理负担，减小了网络的业务量。  
SNMPv2的管理信息结构（SMI）在几个方面对SNMPv1的SMI进行了扩充。定义对象的宏中包含了一些新的数据类型。最引人注目的变化是提供了对表中的行进行删除或建立操作的规范。新定义的SNMPv2 MIB包含有关SNMPv2协议操作的基本流量信息和有关SNMPv2管理者和代理者的配置信息。  
在通信协议操作方面，最引人注目的变化是增加了两个新的PDU―GetBulkRequest 和 InformRequest。前者使管理者能够有效地提取大块的数据，后者使管理者能够向其他管理者发送trap信息。  
4.4.2 SNMPv2网络管理框架  
　　SNMPv2提供了一个建立网络管理系统的框架。但网络管理应用，如故障管理、性能监测、计费等不包括在SNMPv2的范围内。用术语来说，SNMPv2提供的是网络管理基础结构。图4.7是这种基础结构的一个配置例。  
　　SNMPv2本质上是一个交换管理信息的协议。网络管理系统中的每个角色都维护一个与网络管理有关的MIB。SNMPv2的SMI对这些MIB的信息结构和数据类型进行定义。SNMPv2提供了一些一般的通用的MIB，厂商或用户也可以定义自己私有的MIB。  
　　在配置中至少有一个系统负责整个网络的管理。这个系统就是网络管理应用驻留的地方。管理站可以设置多个，以便提供冗余或分担大网络的管理责任。其他系统担任代理者角色。代理者收集本地信息并保存，以备管理者提取。这些信息包括系统自身的数据，也可以包括网络的业务量信息。  
　　SNMPv2既支持高度集中化的网络管理模式，也支持分布式的网络管理模式。在分布式模式下，一些系统担任管理者和代理者两种角色，这种系统被称为中间管理者。中间管理者以代理者身份从上级管理系统接受管理信息操作命令，如果这些命令所涉及的管理信息在本地MIB中，则中间管理者便以代理者身份进行操作并进行应答，如果所涉及的管理信息在中间管理者的下属代理者的MIB中，则中间管理者先以管理者身份对下属代理者进行发布操作命令，接收应答，然后再以代理者身份向上级管理者应答。  
　　所有这些信息交换都利用SNMPv2通信协议实现。与SNMPv1相同，SNMPv2协议仍是一个简单的请求(request)/应答(response)型协议，但在PDU种类和协议功能方面对SNMPv1进行了扩充。  
  
图4.7 SNMPv2的配置  
  
4.4.3 协议操作  
  
SNMPv2消息  
与SNMPv1相同，SNMPv2以包含协议数据单元(PDU)的消息的形式交换信息。外部的消息结构中包含一个用于认证的共同体名。  
SNMPv2确定的消息结构如下:  
Message :: = SEQUENCE \{  
version INTEGER \{ version (1) \}, -- SNMPv2的版本号为1  
community OCTET STRING, -- 共同体名  
data ANY -- SNMPv2 PDU  
\}  
4.3.2节中对于共同体名、共同体轮廓和访问策略的讨论同样适用于SNMPv2。  
SNMPv2消息的发送和接收过程与4.3.5节中描述的SNMPv1消息的发送和接收过程相同。  
  
PDU格式  
表4.11 SNMP协议数据单元(PDUs)  
PDU 描　　述 SNMPv1 SNMPv2  
GetGetNextGetBulkSetTrapInformResponse 管理者通过代理者获得每个对象的值管理者通过代理者获得每个对象的下一个值管理者通过代理者获得每个对象的N个值管理者通过代理者为每个对象设置值代理者向管理者传送随机信息管理者向代理者传送随机信息代理者对管理者的请求进行应答 ○○○○○ ○○○○○○○  
  
　　在SNMPv2消息中可以传送7类PDU。表4.11列出了这些PDU，同时指出了对SNMPv1也有效的PDU。图4.8 描述了SNMPv2 PDU的一般格式。  
  
(a) GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU,  
SNMPv2-Trap-PDU,InformRequest-PDU  
  
(b) Response-PDU  
  
(c) GetBulkRequest-PDU  
  
(d) Variable-bindings  
图4.8 SNMPv2 PDU格式  
值得注意的是，GetRequest、GetNextRequest、SetRequest、SNMPv2-Trap、InformReques 5种PDU具有完全相同的格式，并且与也可以看作是error-status和error-index两个字段被置零的Response PDU的格式。这样设计的目的是为了减少SNMPv2实体需要处理的PDU格式种类。  
  
GetRequest PDU  
SNMPv2的GetRequest PDU的语法和语义都与SNMPv1的GetRequest PDU相同，差别是对应答的处理。SNMPv1的GetRequest是原子操作:要么所有的值都返回，要么一个也不返回，而SNMPv2能够部分地对GetRequest操作进行应答。即使有些变量值提供不出来，变量绑定字段也要包含在应答的GetResponse PDU之中。如果某个变量有意外情况(noSuchObject, noSuchInstance,endOfMibView)，则在变量绑定字段中，这个变量名与一个代表意外情况的错误代码而不是变量值配对。  
在SNMPv2中，按照以下规则处理GetRequest变量绑定字段中的每个变量来构造应答PDU:  
l 如果OBJECT IDENTIFIER前缀与该请求在代理者处所能访问的变量的前缀都不匹配，则它的值字段被设置为noSuchObject;  
l 否则，如果变量名与该请求在代理者处所能访问的变量的名称都不匹配，则它的值字段被设置为noSuchInstance;  
l 否则，值字段被设置为变量值。  
如果由于其他原因导致变量名处理过程的失败，则无法返回变量值。这时，应答实体将返回一个error-status字段值为genErr，并在error-index字段中指出出问题的变量的应答PDU。  
如果生成的应答PDU中的消息尺寸过大，超过了指定的最大限度，则生成的PDU被丢弃，并用一个error-status字段值为tooBig，error-index字段值为0，变量绑定字段为空的新的PDU应答。  
允许部分应答是对GetRequest的重要改进。在SNMPv1中，只要有一个变量值取不回来，所有的变量值就都不能返回。在这种情况下，发出操作请求的管理者往往只能将命令拆分为多条只取单个变量值的命令。相比之下，SNMPv2的操作效率得到了很大提高。  
GetNextRequest PDU  
SNMPv2的GetNextRequest PDU的语法和语义都与SNMPv1的GetNextRequest PDU相同。与GetRequestPDU相同，两个版本的差别是对应答的处理。SNMPv1的GetNextRequest是原子操作:要么所有的值都返回，要么一个也不返回，而SNMPv2能够部分地对GetNextRequest操作进行应答。  
在SNMPv2中，按照以下规则处理GetNextRequest变量绑定字段中的每个变量来构造应答PDU:  
l 确定被指名的变量下一个变量，将该变量名和它的值成对地放入结果变量绑定字段中;  
l 如果被指定的变量之后不存在变量，则将被指定的变量名和错误代码endOfMibView成对地放入结果变量绑定字段中。  
如果由于其他原因导致变量名处理过程的失败，或者是产生的结果太大，处理过程与GetRequest相同。  
GetBulkRequest  
　　SNMPv2的一个主要改进是GetBulkRequest PDU。这个PDU的目的是尽量减少查询大量管理信息时所进行的协议交换次数。GetBulkRequest PDU允许SNMPv2管理者请求得到在给定的条件下尽可能大的应答。  
　　GetBulkRequest操作利用与GetNextRequest相同的选择原则，即总是顺序选择下一个对象。不同的是，利用GetBulkRequest，可以选择多个后继对象。  
　　GetBulkRequest操作的基本工作过程如下：GetBulkRequest在变量绑定字段中放入一个(N+R)个变量名的清单。对于前N个变量名，查询方式与GetNextRequest相同。即，对清单中的每个变量名，返回它的下一个变量名和它的值，如果没有后继变量，则返回原变量名和一个endOfMibView的值。  
　　GetBulkRequest PDU有两个其他PDU所没有的字段，non-repeaters和max-repetitions。  
non-repeaters字段指出只返回一个后继变量的变量数。max-repetitions字段指出其他的变量应返回的最大的后继变量数。为了说明算法，我们定义：  
L = 变量绑定字段中的变量名数量  
N = 只返回一个后继变量的变量名数  
R = 返回多个后继变量的变量名数  
M = 最大返回的后继变量数  
　　在上述变量之间存在以下关系：  
N = MAX \[MIN(non-reperters, L)，0\]  
M = MAX \[max-repetitions,0\]  
R = L - N  
　　如果N大于0，则前N个变量与GetNextRequest一样被应答。如果R大于0并且M大于0，则对应后面的R个变量，返回M个后继变量。即，对于每个变量：  
・获得给定变量的后继变量的值；  
・获得下一个后继变量的值；  
・反复执行上一步，直至获得M个对象实例。  
　　如果在上面的过程中的某一点，已经没有后继变量，则返回endOfMibView值，在变量名处，返回最后一个后继变量，如果没有后继变量，则返回请求中的变量名。  
　　利用这个规则，能够产生的name-value对的数量是N+(M×R)。后面的(M×R)对在应答PDU中的顺序可描述为：  
for i : = 1 to M do  
for r : = 1 to R do  
retrieve i-th successor of (N+r)-th variable  
　　即，返回的后继变量是一行一行的，而不是先返回第一个变量的所有后继变量，再返回第二个变量的所有后继变量，等等。  
GetBulkRequest操作解除了SNMP的一个主要限制，即不能有效地检索大块数据。此外，利用这个功能可以减小管理应用程序的规模。管理应用程序自身不需要关心组装在一起的请求的细节。不需要执行一个试验过程来确认请求PDU中的name-value对的最佳数量。并且，即使GetBulkRequest发出的请求过大，代理者也会尽量多地返回数据不是简单地返回一个tooBig的错误消息。为了获得缺少的数据，管理者只需简单地重发请求，而不必将原来的请求改装为小的请求序列。  
SetRequest  
SetRequest PDU由管理者发出，用来请求改变一个或多个对象的值。接收实体用一个包含相同request-id的Response PDU应答。与SNMPv1相同，SetRequest操作是原子操作，即或者更新所有被指名的变量，或者所有的都不更新。如果接收实体能够为被指名的所有变量设置新值，则Response PDU返回与SetRequest相同的变量绑定字段。只要有一个变量值没设置成功，就不更新任何值。  
SetRequest的变量绑定分两个阶段处理。在第一阶段，确认每个绑定对。如果所有的绑定对都被确认，则进入第二阶段―改变每个变量。即每个变量的set操作都在第二阶段进行。  
在第一阶段中，对每个绑定对进行以下确认，直至所有的都成功或遇到一个失败。失败的原因有:不可访问(noAccess)、无法建立或修改(notWritable)、数据类型不一致(wrongType)、长度不一致(wrongLength)、ASN.1编码不一致、变量值有问题(wrongValue)、变量不存在且无法建立(noCreation)等。如果任意一个变量遇到以上情况，则返回一个在error-status字段给出上述错误代码，在error-index字段给出有问题的变量的序号的应答PDU。与SNMPv1相比，提供了更多的错误代码。为管理站更容易地确定失败的原因提供了方便。  
如果在确认阶段没有遇到问题，则进入第二阶段―更新在变量绑定字段中被指名的所有的变量。不存在的变量需要建立，存在的变量被赋予新值。只要遇到任何失败，则所有的更新都被撤销，并则返回一个error-status字段值为commitFailed的应答PDU。  
SNMPv2 Trap  
SNMPv2 Trap PDU由一个代理者实体在发现异常事件时产生并发给管理站。与SNMPv1相同，它用于向管理站提供一个异步的通报以便报告重要事件。但它的格式与SNMPv1不同，与GetRequest、GetNextRequest、GetBulkRequest、SetRequest和InformRequest PDU拥有相同的格式。变量绑定字段用于容纳与陷阱消息有关的信息。Trap PDU是一个非认证消息，不要求接收实体应答。  
InformRequest  
InformRequest PDU由一个管理者角色的SNMPv2实体应它的应用的要求发给另一个管理者角色的SNMPv2实体，请求后者向某个应用提供管理信息。与SNMPv2 Trap PDU类似，变量绑定字段被用于传送相关的信息。  
收到InformRequest的实体首先检查承载应答PDU的消息尺寸，如果消息尺寸超过限度，用一个含有tooBig错误代码的Response PDU应答。否则，接收实体将PDU中的内容转到信息的目的地(某个应用)，同时对发出InformRequest的管理者用error-status字段值为noError的Response PDU进行应答。  
4.5 SNMPv3  
4.5.1 SNMP管理框架的体系结构  
一个SNMP管理系统由若干包含SNMP实体的节点组成。在这些实体中，至少有一个实体包含命令产生者，和/或通报接收者的应用(对应以往的管理者)，多个实体包含能够访问管理设备的命令和通报产生者应用 (对应以往的代理者)。实体间用管理通信协议传递管理信息。  
执行命令生成者和通报接收者应用的SNMP实体监测和控制被管元素。被管元素是指主机、路由器、终端服务器等设备。这些被管元素的监测和控制通过对它们的管理信息的访问实现。  
在实现方面，对SNMP的体系结构会有以下不同的要求:  
1. 具有命令应答者和/或通报生成者应用的实体(最小的SNMP);  
2. 具有代管转发者应用的SNMP实体;  
3. 具有命令产生者和/或通报接收者应用的命令行驱动的SNMP实体;  
4. 具有命令生成者和/或通报接收者应用，并具有命令应答和/或通报产生者应用的SNMP实体(以往称为SNMP中间层管理者或双重角色实体);  
5. 具有命令生成者和/或通报接收者，及为管理潜在的非常大量的被管节点可能的其它应用的SNMP实体(以往称为网络管理站);  
为了能够统一满足以上要求，SNMPv3定义了一个可进化的体系结构。  
4.5.2 SNMP实体  
SNMP实体是体系结构的一个实现。如图4.9所示，每个SNMP实体都包含一个SNMP引擎、一个或多个应用。  
\+-------------------------------------------------------------------+  
| SNMP entity |  
| |  
| +-------------------------------------------------------------+ |  
| | SNMP engine (identified by snmpEngineID) | |  
| | | |  
| | +------------+ +------------+ +-----------+ +-----------+ | |  
| | | | | | | | | | | |  
| | | Dispatcher | | Message | | Security | | Access | | |  
| | | | | Processing | | Subsystem | | Control | | |  
| | | | | Subsystem | | | | Subsystem | | |  
| | | | | | | | | | | |  
| | +------------+ +------------+ +-----------+ +-----------+ | |  
| | | |  
| +-------------------------------------------------------------+ |  
| |  
| +-------------------------------------------------------------+ |  
| | Application(s) | |  
| | | |  
| | +-------------+ +--------------+ +--------------+ | |  
| | | Command | | Notification | | Proxy | | |  
| | | Generator | | Receiver | | Forwarder | | |  
| | +-------------+ +--------------+ +--------------+ | |  
| | | |  
| | +-------------+ +--------------+ +--------------+ | |  
| | | Command | | Notification | | Other | | |  
| | | Responder | | Originator | | | | |  
| | +-------------+ +--------------+ +--------------+ | |  
| | | |  
| +-------------------------------------------------------------+ |  
| |  
\+-------------------------------------------------------------------+  
图 4.9 SNMP 实体  
SNMP引擎为发送和接收消息、认证和加密消息、控制对被管对象的访问提供服务。SNMP引擎与包含它的SNMP实体之间存在一对一的联系。引擎包括中包括  
l 发报机(Dispatcher),  
l 消息处理子系统(Message Processing Subsystem),  
l 安全子系统(Security Subsystem)，  
l 访问控制子系统(Access Control Subsystem)。  
在一个管理域中，每个引擎都有一个唯一的和明确的标识符snmpEngingID。由于引擎和实体之间一一对应，因此snmpEngingID也能在管理域中唯一地、明确地标识实体。但是，在不同的管理域中，SNMP的实体可能会有相同的snmpEngineID。  
一个引擎中只有一个发报机，但能够同时支持多个版本的SNMP消息。它的功能包括:  
l 向网络发送或从网络接收SNMP消息，  
l 确定SNMP消息的版本，与相应的消息处理模型相互作用，  
l 为SNMP应用提供抽象接口，用以向应用传递PDU，  
l 为SNMP应用提供抽象接口，用以允许它们向远程SNMP实体发送PDU。  
4.5.3 消息处理子系统  
消息处理子系统负责准备要发送的消息和从收到的消息中抽取数据。如图4.10所示，消息处理子系统潜在地包含多个消息处理模型。  
\+------------------------------------------------------------------+  
| |  
| Message Processing Subsystem |  
| |  
| +------------+ +------------+ +------------+ +------------+ |  
| | \* | | \* | | \* | | \* | |  
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |  
| | Message | | Message | | Message | | Message | |  
| | Processing | | Processing | | Processing | | Processing | |  
| | Model | | Model | | Model | | Model | |  
| | | | | | | | | |  
| +------------+ +------------+ +------------+ +------------+ |  
| |  
\+------------------------------------------------------------------+  
4.10 消息处理子系统  
每个消息处理模型定义一个特定版本的SNMP消息的格式，对应所定义的格式对准备和抽取处理进行相应的调整。  
4.5.4 安全子系统  
安全子系统提供诸如消息的认证和隐私的安全服务。如图4.11所示，SNMPv3采用User-Based安全模型，但潜在的安全模型可有多个。  
\+------------------------------------------------------------------+  
| |  
| Security Subsystem |  
| |  
| +----------------+ +-----------------+ +-------------------+ |  
| | \* | | \* | | \* | |  
| | User-Based | | Other | | Other | |  
| | Security | | Security | | Security | |  
| | Model | | Model | | Model | |  
| | | | | | | |  
| +----------------+ +-----------------+ +-------------------+ |  
| |  
\+------------------------------------------------------------------+  
4.11 安全子系统  
安全模型要指出它所防范的威胁，服务的目标和为提供安全服务所采用的安全协议，如认证和隐私。  
安全协议指出为提供安全服务所采用的机制、过程和MIB对象。  
  
4.5.5 访问控制子系统  
访问控制子系统通过一个或多个访问控制模型提供认证服务。如图4.12所示，View-Based 访问控制模型是SNMPv3所建议的。  
\+------------------------------------------------------------------+  
| |  
| Access Control Subsystem |  
| |  
| +---------------+ +-----------------+ +------------------+ |  
| | \* | | \* | | \* | |  
| | View-Based | | Other | | Other | |  
| | Access | | Access | | Access | |  
| | Control | | Control | | Control | |  
| | Model | | Model | | Model | |  
| | | | | | | |  
| +---------------+ +-----------------+ +------------------+ |  
| |  
\+------------------------------------------------------------------+  
图4.12 访问控制子系统  
访问控制模型定义一个特定的访问决策函数，用以支持访问权的认定决策。  
4.5.5 SNMP应用  
SNMP应用分为以下几种类型:  
l 监测和操纵管理数据的命令产生者；  
l 对管理数据提供访问的命令接收者；  
l 发出异步消息的通报产生者；  
l 处理异步消息的通报接收者；  
l 在实体之间转发消息的代管转发者。  
SNMP应用与SNMP引擎之间形成应用与服务的关系，即SNMP应用是SNMP引擎的应用，SNMP引擎向SNMP应用提供服务。  
SNMP Manager  
包含一个或多个命令产生者和/或通报接收者应用的SNMP实体以往被称为SNMP管理者。如图4.13所示  
(traditional SNMP manager)  
\+-------------------------------------------------------------------+  
| +--------------+ +--------------+ +--------------+ SNMP entity |  
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |  
| | ORIGINATOR | | RECEIVER | | GENERATOR | |  
| | applications | | applications | | applications | |  
| +--------------+ +--------------+ +--------------+ |  
| ^ ^ ^ |  
| | | | |  
| v v v |  
| +-------+--------+-----------------+ |  
| ^ |  
| | +---------------------+ +----------------+ |  
| | | Message Processing | | Security | |  
| Dispatcher v | Subsystem | | Subsystem | |  
| +-------------------+ | +------------+ | | | |  
| | PDU Dispatcher | | +->| v1MP \* |<--->| +------------+ | |  
| | | | | +------------+ | | | Other | | |  
| | | | | +------------+ | | | Security | | |  
| | | | +->| v2cMP \* |<--->| | Model | | |  
| | Message | | | +------------+ | | +------------+ | |  
| | Dispatcher <--------->+ | | | |  
| | | | | +------------+ | | +------------+ | |  
| | | | +->| v3MP \* |<--->| | User-based | | |  
| | Transport | | | +------------+ | | | Security | | |  
| | Mapping | | | +------------+ | | | Model | | |  
| | (e.g RFC1906) | | +->| otherMP \* |<--->| +------------+ | |  
| +-------------------+ | +------------+ | | | |  
| ^ +---------------------+ +----------------+ |  
| | |  
| v |  
\+-------------------------------------------------------------------+  
\+-----+ +-----+ +-------+  
| UDP | | IPX | . . . | other |  
\+-----+ +-----+ +-------+  
^ ^ ^  
| | |  
v v v  
\+------------------------------+  
| Network |  
\+------------------------------+  
图4.13 SNMP Manager  
SNMP Agent  
  
包含一个或多个命令接收者和/或通报产生者应用的SNMP实体，以往被称为SNMP代理者。如图4.14所示。  
\+------------------------------+  
| Network |  
\+------------------------------+  
^ ^ ^  
| | |  
v v v  
\+-----+ +-----+ +-------+  
| UDP | | IPX | . . . | other |  
\+-----+ +-----+ +-------+ (traditional SNMP agent)  
\+-------------------------------------------------------------------+  
| ^ |  
| | +---------------------+ +----------------+ |  
| | | Message Processing | | Security | |  
| Dispatcher v | Subsystem | | Subsystem | |  
| +-------------------+ | +------------+ | | | |  
| | Transport | | +->| v1MP \* |<--->| +------------+ | |  
| | Mapping | | | +------------+ | | | Other | | |  
| | (e.g. RFC1906) | | | +------------+ | | | Security | | |  
| | | | +->| v2cMP \* |<--->| | Model | | |  
| | Message | | | +------------+ | | +------------+ | |  
| | Dispatcher <--------->| +------------+ | | +------------+ | |  
| | | | +->| v3MP \* |<--->| | User-based | | |  
| | | | | +------------+ | | | Security | | |  
| | PDU Dispatcher | | | +------------+ | | | Model | | |  
| +-------------------+ | +->| otherMP \* |<--->| +------------+ | |  
| ^ | +------------+ | | | |  
| | +---------------------+ +----------------+ |  
| v |  
| +-------+-------------------------+---------------+ |  
| ^ ^ ^ |  
| | | | |  
| v v v |  
| +-------------+ +---------+ +--------------+ +-------------+ |  
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY \* | |  
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |  
| | application | | | | applications | | application | |  
| +-------------+ +---------+ +--------------+ +-------------+ |  
| ^ ^ |  
| | | |  
| v v |  
| +----------------------------------------------+ |  
| | MIB instrumentation | SNMP entity |  
\+-------------------------------------------------------------------+  
图4.14 SNMP Agent  
抽象服务接口  
抽象服务接口被定义为描述一个SNMP实体内各种子系统间的概念接口。抽象服务接口试图帮助阐明SNMP实体的外部可观察的行为，但并不涉及或规范实现的结构或组织方法。特别要明确的是，它们不应被解释为API或对API的要求。  
这些抽象服务接口由一组原语定义，而由原语定义提供的服务和服务被调用时被传递的抽象数据元素。

[http_blog.csdn.net_clevise_article_details_5101243]: http://blog.csdn.net/clevise/article/details/5101243