Snmp协议总结.docx
《Snmp协议总结.docx》由会员分享，可在线阅读，更多相关《Snmp协议总结.docx（19页珍藏版）》请在冰豆网上搜索。
Snmp协议总结
简单网络管理协议（SNMP：
SimpleNetworkManagementProtocol）是由互联网工程任务组（IETF：
InternetEngineeringTaskForce）定义的一套网络管理协议。
该协议基于简单网关监视协议（SGMP：
SimpleGatewayMonitorProtocol）。
利用SNMP，一个管理工作站可以远程管理所有支持这种协议的网络设备，包括监视网络状态、修改网络设备配置、接收网络事件警告等。
虽然SNMP开始是面向基于IP的网络管理，但作为一个工业标准也被成功用于电话网络管理。
1.网络管理
基于TCP/IP的网络管理包含两个部分：
网络管理站（也叫管理进程，managerStation）和被管的网络单元（也叫被管设备NetworkElement）。
被管设备种类繁多，例如：
路由器、X终端、终端服务器和打印机等。
这些被管设备的共同点就是都运行TCP/IP协议。
被管设备端和管理相关的软件叫做代理程序（agent）或代理进程。
管理站一般都是带有彩色监视器的工作站，可以显示所有被管设备的状态（例如连接是否掉线、各种连接上的流量状况等）。
管理进程和代理进程之间的通信可以有两种方式。
一种是管理进程向代理进程发出请求，询问一个具体的参数值（例如：
你产生了多少个不可达的ICMP端口）。
另外一种方式是代理进程主动向管理进程报告有某些重要的事件发生（例如：
一个连接口掉线了）。
当然，管理进程除了可以向代理进程询问某些参数值以外，它还可以按要求改变代理进程的参数值（例如：
把默认的IPTTL值改为64）。
基于TCP/IP的网络管理包含3个组成部分：
1）管理信息库MIB（ManagementInformationBase）。
管理信息库包含所有代理进程的所有可被查询和修改的参数。
RFC1213[McCloghrieandRose1991]定义了第二版的MIB，叫做MIB-II；
2）管理信息结构SMI（StructureofManagementInformation）
它是关于MIB的一套公用的结构和表示符号，这个在RFC1155[RoseandMcCloghrie1990]中定义。
例如：
SMI定义计数器是一个非负整数，它的计数范围是0~4294967295，当达到最大值时，又从0开始计数；
3）简单网络管理协议SNMP
管理进程和代理进程之间的通信协议，叫做简单网络管理协议SNMP（SimpleNetworkManagementProtocol）。
在RFC1157[Caseetal.1990]中定义。
SNMP包括数据报交换的格式等。
尽管可以在运输层采用各种各样的协议，但是在SNMP中，用得最多的协议还是UDP。
2.SNMP体系
SNMP采用了Client/Server模型的特殊形式：
代理/管理站模型。
对网络的管理与维护是通过管理工作站与SNMP代理间的交互工作完成的。
每个SNMP从代理负责回答SNMP管理工作站（主代理）关于MIB定义信息的各种查询。
图1是SNMP协议的实现模型。
图1SNMP协议的实现模型
3.SNMP报文种类
SNMP代理和管理站通过SNMP协议中的标准消息进行通信，每个消息都是一个单独的数据报。
SNMP使用UDP（用户数据报协议）作为第四层协议（传输协议），进行无连接操作。
SNMP规定了5种协议消息（也就是SNMP报文），用来在管理进程和代理之间的交换。
Get-Request：
从代理进程处提取一个或多个参数值；
Get-Next-Request：
从代理进程处提取紧跟当前参数值的下一个参数值；
Get-Response：
返回的一个或多个参数值，这个操作是由代理进程发出的，它是前面三种操作的响应操作。
SNMP管理站用Get-Request消息从拥有SNMP代理的网络设备中检索信息，而SNMP代理则用Get-Response消息响应。
Get-Next-Request用于和Get-Request组合起来查询特定的表对象中的列元素。
如：
首先通过下面的原语获得所要查询的设备的接口数：
{isoorg（3）dod（6）internet
（1）mgmt
（2）mib
（1）interfaces
（2）ifNumber
（2）}然后再通过下面的原语，进行查询（其中第一次用Get-Request，其后用Get-Next-Request）：
{isoorg（3）dod（6）internet
（1）mgmt
（2）mib
（1）interfaces
（2）ifTable
（2）}
Set-Request：
SNMP管理站用Set-Request可以对网络设备进行远程配置（包括设备名、设备属性、删除设备或使某一个设备属性有效/无效等）。
Trap：
SNMP代理使用Trap向SNMP管理站发送非请求消息，一般用于描述某一事件的发生。
前面的Request操作是由管理进程向代理进程发出的，后面的Response和Trap操作是代理进程发给管理进程的，为了简化起见，前面3个操作今后叫做get、get-next和set操作。
，在代理进程端是用熟知端口161接收get或set报文，而在管理进程端是用熟知端口162来接收trap报文。
4.SNMP报文格式
SNMP消息报文包含两个部分：
SNMP报头和协议数据单元PDU。
图2SNMP报文格式
图2是封装成UDP数据报的5种操作的SNMP报文格式。
可见一个SNMP报文共有三个部分组成，即公共SNMP首部、get/set首部trap首部、变量绑定。
版本识别符（versionidentifier）：
确保SNMP代理使用相同的协议，每个SNMP代理都直接抛弃与自己协议版本不同的数据报。
团体名（CommunityName）：
用于SNMP从代理对SNMP管理站进行认证；如果网络配置成要求验证时，SNMP从代理将对团体名和管理站的IP地址进行认证，如果失败，SNMP从代理将向管理站发送一个认证失败的Trap消息（见后）;
协议数据单元（PDU）：
其中PDU指明了SNMP的消息类型及其相关参数。
4.1公共SNMP首部
版本写入版本字段的是版本号减1，对于SNMP（即SNMPV1）则应写入0。
共同体（community）共同体就是一个字符串，作为管理进程和代理进程之间的明文口令，常用的是6个字符“public”。
PDU类型根据PDU的类型，填入0～4中的一个数字，其对应关系如表1所示。
表1PDU类型PDU
PDU类型
0get-request
1get-next-request
2get-response
3set-request
4Trap
4.2get/set首部
请求标识符（requestID）这是由管理进程设置的一个整数值。
代理进程在发送get-response报文时也要返回此请求标识符。
管理进程可同时向许多代理发出get报文，这些报文都使用UDP传送，先发送的有可能后到达。
设置了请求标识符可使管理进程能够识别返回的响应报文对于哪一个请求报文。
差错状态（errorstatus）由代理进程回答时填入0～5中的一个数字，见表2的描述
表2查错状态描述表差错状态
差错状态名字说明
0noError一切正常
1tooBig代理无法将回答装入一个SNMP报文中
2noSuchName操作指明了一个不存在的变量
3badValue一个set操作指明了一个无效值或无效语法
4readOnly管理进程试图修改一个只读变量
5genErr某些其他的查错
差错索引（errorlindex）当出现noSuchName、badValue或readOnly的差错时，由代理进程在回答时设置的一个整数，它指明有差错的变量在变量列表中的偏移。
4.3trap首部
企业（enterprise）
填入trap报文的网络设备的对象标识符。
此对象标识符肯定是在图3的对象命名树上的enterprise结点{1.3.6.1.4.1}下面的一棵子树上。
trap类型此字段正式的名称是generic-trap，共分为表3中的7种。
表3trap类型说明trap类型
trap类型名字说明
0coldStart代理进行了初始化
1warmStart代理进行了重新初始化
2linkDown一个接口从工作状态变为故障状态
3linkUp一个接口从故障状态变为工作状态
4authenticationFailure从SNMP管理进程接收到具有一个无效共同体的报文
5egpNeighborLoss一个EGP相邻路由器变为故障状态
6enterpriseSpecific代理自定义的事件，需要用后面的“特定代码”来指明
当使用上述类型2、3、5时，在报文后面变量部分的第一个变量应标识响应的接口。
特定代码（specific-code）:
指明代理自定义的时间（若trap类型为6），否则为0。
时间戳（timestamp）:
指明自代理进程初始化到trap报告的事件发生所经历的时间，单位为10ms。
例如时间戳为1908表明在代理初始化后1908ms发生了该时间。
4.4变量绑定（variable-bindings）
指明一个或多个变量的名和对应的值。
在get或get-next报文中，变量的值应忽略。
5.管理信息库MIB
管理信息库MIB指明了网络元素所维持的变量（即能够被管理进程查询和设置的信息）。
MIB给出了一个网络中所有可能的被管理对象的集合的数据结构。
SNMP的管理信息库采用和域名系统DNS相似的树型结构，它的根在最上面，根没有名字。
图3画的是管理信息库的一部分，它又称为对象命名（objectnamingtree）。
图3管理信息库的对象命名举例
管理信息库MIB，就是所有代理进程包含的，能够被管理进程进行查询和设置的信息的结构。
IETF规定的管理信息库MIB（其中定义了可访问的网络设备及其属性，由对象标识符――OID：
ObjectIdentifier唯一指定）的一套公用的结构与表示符号称之为SMI。
MIB是一个树形结构，SNMP协议消息通过遍历MIB树形目录中的节点来访问网络中的设备。
对象命名是一种数据类型，它指明一种“授权”命名的对象。
“授权”的意思就是这些标识不是随便分配的，它是由一些权威机构进行管理和分配的。
对象标识是一个整数序列，以点（“.”）分隔。
这些整数构成一个树型结构，对象标识从树的顶部开始，顶部没有标识，以root表示。
图3显示了在SNMP中用到的这种树型结构。
所有的MIB变量都从1.3.6.1.2.1这个标识开始。
树上的每个结点同时还有一个文字名。
例如标识1.3.6.1.2.1就和iso.org.dod.internet.memt.mib对应。
这主要是为了人们阅读方便。
在实际应用中，也就是说在管理进程和代理进程进行数据报交互时，MIB变量名是以对象标识来标识的，当然都是以1.3.6.1.2.1开头的。
对象命名树的顶级对象有三个，即ISO、ITU-T和这两个组织的联合体。
在ISO的下面有4个结点，其中的一个（标号3）是被标识的组织。
在其下面有一个美国国防部（DepartmentofDefense）的子树（标号是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个类别，见表4。
现在的mib-2所包含的信息类别已超过40个。
表4最初的结点mib管理的信息类别类别
类别标号所包含的信息
system
（1）主机或路由器的操作系统
interfaces
（2）各种网络接口及它们的测定通信量
addresstranslation（3）地址转换（例如ARP映射）
ip（4）Internet软件（IP分组统计）
icmp（5）ICMP软件（已收到ICMP消息的统计）
tcp（6）TCP软件（算法、参数和统计）
udp（7）UDP软件（UDP通信量统计）
egp（8）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进行管理。
6.管理信息结构SMI
SNMP中，数据类型并不多。
这里我们就讨论这些数据类型，而不关心这些数据类型在实际中是如何编码的。
INTEGER
一个变量虽然定义为整型，但也有多种形式。
有些整型变量没有范围限制，有些整型变量定义为特定的数值（例如，IP的转发标志就只有允许转发时的或者不允许转发时的这两种），有些整型变量定义一个特定的范围（例如，UDP和TCP的端口号就从0到65535）；
OCTERSTRING
0或多个8bit字节，每个字节值在0～255之间。
对于这种数据类型和下一种数据类型的BER编码，字符串的字节个数要超过字符串本身的长度。
这些字符串不是以NULL结尾的字符串；
DisplayString
0或多个8bit字节，但是每个字节必须是ASCII码。
在MIB-II中，所有该类型的变量不能超过255个字符（0个字符是可以的）；
OBJECTIDENTIFIER
NULL代表相关的变量没有值。
例如，在get或get-next操作中，变量的值就是NULL，因为这些值还有待到代理进程处去取；
IpAddress
4字节长度的OCTERSTRING，以网络序表示的IP地址。
每个字节代表IP地址的一个字段；
PhysAddress
OCTERSTRING类型，代表物理地址（例如以太网物理地址为6个字节长度）；
Counter
非负的整数，可从0递增到232—1（4294976295）。
达到最大值后归0；
Gauge
非负的整数，取值范围为从0到4294976295（或增或减）。
达到最大值后锁定直到复位。
例如，MIB中的tcpCurrEstab就是这种类型的变量的一个例子，它代表目前在ESTABLISHED或CLOSE_WAIT状态的TCP连接数；
TimeTicks
时间计数器，以0.01秒为单位递增，但是不同的变量可以有不同的递增幅度。
所以在定义这种类型的变量的时候，必须指定递增幅度。
例如，MIB中的sysUpTime变量就是这种类型的变量，代表代理进程从启动开始的时间长度，以多少个百分之一秒的数目来表示；
SEQUENCE
这一数据类型与C程序设计语言中的“structure”类似。
一个SEQUENCE包括0个或多个元素，每一个元素又是另一个ASN.1数据类型。
例如，MIB中的UdpEntry就是这种类型的变量。
它代表在代理进程侧目前“激活”的UDP数量（“激活”表示目前被应用程序所用）。
在这个变量中包含两个元素：
IpAddress类型中的udpLocalAddress，表示IP地址。
INTEGER类型中的udpLocalPort，从0到65535，表示端口号。
SEQUENDEOF
这是一个向量的定义，其所有元素具有相同的类型。
如果每一个元素都具有简单的数据类型，例如是整数类型，那么我们就得到一个简单的向量（一个一维向量）。
但是我们将看到，SNMP在使用这个数据类型时，其向量中的每一个元素是一个SEQUENCE（结构）。
因而可以将它看成为一个二维数组或表。
7.SNMPv2协议
简单性是SNMP标准取得成功的主要原因。
因为在大型的、多厂商产品构成的复杂网络中，管理协议的明晰是至关重要的，但同时这又是SNMP的缺陷所在——为了使协议简单易行，SNMP简化了不少功能，如：
没有提供成批存取机制，对大块数据进行存取效率很低；
没有提供足够的安全机制，安全性很差；
只在TCP/IP协议上运行，不支持别的网络协议；
没有提供manager与manager之间通信的机制，只适合集中式管理，而不利于进行分布式管理；
只适于监测网络设备,不适于监测网络本身。
针对这些问题,对它的改进工作一直在进行。
如1991年11月,推出了RMON（RemoteNetworkMonitoring）MIB,加强SNMP对网络本身的管理能力。
它使得SNMP不仅可管理网络设备,还能收集局域网和互联网上的数据流量等信息。
1992年7月,针对SNMP缺乏安全性的弱点,又公布了S-SNMP（SecureSNMP）草案。
到1993年初,又推出了SNMPVersion2即SNMPv2（推出了SNMPv2以后,SNMP就被称为SNMPv1）。
SNM-Pv2包容了以前对SNMP所做的各项改进工作,并在保持了SNMP清晰性和易于实现的特点以外,功能更强,安全性更好,具体表现为:
提供了验证机制、加密机制、时间同步机制等，安全性大大提高，
提供了一次取回大量数据的能力，效率大大提高；
增加了manager和manager之间的信息交换机制,从而支持分布式管理结构。
由中间（intermediate）manager来分担主manager的任务,增加了远地站点的局部自主性。
可在多种网络协议上运行,如OSI、Appletalk和IPX等,适用多协议网络环境（但它的缺省网络协议仍是UDP）。
根据Carnegie-Mellin大学（SNMPv2标准的制定者之一）的StevenWaldbusser测试结果,SNMPv2的处理能力明显强于SNMPv1,大约是SNMPv1的15倍。
SNMPv2一共由12份协议文本组成（RFC1441-RFC1452）,已被作为Internet的推荐标准予以公布。
可看出它支持分布式管理。
一些站点可以既充当manager又充当agent,同时扮演两个角色。
作为agent,它们接受更高一级管理站的请求命令,这些请求命令中一部分与agent本地的数据有关,这时直接应答即可;另一部分则与远地agent上的数据有关。
这时agent就以manager的身份向远地agent请求数据,再将应答传给更高一级的管理站。
在后一种情况下,它们起的是proxy（代理）的作用。
下面将SNMPv2标准加以详细介绍,包括SNMPv2标准的中的安全机制,SNMPv2标准中的Party实体,以及如何从通信协议操作、SMI、MIB三方面来看SNMPv2标准
7.1SNMPv2标准中的安全机制
SNMPv2对SNMPv1的一个大的改进,就是增强了安全机制。
对管理系统安全的威胁主要有下面几种
（1）信息篡改（modification）
SNMPv2标准中,允许管理站（manager）修改agent上的一些被管理对象的值。
破坏者可能会将传输中的报文加以改变,改成非法值,进行破坏。
因此,协议应该能够验证收到的报文是否在传输过程中被修改过；
（2）冒充（masquerade）
SNMPv2标准中虽然有访问控制能力,但这主要是从报文的发送者来判断的。
那些没有访问权的用户可能会冒充别的合法用户进行破坏活动。
因此,协议应该能够验证报文发送者的真实性,判断是否有人冒充；
（3）报文流的改变（messagestreammodification）
由于SNMPv2标准是基于无连接传输服务的,报文的延迟、重发以及报文流顺序的改变都是可能发生的。
某些破坏者可能会故意将报文延迟、重发,或改变报文流的顺序,以达到破坏的目的。
因此,协议应该能够防止报文的传输时间过长,以给破坏者留下机会；
（4）报文内容的窃取（disclosure）
破坏者可能会截获传输中的报文,窃取它的内容。
特别在创建新的SNMPv2Party时,必须保证它的内容不被窃取,因为以后关于这个Party的所有操作都依赖于它。
因此,协议应该能够对报文的内容进行加密,保证它不被窃听者获取。
针对上述安全性问题,SNMPv2中增加了验证（Authentication）机制、加密（Privacy）机制,以及时间同步机制来保证通信的安全。
7.2SNMPv2Party
SNMPv2标准中增加了一种叫做Party的实体。
Party是具有网络管理功能的最小实体,它的功能是一个SNMPv2entity（管理实体）所能完成的全部功能的一个子集。
每个manager和agent上都分别有多个Par-ty,每个站点上的各个Party彼此是平等的关系,各自完成自己的功能。
实际的信息交换都发生在Party与Party之间（在每个发送的报文里,都要指定发送方和接收方的Par-ty）。
每个Party都有一个唯一的标识符（partyidentity）、一个验证算法和参数以及一个加密算法和参数。
Party的引入增加了系统的灵活性和安全性,可以赋予不同的人员以不同的管理权限。
SNMPv2中有三种安全性机制:
验证（authentication）机制、加密（privacy）机制和访问控制（accesscontrol）机制。
这些机制都工作在Party一级,而不是manager/agent一级。
7.3SNMPv2协议操作
SNMPv2标准的核心就是通信协议——它是一个请求/应答式的协议。
这个协议提供了在manager与agent、manager与manager之间交换管理信息的直观、基本的方法。
每条SNMPv2的报文都由一些域构成.
如果发送方、接收方的两个Party都采用了验证（authentication）机制,它就包含与验证有关的信息;否则它为空（取NULL）。
验证的过程如下:
发送方和接收方的Party都分别有一个验证用的密钥（secretkey）和一个验证用的算法。
报文发送前,发送方先将密钥值填入图中digest域,作为报文的前缀。
然后根据验证算法,对报文中digest域以后（包括digest域）的报文数据进行计算,计算出一个摘要值（digest）,再用摘要值取代密钥,填入报文中的digest域。
接收方收到报文后,先将报文中的摘要值取出来,暂存在一个位置,然后用发送方的密钥放入报文中的digest。
将这两个摘要值进行比较,如果一样,就证明发送方确实是srcParty域中所指明的那个Party,报文是合法的;如果不一样,接收方断定发送方非法。
验证机制可以防止非法用户"冒充"某个合法Party来进行破坏。
authInfo域中还包含两个时间戳（timestamp）,用于发送方与接收方之间的同步,以防止报文被截获和重发。
SNMPv2的另一大改进是可以对通信报文进行加密,以防止监听者窃取报文内容。
除了pri
升级会员 