How we did it

By Barry Nance
Network World, 07/09/01

We ran each protocol analyzer software product on a Windows 98-based Dell OptiPlex G1 computer equipped with a 350-MHz Pentium II processor, 64 M bytes of RAM and a 4G-byte hard drive.

The machine's network adapter varied in the tests. For EtherPeek, WildPackets supplied a Farallon Communications PN996L-TX Fast Ethernet PCI bus network adapter. For Network Instruments' Observer, we installed an OBSPCI Fast Ethernet PCI bus network adapter the vendor sent us. Sniffer Portable, Agilent Advisor and Surveyor eavesdropped on the network via an Adaptec ANA-6911A Fast Ethernet PCI bus network adapter.

We connected each protocol analyzer to all our Fast Ethernet network's six segments, one segment at a time. Each segment consisted of a NetWare 5.0, Windows NT 4.0 or Windows 2000 file server, an Oracle 8i, Microsoft SQL Server or Sybase Adaptive Server database server, a Netscape or Microsoft Internet Information Web server and 10 Windows 98, Millennium Edition, NT, 2000 Professional, Macintosh System 8, Red Hat Linux 6.2 and OS/2 Warp 4.0 clients. The six-segment network also contained SNMP-manageable switches, Cisco 3500 routers, a Covad Communications symmetrical DSL Internet link, Frame Relay DSU/CSUs and SNMP-manageable hardware probes.

We confronted the protocol analyzers with six problem situations. First, we configured an Simple Mail Transfer Protocol mail server to reject relay requests and then sent the server e-mail from bogus, unauthenticated user IDs, an action which produced SMTP Error Code 550 responses. We attempted to log on to Microsoft and Novell file servers with invalid user ID and password credentials. Next, we powered off a file server while clients were accessing it. We then sent badly formed SQL*Net transactions to an Oracle server and badly formed Tabular Data Stream transactions to a Sybase server.

We caused physical layer Ethernet problems by using a cable deliberately wired to produce Near-End Cross Talk. We also asked the analyzers to help us find a misconfigured Cisco router.

In general, we looked at a product's ability to discover our network nodes; monitor those nodes for availability and performance; decode protocols; filter traffic based on network address, protocol type and other parameters; produce useful statistical summaries of network activity; help troubleshoot problems; and report on the current status of the network's devices and connections. To determine a protocol analyzer's accuracy, we flooded our network with a known number of diverse protocol messages and noted whether each product captured and decoded all the traffic.