当前位置:首页 >> 信息与通信 >>

基于SNMP的WEB 分布式网络管理系统设计实例

4.5 基于 SNMP 的 Web 分布式网络管理体系结构设计
4.5.1 体系结构设计内容 论文对 Web 服务技术在网络管理中的应用情况进行了详细的分析, 并设计实现了一个基 于 SNMP 的 Web 分布式网络管理系统模型 SWNMS(SNMP-basedWeb Network Management System)。在 SWNMS 中,主要做了以下几个方面的研究: 1、基于 SNMP 的网络拓扑发现,以及配置管理、性能管理、故障管理的部分实现。 2、网络管理系统实现所采用的技术的研究。 3、基于 Web 网络管理系统设计中安全机制的解决办法。 4.5.2 SWNMS 体系结构模型 传统的基于 SNMP 的网络管理模型中,管理站在整个网络中一旦确定下来,其位置也就 固定,很难随着管理员当前的位置在网上移动。为了解决该问题,提高网络管理效率,本文 将 SNMP 与 Web 技术结合,构造了一种基于 B/S 结构的 SNMP 网络管理框架,如图 4.6 所示。

由于 Java 的跨平台特性和丰富的图形表现能力, 因此被该模型用来向管理者提供 GUI。 它接收管理者发出的各种监控命令,然后调用 SNMP 管理器向 SNMP Agent 发出相应的控制报 文, SNMP 管理器返回响应后把处理结果以图文方式呈现给管理者。 当 SNMP 管理器接收 Java Applet 发来的控制命令,通过 SNMP 协议传递给 SNMP Agent 执行,并把其返回的响应提交 给 Java Applet。同时 SNMP 管理器还负责监听被管设备资源发来的报警通知,提交给 JavaApplet,由 JavaApplet 向管理者报告以便及时处理。 整个管理模型由 JavaApplet 管理程序、Http Server、SNMP 管理器和代理几部分组成, 各部分的作用功能如下: 1)Java 管理程序嵌在网页中的 Java 程序,为用户提供管理接口,充当形式上的管理 站的角色。通过与 SNMP 管理器的交互,来完成管理任务的下发以及显示由代理发来的响应 信息和 Trap 信息。 管理程序还负责将通过 SNMP 管理协议获得的网络拓扑信息显示在屏幕上。 2)Web 服务器负责接受管理员登陆,提供下载 Java Applet 管理程序,显示网络管理 工作面。本模型采用多服务器群集技术,提高网络数据处理速度,均衡网络负载,缓解网管

主机数据处理瓶项。 3)SNMP 管理器 SNMP 管理器是整个模型的核心部分,也是事实上的管理站。由 SNMP 用 户接口模块,SNMP 命令生成器和 SNMP 命令解释器三部分构成。其中 SNMP 用户接口模块负 责监听来自 Java Applet 的管理请求,SNMP 命令生成器负责将管理请求封装成相应的 SNMP 数据报文,然后发送给代理。SNMP 命令解释器负责监听来自 Agent 的信息(该信息可能是 某个命令的响应,也可能是一个 Trap 消息) ,并按照指定的格式对其进行分析,然后发给 JavaApplet。 4)代理(Agent) 这里的 Agent 的作用与传统方式下的 Agent 功能是一样的, 一是负责搜索器所代理的设 备的信息, 并将它们记入 MIB; 二是负责响应管理站发出的管理命令并发出相应的反馈信息。 4.5.3 SWNMS 数据传输流程 以客户端发送 Request 请求为例,管理员通过管理界面取得认证后可以通过 Java Applet 小程序向 SNMP 管理器发送 Request 请求, SNMP 管理器接收到请求命令后, 按照 Agent 私有协议将数据加密, 然后组装成 SNMPv2 数据报文, BER 编码后发送给 Agent 代理, 经 Agent 收到报文后,进行解密,验证权限后即可进行协议请求操作,完成 Response 响应。数据流 程如图 4.7 所示。

4.5.4 相关 MIB 对象集 为了适用于各厂商的网络设备, 使本系统具有很好的兼容性, 本文的网络管理系统不使 用私有的 MIB,尽量使用标准通用的 MIB。本系统涉及到的 MIB 有 MIB-2、Bridge-MIB[30] 和 Host Resources MIB[31],分别定义在 RFC1213、RFC1493 和 RFC2790 中。其中 MIB-2 包 含十个功能组,它定义了本文配置管理、性能管理、故障管理等要用的大部分管理对象,目 前几乎所有的网络设备都实现了此 MIB; Bridge-MIB 主要实现在网桥和交换机设备中, 包含

dot1dBase 组、dot1dStp 组、dot1Sr 组、dot1dTp 组和 dot1dStatic 组,主要定义了在透明 模式下桥接实体操作管理需要的对象, 本文使用其中的地址转发表帮助二层网络拓扑结构的 发现;Host Resources MIB 定义了用于主机管理的对象集,该 MIB 对于某些用于通信服务 的设备如路由器、交换机、网桥等不一定适用,但是包含了所有 Internet 主机共有的属性。 它定义了 6 个功能组:Host Resources System Group、HostResources Storage Group、Host Resources Device Group、 Host Resources RunningSoftware Group、 Host Resources Running Software Performance Group、HostResources Installed Software Group,包含了主机基 本信息、存储器信息、 系统设备信息、 安装软件、 运行软件、 运行软件消耗资源等管理对象, 在本系统中用于监视管理重要的网络服务器,如 FTP 服务器、DNS/DHCP 服务器、Mail 服务 器等。 对使用的 MIB 对象按管理功能分类十分重要, 各种网络管理的基础就是获取或是设置相 应的 MIB 对象值,下面以表格的形式具体描述各类 MIB 对象。 4.5.4.1 拓扑结构对象 与网络拓扑结构信息相关的 MIB 对象有 MIB-2 IP 功能组中的路由表 IpRouteTable,地 址表 IpAddrTable,at 功能组的地址解析表 atTable 和 Bridge MIB 中的地址转发表等,其 具体描述如下:

4.5.4.2 配置管理对象 本系统中的配置管理信息主要用来保存一些比较固定的信息, 包括 MIB-2 中系统组的对 象信息,如设备的名称、描述、启动时间、位置、负责人等,还有 Host Resource MIB 中的 主机安装软件集合、主机硬件配置、存储器与处理器等信息。这些和配置管理相关的 MIB 对象见如下表格:

4.5.4.3 性能管理对象 性能管理的目标是衡量和呈现网络特性的各个方面, 是网络管理最重要的部分, 用到的 管理对象也是最多的, 在这里本文只列出 Host Resource MIB 中的运行软件组、 运行消耗组, MIB-2 中的 IP 组、TCP 组、UDP 组。

4.5.4.4 故障管理对象 故障管理主要包括以下几下方面: 定义各种性能参数的阈值, 超出阈值产生故障信息存 储在数据库中;定时查询设备的接口状态,如有故障产生故障信息存储在数据库中;接受代 理设备的各种 Trap 故障信息存储在数据库中;主动轮询各种故障信息,向管理员报告故障 源,以便管理员查询故障信息与历史解决经验。 本文所采用的故障管理对象如表 4.11。

第五章基于 SNMP 的 Web 分布式网络管理系统的设计与实现
5.1 系统平台 5.1.1 系统应用平台 本网络管理系统应用平台是南京奥罗拉软件公司的局域网络。 南京奥罗拉软件公司是一 家从事基于 Web、WLT、数据库以及 VPN 等多种数据处理技术、网络互联技术的医疗保险信 息处理机构。其网络结构主要包含两个网段,实现域和 Workgroup 组的划分。公司是一家信 息处理机构, 因此网络包含 Web 服务器、 服务器、 Ftp 数据库服务器、 Mail 服务器、 DNS/DHCP 服务器、域服务器、文件服务器等多种类型的服务器。这些服务器由管理员统一管理,集中 控制。公司通过 Cisco2600 接入外网,外网与公司内部局域网由硬件防火墙作为网关,主要 用来进行网络访问控制以及防止病毒黑客入侵。网络设备主要采用 Cisco 公司的网络产品, 支持 SNMPv1 和 SNMPv2。其网络拓扑结构逻辑示意图如图 5.1 所示。

5.1.2 系统运行平台 (1)开发环境 开发平台:Windows2000 操作系统 开发工具:J2SE JDK6.0,Advent SNMPv2c API Package,Eclipse,SQLServer2000。 (2)运行环境 运行的 Web 服务器为 Tomcat Web 服务器。服务器为 Intel Pentium 1.8G,512M 内存, 40G 硬盘,操作系统 Win2000。 客户端运行 IE6.0 或 Maxthon1.5.9。

5.2 系统实现关键技术
5.2.1 SNMP 平台 SNMP 平台是实现网络管理系统的基础, 本课题选用的是美国 Advent 公司提供的 Advent

SNMPv2c Package[32],它具有以下特点:支持 SNMPvl 和 SNMPv2,具有对 MIB 的 Parser 功 能,并可通过 URL 支持装载多个 NUB。实现了 SNMP 协议栈的基本功能如:snmpGet, snmpGetNext,snmpBulk,snmpSet,snmpTrap 等,并提供了一整套 Java 类来实现以上功能, 如: MibMoudle:负责对 MIB 模块文件的装载和解析(Parse)等工作。 SnmpSession:负责对每一个会话进行管理,例如向某一主机发送一个 SNMPPDU 并接收 响应。 SnmpPDU:负责对 SNMP PDU 的打包、拆包工作,例如我们通过定义一个 SnmpPDU 类为 SNMP Get PDU, 使用 SnmpSession 将其发送到某一 Agent 上, 接收回应的 PDU, 再通过 SnmpPDU 提供的功能就可以得到报文中的数据。 SnmpOID:标志了 MIB 树形结构相应的节点标志。 5.2.2 服务器负载均衡技术 在负载均衡的思路下,多台服务器为对称方式,每台服务器都具有同等的地位,可以单 独对外提供服务而无须其他服务器的辅助。 通过负载分担技术, 将外部发送来的请求按一定 规则分配到对称结构中的某一台服务器上,而接收到请求的服务器都独立回应客户机的请 求。 提供服务的一组服务器组成了一个应用服务器集群(cluster)[33],并对外提供一个统 一的地址。当一个服务请求被发至该集群时,根据一定规则选择一台服务器,并将服务转定 向给该服务器承担,即将负载进行均衡分摊。 通过应用负载均衡技术,使应用服务超过了一台服务器只能为有限用户提供服务的限 制,可以利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时,负载均衡服 务器会自动进行检测并停止将服务请求分发至该服务器, 而由其他工作正常的服务器继续提 供服务,从而保证了服务的可靠性。 负载均衡实现的方法有以下几种: 最简单的是通过 DNS,但只能实现简单的轮流分配,也不能处理故障[34]。 ? 如果是基于 MS IIS,Windows 2003 Server 本身就带了负载均衡服务。但这一服务也只 是轮流分配。 ? 硬件方式: 通过交换机的功能或专门的负载均衡设备可以实现。 对于流量的分配可以有 多种方式,但基本上都是应用无关的,与服务器的实际负载关系也不大。另外,设备的 价格较贵(优点是能支持很多台服务器)。这种方式往往适合大流量、简单应用。 ? 软件方式:通过一台负载均衡服务器进行,上面安装软件。这种方式比较灵活,成本也 相对较低。另外一个很大的优点就是可以根据应用的情况和服务器的情况采取一些策 略。这方面比较典型的软件产品是富士通西门子公司的 PCL SIS 负载均衡软件。 本文采用路由器中地址转换实现两台 Web 服务器的负载均衡。 interface FastEthernet0/0 description Link to CNC-Dedicated 10M ip address 218.104.94.14 255.255.255.252//定义广域网 IP no ip redirects ip nat outside //定义为广域网端口 no ip mroute-cache speed 10 full-duplex ! interface FastEthernet0/1

description Link to LAN ip address 218.104.84.97 255.255.255.0 secondary ip address 192.168.0.8 255.255.255.0 //定义广域网端口 IP no ip redirects ip nat inside no ip mroute-cache speed auto full-duplex ! ip nat pool aurora-cncl 58.240.60.1 58.240.60.2 netmask 255.255.255.248 //定义合法 IP 地址池,名称为 aurora-cncl ip nat pool websev 192.168.0.3 192.168.0.4 255.255.255.248 type rotary //定义 Web 服务器的 IP 地址池,名称为 websev。Rotary 关键字表示准备使用轮询策略从 NAT 池中取出相应的 IP 地址用于转换进来的 IP 报文,访问 58.240.60.10 的请求将依次被 发送给主 Web 服务器器 192.168.0.3,辅助 Web 服务器 192.168.0.4,实现负载均衡。 ip nat inside source list 1 pool aurora-cnc1 overload ip nat inside destination list 2 pool websev //inside destination list 语句定义与列表 2 相匹配的 IP 地址的报文将使用轮询策略 ip nat inside source static 10.200.10.61 218.104.84.106//绑定静态 IP 地址 ip nat inside source static 10.200.1.14 218.104.84.109 ip nat inside source static 10.200.10.60 218.104.84.108 access-list 1 permit 192.168.0.0 0.0.0.255 access-list 1 permit 10.200.0.0 0.0.255.255//定义本地访问列表 access-list 2 permit 58.240.60.10//定义轮询地址列表 5.2.3 客户端实现方式 客户端有两种实现方式:HTML Client 和 JAVAClient。它们同服务器之间的通信完全是 两种不同的方式,如图 5.2 所示。

HTML Client 是指客户端通过 HTTP 请求的方式,来获取服务器上的 HTML 文档,其客户 界面完全是在浏览器中, 所有对服务器上的数据操作也都通过浏览器。 服务器则根据客户的 请求来启动 Servlet,来回答客户的请求。 JAVA Client 是以 applet 的方式,applet 从服务器下载到客户端,在客户端主机上运 行,这些 applet 与服务器可以通过 socket 等方式进行通信。在 JAVAClient 方式下,客户 端界面基于 GUI,可以由 JDK 提供的 AWT 包实现,其效果要优于 HTML 方式。 表 5.1 比较了客户端这两种实现方式。 表 5.1 客户端实现方式比较 HTTP Client 界面效果 通讯方式 通讯范围 通讯速度 基于浏览器 HTTP 协议 不受限制 较快 Java Client GUI,效果好 Socket 等协议 受安全限制 较慢

本文采用的是 Java Client 实现方式。 客户端只要求是能够支持 Java Applet 的浏览器, 其通过 HTTP 协议与 Web 服务器进行通信,因此客户端的实现主要涉及到 HTML 文件和 JavaApplet 程序的实现。 当客户端访问服务器的主页时,嵌入于主页的 Java Applet 程序通过网络下载到客户端 的浏览器,并在其上运行。JavaApplet 接收用户的输入,并与服务器进行通信,从而实现 交互式的操作。JavaApplet 的作用主要是图形界面与查询结果的显示,它与 Java ORB 建立 连接后, 就能通过引用对象 hostServant 的变量 ps_host 来引用服务对象而不必知道其位置 与连接等具体信息。

//HostApplet.java import java.awt.*; import HostPackage.*; import org.omg.CosNaming.NamingContextPackage.*; public calss HostApplet extends java.applet.Applet{ public HostApplet(){……}; private hostServant ps//服务对象引用变量 public void init(){ ………… ps host.Regist("dll");//调用服务对象操作 } //init 操作结束 } //主程序结束在程序运行时,先必须启动 Server 程序,然后用户就只需通过 Web 浏览 器 访问相应的网页,Applet 就会下载到本地运行,获取服务组件提供的服务[35]。 5.2.4 拓扑结构的 Java 类实现 Java 是面向对象的语言,拓扑发现的所有功能模块都被封装在设计的 Java 类中,主要 有下列类: topoDiscoveryInterface.class:接口申明类,其中申明了拓扑发现模块提供的方法, 我们给与如下定义。 Public interface topoDiscoveryInterface{ //网络层拓扑发现方法的声明 Public java.util.Vertor DiscoverTopologyThree(java.net.InetAddress ipThree)Throws java.rmi.Exception; //数据链路层拓扑发现方法的声明 Public java.util.Vertor DiscoverTopologyTwo(java.net.InetAddress ipTwo) Throws java.rmi.Exception; } topoUi.class:拓扑图用户界面类,负责调用拓扑发现功能和对拓扑图进行显示; topoDiscoveryImpl.class:拓扑发现实现类,定期进行拓扑发现,刷新数据; mapServer.class:图符生成类,负责拓扑图符的生成和修改。 5.3 SWNMS 网络拓扑结构发现算法研究 拓扑发现是是配置管理的核心、 故障管理的基础, 同时也是衡量一个商业网络管理系统 成败的重要尺度[36]。 所谓拓扑发现就是获取和维护网络元素的存在性信息以及它们之间的 连接关系信息,并在此基础上给出整个网络连接状态的图示,网络元素是指路由器、网关、 交换机、主机和子网等。目前网络拓扑发现主要分为网络层拓扑发现和数据链路层发现。网 络层拓扑又称第三层拓扑, 对应于 ISO/OSI 的七层模型中的第三层, 反映的是路由器到路由 器、路由器端口到子网的连接关系;数据链路层拓扑又称第二层拓扑,对应于 ISO/OSI 的七 层模型中的第二层反映了交换机之间端口联接关系, 交换机与主机、 路由器之间的连接关系。 网络拓扑结构在现代 IP 网络的网络管理中扮演非常重要的角色,国内外很多人对拓扑 算法的发现作了大量的研究,目前常用拓扑发现技术有如下几种: (1)基于 ARP 协议的拓扑发现方法任何有以太网接口的网络设备都必须支持地址解析 协议(ARP) ,并在本机维护着一张 ARP 表,用于 IP 地址与以太网地址之间的地址解析与转

换。 根据任何一台路由器或交换机的 ARP 表, 可以发现与其各以太网端口相连的以太局域网 中的所有网络设备,再判定网络中的路由器与交换机,并继续根据 ARP 表进行发现,从而得 到整个以太网的拓扑结构。这种方法发现率较高,发现迅速简洁,它的不足之处在于实时性 稍差(这一延时与 ARP Cache 表的刷新频率有关), 如某台已关闭的主机仍会在一段时间内被 认为是活动的, 查询的结果会与实际网络的运行情况有出入, 且网络中的一些故障及错误不 能及时发现。同时这种发现算法也不能发现那些不支持 ARP 协议的网络连接和设备。 (2)基于 OSPF 协议的拓扑发现算法 OSPF 协议是一种链路状态协议,已经成为 IAB 推 荐的内部网关协议,目前得到了广泛的应用。OSPF 协议使所有路由器节点都存放一个完整 的网络链路状态图,通过路由器之间的通信来交换彼此的链路状态图,不断更新其内容,保 持所有路由器的链路状态图的一致性。 所以只要访问任一路由器的路由表就可以发现所有子 网的路由信息, 即可构造出拓扑连接信息。 这种方法可以快速发现网络中的所有的子网与路 由器,但是需要所有路由器都支持 OSPF 协议并在每个路由器上正确配置 OSPF 协议。 (3)基于 RIP 协议的拓扑发现算法这种方法与基于 OSPF 协议的方法类似。RIP 是一种 距离向量路由协议,RIP 使路由器每个节点存放到达各个目标站点的距离。所谓距离就是到 达目标节点所经过的跳数。RIP 要求每隔 30s 各路由器向其相邻路由器发送自己存放的、到 达各目标主机的距离信息, 即广播自己的所有路由表项, 同时接收其它相邻路由器发送来的 路由表项更新报文。 RIP 协议支持的最大跳数为 15, 一般情况下网络中存在的路由器不会超 过这一最大跳数, 所以访问任一路由器的路由表就可以发现所有子网的路由信息。 这种方法 也是要求所有路由器都支持 RIP 协议并在每个路由器上正确配置 RIP 协议。 还有一些其它的常用算法不在此一一列举, 这些算法一般都有网络层拓扑的发现, 但缺 少链路层的拓扑发现,或是局限于某种路由协议,效率不高等缺点。下面提出一种新的基于 SNMP 的网络拓扑算法,来快速地发现完整的网络拓扑结构,包括网络层拓扑结构和链路层 拓扑结构。 本文采用一种新的基于 SNMP 的网络拓扑算法[37], 用于迅速发现完整的网络拓扑结构。 5.3.1 网络层拓扑结构发现 网络层拓扑结构采用 SNMP 协议访问路由器 MIB-II 中的路由表(IpRouteTable)、 地址解 析表(ARP 表)与地址表(IpAddressTable)来获取。 考虑到算法的通用性, 在获得网络中路由表信息时并不采用 RIP 和 OSPF 这类路由算法, 所以就要遍历网络中所有路由器。表 4.1 中 IpRouteNextHop 标识了与本路由器相连的路由 器或是有路由功能的节点,所以从管理站的网关路由器开始,可根据 IpRouteNextHop 逐步 向下发现网络中所有的路由器,IpRouteDest 和 IpRouteMask 可确定某一路由目的子网,并 由 ipRouteType 判断路由器间的连接关系。 数据结构的设计:

Class Router//表示网络中的路由器 { IpAddress Ip;//路由器某接口 IP 地址 MacAddress Mac;//路由器某接口 MAC 地址 址 Char*Name;//路由器名称 List InterfaceList;//路由器接口列表

Class Switch//表示网络中的交换机 { IpAddress Ip;//交换机的 IP 地址 MacAddress Mac;//交换机的 MAC 地 Char*Name;//交换机名称 List DeviceList//与交换机相连的 网络设备列表

Switch s;//所连接的交换机 Int Port;//所连接的交换机端口 } Class SubNet //表示子网 { IpAddress SubNetAddress;//子网 IP IpAddress SubNetMask;//子网掩码 List SwitchList;//子网交换机中的列表 List HostList;//子网中普通主机列表 List RouterList//子网中路由器列表 }

}

Class Host //表示网络中的主机 { IpAddress Ip; Mac Address Mac; Char* name; }

Class Connect//表示子网与路由器的连接 关系 Class Interface//表示路由器的接口 { { IpAddress ConnectRouter; IpAddress Ip; IpAddress ConnectSubNetIp; MacAddress Mac; IpAddress ConnectSubNetMask; } } 这里三层发现的目的就是找出网络网中存在的所有子网、 路由器、 子网与路由器之间的 连接关系和子网中的 IP 设备,所以可以定义存放 Router、Subnet、Interface、Connect 类型的列表 RouterList、SubnetList、InterfaceList、ConnectList,分别存储子网中所 有路由器、子网、路由器接口和子网与路由器之间的连接关系,对于子网中的所有 IP 设备 则存放在 SubnetList 中相应的子网对象中。 ]路由与子网的发现算法: Procedure FindRouter() 初始化 RouterList、SubnetList、InterfaceList、ConnectList 为空; gw=GetDefaultGateway() ;//得到管理站点默认网关 把该网关路由器添加到 RouteList 链表的末尾; for(RouteList 中的每一个路由器 CurrentRouter) { for(CurrentRouter 的地址表的每一项)//遍历路由器地址表 { 把 ipAdEntAddr 与 ipAdEntMask 所表示的接口添加到 InterfaceList 中; } for(CurrentRouter 的路由表的每一项)//遍历路由器的路由表 { if(ipRouteType 为 direct) { if(ipRouteMask 为 255.255.255.255)(1) { 把 IpRouteNextHop 所代表的路由器添加到 RouteList 尾部, 同时保证链表中的路由器 不重复;(2) 把当前路由器 CurrentRouter 和 IpRouteNextHop 代表的路由器之间的连接添加到链表 ConnectList 中; }

else { 把 ipRouteDest 和 ipRouteMask 所代表的子网添加到 SubnetList 中; 把该子网与当前路由器 CurrentRouter 的连接添加到 ConnectList 中; } } if(ipRouteType 为 indirect) { 把 IpRouteNextHop 所代表的路由器添加到 RouteList 尾部, 同时保证链表中的路由器 不重复; } } } End 说明:在(1)处,如果 ipRouteMask 为 255.255.255.255,那么该路由为到主机的路由。 也就是说,以该路由的 ipRouteNextHop 为地址的路由器和当前路由器通过一根电缆直接连 接。在(2)处判断当前路由器是否已经遍历过时,由于路由器存在多个接口,也就存在多个 IP,故遍历路由器时就要注意多 IP 问题,避免重复。仅仅靠存在于 MIB 库中的识别标志如 SYSTEMID 或 SYSLOCATION 等无法保证与先前遍历过的设备的区别。本算法通过访问路由器 的地址表获得路由器的所有接口,这样可以根据当前路由器的 IP 是否在已经遍历过的路由 器接口列表中来判断。 子网中 IP 设备发现算法: Procedure FindDevice() Begin for(RouterList 中的每一个路由器 CurrentRouter) { for(CurrentRouter 的地址解析表的每一 Device) //Device 的 IP 为 AtNetAddress,Mac 为 AtPhysAddress {for(SubNetList 中的每个子网 SubNet 对象) if(Device 属于子网 SubNet)break; if(Device 为交换机) 把 Device 加入到 SubNet 对象的 SwitchList 尾部,并保证 SwitchList 中的交换机 不重复; if(Device 为一般主机) 把 Device 加入到 SubNet 对象的 HostList 尾部, 并保证 HostList 中的主机不重复; if(Device 为路由器) 把 Device 加入到 SubNet 对象的 RouterList 尾部,并保证 RouterList 中的主机不 重复; } } End 说明:这里采用了访问每个路由器的地址解析表来查找网络中的 IP 设备,并把它分类存储 在相应的子网中。这比 ping 方法大大节省了时间,尤其网络中存在 A 类或 B 类子网时更为

明显。另外,这种方法还可以同时保存 IP 设备的 Mac 地址,为二层拓扑发现做准备。算法 中判断 Device 的类型时采用向 Device 发送 SNMP Get 报文来获取 MIB-II 中的 sysService 变量与 IpForwarding 变量。由于在 FindRouter()中已经发现了网络中的所有路由器,并且 把路由器的所有接口存在了 InterfaceList 中,所以我们可以根据 Device 的 IP 是否在 InterfaceList 中来判断 Device 是否是路由器,如果在 InterfaceList 中则是路由器,如 果 不 在 , 则 是 其 它 设 备 。 在 区 分 交 换 机 和 其 它 主 机 时 , 可 根 据 sysService 变 量 和 IpForwarding 变量。sysService 变量的值可以确定设备工作在第几层,IpForwarding 确定 设备是否具有转发功能, 如果 IpForwarding 不为 1 并且 sysServices 的第二位为 1, Device 则 为交换机,如果不能获取到 sysService 和 IpForwarding 变量或是 IpForwarding 和 sysService 是其它组合则是一般主机。 5.3.2 链路层拓扑结构发现 贝尔实验室的 Yuri Breitbart 和 Carnegie Mellon University 的 Bruce Lowekamp 等, 分别提出了各自的数据链路层发现算法[38-39],其中 Breitbart 提出的发现算法要求每台 交换机的转发数据库中的地址信息必须是完备的,因而该算法的实际应用存在一定的困难。 Lowekamp 则针对 Breitbart 算法进行了改进,但效率不高。 在网络层拓扑发现时得到了子网中交换机的集合 SwitchList,采用 SNMP 的 GetNext 原 语获取每个交换机 Bridge-MIB 中的地址转发表(Bridge-MIB 定义在 RFC-1493 中),进一步 可分析出它们之间的连接关系,以及子网中主机、路由器与交换机的连接关系。首先引用如 下定义。 定义 1Aij 为一个 MAC 地址集合, 元素均为交换机 Si 的地址转发表中通过端口 Sij 收到 的数据帧的源 MAC 地址(在此为了简单,Aij 中只包括交换机的 MAC 地址)。 定义 2 端口 Sij 的地址转发表是完整的,是指在给定子网中若交换机 Sk 发出的数据帧 可以通过端口 Sij 到达 Si,则 Sk 的 MAC 地址必然出现在 Aij 中。 定义 3 标志结点: 当算法运行的主机在要发现物理网络拓扑的子网中时, 将此主机命名 为标志结点, 若不在, 则将目标子网中能转发算法运行的主机发出的数据包的路由器结点定 为标志结点。 定义 4 上行端口指端口对应的地址转发表中出现标志结点 MAC 地址的端口。 定义 5 下行端口指端口对应的地址转发表中没有出现标志结点 MAC 地址的端口。 定义 6 若交换机端口 Sij 的 Aij 中未出现其他交换机 MAC 地址, 则称端口 Sij 为叶端口。 若交换机 Si 没有下行端口,则称 Si 为叶交换机。 交换机连接关系发现算法具体描述如下: (1)Ping 子网内所有交换机; (2)读取每台交换机地址转发表; (3)构造每台交换机的上行端口与下行端口,加入到待检测交换机列表; (4)从待检测交换机列表取出一交换机,判断是否为叶交换机,若不是,则继续取下一 节点。若是,则再遍历待检测交换机列表,得到与其相连的交换机,保存连接关系; (5)把此叶交换机从待检测交换机列表中删除,并把此叶交换机的 MAC 地址从所有待检 测交换机的地址转发表中删除; (6)判断待检测交换机列表是否只有一个结点, 是则结束, 不是则转到(4); 对于主机 (包 括路由器)与交换机的连接关系发现比较简单,主机的 MAC 地址若出现在交换机 Si 的叶端 口 Sij 的地址转发表中,则主机直接连接到此交换机的端口 Sij 上。

5.4 SWNMS 管理系统实现细节问题解决
5.4.1 数据库设计[40] 网络管理系统是以数据库为中心的, 管理站向代理采集大量的原始数据存入数据库, 并

且从数据库中读出相应的采集数据、 计算分析数据进行上层显示。 为了高效地存储和管理这 些数据,在数据库中建立相应的表。本系统中按照表存储数据的内容分为三类:一是固定信 息表,这类表中的数据基本不变或者不经常发生变化,主要是存储网络拓扑结构信息,配置 管理信息等;二是原始数据采集表,这类表中的数据随着时间推移不断增长,主要存储定时 采集的性能管理、故障管理对象信息;三是计算分析表,主要存储各种网络性能参数的值, 如接口带宽利用率、丢包率、输入输出错误率等,这些信息根据原始数据采集表的数据计算 得来,在原始数据表上建立触发器,插入原始数据表数据时,触发器计算当时各种性能参数 的结果并存入到计算分析统计表,用于上层显示。 在网络管理系统运行时, 一些较为固定的信息在采集第一次后可以直接从数据库相应的 固定信息表中读取,减少对代理的采集次数,减轻网络负担。原始数据采集表与计算分析表 的分离,使用触发器计算性能参数,这样的好处可以使管理站只采集原始数据,把计算任务 交给数据库服务器,缩短采集时间,实现数据采集与计算的分离,并且原始数据表的数据是 随时间的推移而增长,过一段时间后会变得非常的庞大,数据采集表与计算分析表分离后, 可以把原始数据表的数据定期删除, 而只保留计算分析表, 这样就把数据量较少的性能参数 历史数据保留更长的时间。 根据以上对相关 MIB 对象集和数据库作用的分析,我们对数据库表结构作了详细地设 计。本系统数据库中设计了大量的表,包括与每组 MIB 对象集对应的原始数据采集表、固定 信息表、 各种性能参数表和其它辅助的表。 下面列出几个具有代表性的表结构, 5.3 所示。 见

图 5.3 数据库表结构

5.4.2 网络管理的安全机制 为了增强网络管理的安全性,SNMPv2 在进行收发报文的时候,需要检查各自维护的 party 表来进行时钟同步,以及确定传输报文是否需要加密和消息认证等工作,在接收时还 要检查上下文表 context Table 和特权数据库 aclTable 来确定管理站对代理中的哪些资源 具有何种操作权限。因而 party 表,context Table 和 aclTable 是在管理过程中非常重要 的三个表格。Party 表结构如表 5.2 所示。 表 5.2 Party 表结构

当 SNMP 命令生成器在接收管理员发来的管理命令后,将查找数据库发现合法的参加者 和上下文,根据 party 表的 AuthProtocol 决定是否需要产生消息摘要,并按照目标 Agent 的私有协议将数据加密,最后组装成 SNMPv2 报文,经 BER 编码后发送给 Agent[41-42]。 5.4.3 多管理员问题的解决 对于一个分布式网络管理系统, 往往需要设置多个网络管理员, 在管理过程中必然会出 现两个以上的管理员同时在线, 并进行网络管理的情况。 多个管理员在对同一个管理对象进 行管理时,会存在管理命令相互冲突的情况,而且 SNMP 管理器可能分不清楚从 Agent 反馈 的 Response 信息是针对哪个管理程序发出的 Request 命令进行的响应的。 为此,我们要设计 MIB 的存取控制列表 acl,如表 5.3 所示。MIB 只允许特定的几个管 理员拥有 Set 权限, 其它的管理员则只是具备 Get 权限。 这样当 SNMP 接到一个 Set 命令时, 只需要检查该表就可以确定命令发出是否具备足够的权限。 为了防止主管理员不在线而造成 系统产生的 Trap 信息无法及时获得处理,在 acl 表中再设置一到两名候选管理员,当主管 理员不在线时,候选管理员可以被提升权限,具有 Set 权限。 表 5.3 存取控制列表 Agent 主管理员 第一候选管理员 第二候选管理员 在线管理员标识

对于 SNMP 对多管理员的响应问题,是在 SNMP 管理器连接的数据库中设计一个 online_manager 表, 该表中记载在线的每一台主机、 管理员标识和当前请求标识。 根据 SNMP 规范每一个 Get/Set PDU 中都含有请求标识字段,用来区分 Agent 返回的 Response 报文是 针 对 哪 一 次 Get/Set 命 令 的 回 答 。 因 此 SNMP 在 生 成 的 SNMP 报 文 时 可 将 其 记 入 online_manager 表中的适当位置,这样 SNMP 管理器就能够正确的将 Response 报文发送给 浏览器了。 5.4.4 代理设备设置

SNMP 代理是运行在可网管设备中的的一个管理进程,在网络管理软件运行前要对其进 行配置,使它能过响应网络管理站的信息请求,发送 Trap 消息,并进行权限限制与身份验 证。 通过 telnet 进行命令行设置,需要配置的内容我们通过配置一个 Cisco2600 路由器的 实例来具体描述: (1)配置团体名称和权限。 SNMP 服务需要至少一个团体名, 一般设备都有默认的团体名, public 为只读权限的团体名, private 为可读写权限的团体名。 这两个团体名被普遍地被使 用,每个人都会被猜到,为安全起见,配置团体名时尽量为不同权限使用不同的团体名,并 要为团体名建立强壮的口令,定期更改。配置命令如下: snmp-server community rdcommu RO 命令配置了一个 RO 权限的团体名 rdcommu, 它使此代理响应任何提交团体名为 rdcommu 的网管软件的读操作。 (2)配置访问控制列表 ACL。默认情况下,在仅配置了团体名和权限后,代理会接受来 自任何主机的 SNMP 数据包,这使团体名在被破译或泄漏后任何主机都可通过代理进行读写 操作,所以必须考虑安全性方面,设置访问控制列表,使 SNMP 代理只接受访问控制中主机 发出的 SNMP 数据包。配置如下: access-list 3 permit 192.168.0.0 0.0.0.255 snmp-server community rdcommu RW 3 第一个命令创建了一个编号为 3 的访问控制列表,允许来自网络 192.168.0.0255.255.255.0 的信息流量。 第二个命令设置代理只接受来自于网络 192.168.0.0 255.255.255.0 的 SNMP 数据包, 并且数据包中的 commnunity 是可读写权限的团体名 rdcommu。 (3)发送身份验证 Trap。身份验证是验证团体名或地址是否有效的过程。当 SNMP 代理 收到错误的团体名, 或者不是从可接受访问控制列表成员发出的请求, 那么代理将发送身份 验证 Trap 消息到 Trap 目标(管理站),指出身份验证失败,在默认情况下,该项是启动的。 本系统还对企业网络中的某些特殊主机进行管理和监控, 这些主机都是做为重要的服务 器,网络流量较大,负担较重。在对这些主机进行 SNMP 管理前要安装 SNMP 代理程序,这里 我们使用 Windows 本身的 SNMP 代理,选择安装控制面板—添加或删除程序—添加 Windows 组件—管理和监视工具,安装了这一组件后,主机就可以接受响应管理站点的 SNMP 数据包 了。

5.5 系统实现
5.5.1 管理员认证登录界面 管理员通过 Web 浏览器登录到 Web 服务器主页,系统显示管理员认证界面,如图 5.4 所示。输入正确的管理员登录名及密码后,即可通过 Web 认证进入网络管理系统。系统通过 登录认证界面完成对管理员访问权限的控制和网络访问安全机制的管理。

图 5.4 管理员认证登录界面 5.5.2 网络拓扑发现 拓扑的结构发现是一个非常复杂的过程, 尤其是二层拓扑的发现。 对于大型复杂的网络 整个拓扑结构的发现可能要花上几分钟或者更长的时间, 如果网络管理软件每次运行时都先 进行拓扑结构的发现势必浪费时间, 降低效率, 好在网络运行稳定阶段其拓扑结构一般不会 变化或者变化很小, 所以本系统在第一次拓扑结构发现后把其结构按照一定格式存入到数据 库中, 以后再次运行时拓扑结构可以直接从数据库中读出, 必要时再次重新发现拓扑结构更 新数据库。 我们将存储三层拓扑结构表以路由器 ID 和接口索引为主键,每条记录表示一个接口与 一网段或主机的连接;存储二层拓扑结构表以交换机的 IP 地址和端口索引为主键,每条纪 录表示交换机一端口与一 IP 设备的连接。网络层拓扑结构图如图 5.5 所示,数据链路层拓 扑结构如图 5.6 所示。

图 5.5 网络层拓扑结构图

图 5.6 数据链路层拓扑结构图 5.5.3 配置管理功能实现 对于配置管理,我们采用阻塞模式进行数据采集并将数据存入数据库相应的 表中, 在以后使用中可以直接从数据库中读出, 只在必要的时候再次从代理设备采集数据并 更新数据库, 对于一些有可写权限的对象我们可以进行 Set 操作, sysName, 如 sysLocation, sysContact 对象。管理界面如图 5.7 所示。

图 5.7 设备基本信息 5.5.4 性能管理功能实现 通常我们通过 SNMPAgent 代理直接采集到的数据一般不能直接反映网络的性能, 通过采 集数据计算各种性能参数才能反映网络的性能。根据本系统采集的接口组、IP 组、ICMP 组、 TCP 组、UDP 组数据可以计算出接口流量和各种协议流量。以接口组为例,我们给出几个主 要的性能参数计算公式及其意义。 输入速率=△ifInOctets*8/△T bps 输出速率=△ifOutOctets*8/△T bps 带宽利用率=(△ifInOctets+△ifOutOctets)*8/(△T*ifSpeed) 接口的输入输出速率和带宽利用率反映了网络信道的利用情况。 若值较低, 则说明网络 信道有空余,值较高则说明信道资源得到充分利用,若值高出正常值很多,则说明存在网络 瓶颈。 本系统把采集 MIB 中各功能组的数据存入数据库相应的原始数据采集表, 在这些原始数 据表上建立触发器, 每插入一条记录时, 触发器就根据本次插入的记录和上次插入的记录计 算相应的性能参数并存入到性能参数表。最后,将通过计算后的性能参数信息反映到 Web 浏览器中,如图 5.8 所示。

图 5.8 接口组输入输出速率曲线图 5.5.5 故障管理功能实现 故障原因分为三种:接口状态故障、超出阈值故障和陷阱 Trap 故障。故障管理的过程 一般分为三步: 发现网络故障、 分析故障原因、 自动排除故障或给管理员提供排除故障帮助。 本系统在发现故障时采用了两种方式: 主动轮询与自动告警。 主动轮询主要是发现接口状态 故障和超出阈值故障并通知管理员所有的故障源。 自动告警主要是代理进程在代理设备发生 特殊事件时向管理者发送 Trap 报文, 管理站上的接受 Trap 进程始终处于侦听状态, 等待报 文的到来,一旦接收到报文,就可以分析事件来源、事件类型等然后进行报警。本文的故障 管理模块如图 5.9 所示。 整个模块包括发现和接收故障消息(包括性能和配置故障、Trap 信息)和最后的处理建 议,同时转交给网络管理框架程序,使网络拓扑将做相应的变化。