Network Computingwww.networkcomputing.com

  Most people who build and manage networks love the concept of standards and with good reason--standards give them choices and force vendors to differentiate themselves on factors like service, price and execution, rather than on the coercion of proprietary solutions. The Internet was based on this concept, and the IETF was formed to oversee the development of standards for it. The group also influences the standards for any network that runs TCP/IP.

To view the Report card. In the realm of network management, RMON stands ou t as one of the more successful standards. The original document, finalized as RFC 1757 in February 1995, defines a method for gathering network data from specialized devices, called probes, and other networking gear that support the RMON MIB. You will be hard-pressed to find a hub or switch that doesn't implement at least some RMON services.

But however appealing their concept is, standards--including RMON--often force you to trade functionality for interoperability. RMON's biggest drawback is that it does not provide much-needed information on the network layer or any of the layers above. In typical fashion, vendors have used this shortcoming as an opportunity to differentiate their products. In fact, the last time we looked at RMON products, Armon Networking (now owned by Bay Networks), Axon Networks (now owned by 3Com Corp.) and Hewlett-Packard Co. all offered extensions to RMON that made their products stand out from standard RMON solutions (see "RMON: Unfinished Business. Get the Picture?"). The one obvious disadvantage was that these solutions bound users to the vendors supplying them.

The IETF rose to the challenge: In January 1997, it finalized RFC 2021, or RMON2, which extends the original RMON standard with 10 new groups (see "Inside RMON2" on page 76). These groups define how to gather data from the network layer and beyond--and it didn't take the IETF an eon to pull it off.

Last June, we gave RMON probe and software vendors the opportunity to show us what this new RMON2 standard was all about. We thought vendors would have products ready by then--the standard had been out for six months and a draft was in existence for much longer. We also assumed that because most of the vendors had participated in the interoperability testing sponsored by Interworking Labs in October 1996 that they would be raring to go. It turned out that we were a bit premature in our invitation, so we extended our testing period through the fall, letting most of the major vendors come to the table with something more th an marketing glossies and white papers trumpeting the benefits of the RMON2 standard.

Bay, SolCom Systems, Technically Elite and 3Com all participated in our tests. We were especially impressed with 3Com's product, which clearly demonstrated that there does not have to be a serious trade-off between standards and functionality. It earns our Editor's Choice award. 3Com's Transcend Traffix Manager software was in the same league as the better products we evaluated in our last review, yet its sophisticated network management tools were completely standards-based. We also admired its report scheduling and automatic Web publishing capabilities.

Technically Elite's MeterWare for Windows 6.0 and SolCom's LANmaster RMON Utilities for Windows were a little more utilitarian. Of the two, MeterWare was stabler and had more features. It merits an Honorable Mention. Bay's was the only other product capable of graphical conversation mapping. And even though it did a better job of providing real-time data than Traffix, its performance dragged even on a small test network.