As was noted in the introduction, this project set out to discover improved approaches to solving several common network management shortfalls, using the Rhodes University network as a test bed. This chapter seeks to summarise the work that has been done, and to present areas that are open to further research and development.
The field of network management was explored in the opening chapters of this work, with particular emphasis on the shortfalls of current monitoring techniques. One shortfall in particular, the monitoring of multi-vendor networks was examined in some detail.
A solution to the problem of multi-vendor networks was proposed; using an XML-based markup language it is possible to provide a layer of abstraction that removes the vendor-specific components of network monitoring protocols such as SNMP. This approach is used throughout the rest of the work to provide independence from the specific implementation of the test network.
Four common network monitoring shortfalls were identified, and each of these areas was examined in detail. In all cases, a solution to the problem was proposed, and the merits and shortfalls of these solutions were discussed. The four areas identified were: the problem of working out the topology of a network, both at layer two and layer three of the OSI reference model; the problem of tracking the growth of networks, and of accurately predicting future trends; the problem of locating specific hosts on a network, both at a logical and a physical level; and the problem of symptomatic fault reporting, and the need for this reporting to be more relevant.
Network maps were drawn at both layer two and layer three of the OSI model, using SNMP and traceroute(8) respectively to gather the necessary data. This data was fed into the GraphViz graphing engine and topological maps of various parts of Rhodes' network were produced. Limitations were identified in the approaches taken, particularly in the use of SNMP to gather information at layer two.
The growth of Rhodes' network was tracked over a period of thirteen months, and the resulting growth rates of various subnets at the University was calculated. It was noted that the monitoring period was too short to provide a completely accurate picture of the development of the Universities network, particularly on those subnets that had experienced sudden spurts of growth. Two other uses were found for the information that was gathered by the monitoring application. The first of these was a means of providing an estimate of the availability or "uptime" of various systems at Rhodes. The second, and perhaps more significant, use was in the clearing out of stale DNS entries from the University's master DNS database.
The problem of finding specific hosts on a network was examined at two different levels, the physical location of a host within a building and the logical positioning of a host in relation to other hosts on the network. The newly installed network in Hamilton building at Rhodes was used as an example of why these techniques are needed, and as a case study to test the proposed solution. The final result was a solution that used a web interface to provide a combined approach to both problems.
Many current network monitoring tools make use of simplistic, symptomatic methods of reporting faults they discover. The problems associated with these methods was discussed and an alternative was proposed. By using expert systems to perform some of the routine and tedious diagnosis tasks normally associated with tracing network faults, more accurate and useful fault reports can be generated. Particular attention was paid to keeping these reports concise. An approach to intelligently gathering data to produce these reports was also investigated. The wide variety of protocol implementations was presented as an obstacle to the traditional testing of services, and it was suggested that this may be an area where neural networks could be usefully employed.
Finally, all four of these applications were examined to provide an overview of how they interacted and depended on each other. Their position within the OSI network management model was examined to provide a clear indication of the roles that each application was intended to perform, and of how they related to existing network monitoring approaches. In addition, the problems associated with porting the developed applications to other networks was examined. Specific attention was paid to those applications that were not easy to port, and details were give of the possible snags and limitations that might be encountered.