A new generation of network management ``platforms'' can show what's happening throughout a far-flung network, across every bridge, router, gateway, and hub
Paul Korzeniowski
It's a nightmare--keeping track of all the bits and pieces, nodes and workstations, and black boxes and connecting devices that make up a network; identifying trouble spots; and handling all the administrative chores generated by an ever-growing, ever-changing user population. What's needed is automated help in the form of a network management system. The primary goal of such a system is quite simple: to identify and replace faulty equipment. Actually doing that, however, is not so simple.
Consider the data path, for example. A user's PC might pass information to a network adapter card, then over an Ethernet LAN to a c
ommunications server, and then to a router that uses a T1 phone line, just to reach a front-end processor that sends information to a Unix server. And returning data has to retrace those steps. Problems can occur anywhere along this path, and the range of possible problems is large.
Finding a single network management application capable of doing the entire job used to be an impossible task. But now it's beginning to look more likely, because of a shift from proprietary, stand-alone, device-level applications to what are known as network management platforms--integrated systems that can gather data from a variety of third-party applications and present it in a consistent interface.
A platform offers network equipment suppliers a common set of services, such as a map displaying all connected equipment. Platform suppliers encourage third parties to build applications that run on platforms. So, a router manufacturer now designs an application that works with others on a central platform, not as a s
tand-alone program.
Device suppliers welcomed this change, because they could now hand over a portion of their software development activity to the platform vendors and thereby save themselves (and their customers) money. As a result, hundreds of applications running on management platforms are now available on the leading systems.
This shift from proprietary to platform applications is a critical development, because it appears to be the only real hope for the effective management of continually growing and changing enterprise networks. The wide acceptance of SNMP is an important factor in allowing vendors to tie their applications into the platforms (see the text box ``Moving from Proprietary Management to SNMP'' above).
Filling In the Gaps
However, there are still some voids; some areas are still without third-party applications. Many network device suppliers are just beginning to port their management applications to the dominant platforms. For instance, Wellfleet (Billerica, MA),
the second-leading router supplier, sells a version of its SiteManager package that runs on only one of the three leading platforms. (Wellfleet recently merged with SynOptics Communications [Santa Clara, CA] to form Bay Networks.)
Links to PC LANs are just emerging. In addition, connections to Banyan Systems' Vines networks and Microsoft's Windows NT Advanced Server are hard to find.
Much of the network equipment currently in service dates from the mid-1980s. Some of these devices may not have been upgraded and are thus unable to operate with management platforms.
Platforms help corporations rein in network management applications. Because all the applications run on one platform, troubleshooters no longer need to work on three or four different terminals simultaneously to pinpoint problems.
Because of such improvements, sales of network management platforms have swelled. International Data, a Framingham, Massachusetts, market-research firm, estimates there will be over 20,000 cent
ral management platform installations by the end of 1994 (see the figure ``Installed Base of Network Management Platforms'').
The Main Players
At present, the platform arena includes three major players: SunNet Manager from SunSoft, a division of Sun Microsystems (Mountain View, CA); OpenView from Hewlett-Packard (Cupertino, CA); and IBM's NetView for AIX. Here's a brief look at each one.
SunSoft's SunNet Manager. SunSoft introduced SunNet Manager, the first commercial network management platform, in 1989. It's still the top-selling Unix network management platform. Being first helped SunSoft in the marketplace, and its track record is important in luring customers.
Three years ago, the Cobb County government in Atlanta, Georgia, realized that, at 4000 users, its network had become unmanageable. The county determined that a network management platform was called for. SunNet Manager was selected because, according to Gene Estensen, information services manager for Cobb County, ``it was
the only platform that ran on Unix and was stable.'' The county purchased the platform along with SynOptics' Optivity to manage its Cisco Systems (Menlo Park, CA) routers and SynOptics wiring hubs.
HP's OpenView. But SunSoft did not have the market to itself for long. In 1990, HP entered the platform arena with OpenView. HP has been successful in courting third parties; Data General, Groupe Bull, and Hitachi resell the package, and this has helped OpenView gain market share.
In 1992, Martin Marietta, based in Orlando, Florida, wanted to move from proprietary management tools to open systems. Frank Mellard, a Martin Marietta senior communications consultant, says the company was more comfortable with HP's long-term direction: ``We felt that HP had a better grasp of the problems of managing large, complex networks than Sun.''
Martin Marietta's corporate network is quite large--100,000 users--and it is also complex. Its computers support AppleTalk, DECnet, SNA (Systems Network Architecture)
, Novell's Integrated Packet Exchange, and TCP/IP. The company currently uses OpenView along with Remedy, Inc.'s, Remedy trouble-ticketing package to control its TCP/IP connections. The company has plans to tie OpenView to DECnet with software from Isicad and to SNA with Peregrine's OpenSNA.
IBM's NetView for AIX. In 1992, IBM decided to develop a Unix network management system. Rather than write it from scratch, the company licensed HP's OpenView to incorporate into NetView for AIX. To further convolute the mix, DEC dumped its proprietary network management platform, DECmcc, in 1993 and became a NetView for AIX reseller. Because of its late entry into the market, IBM lags behind SunSoft and HP, but it has been steadily gaining ground.
For example, in 1992, the University of Florida in Gainesville searched for a platform for its 3000-user network. Because it had relied on the mainframe version of NetView for 10 years, the university chose NetView for AIX to manage wiring hubs from Cabletron and
IBM as well as routers from Cisco, Proteon, and Wellfleet. Jerry Wetherington, systems coordinator, notes that a major advantage of using NetView is that a technician can view network devices on a central map and get a quick picture of how the network is functioning.
Integrated or Not? Users Tell All
Map support is one of many ways in which a third-party vendor can integrate its application into a network management platform. But third-party applications differ in the way they work with major platforms. ``Some third-party applications run on Unix fine without the network management platforms,'' notes L. Dave Passmore, a principal at Decisis, a consulting firm in Herndon, Virginia. Skeptics claim that about half of all listed applications actually run as stand-alone systems. Platform vendors downplay that claim but admit that the level of integration varies dramatically from application to application.
In its latest third-party catalog, HP identified 17 possible areas of compatibility. Gordon
MacKinney, OpenView marketing communications manager, says the most commonly supported features are a common interface and an ability to access a MIB (Management Information Base).
Because of the wide range of options, users often receive far less integration than they expect. For example, third-party applications might rely on their own polling and error-handling features, which results in redundant processing. Some products may have their own data-display facilities, with the result being that even simple things, such as color coding, differ among products. One company might represent a faulty modem with a flashing yellow indicator, for instance, while another might use a blinking red light instead.
Some companies limit the number of network vendors they use. For instance, Tom Davis, engineering department system administrator at Dayton University (Dayton, OH), started relying on SunNet Manager in 1992 with the department's 500-user network to identify physical problems, such as broken cables.
When SunSoft added PC management features to its Solaris operating system, the university simply expanded the scope of SunNet Manager. Since SunNet Manager applications present information in a consistent manner, technicians didn't have to learn several different interfaces.
Some third-party applications also offer data consistency. For instance, to oversee its 2200-user network, the Presbyterian Health Care System in Dallas, Texas, relies on Optivity and its add-on modules. Mel Lively, network manager at Presbyterian Health Care, says the company uses FaultMan to control its wiring hubs, RouterMan to oversee its routers, PathMan to determine network connections, PolicyMan to set network thresholds, and FactMan for trouble-ticketing.
But most networks rely on multiple management applications. For example, a company may have Chipcom (Southborough, MA) wiring hubs and Proteon routers. In these cases, all sorts of problems arise because of user-interface issues.
Data Integration: Tying It Al
l Together
Data integration presents other vexing problems. ``Currently, different management applications store information in distinct databases,'' notes Passmore at Decisis. ``So, a company can't take wiring-hub information and correlate it to work with its router network.'' Another data-compatibility problem arises because different network management applications employ different DBMSes to store and analyze data. For example, a router application might store its information using Sybase, while a platform relies on Ingres. What's an organization that uses both network management products to do? Use both DBMSes?
Here's a case in point. The Travelers (Hartford, CT) operates an IBM SNA network with 25,000 devices, and a LAN-interconnected network with approximately 15,000 nodes. Because it has traditionally relied on IBM for much of its networking equipment, the company began working with NetView for AIX in January.
Eric Mirer, an engineer/consultant at The Travelers, says ``there is litera
lly no integration among the data generated with our various management packages.'' Data about the company's IBM RS/6000 servers is stored in one database, router information is housed in a second, PC LAN information is monitored with an OS/2-based package, and mainframe data is overseen by IBM's NetView. The Travelers wants tools that consolidate all that information. ``Data integration represents the big kahuna for network management suppliers,'' notes David Abbajay, software development manager for network management products at Cisco Systems.
SNMP specs include a MIB standard so that management tools can access database information. With a MIB browser, for example, HP's OpenView can examine information generated by Cisco routers. However, there's no standard for translating that information so it can be stored in one location. Thus, problems arise when two vendors rely on different DBMSes.
Even with a common DBMS, there are limitations. ``Two vendors can rely on the same DBMS, but if they us
e different rows and tables, then their applications cannot share common information,'' explains Abbajay. Thus, platform vendors have to add a layer of software that identifies database differences and translates them. These features constitute a data schema, a technique outlining how to store data in a consistent fashion in a central repository.
Platform vendors are at different stages in the search for solutions. The first step is incorporating support for RDBMSes (relational DBMSes) in their products. Next, they must outline a central repository model.
Market leader SunSoft has been the quietest about its plans. SunNet Manager now relies on a flat-file system to store network management information, but the company plans to support RDBMSes. Yet SunSoft has been silent on the repository issue. ``Sun will have to say something soon to keep pace with competitors,'' says Passmore at Decisis.
HP has been gradually improving OpenView's DBMS capabilities. Initially, the product stored informa
tion in flat files, but HP now uses DBMSes and plans to support a wide range of them in the future.
In August, HP unveiled its plans for building a network data repository: OpenView Meta Schema. This document specifies object attributes, topology, and trend information. In the first iteration, each vendor will own a slice of the DBMS, which will be accessible to third-party tools.
HP plans to eventually allow all information to be stored in one database. How long that will take, however, is unclear. HP has invited third parties to comment on the working draft of its schema.
One might think that IBM would work with HP on the repository issue, but no. In fact, the two companies have been moving away from each other during the past few years. The first release of NetView/6000 relied on OpenView for about 75 percent of its functions. However, ``the latest release of NetView for AIX might be 10 percent OpenView code, and the rest is IBM-developed,'' states John Byzek, director of enterprise ma
nagement development at IBM's Network Systems Division in Research Triangle Park, North Carolina.
IBM says that HP didn't offer a sufficiently robust product. ``We found a lot of problems with the source code, so we felt we had to develop the work ourselves to ensure that our customers would have robust software,'' says Byzek.
HP's MacKinney scoffs at this. ``IBM may not like to admit it, but NetView for AIX is based on OpenView,'' he counters, concluding that IBM has been taking heat from third parties for forcing them to use another API. ``So, IBM needs to justify its actions.''
In August, IBM unveiled its Karat project, which relies on objects to integrate disparate database information. The software is based on the CORBA (Common Object Request Broker Architecture) standards as well as on IBM's SOM (System Object Model), an operating environment that lets users develop distributed, object-oriented applications.
With the primary suppliers moving in different directions, which one
has the best chance for success? SunSoft has the leading market share and many third-party supporters. HP is gaining ground and widening its distribution channels. IBM can tap into the base of companies already working with its mainframe and LAN management systems. Third-party support is crucial, so all three are courting third parties.
``Dis-Integration'': Competition's Dark Side
While the move to platforms has been a blessing for network suppliers, it also has its downside. Passmore at Decisis notes that ``a package like Ciscoworks was designed for SunNet Manager. Because Cisco relied so much on the Sun platform, the company has been slow to deliver versions of its software for other platforms.''
Cisco planned to deliver versions for HP's OpenView in the fall, and for IBM's NetView for AIX shortly thereafter. Cisco's Abbajay admits that the different versions took longer to deliver than anticipated, but he says porting was only one of several reasons why the software was late.
Whate
ver the reasons for Cisco's delays, most third parties do not want to align themselves too closely with a single platform because it takes extra time to move their software to another. They would clearly prefer a common set of APIs.
For their part, platform vendors want to differentiate their wares and have no desire to standardize APIs. In May, a group of third-party organizations formed the MIC (Management Integration Consortium) in an attempt to wrest control of the APIs from platform vendors. The group plans to outline a schema for storing information in DBMSes, for developing a simple API for access to common data, and for integrating multiprotocol events.
``Vendors face two choices: Deliver something simple that works, or bring something comprehensive,'' notes James Herman, a principal at Northeast Consulting Group, a Boston-based consulting firm. ``MIC is working on something simple, so it has a good chance for success.''
Joseph Diamond, a marketing manager at Peregrine Systems (Ca
rlsbad, CA), says that MIC membership has swelled to 30 suppliers and that all three platform vendors are vying to have their work adopted by the group. MIC has begun working on the first draft of its data schema, plans to complete it by early 1995, and expects conforming products to arrive during 1995.
But users should be cautious; previous integration tries have failed. IBM was the first vendor to step up to the chore with its mainframe NetView products. In 1989, it announced its SystemView initiative to provide a common repository. But when it announced the Karat project, IBM was throwing in the towel on SystemView.
In the early 1990s, the OSF (Open Software Foundation), a vendor consortium in Cambridge, Massachusetts, was charged with creating common network management standards. The group outlined a complex set of standards dubbed DME (Distributed Management Environment). HP and IBM were early backers. The OSF missed shipment dates, however, and eventually DME also went the way of the dinos
aur. ``DME was ahead of its time, and that's why it failed,'' notes IBM's Byzek.
A principal reason for failure to achieve integration is vendors' constant attempts to differentiate their products. Martin Marietta's Mellard notes that adherence to MIB specifications would eliminate many current incompatibility problems. ``Problems arise because vendors always add proprietary extensions to existing standards,'' he says. ``Whenever that occurs, the level of interoperability drops significantly.''
Vendors admit this without remorse. Cisco's Abbajay says that ``a vendor has to differentiate its products in order to sell them. Whenever you add value, the level of interoperability diminishes.''
Is there hope for integrated network management? ``The fact that HP and IBM are now supporting only the lowest common denominator in their management systems, rather than working together, does not bode well,'' states The Travelers' Mirer.
Cisco's Abbajay counters that the MIC will enable users to
mask the distinctions. And, although current products may be flawed, they do offer more integration than yesterday's alternatives.
Observers expect the level of integration to continue to improve. Northeast Consulting's Herman concludes that ``everyone knows what the current problems are, but how to fix them is not as clear. Solutions will eventually emerge, but users shouldn't get their hopes up. There is no short-term fix to this problem, and years will pass before it is fully addressed.''
Figure: Installed Base of Network Management Platforms
Source: International Data Corp. (Framingham, MA)
Illustration: An HP OpenView screen shows the overall network configuration.
Paul Korzeniowski is a freelance writer specializing in communications and networking issues. He can be reached on the Internet at
6841944@mcimail.com
or on BIX c/o ``editors.''
Monitoring Your Net
