从SNMP到WBEM－－论网络和系统管理的发展和展望(SNMP篇)

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：除去这个原因，还有个重要原因是各个厂商都有自己的一些私有协议，而厂商自己的网管软件在很大程度上都依附这些私有协议。