Network Computingwww.networkcomputing.com

If the LANMeter is a bit too large for your taste and you can live without the SNMP capabilities, MicroTest's Compas is worth a look. In addition to providing basic IP ping and traceroute capabilities, Compas also can perform NT ping, IPX ping (also known as diagnostic responder) and query Novell NetWare servers for information, such as cache-hit ratio. Compas also has some of the best online help I've seen in a handheld tester.

If there's one network tester that exemplifies beauty in form and function, it's Fluke's OneTouch 10/100. For 10-Mbps and 100-Mbps Ethernet testing exclusively, OneTouch is by f ar the easiest to use of all the network testers I've come across to date. There's only one button on the entire unit--the on-off button. The rest of the functions are accessed via a touch-sensitive LCD panel, measuring about 2.5x4.5 inches. The OneTouch can perform IP ping, identify NetWare and Windows NT servers and provide basic cable testing. Although not as rich in functions as some of the other network testers, its ease of use and palm size make it a welcome addition to any network troubleshooting toolbox. Firmware upgrades (all of the units I've mentioned in this article are firmware upgradable, via Web site downloads) are on the way to add more functionality.

A caveat in purchasing a handheld tester is to make sure that it performs all of the cable tests you desire, so you don't end up having to carry both a network tester and a cable tester. For example, none of the heldheld testers has the cable-testing capabilities and precision of the Fluke DSP 200 0, a cable tester based on digital signal proc essing. Although you may not need all of the bells and whistles--such as pinpointing the exact location of NEXT on a cable--you will want to make sure you have the troubleshooting essentials such as open, short, length, split-pair and NEXT testing.

How Does Your Analyzer Measure Up? The network analyzer market is becoming very competitive, especially for the 32-bit Windows95 and NT platforms. Take Cinco Networks' NetXRay, for example, a popular analyzer in the less-than-$1,000 category that does a decent all-around job. However, many of the analyzers lack basic functions that are often overlooked in favor of more decodes, esoteric packet filtering, expert systems and other bells and whistles.

Naturally, every analyzer filters packets while capturing and displaying. Every analyzer also displays your basic packet summary, protocol details and raw packet data in hexadecimal and ASCII format. And every analyzer time-stamps the packet and shows you the addresses of who is sending and (should be) rec eiving that packet at both the data link and the network layer.

While this is adequate for basic packet exploring, a few essentials may be missing. For example, if you can set the analyzer to display two additional metrics--cumulative time and cumulative bytes in the summary display and by setting the appropriate filters--you can more easily perform throughput analysis for a given application such as a file transfer. Only a few high-end units, such as Network General Corp.'s Sniffer and Wandel and Golterman's Domino, have this capability. The low-end analyzers have no excuse not to include this basic, but essential, capability.

Another little essential that makes a big difference in troubleshooting is the ability to display a user-selectable layer of protocol in the summary. As an example, you may want to study the TCP transactions for an application using the Server Message Block (SMB) application-layer protocol to communicate with an NT server. By setting the s ummary to display only up to the TCP lay er, you can quickly see the ports in use, the TCP handshaking, the amount of TCP payload during data transfer and the TCP sequence and acknowledgment numbers. Although some analyzers have this capability, they may show only part of the critical information needed about the TCP layer. For example, the port numbers are present, but the sequence or acknowledgment numbers are not.

Are All Decodes Created Equal? With all the information available on packet formats, especially with TCP/IP and related protocols found in the various RFCs, you'd think analyzers would do a great job of decoding protocols. They don't.

The problem is that some of the protocols in widespread use--most notably the NetWare Core Protocol (NCP) and some Microsoft-specific protocols like MS-Browse and the Windows Internet Name Service (WINS)--are not well-documented at the packet level. So the protocol analyzer vendor must reverse-engineer the protocol (very time-consuming), pay a license fee to obtain the information (costs som e bucks), or copy the decodes from another vendor (you bet).