Cover Story

Enterprise Management Is Just Around The Corner

by Art Wittmann and Bruce Boardman

We tested some preview editions of the next generation of network management products from SunSoft, HP and Cabletron, and the latest shipping version from IBM. Here's what we found...

HP OpenView Network Node Manager v4.0

OpenView Network Node Manager (NNM) has gotten better since I last looked at it--lots better. The last version I tested was 3.0, and it had serious problems. The software couldn't manage many stations (it crapped out at about 1,000), didn't scale well and came with virtually no support for non-HP hardware.

NNM v4.0 addresses all this, although not strictly because of HP's efforts. CPUs are substantially faster and the 64 MB (or more) memory required two years ago is more common and somewhat more affordable today. On the other hand, I counted no less than 147 MIB definitions from 47 different companies under NNM v4.0. Company-specific MIBs are where network management's real value lies, and it's good to see HP include so many.

I was disappointed, however, to see other NNM limitations unaddressed. While the Windows version will manage both TCP/IP and IPX devices, its hefty Unix sibling only knows TCP/IP--although HP sells a NetWare product for NNM (that still relies on TCP/IP). HP sees the lack of IPX support as a result of its high-end enterprise focus. I tend to see it as a mistake HP should have corrected by now. NNM doesn't support Windows NT either. While you mig ht be more likely to run NT using TCP/IP, having specific knowledge of these operating systems also seems reasonable for an enterprise management console.

RMON and other IETF-developed MIBs are becoming increasingly important, and this new version of NNM has no special support for them, leaving that to other HP products. Certainly as you add switching to your network, you'll want your network management console to deal intimately with RMON.

Ease of Use: Getting Closer! HP has improved the software in a number of other ways, however. For example, it has added a configurable tool bar and improved the browse-ability of subnet lists. Nowhere is it written that $16,000 software should be hard to use.

On the other hand, there's room for improvement. For example, if some managed piece of hardware fails, it typically turns red (other actions are taken too, but at a minimum, the icon becomes red). Being the ever-watchful network manager, I double-click on the red thing to see what's wrong. The problem is, you don't find out what's wrong that way. Instead, you highlight it and then use the "Events" menu to find out what's wrong. That seems pretty counterintuitive, and it exemplifies how far these products need to go. The interface problem actually gets worse as time goes by, since your trained base of users gets used to the arcanity of the software, and vendors become tied to the oddities because the existing user base is.

On the bright side, HP has continued to make OpenView more, wellıopen. Along with its default, proprietary, flat-file structure, OpenView can also use Oracle and Ingres databases for data storage. Ingres has been an option for a while. Oracle support is new. You might think that Relational Database Management System (RDBMS) support would speed up performance, but you'd be wrong (as I was). HP tells us that the flat-file system is slightly faster than using an RDBMS, and that customers typically use the relational databases so that they can perform other queries on the NNM-ga thered data.

Performance is still a big issue overall, and HP has gone to significant effort to make NNM operate in a more distributed fashion. HP used to say that no more than five operators could use a single system running NNM. With its more distributed approach, it has raised that number to 15. During my time with the software, HP was careful to start NNM on one system and each of its other products on other systems in the test lab.

Discovery That Works It used to be that NNM would discover the entire network by default. This is no longer the case. It now starts at the management station and goes out one level of subnets (and hence, routers). This is generally a very good thing, since you have much more control over the devices you choose to manage. NNM also checks with your friendly neighborhood DNS server and resolves IP addresses into host names, making determining the stations to manage much easier.

NNM brings all devices that have two or more connections to the network up to the top level of the network diagram. This is a good layout technique, since you automatically get a map with all of your routers on the top level. You'll get some servers, too, if they happen to be connected to more than one network. NNM has done this for a while and I liked the feature the first time I saw it.

I particularly liked the limited discovery option. Limiting the station's management has two effects: First, there is no use seeing stations listed on the console that you don't want to handle. Second, by limiting the number of managed stations, NNM runs faster.

Solstice Enterprise Manager v1.1

Sun was one of the first network management vendors out of the box with SunNet Manager (SNM), but compared with others, SNM has seemed a little anemic lately. SunSoft added a few enhancements, but rather than try to fix a product that really was never meant to compete with more capable offerings from the likes of IBM and HP, SunSoft developed Solstice Enterprise Manager (SEM). SunSoft still offers SNM, but it's targeted at smaller networks.

Solstice Enterprise Manager v1.1 is a highly distributed, agent-based management tool that will appeal to the largest of the large network providers--including telcos and large corporations that place a significant value on their worldwide data network. SEM sits prominently in SunSoft's Solstice product family, and it should. SEM's databases (called Management Information Servers or MIS) are fully distributed and so are its consoles. This sort of distributed, object-oriented database sets SEM apart by making it more scalable and more capable of handling large wide area networks.

Made for the Big Enterprise SNM has long been dependent on SunSoft's own Remote Procedure Call (RPC)-based agents. In fact, SNMP delivered information to SNM through such an agent. SEM is much more flexible. It supports SNMP, Common Management Information Protocol (CMIP) and RPC agents and is internally oriented toward CMIP. It might surprise you that SunSoft, a company that has historically been committed to TCP/IP and Internet-based standards would create a product based on an International Standards Organization (ISO) standard. But then, everything about SEM is aimed at the large, multinational concerns that actually like and use ISO standards; so much so that two of the key standards upon which SEM is based--OMNIPoint and TMN--are both primarily telco standards.

SunSoft expects SEM buyers to customize it, and heavily at that. There are development kits to write both agents--which SunSoft calls management protocol adapters--and data viewers or consoles. SunSoft provides an Application Launcher tool bar from which various applications, like SEM's own console/viewer, can run. SunSoft's data viewer is written with the same Portable Management Interface APIs available to any customer. SunSoft sees it not only as a useful general purpose tool, but also as an example of what can be done, and expects that many of its customers will want to write a new viewer or exte nsively modify the one it provides. The front-end viewer isn't just tied to Solaris either. SunSoft also provides the hooks to build consoles on Windows.

Perhaps one of the most interesting aspects of SEM is its object-oriented database. With it, you can make requests for data and configuration changes against classes of nodes on the network. SunSoft showed me an easily created query that returned the status of all of the Cisco routers on the network. This is only possible through object-oriented technology, and it is a significant tool for those tasked with managing a large wide area network. SEM provides a very flexible environment for generating reports on almost any aspect of such a WAN.

Event Handling SEM excels at handling events and alarms, too. Although the first version doesn't do it, SunSoft plans to add enough smarts so that events caused by other events can be recognized as a single event: for example, a router going down and the management station subsequently losing contact with all managed stations on the other side of the router. Request Builder is the tool you use to define regular queries of managed devices, and through judicious use of the tool, you can minimize these "effect" alarms. Alarm handling and acknowledgments are also designed to conform to ISO standards.

SEM can also define a state machine that represents the possible states of a managed device. At each state, events, alarms and actions can be defined. SEM will execute these actions when it finds the managed device in a given state. This is a powerful, unique tool that exemplifies SEM's flexibility.

As you'd expect, SEM's discovery and layout are somewhat more sophisticated than SNM's. In fact, the biggest complaints that I've had about SNM are its lousy layout ability, inflexible discovery and the inability to rename an object it discovers. SEM suffers from none of these problems. As it discovers devices, it sensibly places them on the network diagram. You can associate MIBs and RPC agents with the mana ged object, making it much easier to get information on classes of managed objects.

Layout is done in a hierarchy, and groups of devices (such as routers or servers) can be placed into their own views. Once your database is built, you can export it as a flat file, Sybase, Informix or Oracle database.

SEM Management Information Servers require a minimum of a SparcStation 20 with 96 MB of memory, 200 MB of swap space and at least 1 GB of disk space. The Management Information Server currently resides only on the SPARC version of Solaris since both TCP/IP and ISO protocols are required.

Cabletron Spectrum v4.0

Spectrum is in the lead and pulling away, only nobody knows it. Did you know that the current release of Spectrum (v3.1) already has the multiclient, multiserver, distributed architecture that the big three (HP, IBM and SunSoft) are bragging about for their next releases? Don't feel bad. You're not alone!

Spectrum will actually manage multivendor networks right out of the box, unlike its competitors who rely on third-party vendors to provide add-on programs to make the management platform useful, or expect that you will use their network devices primarily. Not that Cabletron doesn't consider its network hardware the end-all in network device offerings. It does, and Cabletron sees its management strategy intimately tied to its hardware. However, Cabletron seems to be paying a bit more attention to reality.

Spectrum often gets a bad rap for not having the wide third-party support others have, but at last count, 136 vendors offered 166 Spectrum applications, in addition to the 56 Cabletron offers. We tested an alpha version of the new Spectrum 4.0 release, which is due out around the end of the year. Not only does it have a year's head start over the big three, but if it delivers all that Cabletron promises--from distributed applications to Windows NT as an operating environment--it's going to pull away from the pack. The question is, will anybody know it?

Promises, Promises A year ago, Cabletron brought unlimited scaling by braking apart its network management software into a client--SpectroGraph--and a server--SpectroServer. Version 4.0 adds more functionality, with distributed applications that focus reports and data from multiple servers to distributed clients, apply and store configurations between servers and facilitate receiving alarms from multiple servers on distributed clients.

Cabletron also plans to include the ability to export data on multiple servers in Spectrum's proprietary database to flat-file, Sybase, Oracle or SAS databases. These reports can also be printed or delivered in HTTP format for Web browsing.

Cabletron plans to tackle Novell with a Network Management Gateway Server for IPX. The promise is systems, user, file and fault management without adding NetWare Loadable Modules (NLMs) or any code to the NetWare server. Finally, and maybe the biggest promise in 4.0, is that Cabletron is porting Spectrum, both client and server, to the NT 3.51 platform. SunSoft is putting its viewer on many platforms, but leaving the server on SunSoft. The reason, according to SunSoft, is that there are no good ISO stacks available on other platforms.

Finding the Network Autodiscovery using any network management platform is a black art. No matter what techniques they use, the details of a particular network will throw a curve into the mix, making the resulting topology map inaccurate. Manual verification of autodiscovery results is always required, no matter what platform you're using.

With this in mind, I first ran a discovery of only our collapsed backbone. The process spanned the IP subnet that acts as a backbone and discovered the routers by getting their SNMP System-ID. Routing tables and the ARP caches get queried, resulting in maps of the router interfaces and their relationship to the other routers on the backbone. The resulting map was correct.

This relational aspect of Spectrum's map is unique. Spectrum uses a technique called Inductive Modeling Technique (IMT), aided by generic models or objects that describe the characteristics of a large number of third-party networking devices like hubs, routers and RMON probes. The idea is that knowing what a particular device does helps define its relationship to other devices in the network.

I also ran a discovery on the entire class "B" network and mapped the rest of the routers, hubs and LAN devices along with a name lookup from the Domain Name Server (DNS), which correctly applied names to the discovered devices. The result after this second pass wasn't quite as accurate as my router-only pass, but with a little cutting and pasting I could mold the topology map to about 90 percent accuracy within an hour. For my purposes, this was close enough. While cutting and pasting the remaining 10 percent would be trivial, certifying the results of this, or any autodiscovery, is significant.

Functional Out of the Box Spectrum makes intelligent assumptions about what a network device does, and because of that, it can monitor device functions without a clumsy MIB walk. So a click on the device brought up a statistical display that showed tabled and graphical representations of how the selected device was performing.

Spectrum's icons are "active," so clicking on different parts of the icon opened different windows of information about the device, or opened up subnets or attached devices hierarchically located below the selected device. So right away we had all this rich information, and until we became familiar with the user interface, we didn't really know where it was coming from.

For instance, a load parameter was reported for a Cisco router, but nothing told us what that meant. It turns out that this is another feature based on the generic model for a Cisco router. Spectrum made a calculation of how much of a load our Cisco router was processing. That's useful and modifiable, but confusing at first.

A further extension of the models and IMT technology is Spectrum's corr elation of alarms. When I simulated a router failure by disconnecting it, Spectrum only reported that the router was down. It didn't report on all of the devices attached to it. Again, this is a feature that the other big three are talking about, but that Spectrum has had.--B.B.

NetView For AIX SNMP Manager

I couldn't look at NetView for AIX without getting a healthy dose of IBM's "strategic," all-encompassing, we've-been-doing-it-longer, the one and only, drum roll please, SystemView. The plan is very well thought out, just not a realityıyet.

IBM wants SystemView, the umbrella system management product that includes NetView for AIX 4.x, to lead the network management/system management field in openness and distributed architecture. The plan is to make all of the products that make up SystemView standards-based and object-oriented. That's what is happening in v4.x. IBM says its involvement in the COSE effort is strategic to giving SystemView, and consequently NetView, an advantage in network and system management. In addition to open systems development, IBM supports not only SNMP MIB-II, but CMIB, and is shipping an Application Programming Interface (API) that supports early attempts at SNMP v2.

Architectural Nuances I tested NetView for AIX 4.x and found that while IBM is on the right road, like HP and SunSoft, it's playing catch-up to the functionality of Cabletron's Spectrum. However, where IBM takes no back seat in being "open" is in database support, where NetView supports DB2/6000, Informix, Ingres, Oracle and Sybase.

IBM has also decoupled the server and client portion of NetView 4.x. Each server supports up to 30 client stations--twice the number of clients HP currently supports, but still trailing Cabletron's Spectrum, which supports multiple clients attached to multiple servers in a many-to-many relationship. IBM claims that this new client/server relationship will run v3.0 third-party applications. I didn't have any existing NetView 3.0 applications to test th is backward compatibility.

I was concerned that NetView's single server architecture would limit its support of larger networks. IBM says NetView, with additional hardware, could expand to support a 20,000-plus node network easily. Still, they all have to communicate over the network to a centralized server, a seriously limiting factor over slower WAN links.

Nevertheless, with the new client/server relationship, client machines can load their map from the server or store it locally. Still, while locally stored map loading improves performance, network map changes on the server must be distributed.

Since new architectures may introduce new security concerns, the NetView client authenticates users on client machines separately from operating system login. This adds an audit trail and allows for a change of operators, like during a shift change, without having to down the client application.

Getting Around I ran autodiscovery by choosing a seed router, which, via its ARP cache and our DNS server, correctly drew a map representing our network. Unfortunately, all of the devices were placed on the same level, creating a huge, unwieldy map. I used NetView's new Collection Facility to mold the topology map to represent the hierarchical constructs of the network more closely. This really just involved cutting a logical group of IP subnets from the auto-discovered topology map and pasting to a new, empty map. I associated this new map with a single icon that I placed on the top level map.

This was a more logical way to handle the large number of subnets. Subsequent changes to devices were reflected in the map and not in the original autodiscovered topology. Yet overall, this made navigating the network customizable for each client workstation, and easier to deal with than the overwhelming display of subnets and devices I saw with Cabletron's Spectrum.

The Navigation Tree made map navigation even easier. It's just a high-level tree representation of the network topology that sits in a cut out window on the screen. It showed the tree paths I had drilled into, and let me quickly return to a previously opened section of the map. It would have been better if I could have made my initial drill-down from this high-level look, but since that would have defeated the purpose of having a summary view, a user-definable view of frequently visited locations would have sufficed.

Controlling Events The event and alarm status has been enhanced with the ability to trap and alarm based on just about any detail, including MIB variables. This flexibility still required understanding the MIB structure of the device that I was trapping on, but the additional granularity for alarms was good.

The Control Desk is a screen cutout, and its purpose is to provide quick access to applications. Its default is to run the alarm application, but you can drag any application onto the Control Desk. I created alarms, which the Control Desk displayed as stacked index cards. When I fixed the problem that was creating the alarm, NetView removed the associated card from the Control Desk automatically. For chronic problems I was able view or print the log of events for particular alarms or devices.

I found the procedure for creating alarms very detailed, and it really showed IBM's experience in managing trouble tickets within its mainframe products, like InfoSys. The focus is procedural, calling on organizations that are going to implement fully this kind of approach to define how they want various severities and types of alarms to be handled. Even though it's not easy, it's certainly the right way to set up event monitoring.

Art Wittmann can be reached at wittmann@engr.wisc.edu. Bruce Boardman can be reached at bboardman@nwc.com.

October 15, 1995