Network Computingwww.networkcomputing.com

	Issue TOC Print full article Print this page Download as PDF E-Mail this URL Discuss this article Flame the author     In this article Introduction Busy Windows Executive Summary How We Tested Where Does Protocol Modeler Fit? Hailstorm Protocol Modeler Looks To Find Its Niche Report Card

Hailstorm Protocol Modeler's requirements are pretty basic: a beefy, but not killer, Windows machine with at least one NIC. We recommend using standard, well-supported hardware (including that NIC) in case you run into problems, as we did. This lets you rule out hardware problems quickly.

You'll need to create a segmented test network, if you don't already have one, before you let Protocol Modeler hurl packets. Don't even think about deploying this product on a production network. Critical applications crash at the mere mention of the program being connected to their segments. Not only are most of Protocol Modeler's tests designed to produce fatal run-time faults in OSs, network devices and applications, but sometimes a test will do something slightly different from what the operator intended.

Fortunately, at our Neohapsis labs we have more test networks than production networks. We plugged the Protocol Modeler host (housed on a Compaq 1850R Pentium III machine) into a Cisco Systems 2900 series switch. Several Linux and Microsoft Windows 2000 hosts, all running various services including POP, SMTP, DNS and HTTP, provided target applications. One advantage of running on a full-featured managed switch is the option of configuring a span port to monitor traffic. The other option is to connect Protocol Modeler to a hub.

Either way, you'll want to hook up your favorite sniffer--we used Ethereal and its CLI-based sibling, Tethereal--for out-of-band monitoring of Protocol Modeler. The run-time logging is insufficient not only for monitoring progress but also for gaining an understanding of the transactions being run.