|Novel Approaches to the Monitoring of Computer Networks|
|Prev||Chapter 2. Overview Of Network Monitoring||Next|
Rhodes University (referred to subsequently as "Rhodes") operates a network consisting of approximately 1400 computers connected together to form a campus-wide local area network (LAN). The network encompasses almost all of the Grahamstown campus and extends to the University's office in Johannesburg and the satellite campus in East London, as well as to various parts of Grahamstown through remote access technologies. The University backbone runs on 1Gb/s fibre, and the majority of machines access the network at 100Mb/s. Satellite offices are connected using Diginet leased lines, and access technologies such as ISDN dial-up, RADSL, analogue leased lines and dial-up are also employed to a limited extent.
For ease of management, the Rhodes LAN is divided up into about 32 subnets, each of which serves a different logical area of campus (and usually a different physical area too). For many years, these sub-divisions were sufficient to distinguish different areas of the network. In recent years, however, it has become necessary to further sub-divide these subnets to allow machines with different logical functions to be grouped together. In general these secondary divisions are not subnets in their own right, but are placed on CIDR boundaries to make it easy to refer to entire logical blocks of computers.
In general, networking is managed by the Information Technology Division, a support division falling under central management. In rare cases there are exceptions to this rule, most notably, the Department of Computer Science. This department manages its own, fairly extensive, network infrastructure in cooperation with the Information Technology Division.
There are three network monitoring approaches taken by Rhodes.
The first of these is the use of commercial network monitoring packages; namely CiscoWorks from Cisco and Optivity from Nortel Networks. Both these products are capable of monitoring large numbers of devices on the network, and this was the original intention. In practice it was found that these products did not provide a satisfactory solution to monitoring Rhodes' network, and currently each monitor a single device on the network — a Catalyst 5000 switch in the case of CiscoWorks and a Passport 8600 switch in the case of Optivity. These two devices form the core of Rhodes' network, and so are fundamental to the running of the network.
Network services, such as e-mail, the University web server, the central file servers, et cetera. are monitored by the Big Brother package mentioned earlier. This package is also used to monitor the South East Academic Libraries Service (SEALS) that is hosted at Rhodes. Big Brother is connected to a SMS notification service to provide rudimentary notification of problems as they occur. It is also used to keep historical information about the reachability of various machines, something that is important in terms of the service level agreement between SEALS and Rhodes.
TENET, the University's service provider, uses Tobias Oetiker's MRTG to monitor each of the downstream links they provide. They make these graphs available to the University and these are used to determine both network faults and historical performance. The graphs clearly indicate the Committed Information Rate (CIR) and allow the University to monitor and manage their bandwidth usage.
In addition to these, the University has made use of some custom-written network monitoring software in order to determine specific statistics, such as the amount of traffic on each of the various subnets. Due to time constraints, this software has not been well maintained and often does not reflect the current state of the network.
Several shortfalls in the current monitoring systems at Rhodes have been identified, and later chapters will attempt to address some of these.
To a large extent, access control for the University's proxy server and firewall is dependant on hosts having a valid reverse DNS entry. DNS records are maintained in a centralised database together with information about the host (its MAC address, asset number, owner, et cetera). Unfortunately, there is no easy way of telling when records in this database become stale. The result of this is that there are in excess of 5300 DNS entries at Rhodes corresponding to about 1400 actual hosts (or roughly 3.5 times as many). This makes bypassing DNS-based access control fairly trivial.
The University has no real way of determining which of these records are still in active use, or indeed how many actual machines there are on campus. There are no statistics about which subnets are most populated, or about the growth rate of the University network. All present information about these metrics is currently of the educated guess form.
Over the years, the University's network has grown in a largely ad-hoc fashion. As a result, there are no complete topology maps of the network. This is slowly being addressed, but it is being done manually — every time a section of the network is worked upon, its layout is documented. Attempts at automatically working out the topology of the network have failed, largely due to the multi-vendor problem discussed in Section 2.3.2.
In reality, however, this documentation is not always kept as up-to-date as it is supposed to be. When the network infrastructure in Hamilton Building (home of the Department of Computer Science) was put in, detailed records of all connections were made. These records, however, have been misplaced and currently there is no way of associating a physical network point in the building with a corresponding port on the local switch stack. This problem is not unique to the building, or indeed even to Rhodes. For example, Pick 'n Pay have the same problem in their offices in Rondebosch, Cape Town.