Network Computingwww.networkcomputing.com

If we had not been able to adjust the thresholds, this application would have been far less useful: Some of its basic assumptions were way off. For example, using the default settings, an error rate of up to 3 percent was considered excellent, and error rates had to exceed 10 percent to be considered poor. However, our experience has shown that error rates above 1 percent can signal serious problems and incur noticeably slow user response time. The default settings also overestimated the impact of collisions, assigning a poor rating to anything over 15 percent. Fortunately, it was easy to make corrections, and once we did, our health report became useful. To maximize this system's benefit, plan on adjusting the thresholds as you observe the results.

All of Network Health's scheduled and ad hoc reports were automatically published on the Web. Unlike the reports from the Kaspia and DeskTalk products, however, none of Concord's reports made use of Java. We found that though they lacked some of the slickness that only Java can provide, they also didn't show the slow performance and instability that Java applications can inflict on a system.

We also liked the fact that we could effortlessly change the time periods, devices, interfaces and combinations of variables to include in the report. Errors could be shown as a rate value by choosing to divide them by the total frames. The errors by themselves are fairly meaningless without putting them into this context. We also were able choose from about a half-dozen different styles of graphical and tabular versions of the reports. The one thing that we did not like about the reporting application was that ad hoc reporting was so easy that you could quickly clutter the corresponding Web page. The way to curb this is to restrict the ability to run reports by the user login, which is required before any of Concord's reports can be accessed.

We were delighted that Network Health's Traffic Accountant application was able to archive RMON2 data from the three probes we tested it against, without relying on proprietary MIBs. The reports did a good job of a summarizing protocol usage as a whole and in a graph over time. The application also showed us IP conversations and the higher layer protocols associated with them.

DESKTALK SYSTEMS TREND

If you have your own ideas about what data you want to poll and how it should be reported, you'll appreciate DeskTalk's TREND. It comes with a full kit of powerful tools, including a polling engine that stores results in a Sybase database, a report builder, a graphing tool and a MIB walker; the Sybase engine is included in the purchase price, a plus for anyone who wants to query the data using standard SQL. If you're looking for quick results, however, this is not your best choice--unless you have someone at your disposal who possesses exceptional SNMP skills and has a lot of spare time.

Of the products tested, only TREND included a MIB walker. This tool lays out a MIB tree in a format that makes navigating it and searching for the variables you are interested in much easier than reading through the MIB document. We navigated with ease through MIBs that we had compiled merely by clicking on a branch of the MIB tree to expand or contract it. We also used string searches to locate certain variables. Another click provided a description of the variable. Once we highlighted a MIB variable, the ASN.1 Object Identifier string that was created could be used to do an ad hoc "get" or "set" of any of the devices in the polling database.

The MIB walker tool also let us change polling intervals for MIB variables. And it could compile proprietary MIBs. We were disappointed, however, that the two Cisco MIBs we attempted to compile could not be compiled correctly, even though we managed to compile them easily with the MIB walker that came with a copy of Technically Elite's MeterWare we happened to have on hand. DeskTrend pointed us to an FTP site for one of the MIBs that it had compiled. We also were able to use the MIB walker tool to launch another GUI-based tool that could control the polling rate for the MIB variables.

After sorting out the data we wanted to collect, we defined the reports. With the TRENDbuild application, we created reports on the statistics that had been processed in the database. We were especially impressed with the ease with which we could further refine the data for the report. For example, once we chose one or more statistics from the database, we could click on buttons that would automatically build complex expressions using mathematical operators and parentheses. Once this was done, we used an equally powerful graphics tool called TRENDgraph to build a customizable graph that could be printed or saved as a GIF file. These reports and graphs could be scheduled to run automatically or on a regular basis. Unfortunately, we could not get these reports automatically published using DeskTalk's Web-based reporting tool, TRENDweb. To do this, you have to write your own scripts to update the HTML to reference the GIF files, which can be saved to the directory of your choice--a procedure that is more a nuisance than a problem.