Previous Table of Contents Next


Chapter 61
TCP/IP Network Management: A Case Study

Vishal Desai

When an organization begins setting up a new TCP/IP internetwork supporting satellite and terrestrial-based data transmission, it must look at such major considerations as avoiding downtime, reducing implementation risk and cost, training and developing the implementation team, and incorporating ensuing software upgrades easily. This case study discusses the implementation path decided upon, the platform and software chosen, and the new operations workflow model that resulted in one such organization.

INTRODUCTION

One large organization is currently setting up a new TCP/IP internetwork supporting satellite and terrestrial-based data transmission. It intends to process collected data at two separate locations and distribute that data to 15 remote sites; therefore, the organization is designing the network to support a high volume of data transfer, initially supported by a DS3 backbone with an eventual migration to an ATM OC3 backbone. Aggregate network data rates are expected to range from 200M bps to 300M bps. Data types include administrative, historical, and time-sensitive real-time data.

Initially, the network will be comprised of 30 routers supplied jointly by Cisco and 3Com vendors, and 20 to 30 Ethernet and FDDI hubs from Cabletron Inc. and InterPhase Inc. Twenty DS3 CSU/DSUs, and about five DS1 MUX from Digital Link corporations are also included. As the network grows, additional routers will be deployed to handle increasing traffic requirements. The network is expected to grow exponentially over the next five years.

MISSION-CRITICAL AND FAULT-TOLERANT REQUIREMENTS

The data is considered mission-critical and accordingly needs to be protected in the event of network failure. Because data transfer rates are high, a huge buffering capability is required to preserve captured data in the event of even a brief period of network downtime. As a result, one of the organization’s primary goals is to avoid downtime at all costs. Accordingly, the organization is designing the network in a highly fault-tolerant manner. This includes provisions for redundant cabling, dual UPS for all routers and hubs, and an out-of-band network connectivity.

The transport system must have its own restoration capabilities, allowing the network itself to take care of as many problems as possible before the NMS must step in. In addition, to accommodate the stringent mean-time-to-restore requirements of 1 min. restoration, the organization has decided to maintain an inventory at each node. This inventory will, at a minimum, include spare interface cards, chassis, cables, connectors, and test equipment. This will allow technicians to swap parts quickly and perform detailed diagnostics off-line. The organization has also given careful consideration to equipment room design and equipment placement, ensuring such things as proper bottom-to-top airflow, placement of equipment with reference to ceiling water sprinklers, and easy access to the backs of routers and other devices.

NETWORK MANAGEMENT SYSTEM IMPLEMENTATION STRATEGY

The organization researched leading industry surveys and reports and concluded that large undertakings such as its implementation project are highly susceptible to cost overrun and schedule extensions and often fail to deliver the promised functionality. Accordingly, management developed a phased implementation strategy based on the philosophy, “Only bite off what you can chew.” Limiting middleware integration in the initial phase was deemed to be critical to the eventual success of the project.

As such, the company analyzed and listed all functions that comprise an enterprise management solution and selected the absolutely essential functions for its phase one implementation, which included:

  An SNMP-based platform.
  Trouble-ticketing software.
  A physical management application.
  RMON capability.
  Report-generation tools.

The organization decided to evaluate additional value-added functions, such as event correlation, integration with legacy systems, and modeling software, on a per-need basis in successive phases. The organization believes that such an implementation path greatly reduces its implementation risk and cost and allows it to train and develop an implementation team of manageable size instead of an army of operators and technicians. Finally, this strategy allows the organization to easily incorporate software upgrades as part of subsequent delivery.

Another area that the organization considered vital to the success of its system was early integration of its business processes with the underlying management technology. As such, in each phase, during the system design and development, the managers decided to define and closely couple their operations concepts with the network management system. This ensured that issues pertaining to maintenance philosophies, remote-sites, operator roles and responsibilities, and handling and parsing of trouble tickets were probed in-depth during the system design and implementation cycle. Such an approach guaranteed that the implementation engineers weighed and considered the operational needs early in the development cycle. Not only did this provide the organization with a “complete workable solution” but also greatly reduced system changes after it became operational.

The SNMP Platform-Evaluation Criteria

Before selecting a network management platform, the organization tested several systems in its development lab. Between 1992 and 1994, the systems tested in the labs included Cabletron Spectrum, SNM, HPOV, NL’s DMONS, and IBM NV. The organization made its selection carefully, as the decision entails a 15-year commitment to the network management infrastructure. The organization was initially impressed by the NL’s product, particularly its ability to perform alarm correlation using it Nerve Center application. However, the organization took into consideration NL’s precarious market position and chose to select a larger, established player.

The organization decided against Cabletron Spectrum for two reasons. First, the managers were concerned about Spectrum’s ability to fully manage competing vendors’ hub products. Second, the organization wanted to customize Spectrum’s filtering and network modeling capabilities and, after extensive testing, concluded that detailed customization would entail immense up-front development.

SNM was ruled out because the organization found the user interface too archaic, and Sun’s higher-end Enterprise Manager was not yet shipping. Finally, IBM NV, although it offered high product stability and advanced features, was discounted due to its DOS/OS-2-centric hardware dependency. Such dependency, according to the organization’s existing skill base, would require retraining of its operators, who were familiar with Sun and HP workstations.

The organization then chose HPOV primarily because the product offered a flexible and industry-pervasive management platform that facilitated the integration of third-party applications and because it appeared to pose the least risk in terms of product longevity. Additionally, the NNM, HP’s SNMP manager, adequately provided the basic management functions without requiring significant up-front configuration or development investment.


Previous Table of Contents Next

Copyright © CRC Press LLC