snmp v3的不错的资料【分享】
一SNMP v3概述SNMP v3定义了一种架构，用来把安全特性整合到SNMPv1或SNMP v2的整体功能中去。SNMP v3只是一个安全规范，没有定义其它新的SNMP功能，只为v1和v2提供安全方面的性能。SNMP v3由RFC 2271-RFC 2275描述。RFC描述了v3的整体框架和具体的消息结构及安全特性，但没有定义新的SNMP PDU格式，因此在新的结构中必须使用已有的SNMPv1或SNMP v2 PDU格式、SMI及主要的MIB。SNMP v3＝SNMP v2 + 安全+ 管理。 下面具体阐述SNMPV3的核心内容。
1．架构中的元素
架构中的元素包括：实体、标识、管理信息。以及这些元素的支持模块、技术。
1.1 实体
实体是SNMP的角色定义单位。一种角色是一个实体，比如，一个管理站是一个实体，一个代理是一个实体，一个代理和管理站二合一的应用也是一个实体，一个代理服务器也是一个实体。
一个实体包含一个SNMP引擎和相关应用程序。引擎和不同的应用程序组成，就构成了具有不同角色的实体。
图１：SNMP实体结构
1.1.1 引擎
实体的核心是SNMP引擎（engine）。什么是引擎？引擎这个词在IT行业见得多，但没见有几个人给他下过定义，大家经常听到：3D引擎、搜索引擎、网络引擎，什么是引擎？引擎这个词是从工业领域引入的。引擎就好像汽车的发动车，是汽车的动力所在，是汽车的核心功能。在发动机上装上必需的油路、电路、机械部件就可以制造一部汽车。站在制造发动机的角度上，能看到引擎也是由很多的部件构成。站在使用发动机装配汽车的角度上，我们只要看到发动机的功能和接口就可以了。这就是引擎，一个核心功能的集合体。
SNMP的引擎提供了：消息的发送、接收、鉴别、加密，并控制对管理对象的访问这些核心功能。
在引擎上配置不同的应用程序，就构成了不同的SNMP实体。
一个SNMP引擎包含下面功能模块：
分配器：1. 接收和发送SNMP消息；2. 通过SNMP消息体判断消息版本，并送到相应的消息处理子系统；3. 提供一个抽象的接口，以便向应用程序转发SNMP消息；4. 提供一个抽象的接口，使应用程序可以向另外的SNMP实体发送消息。
消息处理系统：1. 从接收到的消息里提取数据、组装准备发送的消息；2. 包含不同版本消息处理子模块，实现简单扩展和模块化，每一个子模块负责一个版本的消息处理。
图２：消息处理子系统
安全系统：提供安全功能，例如鉴别和加密。安全系统包括安全协议，安全协议定义了安全机制、实现过程、MIB数据。
图３：安全子系统
访问控制系统：提供了对设备的访问的控制模式。当前SNMP采用的是基于视图的访问控制模型。
图４：访问控制子系统
snmpEngineId
一个SNMP实体都包含一个SNMP引擎，那么就为引擎赋一个唯一的、明确的标识来标记这个引擎。因为引擎和实体是一一对应的关系，故此，此ID也唯一地标识了SNMP实体。
snmpSecurityModel
安全子系统的安全模型的唯一标识符，可能的取值包括SNMPv1、SNMPv2c和USM，它用原语规范定义，语法为Integer。用来指出相应引擎中的安全子系统使用的安全模型。
1.1.2 应用程序
应用程序是一种高级别的程序，实现高级别的管理功能，与SNMP引擎一起构成SNMP实体。
应用程序有下面几种：
命令发生器：产生指令操作MIB数据（用于管理站）。
命令响应器：响应MIB数据操作指令（用于代理）。
通告接收器：向外发出trap（用于代理）。
通告产生器：处理trap（用于管理站）。
代理服务器：在不同实体间转发消息（用于代理服务器）。
1.1.3 SNMP管理站
一个管理站有一个或若干个命令发生器或通告接收器，和他的SNMP引擎一起被叫做“SNMP管理站”。
图５：SNMP管理站结构
1.1.4 SNMP代理
代理是在引擎上运行：命令响应器、通告产生器、代理服务器的SNMP实体，代理还维护MIB。
图６：SNMP代理结构
1.2 术语
1.2.1 Principal
要素，提供服务或进行处理所代表的实体，要素可以是执行特定角色的个体、一系列个体、每一个执行特定的角色、一个应用程序或者一系列应用程序，以及它们的组合。一个管理站对一个代理进行访问，对这个代理来讲，这个管理站就是他的Principal；一个代理向管理站发送trap，则这个代理就是此管理站的Principal。
1.2.2 securityName
可读字符串，标识使用到的安全模块名称。如，SNMP使用共同体作为安全模式，则securityName应该为相应的community。在v3中，securityName等于username。
它作为参数传送到所有的SNMP模块中（调度器、消息处理、安全、访问控制）。
1.2.3 Module-dependent security ID
模式依赖安全ID，一个依赖于模式的ID，用来描述一个具体安全模式中的securityName。模式依赖ID可以是可读的，也可以是不可读的，并且有一个模式依赖的类型。比如，community names(共同体)、user names(用户名)。安全ID和securityName可以在相关模式的原则下相互转换。
要素、securityName、模式依赖安全ID的结构图为：
图７：要素、安全名、模式依赖安全ID结构
1.3 MIB
管理信息存在于一个SNMP实体上，这个实体拥有一个命令响应器程序，能访问本地多个context（上下文）。命令响应器使用一个contextEngineID，值等于他的snmp引擎的snmpEngineID。
图８：MIB与Context
1.3.1 Context
context是一个可以被SNMP实体访问的管理信息集合，是一个本地概念，对本地实体管理的信息在实例一级的一个分类管理机制。如，本地实体管理两个网卡，那么，一般地来说，每一个网卡的管理信息就归属一个context管理，此管理就有管理两个context。每个网卡都有ifTable表中的一行实例数据。在表一级看，他们属于同一个表，但在设备一级看，他们分属于不同的设备，那么，他们分属于不同的context，context里有各自的ifTable一个实例。一般情况下，一个context是一个物理设备，或一个逻辑设备。虽然context也可以包括一系列设备或一个设备的一个子范围，亦或是一个多设备组成的管理范畴中的若干子范畴，但是，context一般用于单一的物理设备或逻辑设备。他是更高一层的MIB分类管理机制，以管理信息实例为单位对管理信息进行分类管理。
一个管理信息可以存在于不同的context里。一个代理实体可以有很多个context。为了标识一个管理域内单独的管理信息，contextName和contextEngineID就必须依据对象类型和对象实例被标识。如，ifDescr定义为一个网络接口的描述。标识一个设备x的描述需要4个信息：提供设备x管理信息访问的snmp实体的引擎snmpEngineID，contextName（设备x）,管理对象类型ifDexcr，和实例号（如1）。
contextEngineID和contextName明确地标识了管理域中的一个context。注意，也可能有不同的contextEngineID和contextName明确地标识相同的context.。
例如：SNMPv1 SNMPv2中提到的共同体，与MIB视图是相关的，比如read和write分别为两个视图，可以分配两个共同体。共同体因为不安全性，在后续的SNMP版本中被取代，相应的也将视图和context联系起来，read和write就可以分别做为一个context。
1.3.2 contextName
用于标识一个context，在一个SNMP引擎内部，contextName必须是唯一的。
1.3.3 contextEngineID
在一个管理域中，一个contextEngineID可以唯一地标识一个能识别一个contextName的实例的SNMP实体。一般等于snmpEngineID。因为context是定义在snmp引擎中的，所以，针对一个特定的contextName而言，它只能被所在的snmp引擎所认识，contextEngineID就是标识这个引擎的，从而使该contextName能被正确访问，这其实跟MIB管理树一样，从根到叶地访问，可以这样访问一个context：ip.snmpEngineID.contextEngineID.contextName，这样就唯一地标识了一个context。
1.3.4 scopedPDU
由contextEnginedID、contextName和snmp PDU组成的数据块，它作为一个参数被传输到安全子系统中或从安全子系统传送出来。这是站在管理框架下说的，SNMP v1和SNMP v2的消息就是snmp PDU部分。
1.4 其它构造
1.4.1 maxSizeResponseScopedPDU
应答的scopedPDU的最大长度。长度不包括SNMP消息头。
1.4.2 本地配置数据库
一个实体中的子系统、模型和应用程序可能需要保存他们的配置信息。部分配置信息可以被作为管理对象访问。
1.4.3 snmpSecurityLevel
这套构架支持3种安全级别：
无鉴别无加密，noAuthNoPriv
有鉴别无加密，authNoPriv
鉴别、加密，authPriv
每一个SNMP消息内有一个securityLevel字段。所有的子系统（消息处理、安全、访问控制）和应用程序需要能提供一个securityLevel值或按securityLevel值所定的安全级别处理消息。
都将被送到已经注册的支持这种组合的指令应答器中。指令应答器也能够使
2. SNMP应用程序
应用程序决定了实体的角色，比如，命令发生器和通告接收器加上一个SNMP引擎，构成了管理站的角色；命令响应器和通告产生器，构成了代理的角色。
我们使用抽象服务接口中定义的原语来描述应用程序的功能和行为，我们只给出简明的流程，细节都是实现时定义的，这些我想诸位开发人员有足够的理解能力与经验。
2.1 指令发生器
指令发生器生成get和set请求，并且处理请求相应的应答。
工作流程
指令发生器使用sendPdu和processResponsePDU调度器原语。sendPdu为调度器提供了目标地址、安全参数、和要发送的实际PDU消息。调度器然后调用消息处理模型，而消息处理模型又调用安全模型来准备一个消息。调度器把好的消息移交给传输层（如，UDP）用来传输。如果消息准备失败，则调度器返回的原语取值为sendPdu时表示出错。如果消息准备成功，调度器赋给该PDU一个sendPduHandle标识符并返回该取值给指令发生器，作为sendPdu的返回原语取值，指令发生器存储sendPduHandle以便随后的响应PDU能和原来的请求相匹配。
调度器利用processResponsePdu原语把每一个注入的响应PDU都交给正确的指令发生器应用。指令发生器要执行下面的步骤：
首先，指令发生器检查processResponsePdu原语中的参数，并把所接收到的messageProcessingModel、securityModel、secirutyName、contextEngineID、contextName、和pduVersion的取值与在相应requestPDU中的取值相比较（使用sendPduHancle来识别请求PDU）。如果不是所有的这些参数都匹配，则告丢弃该响应。如果statusInformation表示请求失败，则会有一个依赖于实现的动作发生，例如重发请求或者通知该要素。
然后，指令发生器检查响应PDU的内容。指令发生器提取出operation type、request-id、error-status、error-index和variable-bindings。如果request-id和原来请求中的取值不相等，则丢弃该响应
如果第一和第二步都成功，则指令发生器执行一个依赖于实现的动作。
2.2 指令应答器
指令应答器接收get和set请求，请求中的contextEngineID需要等于本地引擎ID，否则丢弃该请求。请求合法，指令应答器将执行适当的协议操作，使用访问控制，并且产生一个应答消息回应请求方。
工作流程
指令应答器要用到的四种调度原语（registerContextEngineID、unregisterContextEngineID、processPdu、returnResponsePdu）和一个访问控制子系统的原语（isAccessAllowed）。
为了处理上下文引擎中特定类型的PDU，应答器使用registerContextEngineID原语和一个SNMP引擎联系起来。一旦指令应答器完成注册，在所有接收到的消息中如果包含有已注册的contextEngineID和pduType（get或set）的组合，用unregisterContextEngineID来取消和SNMP引擎的联系。
调度器使用processPdu原语把流入的每一个请求PDU都递交给正确的指令应答器。指令应答器然后执行下面的步骤：
指令应答器检查request PDU的内容。PDU type必须和前面已注册过的类型中的一种相匹配。
相应的操作类型被识别出来后，将根据contextName指定的MIB视图进行访问。能访问的视图由securityLevel、securityModel、contextName、securityName和PDU type决定（PDU type指get或set，他们可能有不同的视图）。一个实际的对象实现是否在相关的MIB视图中，取决于isAccessAllowed接口。
如果允许访问，则指令应答器执行管理操作并准备一个response PDU。如果访问失败，则指令应答器准备一个合适的response PDU来通知失败。
一般情况下，管理操作的结果将产生一个新的PDU，并进入到下一步，但是，处理管理操作的过程中，下面的规则将被遵守：
如果isAccessAllowed返回一个noSuchView、noAccessEntry、或noGroupName错误，管理操作将挂起，一个PDU将从输入的原始PDU构造，只是使用一个authorizationError替换掉error-status，error-index还是0，流程进入到下一步。
如果isAccessAllowed返回一个otherError，管理操作将挂起，一个新的PDU将从原始PDU构造出来，使用genError替换error-status，error-index使用引起错误的变量在variable-binding中的索引，流程进入到下一步。
如果isAccessAllowed返回一个noSuchContext错误，管理操作将挂起，没有结果PDU被构造，snmpUnknownContexts计数器增加（MIB中定义了这个管理对象），流程进入到下一步，以产生一个错误报告。
如果contextName无效，管理操作将挂起，没有结果PDU构造，snmpUnavailableContexts计数器增加，流程进入到下一步，以产生一个错误报告。
指令应答器调用调度器，用returnResponsePDU原语来发送该response PDU。
命令应答器使用returnResponsePDU抽象服务接口来发送应答PDU时，如果操作包含错误，传入returnResponsePdu的PDU要包含相应的errorStatus 和errorIndex。
上一步描述了两个计数器，snmpUnknownContexts和snmpUnavailableContexts，不同点在于，snmpUnknownContexts是在给定的contextName在SNMP实体上未知，则计数器增加。snmpUnavailableContexts是contextName在实体上是已经的，正确的，但是当前context不可用，计数器才增加。Context是否可用是由实现定义的，一些实现可能永远也遇不上这种情况，所以记录也不会增加这个计数器。
应答器是按pduType注册的，也就是说，在一个引擎上，可以对不同的pdyType注册不同的应答器，另一个应答器对一个已经注册的pduType注册时将被拒绝。但是实际使用中，将只注册一个应答器，处理各种pduType。因为，注册多个应答器麻烦而且没有必要，SNMP本身就是简单网络管理协议，没有太复杂的功能。
接收到的PDU中并没有一个类型字段标识pdu type这个协议中的字段，这是ASN.1的一种结构类型，BER编码时可以体现，而在具体的PDU结构里，只是一个抽象概念，这点在协议一章和BER编码一章各有提到，这里强调一下，因为容易迷惑。
2.3 通告发生器
通告接收器监视一个系统的事件或条件，根据事件或条件产生消息。一个消息发生器必须有一个机制知道通告接收器的地址和接收器的SNMP版本和安全参数，以供发送通告时使用。本章后面会给出应用程序的MIB，提供了这个机制。在SNMPv3里，通告有两种类型，需要确认和不需要确认（inform和trap）。
工作流程
通告发生器应用也遵循指令发生器应用中用到的一般过程。如果要发送一个inform PDU，则要使用到sendPDU和processResponsePdu原语，使用方式和指令发生器应用中的一样。如果要发送一个trap PDU，则只用到sendPdu原语。
一个适当的过滤机制被允许去决定是否通告应该被发送到管理目标。如果这个过滤机制决定这个通告不应该发送，处理过程继续下一个管理目标。 适当的Variable-bindings集合从相关的MIB视图中的MIB机制中获取。相关的MIB视图由securityLevel、securityModel、contextName、securityName决定。决定是否一个实际的对象实例包含在相关的MIB视图中，使用isAccessAllowed接口，使用前面描述过的相同的习惯，除了viewType指出是一个通告类型操作。如果isAccessAllowed返回的statusInformation没有accessAllowed，通告将不被发送到管理目标。
通告的NOTIFICATION-TYPE对象标识（是variable-bindings变量绑定里名字为snmpTrapOID.0的对象的值）被isAccessAllowed检查，使用跟上一步操作相同的参数。如果isAccessAllowed返回的statusInformation没有指出accessAllowed，通告将不被发送。
一个PDU使用一个本身唯一的request-id值构造，PDU type由实现决定，error-status和error-index为０。
如果通告是非确认型，使用sendPdu接口发送。expectResponse参数指示不需要确认。
如果通告是确认型，使用sendPdu接口发送。expectResponse参数指示需要确认。
调度器被调用：
应用程序缓存管理目标信息。
如果在一个合适的时间间隔里，从管理目标的终点接收到一个应答，通告被确认，并且缓存信息删除，否则，
如果一个应答没有在一个合适的时间间隔里收到，或一个指示报告收到，管理目标的信息从缓存里被找到，重新发送。重试的次数由定义设定。如果尝试次数超标，通告认为发送失败，这个管理目标的通告处理将被挂起。注意，一些报告标识可以被认为是一个失败。这样的报告标识应该解释为通告失败的确认，应该重发通告。
需要确认的通告的应答，应该从processResonsePdu抽象服务接口收到。
通告发送到哪里，什么时候发送的步骤为：
决定通告要发送到的目标。
使用任何请求过滤去过滤目标列表。
决定哪个目标接收和鉴别通告。
2.4 通告接收器
通告接收器接收通告消息，如果通告是需要确认的（inform），就产生应答。
工作流程
通告接收程器遵循指令应答器中一般过程的一个子集。要接收Inform或trap PDU，通告接收器必须先注册。两种类型的PDU都通过sendPdu原语来接收。对于Inform PDU，则使用returnResponsePdu来进行响应。
当一个非确认通告传到通告接收器时，首先取出SNMP操作类型、request-id、error-status、error-index和variable-bindings，剩下的步骤依赖于具体的实现。
当一个需要确认的通告收到时：
取出PDU type，request-id、error-status、error-index、variable-bindings。
使用request-id、variable-bindings、取值为0的error-status、取值为0的error-index构造一个应答PDU。
调用分配器的returnResponsePdu接口发送应答PDU。
2.5 代理服务器
代理服务器有下列不同的作用：
１． 转发SNMP请求到其它的实体，不管访问控制设置，如，从一个管理域转发请求到另一个管理域，或将SNMP请求从一个版本转换成另一个版本。
２． 翻译SNMP请求到其它非SNMP协议。
３． 支持由其它远程管理信息组成的集合型管理信息的访问。
这些功能都应该由代理服务器实现，会带来很多好处。比如，支持集合型管理信息可以有效地减小带宽占用。
工作流程
代理服务器转发器应用程序使用调度原语来转发SNMP消息。代理服务器应用处于是下面四种基本类型的消息：
包含从指令发生器应用程序中得到的请求消息：代理服务器转发器确定目标SNMP引擎，或者是一个比较近或者是下游的引擎，并发送合适的request PDU。
包含从通告发生器应用程序中得到的请求消息：代理服务器转发器确定哪一个SNMP引擎应用接收通告，并发送合适的notification PDU。
包含一个response 类型的PDU的消息：代理服务器转发器确定哪一个是先前转发的请求或通告，如果有的话，与这个响应匹配，并发送合适的response PU。 包含一个report指示的消息：report PDU是SNMPv3中引擎到引擎的通信，代理服务器转发器确定哪一个是先前转发的请求或通告，如果有的话，与这个report指示相匹配，并把Report指示转回给请求或通告的引发者。
有四种类型的消息需要代理服务器转发，按照PDU type分，这四种基本类型消息是：
－ 包含Read-Class或Write-Class PDU type（如，Get、GetNext、GetBulk、Set）。
－ 通告类型的PDU（SNMPv2-Trap和Inform PDU）。
－ 应答的PDU类型。
－ 内部的PDU类型（如，报告PDU）。
前两种类型，PDU内部都包含了相关的context（contextEngineID、contextName等）信息，代理可以知道转发的路径。处理应答这些类型时，代理服务器的规则是要将应答和请求的PDU匹配，然后正确地应答出去。处理第四种类型时，也是要需要匹配报告消息和原始的请求操作，然后准确地应答出去。
转发消息时，代理服务器必须执行一个转换，将输入的管理目标转换为输出的管理目标，具体如何转换依赖实现指定。许多情况下，这将被预配置的转换表驱动，这时，需要使用SNMP-PROXY-MIB模块。
Thanks for your information. {:6_267:}{:6_268:}{:6_267:}{:6_268:}
页:
[1]