Network Computingwww.networkcomputing.com

The products also had trouble identifying the devices themselves, chiefly because of the way we had named them. In most cases, the products sought to use the devices' DNS names to identify the network equipment that it queried for the SNMP data. Our problem was that the DNS names we had assigned to our networking equipment corresponded well to our equipment database but were not very descriptive. For example, we identified all our switches and hubs by a generic name, such as "hubxxx." Had we given it a bit more forethought, we could have included a few more characters when we assigned our DNS names to describe the network and perhaps the type of equipment and location. For example, a hub on subnet 40 in Brewster Hall could have been named "hub384_40_BREW," instead of simply hub384.

So Much Data, So Little Time Keep in mind that a lot of data is available in networks like ours, and processing that data is not a trivial task for any product. Our network has hundreds of routers, switches and hubs--each with uniquely identifiable interfaces--that are polled for numerous statistics from various MIB variables every five to 15 minutes. In some cases, the data must be turned into deltas and percentages. Ultimately, it all gets stored in a database to be accessed for reports. All of this, plus the reporting and analysis functions, requires lots of CPU cycles and disk I/O. Network Health, running on an NT machine with dual 200-MHz processors, seemed to handle this load without any great difficulty. TREND, running on a 166-MHz Sun Microsystems Ultra 1, also seemed to keep up. Kaspia's Network Audit, however, running on a platform almost identical to Concord's, struggled under the load, taking many hours to process the data before we could access it. We found, for example, that we could immediately report on data after every five-minute poll with Concord's Network Health, whereas it took a minimum of seven hours before we could report on data generated by Network Audit. The availability of DeskTalk's data fell somewhere in between, becoming accessible a few hours after polling.

We let the products poll our network of Cabletron hubs and Cisco switches and routers for a couple of months and then evaluated the reports to see what they told us about our network. We also took advantage of the fact that three RMON2 probes from Hewlett-Packard Co., Technically Elite and 3Com Corp. were still in Network Computing's Real-World Lab® at Syracuse University following our RMON2 review (see "RMON2: To the Network Layer and Beyond!," at www.NetworkComputing.com/903/903f1.html). We incorporated them into our test plan and were able to pull data from all the probes with the Concord and DeskTalk products. Kaspia's product does not support RMON2.

Concord Communications Network Health

When you're trying to anticipate problems on a large network, you want as much data as possible at your disposal so you don't miss a thing. On the other hand, too much data can be overwhelming. After we tweaked their thresholds, Network Health's health reports successfully highlighted the situations we needed to be concerned about. This let us concentrate on real problems. For more detail, and to monitor specific devices more closely, we ran Concord's more conventional Trend, At a Glance and Traffic Accountant reports. Although the customization tools were not nearly as advanced as those in DeskTalk's product, the reports we scheduled and ran using Concord's Report scheduling tool on Concord's Console and the ad hoc reports from Concord's Web interface provided at least 90 percent of the data we were looking for.

However, before we could get any reports, we had to run a discovery process that finds all the SNMP-manageable devices on the network and figures out what kind of data can be pulled from them. Concord's discovery application was the easiest to use of all the products tested. It let us specify the ranges of IP addresses we wanted to discover with a tremendous amount of precision and flexibility. It also did the best job of providing status on the console on the progress of the discovery process. In addition, it made it very easy to add devices or groups of devices after the initial discovery. Its one weakness was that we could not specify more than one community string per discovery session. Kaspia and DeskTalk both let us use multiple community strings.

Once all devices were polled, Concord also did a great job of managing the polling configuration. For example, we could effortlessly list classes of polled devices--such as routers, WAN, LAN and frame relay--and search for devices by name. It also was very simple to change the labels of devices, as well the MIBs that would be used for polling.