We also constantly found ourselves getting our hands crossed, after having started the server and then the graph, only to find that the server had failed and had to be restarted. It would restart, but would not allow the console to attach. According to technical support, the graph is rejected directly after the server is started to allow the server to contact all of the devices it manages on the network. Normally, this would not be a problem, but because we were constantly restarting a downed server, we bumped our head on this restriction as well.

SPECTRUM's biggest claim to fame is its Inductive Modeling Technology. This modeling includes the creation of devices and their ports, in a hierarchical relationship that is supposed to represent the way the network is cabled. Thresholds for each port allow for the bubbling up of status checks in a controlled manner, representing network connectivity and the importance of each node within the network. This is simplistic and powerful in design, but complex to implement. SPECTRUM comes with defaults, but we found that just getting the devices in our subnet set required separate edits, incurring a little more time consumption than we would have liked.

Likewise, events are set on a model-by-model basis. The setting of the alarm code involves listing hex numbers that relate to specific descriptions. The idea is that the event will have more meaning once it reaches the operator. The trouble with t hese codes is their lack of documentation. Perseverance is required to scroll through the long list of meaningless numbers to find an appropriate code.

A notable application included with SPECTRUM for NT is SpectroRX. SpectroRX suggests probable causes of problems, and logs actual fixes for future reference. This, along with the ability to assign operators, doesn't make it a help desk, but it is a start.

Trending Statistical collection of data is actually very good, once you master navigating the SPECTRUM map and applications. Icons can be doubled-clicked and application displays sent directly to a flexible report generator. Some of the predefined statistics include errors, collisions, CRCs (cyclic redundancy checks) and packet sizes. Protocol statistics and CPU utilization are among the add-on modules. We guessed the data sources for most of the statistics, but would have preferred to have on-screen documentation.

Sometimes we had trouble getting historical data collections to persist. If we stopped the graphed collection and then ran the report, we would have no data in the graph. If we ran the report while the graph was running, we were able to get report data. Cabletron indicated that the data should have been there in both scenarios, but up to the time we wrote this article, Cabletron had not managed to resolve the problem.

Bruce Boardman can be reached at bboardman@nwc.com. Randy Grimshaw is a network engineer for Syracuse University. He can be reached at rgrimsha@syr.edu.

How We Tested We ran our tests on the 6,000-plus nodes of Syracuse University's network, as well as on our Network Computing Lab network that consists of four sites connected via frame relay. We used identical Intel 200-MHz P6s with 128 MB of RAM for each platform. The participating vendors agreed this hardware configuration would easily handle our network setup. Each product allowed for at least the distribution of the client and the server, and in the case of Tivoli Systems' TME 10 NetView 5.0 and Computer Associates International's Unicenter TNG, the database as well. We ran all three on the same machine, again with the vendors' blessing, but we would recommend splitting the services. The major infrastructure pieces within the network consisted of a Cisco Systems 7500 with 85 active interfaces, which acts as a central router on the university network. Also on the network are Fast Ethernet LANs fed by Cisco Catalyst 5000s, departmental switches, and managed and unmanaged hubs from Cabletron Systems, Cisco and 3Com Corp. that are sprinkled throughout the two networks. We focused on MIB II capabilities, but all the products had some ability to look at enterprise and systems information. We did not install any proprietary agents to exercise that functionality, nor did we include that agent cost in the pricing information. We found that we could discover the nearly 7,000 nodes, but subsequent maintenance polls slowed the console interface to the point of being unusable. Also unusable were the resultant maps. Because of the size and complexity of the managed network, nodes were either off the screen or so small as to be unreadable. For this reason, we preferred the quick filtering and sorting functions. The event and statistical testing consisted of receiving actual statistics and traps from the network devices as they functioned for the university and Network Computing. We did not attempt, nor did we need artificial traffic, to exercise the platforms. Our litmus test was determining how well the platforms improved the signal-to-noise ratio when looking at a busy complex network.

For the Side Bar on Is Java The Future of Network Management? Kinnetics Enterprise Node Manager ATM Backbone Switches By Joel Conover Updated November 10, 1997