从SNMP到WBEM――论网络和系统管理的发展和展望之一SNMP篇

从SNMP到WBEM――论网络和系统管理的发展和展望之一SNMP篇
作者：xxbin
时间：2004年9月20日

关键字
SNMP、SNMP Agent、 NMS

SNMP的历史
SNMP（Simple Network Management Protocol）即简单网络管理协议，它为网络和系统管理提供了底层的框架，使得网络和系统管理员能够远程监测和配置管理他们的网络设备、操作系统、应用系统等。
1987年11月发布的SGMP（Simple Gateway Monitoring Protocol）即简单网关监控协议，成为提供专用网络管理工具的起点，自从SGMP出现后，网络管理摆脱了原始的利用ICMP来探测主机是否在线等简单监控手段的时代。
随着网络管理需求的增长和变化，出现了很多网络管理的标准和方法，其中比较有影响力的有两个：
1) SNMP（Simple Network Management Protocol）即简单网络管理协议(SNMP)，SNMP协议是SGMP的升级版；
2) CMIP（Common Management Information Protocol）即通用管理信息协议，建立在开放系统互连通信模式上的网络管理协议。
在当时，IETF推荐采用基于OSI的CMIP协议作为网络管理协议，并对它作了修改，修改后的协议被称作CMOT(Common Management Over TCP/IP)。但是CMOT的各项标准迟迟未能出台，在这种情况下，IETF决定把已有的SGMP进一步修改后，作为临时的解决方案，而这个在SGMP基础上开发的解决方案就是著名的SNMP。
虽然推出了SNMP作为临时解决方案，但是IETF并没有放弃CMOT，并计划将SNMP作为近期解决方案进一步开发，而把CMOT作为远期解决方案，并且设计SNMP和CMOT使用相同的被管对象数据库，因此，两个协议共享一个一个公共的SMI（管理信息结构）和一个MIB（管理信息库）。
但是因为SNMP的简单性，SNMP与CMOT这两个协议在被管理对象的兼容是不现实的，SNMP只关注于一些简单的数据、特性和变量，因此最后放弃了两者之间的兼容，SNMP开始独立发展。

SNMP v1
1988年，SNMP的最初的标准就已经确定，现在我们把当时那个标准称之为SNMPv1，从与OSI兼容的束缚中解脱后，SNMP取得了迅速的发展，很快被众多的厂商设备所支持，许多著名的网络管理系统，如HP的OpenView、IBM的 NetView、Cabletron的 Spectrum、Microsoft的Systems Management Server（SMS）、Novell的ManageWise和开源的OpenNMS都是基于SNMP标准设计的。
SNMPv1协议的模型如下图所示（注1）：



在被监控端，嵌入到网络设备中或主机设备的SNMP Agent收集设备的各种信息和统计数据并不断的把这些数据记录到MIB库中，在管理端，通过SNMP协议向SNMP Agent发出SNMP报文，SNMP Agent收到报文后向SNMP管理端响应应答包。
SNMP报文中的GetRequest、GetNextRequest用来向SNMP Agent查询MIB库数据，比如可以查询被监控设备的CPU利用率等；SetRequest报文用来向SNMP Agent设置一些变量，比如可以利用SetRequest来重启某台设备；另外，SNMP Agent会收集一些系统的事件，并以SNMP Trap的方式向SNMP管理端通告事件。
本文不打算讨论SNMP协议的细节，有关SNMP协议的具体细节和实现，可以查看相关的RFC文档。(RFC 1157 等)

SNMP v2
为了弥补SNMPv1在安全性和其它方面的欠缺，IETF为SNMP v2做了大量的工作，其中大多数是为了寻找加强SNMP安全性的方法，1992年7月，出现了一个称为SMP的SNMP新版本，SMP在功能和安全性两方面提高了SNMP，最终SMP被接受为定义SNMPv2的基础，并于1993年发布了SNMPv2。但是SNMP在安全方面的改进并没有得到个方面的支持，1996年，IETF发布了一组新的RFC，取消了SNMPv2的安全特性的修改，主要通讯方式也重新采用 SNMPv1的基于Community（通讯字）的方式。
SNMP v2改进了SNMP v1的Trap通告方式，一种不同的事件格式被设计来替代SNMP v1的Trap事件格式。
同时，SNMP v2定义了两种新的SNMP报文：GetBulk和Inform。GetBulk用来更有效率的查询和接收批量的数据，而Inform可以被NMS（网络管理系统）发送Trap信息到另一个NMS。

SNMP v3
1999年，SNMPv3的草案发布，在2002年3月，SNMPv3的标准正式出台，SNMPv3针对SNMPv2的最大改进主要在安全性和管理能力两个方面。
SNMPv3采用User-based安全模型和View-based访问控制模型提供SNMP网络管理的安全性，并利用加密的方式来避免信息的泄漏。



SNMPv3在安全性方面的改进主要有3点：
1）SNMP的数据报文将被使用DES加密来避免信息的非法泄漏；
2）SNMP管理端与SNMP Agent通讯时必须要通过认证（authenticated）来保证身份的正确性、信息的完整性合信息的合时性（timeliness）；
3）SNMP Agent实现了User-base和View-base访问控制模型，访问控制可以精确到数据级别，并且更加灵活利于控制。
现在一些设备和操作系统已经开始支持SNMPv3，比如在UNIX世界比较有名的开源的SNMP实现――NET-SNMP( http://net-snmp.sourceforge.net/)，SNMP v3与SNMP v1/SNMPv2相比，基础架构和设计思路没有本质的改变，随着一些新的网路管理协议和标准的提出，SNMP的发展可能已经走到了尽头，但是无论将来怎么发展，在5年之内，SNMP绝对是业界事实上的网络管理协议标准。

SNMP的缺点
即使SNMP协议已经发展到第三版，但是因为SNMP出现时人们对网络管理认识的局限性以及SNMP协议不得不向上兼容的做法使得SNMP拥有很多缺点，在这里，将讨论SNMP协议的几个主要的缺点：
1）SNMP协议轮询的方式在一个大型网络中可能会导致网络通信拥塞情况的发生，并且SNMP协议把采集数据的负担完全压在了管理端之上；（注2）
在现在流行的千兆为主干的企业网中使用SNMP协议来监控设备会导致网络通信拥塞的说法可能有所危言耸听，但是在一个大型网络中，SNMP协议的确有浪费带宽的嫌疑；而且在一个大型网络中，面对近千台设备上万个OID采集点的数据采集量，管理端的负担太重，管理端甚至不能在设定的时间间隔内做一次完整的轮询。
要解决上面的问题，现在流行的做法是在网络的不同位置放置一些采集设备（或者称之为探针），由这些采集设备利用SNMP协议向不同的SNMP Agent采集数据，并在某个时候把这些采集好的数据提交到主控端上，或是主控端需要某些数据的时候从采集设备提取。

2）SNMP Agent无法提供某个数据的历史记录；（注3）
SNMP Agent只能提供被监控设备的当前状态，某些时候，SNMP Agent也能提供设备在15分钟或者更短时间内的某些统计数据，但是一个设备的性能和状态的历史记录对网络优化和性能调优有着莫大的帮助，整个网络的设备的历史记录还可以帮助决策者进行更有效、更合理的决策。
针对SNMP协议的这个说不上是缺点的缺点，管理端必须要在一定的间隔时间内不断的进行SNMP轮询，并把轮询得到的结果存储在本地以便将来能够对这些数据进行查询和分析。
比较有名的MRTG就是采用这种方式来统计网络设备的流量的信息的，并可以生成各种统计数据的趋势图。但是不幸的是，很多网络管理软件就根本无法提供这些历史数据。

3）SNMP协议不能以一种统一通用的数据描述格式保存所有被管理设备的标识、状态和配置等信息。
如果说SNMP协议的前两个缺点是可以用某些方式弥补的话，这里提到的第三个缺点是SNMP协议最致命的缺点。
SNMP这个缺点，在某种程度上来说主要是因为MIB库的混乱所导致的，在SNMP协议被提出来的最初，定义了一些公用（public）的MIB库，在SNMPv2版本，也定义了MIB-II，但是这些MIB库并无法包容所有厂商的被监控的信息，比如说Windows NT/2000的一些性能参数在这些公用的MIB库中根本无法得到体现，因此Microsoft就不得不定义一系列自己的MIB库来提供这些信息，由于这个原因，每个厂商都有大量的自己私有（private）的MIB库，正因为这些私有MIB库的存在，导致SNMP协议不能以一种统一通用的数据描述格式来保存所有被管理设备的各种信息。
下面我将举两个例子来详细说明这个问题：
假设我们需要通过SNMP协议来采集某些设备的CPU利用率的话，我们会发现，很多厂商提供CPU利用率的OID都不一样，比如在Netware上是.1.3.6.1.2.1.25.3.3.1.2、在使用NET-SNMP来提供Agent的Linux和BSD机器上是.1.3.6.1.4.1.2021.10.1.5、在Windows系列的操作系统上是.1.3.6.1.2.1.25.3.3.1.2、在Cisco路由器上却又变成.1.3.6.1.4.1.9.2.1.58，研究下去，你会发现，MIB简直就是个泥塘！
上面提到了MIB和OID的混乱，而第3个缺点的另外一层含义是：SNMP没有定义一套数据表达规范来描述不同厂商的相同类别的数据。比如操作系统的用户，在管理员看来无论什么操作系统，用户就是用户，虽然每个操作系统对用户的描述的字段不同（比如Windows系列操作系统中的用户的某些描述字段是UNIX操作系统中所没有的），但是用户就是用户，用户的描述再怎么变化，它也不会变成一个CPU，对于管理员来说，特别是一个管理不同平台、不同厂商设备的管理员来说，希望网管协议能够把各种相同类别的信息归纳成一个统一的、通用的数据表达方式，比如我们刚才所提到的不同操作系统的用户信息就可以归纳成一个通用的表达方式，某个平台无法提供的字段即使为空也是无所谓的，最关键的是――统一、通用。
为什么说这个问题是SNMP的致命的缺点？简单的来说这个缺点使得一个网络中采用一套基于SNMP的网管平台来管理不同厂商和平台的设备的美梦成为了一个幻想，从现在的情况来看，我们不可能仅仅只利用一套网络管理系统来有效的管理一个拥有AIX、HP-UX、Solaris、Linux、IBM Switch、Cisco Router、Cisco Switch、Foundry Switch、NetScreen、APC UPS、Windows NT/2000、Netware等等各种厂商和平台的网络中的所有设备（注4），这也是为什么Cisco的网络环境用Ciscoworks来管理最方便最有效、而HP的OpenView虽然可以管理更多厂商的设备但是在Cisco网络环境下不如Ciscoworks的主要原因之一（注5）。这也是当今主流的网络和系统管理软件无法有效的共享信息和协作的最主要的原因。

SNMP相关链接
http://www.faqs.org/faqs/snmp-faq/
SNMP FAQ

http://www.ietf.org/rfc.html
IETF RFC Page
你可以在这里浏览SNMP相关的RFC文档

http://www.ibr.cs.tu-bs.de/projects/snmpv3/
SNMP Version 3 (SNMPv3)
This web page provides information about the Simple Network Management Protocol Version 3 (SNMPv3).

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/
MRTG: The Multi Router Traffic Grapher
The Multi Router Traffic Grapher (MRTG) is a tool to monitor the traffic load on network links. MRTG generates HTML pages containing PNG images which provide a LIVE visual representation of this traffic.

http://www.net-snmp.org/
The NET-SNMP Project Home Page
net-snmp provides tools and libraries relating to the Simple Network Management Protocol including: An extensible agent, An SNMP library, tools to request or set information from SNMP agents, tools to generate and handle SNMP traps, etc.

http://www.opennms.org/
OpenNMS Home
OpenNMS is an open-source project dedicated to the creation of an enterprise grade network management platform.

注释：
注1：SNMP刚出台时，它主要是为基于TCP/IP的互联网设计的，现在已经被其它协议实现，如IPX/SPX，DECNET以及Appletalk等。

注2：这里列举的缺点是制传统意义上的SNMP的缺点，而这个缺点已经被RMON有效的解决了，但是通常我们都习惯把SNMP与RMON分开来提，并且相当数量的支持SNMP的设备并不支持RMON，因此才会有这么一个提法。

注3：同注2

注4：这里所说的有效的管理是指能达到厂商自带的或者厂商能提供的管理软件的管理水平。

注5：除去这个原因，还有个主要原因是各个厂商都有自己的一些私有协议，而厂商自己的网管软件在很大程度上都依靠这些私有协议。

我8点钟起来就看这个?

QUOTE

我8点钟起来就看这个?

啊，这么捧场啊，难得难得。

嗯，Worth wating

提点建议啊。

又一个不置可否的人
BS之

SNMP的缺点
1.应该提到庞大的MIB和轮询机制不但加大了网络的流量，同时还带来存储和处理效率的问题：SNMP网管系统清一色的需要很高的硬件配置，但是发现网络问题的速度却较慢

应该把snmp的安全问题作为一个缺点或者一个专门的点来说明，包括默认的community string和那一套测试工具发现的n多snmp 实现中的漏洞等等

RFC现在好象有针对某些技术定义的MIB规范，比如说支持IPSEC 的Agent应该支持某个跟IPSEC技术相关的MIB...没有仔细研究过。

QUOTE

我8点钟起来就看这个?

注意问号。

网管系统的效率问题或许和网管系统本身的架构有关，有的做得稍微好一点，有的做的差些，文章中也提到过“SNMP协议把采集数据的负担完全压在了管理端之上”。

SNMP的安全性已经在SNMPv3得到很好的解决了，DES加密，User-base和View-base访问控制模型，这还不够啊？不过偶对现在的产品不太熟悉，不知道CISCO是否开始支持SNMPv3了？

最后BS纸马
另外还怀疑麦子偷懒没有看完偶的帖子

555

最大的缺点是:
除非操作系统、IP和传输层协议等都工作正常 管理系统 才能网管设备
唉
要解决这个问题才行


签名
-----
把传输层翻译成运输层是没文化的表现

嗯
纸马说的是

这个平常也有感触，写的时候忘记了，改天加进去，呵呵

BUT
从某种意义上来说
IP层不工作了

这台设备也就基本上OVER了
当然话也不能这么说，只是要解决这样的问题，什么协议都搞不定的说

QUOTE

另外还怀疑麦子偷懒没有看完偶的帖子

可能相关的问题你已经在文中“暗示”过了吧，偶虽然逐字读过，无奈资质鲁钝，未能领会...

QUOTE

我们不可能仅仅只利用一套网络管理系统来有效的管理一个拥有AIX、HP-UX、Solaris、Linux、IBM Switch、Cisco Router、Cisco Switch、Foundry Switch、NetScreen、APC UPS、Windows NT/2000、Netware等等各种厂商和平台的网络中的所有设备

非常同意,八能通用,郁闷死了

QUOTE

QUOTE 另外还怀疑麦子偷懒没有看完偶的帖子 可能相关的问题你已经在文中“暗示”过了吧，偶虽然逐字读过，无奈资质鲁钝，未能领会...

有关网管平台的负载问题在第一个缺点是说了很多嘛

至于安全性的问题，从v2开始说，v3主要说安全性的改进了，改进了就没有弱点了，只是大多数设备还是基于SNMPv2的说，是有必要说说安全性的弱点。

签名
---------------------------------------------------------------------------
法语电影看多了中文的表达能力会严重下降

加密＝更大的开销、更低的效率

cisco snmp v3 support
(IOS V12.0T)

RFC 1901, Introduction to Community-Based SNMPv2. SNMPv2 Working Group.

RFC 1902, Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). SNMPv2 Working Group.

RFC 1903, Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). SNMPv2 Working Group.

RFC 1904, Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). SNMPv2 Working Group.

RFC 1905, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). SNMPv2 Working Group.

RFC 1906, Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2).

RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). SNMPv2 Working Group.

RFC 1908, Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. SNMPv2 Working Group.

RFC 2104, Keyed Hashing for Message Authentication


RFC 2271, An Architecture for Describing SNMP Management Frameworks.

RFC 2272, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP).

RFC 2273, SNMPv3 Applications.

RFC 2274, User-Based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3).

RFC 2275, View-Based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP).

http://www.cisco.com/en/US/products/sw/ios...00800878fa.html

http://www.cisco.com/pcgi-bin/Support/brow...MP&viewall=true

QUOTE

而HP的OpenView虽然可以管理更多厂商的设备但是在Cisco网络环境下不如Ciscoworks的主要原因之一

HPOpenView似乎和cisco的ciscoworks不能等量齐观。ciscoworks就像华为的网管软件一样，是下层的，OpenView应该像一个盒子，是高一个层次的东西。

另外，负载的确是一个问题。不过偶觉得，提高了安全性的同时肯定加大了负载。另外，一个大型网络中，不可能只有一个网管终端，所以偶觉得负载不是一个太大的问题。

哈哈
麦子可能担心某个客户的网管平台不堪重负了

但是网管数据可是比较重要的说，加密还是有必要的
要相信芯片的发展是可以承受这样的负载的

再说了，可以用分布式架构来解决这个问题嘛

顺便问一句，麦子你在CISCO的机器上配置过SNMPv3么？

偶觉得SNMPv3搞得太复杂了，特别是那个View-base的东东，可以和MIB的混乱有得一拼了

QUOTE

QUOTE 而HP的OpenView虽然可以管理更多厂商的设备但是在Cisco网络环境下不如Ciscoworks的主要原因之一 HPOpenView似乎和cisco的ciscoworks不能等量齐观。ciscoworks就像华为的网管软件一样，是下层的，OpenView应该像一个盒子，是高一个层次的东西。 另外，负载的确是一个问题。不过偶觉得，提高了安全性的同时肯定加大了负载。另外，一个大型网络中，不可能只有一个网管终端，所以偶觉得负载不是一个太大的问题。

呵呵
你已经中毒了

难道一套网管软件管理所有设备不是一件好事情么？想想有那么一天，网络管理比MS Office系列还容易使用，并且就是一个统一的平台和界面，那多爽啊，不过那时候可能有的人要因此失业的说。

不过CISCOWORKS和OPENVIEW的确关注的东东不一样，但是，网管就是网管啊，偶要实现的功能就是那么多，有一个平台能实现就OK了。

负载的问题在中小型企业的确不算什么
听说过电信的网管系统，嗯，实时数据居然入ORACLE关系型数据库，也不整个类似PI的实时数据库来玩玩，另外所有被控端的事件集中起来都是一件非常恐怖的事情。

推荐一个snmp的连接
www.snmplink.org

一个网管管理所有的不同厂商的设备、主机、数据库很正常啊
只要有对应的MIB就行了
问题是MIB标准定义的变量太少了
所谓管理也只是做一些简单的配置而已
唉

签名
------
大家都被骗了