FEATURES Global Network Management by Bruce Boardman Try out our Interactive Report Card ®! For more information about our Interactive Report Card ®, click here .

In the network showroom, the sleek new look of colorful ico ns and the explosion of 3-D gr aphics could be enough to seduce you to ink the dotted line. But get a grip! Acquiring a network management platform is not going to put you in the driver's seat. You'll get an engine, some seats, keys and a map. How and if you get to your destination, or whether you just end up cruisin', is completely up to you.

And this is as it should be. We have open networks and the problems that come with them; no two networks are alike and there are no easy answers. But network management vendors are now selling foundations that may help you build the tools to better manage your network.

These past two months, we tested the foundations laid by Cabletron's Spectrum 4.0, HP's OpenView Network Node Manager (NNM), Tivioli Systems/IBM. Corp. TME 10 NetView and SunSoft's D omain Manager. While it is one thing to drive products like these over fairly straightforward lab networks, we distributed the platforms in three of our lab sites monitoring nodes across our coast-to-coast frame rel ay network (a network that includ ed approximately 20 routers, more than 100 subnets and more than 6,000 nodes).

This was a difficult test to call because all of the products are an excellent foundation for some network bias. But Cabletron's Spectrum and HP OpenView NNM proved to be the best. Both have a fine distributed strategy and have added tools and functions to their base platforms. HP is still the leader in open systems support, while Spectrum's offering is the most intelligent. This is not to say the products from IBM and SunSoft failed. Both have workable, distributed strategies, and IBM has some useful tools where the most benefit is derived from a commitment to its hardware and software strategy.

Cabletron Spectrum 4.0

Cabletron not only has the most intelligent network management platform, it interoperates on both Unix and Windows NT 3.51 with the same functionality and look and feel, making its distributed paradigm very flexible and almost complete. Spectrum's distribu ted architecture is completely client /server, relying on applications to focus reporting data, and design to focus operations. The only Achilles tendon was the dedication of an additional server at each location to achieve a hot-swappable, redundant management database.

Ping Get ARP! Topology discovery is a specious art. Although it's not the most important weapon in the arsenal of a network management platform, it can save time if done right or waste it if done wrong. In Spectrum's case, it is even more important that the job is done right because the functional relationships as well as the connectivity relationships are mapped. Devices are mapped to the port level, and the intelligence of Spectrum's Inductive Modeling applies the information about the type of device to the connection between d evices.

Topology discovery is a specious art because no matter how many times it is run, and regardless of how static a particular network is, the results will be different regardless of the platfor m. We ran Spectrum's autodiscovery a numb er of times and each one produced relatively the same map with less than 5 percent of the network nodes unattached, or incorrectly placed.

Much of what makes autodiscovery successful is the procedure used to employ it. While it would be nice to click a button and just let it go, none of the products produces a very accurate representation of the network with this approach. Spectrum has one of the best tools for autodiscovery, including the ability to discover an IP address range, create a hierarchical flat node map and include multiple SNMP community strings, router-only discovery, ARP cache discovery and ICMP discovery. We liked the obviousness of these options and the scrolling feedback that the discovery status window gave us.

After we discovered the main routers on the network, we defined the IP address ranges that we were planning to manage and let the process go. On the networks we were managing this process took about 36 hours. Being able to see that th e process was cranking away prevented us fro m shutting down the process early in the belief that it was doing nothing. This may not sound like a big deal, but in contrast, we often let SunSoft's Domain Manager go for days only to find out that it was doing nothing of any use, and other times we shut it down when it was still finding nodes.

Another feature that is useful when discovering large networks is the ability to start over with a clean database. All the products do this, but Spectrum makes it easy by including a menu option that performs the reset.

A tendency with autodiscovery is to make the subnet that the management station is on the center of the universe. All the products have post-discovery cut-and-paste options to shift the center to the backbone, central router or whatever. What Spectrum did nicely here was to create the central collapsed backbone of Syracuse University as one center, and Network Computing's frame relay as another, with the network management station spanning both in a visual way that made that relationship obviou s.

Don't Eat the Paste, Ralph All these products have cut-and-paste functions for tying up loose ends that autodiscovery can create. This manual process requires you to figure out where in the map a node belongs and how its placement will logically represent its function in the network.

When we pasted an icon on the map and Spectrum understood its connection to the network, it would automatically connect itself to the correct adjacent node. It was especially nice that when we guessed wrong about the exact relationship of a node in the network, Spectrum added the correct connection, representing its actual port connections to adjacent nodes. Other products connect nodes to subnets because the node is part of the subnet. Spectrum tries to resolve the ports at each end of the connection. The obvious benefit of this approach when it works (and for the majority of the connections it did) is that if a router goes down, Spectrum knows that events from all subsequent nodes spring from the router going down, and can automatically suppress them.

All the products have network topology perspectives, but they also add location and groupings. You can cut and paste graphical location maps, upon which icons representing London, Tokyo and New York can be placed, for instance. In this situation, Spectrum creates new icons that represent London, Tokyo and New York, and these are connected to the networks they represent. These connected icons display the status of their underlying network hierarchy.

This can be confusing at first. The other products represent status within their icons by blinking and changing colors based on filters and thresholds of the underlying devices. Spectrum extends this by letting you assign importance to the thresholds. We assigned such weighting to a router icon buried several layers down in the network hierarchy, and that router's failures passed directly to the highest level view. The logic is initialized with defaults, that, li ke autodiscovery, work in the majority of cases, but l eave many event situations uncovered, causing a Christmas lights-like effect on higher layers of the network. This is important to keep in mind because this is how the nice graphical map we all see at trade shows misleads us in believing that it is somehow magically managing the network.

Moreover, the details of what those thresholds should be for icon status logic, and more important for SNMP thresholds, is not in any way addressed by the base functionality of these products. It is no small chore to set up the thresholds so that they accurately provide blinks, beeps and alarms for the particulars of your network.

Spectrum's grouping view is an organizational one that basically allows the creation of an organizational chart and the connection of icon models to actual nodes or networks. It is a completely manual process, like the location view, and will require dedicated resources as well as organizational procedural integration to maintain accurac y. It's an elaborate, even nice idea, but not trivial.

Can't Get There From Here! Spectrum is confusing at first look because a single icon (actually a database model) may be only one of many icons that represent a particular node. So when we audited the autodiscovery, we found multiple instances of nodes and felt as if we were going around in a circle. Once we understood that icons could represent a function or relationship, the layout made sense.

An addition to Spectrum's navigational tools is the network topology map that shows the entire network in a single view. Interacting with this map view is impractical with the tiny icons, but it is useful in creating an orientation of the overall network. By default, the other products tend to place the major nodes of the network at the same layer, making this orientation obvious from t he start. Spectrum's default hierarchical, multiple icon-to-node approach is easier to get lost in.

Tool Time One of Spectrum's best features is compl ete consistency and improved tool usability across Unix and Wi ndows NT 3.51. Some users have complained that the NT implementation relies on a Unix process that lets Cabletron avoid completely rewriting its code to be a native NT application. While this is true, and a beefy P6 200-MHz processor with 200 MB of RAM is needed to drive both the Spectro-

SERVER and SpectroGRAPH client pieces, we saw no difference between running on NT or Unix.

WatchManager is Spectrum's application for monitoring events on the network. The display is similar to a spreadsheet, with each event designated a row. Upon highlighting the row, the icon representing a problem is displayed on the sheet with all of its attached functions, including the ability to drill into its topology, object definition or performance. Another area of the screen displayed a tabbed description of the problem's cause, a suggested corrective action, assigned troubleshooter and current status. It's not a full-fledged helpdesk, or workflow application, but we set up a couple of troubleshooters and notified them auto matically (via e-mail) of their assignments and problems to fix.

We would have liked some automatic acknowledged receipt and status feedback via e-mail, but we had to do this manually from the SpectroGRAPH console. Can you say third party?

Besides the integrated relational logic, Spectrum's Watch editor let us set thresholds and perform conditional processing on MIB and Spectrum instances. This isn't specific to Spectrum, but we liked Spectrum's ability to autofill edit fields, and its scrolling lists of possible choices (of course, real networkers know the ANS1 notation by heart).

Spectrum's reporting has improved. Predefined reports that can be modified for alarm, event, inventory, node relation, statistics and up/down status let us select a group of nodes in multiple server domains an d spit out a report. Again any variable can be reported on and scheduled to run. The choices are overwhelming, but nobody said this was going to be easy (OK, maybe a sales rep).

Together Apart Together Sp ectrum's distributed architecture is a complete disengagement of the display/client (SpectroGRAPH) function from the server/polling/database (SpectroSERVER) function; any client can attach to any server, regardless of operating system. The clients can attach directly to each server to view that server's network segment, or the client map can have an icon that represents the servers it's authorized to manage.

The realms that a server manages can be distinct from, or overlap, other servers, either in terms of the actual nodes/segments managed or the types of devices or map views (organizational, location). Carrying this to its logical end, two servers could completely mirror each others' managed domains, thus providing a complete measure of redundancy. Of course, in situations where the servers are separated by WAN links this is not a good idea. But even on LAN segments this complete overlap defeats the purpose of segregating management activity and responsibility. This is not to say that servers can't be ba cked up, but as they are distributed on the network, all the attendant problems of network backup apply. A further function allows a server to have a hot backup spare, but relegates the backup server to the single task of mirroring the first--a function HP's NNM does without dedicating a machine.

Since Spectrum has a completely distributed paradigm, much has been made about the lack of a central online repository for all network topology. There may be instances where this centrality makes sense. But in general, as networks become larger, organizations are going to be segmented for business efficiencies into divisions that operate independently, so the benefit of having a single NOC that has all the network data and manages all of the nodes for a central location is generally not a reality.

While operational centralization is not needed, a focus for planning and budgeting is. To this end, Spectrum's Distributed Data Manager does a good job of querying the multiple databases and combining the desired res ults into a focused look. This applies to reports as well as data queries.

HP OpenView Network Node Manager

Always among the elite, OpenView Network Node Manager (NNM) is the choice for those who want open systems with comprehensive support from third parties that offer the most advanced network management add-on applications. Thus, NNM has become the standard network management platform, and with the addition of its distributed architecture, it will continue to be a leading platform.

Soon There Were Many We started up NNM, defined a router and let it discover everything in site, just to see how it compared. This was a mistake. Our map started with a fairly accurate display of the network, and it was kind of exciting watching it grow as we let it discover more and more subnets (we know, we need to get a life). But soon we had nodes small enough to require a microscope, and the map morphed into ev er-more-torturous shapes, leaving our once-happy map completely unusable.

We s ummoned the wise men, who told us to read the book of wisdom (the manual). It outlined a more controlled approach that entailed choosing a central, or seed router to become the center of our kingdom, and discovering subnets attached to that and the other routers on the network--but only after we had planned and created the submaps that represented the network hierarchy we had in mind. The process was not difficult but did require more manual choices than Spectrum did.

We autodiscovered the network many times and, as we expected, received differing results for each. An interesting result of the discoveries was that even with a specified seed router, the center of the network was based on the placement of NNM within the network topology. Another anomaly of the discovery process was that the backbone of the n etwork wasn't entirely displayed on the same map on the hierarchy.

Manually editing the map is really not so bad, b ut because the topology is flatter by default, we had to spend more time creating Chi ld Maps (NNM term for submaps), and manually cutting and pasting icons to represent the map. It took a day to get the main routers and subnets into place.

Even with the layout of the map done, some submaps contained a large number of nodes. We could have continued to cut and paste, but instead relied on the "panner," a magnifying function that, like Spectrum's network view, showed us an entire view of the map in a little window. We could open a selected area to display in a larger representation on the main map, and this worked pretty well with our edited version of the discovered map; when we used it on the entire map as discovered, however, it was pretty slow in redrawing the screen.

MIBing It NNM has a powerful set of MIB applications, a MIB browser and a MIB application builder. The browsers worked as expecte d, without the ANS1 notation, which was replaced with MIB group and instance names. Performing SETS and GETS was easy. The MIB application builder let us set up specific MIB instance browsing for specific devices. The setup procedure required knowledge of how to apply the MIB instance, but we found it easy to set up an application that monitored and graphed the packets in and out of the main Cisco routers on the network, for instance. It was convenient to be able to launch that application again with a click.

The Event Categories Window is a new application that is launched by default with this version of NNM--it sits on the desktop listing the possible event categories. The most severe event in every category is represented by a user-definable color button for each event category. By clicking on the corresponding event cate gory button, the corresponding events were displayed. Defining events were outside the scope of the graphical interface. Be prepared to read the manuals and develop some in-house exper tise.

NNM manager was the only platform to provide an alarm setting that defined the length of time that an event must exist before it is valid; therefore, intermittent peaks in network utilization do not set off alarms. Similarly smart is NNM's ability to set a value that indicates a low-water mark. It tells an event not to generate additional events for the threshold being exceeded until the value being tested has dropped below the low mark value.

NNM lets you view traps from HP 9000 and SunSparc machines running SNMP agent software. We set up a trap on CPU utilization on our lab Sparc machines, for example.

A graphing application, called, strangely enough, Grapher, displays collected data in either real-time or historically. Historical data also can be output to an ASCII file. One of the nice features of the Grapher is that it displays historical data and real-time data in the same graph. While graphs ca n be printed and the NNM manual steps you through the command line arguments, reporting is an a rea left to database queries and third-party reporting software. Can you say open systems?

Over There The distributed approach that NNM has taken is hierarchical, as compared with Spectrum's client/server approach. By forwarding database information among servers and using filters, some or all of a network's database can reside in distributed locations on the network.

The filters are inclusive for the objects that are to be passed upstream to a management station. Only a single filter file per collection station, or distributed server, can be set, and it serves all the upstream management stations subscribing to that distributed server. HP does have an impressive list of filters, including filtering for the type of equipment, MAC address, IP range, particular network, vendor, topology, product name or type, and so on.

Sadly, the filters are created by setting up a text file that is fed as a pa rameter into the discovery and monitoring executables. Each filter must be created separately; you c annot combine filters, and you have to create and apply each at startup, rather than dynamically--a real hassle. While it is likely that you won't apply filters willy-nilly, it is almost certain that some fine-tuning after every network upgrade will require a filter change. Having the ability to make changes on the fly without taking the network management system down would be nice. HP does provide for filter syntax checking, testing the filter against a database and shell script editing.

This filtering mechanism lets NNM provide completely hot-swappable and redundant servers. If one server goes down, just attach to the other. A restriction to the hierarchy approach is the support of only two layers of topology filtering. In a three-tier network hierarchy, both the middle- and bottom-layer servers must communicate directly with the top layer so that the top layer server has all the topology information.

Tivoli/IBM TME 10 NetView

Originating from HP's NNM, NetView shares much of HP's wide third-party support. For managing networks that mix common third-party and IBM hardware, it is the best choice. And, none of the other products we tested came with such IBM stalwarts as APPN or DLSW support, making it a must for networks that deploy those strategies. NetView has had an open architecture for quite some time, but while it was the easiest to use, it was also the least flexible distributed architecture of the four products we tested.

Double Take When NetView first comes up it doesn't look any thing like NNM, but right away it had us discovering the network just like NNM. Node discovery is on by default, so once we defined a seed router, the network map began to appear, just like NNM. For some reason, we didn't find as much of the network on our first go-round as we did with NNM, but that was easily remedied by clearing the database and starting again. We soon (overnight) had an accurate picture of the main Cisco routers, correctly identified, and our lab frame relay backbone.

As we did with NNM, we fixed the main network map so that it wouldn't autodiscover any more and set about cutting and pasting a hierarchy upon which the rest of the network could reside. We added network by network and added layers to the maps as needed, with the entire process of adding main routers, subnets and servers taking a good day--at the end of which we certainly were not managing every node on the network, but did have a fairly accurate picture of what was out there.

Ready, Set, Navigate Compared with the other products, NetView's interface is easy to get started. It includes a toolbar, navigation view, default events screen and topology map. It's no Windows application though; while navigation, alarm and MIB retrieval are straightforward enough, we found some of the applications very powerful.

For instance, the Alarm Correlation application uses cheesy icons like a mouset rap (don't worry, I won't milk this metaphor) that you drag into a work area, define and combine into a logic st ream to perform conditional processing on received events, network and otherwise. We had to read the manual on this one and go through a couple of guided practices, but the effect was to create a visual stream that, after we used it, began to make sense. It let us test event variables directly and apply logic to any number of possible network conditions (traffic and node-specific). The event, once tested, can kick off a process, or be suppressed, and the alarm itself can be cleared, send a page or call a command-line executable.

The interface is difficult, but powerful. Although it's a visual language, it is not intuitive, nor does NetView come with enough examples to let you apply basic, generic correlations. While no programming is needed, NetView will require someone with plenty of general network knowledge, and knowledge of your network spe cifics. Our wish list for this product includes mo re scrollable lists, with context-sensitive help and the ability to automatically plug in information from the dat abase, like node names. Don't get us wrong; this is a good tool, but a great deal of work is required to set up and maintain accurate baselines.

The Events window fans the events--on what looks like 3x5 index cards--in a dizzying fashion on large networks. The display can be frozen, listed, sorted and searched in just about every way imaginable. One of the powerful features on NetView's interface is that if you think it makes sense to highlight and select, it probably does. When we selected a node that represented our main frame relay router, we got a view of its events, including the one that we had just correlated. We also got an icon representing the frame relay's filter right next to an icon that showed us all of the events. This automatic filtering icon gave us the ability to jump back and forth between the important nodes on the network, without any more than a couple of clicks in place s that made sense.

Online and historical monitoring of network traffic is much the same as in NNM, right down to using only line graphs. The menu system included a number of predefined collections for routers and HP and AIX systems performance, which made activating these studies easier than with NNM. But initially some of the known Cisco routers were not discovered as Cisco routers.

Not Hard. Easy! NetView's distributed server architecture is designed to not distribute the database. Rather, it uses distributed polling servers--Mid-Level Managers--to cut down on the topology and event traffic through the use of filters. These were the easiest of all the products to set up, requiring only that we start the central server's discovery, which, when it discovered a Mid-Level Manager, added it to a managed group on the top level of the map. The configuration is done via the Agent Policy Manager (APM), and was easy enough to change once we read the manual. Th e APM creates an icon that represents a collection of devices. Mid-Level Managers can filter events and even take corrective action on the event without involv ing the Systems Monitor running on the upstream NetView server.

SunSoft's Domain Manager

SunSoft's Domain Manager is for those who need to manage Sun-centric networks. Its systems management functionality is useful to networks using Sun gear, and the distributed architecture of SunSoft agents and distributed servers expands the size of the network over that handled by SunNet Manager. However, poor autodiscovery and lagging application and third-party support make it the wrong choice for most heterogeneous networks.

Manual Autodiscovery We spent days trying to get the autodiscovery process to discover our network correctly. We defined seed routers, limited hop counts, talked to technical support, added routers manually, ran the process from the command line, talked with technical support some more, limited it by IP address, created maps manually and laun ched discovery for the nodes below that map, brought technical support into the lab, let discover run over weekends, talked a bout a holiday gift exchange with technical support....In the end, the best autodiscovery did was to define a couple of routers, their connected segments and created submaps for their nodes. The rest of the network was either not found or incorrectly identified.

Frequently our Cisco routers were identified as common everyday ICMP devices (sorry Cisco), and in one instance, a laptop was discovered as a router. You can imagine the amount of manual work this left. We finally decided it would be less work to model the network manually than have to go in and audit and fix the nodes that were mapped. While Sun says it has never had this problem before, we can't see how this would work in anything but a small, relatively flat network.

One unique function of Domain Manager was its discovery of IPX network. It really doesn't directly do IPX discovery; rather it attaches to a Novell Man ageWise Server via a TCP port and a special agent NetWare Loadable Module. It then queries the ManageWise Server for topology up dates, which it integrates with the IP nodes already in the discovered database.

New in this version of Domain Manager is Network Layout Assistant (NLA), which helps fix the awful default-icon placement. The NLA sets the icons in a circular, hierarchical or flat configuration, with adjustments for icon spacing. SunSoft believes this kind of functionality is necessary, and we agree, especially with such a poor default layout. The trouble is that with a highly populated screen--say around 40 nodes or more--the icons are off the screen because they do not become smaller as the screen population grows. This screen scaling is common on the other products.

Gittin' Results Domain Manager, for all its layout failings, has easy-to-use information gathering tools. The Quick Dump application gets all the incidents for a MIB group of a selected node with just a couple of click s of the mouse. Scheduling, graphing and printing the same set of MIB groups or user-defined instance groupings is also fairly intui tive.

New in this release is the ability to start and stop MIB and agent requests for data, based on an event. Sun has done a good job making this a fairly straightforward process, again providing predefined and user-definable events. Conditional processing on MIB or database elements was not available, as it was on other products.

Everyone, Everywhere Domain Manager's distributed approach is very flexible. It has a complete filtering mechanism--the entire line of SunSoft network management products works together. These products include: Site Manager, which has some of the Domain Manager feature set, like NLA, but with the number of nodes limited; Sun NetManager, which is its legacy SNMP proxy agent product; Domain Manager; and Enterprise Manager, which is aimed at very large telcos and international organizations where CMIP support is required.

Th e basic approach is that Domain Manager opens a Cooperative Console session with another Domain or Site Manager (Sun NetManager is part of the d istributed architecture by way of forwarded traps and events). To set up a Cooperative Console session with a remote Domain Manager, we defined our local console on the remote system and then requested a session with the remote system from our local system.

The power of the session is in this setup, which uses filtering to determine what network database information is shared between the two servers. Information regarding traps, events and polling can be shared for all or some of the remote network. This means that by setting filters correctly, the relationship between the two servers' databases can be anywhere on a sliding scale between completely peer-to-peer and hierarchical. There are also no limits (in theory) to the number of relationships that a server has. So a single server might be forwarding information to one remote server in a peer-to-peer relationship, and in a hierarchical relationship to another, as well as receiving forwarded information from remote servers.

When we set up Cooperative C onsole relationships we had the choice to continue to maintain the polling of the same remote nodes that were being forwarded to us. There might be a redundancy reason for this, but generally it is not necessary. However, we wanted to find out how well Domain Manager resolved duplicate nodes. It did so beautifully. We then ran a test where we removed all of the nodes that we duplicated in order to determine the responsiveness of the remote updates. Initially the synchronization took a couple of minutes, but from that point on, we were unaware that the remote devices were receiving their updates remotely.

One problem with the setup was the lack of a character-based way to set up the remote console filtering. We ended up having to Xwindow the remote console's GUI. This wasn't unbearable over our 512-Kbps frame relay link, but would be painful on slower links. In the ca s e of a remote Domain Manager, there would likely be trained personnel at the remote site to perform the configuration, but in the case of Si te Manager, which is designed for smaller sites, the needed expertise might not be available.

Bruce Boardman can be reached at bboardman@nwc.com.

SOHO ISDN .
Return to The Table of Contents .

Updated August 8, 1996