How we did it

How we tested the various WAN monitoring tools.

Our test environment had three T-1 links, three frame relay links and a 384K bit/sec symmetric DSL link. The T-1 and frame relay links consisted of pairs of back-to-back DSU/CSUs and Cisco 3500 routers. The SDSL link consisted of Efficient Networks’ SpeedStream 5851 DSL modems and a Nokia D50e DSL access multiplexer. The three frame relay links had committed information rates of 56K, 256K and 384K bit/sec. The seven links, singly and in combination, simulated increasingly complex WAN pathways among four 100-MHz Fast Ethernet network segments.

Our client platforms include Windows 98/ME/NT/2000, Red Hat Linux 6.2 and Macintosh System 8. The relational databases on the network were Oracle 8i, Sybase Adaptive Server 11.5 and Microsoft SQL Server 2000. Windows NT/2000 and NetWare 5.1 shared files, while Internet Information Server, Netscape and Apache software served up Web pages. The network’s transport-layer protocols were TCP/IP, IPX/SPX, AppleTalk and SNA.

UpTime is a Windows-based monitoring tool the vendor delivers pre-installed on a Dell server. Observer is a Windows-based monitoring tool. N-Form is a modular, Windows-based, Java-enabled software tool for configuring and collecting data from IQ 710 DSU/CSUs. WiseWAN WANXplorer runs on Sun Solaris and Windows, and includes a bundled Sybase relational database. CyberGauge runs on Windows and, interestingly, Macintosh System 7 or later. EHealth, too is multi-platform, available for HP-UX, Solaris, Windows NT and Windows 2000.

Except for Visual UpTime, which was pre-installed on its own server, we ran each vendor’s software on a 4-way Compaq Proliant ML570 computer with 900-MHz Pentium III CPUs, 2G bytes of RAM, eight 18G-byte SCSI RAID drives and two NC3134 10/100 network adapters. The operating system platform was Windows 2000 Advanced Server. An Agilent Advisor protocol analyzer generated packets, and decoded and displayed network traffic.

We particularly wanted each WAN monitoring tool to alert us quickly and accurately to WAN link outages and problems. We looked for reports that helped us establish baselines, show available and unavailable devices, log device availability histories and identify trends. We tested for accurate, complete interpretation of network events and processing of SNMP management information bases emitted by network devices. Comprehensive traffic analysis, device discovery and multiple protocol support were important. We examined the products’ reports to determine compliance with the terms of an service-level agreement. The ability to interface with a network management system, such as OpenView, was a plus. We factored in the ease with which we could administer the product.

We used various techniques to cause WAN link error events in the lab, including powering down specific devices, generating high traffic loads and introducing electrical interference, via a wired shunt, at the V.35 interface of the DSU/CSUs.

Back to review: “WAN monitoring tools”