Network Computingwww.networkcomputing.com

We used the RMON2 report pack to pull information from our RMON2 probes. We were impressed that the application interoperated with all three probes; far less impressive was the data that was presented. For example, when we chose a protocol utilization report to run and then chose the probe to run it from, we were given a list of items from the protocol directory in a small window that could display only five entries at a time. To choose a protocol to include in the report, we had to click one item at a time to add it to the list. This was a tedious process that proved to be all too typical for most of the reports. It was especially frustrating that there were no shortcuts for choosing a group of entries simultaneously. If we chose another probe, we were forced to manually delete every entry we had previously added to the report, one at a time. None of the reports we ran could show us intervals of time less than one hour. In contrast, the Concord reports could show us five-minute intervals and the Kaspia product could show us 15-minute intervals.

Although we liked the development tools that came with TREND, we think DeskTalk has a long way to go before it can compete with the built-in reporting capabilities in Network Health and Network Audit. However, if you need to develop your own solutions, then the tools included TrendSNMP can save you a lot of time.

Kaspia Systems Network Audit Technology

We hit the ground running with Network Audit. It was easy to set up and started cranking out solid reports with minimum effort on our part. Not that we didn't encounter problems, however. Some of the data was not accurate, and the package generally seemed to have to strain to keep up. If you have a smaller network and you want quick results, this would be a good choice. We ran into some problems with the accuracy of the reporting data on our Cisco 7513, which had not been explained by the vendor as of press time. You may want to check on this before making your purchase decision.

Although we got Network Audit up and onto the task of discovering our network faster than the other products, it discovered more of our network than we had planned. While we configured one community string for the discovery process to use, it used the "public" community string as well. This won't be a problem if your goal is to discover as much of your network as possible. But you need to keep in mind that the cost of the software is tied to the total number of polling units. We found that Network Audit discovered a number of networks we did not support, along with a lot of workstations and printers that happened to be running SNMP that we didn't want to know about.

Network Audit publishes all of its reports on the Web and gave us the option of viewing them in Java or old-fashioned HTML formats. Although performance of the Java versions was a bit slow at times, it was faster than the TRENDweb product. The reports also were better designed. We enjoyed using Rolodex-like tabs to flip from one view to another, for instance, instead of scrolling up and down a long page of standard HTML. Nevertheless, much of the time the more sophisticated navigational capabilities did not justify the poor performance. We were glad we had the choice to revert to the non-Java views.

The time it took for Network Audit to generate the report data was the worst of all the products. Before any of the polled information could become available, it had to be crunched through a formatting process that took hours to run. Initially, we attempted to run reports every two hours, but the program fell way behind and was always running. We then started running it twice a day. By the time the process completed, the data was already a little old. For example, when it finished at 3:00 a.m., it only showed data through 8:00 p.m. the previous night. Although it's true that in many cases you may not need to see this data any sooner, we found the ability to see Network Health's data immediately after it was polled to be a great way to investigate response time problems that had just been reported by users. Kaspia suggested that a dual-processor 300-MHz platform with higher-performance disk drives would improve the overall performance of the product.

We found some of the reports very useful. The router reports, for example, showed us a graph of statistics, such as CPU utilization and errors at 15-minute peaks, superimposed over another graph of hourly averages. It also showed graphs of daily averages for one month and three months. This made it easy to see long-term trends. While this was not as sophisticated as Network Health's Health application, we liked seeing the big picture and making our own judgments.