SNMP网络管理体系结构Word下载.docx

上传人:b****6 文档编号:19368804 上传时间:2023-01-05 格式:DOCX 页数:45 大小:171.62KB
下载 相关 举报
SNMP网络管理体系结构Word下载.docx_第1页
第1页 / 共45页
SNMP网络管理体系结构Word下载.docx_第2页
第2页 / 共45页
SNMP网络管理体系结构Word下载.docx_第3页
第3页 / 共45页
SNMP网络管理体系结构Word下载.docx_第4页
第4页 / 共45页
SNMP网络管理体系结构Word下载.docx_第5页
第5页 / 共45页
点击查看更多>>
下载资源
资源描述

SNMP网络管理体系结构Word下载.docx

《SNMP网络管理体系结构Word下载.docx》由会员分享,可在线阅读,更多相关《SNMP网络管理体系结构Word下载.docx(45页珍藏版)》请在冰豆网上搜索。

SNMP网络管理体系结构Word下载.docx

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的最具特色的内容。

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,之上实现。

  每个代理者也必须实现SNMP、UDP和IP。

另外,有一个解释SNMP的消息和控制代理者MIB的代理者进程。

图SNMP的协议环境

  图描述了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)服务。

  图显示了常见的一类协议体系结构。

管理站向代管代理者发出对某个设备的查询。

代管代理者将查询转变为该设备使用的管理协议。

当代理者收到对一个查询的应答时,将这个应答转发给管理站。

类似地,如果一个来自托管设备的事件通报传到代理者,代理者以陷阱消息的形式将它发给管理站。

图SNMP协议体系结构

SNMP管理信息

与CMIP体系相同,SNMP的基础是包含被管元素信息的被称为MIB的数据库。

每个被管资源由对象来表示,MIB是这些对象的有结构的集合。

在SNMP中,MIB本质上是一个树型的数据库结构。

网络中每个的系统都(工作站、服务器、路由器、网桥等)拥有一个反映系统中被管资源状态的MIB。

网络管理实体可以通过提取MIB中的对象值监测系统中的资源,也可以通过修改这些对象值来控制资源。

管理信息结构

SNMP的规范SMI(structureofmanagementinformation)为定义和构造MIB提供了一个通用的框架。

同时也规定了可以在MIB中使用的数据类型,说明了资源在MIB中怎样表示和命名。

SMI的基本指导思想是追求MIB的简单性和可扩充性。

因此,MIB只能存储简单的数据类型:

标量和标量的二维矩阵。

我们将看到SNMP只能提取标量,包括表中的单独的条目。

SMI避开复杂的数据类型是为了降低实现的难度和提高互操作性。

但在MIB中不可避免地包含厂家建立的数据类型,如果对这样的数据类型的定义没有严格的限制,互操作性也会受到影响。

为了提供一个标准的方法来表示管理信息,SMI必须:

提供一个标准的技术定义MIB的具体结构;

提供一个标准的技术定义各个对象,包括句法和对象值;

提供一个标准的技术对对象值进行编码。

1)MIB结构

SNMP中的所有的被管对象都被排列在一个树型结构之中。

处于叶子位置上的对象是实际的被管对象,每个实际的被管对象表示某些被管资源、活动或相关信息。

树型结构本身定义一个将对象组织到逻辑上相关的集合之中的方法。

MIB中的每个对象类型都被赋予一个对象标识符(OBJECTIDENTIFIER),以此来命名对象。

另外,由于对象标识符的值是层次结构的,因此命名方法本身也能用于确认对象类型的结构。

对象标识符是能够唯一标识某个对象类的符号。

它的值由一个整数序列构成。

被定义的对象的集合具有树型结构,树根是引用标准的对象。

从对象标识符树的树根开始,每个对象标识符成分的值指定树中的一个弧。

从树根开始,第一级有3个节点:

iso、ccitt、joint-iso-ccitt。

在iso节点下面有一个为“其他组织”使用的子树,其中有一个美国国防部的子树(dod)。

SNMP在dod之下设置一个子树用于Internet的管理。

如下所示:

internetOBJECTIDENTIFIER:

:

={iso

(1)org(3)dod(6)1}

因此,internet节点的对象标识符的值是。

这个值作为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协议的如下特性:

协议在成为标准之前进行大量的实验性的使用和调测。

图对象标识符树型结构

2)对象句法

SNMPMIB中的每个对象都由一个形式化的方法定义,说明对象的数据类型、取值范围以及与MIB中的其他对象的关系。

各个对象以及MIB的整体结构都由描述法定义。

为了保持简单,只利用了的元素和特征的一个有限的子集。

UNIVERSAL类型:

的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类型:

的APPLICATION类由与特定的应用相关的数据类型组成。

每个应用,包括SNMP,负责定义自己的APPLICATION数据类型。

在SNMP中已经定义了以下数据类型:

networkaddress:

该类型用CHOICE结构定义,允许从多个协议族的地址格式中进行选择。

目前,只定义了IpAddress一种地址格式。

ipaddress:

IP格式的32位地址。

counter:

只能做增值不能做减值运算的非负整数。

最大值被设为232–1,当达到最大值时,再次从0开始增加。

gauge:

可做增值也可做减值运算的非负整数。

最大值被设为232–1,当达到最大值时被锁定,直至被复位(reset)。

timeticks:

从某一参照时间开始以百分之一秒为单位计算经历的时间的非负整数。

当MIB中定义的某个对象类用到这个数据类型时,参照时间在该对象类的定义中指出。

opaque:

该数据类型提供一个传递任意数据的能力。

数据在传输时被作为OCTETSTRING编码。

被传递的数据本身可以是由或其他句法定义的任意的格式。

3)定义对象

管理信息库由一个对象的集合构成,每个对象都有一个型和一个值。

型是对被管对象种类的定义,因此型的定义是一个句法描述。

对象的实例是某类对象的一个具体实现,具有一个确定的值。

怎样定义MIB中的对象呢是将被使用的描述法。

中包含一些预定义的通用类型,也规定了通过现有类型定义新类型的语法。

定义被管对象的一个可选方法是定义一个被称为Object的新类型。

这样,MIB中所有的对象都将是这种类型的。

这个方法在技术上是可行的,但会产生定义不便于应用的问题。

我们需要多种值的类型,包括counter、gauge等等。

另外,MIB支持二维表格或矩阵的定义。

因此,一个通用的对象类型必须包含参数来对应所有这些可能性和选择性。

另一个更有吸引力的方法,并且也是被SNMP所实际采用的方法是利用宏(macro)对在被管对象定义中相互关联的类型进行集合定义。

一个宏的定义给出相关类型集合的句法,而宏的实例定义一个特定的类型。

因此定义被分为以下等级:

宏:

定义合法的宏实例,即说明相关集合类型的句法

宏实例:

通过为宏定义提供实际参数生成实例,即说明一个特定的类型

宏实例值:

用一个特定的值来表示一个特定的实体

图是OBJECT-TYPE宏的定义(引自RFC1212)。

图被管对象宏

其中的主要项目是:

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的冗长的文档中,因此,人们并不常使用它们。

比较常用的是更简捷的方法—基于树型结构和对象特性的表格表示的方法。

4)定义表格

SMI只支持一种数据结构化方法:

标量值条目的二维表格。

表格的定义用到的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强调保持网络管理简单性的特点。

即,在被管对象中,只包含相对应的被管实体的有限的和有用的信息。

图给出了tcpConnTable的定义(引自RFC1213)。

图TCPconnectionTable

在图中,可以看到sequence和sequenceof在定义表格时的应用:

整个表由一个SEQUENCEOFTcpConnEntry构成。

的结构SEQUENCEOF由一个或多个相同的元素构成,在本例中(在所有的SNMPSMI的情况下)每个元素是表中的一行。

每一行由一个指定了5个标量元素的SEQUENCE构成。

的结构SEQUCECE由固定数目的元素组成,元素的类型可以是多种。

尽管允许这些元素是可选的,但SMI限制这个结构只能使用“mandatory”元素。

在本例中,每一行所包含的元素的类型是INTEGER,IpAddress,INTEGER,IpAddress,INTERGE。

tcpConnEntry定义中的INDEX成分确定哪个对象值将被用于区分表中的各行。

在TCP中,一个socket(IP地址,TCP端口)可以支持多个connection,而任意一对sockets之间同时只能有一个connection。

因此为了明确地区分各行,每行中的后4个元素是必要的,也是充分的。

MIB-II

在TCP/IP网络管理的建议标准中,提出了多个相互独立的MIB,其中包含为Internet的网络管理而开发的MIB-II。

鉴于它在说明标准MIB的结构、作用和定义方法等方面的重要性和代表性,有必要对其进行比较深入的讨论。

MIB-II是在MIB-I的基础之上开发的,是MIB-I的一个超集。

mib-2组被分为以下分组:

system:

关于系统的总体信

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 表格模板 > 合同协议

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1