snmp协议

SNMPv2的管理模型

1.介绍

            一个网络管理系统包含：几个（可能是许多的）节点，每个都有一个名为代理的处理实体。代理有到管理工具的通路；至少一个管理站点和一个管理协议，该协议用于在代理和管理站点间传递管理信息。协议的实施是在一个定义了鉴定和认证策略的管理体系下进行的。

            网络管理站点上运行监视和控制网络元素的管理应用程序。网络元素是诸如主            机，路由器，终端服务器等的设备，通过对它们的管理信息的访问来监视和控制网络元素。

            本文档--<<SNMPv2的管理模型>>--的目的就是定义：在不同的配置和环境下，管理体系是怎样被用来实现实际的网络管理的。

            这里描述的模型使后面的要求成为必要：交换SNMPv2消息的对等实体使用唯一           的表示。所以，这里表现出与先前的SNMP[1]的基于社区的管理模型的不同。通过对每个SNMPv2消息来源和预期的接收者的明白无误的标识，这个新的策略改善了过去的社区方案，它不仅支持一个更加方便的访问控制模型，而且允许在将来对非对称公匙安全协议的有效运用。

            1.1.术语的注解

            为了便于说明，原先的Internet标准网络管理体系（在RFC 1155 , 1157 和1212中            有描述）被叫做SNMP版本1体系(SNMPv1)。当前的体系叫做SNMP版本2体系(SNMPv2)。

            2.模型的元素

            2.1.SNMPv2参与者

            SNMPv2参与者是一个概念性的，虚拟的执行环境，它的操作被限制在（出于对安全性的考虑）一个特定SNMPv2实体的所有可能的操作的子集中（参考2.2），该子集被管理性地定义。不论一个SNMPv2实体什么时候处理一个SNMPv2消息，它都是以一个SNMPv2参与者的身份进行操作，因而它的操作就被限制在为这个参与者定义的操作集合中。对这个参与者，其特定的可能的操作可能与其他参与者的操作            集合重叠或者不相关，它也可能是那个SNMPv2实体的所有可能操作的一个合适或者不合适的子集。从协议体系上讲，每个SNMPv2参与者包含：

            ? 一个唯一的，与众不同的参与者标识。

            ? 一个逻辑网络位置，参与者执行时所在的逻辑网络位置称为一个传送协议的域，            并且传送寻址信息。

            ? 一个专门的鉴定协议和相关的参数，所有那个参与者产生的协议消息通过他们            被鉴定为初始的和完整的。

            ? 一个专门的私有协议和相关参数，用来保护所有参与者接收的协议消息，防止            泄漏。

            从概念上讲，每个SNMPv2参与者可以用一个ASN.1值表示，符合下面的语法：

SnmpParty::=SEQUENCE{

            partyIdentity

            OBJECTIDENTIFIER,

            partyTDomain

            OBJECTIDENTIFIER,

            partyTAddress

            OCTETSTRING,

            partyMaxMessageSize

            INTEGER,

            partyAuthProtocol

            OBJECTIDENTIFIER,

            partyAuthClock

            INTEGER,

            partyAuthPrivate

            OCTETSTRING,

            partyAuthPublic

            OCTETSTRING,

            partyAuthLifetime

            INTEGER,

            partyPrivProtocol

            OBJECTIDENTIFIER,

            partyPrivPrivate

            OCTETSTRING,

            partyPrivPublic

            OCTETSTRING

            }

            对于每个代表一个SnmpParty参与者的SnmpParty值，下列叙述是成立的：

            o它的partyIdentity组件是参与者的标识

            o它的partyTDomain组件称作传送域，并指明参与者用来接收网络管理通信量的那种传送设备。一个传送域的例子是snmpUDPDomain(在UDP上的SNMPv2，使用SNMPv2参与者).

            o它的partyTAddress组件称作传送寻址信息，代表一个参与者用来接收网络管理通信量的传送设备的地址。

            o它的partyMaxMessageSize组件称作最大消息的尺码，代表这个参与者将要接收的最大SNMPv2消息的八位组的长度。

            o它的partyAuthProtocol组件称作鉴定协议，指明了一个协议和鉴定所有该参与者生成的消息是初始和完整的机制。在这种上下文下，值noAuth表明该参与者产生的消息未被鉴定为初始和完整。

            o它的partyAuthClock组件称作鉴定时钟，代表与该参与者关联的当前时间。本组件的重要性是在鉴定协议中体现的。

            o它的partyAuthPrivate组件称作私有鉴定密匙，代表支持鉴定协议所需的任何保密的值。本组件的重要性是在鉴定协议中体现的。

            o它的partyAuthPublic组件称作公有鉴定密匙，代表任何支持鉴定协议所需的公共值。本组件的重要性是在鉴定协议中体现的。

            o它的partyAuthLifetime组件称作生命周期，代表该参与者生成的协议消息的可以接受的传送延时的管理性的上界。本组件的重要性是在鉴定协议中体现的。

            o它的partyPrivProtocol组件称作私有协议，指明了一个协议和一个防止该参与者接收到的所有协议消息泄漏的机制。在这种情况下，值noPriv表明该参与者接收到的消息未被保护以防止泄漏。

            o它的partyPrivPrivate组件称作私有密匙，代表支持私有协议所需的保密值。本组件的重要性是在私有协议中体现的。

            o它的partyPrivPublic组件称作公有密匙，代表支持私有协议所需的任何公共值。本组件的重要性是在私有协议中体现的。

            对于所有的被某个SNMPv2实体实现的SNMPv2参与者，如果它的鉴定协议是            noAuth而且它的私有协议是noPriv，那么那个实体称作不安全的。

            2.2.SNMPv2实体

            一个SNMPv2实体是一个实际的处理者，它通过用[2]中指明的方式产生消息并且/或者对SNMPv2协议消息进行响应来完成网络管理操作。当一个SNMPv2实体以一个特定的SNMPv2参与者的身份进行操作时，这个实体的操作必须限制在管理性地定义在那个参与者上的所有可能的操作的子集中。

            通过定义，一个SNMPv2实体的操作在一个特定SNMPv2参与者生成的任何单个协            议消息的处理和一个潜在的不同的SNMPv2参与者生成的任何其他协议消息的处理之间不需要同时发生。相应地，一个支持超过一个参与者的SNMPv2实体的实现不需要是多线程的。当然，也存在着实现时选用多线程的情况。

            从协议体系上说，每个SNMPv2实体维护一个保存了它所知的所有SNMPv2参与者            的逻辑数据库，这些参与者的操作有的是逻辑地实现的，有的是通过代理与远地实体地交互来实现的，有的是远地实体实现的。另外，每个SNMPv2实体维护一个存有该实体所知的所有被管理对象资源（参照2.8）。最后，每个SNMPv2实体维护一个存有定义了针对已知的SNMPv2参与者的访问权限的访问控制策略信息的逻辑数据库。

            2.3.SNMPv2管理站点

            一个SNMPv2管理站点是一个SNMPv2参与者在通过生成相应的SNMPv2协议消息来            初始化SNMPv2管理操作时，或者在它接收和处理陷阱通告时假定的运作性的角色。有时，术语SNMPv2管理站点也指专注于操作角色的SNMPv2的部分实现（例如图形工作站）。这种SNMPv2的部分实现可能用来提供方便或管理设备的本地革新，但是它们可能对代表远地协议用户的SNMPv2管理操作提供很少甚至没有支持。

            2.4.SNMPv2代理

            一个SNMPv2代理是一个SNMPv2参与者在为响应收到的诸如一个SNMPv2管理站点            （参照2.3）生成的SNMPv2协议消息而进行SNMPv2管理操作时假定的操作性角色。有时，术语SNMPv2代理也指专注于这种操作角色的SNMPv2（例如在嵌入式系统中）的部分实现。这种部分实现对代表管理设备的远地用户的SNMPv2管理操作的实现提供了支持，但是它可能对这些设备的本地革新提供很少甚至没有支持。

            2.5.视图子树

            一个视图子树是所有名字有公共的ASN.1实体标识符前缀的管理信息库对象的            集合。一个视图子树由OBJECTIDENTIFIER的值来标识，该值是该子树中所有（潜在）的类似的管理信息库对象实例中最大的OBJECTIDENTIFIER前缀。

            当标识一个视图子树的OBJECTIDENTIFIER前缀比根据SMI[3]定义的OBJECT            IDENTIFIER长时，用这个视图子树来控制访问就会在对象实例层有梯度。这种梯度在超越作为代理角色的SNMPv2实体的范围之上来考虑。所以，一个作为代理角色的SNMPv2实体的实现不需要支持在标识一个特定叶子对象类型时有多于必要数目的子标识符的视图子树的值。然而，在决定哪一个作为管理者角色的SNMPv2实体应该接收陷阱通知时，也用到了访问控制信息。（ 4.2.6 of[2]）所以，为了使一个管理站点能使用合适粒度的陷阱通知配置，代理实现者可能希望提供实例级的梯度。

            2.6.MIB视图

            一个MIB视图是根据SMI[3]（那就是，所有MIB对象的所有实例的通用集合）定义的所有对象类型的所有实例的集合的子集：

            o一个MIB视图的每个元素用一个ASN.1OBJECTIDENTIFIER值唯一地标识。所以，一个特定对象类型的完全相同命名的实例（例如在不同的代理中）必须包含在不同的MIB视图中。也就是，在一个特定的MIB视图中，一个特定的对象实例名字解析为最多一个对象实例。

            o每个MIB视图被定义为视图子树的一个集合。

            2.7.代理关系

            一个代理关系在下面情况下存在：为了处理一个接收到的管理请求，一个SNMPv2            实体必须和其他逻辑上远地的实体通讯。一个用代理关系来处理管理请求的SNMPv2实体叫做一个SNMPv2代理机构。

            当一个逻辑上远地的参与者和一个SNMPv2实体间的通讯是通过SNMPv2时（通过            任何传输协议），那个代理参与者称作一个SNMPv2本地代理关系。SNMPv2本地代理关系的部署是一种有利的手段，用它可以分期偿还或轮换构建一个大的管理系统时的管理处理或带宽的代价。

            当一个逻辑上远地的参与者和一个SNMPv2实体间的通讯不是通过SNMPv2时（通            过任何传输协议），那个代理参与者称作一个SNMPv2远地代理关系。远地代理关系的部署是一种使Internet上的从某种意义上讲不可管理的设备或部门可以通过SNMPv2来管理。

            定义一个通常用于一个SNMPv2代理关系的SNMPv2实体的行为的透明原则如下：

            一个SNMPv2实体处理从另一个SNMPv2实体接收而来的SNMPv2协议消息的方式对            于后者是完全透明的。这种透明原则是从历史上分离结构体系与实现的SNMP原则中继承而来。这种            二分法给Internet标准网络管理体系的信息和分配模型都带来了好处，而且它是可能建造的大型管理系统的建筑性基石。与这种原则一致，尽管在某些环境下SNMPv2代理机构的实现可能与传输层的网桥的实现相似，这种特定的实现战略（或其他任何实现战略）不值得在SNMPv2管理体系或代理管理的标准机制中得到认可。很明显，在透明原则里，在任何两个SNMPv2对等体之间需要保持SNMPv2的管理操作的语义。特别地，如果一个操作集合的范围延伸到去管理位于多个网络位置的信息，它的“似乎是同步”的语义将极难保证。正因为如此，允许管理位于多个位置的信息的操作集合的代理配置是不提倡的，尽管这种操作并没有被协议体系明确的禁止，以防在很稀少的情况下，可能需要以一种相容的方法来支持它们。            在这种透明原则下，还很明显的是：与一个代理机构的交互时，不提供给一个管理站点实现它的请求的代理机制的特点和过程的信息。也就是，除了在底层传输地址中的任何明显的区别外，应该使管理站点看起来似乎是在通过SNMPv2与被代理的设备直接通讯。所以，一个在代理机构和它被代理设备间的通讯超时信息应该表现为在管理站点与代理机构间的超时。同样的，一个来自于被代理设备的出错响应应该尽可能的以代理机构和管理站点间的对应出错信息表示。

            2.8.SNMPv2上下文

            一个SNMPv2上下文是指一个可被一个SNMPv2实体访问的被管理对象资源的集合。被一个上下文标识的对象资源可能是本地的或远地的。

            一个涉及本地对象资源的SNMPv2上下文被标识为一个MIB视图。在这种情况下，一个SNMPv2实体用本地机制去访问被SNMPv2上下文标识的管理信息。

            一个涉及远地对象资源的远地SNMPv2上下文被标识为一个代理关系。在这种情            况下，一个SNMPv2实体作为一个代理机构去访问被SNMPv2上下文标识的管理信息。

            2.9.SNMPv2管理通讯

            SNMPv2管理通讯是一个从一个特定的SNMPv2参与者到第二个特定的SNMPv2参与者的，关于包含在相应的SNMPv2实体中可以被访问的SNMPv2上下文中的管理信息的通讯。特别地，一个SNMPv2管理通讯可以是：

            o一个发起通讯的参与者的关于被寻址的参与者可以访问的信息的

            查询（例如getRequest,getNextRequest,或者getBulkRequest）。

            o一个被寻址参与者的，关于发起方可访问的信息的，指示性的断言。（例如Response,InformRequest,或者SNMPv2-Trap）

            o一个发起方作出的，发给被寻址的参与者的，关于被寻址的参与者可以访问的信息的命令式的断言（例如setRequest），或者

            o一个发向被寻址的参与者的确认，它是关于发起方接收到的信息的。（例如一个确认InformRequest的响应）一个管理通讯用一个ASN.1值表示，符合下面的语法: SnmpMgmtCom::=[2]IMPLICITSEQUENCE{

            dstParty            OBJECTIDENTIFIER,

            srcParty            OBJECTIDENTIFIER,

            context            OBJECTIDENTIFIER,

            pdu

            PDUs

            }

            对于每个代表一个SNMPv2管理通讯的SnmpMgmtCom值,下列叙述成立:

            o它的dstParty组件称作目的点，标识了该通讯发往的SNMPv2参与者。

            o它的srcParty组件称作源点，标识了发起通讯的SNMPv2参与者。

            o它的context组件标识SNMPv2上下文，它含有通讯涉及的管理信息

            o它的pdu组件有在[2]中赋于的形式和含义。

            2.10.SNMPv2鉴定过的管理通讯

            SNMPv2鉴定过的管理通讯是这样的SNMPv2管理通讯：它的发起方SNMPv2参与者            被可信地鉴定过，并且该通讯的传输的完整性受到保护。一个SNMPv2鉴定过的管理通讯用一个ASN.1值表示，符合下面的语法:

SnmpAuthMsg::=[1]IMPLICITSEQUENCE{

            authInfo        ANY,--由鉴定协议定义

            authData

            SnmpMgmtCom

            }

            对于每个代表一个SNMPv2鉴定过的管理通讯的SnmpAuthMsg值,下列叙述成立:

            o它的authInfo组件称作鉴定信息，包含支持产生本消息的SNMPv2参与者使用的鉴定协议的信息。鉴定信息的详细含义由使用的鉴定协议指定；除了鉴定协议用它来判断该通讯是否被鉴定过以外，它对通讯的应用语义没有影响。

            o它的authData组件称作鉴定数据，代表一个SNMPv2管理通讯。

            2.11.SNMPv2私有管理通讯

            SNMPv2私有管理通讯是一个SNMPv2鉴定过的管理通讯，它受到可能的保护，防止泄漏。一个私有管理通讯用一个ASN.1值表示，符合下面的语法:

            SnmpPrivMsg::=[1]IMPLICITSEQUENCE{

            privDst            OBJECTIDENTIFIER,

            privData            [1]IMPLICITOCTETSTRING

            }

            对每个代表一个SNMPv2私有管理通讯的SnmpPrivMsg值，下面的叙述成立：

            o它的privDst组件称作私有目的地，表明该通讯发向的SNMPv2参与者。

            o它的privData组件称作私有数据，包含一个SNMPv2鉴定过的管理通讯的（可能已加密）数据序列（根据[5]的约定）。

            2.12.SNMPv2管理通讯类

            一个SNMPv2管理通讯类对应于一个在[2]中定义的特定的SNMPv2PDU类型。SNMPv2管理通讯类用ASN.1INTEGER值表示，需要根据识别PDU的类型而定（表1）

            Get1

            GetNext2

            Response4

            Set8

            --unused16

            GetBulk32

            Inform64

            SNMPv2-Trap128

            表1:管理通讯类

 

            一个表示通讯类的值被计算为2，增加到ASN.1上下文的值，对应SNMPv2 PDU的特定标签。

            一个管理通讯的类的集合用ASN.1INTEGER值来表示，该值是该集合类表示通讯类的标识的和。空集用0值表示。

            2.13.SNMPv2访问控制策略

            SNMPv2访问控制策略是一个用SNMPv2上下文和在一对SNMPv2参与者间被认证的管理通讯类描述的本地访问策略的标准说明书。在协议体系中，该说明书包含四部分：

            oSNMPv2访问控制的目标－接收其他参与者的管理请求，执行管理操作的SNMPv2参与者。

            oSNMPv2访问控制的主体－通过发送管理通讯给其他参与者而请求管理操作被执行的SNMPv2参与者。

            oSNMPv2访问控制的被管理的对象资源――标识管理信息的SNMPv2上下文，被请求的管理操作在它之上被执行，

            o指定SNMPv2管理通讯类的策略，它属于一个特定的SNMPv2上下文，该上下文由一个被认证的特定的目标从一个特定的主体获得。

            概念性地，一个SNMPv2访问策略用ASN.1值表示，符合下面地语法：

  AclEntry::=SEQUENCE{

            aclTarget            OBJECTIDENTIFIER,

            aclSubject            OBJECTIDENTIFIER,

            aclResources            OBJECTIDENTIFIER,

            aclPrivileges            INTEGER

            }

            对于表示一个SNMPv2访问策略的每个值，下列陈述成立：

            o它的aclTarget组件称作目标，指明该部分策略允许访问的SNMPv2参与者。

            o它的aclSubject组件称作主体，指明被该部分策略赋予权限的SNMPv2参与者。

            o它的aclResources组件称作被管理的对象资源，表明该部分策略涉及的SNMPv2上下文。

            o它的aclPrivileges组件称作权限，代表一个SNMPv2管理通讯类的集合，在指明特定的SNMPv2上下文时，该集合从特定的主体参与者接收，认证后被目标参与者处理。SNMPv2访问控制策略的运用仅发生在管理通讯接收的时候；它不用在管理通讯的传输中。注意：用AclEntry语法的ASN.1值，也被用于决定一个SNMPv2陷阱[2]的目的地。

            3.过程的元素

            本小节描述一个SNMPv2实体在处理SNMPv2消息的程序。这些程序独立于可能用到的特定的鉴定和私有协议。

            3.1.产生一个请求

            本小节描述一个SNMPv2实体发送一个管理请求和者一个陷阱通知的程

            序：

            (1)创建一个SnmpMgmtCom值，其中的srcParty组件表明发起方的参与者，dstParty表明接收的参与者，context标识期望的SNMPv2上下文，pdu指明期望的管理操作。

            (2)查询存有参与者信息的本地数据库，以决定发起方和接收方的SNMPv2的鉴定协议和其他相关信息。

            (3)创建一个SnmpAuthMsg值，含有下面的属性：

            根据发起方的鉴定协议创建它的authInfo组件。特别地，如果发起方的鉴定协            议为noAuth，该属性置为长度为0的OCTETSTRING值。它的authData属性是已经创建的SnmpMgmtCom的值

            (4)查询关于参与者信息的本地数据库，以决定接收方的SNMPv2参与者的私有协议和其他相关信息。

            (5)创建一个SnmpPrivMsg值，属性如下：

            它的privDst属性指明接收方的SNMPv2参与者。

            它的privData属性是序列化的SnmpAuthMsg值（可能被加密）。

            特别地，如果接收方SNMPv2参与者地私有协议是noPriv，那么privData属性是未被加密的。否则，privData根据私有协议来处理。

            (6)根据[5]中的约定序列化SnmpPrivMsg的值。

            (7)序列化后地SnmpPrivMsg值用接收方的SNMPv2参与者的传输地址和传输域来传送。

            注意：上述地过程不包含任何SNMPv2访问控制策略地应用。(参照2.13)

            3.2.处理一个收到的通讯

            本节描述一个SNMPv2实体收到一个管理通讯后的处理过程。

            (1)增加snmpStatsPackets计数器[7].如果收到的信息不是一个SnmpPrivMsg的序列化的（根据[5]地约定）值，该消息不作进一步地处理就被抛弃。(如果该数据包的第一个八位组地值为16进制的30，有时在抛弃该消息前增加 snmpStats30Somethingcounter[7]的值；否则增加snmpStatsEncodingErrors          counter[7]的值)

            (2)查询关于参与者信息的本地数据库，根据SnmpPrivMsg中的privDst属性得到接收方SNMPv2参与者的信息。

            (3)如果本地数据库中没有关于接受方SNMPv2参与者的信息，或者表明本地的SNMPv2实体没有实现接收方参与者的操作，那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsUnknownDstPartiescounter[7]的值。

            (4)根据SnmpPrivMsg中的privData属性创建一个ASN.1OCTETSTRING值（可能根据使用的私有协议解密） 特别地，如果该参与者的私有协议是noPriv，那么OCTETSTRING 的值与SnmpPrivMsg中的privData的值完全对应。

            (5)如果OCTETSTRING的值未被序列化，（根据[5]的约定），那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsEncodingErrors  counter[7]的值。

            (6)如果authData中的dstParty属性与SnmpPrivMsg中的privDst属性不同，那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsDstPartyMismatchescounter[7]的值。

            (7)根据SnmpAuthMsg中authData中的srcParty属性得出发起方SNMPv2 参与者，在关于参与者信息的本地数据库中查询它的信息。

            (8)如果本地数据库中没有发起方参与者的信息，那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsUnknownSrcPartiescounter[7]的值。

            (9)根据关于参与者信息的本地数据库中发起和接收方的SNMPv2参与者的相关信息和鉴定协议，鉴定得到的SnmpAuthMsg值。特别地，如果鉴定协议指明为noAuth，那么总是鉴定SnmpAuthMsg            的值为真实的。

            (10)如果鉴定SnmpAuthMsg的值为不真实的，那么无需进一步的处理就丢弃接收到的消息，而且，如果snmpV2EnableAuthenTrapsobject[7]正在生效，那么该SNMPv2实体根据它的配置（ 4.2.6 of[2]）发送authorizationFailure陷阱[7]

            (11)从SnmpAuthMsg中的authData属性提取SnmpMgmtCom的值

            (12)从SnmpMgmtCom的context属性得到SNMPv2的上下文，查询关于参与者信息的本地数据库以获得它的信息。

            (13)如果本地数据库中没有该SNMPv2上下文的信息，那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsUnknownContextscounter[7]的值。

            (14)查询关于访问处理信息的本地数据库，根据接收方参与者和指明的SNMPv2上下文得到本地访问策略许可给发起方SNMPv2参与者的访问权限。

            (15)根据与SnmpMgmtCom中的PDUs属性值关联的ASN.1tag值决定管理通讯类。如果接收到的消息的管理信息类是32,8,2,或1(也就是GetBulk,Set, GetNext或者Get)，并且本地SNMPv2实体没有实现SNMPv2上下文，那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsUnknownContextscounter[7] 的值。

            (16)如果接收到的消息的管理信息类是128,64或4(也就是            SNMPv2-Trap,Inform,或者Response)，并且该类无访问权限，那么无需进一步的处理就丢弃接收到的消息，之后增加snmpStatsBadOperationscounter[7]的值。

            (17)如果接收到的消息的管理通讯类没有访问权限，那么在生成和传送一个响应消息后无需进一步的处理就丢弃接收到的消息，该响应消息代表接收方SNMPv2参与者，被发往发起方SNMPv2参与者，它的context,var-bind-list和request-id属性与接收到的请求中的对应属性完全一样。它的error-            index属性是zero并且它的error-status属性是authorizationError[2].

            (18)如果SNMPv2上下文涉及本地对象资源，那么根据在[2]中的程序，用SNMPv2上下文识别MIB视图，根据该视图用接收方SNMPv2实体执行SnmpMgmtCom值代表的管理操作。

            (19)如果SNMPv2上下文涉及远地对象资源，那么通过合适的代理关系执行SnmpMgmtCom值代表的管理操作。

            3.3.生成一个响应

            生成一个针对SNMPv2管理请求的响应的过程和传送一个请求的过程是完全一样的（参考3.1），除了下列的情况例外：

            (1)在第一步，从初始的SnmpMgmtCom中的srcParty属性得到响应SnmpMgmtCom中的dstParty，从初始的SnmpMgmtCom中的dstParty属性得到响应SnmpMgmtCom中的srcParty属性，从初始的SnmpMgmtCom中的context属性得到响应SnmpMgmtCom中的context属性；而且，响应SnmpMgmtCom的pdu属性的值是那个实施初始SnmpMgmtCom值指定的操作执行后得到的结果。

            (2) 在第七步，用生成自己的相应请求的传送地址和传送域来传送序列化的SnmpPrivMsg值，即使这与关于参与者信息的本地数据库中记录的传送信息不同。

            4.模型应用

            这一部分描写如何设置管理模型，以达到在各种环境和配置中实现有效的网络            管理.定义了几种类型的管理配置，并用各自的几个例子来加以描述.

            4.1无安全的小代理配置

            这段是关于与一个或多个SNMPv2管理站点相互作用的小的、无安全保证的            SNMPv2代理的配置的例子.表2是关于小代理和管理者都知道的SNMPv2参与者的信息.表3介绍了关于本地访问策略的相似的公共部分的信息.

            在表2中，代理在IP地址为 1.2.3 .4、UDP的断口161使用参与者身份gracie来操作；管理者在IP地址为 1.2.3 .5、UDP的断口的2001上用身份为george来操作的.在小的、无安全保证的SNMPv2代理段执行必须提供关于两个SNMPv2参与者的身份和传输地址的管理配置（和稳定存储）：自身和远端的.严格的讲，关于参与者的其他信息（包括访问策略信息）是不必要配置的.

            身份gracie（代理者）george（管理者）

            域snmpUDPDomainsnmpUDPDomain

            地址 1.2.3 .4，1611.2.3.4.5，2001

            认证段口noAuthnoAuth

            （AuthPort）

            认证的私有密钥“”“”

            （AuthPrivKey）

            认证的公开密钥“”“”

            认证的时钟00

            认证的生命周期00

            私有端口noPrivnoPriv

            私有私人密钥“”“”

            私有的公开密钥“”“”

            表2：小代理的参与者信息

            目标主题上下文权限

            graciegeorgelocal35（获取,获取下一个获取一批）

            （GetGetNextGetBulk）

            georgegracielocal132

            (ResponseSNMPv2-Trap)

            表3：关于小代理的访问信息

            假如管理端的参与者george希望通过叫代理者gracie发布一个SNMPv2的            GetNext请求消息来的询问关于上下文为“local”的管理信息.该管理者参考他本地的关于参与者的数据库信息.因为对参与者george的鉴定认证协议是记录为“moAuth”的，这个通过管理者生成的GetNext请求消息是作为原始性和完整性是不需要鉴别的.通过管理者的本地数据库中关于参与者的信息，对参与者gracie的私有协议是设置为“noPriv”的，GetNext请求消息是不会得到保护的，可能会暴露.更准确的讲，它是简单的装配的，排序和传输到目的地址的（IP地址为 1.2.3 .4，UDP端口为161），这个目的地址就是参与者gracie在管理者的本地数据库中的信息所记录的.

            当GetNext请求消息在代理段被收到后，这个（gracie）参与者的身份信息从消息中取得，并且接收的实体参考参与者信息的本地数据库.因为gracie的私有协议是“noPriv”，其接受消息是不会得到不被暴露的保护的.类似的，当原始参与者（grorge）的身份被取得后，参与者的本地数据库的信息也被取得了.因为对当时人george的鉴别协议记录为“noAuth”，这个接受信息是立即被认证接收.            这个接受消息完全被处理的情况，仅仅发生代理关于访问策略信息的本地数据库对通过参与者george向参与者gracoe关于SNMPv2的上下文为“local”的"GetNext"请求通讯的认证.访问策略的数据库信息在表3中的认证象通讯等（Get和GetBulk等操作）. 当一个标准的请求被处理时，一个响应消息通过参考SNMPv2上下文“local”和身份来生成，gracie作为源参与者，从请求端来的george作为目的参与者.因为            对gracie的本地数据库中的关于认证协议记为“noAuth”，对原始和整体性而言， 一般性的响应消息是不用认证的.根据参与者信息的本地数据库，对参与者george 的私有协议是“noPriv”，响应消息可能被暴露.响应消息从相应的的请求地址传输到传输地址，而不关心和传输地址相关的george的本地数据库的信息.当生成响应是被管理者接受时，直接的参与者（george）的身份是从消息中提取出来的，并且管理者参考参与者的本地数据库信息.因为参与者george的私有协议记录为“noPriv”，该响应是得不到保护的.类似的，发起的参与者gracie的身份被提取出来，并参考其本地数据库，因为参与者gracie的认证协议记为“noAuth”，响应立即作为认证被接受.接受的信息能完全被处理，仅仅当管理者的本地数据库的访问策略认证来自于参与者gracie到管理者george的响应信息，并且参考SNMPv2的上下文“local”.            访问策略信息数据库描述象表3中认证响应消息等（如snmpV2-陷阱信息）

            4.2安全小代理配置

            这段给出了一个例子来配置SNMPv2安全小代理，该代理仅仅和单一的SNMPv2的管理站相互作用.表4说明了关于对小代理和管理者都知道的SNMPv2参与者的信息.而表5类似地说明了本地访问策略的公共信息.管理者和代理之间的相互影响在这个配置中是和上面的非安全小代理非常相似            的，除了所有的协议消息要对原始性和完整性认证及对信息的隐蔽的保护.这个例子要求加密技术，是为了支持通过SNMPv2本身来分发密码密钥.一个更精确的包含附加的一对参与者例子支持在没有加密技术认证消息中交换非加密信息来不花加密的代价。

            一个实际的安全代理的配置可能要求SNMPv2参与者的认证和私有协议均为不            认证noAuth（）和无私有（noPriv），其目的是为了支持时钟同步（参考[6]）.更详细的说，这些额外的参与者是不在这个例子中说明的.

            身份olliestan

            (代理)(管理者)

            域snmpUDPDomainsnmpUDPDomain

            地址 1.2.3 .4,1611.2.3.5,2001

            认证端口v2md5AuthProtocolv2md5AuthProtocol

            认证私有密钥"0123456789ABCDEF""GHIJ KL 0123456789"

            认证公开密钥""""

            认证时钟00

            认证的生命周期300300

            私有端口desPrivProtocoldesPrivProtocol

            私人私有密钥"MNOPQR0123456789""STUVWX0123456789"

            私人公开密钥""""

            表4:安全小代理的参与者信息

            目标目标上下文权限

            olliestanlocal35(Get,GetNext&GetBulk)

            stanollielocal132(Response&SNMPv2-Trap)

            表5:安全小代理的访问信息

            在表4中，这个例子的代理参与者在IP地址为 1.2.3 .4、UDP端口为161上使用ollie的身份来操作；管理者在IP地址为 1.2.3 .5、UDP的端口为2001上使用身份stan来操作.SNMPv2的安全小代理的执行必须提供关于SNMPv2的参与者的相关信息管理配置（和稳定存储）：包括它自身和远端.Ollie和stan认证他们通过使用SNMPv2认证协议v2md5AuthProtocol和他们的彼此不同的私有认证密钥来产生的所有的信息.尽管在这里他们的私有认证密钥的值（"0123456789ABCDEF"和           "GHIJ KL 0123456789"）的出现是属于解释目的，关于私有认证密钥的信息一般是不会提供给人们的，并且是限制请求它的协议的部分操作.当使用v2md5AuthProtocol时，对每个SNMPv2参与者的公开认证密钥从不会在SNMPv2的认证和校验中使用的.（v2md5AuthProtocol在字符上是对称的的），同时每个参与者的私有认证密钥必须对彼此要认证通讯的参与者是已经知道的.相反，不对称认证协议（公开密钥）不能依靠他们操作的私有密钥的共享.传输给参与者stan的所有协议消息是使用desPrivProtocol私有协议和私有密钥“STUVWX 0123456789 ” 来加密的；它们加密是通过相同的协议和密钥.类似地，传输给参与者ollie的所有信息是用desPrivProtocol协议和私人私有密钥“MNOPQR 0123456789 ” 来加密的，他们相互加密.作为认证密钥，私人私有密钥是不能提供给人们的，同时请求它的协议的执行也要限制部分功能.

            4.3MIB视图的配置

            这段描述了一个关于MIB视图定义的惯例和惯例的使用，并给出一个关于参考            本地目标资源的SNMPv2的上下文的MIB视图的配置.

            一个MIB视图通过收集视图子树来定义（参考2.6段），并且任何一个MIB视图可以用这种方法来描述.因为MIB视图的定义可以包含很多视图子树，关于一个简化的MIB视图的定义也是合理的.           惯例中采纳了关于支持用视图子树族（包括或者排除有关的MIB）来实现简化的MIB视图的定义.该视图子树族包括或排除相关MIB视图的定义。通过这个惯例，每个SNMPv2实体根据相关的SNMPv2上下文（可参考本地的目标资源）来定义MIB视图，通过该MIB视图来维持本地表.在表中的每个条目表示一个视图子树族，该视图子树包括或者排除一些SNMPv2上下文的MIB视图.每个表中实体描述了一个子树族用一对序偶：目标验证人（OBJECTIDENTIFIER）值（又叫族名）和位串（bitstring）值（又叫族标志）.族标志是指出了在一个相关族名的子验证名在一个相关子树族定义中是非常重要的.对每个可能的MIB对象实例，如果下列条件成立，那么它是属于通过一个详细表条目来描述的的视图子树族的：

            ? 由MIB对象实例组成的目标标识符名至少和上述的表条目的族名一样数目的标识符.

            在上述的MIB对象实例名中每个子标识符匹配相应族名相关的子标识符.而不管其族标志是否为零

            对一个特殊的SNMPv2上下文来讲，在MIB视图中出现的MIB对象实例是和子树            族的实例的成员有关的，在SNMPv2的上下文中的本地表的条目：

            ● 如果一个MIB对象实例不属于任何一个子树族，则对相关的SNMPv2的上下文            而言，它就不在的MIB视图中.

            ● 如果一个MIB对象实例属于子树族，该子树族是通过一个相关的表条目详细            的描述的，则根据条目的类型来决定是包括还是排除相关的MIB视图.

            ● 如果一个MIB对象实例属于通过多个相关表条目描述的子树族，则实例根据            单一的表条目来决定是包括还是排除相关的MIB视图.这里表项目，首先，关联最大的子标识名数，其次，还关联最大的族名.

            子树通过这样的表条目来描述，其关联的族标志是符合通过族名的条目来标识            的单一视图子树.因为惯例提供了内在族标志值和多个的扩展，带有一个零长度的族标志的表项代表一个子树族，该子树与一个单一的视图子树相对应。

            上下文类型族名族标志

            lu cy includedinternet''H

            表6：小代理的视图定义

            用这个惯例来简化MIB视图的定义，一些最通用的MIB定义可以方便的表示.

            例如，表6就说明了小的SNMPv2实体需要的MIB视图的定义，这个小的MIB具有单            一的SNMPv2的上下文，该上下文和MIB视图相关，这样MIB视图包括了在SNMPv2网络管理结构中定义的所有MIB目标.这个说明表有单一的入口.在MIB视图中定义条目的SNMPv2上下文（lu cy ）的在第一列表明.条目的类型表明任何MIB对象实例属于子树族，该子树族是通过对在MIB视图中SNMPv2上下文“lu cy ”的条目的出现来描述的.这个条目的族名是internert，并且零长度的族标志表明了相关子树族和            根和该节点的单一子视图相适应.

            另一个关于MIB视图定义的例子（见表7）是一个有多个SNMPv2上下文的SNMPv2            实体，并且有截然不同的MIB视图.关联了SNMPv2上下文lu cy 的MIB视图，组成了所有在SNMPv2网络环境结构中定义的MIB目标的实例，除了适合于SNMPv2参与者管理的部分.相反地，属于SNMPv2上下文ricky的MIB视图仅仅包含在Internet- 标准MIB的系统组中的MIB对象实例，和SNMPv2参与者管理的这些对象实例.

            上下文类型族名族标志

            lu cy includedinternet''H

            lu cy excludedsnmpParties''H

            rickyincludedsystem''H

            rickyincludedsnmpParties''H

            表7:多上下文的视图定义

            一个更复杂的关于MIB视图配置的例子说明了通过视图子树族（见表8）的视图            子树的简化集合.在这个例子中，和SNMPv2上下文lu cy 相关的MIB视图包括所有的对象实例（这些实例在Internet标准MIB系统组中），和一些次要的网络交互的设备相关的信息.无论如何，相关信息交互是不包括交互的速度的.次要表条目族标志值“FFAO”H表明一个MIB对象实例属于相关的子树族，假如它的名字的初始前缀包含有在注册层次上的ifEntry部分，它的名字的11层子树的名字为2. 描述次要网络交互的速度的MIB对象实例，是属于通过次要的和第三个表的条目的来描述的子树族，但特殊的实例是排除SNMPv2上下文为lu cy 的MIB视图的，因为更多的相关族名在表条目上是排除类型.

            对SNMOv2上下文为ricky的MIB视图在这个例子中也被定义.这个SNMPv2上下文            为ricky的MIB视图包括了在Internet标准MIBicmp组中所有的对象实例，和与管理设备相关的15层的网络交互所有相关的信息.另外，SNMPv2上下文为rickyMIB视图包括在14层上收到的和网络交互的8位组的数目.

            上下文类型族名族标志

            lu cy includedsystem''H

            lu cy included{ifEntry02}'FFA0'H

            lu cy excluded{ifSpeed2}''H

            rickyincludedicmp''H

            rickyincluded{ifEntry05}'FFA0'H

            rickyincluded{ifInOctets4}''H

            表8:更多的视图定义的详细阐述

            根据上面的例子的假设，一个MIB视图配置的广阔范围可以通过[4]中的简化描           述得到高效的支持，严格的MIB设计可能有时要更加简化大多数MIB视图定义的大小和复杂度.一方面，MIB视图配置的机构没有强加一个绝对的约束在当地管理的访问策略上和MIB的名字空间的结构上；在另一方面，大多数的访问策略是已知的，这些策略的配置代价可以通过分配一些不同的部分在注册层来降低，这里注册层的MIB目标是本地策略要求经常频繁地处理的.

            4.4代理配置

            这节主要是用一个例子来解释SNMPv2的代理配置.一方面，外部代理配置提供了            管理非SNMP设备的能力，另一方面，本地代理配置允许一个管理者减轻一个主要任务不是管理的网络设备的管理方面的负担.从这个程度上来讲，SNMPv2代理机构的功能主要就是个管理信息的集合，代理配置也可减轻大规模管理活动的带宽要求.

            这个例子配置的一个说明：实际的配置可能要求附加的的部分，主要大为了支持时钟同步和保密的分发.

            4.4.1 外部代理配置

            这段主要是介绍一个关于通过SNMPv2管理站管理网络元素（这些网络元素并不            支持SNMPv2）的配置的例子.这个在SNMPv2代理机构的配置中心通过使用一个叫所有者协议（proprietaryprotocol）来和非SNMPv2设备进行交互来实现SNMPv2的管理操作.

            表9介绍了关于SNMPv2参与者的信息，这些信息记录在SNMPv2代理机构的本地           数据库中的参与者信息中.表10介绍了关于代理关系的信息，该信息记录在SNMPv2理机构的本地数据库的的上下文信息中.表11介绍了关于SNMPv2参与者的信息，该信息记录SNMPv2管理站的本地数据库的参与者信息中.表12介绍了关于访问策略的数据库信息，该信息是在本地的管理中指明.

            身份grouchochicoharpo

            (管理者)(代理人)(代理目的)

            域snmpUDPDomainsnmpUDPDomainacmeMgmtPrtcl

            地址 1.2.3 .4,2 0021.2.3 .5,1610x98765432

            认证端口v2md5AuthProtocolv2md5AuthProtocolnoAuth

            认证私有密钥"0123456789ABCDEF""GHIJ KL 0123456789"""

            认证公开密钥""""""

            认证时钟000

            认证生命周期3003000

            私有端口noPrivnoPrivnoPriv

            私人私有密钥""""""

            私人公开密钥""""""

            表9:代理机构的参与者信息

            上下文代理目的代理源代理上下文

            ducksoupharpon/an/a

            表10:代理机构的代理关系

            身份grouchochico

            (管理者)(代理人)

            域snmpUDPDomainsnmpUDPDomain

            地址 1.2.3 .4,2 0021.2.3 .5,161

            认证端口v2md5AuthProtocolv2md5AuthProtocol

            认证私有密钥"0123456789ABCDEF""GHIJ KL 0123456789"

            认证公开密钥""""

            认证时钟00

            认证生命周期300300

            私有端口noPrivnoPriv

            私人私有密钥""""

            私人公开密钥""""

            表11:管理站的参与者信息

            目标主题上下文权限

            chicogrouchoducksoup35(Get,GetNext&GetBulk)

            grouchochicoducksoup132(Response&SNMPv2-Trap)

            表12:外部代理的访问访问信息

            向在表9中的介绍，代理机构的参与者在IP地址为 1.2.3 .5、UDP端口为161上用            身份chico操作；同时，这个例子中的管理者在IP地址为 1.2.3 .5、UDP端口为2002上用身份groucho操作.Groucho和chico认证所有的关于他们使用v2md5AuthProtocol协议生成的信息和他们截然不同的、私有的认证密钥.虽然他们的私有认证密钥值("0123456789ABCDEF"和"GHIJ KL 0123456789")在这里因为解释            的目的而出现了.但私有密钥的信息一般是不会告诉人们的，并且对请求它的协议的执行也是有限制的.            参与者harpo不会发送或接收SNMPv2协议信息；进一步说，所有与参与者的通讯信息是通过一个假设的私有协议来确认的，该私有协议是由acmeMgmtPrtcl的值来确认的.由于参与者harpo不参与到SNMPv2中，许多为该参与者记录在本地数据库中的诸属性均被忽略.

            表10表明了相互了解的代理的代理关系.更详细的说，SNMPv2上下文ducksoup            指一个这样的关系：参与者harpo感到满意的关系.（这个代理的目的地的参与者的传输域决定了代理源的解释和代理上下文的确认---在这种情况下，用acmeMgmtPrtcl表明代理源和上下文是可以忽略的）            为了询问与参与者harpo相关的私有设备，管理站的groucho构造了一个SNMPv2 的GetNext请求，其中包含一个SnmpMgmtCom的值，该值是参考SNMPv2的上下文ducksoup，并且传输它给在IP地址为 1.2.3 .5、UDP端口为161的参与者chico.该请求是用私有认证密钥“0123456789ABCDEF”来认证的. 当该请求被参与者chico接收到后，消息的发起者作为参与者groucho通过使用本地信息（见表9）的私有密钥“0123456789ABCDEF”来效验.由于参与者groucho通过发布一个通过访问控制策略（见表12）对参与者chico和SNMPv2的上下文ducksoup的GetNext（也可以是Get、GetBulk）请求来获得认证.从而该请求获得认可.由于上下文信息的本地数据库指明了SNMPv2的上下文ducksoup是参考了一个代理关系，这个请求可通过直接翻译到参与者harpo的合适的操作acmeMgmtPrtcl上来获得确认.这些新的操作传输到参与者harpo的acmeMgmtPrtcl的域上的0x98765432地址上.

            代理和私有设备之间私有协议的交流要求：一个SNMPv2响应管理操作是通过参            与者chico转发参与者grpucho的结果而不是参考SNMPv2的上下文ducksoup.这个响应通讯是为了原始的和完整性的认证，可通过在参与者chico的传输中指明使用认证协议“v2md5AuthProtocol”和私有认证密钥“GHIJ KL 0123456789 ” 来实现.它传输给在管理站点的SNMPv2参与者groucho，其IP地址为 1.2.3 .4、UDP端口为2002（相应请求的源地址）.

            当参与者groucho接受到这个响应后，参与者chico通过使用本地私有认证密钥            信息（见表11）“GHIJ KL 0123456789 ” 来效验发起者的信息.由于参与者chico可根据相关访问策略（见表12），再通过发布关于参与者groucho和SNMPv2上下文ducksoup 的响应通讯来认证，其响应获得认可，同时结束对私有设备的询问.

            通过观察记录管理站在代理机构（表9）上既不是静态的、也不是专有配置的本地数据库的参与者信息是很重要的.例如，在这个例子中，假设acmeMgmtPrtcl是一个管理站连接到局域网上的私有的MAC-layer机构.在这样的环境下，SNMPv2参与者chico想驻留在连接到LAN的SNMPv2代理机构，通过局域网协议的参与，去发现附件和未连接到局域网上的各类站点.在这中情况下，SNMPv2代理很容易调整它的本地参与者的数据库信息，达到通过SNMPv2管理站点来支持不是直接受局域网管理的站点.对每个新发现的局域网站点，SNMPv2代理可以把它作为一个类似于参与者harpo（代表局域网本身的）的条目添加它到参与者信息的本地数据库中，也可以添加它到上下文信息的本地数据库中，作为一个类似于SNMPv2的上下文ducksoup（代表在SNMPv2域中新站点的代理关系）的条目来处理.

            由SNMPv2代理机构通过使用SNMPv2来询问参与者的本地数据库信息，只要有新            站点连接到局域网上来.一个SNMPv2管理站能够发现和影响它们，

            4.4.2 本地代理配置

            该段介绍了一个关于配置支持SMPv2本地代理操作的例子.即在一个SNMPv2代理            和一个要通过次要SNMPv2代理仲裁的管理站之间进行非直接交互的操作.该例子的配置和上面的外部代理的介绍是类似的.在这个例子中，无论如何，与身份为harpo相关的参与者通过SNMPv2接收消息，并且和SNMPv2代理chico用认证的SNMPv2通讯来进行交互.

            表13介绍了关于SNMPv2参与者的信息，它记录在SNMPv2代理的代理信息的本地            数据库中.表14介绍了关于记录在SNMPv2代理的上下文信息的本地数据库中的代理关系信息.表11介绍了关于记录在SNMPv2管理站点的参与者信息的本地数据库中SNMPv2参与者信息.表15介绍了关于在本地管理中指明的访问策略的数据库信息.

            身份grouchochico

            (管理者)(代理)

            域snmpUDPDomainsnmpUDPDomain

            地址 1.2.3 .4,2 0021.2.3 .5,161

            认证端口v2md5AuthProtocolv2md5AuthProtocol

            认证私有密钥"0123456789ABCDEF""GHIJ KL 0123456789"

            认证公开密钥""""

            认证时钟00

            AuthLifetime300300

            PrivProtnoPrivnoPriv

            PrivPrivKey""""

            PrivPubKey""""

            Identityharpozeppo

            (代理目的)(代理源)

            DomainsnmpUDPDomainsnmpUDPDomain

            Address 1.2.3 .6,1611.2.3.5,161

            AuthProtv2md5AuthProtocolv2md5AuthProtocol

            AuthPrivKey"MNOPQR0123456789""STUVWX0123456789"

            AuthPubKey""""

            AuthClock00

            AuthLifetime300300

            PrivProtnoPrivnoPriv

            PrivPrivKey""""

            PrivPubKey""""

            表13:代理的参与者信息

            上下文代理目的代理源代理上下文

            ducksoupharpozeppobigstore

            bigstoregrouchochicoducksoup

            表14:代理的代理关系

            目标主体ContextPrivileges

            chicogrouchoducksoup35(Get,GetNext&GetBulk)

            grouchochicoducksoup132(Response&SNMPv2-Trap)

            harpozeppobigstore35(Get,GetNext&GetBulk)

            zeppoharpobigstore132(Response&SNMPv2-Trap)

            表15:本地代理的访问信息

            在表13中介绍说，代理的参与者在IP地址为 1.2.3 .5、UDP端口为161上用身份            chico来操作的.该例子的管理者在IP地址为 1.2.3 .4、UDP端口为2002上用身份 groucho来操作的.；代理源参与者在IP地址为 1.2.3 .5、UDP端口为161上用身份zeppo 来操作的.；代理目的参与者在IP地址为 1.2.3 .6、UDP端口为161上用身份harpo来操作的.4个SNMPv2参与者的认证产生的信息是为了保证原始性和完整性，他们使用了认证协议v2md5AuthProtocol和不同的私有认证密钥.虽然这些私有认证密钥的值("0123456789ABCDEF","GHIJ KL 0123456789","MNOPQR0123456789"和"STUVWX0123456789")在这里描述出来了，但私有密钥的信息一般是不能告诉人们的，同时要限制一些请求它协议操作.

            表14介绍了相互了解的代理机构间代理关系，更具体的讲，SNMPv2上下文            ducksoup是参考这样一个关系的：被SNMPv2参与者zeppo和SNMPv2参与者harpo的通讯认可了，同时也参考了SNMPv2的上下文bigstore.为了询问与参与者harpo相关的代理设备，管理站点groucho构造一个SNMPv2的GetNext请求，该请求中包含了参考SNMPv2的上下文ducksoup的SnmpMgmtCom值，并            且传输给在IP为 1.2.3 .5、UDP端口为161的（见表11）参与者chico，这个请求是用私有认证密钥“0123456789ABCDEF”来认证的. 当参与者chico收到请求时，消息的发起者是通过参与者grouhco使用本地信息（见表13）关于私有认证密钥“0123456789ABCDEF”来校验的.由于参与者groucho 是通过发布GetNext（也可以是get和getbulk）请求来认证的，该发布是参考了参与者chico和相关访问控制策略（见表15）的SNMPv2上下文ducksoup，故该请求被接受. 由于上下文信息的本地数据库指明了参考代理关系的SNMPv2上下文ducksoup，这个 通过翻译为一个从参与者zeppo到参与者harpo的相应SNMPv2的GetNext请求，同时也参考了SNMPv2的上下文bigstore的请求，是可以得到确认的.通过使用私有认证           “STUVWX 0123456789 ” 来认证新的通讯和传输到IP地址为 1.2.3 .6的参与者harpo. 当新的请求被参与者harpo收到时，消息的发起者是通过参与者zeppo使用本地信息（见表13）关于私有认证密钥“STUVWX 0123456789 ” 来校验的.由于参与者zeppo 是通过发布GetNext（也可以是get和getbulk）请求来认证的，该发布参考了参与者 harpo和相关访问控制策略（见表15）的SNMPv2上下文ducksoup，故该请求被接受. 描述了询问结果的SNMPv2响应消息是通过参与者harpo到参与者zeppo来生成的.并            参考了SNMPv2的上下文bigstore.这个响应通讯也是使用私有认证密钥“MNOPQR 0123456789 ” 来认证的，并传输给IP地址为 1.2.3 .5的参与者zeppo（相应的请求的源地址）

            当这个响应被参与者zeppo收到时，信息的发起者是通过参与者harpo使用本地            信息（见表13）关于私有认证密钥“MNOPQR 0123456789 ” 来校验的.由于参与者harpo是通过发布和响应通讯来认证的，该通讯参考了参与者zeppo和通过相关的访问控制策略（表15）SNMPv2的上下文bigstore，响应是可以接受的.并且它是对原始的 GetNext请求构造响应，表明为一个ducksoup的SNMPv2上下文.从参与者chico到参与者groucho响应的原始性和完整性通过使用私有认证密钥“GHIJ KL 0123456789 ” 来认            证的，并传输给IP地址为 1.2.3 .5的参与者groucho（相应原始请求的源地址）.当这个响应被参与者groucho收到时，消息的发起者是通过参与者chico使用本地信息（见表13）关于私有认证密钥“GHIJ KL 0123456789 ” 来校验的.由于参与者chico是通过了发布和响应通讯来认证的，该通讯又参考了参与者groucho和通过相关的访问控制策略（表15）SNMPv2的上下文ducksoup，故响应是可以接受的.并且可完成询问.

            4.5公共密钥配置

            这段介绍了一个关于假设的安全协议的配置的例子.这个假设协议将基于不对称（公开密钥）的密码技术，把它作为一个提供数据原始性的认证（不保证会保护不被暴光）.这个例子说明了用公开密钥技术的管理模型的一致性，并且在例子范围内支持保护不被暴光. 身份olliestan

            (代理t)(管理者)

            域snmpUDPDomainsnmpUDPDomain

            地址 1.2.3 .4,1611.2.3.5,2004

            AuthProtpkAuthProtocolpkAuthProtocol

            AuthPrivKey"0123456789ABCDEF"""

            AuthPubKey"0123456789abcdef""ghij kl 0123456789"

            AuthClock00

            AuthLifetime300300

            PrivProtnoPrivnoPriv

            PrivPrivKey""""

            PrivPubKey""""

            表16:公开密钥代理的参与者信息

            这个例子的配置由单一的SNMPv2代理组成，它是和单一的SNMPv2管理站点相互    作用影响的.表16和17介绍了关于SNMPv2的参与者通过代理和管理者的信息，另外表 5介绍的关于对管理者和代理的本地访问策略的信息.

            身份olliestan

            (agent)(manager)

            域snmpUDPDomainsnmpUDPDomain

            Address 1.2.3 .4,1611.2.3.5,2004

            AuthProtpkAuthProtocolpkAuthProtocol

            AuthPrivKey"""GHIJ KL 0123456789"

            AuthPubKey"0123456789abcdef""ghij kl 0123456789"

            AuthClock00

            AuthLifetime300300

            PrivProtnoPrivnoPriv

            PrivPrivKey""""

            PrivPubKey""""

            表17:公开密钥管理站点的参与者信息

            在表16中，使用身份为ollie的代理的参与者在IP为 1.2.3 .4、UDP的端口为161            上上操作；使用身份stan的管理者的参与者在IP为 1.2.3 .5、UDP的端口为2004上操作；ollie和stan认证所有由他们生成的信息，通过用假设的SNMPv2认证协议与他们截然不同的私有认证密钥来保证其原始性和完整性.这些私有认证密钥的值（"0123456789ABCDEF"和"GHIJ KL 0123456789"）在这里说明仅仅是为了解释的目的，私有密钥通常是不能告诉人们的，并且访问它们协议的执行也有部分限制.

            在更多的方面，在上述的这个小的安全SNMPv2代理中，管理和代理之间的相互            影响在它们的配置中总是同样的.最主要的不同不是SNMPv2的参与者在公共密钥的配置中有这样的信息：可以通过其他参与者来认证其通讯来了解关于私有密钥的信息，相反的，对每个收到的认证SNMPv2信息，发起者的身份是通过应用一个不对称加密技术算法对收到的信息和发起者的公开密钥一起来确认的.因此，在配置中，代理知道管理的公开密钥（“ghij kl 0123456789 ” ）但不知道它的私有密钥            ("GHIJ KL 0123456789")；类似地，管理者知道代理的公开密钥（“0123456789abcdef”）而不知道自己的私有密钥("0123456789ABCDEF").

            5.安全考虑

            为了参与在管理模型中说明这个备忘录，SNMPv2的执行必须支持在参与者信息            的本地数据库方面具有本地的、稳定存储的能力.相应地，每次尝试的操作必须小到稳定存储的数目之内.

            6.感谢

            该文档是基本上基于RFC1351而来的.

           7.参考

            [1]Case,J.,Fedor,M.,Schoffstall,M.,Davin,J.,"Simple

            NetworkManagementProtocol",STD15,RFC 1157 ,SNMP

            Research,PerformanceSystemsInternational,MIT

            LaboratoryforComputerScience,May1990.

            [2]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,            "ProtocolOperationsforversion2oftheSimpleNetwork

            ManagementProtocol(SNMPv2)",RFC1448,SNMPResearch,

            Inc.,HughesLANSystems,DoverBeachConsulting,Inc.,

            CarnegieMellonUniversity,April1993.

            [3]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,            "StructureofManagementInformationforversion2ofthe

            SimpleNetworkManagementProtocol(SNMPv2)",RFC1442,

            SNMPResearch,Inc.,HughesLANSystems,DoverBeach

            Consulting,Inc.,CarnegieMellonUniversity,April1993.

            [4]McCloghrie,K.,andGalvin,J.,"PartyMIBforversion2

            oftheSimpleNetworkManagementProtocol(SNMPv2)",RFC

            1447,HughesLANSystems,TrustedInformationSystems,

            April1993.

            [5]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,

            "TransportMappingsforversion2oftheSimpleNetwork

            ManagementProtocol(SNMPv2)",RFC1449,SNMPResearch,

            Inc.,HughesLANSystems,DoverBeachConsulting,Inc.,

            CarnegieMellonUniversity,April1993.

            [6]Galvin,J.,andMcCloghrie,K.,"SecurityProtocolsfor

            version2oftheSimpleNetworkManagementProtocol

            (SNMPv2)",RFC1446,TrustedInformationSystems,Hughes

            LANSystems,April1993.

            [7]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,

            "ManagementInformationBaseforversion2oftheSimple

            NetworkManagementProtocol(SNMPv2)",RFC1450,SNMP

            Research,Inc.,HughesLANSystems,DoverBeach

            Consulting,Inc.,CarnegieMellonUniversity,April1993.

 

 

            8.作者地址

            JamesM.Galvin

            TrustedInformationSystems,Inc.

            3060WashingtonRoad,Route97

            Glenwood,MD21738

            Phone:+1301854-6889

            EMail:galvin@tis.com

            KeithMcCloghrie

 

            HughesLANSystems

 

            1225CharlestonRoad

 

            MountainView,CA94043

 

            US

 

            Phone:+14159667934

 

            Email:kzm@hls.com

 

 

SNMP管理信息库MIB

作者: 未知 来源: 中国协议分析网

  管理信息库MIB指明了网络元素所维持的变量（即能够被管理进程查询和设置的信息）。MIB给出了一个网络中所有可能的被管理对象的集合的数据结构。SNMP的管理信息库采用和域名系统DNS相似的树型结构，它的根在最上面，根没有名字。图3画的是管理信息库的一部分，它又称为对象命名（objectnamingtree）。

 

  图3管理信息库的对象命名举例

  对象命名树的顶级对象有三个，即ISO、ITU-T和这两个组织的联合体。在ISO的下面有4个结点，其中的饿一个（标号3）是被标识的组织。在其下面有一个美国国防部（Department of Defense）的子树（标号是6），再下面就是Internet（标号是1）。在只讨论Internet中的对象时，可只画出Internet以下的子树（图中带阴影的虚线方框），并在Internet结点旁边标注上{ 1.3.6 .1}即可。

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

  最初的结点mib将其所管理的信息分为8个类别，见表1。现在de mib-2所包含的信息类别已超过40个。

  表1 最初的结点mib管理的信息类别

 

类别	标号	所包含的信息
system   interfaces   address translation   ip   icmp   tcp   udp   egp	(1)   (2)   (3)   (4)   (5)   (6)   (7)   (8)	主机或路由器的操作系统   各种网络接口及它们的测定通信量   地址转换（例如ARP映射）   Internet软件（IP分组统计）   ICMP软件（已收到ICMP消息的统计）   TCP软件（算法、参数和统计）   UDP软件（UDP通信量统计）   EGP软件（外部网关协议通信量统计）

应当指出，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}等。世界上任何一个公司、学校只要用电子邮件发往iana-mib@isi.edu进行申请即可获得一个结点名。这样各厂家就可以定义自己的产品的被管理对象名，使它能用SNMP进行管理。

SNMP的5种协议数据单元

作者: 未知 来源: 中国协议分析网

  SNMP规定了5种协议数据单元PDU（也就是SNMP报文），用来在管理进程和代理之间的交换。get-request操作：从代理进程处提取一个或多个参数值get-next-request操作：从代理进程处提取紧跟当前参数值的下一个参数值set-request操作：设置代理进程的一个或多个参数值get-response操作：返回的一个或多个参数值。这个操作是由代理进程发出的，它是前面三种操作的响应操作。trap操作：代理进程主动发出的报文，通知管理进程有某些事情发生。

  前面的3种操作是由管理进程向代理进程发出的，后面的2个操作是代理进程发给管理进程的，为了简化起见，前面3个操作今后叫做get、get-next和set操作。图4描述了SNMP的这5种报文操作。请注意，在代理进程端是用熟知端口161俩接收get或set报文，而在管理进程端是用熟知端口162来接收trap报文。

 

  图4 SNMP的5种报文操作

  图5是封装成UDP数据报的5种操作的SNMP报文格式。可见一个SNMP报文共有三个部分组成，即公共SNMP首部、get/set首部trap首部、变量绑定。

 

  5 SNMP报文格式

  （1）公共SNMP首部

  共三个字段：

 版本l 

  写入版本字段的是版本号减1，对于SNMP（即SNMPV1）则应写入0。

 共同体（community）l 

  共同体就是一个字符串，作为管理进程和代理进程之间的明文口令，常用的是6个字符“public”。

 PDU类型l 

  根据PDU的类型，填入0～4中的一个数字，其对应关系如表2所示意图。

  表2 PDU类型

 

PDU类型	名称
0	get-request
1	get-next-request
2	get-response
3	set-request
4	trap

2）get/set首部

 请求标识符(request ID)l 

  这是由管理进程设置的一个整数值。代理进程在发送get-response报文时也要返回此请求标识符。管理进程可同时向许多代理发出get报文，这些报文都使用UDP传送，先发送的有可能后到达。设置了请求标识符可使管理进程能够识别返回的响应报文对于哪一个请求报文

 差错状态（error status）l 

  由代理进程回答时填入0～5中的一个数字，见表3的描述

  表3 差错状态描述

 

差错状态	名字	说明
0	noError	一切正常
1	tooBig	代理无法将回答装入到一个SNMP报文之中
2	noSuchName	操作指明了一个不存在的变量
3	badValue	一个set操作指明了一个无效值或无效语法
4	readOnly	管理进程试图修改一个只读变量
5	genErr	某些其他的差错

 差错索引(error index)l

  当出现noSuchName、badValue或readOnly的差错时，由代理进程在回答时设置的一个整数，它指明有差错的变量在变量列表中的偏移。

  （3）trap首部

 企业（enterprise）l 

  填入trap报文的网络设备的对象标识符。此对象标识符肯定是在图3的对象命名树上的enterprise结点{ 1.3.6 .1.4.1}下面的一棵子树上。

 trap类型l 

  此字段正式的名称是generic-trap，共分为表4中的7种。

 

trap类型	名字	说明
0	coldStart	代理进行了初始化
1	warmStart	代理进行了重新初始化
2	linkDown	一个接口从工作状态变为故障状态
3	linkUp	一个接口从故障状态变为工作状态
4	authenticationFailure	从SNMP管理进程接收到具有一个无效共同体的报文
5	egpNeighborLoss	一个EGP相邻路由器变为故障状态
6	enterpriseSpecific	代理自定义的事件，需要用后面的“特定代码”来指明

  当使用上述类型2、3、5时，在报文后面变量部分的第一个变量应标识响应的接口。

 特定代码(specific-code)l 

  指明代理自定义的时间（若trap类型为6），否则为0。

 时间戳(timestamp)l 

  指明自代理进程初始化到trap报告的事件发生所经历的时间，单位为10ms。例如时间戳为1908表明在代理初始化后1908ms发生了该时间。

  （4）变量绑定(variable-bindings)

  指明一个或多个变量的名和对应的值。在get或get-next报文中，变量的值应忽略。