以太网络拓扑发现 SNMP.docVIP

以太网络拓扑发现 原理概述 简单网络管理协议(SNMP)首先是由Internet工程任务组织(Internet Engineering Task Force)(IETF)的研究小组为了解决Internet上的路由器管理问题而提出的。许多人认为 SNMP在IP上运行的原因是Internet运行的是TCP/IP协议，然而事实并不是这样。 SNMP被设计成与协议无关，所以它可以在IP，IPX，AppleTalk，OSI以及其他用到的传输协议上被使用。 SNMP是一系列协议组和规范（见下表），它们提供了一种从网络上的设备中收集网络管理信息的方法。SNMP也为设备向网络管理工作站报告问题和错误提供了一种方法。 名字 说明 MIB 管理信息库 SMI 管理信息的结构和标识 SNMP 简单网络管理协议 从被管理设备中收集数据有两种方法：一种是只轮询（polling-only）的方法，另一种是基于中断（interrupt-based）的方法。 如果你只使用只轮询的方法，那么网络管理工作站总是在控制之下。而这种方法的缺陷在于信息的实时性，尤其是错误的实时性。你多久轮询一次，并且在轮询时按照什么样的设备顺序呢？如果轮询间隔太小，那么将产生太多不必要的通信量。如果轮询间隔太大，并且在轮询时顺序不对，那么关于一些大的灾难性的事件的通知又会太馒。这就违背了积极主动的网络管理目的。 当有异常事件发生时，基于中断的方法可以立即通知网络管理工作站（在这里假设该设备还没有崩溃，并且在被管理设备和管理工作站之间仍有一条可用的通信途径）。然而，这种方法也不是没有他的缺陷的，首先，产生错误或自陷需要系统资源。如果自陷必须转发大量的信息，那么被管理设备可能不得不消耗更多的时间和系统资源来产生自陷，从而影响了它执行主要的功能（违背了网络管理的原则2）。 而且，如果几个同类型的自陷事件接连发生，那么大量网络带宽可能将被相同的信息所占用（违背了网络管理的原则1）。尤其是如果自陷是关于网络拥挤问题的时候，事情就会变得特别糟糕。克服这一缺陷的一种方法就是对于被管理设备来说，应当设置关于什么时候报告问题的阈值（threshold）。但不幸的是这种方法可能再一次违背了网络管理的原则2，因为设备必须消耗更多的时间和系统资源，来决定一个自陷是否应该被产生。 结果，以上两种方法的结合：面向自陷的轮询方法（trap-directed polling）可能是执行网络管理最为有效的方法了。一般来说，网络管理工作站轮询在被管理设备中的代理来收集数据，并且在控制台上用数字或图形的表示方式来显示这些数据。这就允许网络管理员分析和管理设备以及网络通信量了。 被管理设备中的代理可以在任何时候向网络管理工作站报告错误情况，例如预制定阈值越界程度等等。代理并不需要等到管理工作站为获得这些错误情况而轮询他的时候才会报告。这些错误情况就是众所周知的SNMP自陷（trap）。 在这种结合的方法中，当一个设备产生了一个自陷时，你可以使用网络管理工作站来查询该设备（假设它仍然是可到达的），以获得更多的信息。 … Get：一次只读一条记录，而且对于目标oid肯定，例如，希望读取sysDescr的值，则oid值必须输入..0。 GetNext:一次只读取一条记录，但是能读取不确定的oid所对应的信息，如输入.，也能读出对应的sysDescr值。 GetBulk:一次能读取多条数据，需要在对应的edit框中输入所需读取的信息数目，例如在oid中输入.2.1.1，在edit栏中输入7，就能读出System组的所有7条信息。 效果图： 程序设计说明： 目前流行的snmp工具包主要有net-snmp,agent++,snmp++,和winsnmp，我用的是由微软提供的winsnmp开发包，因为其它的工具包要么不是免费的（如hp公司的snmp++和agent++），要么是针对linux系统开发的，对VC的支持不好，所以被迫选择了winsnmp，使用之后发现这个开发包很不好用，集成度太低，而且宏定意相当凌乱，总之，花了相当功夫才上手的。 我自己将winsnmp.h提供的api封装成一个CSnmp类，方便后面程序的开发，期中主要的函数有： //构造函数 CSnmp(); 主要封装了三个api: //启动Snmp服务 SnmpStartup(nMajorVersion,nMinorVersion,nLevel,nTranslateMode,nRetransmitMode) //设置传输模式 *注意，这里必须为V2以上版本，否则对很多功能不支持。 SnmpSetTranslateMode(SNMPAPI_UNTRANSLATED_V2) //设置重传模式 SnmpSetRetran