SNMP网络管理体系结构分析

第4章SNMP网络治理体系结构CMIP网络治理体系结构对系统模型、信息模型和通信协议几个方面都提出了比较完备和理想的解决方案，为其他网络治理体系结构建立了理想参考标准。SNMP网络治理体系结构是为了治理基于TCP/IP协议的网络而提出的，与TCP/IP协议与OSI协议的关系类似，SNMP与CMIP相比，突出的特点是简单。这一特点使SNMP得到了广泛的支持和应用，特别是在Internet上的成功应用，使得它的重要性越来越突出，目前已经成为CMIP之外的最重要的网络治理体系结构。4.1SNMP体系结构4.1.1TCP/IP网络治理的开展在TCP/IP的早期开发中，网络治理问题并未得到太大的重视。直到70年代，还一直没有网络治理协议，只有互联网络控制信息协议(ICMP)可以作为网络治理的工具。ICMP提供了从路由器或其它主机向主机传送控制信息的方法，可用于所有支持IP的设备。从网络治理的观点来看，ICMP最有用的特性是回声(echo)和回声应答(echoreply)消息对。这个消息对为测试实体间能否通信提供了一个机制。echo消息要求其接收者在echoreply消息中返回接收到的内容。另一个有用的消息对是时间戳(timestamp)和时间戳应答(timestampreply)，这个消息对为测试网络延迟特性提供了机制。与各种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，还对根本SNMPMIB进行了扩充。有些扩充摘用标准的网络接口，例如令牌环(tokenring)和光纤分布数据接口(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(InternetEngineeringTaskForce)决定对SNMPv2进行修订。1996年发布了一组新的RFC(RequestForComments)，在这组新的文档中，SNMPv2的平安特性被取消了，消息格式也重新摘用SNMPv1的基于“共同体(community)〞概念的格式。删除SNMPv2中的平安特性是SNMPv2开展过程中最大的失败。主要原因是厂商和用户对1993版的SNMPv2的平安机制不感爱好，同时IETF要求的修订时间也非常紧迫，设计者们来不及对平安机制进行改善，甚至来不及对存在的严重缺陷进行修改。因此不得不在1996年版的SNMPv2中舍弃了平安特性。1999年4月IETFSNMPv3工作组提出了RFC2571～RFC2576，形成了SNMPv3的建议。目前，这些建议正在进行标准化。SNMPv3提出了SNMP治理框架的一个统一的体系结构。在这个体系结构中，摘用User-based平安模型和View-based访问控制模型提供SNMP网络治理的平安性。平安机制是SNMPv3的最具特色的内容。4.1.2SNMP根本框架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.1SNMP的协议环境图4.1描述了SNMP的协议环境。从治理站发出3类与治理应用有关的SNMP的消息GetRequest、GetNextRequest、SetRequest。3类消息都由代理者用GetResponse消息应答，该消息被上交给治理应用。另外，代理者可以发出Trap消息，向治理者报告有关MIB及治理资源的事件。由于SNMP依赖UDP，而UDP是无连接型协议，所以SNMP也是无连接型协议。在治理站和代理者之间没有在线的连接需要保护。每次交换都是治理站和代理者之间的一个独立的传送。3)陷阱引导轮询(Trap-directedpolling)如果治理站负责大量的代理者，而每个代理者又保护大量的对象，那么靠治理站及时地轮询所有代理者保护的所有可读数据是不现实的。因此治理站摘取陷阱引导轮询技术对MIB进行控制和治理。所谓陷阱引导轮询技术是：在初始化时，治理站轮询所有知道关键信息(如接口特性、作为基准的一些性能统计值，如发送和接收的分组的平均数)的代理者。一旦建立了基准，治理站将降低轮询频度。相反地，由每个代理者负责向治理站报告反常事件。例如，代理者崩溃和重启动、连接失败、过载等。这些事件用SNMP的trap消息报告。治理站一旦发现反常情况，可以直接轮询报告事件的代理者或它的相邻代理者，对事件进行诊断或获取关于反常情况的更多的信息。陷阱引导轮询可以有效地节约网络容量和代理者的处理时间。网络根本上不传送治理站不需要的治理信息，代理者也不会无意义地频繁应答信息请求。4)代管(Proxies)利用SNMP需要治理站及其所有代理者支持UDP和IP。这限制了在不支持TCP/IP协议的设备(如网桥、调制解调器)上的应用。并且，大量的小系统(PC、工作站、可编程控制器)虽然支持TCP/IP协议，但不希望承担保护SNMP、代理者软件和MIB的负担。为了容纳没有装载SNMP的设备，SNMP提出了代管的概念。在这个模式下，一个SNMP的代理者作为一个或多个其他设备的代管人。即，SNMP代理者为托管设备(proxieddevices)效劳。图4.2显示了常见的一类协议体系结构。治理站向代管代理者发出对某个设备的查询。代管代理者将查询转变为该设备使用的治理协议。当代理者收到对一个查询的应答时，将这个应答转发给治理站。类似地，如果一个来自托管设备的事件通报传到代理者，代理者以陷阱消息的形式将它发给治理站。图4.2SNMP协议体系结构4.2SNMP治理信息与CMIP体系相同，SNMP的根底是包含被管元素信息的被称为MIB的数据库。每个被管资源由对象来表示，MIB是这些对象的有结构的集合。在SNMP中，MIB本质上是一个树型的数据库结构。网络中每个的系统都〔工作站、效劳器、路由器、网桥等〕拥有一个反映系统中被管资源状态的MIB。网络治理实体可以通过提取MIB中的对象值监测系统中的资源，也可以通过修改这些对象值来控制资源。4.2.1治理信息结构SNMP的标准SMI〔structureofmanagementinformation〕为定义和构造MIB提供了一个通用的框架。同时也规定了可以在MIB中使用的数据类型，说明了资源在MIB中怎样表示和命名。SMI的根本指导思想是追求MIB的简单性和可扩充性。因此，MIB只能存储简单的数据类型：标量和标量的二维矩阵。我们将看到SNMP只能提取标量，包括表中的单独的条目。SMI避开复杂的数据类型是为了降低实现的难度和提高互操作性。但在MIB中不可防止地包含厂家建立的数据类型，如果对这样的数据类型的定义没有严格的限制，互操作性也会受到影响。为了提供一个标准的方法来表示治理信息，SMI必须：提供一个标准的技术定义MIB的具体结构;提供一个标准的技术定义各个对象，包括句法和对象值;提供一个标准的技术对对象值进行编码。MIB结构SNMP中的所有的被管对象都被排列在一个树型结构之中。处于叶子位置上的对象是实际的被管对象，每个实际的被管对象表示某些被管资源、活动或相关信息。树型结构本身定义一个将对象组织到逻辑上相关的集合之中的方法。MIB中的每个对象类型都被赋予一个对象标识符(OBJECTIDENTIFIER)，以此来命名对象。另外，由于对象标识符的值是层次结构的，因此命名方法本身也能用于确认对象类型的结构。对象标识符是能够唯一标识某个对象类的符号。它的值由一个整数序列构成。被定义的对象的集合具有树型结构，树根是引用ASN.1标准的对象。从对象标识符树的树根开始，每个对象标识符成分的值指定树中的一个弧。从树根开始，第一级有3个节点:iso、ccitt、joint-iso-ccitt。在iso节点下面有一个为“其他组织〞使用的子树，其中有一个美国国防部的子树(dod)。SNMP在dod之下设置一个子树用于Internet的治理。如下所示:internetOBJECTIDENTIFIER::={iso(1)org(3)dod(6)1}因此，internet节点的对象标识符的值是1.3.6.1。这个值作为internet子树的下级节点标识符的前缀。SMI在internet节点之下定义了4个节点:directory为与OSI的directory相关的将来的应用保存的节点mgmt用于在IAB批准的文档中定义的对象experimental用于标识在Internet实验中应用的对象private用于标识单方面定义的对象mgmt子树包含IAB已经批准的治理信息库的定义。现在已经开发了两个版本的MIB，mib-1和和它的扩充版mib-2。二者子树中的对象标识符是相同的，因为在任何配置中，只有一个MIB。MIB中的mib-1或mib-2以外的对象可以用以下方法定义:由一个全新的修订版(如mib-3)来扩充或取代mib-2。可以为特定的应用构造一个实验MIB。这样的对象随后会被移到mgmt子树之下。例如定义包含各种传输媒体的MIB(例如为令牌环局域网定义的MIB)。专用的扩充可以加在private子树之下。private子树目前只定义了一个子节点enterprises，用于厂商加强对自己设备的治理，与用户及其他厂商共享信息。在enterprises子树下面，每个注册了enterprise对象标识符的厂商有一个分支。internet节点之下分为4个子树的做法为MIB的进化提供了很好的根底。通过对新对象的实验，厂商能够在其被接受为mgmt的标准之前有效地获得大量的实际知识。因此这样的MIB既是对治理符合标准的对象直接有效的，对适应技术和产品的变化也是灵活的。这一点也反映了TCP/IP协议的如下特性：协议在成为标准之前进行大量的实验性的使用和调测。图4.3对象标识符树型结构对象句法SNMPMIB中的每个对象都由一个形式化的方法定义，说明对象的数据类型、取值范围以及与MIB中的其他对象的关系。各个对象以及MIB的整体结构都由ASN.1描述法定义。为了保持简单，只利用了ASN.1的元素和特征的一个有限的子集。UNIVERSAL类型:ASN.1的UNIVERSAL类由独立于应用的通用数据类型组成。其中只有以下数据类型被允许用于定义MIB对象:integer(UNIVERSAL2)octetstring(UNIVERSAL4)null(UNIVERSAL5)objectidentifier(UNIVERSAL6)sequence,sequence-of(UNIVERSAL16)前3个是构成其他对象类型的根本类型。objectidentifier唯一标识对象的符号，由一个integer序列组成，序列中的integer被称为子标识符。对象标识符的integer序列从左到右，定义了对象在MIB树型结构中的位置。sequence和sequence-of用于构成表。APPLICATION-WIDE类型:ASN.1的APPLICATION类由与特定的应用相关的数据类型组成。每个应用，包括SNMP,负责定义自己的APPLICATION数据类型。在SNMP中已经定义了以下数据类型:networkaddress:该类型用CHOICE结构定义，允许从多个协议族的地址格式中进行选择。目前，只定义了IpAddress一种地址格式。ipaddress:IP格式的32位地址。counter:只能做增值不能做减值运算的非负整数。最大值被设为232–1，当到达最大值时，再次从0开始增加。gauge:可做增值也可做减值运算的非负整数。最大值被设为232–1，当到达最大值时被锁定，直至被复位(reset)。timeticks:从某一参照时间开始以百分之一秒为单位计算经历的时间的非负整数。当MIB中定义的某个对象类用到这个数据类型时，参照时间在该对象类的定义中指出。opaque:该数据类型提供一个传递任意数据的能力。数据在传输时被作为OCTETSTRING编码。被传递的数据本身可以是由ASN.1或其他句法定义的任意的格式。定义对象治理信息库由一个对象的集合构成，每个对象都有一个型和一个值。型是对被管对象种类的定义，因此型的定义是一个句法描述。对象的实例是某类对象的一个具体实现，具有一个确定的值。怎样定义MIB中的对象呢？ASN.1是将被使用的描述法。ASN.1中包含一些预定义的通用类型，也规定了通过现有类型定义新类型的语法。定义被管对象的一个可选方法是定义一个被称为Object的新类型。这样，MIB中所有的对象都将是这种类型的。这个方法在技术上是可行的，但会产生定义不便于应用的问题。我们需要多种值的类型，包括counter、gauge等等。另外，MIB支持二维表格或矩阵的定义。因此，一个通用的对象类型必须包含参数来对应所有这些可能性和选择性。另一个更有吸引力的方法，并且也是被SNMP所实际摘用的方法是利用宏〔macro〕对在被管对象定义中相互关联的类型进行集合定义。一个宏的定义给出相关类型集合的句法，而宏的实例定义一个特定的类型。因此定义被分为以下等级：宏：定义合法的宏实例，即说明相关集合类型的句法宏实例：通过为宏定义提供实际参数生成实例，即说明一个特定的类型宏实例值：用一个特定的值来表示一个特定的实体图4.4是OBJECT-TYPE宏的定义(引自RFC1212)。图4.4被管对象宏其中的主要工程是:SYNTAX:对象类的抽象句法，该句法必须从SMI的对象句法类型中确定一种类型。ACCESS:定义通过SNMP或其他协议访问对象实例的方法。Access子句定义该对象类型支持的最低等级。可选的等级有:read-only、read-write、write-only和not-accessible。STATUS:指出该对象在实现上的要求。要求可以是:mandatory(必须)、optional(可选)、deprecated(恳求—必须实现的对象，但很可能在新版MIB中被删除)和obsolete(废除—不再需要被管系统实现的对象)。DescrPart:对象类型语义的文本描述。该子句是可选的。ReferPart:对定义在在其他MIB模块中的某个对象的文本型交叉引用。该子句是可选的。IndexPart:用于定义表。该子句只是在对象类型对应表中的〞行〞时才出现。DefValPart:定义一个默认值，用于建立对象实例。该子句是可选的。VALUENOTATION:指出通过SNMP访问该对象时使用的名字。由于应用OBJECT-TYPE宏的MIB的完整的定义包含在MIB的冗长的文档中，因此，人们并不常使用它们。比较常用的是更简捷的方法—基于树型结构和对象特性的表格表示的方法。定义表格SMI只支持一种数据结构化方法:标量值条目的二维表格。表格的定义用到ASN.1的sequence和sequenceof两个类型和OBJECT-TYPE宏中的IndexPart。表格定义方法可以通过实例进行说明。考虑对象类型tcpConnTable，这个对象包含由相应的被管实体保护的TCPconnections的信息。对于每个这样的connection，以下信息在表中存储:state:TCPconnection的状态localaddress:该connection的本端的IP地址localport:该connection的本端的TCP端口remoteaddress:该connection的另一端的IP地址remoteport:该connection的另一端的TCP端口需要注意的是，tcpConnTable是存放在某个被管系统保护的MIB中。因此，tcpConnTable中的一个条目对应被管系统中的一个connection的状态信息。TCPconnection的状态信息有22个工程，按照tcpConnTable的定义，只有上述5个工程对网络治理者来说是可见的。这也表达了SNMP强调保持网络治理简单性的特点。即，在被管对象中，只包含相对应的被管实体的有限的和有用的信息。图4.5给出了tcpConnTable的定义(引自RFC1213)。图4.5TCPconnectionTable在图4.5中，可以看到sequence和sequenceof在定义表格时的应用:整个表由一个SEQUENCEOFTcpConnEntry构成。ASN.1的结构SEQUENCEOF由一个或多个相同的元素构成，在本例中(在所有的SNMPSMI的情况下)每个元素是表中的一行。每一行由一个指定了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.2MIB-II在TCP/IP网络治理的建议标准中，提出了多个相互独立的MIB，其中包含为Internet的网络治理而开发的MIB-II。鉴于它在说明标准MIB的结构、作用和定义方法等方面的重要性和代表性，有必要对其进行比较深入的讨论。MIB-II是在MIB-I的根底之上开发的，是MIB-I的一个超集。mib-2组被分为以下分组:system:关于系统的总体信息;interface:系统到子网接口的信息;at(addresstranslation):描述internet到subnet的地址映射;ip:关于系统中IP的实现和运行信息;icmp:关于系统中ICMP的实现和运行信息;tcp:关于系统中TCP的实现和运行信息;udp:关于系统中UDP的实现和运行信息;egp:关于系统中EGP的实现和运行信息;dot3(transmission):有关每个系统接口的传输模式和访问协议的信息。snmp:关于系统中SNMP的实现和运行信息。system组system组提供有关被管系统的总体信息。表4.1列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.1system组中的对象ObjectSyntaxAccessDescriptionsysDescrDisplayString(SIZE(0…255))RO对实体的描述，如硬件、操作系统等sysObjectIDOBJECTIDENTIFIERRO实体中包含的网络治理子系统的厂商标识sysUpTimeTimeTicksRO系统的网络治理局部本次启动以来的时间sysContectDisplayString(SIZE(0…255))RW该被管节点负责人的标识和联系信息sysNameDisplayString(SIZE(0…255))RW该被管节点被赋予的名称sysLocationDisplayString(SIZE(0…255))RW该节点的物理地点sysServiceINERGER(0…127)RO指出该节点所提供的效劳的集合，7个bit对应7层效劳interfaces组interfaces组包含实体物理接口的一般信息，包括配置信息和各接口中所发生的事件的统计信息。表4.2列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.2interfaces组中的对象ObjectSyntaxAccessDescriptionifNumberINTEGERRO网络接口的数目ifTableSEQUENCEOFifEntryNA接口条目清单ifEntrySEQUENCENA包含子网及其以下层对象的接口条目ifIndexINTEGERRO对应各个接口的唯一值ifDescrDisplayString(SIZE(0…255))RO有关接口的信息，包括厂商、产品名称、硬件接口版本ifTypeINTEGERRO接口类型，根据物理或链路层协议区分ifMtuINERGERRO接口可接收或发送的最大协议数据单元的尺寸ifSpeedGaugeRO接口当前数据速率的估量值ifPhysAddressPhysAddressRO网络层之下协议层的接口地址ifAdminStatusINTEGERRW期望的接口状态(up(1),down(2),testing(3))ifOperStatusINTEGERRO当前的操作接口状态(up(1),down(2),testing(3))ifLastChangeTimeTicksRO接口进入当前操作状态的时间ifInOctetsCounterRO接口收到的8元组的总数ifInUcastPktsCounterRO递交到高层协议的子网单播的分组数ifInNUcastPktsCounterRO递交到高层协议的非单播的分组数ifInDiscardsCounterRO被丢弃的进站分组数ifInErrorsCounterRO有错的进站分组数ifInUnkownProtosCounterRO由于协议未知而被丢弃的分组数ifOutOctetsCounterRO接口发送的8元组的总数ifOutUcastPktsCounterRO发送到子网单播地址的分组总数ifOutNUcastPktsCounterRO发送到非子网单播地址的分组总数ifOutDiscardsCounterRO被丢弃的出站分组数ifOutErrorsCounterRO不能被发送的有错的分组数ifOutQLenGaugeRO输出分组队列长度ifSpecificOBJECTIDENTIFIERRO参考MIB对实现接口的媒体的定义addresstranslation组addresstranslation组由一个表构成，表中的每一行对应系统中的一个物理接口，提供网络地址向物理地址的映射。一般情况下，网络地址是指系统在该接口上的IP地址，而物理地址决定于实际摘用的子网情况。例如，如果接口对应的是LAN，那么物理地址是接口的MAC地址，如果对应X.25分组交换网，那么物理地址可能是一个X.121地址。表4.3列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.3addresstranslation组中的对象ObjectSyntaxAccessDescriptionatTableSEQUENCEOFAtEntryNA包含网络地址对物理地址的映射atEntrySEQUENCENA包含一个网络地址、物理地址对atIfIndexINTEGERRW表格条目的索引atPhysAddressPhysAddressRW依赖媒体的物理地址atNetAddressNetworkAddressRW对应物理地址的网络地址实际上，addresstranslation组包含在MIB-II中只是为了与MIB-I兼容，MIB-II的地址转换信息在各个网络协议组中提供。ip组ip组包含有关节点上IP实现和操作的信息，如有关IP层流量的一些计数器。ip组中包含3个表，ipAddrTable、ipRouteTalbe和ipNetToMediaTable。ipAddrTable包含分配给该实体的IP地址的信息，每个地址被唯一地分配给一个物理地址。ipRouteTable包含用于互联网路由选择的信息。该路由表中信息是比较原本地从一些协议的路由表中抽取而来的。实体当前所知的每条路由都有一个条目，表格由ipRouteDest索引。ipRouteTable中的信息可用于配置的监测，并且由于表中的对象是read-write的，因此也可被用于路由控制。ipNetToMediaTable是一个提供IP地址和物理地址之间对应关系的地址转换表。除了增加一个指示映射类型的对象ipNetToMediaType之外，表中所包含的信息与addresstranslation组相同。此外，ip组中还包含一些用于性能和故障监测的标量对象。表4.4列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.4ip组中的对象ObjectSyntaxAccessDescriptionipForwardingINTEGERRW是否作为IP网关〔1/0〕ipDefaultTTLINTEGERRW插入到该实体生成的数据报的IP头中Time-To-Live字段中的默认值ipInReceivesCounterRO接口收到的输入数据报的总数ipInHdrErrorsCounterRO由于IP头错被丢弃的输入数据报总数ipInAddrErrorsCounterRO由于IP地址错被丢弃的输入数据报总数ipForwDatagramsCounterRO转发的输入数据报数ipInUnknownProtosCounterRO由于协议未知被丢弃的输入数据报数ipInDiscardsCounterRO无适当理由而被丢弃的输入数据报数ipInDeliversCounterRO成功地递交给IP用户协议的输入数据报数ipOutRequestsCounterRO本地IP用户协议要求传输的IP数据报总数ipOutNoRoutesCounterRO由于未找到路由而被丢弃的IP数据报数ipReasmTimeOutINTEGERRO重组接收到的碎片可等待的最大秒数ipReasmReqdsCounterRO接收到的需要重组的IP碎片数ipReasmOKsCounterRO成功重组的IP数据报数ipRaesmFailsCounterRO由IP重组算法检测到的重组失败的数目ipFragsOkCounterRO成功拆分的IP数据报数ipFragsFailsCounterRO不能成功拆分而被丢弃的IP数据报数ipFragsCreatesCounterRO本实体产生的IP数据报碎片数ipAddrTableSEQUENCEOFIpAddrEntryNA本实体的IP地址信息(表内对象略)ipRouteTableSEQUENCEOFIpRouteEntryNAIP路由表(表内对象略)ipNetToMediaTableSEQUENCEOFIpNetToMedisEntryNA用于将IP映射到物理地址的地址转换表(表内对象略)IpRoutingDiscardsCounterRO被丢弃的路由选择条目icmp组ICMP(InternetControlMessageProtocol)是TCP/IP协议族中的一局部，所有实现IP协议的系统都提供ICMP。ICMP提供从路由器或其他主机向主机传递消息的手段，它的根本作用是反响通信环境中存在的问题，例如:数据报不能到达目的地，路由器没有缓冲区容量来转发数据报。icmp组包含有关一个节点的ICMP的实现和操作的信息，具体地讲，icmp组由节点接收和发送的各种ICMP消息的计数器所构成由一个表构成。表4.5列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.5icmp组中的对象ObjectSyntaxAccessDescriptionicmpInMsgsCounterRO收到的ICMP消息的总数icmpInErrorsCounterRO收到的有错的ICMP的消息数icmpInDestUnreachsCounterRO收到的目的地不可到达的消息数icmpInTimeExcdsCounterRO收到的超时的消息数icmpInParmProbsCounterRO收到的有参数问题的消息数icmpInSrcQuenchsCounterRO收到的源有问题的消息数icmpInRedirectsCounterRO收到的重定向的消息数icmpInEchosCounterRO收到的要求echo的消息数icmpInEchoRepsCounterRO收到的应答echo的消息数icmpInTimestampsCounterRO收到的要求Timestamp的消息数icmpInTimestampRepsCounterRO收到的应答Timestamp的消息数icmpInAddrMasksCounterRO收到的要求AddressMask的消息数icmpInAddrMaskRepsCounterRO收到的应答AddressMask的消息数icmpOutMsgsCounterRO发出的ICMP消息的总数icmpOutErrorsCounterRO发出的有错的ICMP的消息数icmpOutDestUnreachsCounterRO发出的目的地不可到达的消息数icmpOutTimeExcdsCounterRO发出的超时的消息数icmpOutParmProbsCounterRO发出的有参数问题的消息数icmpOutSrcQuenchsCounterRO发出的源有问题的消息数icmpOutRedirectsCounterRO发出的重定向的消息数icmpOutEchosCounterRO发出的要求echo的消息数icmpOutEchoRepsCounterRO发出的应答echo的消息数icmpOutTimestampsCounterRO发出的要求Timestamp的消息数icmpOutTimestampRepsCounterRO发出的应答Timestamp的消息数icmpOutAddrMasksCounterRO发出的要求AddressMask的消息数icmpOutAddrMaskRepsCounterRO发出的应答AddressMask的消息数tcp组tcp组包含有关一个节点的TCP的实现和操作的信息，图4.5定义的tcpConnTable包含在这个组中。表4.6列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.6tcp组中的对象ObjectSyntaxAccessDescriptiontcpRtoAlgorithmINTEGERRO重传时间tcpRtoMinINTEGERRO重传时间的最小值tcpRtoMaxINTEGERRO重传时间的最大值tcpMaxConnINTEGERRO实体支持的TCP连接数的上限tcpActiveOpensCounterRO实体已经支持的主动翻开的数量tcpPassiveOpensCounterRO实体已经支持的被动翻开的数量tcpAttemptFailsCounterRO已经发生的试连失败的次数tcpEstabResetsCounterRO已经发生的复位的次数tcpCurrEstabGaugeRO当前状态为established的TCP连接数tcpInSegsCounterRO收到的segments总数tcpOutSegsCounterRO发出的segments总数tcpRetranSegsCounterRO重传的segments总数tcpConnTableSEQUENCEOFTcpConnTntryNA包含TCP各个连接的信息(表内对象略，参考图4.5)tcpInErrorsCounterRO收到的有错的segments的总数tcpOutRstsCounterRO发出的含有RST标志的segments数udp组udp组包含有关一个节点的UDP的实现和操作的信息。除了有关发送和接收的数据报的信息之外，这个组中还包含一个udpTable表，该表中包含UDP端点的治理信息。所谓UDP端点是指正在支持本地应用接收数据报的UDP进程。udpTable表中包含每个UDP端点用户的IP地址和UDP端口。表4.7列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.7udp组中的对象ObjectSyntaxAccessDescriptionudpInDatagramsCounterRO递交该UDP用户的数据报的总数udpNoPortsCounterRO收到的目的端口上没有应用的数据报总数udpInErrorsCounterRO收到的无法递交的数据报数udpOutDatagramsCounterRO该实体发出的UDP数据报总数udpTableSEQUENCEOFUdpEntryNA包含UDP的用户信息udpTableSEQUENCENA某个当前UDP用户的信息udpLocalAddressIpAddressROUDP用户的本地IP地址udpLocalPortINTEGERROUDP用户的本地端口号egp组egp组包含有关一个节点的EGP(ExternalGatewayProtocol)的实现和操作的信息。除了有关发送和接收的EGP消息的信息之外，这个组中还包含一个egpNeighTable表，该表中包含有关相邻网关的信息。表4.8列出了该组中各个对象的名称、句法、访问权限和对象描述。表4.8egp组中的对象ObjectSyntaxAccessDescriptionegpInMsgsCounterRO收到的无错的EGP消息数egpInErrorsCounterRO收到的有错的EGP消息数egpOutMsgsCounterRO本地产生的EGP消息总数egpOutErrorsCounterRO由于资源限制没有发出的本地产生的EGP消息数egpNeighTableSEQUENCEOFEgpNeighEntryNA相邻网关的EGP表(表内的对象略)egpAsINTEGERRO本EGP实体的自治系统数4.3简单网络治理协议(SNMP)4.3.1SNMP支持的操作SNMP只支持对变量的检查和修改的操作，具体地，可以对标量对象进行以下三种操作：Get：治理站从被治理站提取标量对象值。Set：治理站更新被治理站中的标量对象值。Trap：被治理站向治理站主动地发送一个标量对象值。MIB的结构不能通过增加或减少对象实例被改变，并且，访问只能对对象标识树中的叶子对象进行。这些限制大大简化了SNMP的实现，但同时也限制了网络治理系统的能力。4.3.2共同体和平安控制网络治理是一种分布式的应用。与其他分布式的应用相同，网络治理中包含由一个应用协议支持的多个应用实体的相互作用。在SNMP网络治理中，这些应用实体就是摘用SNMP的治理站应用实体和被治理站的应用实体。SNMP网络治理具有一些不同于其他分布式应用的特性，它包含一个治理站和多个被治理站之间一对多的关系。即，治理站能够获取和设置各治理站的对象，能够从各被治理站中接收陷阱信息。因此，从操作或控制的角度来看，治理站治理着多个被治理站。同时，系统中也可能有多个治理站，每个治理站都治理所有的或一局部被治理站。反过来，我们也要看到SNMP网络治理中还包含另外一种一对多的关系—一个被治理站和多个治理站之间的关系。每个被治理站控制着自己的本地MIB，同时必须能够控制多个治理站对这个本地MIB的访问。这里所说的控制有以下三个方面:认证效劳:将对MIB的访问限定在授权的治理站的范围内;访问策略:对不同的治理站给予不同的访问权限;代管效劳:一个被治理站可以作为其他一些被治理站(托管站)的代管，这就要求在这个代管系统中实现为托管站效劳的认证效劳和访问权限。以上这些控制都是为了保证网络治理信息的平安，即被管系统需要保护它们的MIB不被非法地访问。SNMP通过共同体(community)的概念提供了初步的和有限的平安能力。SNMP用共同体来定义一个代理者和一组治理者之间的认证、访问控制和代管的关系。共同体是一个在被管系统中定义的本地的概念。被管系统为每组可选的认证、访问控制和代管特性建立一个共同体。每个共同体被赋予一个在被管系统内部唯一的共同体名，该共同体名要提供给共同体内的所有的治理站，以便它们在get和set操作中应用。代理者可以与多个治理站建立多个共同体，同一个治理站可以出现在不同的共同体中。由于共同体是在代理者处本地定义的，因此不同的代理者处可能会定义相同的共同体名。共同体名相同并不意味者共同体有什么相似之处，因此，治理站必须将共同体名与代理者联系起来加以应用。认证效劳认证效劳是为了保证通信是可信的。在SNMP消息的情况下，认证效劳的功能是保证收到的消息是来自它所声称的消息源。SNMP只提供一种简单的认证模式:所有由治理站发向代理者的消息都包含一个共同体名，这个名字发挥口令的作用。如果发送者知道这个口令，那么认为消息是可信的。通过这种有限的认证形式，网络治理者可以对网络监控(set、trap)特别是网络控制(set)操作进行限制。共同体名被用于引发一个认证过程，而认证过程可以包含加密和解密以实现更平安的认证。访问策略通过定义共同体，代理者将对它的MIB的访问限定在了一组被选择的治理站中。通过使用多个共同体，代理者可以为不同的治理站提供不同的MIB访问控制。访问控制包含两个方面:SNMPMIB视图:MIB中对象的一个子集。可以为每个共同体定义不同的MIB视图。视图中的对象子集可以不在MIB的一个子树之内。SNMP访问模式:READ-ONLY或READ-WRITE。为每个共同体定义一个访问模式。MIB视图和访问模式的结合被称为SNMP共同体轮廓(profile)。即，一个共同体轮廓由代理者处MIB的一个子集加上一个访问模式构成。SNMP访问模式统一地被用于MIB视图中的所有对象。因此，如果选择了READ-ONLY访问模式，那么治理站对视图中的所有对象都只能进行read-only操作。事实上，在一个共同体轮廓之内，存在两个独立的访问限制—MIB对象定义中的访问限制和SNMP访问模式。这两个访问限制在实际应用中必须得到协调。表4.9给出了这两个访问限制的协调规那么。注意，对象被定义为write-only，SNMP也可以对其进行read操作。表4.9MIB对象定义中的ACCESS限制与SNMP访问模式的关系MIB对象定义中的ACCESS限制SNMP访问模式READ-ONLYREAD-WRITEread-onlyget和trap操作有效read-writeget和trap操作有效get，set和trap操作有效Write-onlyget和trap操作有效，但操作值与具体实现有关get，set和trap操作有效，但操作值与具体实现有关not-accessible无效在实际应用中，一个共同体轮廓要与代理者定义的某个共同体联系起来，便构成了SNMP的访问策略(accesspolicy)。即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.5SNMP消息格式治理站和代理者之间以传送SNMP消息的形式交换信息。每个消息包含一个指示SNMP版本号的版本号，一个用于本次交换的共同体名，和一个指出5种协议数据单元之一的消息类型。图4.6描述了这种结构。表4.10对其中的元素进行了说明。(a)GetRequestPDU,GetNextRequestPDU,SetRequestPDU(b)GetRequest-PDU,GetNextRequest-PDU,SetRequest-PDU(c)ResponsePDU(d)TrapPDU(e)Variable-bindings图4.6SNMP消息格式表4.10SNMP消息字段字段描述versionSNMP版本community共同体的名字用作SNMP认证消息的口令request-id为每个请求赋予一个唯一的标识符error-statusnoError(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:构成PDU。将构成的PDU、源和目的传送地址以及一个共同体名传给认证效劳。认证效劳完成所要求的变换，例如进行加密或参加认证码，然后将结果返回。SNMP协议实体将版本字段、共同体名以及上一步的结果组合成为一个消息。用根本编码规那么(BER)对这个新的ASN.1的对象编码，然后传给传输效劳。SNMP消息的接收一般情况下，一个SNMP协议实体完成以下动作接收一个SNMP消息进行消息的根本句法检查，丢弃非法消息检查版本号，丢弃版本号不匹配的消息SNMP协议实体将用户名、消息的PDU局部以及源和目的传输地址传给认证效劳。如果认证失败，认证效劳通知SNMP协议实体，由它产生一个trap并丢弃这个消息;如果认证成功，认证效劳返回SNMP格式的PDU。协议实体进行PDU的根本句法检查，如果非法，丢弃该PDU，否那么利用共同体名选择对应的SNMP访问策略，对PDU进行相应处理。变量绑定在SNMP中，可以将多个同类操作(get、set、trap)放在一个消息中。如果治理站希望得到一个代理者处的一组标量对象的值，它可以发送一个消息请求所有的值，并通过获取一个应答得到所有的值。这样可以大大减少网络治理的通信负担。为了实现多对象交换，所有的SNMP的PDU都包含了一个变量绑定字段。这个字段由对象实例的一个参考序列及这些对象的值构成。某些PDU只需给出对象实例的名字，如get操作。对于这样的PDU，接收协议实体将忽略变量绑定字段中的值。4.3.6GetRequestPDUSNMP实体应网络治理站应用程序的请求发出GetRequestPDU。发送实体将以下字段包含在PDU之中:PDU类型:指出GetRequestPDU类型。request-id:Request-id能够使SNMP应用将得到的各个应答与发出的各个请求一一对应起来。同时也可以使SNMP实体能够处理由于传输效劳的问题而产生的重复的PDU。variablebindings:要求获取值的对象实例清单。GetRequestPDU的SNMP接收实体用包含相同request-id的GetResponsePDU进行应答。GetRequest操作是原子操作—要么所有的值都提取回来，要么一个都不提取。GetRequst操作不成功的原因有对象名不匹配(noSuchName)、返回结果太长(tooBig)以及其他原因(genErr)。SNMP只允许提取MIB树中的叶子对象的值。因此不能只提供一个表或一个条目的名字来获取整个表或整行的对象值。但是可以将表中每行的各个对象包含在变量绑定中，来一次获取一行的对象值。4.3.7GetNextRequestPDUGetNextRequestPDU几乎与GetRequestPDU相同。它们具有相同交换模式和相同的格式。唯一的不同是:在GetRequestPDU中，变量绑定字段中列出的是要取值的对象实例名本身，而在GetNextRequestPDU中，变量绑定字段列出的是要取值的对象实例的“前一个〞对象实例名。与GetRequest相同，GetNextRequest也是原子操作。虽然与GetRequest的外在差异不大，但是GetNextRequest却有GetRequest无法替代的用途。它能够使网络治理站去动态地发现一个MIB视图的结构。它也为查找不知其条目的表提供了一个有效的机制。简单对象值的提取假设网络治理站希望从某个代理者处提取udp组中的所有简单对象，那么它可以发出一个如下的PDU:GetRequest(udpInDatagrams.0，udpNoPorts.0,udpInError.0,udpOutDatagrams.0)如果代理者支持所有这些对象，那么将返回一个包含这4个对象值的GetResponsePDU:GetResponse((udpInDatagrams.0=100),(udpNoPorts.0=1),(udpInErrors.0=2), (udpOutDatagrams.0=200))这里，100，1，2和200分别是这4个对象的值。然而，只要有一个对象不被支持，那么代理者将返回一个含有错误码NoSuchName的GetResponsePDU，而不返回任何其他值。为了确保得到所有可用的对象值，治理站必须分别发出4个GetRequestPDU。现在考虑应用GetNextRequestPDU的情况: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个对象都被支持，那么代理者返回一个如下的GetResponsePDU: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视图中实际存在的对象或对象实例的标识符。利用这一特点，治理站可以使用GetNextRequestPDU去探查一个MIB视图，并搞清它的结构。在我们上面的例子中，如果治理站发出一个GetNextRequest(udp)PDU，那么将获得Response(udpInDatagrams.0=100)的应答。治理站因此便知道了在这个MIB视图中第一个被支持的对象是udpInDatagrams，并且知道了它的当前值。4.3.8SetRequestPDUSNMP实体应网络治理站应用程序的请求发出SetRequestPDU。它与GetRequestPDU具有相同的交换模式和相同的格式。但是，SetRequest是被用于写对象值而不是读。因而，变量绑定清单中既包含对象实例标识符，也包含每个对象实例将被赋予的值。SetRequestPDU的SNMP接收实体用包含相同request-id的GetResponsePDU进行应答。SetRequest操作是原子操作—要么变量绑定中的所有变量都被更新，要么一个都不被更新。如果应答实体能够更新变量绑定中的所有变量，那么GetResponsePDU中包含提供给各个变量的值的变量绑定字段。只要有一个变量值不能成功地设置，那么无变量值返回，也无变量值被更新。在GetRequest操作中可能返回的错误—noSuchName、tooBig和genErr也是SetRequest可能返回的错误。另外一个可能返回的错误是badValue，只要SetRequest中有一个变量名和变量值不一致的问题，就会返回这个错误。所谓不一致可能是类型的问题，也可能是长度的问题，还可能是提供的实际的值有问题。利用SetRequest不仅可以对叶子对象实例进行值的更新，也可以利用变量绑定字段进行表格的行增加和行删除操作。除此之外，SetRequest还可被用于完成某种动作。SNMP没有提供一种命令代理者完成某种动作的机制，它的全部能力就是在一个MIB视图内get和set对象值。但是利用set的功能可以间接地发布完成某种动作的命令。某个对象可以代表某个命令，当它被设置为特定值时，就执行特定的动作。例如代理者可以设一个初始值为0的对象reBoot，如果治理站将这个对象值置1，那么代理者系统被重新启动，reBoot的值也被重新置0。4.3.9TrapPDUSNMP实体应网络治理代理者应用程序的请求发出TrapPDU。它被用于向治理站异步地通报某个重要事件。它的格式与其他的SNMPPDU完全不同。所包含的字段有:PDU类型:指出TrapPDU类型enterprise:标识产生本Trap的网络治理子系统(用System组中的sysObjectId值)agent-addr:产生本Trap的对象的IP地址generic-trap:一种预定义的trapspecific-trap:更明确地指出trap特性的代码time-stamp:发出trap的网络实体从上次重启到产生本trap所经历的时间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.4SNMPv24.4.1SNMPv2对SNMPv1的改进1993年，SNMP的改进版SNMPv2开始发布，从此，原来的SNMP便被称为SNMPv1。最初的SNMPv2最大的特色是增加了平安特性，因此被称为平安版SNMPv2。但不幸的是，经过几年试用，没有得到厂商和用户的积极响应，并且也发现自身还存在一些严重缺陷。因此，在1996正式发布的SNMPv2中，平安特性被删除。这样，SNMPv2对SNMPv1的改进程度便受到了很大的削弱。总的来说，SNMPv2的改进主要有以下3个方面：支持分布式治理；改进了治理信息结构；增强了治理信息通信协议的能力。SNMPv1摘用的是集中式网络治理模式。网络治理站的角色由一个主机担当。其他设备(包括代理者软件和MIB)都由治理站监控。随着网络规模和业务负荷的增加，这种集中式的系统已经不再适应需要。治理站的负担太重，并且来自各个代理者的报告在网上产生大量的业务量。而SNMPv2不仅可以摘用集中式的模式，也可以摘用分布式模式。在分布式模式下，可以有多个顶层治理站，被称为治理效劳器。每个治理效劳器可以直接治理代理者。同时，治理效劳器也可以托付中间治理者担当治理者角色监控一局部代理者。对于治理效劳器，中间治理器又以代理者的身份提供信息和接受控制。这种体系结构分散了处理负担，减小了网络的业务量。SNMPv2的治理信息结构〔SMI〕在几个方面对SNMPv1的SMI进行了扩充。定义对象的宏中包含了一些新的数据类型。最引人注目的变化是提供了对表中的行进行删除或建立操作的标准。新定义的SNMPv2MIB包含有关SNMPv2协议操作的根本流量信息和有关SNMPv2治理者和代理者的配置信息。在通信协议操作方面，最引人注目的变化是增加了两个新的PDU—GetBulkRequest和InformRequest。前者使治理者能够有效地提取大块的数据，后者使治理者能够向其他治理者发送trap信息。SNMPv2网络治理框架SNMPv2提供了一个建立网络治理系统的框架。但网络治理应用，如故障治理、性能监测、计费等不包括在SNMPv2的范围内。用术语来说，SNMPv2提供的是网络治理根底结构。图4.7是这种根底结构的一个配置例。SNMPv2本质上是一个交换治理信息的协议。网络治理系统中的每个角色都保护一个与网络治理有关的MIB。SNMPv2的SMI对这些MIB的信息结构和数据类型进行定义。SNMPv2提供了一些一般的通用的MIB，厂商或用户也可以定义自己私有的MIB。在配置中至少有一个系统负责整个网络的治理。这个系统就是网络治理应用驻留的地方。治理站可以设置多个，以便提供冗余或分担大网络的治理责任。其他系统担任代理者角色。代理者收集本地信息并保存，以备治理者提取。这些信息包括系统自身的数据，也可以包括网络的业务量信息。SNMPv2既支持高度集中化的网络治理模式，也支持分布式的网络治理模式。在分布式模式下，一些系统担任治理者和代理者两种角色，这种系统被称为中间治理者。中间治理者以代理者身份从上级治理系统接受治理信息操作命令，如果这些命令所涉及的治理信息在本地MIB中，那么中间治理者便以代理者身份进行操作并进行应答，如果所涉及的治理信息在中间治理者的下属代理者的MIB中，那么中间治理者先以治理者身份对下属代理者进行发布操作命令，接收应答，