SNMP学习札记
版本：1.0SNMP
二十世纪70年代末、80年代初的时候，计算机网络由最初的只是小范围内的几台计算机相互连接逐步发展成大规模的网络。随着网络跳跃式的发展，对网络进行的监控和维护等管理操作也变得更加困难，从而对开发出能够满足网络管理需要的协议提出了迫切要求。
第一个开始使用的网络管理协议就是SNMP。当时，人们只是把SNMP当作一种应急措施，等到日后有更加成功，更加成熟的新协议出现时将会被自然淘汰。然而，虽然不断有新的协议推出，但是SNMP凭借其结构简单，使用方便的特点一直到今天仍然被广泛使用。
SNMP协议的工作机制非常简单，主要通过各种不同类型的消息，即PDU（协议数据单位）实现网络信息的交换。PDU实际上就是一种变量对象，其中每一个变量都是由标题和变量值两部分组成。
SNMP主要使用5种类型的PDU对网络实施监控，两种用于读取终端信息，两种可以设置终端数据，最后一种被用来监视各种终端事件，如终端的启动和关闭等。
这样，如果用户希望了解是否某一台终端已经被接入到网络，可以使用SNMP向该终端发送一个具有信息读取功能的PDU。如果终端已经被连接到网络，用户将会得到返回的确认信息。当有终端被关闭时，可以通过事件变量（trap）发出数据包，通知用户终端系统已经被关闭。
SNMP协议的优势
SNMP协议的最大优势就是设计简单，既不需要复杂的实现过程，也不会占用太多的网络资源，非常便于使用。
一般来说，SNMP协议所使用的各种变量主要包含以下信息：
1.变量标题；
2．变量数据类型，如整数，字串等；
3．变量是否具有信息读取或读写功能 ;
4．变量值
SNMP协议的另外一个优势就是使用非常广泛，几乎所有的网络管理人员都喜欢使用简单的SNMP来完成工作操作。这就促使各大网络硬件产品商在设计和生产网桥、路由器等网络设备时都加入了对SNMP协议的支持。
良好的可扩展性是SNMP协议的另外一个可取之处。因为协议本身非常简单，所以对协议的任何升级或扩展也非常方便，从而能够满足今后网络的发展需求。
SNMP协议的不足之处和解决方法
虽然SNMP以其简单易用的特点成为目前最为流行的网络管理协议，但是无论如何SNMP都不能算是一种设计完美的协议。
首先，SNMP协议存在一些安全漏洞，网络入侵者很容易获取正在通过网络传递的各种信息，设置可以关闭某些终端。对此，SNMP提出了自己的解决方案，在新版本SNMPv2中增加了一些安全机制，可以有效的解决以下几种安全性问题：
数据的保密性，可以防止网络入侵者获取网络信息；
验证，可以防止网络入侵者通过网络发送虚假数据；
访问控制，限制不同用户可以使用的变量类型，从而避免由于单个用户的错误操作所引发的网络崩溃。
SNMP协议的最大问题还是由于太过简单而无法处理各种细节信息，无法满足当今日益膨胀的网络的发展需要。同样，SNMPv2对这一问题也进行了改进。新版本的协议允许使用更多，更加详细的变量规范，并且加入了两种新的PDU可以对方便数据读取的表数据结构对象进行管理和控制。事实上，SNMPv2中融入了如此多的新功能，以至使协议规范从最初的36页猛增到416页。也有人认为SNMPv2已经丧失了原先的简单性，但是从另一方面来说，对SNMP的改造也是必需的，在网络飞速发展了几十年之后，SNMP必须能够适应新时代的网络要求。
SNMPv2
当我们介绍到这里时，大家可能都在期望NMPv2能够成为新一代的网络管理标准协议。但是，事实正好相反，SNMPv2仍然只停留在理论阶段。
SNMPv2的失败主要应当归因于开发商不能在关键性的问题上达成一致。此外，目前也很难找到能够全面支持SNMPv2协议各种扩展功能的产品。事实上，SNMP所获得的空间成功从某种意义上也影响了SNMPv2的进一步发展，无论是SNMPv2还是更高版本的SNMPv3似乎都无法成为SNMP的合格继承者。
MIB = Management Information Base
网络管理信息库（MIB）是网络管理数据的标准，在这个标准里规定了网络代理设备必须保存的数据项目，数据类型，以及允许在每个数据项目中的操作。通过对这些数据项目的存取访问，就可以得到该网关的所有统计内容。再通过对多个网关统计内容的综合分析即可实现基本的网络管理。
Management Information Base (MIB) 描述一个管理的对象集合。如果SNMP服务程序支持MIB，一个管理程序可以在个特定的计算机上操纵这个对象。
网络中的每个设备都是一个对象元素，他们的集合就是MIB。作为访问集，MIB的职能就是为管理工作站指定代理。可以通过修改变量来改变代理中配置的设置。
对于SNMP而言，MIB本质上是一个树形结构的数据库。而且用于表示特定资源的对象在每个系统中都必须相同。通过定义一个SMI（Structur of Management Information，管理信息结构）。它确定了可以用于MIB中的数据类型并说明对象在MIB内部怎么样表示和命名。
我该如何创建自己的MIB？
首先：要定义自己的MIB，要先熟悉ASN.1的语法，其中有个老外的一本MIB书很好，MIB的RFC文档就是它定义的好像。
其次：多看其他的MIB，其实定义比较简单，就是TYPE，标量，表三个主要的东西
SNMP(简单网络管理协议)是一个应用层协议，用于在网络设备间交换管理信息，他是TCP/IP协议套件的一部分。它是网络管理人员能够管理网络，发现并解决网络问题，规划网络的发展。
SNMP管理的数据包括被管理对象、代理和网络管理系统（NMS）三个主要组件。被管理设备是网络节点，包括一个驻留的SNMP代理（Agent）。代理（Agent）是一个网络感里软件模块，驻留在一个被管理设备中；NMS监测并控制被管理设备。
SNMP的基本命令：read、write、trap和traversal。NMS用read命令监测被管理设备；NMS用write命令控制被管理设备；被管理设备用trap命令异步地向NMS报告事件；NMS用traversal操作决定被管理设备支持哪一个变量值，并不断为参数表收集信息，如路由信息。
SNMP管理信息库（MIB）是一个信息的集合，它分层组织，形成一个树形结构。用网络管理协议可以访问MIB。MIB由被管理对象组成，并有对象标签标识。对象标识在MIB树种唯一标识一个被管理对象。
在snmp网管协约中有两侧：Manager侧和Agent侧。
其中Agent侧是指被管对象的代理，比如交换机等设备上的网管；
Manager侧是指网管工作站，可以编程实现snmp协约对被管设备
进行管理，可以选用HP提供的snmp++软件包，免费并且提供源代码，
而且是for VC++.
你所说的编程主要指的是Manager侧的编程，snmp++足够了。
另外，你还必须知道被管设备的MIB库结构及内容！！！
Remote Monitoring ,即远程监视。 RMON可以把子网作为一个整体来监视，而不用监视每个设备。
RFCRequest For Command,请求注解。一个厂商开发出一套新的产品，就发布一份RFC来征求意见。所以RFC是网络的规范，有自己的版本号。
管理工作站是典型的独立设备。包括应用程序、管理员、翻译管理员信息的模块、网络中各种设备的信息库MIB。
管理代理关键平台（主机、网桥、路由器、集线器）可能安装有SNMP代理以便从管理工作站来管理。响应工作站的请求并以异步方式提供重要信息（哪怕未请求）。
SNMP协议结构SNMP在UDP上操作，User Datagram Protocol。
OIDOID是“对象标识符”。是标识这个树内具有某个具体对象的数字序列。
ASN.1是由CCITT（X.208）开发和标准化的正式语言。是一种可以用来定义数据结构的语言
SNMP概述
网管软件一般都支持SNMP（简单网络管理协议），能与惠普公司的Open View Professional Suite专业程序集和Open View Network Node Manager节点管理器结合得天衣无缝，并提供MIB（管理信息基地）、RMON（远程监控）等功能。
SNMP（简单网络管理协议）是一种广为执行的网络协议，它使用嵌入到网络设施中的代理软件来收集网络的通信信息和有关网络设备的统计数据。代理软件不断地收集统计数据，并把这些数据记录到一个管理信息库（MIB）中。网管员通过向代理的MIB发出查询信号可以得到这些信息，这个过程叫轮询（polling）。虽然MIB计数器将统计数据的总和记录下来了，但它无法对日常通信量进行历史分析。为了能全面地查看一天的通信流量和变化率，管理人员必须不断地轮询SNMP代理，每分钟就轮询一次。这样，网管员可以使用SNMP来评价网络的运行状况，并揭示出通信的趋势，如哪一个网段接近通信负载的最大能力或正使通信出错等。先进的SN？MP网管站甚至可以通过编程来自动关闭端口或采取其它矫正措施来处理历史的网络数据。然而SNMP轮询有个明显的弱点：它没有伸缩性。在大型的网络中，轮询会产生巨大的网络管理通信量，因而导致通信拥挤情况的发生。它将收集数据的负担加在网络管理控制台上。管理站也许能轻松地收集8个网段的信息，当它们监控48个网段时，恐怕就应付不下来。
1 概述
电信管理网与信令网、同步网一样，是保证电信网正常运行的支撑网。随着电信网技术的不断发展，电信网对电信管理网的依赖性越来越强，正如电信网的建设需要标准、设备入网需要测试一样，电信管理网的建设也必须遵循同样的方法论。
当前，对于电信管理网标准的研究，主要集中在网络管理框架、网络管理研究方法论和网管接口等方面。其中，核心内容是网管接口，对于厂家提供的网管接口应该定位在哪一层次、提供什么样的管理功能、采用什么样的技术、需要多大的成本等问题，这直接影响到业务运营商和设备提供商之间的主权和利益分配，可以说网管标准规定的内容是业务运营商和设备供应商之间此进彼退的战略要地。
2 我国网管标准的现状
经过十多年的网管建设，我国在网管标准化方面取得了很大的成绩，同时也有一些深刻的教训。总结过去的经验和教训，同时借鉴ITU-T和其它国际、区域、专业性标准化组织的成果，目前我国已经基本完成了网管标准化体系的建设。
在电信管理网理论方面，确定了电信管理网标准化研究的内容和方法论；在此基础上，先后制定了一系列行业标准和企业标准，并承担了ITU-T的建议制定任务；在标准的实施方面，提出了一整套保证措施，所有这一切都已经产生了较好的社会效益和经济效益。
2.1 网管理论
随着电信网络技术和电信管理网所采用的计算机技术的不断发展，对于网管理论的研究也在不断深入，目前，这方面的研究内容主要包括以下几个方面：
2.1.1 网络管理框架的研究
当前最典型的网络管理体系结构主要有Internet/SNMP管理体系结构、TMN管理体系结构和TINA体系结构三种。随着理论研究和实际应用的不断深入，TMN通过吸收其它两种结构的某些思想而不断完善，在电信网络管理领域逐渐占据了主导地位。
TMN的核心思想是一种网管网的概念，它将管理网提供的管理业务与电信网提供的电信业务分开，相对于被管理的电信网来说属于一种带外管理。TMN通过对网管接口的引入，将业务网和管理网分开，在保持接口相对稳定的同时，尽量屏蔽了电信网络技术和网络管理技术的发展对彼此的影响。同时，TMN通过引入信息模型管理功能和软件体系结构的重复使用，以及开发方法的重复使用等软件重用的思想，缩短了网管系统的开发周期，提高了网管软件的质量。
相对于TMN管理体系结构，TINA体系结构将管理业务和电信业务统一考虑，更像是一种带内管理方式，从理论上来说更容易满足网络管理实时性的要求，特别适合处理高层网络管理问题。但是，它所要求的计算技术较高，在短时间内还不可能达到实用化的程度，在没有得到市场认同的情况下，其影响力会逐渐丧失。
Internet/SNMP管理体系结构在计算机网的网络管理领域取得了巨大成功。根据计算机网管理信息较少的特点，采用这种带内管理的方式一般不会对网络的性能带来太大的影响，但是，其轮询机制所固有的缺点限制了被管节点的数目和操作响应时间，决定了该体系结构不可能用于大型网络的实时管理。
在传统的电信网和IP网融合趋势日益明显的今天，在TMN管理体系结构基础上，如何解决信息网的综合管理问题是网络管理体系结构标准化研究的主要内容。
2.1.2 网络管理接口研究的方法论
在TMN管理框架内，网管标准化研究的核心问题是网管接口问题。ITU-T在M.3020建议中给出了电信管理网接口规范标准化研究应该遵循的方法论，据此，可以从三个方面定义网络管理接口，它们分别是管理业务定义指南（GDMS）、管理功能定义指南（GDMF）和管理对象定义指南（GDMO）。
其基本思想是将网管接口定义过程划分为一系列的任务（Task），每一阶段的任务具有相关联的任务信息库（TIB），TIB描述了关于完成该任务所必须具备的知识和方法以及完成该任务后产生的结果。在按照一定的时序完成指定的任务序列后，根据生成的TIB就可以得到满足用户需求的网管接口规范。1995年版的M.3020建议的图10中详细描述了网管接口方法论中定义的两类共14个任务、与每个任务相关联的TIB以及完成整个网管接口定义的流程。
该方法在基于Q3接口的网管接口规范制定过程中起到了很好的作用，按照该方法论，ITU-T先后完成了一系列通用的网管接口建议。在此基础上，我国也制定了一系列关于特定业务网的网管接口规范。但是，传统管理信息建模方法存在一些不足。首先，GDMO本身的描述能力不足，例如模型中对行为的描述采用自然语言，这无法清楚定义对象的具体行为，因而可能引起二义和歧义；其次，在信息建模过程中缺少需求、分析和设计阶段的可溯性，无法体现信息建模的全过程；再次，往往最终给出的只是静态的信息模型，无法描述被管对象的动态特性；最后，得出的信息模型只适用于本管理框架，无法在其他管理框架中得到直接的重复使用。
随着基于CORBA（公共对象请求代理体系结构）平台管理应用的出现，越来越要求信息模型在不同管理框架下实现互通，如传统的基于Q3的信息模型可以在基于CORBA的平台中应用。目前JIDM工作组提出的静态和动态GDMO/IDL映射作为一种方案在一定程度上可以解决信息模型的互通，但是在模型翻译过程中存在不可避免的语义丢失。因此，只有从管理信息建模方法本身入手，找到一种可以得到与管理框架无关的信息模型的建模方法，才能解决这个问题。
为此，ITU-T在1999年3月决定简化网管接口规范制定的方法论，提出了RAD（Requirements, Analysis, and Design）方法。与传统管理信息建模不同，RAD方法将整个建模过程分为需求、分析和设计三个阶段。但是，这三个阶段并不是严格的从上到下的过程，而是一个反复的逐步求精的过程。需求阶段主要涉及问题域空间、系统策略和外部系统与该系统所扮演的角色的定义，它可分为事务(business)需求定义和详述(specification)需求定义。事务需求从宏观的角度完整地定义被解决的管理问题的需求；详述需求则给出在分析和设计阶段可以直接使用的详细的需求细节，详述需求是最终分析和设计结果的来源。分析阶段主要根据需求阶段的结果，定义实体与实体间的关系以及实体所支持的接口，分析阶段的工作独立于具体设计的要求。在分析阶段的信息主要包括对象类的描述、类中数据的定义、对象类间的关系、类中的动作以及类间相互交互的脚本的描述。设计阶段主要是依据需求和分析阶段的工作，基于特定的管理框架，如Q3或CORBA，将需求和分析结果映射为与特定管理框架相关的管理信息模型。例如：Q3采用GDMO描述、CORBA则采用IDL描述。
通过将建模过程分为RAD三阶段，可以做到模型在需求和分析阶段的结果与具体管理框架无关，而在设计阶段才使之与特定管理框架相关联，这就使信息模型与管理框架无关，从而实现了信息模型间的互通。
在RAD三阶段中均融合了ODP的企业视点、信息视点和计算视点。在建模的全过程中使用的主要描述语言是UML。在设计阶段，与具体管理框架相关的建模语言是GDMO或IDL。
目前，ITU-T内部各个网管标准化工作组正在评估RAD方法论的提出对过去已经完成的工作带来的影响。对于我国已经制定的标准，也应该重新审查，消除引进新的方法论带来的影响；同时，应该直接在新方法论的指导下进行新标准的制定工作。
2.1.3 网络管理接口研究的内容
作为网管标准化工作的核心，网管接口标准化主要包括三个方面的内容：接口通信协议、接口信息模型和接口的测试。
对于接口通信协议，目前，已普遍接受的是基于Q3接口的CMIP、基于CORBA接口的IIOP以及基于Internet/SNMP框架结构的SNMP。对于接口信息模型，与以上三种接口相对应，分别采用GDMO/ASN.1、IDL/UML和MIBII方式进行信息模型的描述。对此，有关各方已达成共识，未来的工作主要集中于如何完成具体业务网的信息建模工作。
但是，以上两部分工作的贯彻实施必须有足够的技术保证，正如电信网的设备入网需要测试一样，电信管理网的建设也必须遵循同样的方法论。网管标准的制定应该着重于网管接口的标准化，相应地，网管系统的测试也应该着重放在网管接口的测试方面。
从纯技术角度来看，与电信网中的其它测试一样，厂家提供的产品与规范并不总是一致。相对而言，网管接口包含的内容更复杂，包括通信协议测试、信息模型测试和接口功能等，要想解决网管接口的标准化问题，接口测试是必不可少的。
从网管产品的市场角度来看，厂家为了达到广告效应，对网管接口的承诺与产品的实现往往不一致，从测试的结果来看，这种不一致性也是必然的。业务运营商只有通过对产品供应商的网管接口进行测试，才能做到知彼知己。
从我国电信管理网建设的现状来看，我们已经尝到了沉痛的历史教训，对于已经建成的部分重要的电信基础网，由于没有能够在网管接口方面进行规范、测试，导致了后续网管建设的被动。其客观原因在于，我们对网管建设应该遵循的方法论理解不深刻，对网管标准应该规范的内容认识不足，而且没有对厂家的所谓标准接口进行测试。
目前，在信息产业部和中国电信的共同努力下，一套指导网管接口测试的方法论已经形成；在此指导下，多个企业级的测试规范已经完成，相关的测试系统已经具备。承担测试任务的北京邮电大学网络管理系统测试中心已经能够对外提供Q3接口、CORBA接口和传统的基于TCP/IP码流的测试业务，并在国内外产生了很大影响，引起世界各大产品供应商的高度重视。
2.2 行业标准
截止到1999年上半年，我国在电信管理网方面已经发布的标准如表1所示。其中，大部分是关于TMN的基本框架结构的标准，通过这些标准的制定，一个电信管理网标准的基本体系已经形成，为具体业务网管标准化工作的开展打下了基础。
在信息产业部颁布的一系列行业标准所规定的TMN框架范围内，以中国电信和中国移动集团（筹）为代表的企业已经完成了或正在制定有关特定业务网的网管标准，主要包括电话交换网、移动通信网、数据通信网、七号信令网、寻呼网、接入网、传送网和电信管理网本身等。
其中具有代表性的是：
2.2.1 中国电信关于接入网网管的标准系列
该标准系列包括接入网网管规范、接入网网管测试规范、接入网网管测试系统以及网管系统测试实验室。这些行业标准的制定规范了接入网的建设，为接入网网管的建设提供了充分的技术保证。
在标准的制定过程中，作为业务运营商的中国电信在完成网管接口信息模型定义的基础上，选择接口实现技术时只选用了Q3，而没有选择当时还不太成熟的CORBA或其它通信协议。在尽可能地考虑到业务运营商利益的前提下，选择一种而且仅选择一种接口技术作为行业标准是十分合理的，而且事实也证明Q3技术是目前最成熟的接口技术。而CORBA产品还仅仅停留在实验阶段，作为网管接口技术，相关的后续准备措施还不充分，距离实用化还有很大的差距。而且，仅仅从技术角度考虑，将采用GDMO/ASN.1定义的接口信息模型语义等价地转化为IDL信息模型而采用CORBA接口技术也是非常容易的。
2.2.2 GSM网管接口技术规范
中国移动在制定厂商OMC向上层网管系统提供网管接口的标准时，充分考虑了设备供应商的利益，为了在二者利益之间找到一个平衡点，采用了Q3和CORBA两种接口技术。但是，对业务运营商来说，增加了其上层网管系统的开发工作量。
在标准的制定过程中，首先基于Q3接口技术，对网管接口信息模型进行了标准化，由此，准备支持Q3接口的设备厂商可以遵循该标准进行相应网管接口的开发；同时，采用ITU-T最新提出的制定接口标准的方法论，语义等同地将Q3接口信息模型转换为CORBA的信息模型。
2.3 国际标准
自从1997年北京邮电大学代表中国首次向ITU-T第四研究组提交“基于TMN接口的ATM网络管理所使用的管理目标定义”文稿以来，经过两年的努力，已经完成了M.3208.3的建议草案，并在1999年3月的ITU-T全会上讨论,同时M.3108.3建议也将在2000年1月的全会上审批，这是中国在电信网络管理标准化领域第一次被ITU-T接受的建议，将使我国在VPN网络管理的研究、实现和标准化方面具有优势。
3 网管标准发展趋势
在电信管理网标准的基本体系已经初步形成的基础上，我国网管标准研究的下一步工作应该是积极参与ITU-T建议的制定、跟踪其它相关标准化组织的发展；同时，制定实用化的、符合中国实际情况的国家或行业标准。在将来一段时期内，亟待解决的问题表现在以下几个方面：
3.1 网管标准研究方法论的完善
在1999年全会上，ITU-T就目前网管技术发展的现状，对M.3010和M.3020建议进行了修改。其中，M.3010定义的TMN体系结构更强调与技术无关及与协议无关，这一点会影响今后Q3接口的内涵；M.3020确定了UML作为今后有关TMN建议中信息建模和功能描述的一般方法。对此，我国应该尽快对现有的相关行业标准进行修正，并制定对标准化工具进行规范的相关标准，使我国的标准化工作与国际保持同步。
对于现有的各个具体业务网的网管标准，各相关单位应该认真思考RAD方法论的提出对过去已经完成的工作的影响，同时，应该直接在新方法论的指导下完成新标准的制定工作。
3.2 网管标准化工作的定位
从制定标准的主体和标准的作用范围来看，电信管理网的标准可以划分为三个层次，即国际建议、国家标准和行业标准。按照TMN方法论，标准规范的内容应该包括对所研究客体的需求、分析、设计以及产品验证与标准是否相符的测试等四个阶段。
对于不同的标准制定主体来说，其对所研究的客体的标准化内容可以不同，如表2所示。
对于国际建议和国家标准来说，标准的制定可以仅仅涉及需求和分析阶段，而不用关心设计阶段采用的具体技术；为了加强对产品和市场的控制，对于国家标准来说，也有可能对设计阶段采用的某些技术进行限定。
对于行业标准来说，不仅要关心需求、分析和设计三个阶段的所有内容，甚至还要规范按照标准进行产品实现的具体内容；同时，必须要通过测试解决产品与标准的一致性问题，保证异构环境下网管系统的可持续建设。
在将来的标准化工作中，不同的标准制定主体应该根据不同客体的实际情况，在国家利益、业务运营商利益和产品供应商利益三者之间找到一个平衡点，对所负责的标准化工作的内容进行定位。
3.3 网管具体实现技术
按照TMN的方法论，标准化工作在实现阶段必须与具体的技术相结合。目前，引起激烈争论的是对CORBA和Q3这两种技术的应用，现将二者比较如下：
首先，CORBA代表了分布式计算技术的未来，当我们把目光转移到网管系统产品的现实中来时，会发现要为分布式处理系统提供一个有效的环境（包括可靠的网络、高速运算的硬件等），其代价是相当昂贵的。在我国，尽管信息网络建设在超高速发展，但是由于许多具体的历史、经济、自然条件所限，许多电信网络运营商不可能为电信管理网提供一个如此昂贵的DCN（数据通信网），在某些地方，甚至传统的Modem通信方式还要存在一个较长的时期。因此，对于现有网上运行的网管系统，无论CORBA技术，还是Q3技术都是作为一种数据通信接口技术来使用的。通过该通信接口，所有的网管数据都被收集到本地的NMS，然后再对这些数据进行集中分析、处理，而没有充分利用分布式计算的特性。
从方法论角度来看，在网管系统的分析和设计阶段，与OMG IDL语言相比较，Q3接口技术采用的GDMO/ASN.1描述语言可以更方便地进行信息建模，如果UML与IDL相结合，有可能满足电信管理网的建模要求。目前的现状是，如果给定一个GDMO/ASN.1描述的信息模型，花费较少的时间就可以对其精确地理解；如果给出的是用IDL描述的同样的一个信息模型，接口双方将会花费很多时间对其细节进行无休止地讨论。
从软件重复使用角度来分析，CORBA的标准对象服务还不足以方便地用来进行网管系统的开发。在基于Q3接口的TMN框架内，类似事件管理、日志管理、性能管理等一系列通用系统管理功能，已经作为标准被普遍接受。然而，OMG目前定义的CORBA服务大部分是支持分布式处理通用的一些服务，针对网络管理领域的服务或者与ITU-T的建议有很大出入，或者还没有涉及，总之，距离TMN的要求还很远。CORBA规范3.0版本中，可能在一定程度上会对该问题做出明确规范。
从系统开发角度分析，OMG IDL转换为编程语言的标准化工作要优于GDMO/ASN.1转换为编程语言的标准化工作。在解决GDMO/ASN.1转换为编程语言的标准化问题上，ITU-T没有参与。对此，TMF曾经做出了很大努力，但是由于某些历史和商业原因，它将某个厂家已经实现的产品中采用的转换方法作为标准，使得所谓的标准成为一纸空文，没有得到大多数主要网管平台开发商的支持。但是，在CORBA规范的制定过程中，直接完成了OMG IDL转换为编程语言的标准化任务，并且规范了到各种流行的编程语言的转换方法，从而得到了所有CORBA产品供应商的支持，成为了事实上的标准。同时，令开发人员鼓舞的是，该方法得到了X/Open的支持。
从目前产品的现状来看，在经历了十几年的发展之后，基于Q3技术的网管开发、运行平台要比采用CORBA技术的产品更稳定，而且在大量的实际工程中已经得到了验证。产品之间的互联、互通得到了很好的保证。对于目前的CORBA产品，一方面，CORBA规范是如此的完美；另一方面，没有专门的机构和措施来检验CORBA产品与CORBA规范的一致性，从而导致实际中不同厂商的CORBA产品之间的互联存在问题，而没有达到CORBA本身所希望的目标。更为遗憾的是，即使同一个产品供应商的基于不同硬件平台的CORBA产品也不能进行很好的互联，但是，应该相信CORBA产品经过一段时间的锤炼，相应的问题会得到解决，我们有理由对其未来充满信心。
3.4 综合网管的问题
由于IP业务和网络在全球的迅猛发展，如何解决IP网和基于电路概念的传统电信网的综合管理问题是目前网管标准化工作的重点。1998年9月ITU-T在美国奥兰多举行了IP技术研讨会，并召开了TSAG会议，一致通过为满足日益增长的IP业务和技术标准化的需求而加强对IP网管理的标准化力度的建议。
目前，ITU-T各研究组都已经开展IP方面的研究，第四研究组特别增设了相关专题，对电路交换和包交换综合网络的统一管理框架、统一的IP和电路交换网络的控制功能和基于服务器的应用的管理等问题进行标准化研究。
网管标准的制定仅仅为网管系统的建设创造了技术条件，但是如何保证网管标准的贯彻实施，还需要相应的行政管理措施相配合。对此，中国电信在接入网和DWDM传输网网管建设中，已经通过基于接口测试、发放入网认可等措施积累了一套行之有效的经验。
回复人：playpcgame(2000-10-10 15:22:00) 得0分
网管软件一般都支持SNMP（简单网络管理协议），能与惠普公司的Open View Professional Suite专业程序集和Open View Network Node Manager节点管理器结合得天衣无缝，并提供MIB（管理信息基地）、RMON（远程监控）等功能。
SNMP（简单网络管理协议）是一种广为执行的网络协议，它使用嵌入到网络设施中的代理软件来收集网络的通信信息和有关网络设备的统计数据。代理软件不断地收集统计数据，并把这些数据记录到一个管理信息库（MIB）中。网管员通过向代理的MIB发出查询信号可以得到这些信息，这个过程叫轮询（polling）。虽然MIB计数器将统计数据的总和记录下来了，但它无法对日常通信量进行历史分析。为了能全面地查看一天的通信流量和变化率，管理人员必须不断地轮询SNMP代理，每分钟就轮询一次。这样，网管员可以使用SNMP来评价网络的运行状况，并揭示出通信的趋势，如哪一个网段接近通信负载的最大能力或正使通信出错等。先进的SN？MP网管站甚至可以通过编程来自动关闭端口或采取其它矫正措施来处理历史的网络数据。然而SNMP轮询有个明显的弱点：它没有伸缩性。在大型的网络中，轮询会产生巨大的网络管理通信量，因而导致通信拥挤情况的发生。它将收集数据的负担加在网络管理控制台上。管理站也许能轻松地收集8个网段的信息，当它们监控48个网段时，恐怕就应付不下来。
1. SNMP管理模型
1.1 什么是SNMP
SNMP（Simple Network Management Protocol）是被广泛接受并投入使用的工业标准，它的目标是保证管理信息在任意两点中传送，便于网络管理员在网络上的任何节点检索信息，进行修改，寻找故障；完成故障诊断，容量规划和报告生成。它采用轮询机制，提供最基本的功能集。最适合小型、快速、低价格的环境使用。它只要求无证实的传输层协议UDP，受到许多产品的广泛支持。SNMP在TCP/IP协议族中的地位如下图：
1.2 SNMP的基本操作：
SNMP以GET-SET方式替代了复杂的命令集，利用基本操作演绎出全部操作。用户可以采用管理信息库标准或按标准的方式来定义自己的管理信息库（MIB）。这样做的好处是：通过降低占网管系统中大多数的代理部件的成本来降低整个网管系统的成本。
1.3 网管站和代理
网管站（NMS）对网络设备发送各种查询报文，并接收来自被管设备的响应及陷阱（trap）报文，将结果显示出来。代理（agent）是驻留在被管设备上的一个进程，负责接受、处理来自网管站的请求报文，然后从设备上其他协议模块中取得管理变量的数值，形成响应报文，反送给NMS。在一些紧急情况下，如接口状态发生改变，呼叫成功等时候，主动通知NMS（发送陷阱TRAP报文）。
他们的关系如下图：
SNMP就是用来规定NMS和Agent之间是如何传递管理信息的应用层协议。
1.4 ASN.1和SMI
SNMP是应用层协议，它要求两端的协议实体交换各种报文，而低层要求用户数据都是BYTE序列，这就产生了一个问题： SNMP协议实体如何从接受到的一个BYTE序列中识别出报文又如何把一个用内部数据结构表示的报文转换成一个可供发送的BYTE序列， 也就是编解码问题。
解决这个问题，就需要一个定义从实际的软件数据结构中抽象出来的数据类型的表示方法，称为抽象句法。
ASN.1就是用来描述抽象记法的语言，事实上可应用与任何协议层，在它的基础上，通过规定编码规则，就可以确定数据在传送中的八比特组的值。
SMI（Struct of Management Imformation），通过定义一个宏OBJECT-TYPE，规定了管理对象的表示方法，从这个意义上说，它是ASN.1的一个子集。另外它还定义了几个SNMP常用的基本类型和值。
MIB (Management Imformation Base), 是所监控网络设备的标准变量定义的集合。SNMP用层次结构命名方案来识别管理对象，就象一棵树，树的节点表示管理对象，它可以用从根开始的一条路径来无二义的识别。见下图：
管理对象B可以用一串数字唯一确定{1.2.1.1} 这串数字是管理对象的object identifier（客体标识符）。通过object identifier可确定从根到 B的一条路径。
管理对象 A 的object identifier 是{1.2.1.1.5}，或{B 5},后一种表示方法表明A是B的第5棵孩子。
在agent中这棵树是用较复杂的数据结构来实现的，幸运的是，建树这个工作可由MIB编译器完成。在树的叶节点中，存放有访问函数的指针，Agent就是通过调用这些函数来从相关模块取得管理变量的值的。
1.5 SNMP报文
SNMP报文结构如下：（编码之前）
SNMP共有5中报文，所以其PDU也有5中，仅以GetRequest-PDU为例
2. 管理变量的表示
管理变量表示管理对象类型在某一时刻的值（或称该类型的实例），SNMP以管理变量作为操作对象。
管理变量的表示方法是这样规定的：形如x.y，其中x是管理对象的object identifer。y是能唯一确定对象类型值的一组数字，在非表型变量中为0，在表型变量中是这个表的索引，比如接口表中的接口号，或路由表中的目的网络地址等等 。如：在MIB文件里定义了ipAdEntNetMask这一管理对象，其object identifier为1.3.6.1.1.5.6.1.3它是个路由表中的一项，它的一个实例就是路由表中某一行的子网掩码，如果这行的索引、目的网络地址为129.102.1.0。则这个变量名是：1.3.6.1.1.5.6.1.3.129.102.1.0。在以后的说明中，为了方便，把唯一确定管理变量的一组数字，也就是x.y中的y称作实例。
3. SNMP的运行过程
驻留在被管设备上的AGENT从UDP端口161接受来自网管站的串行化报文，经解码、团体名验证、分析得到管理变量在MIB树中对应的节点，从相应的模块中得到管理变量的值，再形成响应报文，编码发送回网管站。网管站得到响应报文后，再经同样的处理，最终显示结果。
下面根据RFC1157详细介绍Agent接受到报文后采取的动作：
首先解码生成用内部数据结构表示的报文，解码依据ASN.1的基本编码规则，如果在此过程中出现错误导致解码失败则丢弃该报文，不做进一步处理。
第二步：将报文中的版本号取出，如果与本Agent支持的SNMP版本不一致，则丢弃该报文，不做进一步处理。当前北研的数据通信产品只支持SNMP版本1。
第三步：将报文中的团体名取出，此团体名由发出请求的网管站填写。如与本设备认可的团体名不符，则丢弃该报文，不做进一步处理，同时产生一个陷阱报文。SNMPv1只提供了较弱的安全措施，在版本3中这一功能将大大加强。
第四步：从通过验证的ASN.1对象中提出协议数据单元PDU，如果失败，丢弃报文，不做进一不处理。否则处理PDU，结果将产生一个报文，该报文的发送目的地址应同收到报文的源地址一致。
根据不同的PDU，SNMP协议实体将做不同的处理：
1)、GetRequest PDU：
第一种情况：如果PDU中的变量名在本地维护的MIB树中不存在,则接受到这个PDU的协议实体将向发出者发送一个GetResponse报文，其中的PDU与源PDU只有一点不同：将ERROR-STATUS置为noSuchName,并在ERROR-INDEX中指出产生该变量在变量LIST中的位置。
第二种情况：如果本地协议实体将产生的响应报文的长度大于本地长度限制，将向该PDU的发出者发送一个GetResponse报文，该PDU除了ERROR-STATUS置为tooBig，ERROR-INDEX置为0以外，与源PDU相同。
第三种情况：如果本地协议实体因为其他原因不能产生正确的响应报文，将向该PDU的发出者发送一个GetResponse报文，该PDU除了ERROR-STATUS置为genErr，ERROR-INDEX置为出错变量在变量LIST中的位置，其余与源PDU相同。
第四中情况：如果上面的情况都没有发生，则本地协议实体向该PDU的发出者发送一个GetResponse报文，该PDU中将包含变量名和相应值的对偶表，ERROR-STATUS为noError,ERROR-INDEX为0，request-id域的值应与收到PDU的request-id相同。
2)、GetNextRequest PDU
GetNextRequest PDU的最重要的功能是表的遍历，这种操作受到了前面所说的管理变量的表示方法的支持，从而可以访问一组相关的变量，就好象他们在一个表内。
下面通过一个例子解释表遍历的过程：
被管设备维护如下路由表：
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
假设网管站欲取得这张路由表的信息，该表的索引是目的网络地址。
网管站向被管设备发送一个GetNextRequest PDU,其中的受管对象的标识如下
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
SNMP agent响应如下GetResponse PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
网管站继续：
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
agent响应：
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
值得注意的是agent必须能够确定下一个管理变量名，以保证所有变量能被取到且只被取到一次。
网管站继续：
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
agent 响应：
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
网管站继续
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
这时因为路由表中所有的行都被取遍，agent因返回路由表对象的下一字典后继即该管理对象在MIB树中的后序遍历的直接后继。这里应是nettoMediaIndex，管理对象的OBJECT IDENTIFIER。这个响应通知网管站对表的遍历已经完成。
3)、GetResponse PDU
GetResponse PDU只有当受到getRequest GetNextRequest SetRequest才由协议实体产生，网管站收到这个PDU后，应显示其结果。
4)、SetRequest PDU
SetRequest PDU除了PDU类型标识以外，和GetRequest相同，当需要对被管变量进行写操作时，网管站侧的协议实体将生成该PDU。
对SetRequest的响应将根据下面情况分别处理：
(1)． 如果是关于一个只读变量的设置请求，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为noSuchName, error index的值是错误变量在变量list中的位置。
(2)． 如果被管设备上的协议实体收到的PDU中的变量对偶中的值，类型、长度不符和要求，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为badValue, error index的值是错误变量在变量list中的位置。
(3)． 如果需要产生的GetReponse报文长度超过了本地限制，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为tooBig, error index的值是0。
(4)． 如果是其他原因导致SET失败，则收到该PDU的协议实体产生一个GetReponse报文，并置error status为genErr, error index的值是错误变量在变量list中的位置。
如果不符合上面任何情况，则agent将把管理变量设置收到的PDU中的相应值，这往往可以改变被管设备的运行状态。同时产生一个GetResponse PDU，其中error status置为noError,error index的值为0。
4)
本文地址：http://com.8s8s.com/it/it35927.htm