参与网管软件开发也有一年多了，中间参与了部分需求分析工作，而且由于公司规模小，也曾跑过不少现场，做过实施工作，当然大部分时间还是系统设计和开发。

我们是在一个半成品的基础上做起来的，所以省去了很多系统架构设计的工作，好在这个架构还不错，维护起来还不是太复杂。它基于一个事件总线，各个模块基于总线收发事件进行通信，这些模块包括拓扑发现、性能管理、故障管理、配置管理、阈值管理等。

我们系统中没有像TMN标准中分的那么清楚，EMS、NMS...，而是混杂在一起，直接通过SNMP管理网元设备，主要支持标准的MIB库，如HOST-mib，MIB2(RFC2312)，bridge bid等，另外对于一些主流厂商，如思科、华为、H3C等，也支持其部分私有MIB库，通过这些私有MIB库，可以获取设备的诸如CPU、内存等信息，而这些信息没有标准MIB库，所以就只能一个个厂家去收集了，好在网上能搜到一些，其他的就只能在现场，通过一些工具将设备上支持的私有MIB信息抓回来仔细研究，不断补充和积累。

如果上面这些归EMS的管理工作，那么拓扑发现就应该归NMS的功能了。拓扑发现也是一个非常具有挑战性的工作，IEEE/ACM等都曾有专门的论文研究过这个课题，特别是二层拓扑发现，更是个难题。我们在实际中进行拓扑发现时碰到的问题主要有以下几个方面：

  • 不同厂家、不同型号设备对SNMP支持的情况不同，甚至有的根本就不支持
  • 二层设备的链接发现
  • 设备之间的一些复杂链接及配置，如双链路等
  • 在大规模网络环境下的拓扑发现的性能问题

我们系统从一开始定位就是面向中小型网络，所以性能问题不是很突出，但性能的提升总是无止境的，对于我们的客户总是希望网管一上线后立马就能又快又准的将他们的网络呈现在他们的眼前，客户的心情是容易理解的，黑灯瞎火摸索了这么久，上了套网管系统，当然希望能够马上见到庐山真面目了。然而在拓扑自动发现的背后是要收集非常多的数据，如路由表、MAC地址转发表等，还要进行关联分析，所以一旦遇到大规模网络环境，如果不是分布式的部署模式，拓扑发现的性能还是一个不小的挑战。