Network Computingwww.networkcomputing.com

Like 3Com's Traffix, TrafficMan's conversational line representations are color-coded by protocol. Networks appear as clouds that can be expanded to show the end nodes. One major difference between the 3Com and Bay products is that TrafficMan polls the probes directly and immediately starts loading the data, as opposed to the archiving approach that Traffix uses. While the dynamic approach makes it a better troubleshooting tool, we were a little frustrated by the fact that for even small networks, it took at least a few minutes to repaint the screen every time it updated the Sun Microsystems SPARC 10 we were running it on.

One valuable feature is that by right-clicking on a conversation line, you can automatically fire off a capture session with its capture/filter application. This is especially helpful for conversations whose black lines indicate an unidentifiable protocol. The decode immediately reveals the TCP port numbers in use. These protocols then can be added to the protocol directory using Bay's protocol extender application.

Another beneficial feature of this application is its ability to store numerous historical samples f or the duration of a session. Although we could not archive data, we could easily access the stored samples by clicking on arrow keys on the bottom of the screen.

The protocol extender application makes use of RMON2's "limited extensibility" feature, which provides a way to add protocols to the protocol directory. Bay's implementation of this particular feature is better than 3Com's in a number of ways: It provides entries for a list of protocols that can be changed all at once, as opposed to changing them one at a time; it also makes the changes on a group of probes as opposed to changing just one; and to compensate for the fact that this information is normally lost if the probe is powered down or reset, the protocol extender periodically reloads the changes into the probes. Unfortunately, we couldn't get this feature to work with any of the probes other than Bay's own probe.

Although we liked Bay's software and expect to see continued development of it, we had trouble keeping it running. We'll remai n skeptical about Bay's commitment to interoperability until it proves otherwise.

Stargazing Overall, we were very pleased that our testing proved that interoperability among RMON2 probes and management software is for real. Although some products fared better than others, it is clear that the four vendors that were willing to submit their products for our scrutiny are committed to standards as more than just a marketing tool. As we were completing our testing, Interworking Labs was poised to begin hosting another round of interoperability testing. This kind of joint effort presents a great opportunity for vendors to get together to better understand what they must do to make their products interoperable. And from all indications, when it comes to RMON2 product interoperability, the sky's the limit.

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

How We Tested Interoperability
We asked participating vendors to send us both a probe and management software. We then tested for interoperability by running the RMON2 applications included in each software product against the probes from each of the other vendors. We felt this would be the most relevant measurement of interoperability.

In some cases, an application used more than one RMON2 group, which made it difficult to isolate the exact group involved if the application failed. For this reason, we used an all-or-none approach. If the application worked, we gave the vendor credit for all the groups the application used. If it failed, the vendor received a "no" for all the groups involved in the application.

Using 3Com Corp.'s Traffix database, we stored the results of its interactions with the different probes to compare them closely. When we compared the results of the 3Com, Hewlett-Packard Co. and SolCom probes, we noticed that the Traffix application ran fine with the other probes and showed identical traffic patterns in each case. The HP and SolCom probes consistently produced about half the volume of data as the 3Com probe.

We also tested the interoperability of a feature called "protocol extension." This lets management software add a protocol that is not defined on a probe. The disadvantage is that the additions are lost if the probe is powered down. Both 3Com and Bay have implemented this feature in their software.

The groups and features that we tested for interoperability are abbreviated as follows: protocolDir, a table of all identifiable protocols, plus their descriptions; protocolDist, counters of all detected protocols;

addressMap, mapping of a Layer 3 address to corresponding MAC (Media Access Control) address; nlHost, total traffic based on network-layer address; nlMatrix, total traffic based on network-layer conversati on pairs, plus TopN capability; alHost, same as nlHost except that traffic broken down by protocols can be recognized by ProtocolDir; alMatrix, same as nlMatrix except that conversation traffic broken down by protocols can be recognized by ProtocolDir; probeConfig, provides remote capability for performing tasks that normally require a direct serial connection, such as resets, software updates, IP address changes and trap destinations; Protocol Ext., the Protocol Extension Feature that allows protocols to be added to the protocolDir.

HP was able to send us only a probe. Thus, we could not include HP in our review. We did, however, use the probe in interoperability testing against the other vendors' software.