|Novel Approaches to the Monitoring of Computer Networks|
|Prev||Chapter 8. A Coalescence of Systems||Next|
As was noted in the introduction to this chapter, a number of the systems presented in the work were intended to solve specific problems at Rhodes University.
Conceptually, however, all of the systems that were developed as part of this project have application outside of the Rhodes environment. All of the problems that these programs have attempted to solve are not unique to the University, but rather represent a spectrum of the problems encountered by network administrators world-wide. For example, as has previously been mentioned, Pick 'n Pay, a large South African supermarket chain, suffers from the same problem as Hamilton Building at Rhodes — determining the logical location of machines on their network.
For this reason, in order to ensure that the applications developed as part of this project would be applicable to a wider audience, care was taken to ensure that they were as portable as possible.
In most instances, systems can be ported by simply altering a configuration file or configuration variables in the source code of the application. For example, the network growth tracking application presented in Chapter 5 simply has a variable that identifies Rhodes' network as a CIDR network block, in other words $network = 188.8.131.52/16. Changing this network block changes the network that is monitored. In fact, it is possible for the system to monitor networks that are not part of its local area network, although this application is not recommended.
A few of the applications are significantly more complicated to port to other networks; the RADSL monitoring system presented in Section 3.2 and the location monitoring application described in Chapter 6 fall into this category. This section aims to document the issues associated with porting these applications in order to facilitate an easier transfer to other networks. In cases where an application is not specifically mentioned, it can be assumed that porting it to another network is a straightforward task.
The XML-based abstraction layer described in Section 3.2 addressed many of the portability concerns associated with this application. It is not, however, completely devoid of issues as a result of this.
While this application makes no assumptions about how to communicate with the RADSL DSLAMs it is monitoring, it does make assumptions about how these devices are connected to the network. Specifically, the application has knowledge of the VLAN configuration on each device, as well as the fact that there are two manageable devices that each use a slightly different communications protocol.
It is possible to correct these assumptions by extending the XML DTD that was presented in Section 3.2. It was always intended that this would be done, but unfortunately making this correction would involve a significant number of alterations to the existing code base. As it is, the system has been functioning in its current format for just under two years, and for this reason it was felt that the changes were not justifiable.
The biggest problem with porting this application is obtaining the seed data that it requires in order to be able to accurately map a network at layer two. The system needs to be able to distinguish between hosts and switching infrastructure on a network, and in order to do this, it compares the MAC addresses obtained from the system's ARP table with a list of MAC addresses known to belong to switching infrastructure.
In places where the MAC address of every layer two networking device is known (such as those places that use DHCP to configure these devices), this information should be easy to obtain. Networks, however, tend to grow in a ad-hoc manner and, for this reason, information on the network infrastructure is often difficult to obtain.
Chapter 4 discussed an alternative approach to this problem that determined whether or not the device was part of the network infrastructure based on the organisationally unique identifier (OUI), the first three bytes of its MAC address. This approach was based on the assumption that, traditionally, network infrastructure uses different OUIs to network interface controllers, even when they shared a common manufacturer — for example, 3COM manufacture both network interface controllers and switches, but use, among others, the OUI 00:50:04 for NICs and the OUI 08:00:4E for switches. This approach, however, was never implemented.
Ironically, this is perhaps the most location-specific application that was developed. This is because it attempts to display the physical location of machines graphically by displaying their position on a building floor plan. In addition to high-resolution images of the building's floor plans, this system needs to be pre-configured with a large amount of information concerning the layout of the building before it can be used.
It is assumed throughout the combined location application discussed in Section 6.3 that the network point numbering scheme used in Hamilton Building is the de facto way of numbering ports — that is, all rooms in a building are assigned a number, and all ports within that room are assigned a unique number within that room. For example, 35/1 would be the first network point in room thirty-five. The application is not easily portable to any network where this numbering scheme does not hold true.
One of the pieces of information required during the pre-configuration phase of this application is a set of co-ordinates for every room within the area to be monitored. This is time-consuming to obtain, especially where the number of rooms is large. In addition, the system maintains a textual description of the function of each room, which needs to be entered along with the co-ordinates.
As was noted in Section 6.4, this system also has a number of shortfalls associated with it. Most notable of these is the problem of convincing people to participate in the process. This problem will need to be overcome in order to make this location monitoring system useful.
There are three issues relating to porting the intelligent reporting system: the importation of topology information, the configuration of areas of responsibility, and the definition of a reporting system.
Topology information is important to this system since it allows the system to determine where the fault is located. This layout information can either be entered by hand, or can be obtained from the network mapping systems described in Chapter 4.
Areas of responsibility are used by the reporting system to determine which people to notify in the event of a fault. This information is contained in a configuration file, and needs to be entered before the system can be used. In some instances where these areas of responsibility are not already clear cut, this may be problematic.
The definition of a reporting system is perhaps the most important part of the intelligent reporting application. Without this system, the application has no way of alerting administrators of faults and issues that arise. The reporting system currently in use is based on the GSM short message service, but this is not the only method that is available. Custom reporting modules can be written and integrated with the system, ensuring that almost any method of reporting can be accommodated.
Section 7.3.2 describes the method employed by the intelligent reporting system to test services. As was mentioned previously, only tests for the most common protocols and services have been implemented. The administrator of any network that runs services other than those already covered by the testing module may wish to develop further protocol routines for this module. This requires the writing of code to handle the specific requirements of the protocol.