Network Computingwww.networkcomputing.com

We liked a number of other individual features in the Kaspia product, such as its graphical topology map and its frame relay application, which displayed utilization statistics based on the CIR (committed information rate) of a DLCI (Data Link Connection Identifier) as well as congestion. Given the problems mentioned, and our concerns about scalability and the product's lack of RMON2 support, however, we could not recommend Network Audit for anything but smaller networks.

Peter Morrissey is a network systems programmer at Syracuse University. He can be reached at ppmorris@syr.edu.

Tips To Proactive Network Management
Some of the biggest threats to good network performance are high utilization and high error rates. It's also possible for networking equipment, such as routers, to become overloaded and start dropping packets. At Syracuse University, Network Computing has been using a number of homegrown techniques to monitor trends on our networks. To monitor router performance, we've been writing Perl scripts that telnet into the routers and parse through the results of commands that let us calculate the utilization, packets transmitted, error rates and collisions for each interface. We also have started using Carnegie Mellon University's SNMP software in our scripts to gather RMON statistics from our Cabletron hubs and Cisco switches. The results are stored in flat files at five-minute intervals. Additional scripts compile summary reports that are e-mailed every morning. We also publish some of the information on the Web. Although this has worked reasonably well, it's not very flexible or scalable.

For these reasons, we were delighted at the ease with which we were able to access this information with the trending products that we tested. Following are some examples of how we made practical use of the information these products provided.

·Router Upgrade Before we started looking at these packages, we were concerned about the performance of the Cisco 7010 router that links our 45-Mbps Internet connection to our backbone router via Fast Ethernet. Because the 7010 router also supports the burden of access lists, and our statistics showed utilization steadily increasing, we thought it might be headed for a meltdown. Although we had not developed a way to track router CPU utilization and dropped packets, we had detected signs of problems through ad hoc queries while we were telneted into the router.

Once we had the trending products installed, we immediately got graphs depicting daily CPU utilization and dropped packets. Because Kaspia's Network Audit was the first one we had up and running, we used it to see what it would show us. Soon after it discovered our network, it began producing graphs of CPU utilization and dropped packets at hourly intervals, with another graph of 15-minute peaks superimposed on it. It also started showing us averages over one-month and three-month periods. Concord's Network Health gave us similar reports, showing us packets per second, CPU utilization, bytes per second and free memory available over five-minute intervals. The reports confirmed our earlier suspicions: We saw that CPU utilization was climbing to the 80 percent range and packets were getting dropped. And we used this information to justify a proposal we were writing, recommending purchasing a replacement router.

By the time that new router was purchased and installed, CPU utilization had risen dangerously high, into the 90 percent range. Following the arrival of the new router, CPU utilization stayed in the teens and no packets were dropped.

·The Quick Switch In another case, we were concerned about the increasing utilization of one of our subnets. We suspected that a malfunctioning hub might have been causing slow user response times. We used Concord's Network Health to run an RMON report that showed us that utilization was hitting the 60 percent to 70 percent range over five-minute intervals, during the time periods users had had difficulties. This meant it was likely that there were higher spikes that would have caused slow response times. As a stopgap measure we installed a 10-Mbps switch that segmented the network backbone. After "discovering" this device, Concord's trending product let us schedule an RMON report that showed utilization for all the ports on the switch on one graph. This graph informed us that utilization was rarely getting above 20 percent. This, along with the cessation of user complaints, indicated we had solved the problem.