Click on our Sponsors to help Support SunWorld

Support your TCP/IP global enterprise properly

Administering a rapidly expanding TCP/IP environment can be a nightmare. We show you how one company chose the right management tools and developed the right processes to dynamically assign and track IP addresses, names, and configuration files

June  1997
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

As corporations migrate to intranet-based computing, they need to make sure the infrastructure is also in place. TCP/IP is becoming the de facto networking protocol, and the accompanying domain name services (DNS) provide any-to-any connectivity across the TCP/IP computing fabric. At the same time, legacy systems (NetWare, Windows, etc.) must be integrated into an enterprisewide directory in order to speed information to end user recipients. This article provides a background on addressing and offers a case study to demonstrate the state-of-the-art in directory software. (2,800 words)

Mail this
article to
a friend

In the apocalyptic TV movie, "The Day After," the remaining survivors of the planet, ravaged by nuclear catastrophe, sent out a final plea: "This is Lawrence, Kansas. Is there anyone out there?" While the need for an enterprisewide global addressing and directory mechanism has not reached thermonuclear alert stage, the rise of intranets, Internets, and extranets have strained (to the breaking point) LAN-based or protocol-specific solutions.

With the lines of business in most organizations becoming more dependent on distributed applications, the dependence on the TCP/IP protocol suite is increasing proportionately. TCP/IP-based standards and support processes need to be developed and applied, to allow the technology-based information age to propel corporations into the next millennium. Given the migration toward larger network infrastructures and a new dependence on distributed TCP/IP-based applications, it is now critical for organizations to develop a centrally-administered TCP/IP infrastructure in order to ensure ubiquitous access to business unit-centric, client/server applications, and Internet information resources. As part of this process, it will be necessary to develop an integrated system based on tools and procedures to support the global TCP/IP enterprise.

Network administrators, faced with exploding demand for Internet/intranet-based access, know the symptoms all too well. Manually assign an IP address and name to every desktop PC, workstation, and network printer and administer the assignments from your handy dandy spreadsheet, word processing document, or napkin. This manual paper support process falls short of support objectives in all but the very smallest environments. This manual support model is a little like eating chocolate -- a few pieces of chocolate seem fine but eating the whole box will make you sick as a dog. The same holds true for administering TCP/IP networks -- you begin with a few TCP/IP gurus supporting early TCP/IP adopters (engineering) and then are forced to support an entire corporation of business users with the same meager support personnel.

The problem of administering larger and larger TCP/IP environments has caused growing frustration for network administrators. The manual and home-grown tools available to manage IP addresses, resource names, and configuration files can no longer scale to meet end-user services levels. Administrators need flexibility to control TCP/IP addresses, names, and configuration files from a central location and must have server-based tools that can automatically adapt to standard moves, adds, and changes.


What's out there?
There are viable alternatives to manual and home-grown TCP/IP support systems, and they involve implementing a server-based architecture to serve up IP addresses, names, and administrative boot files. Perhaps the venerable TCP/IP administrator doesn't need to throw in the towel just yet. Several TCP/IP administrative tools have emerged from the primordial IP slime that are designed to alleviate the pain associated with administering a dynamic TCP/IP environment. The available products run on network servers and range from department-based solutions to full enterprise systems.

The table below shows a sampling of such products:

Department Solutions
Vendor Product Server platforms supported Databases supported Directory dynamic updated Directory static updated Mgmt platforms supported SNMP Mgmt support Web Mgmt support
Microsoft (Doesn't support BootP or DDNS) NT server 4.0 NT 4.0 No WINs NT clients only WINs, DNS NT clients only NT server 4.0 No No
Novell (Doesn't support DDNS) NetWare 4.1 NetWare 4.1 No No DNS NetWare 4.1 No No

Enterprise Solution
Vendor Product Server platforms supported Databases supported Directory dynamic updated Directory static updated Mgmt platforms supported SNMP Mgmt support Web Mgmt support
El Paso, TX
IP Address Mgmt 1.3 HP-UX, IBM AIX, Solaris Ingres, Informix, Oracle, Sybase NO DNS HP-UX, IBM AIX, Solaris No Yes
Isotro Net Mgmt
NetID 2.12 HP-UX, IBM AIX, Solaris, Windows NT Oracle, Sybase DNS DNS, partial NIS Solaris, Windows 3.1, 95, NT No Yes Solaris only
On Technology Cambridge, MA 617-374-1400 IP-Track 2.0 NetWare 3.11 and 4.x Proprietary No DNS, NDS Macintosh Windows 3.1, 95, NT No No
Quadritek Malvern, PA 610-725-8535 Quadritek IP Mgmt QIP 3.0 HP-UX, IBM AIX, Solaris, Windows NT Oracle, Sybase DNS, NIS, NIS+ DNS, NIS, NIS+, ldap and X.500 Windows 3.1, 95, NT Yes Yes

The NOS-based solutions provide adequate solutions for simple IP networks with up to a couple of hundred users. As the number of users increase, the package enables a distributed architecture with a central address repository, support for heterogeneous server platforms, and integration with SNMP and Web-based management tools.

The leading high-end vendors, which feature IP address and directory management systems, are Quadritek and Isotro (recently purchased by Bay Networks). These enterprise products run on the network server and support end-user IP address and DNS moves, as well as adds and changes automatically, via management console software or a Web-based tool. Both products automatically issue IP addresses using dynamic host configuration protocol (DHCP) and can be configured to automatically update the DNS servers with the dynamic name assignments every time a change is made to the central address database. Specifically, when a client machine requests an address, the DHCP server checks the database to see if the name and address are already being used. Once the database clears the request, it sends the information about the newly-issued address via RPC to the primary DNS server with authority for the name space.

It is important to note that all administrative IP address changes are made to the master database and pushed down to the domain-based DHCP servers. This update process functions independently to the DNS update process, which relies on the standards base zone transfer process to synchronize distributed DNS servers. As a final point name updates, Quadritek's QIP also updates Network Information Services (NIS) and NIS+ servers which can prove important in a Unix environment.

Isotro and Quadritek both offer integration with the world of SNMP management. Isotro has chosen to address SNMP management by integrating an SNMP agent which allows IS managers to receive alerts (traps) from any standards-compliant management station and view raw MIB data. Most IS managers will find this base level offering better then having no management, but the software lacks a historical accounting and database integration perspective. An integrated management application, with one or more of the major network management platforms, would be a real benefit. Quadritek has chosen to bypass the SNMP agent process entirely in favor of building an application that bolts right into an HP OpenView management console.

Quadritek + Hewlett-Packard
The QIP OpenView management application has five major functions.

  1. HP OpenView Discovery: QIP integrates with the HP OpenView Discovery function to ensure that new QIP-based IP assignments that are discovered between updates by HP/OV are not seen as a "warning" issue but rather as a need to update.

  2. Exception Reporting: QIP can force database bidirectional synchronization with HP OpenView discovered nodes.

    Object Existing: QIP can automatically ping and check with HP/OV before assigning an IP address.

  3. Synch HP OpenView: QIP allows for the dynamic update of HP OpenView's databases every time a DHCP server hands out a new DHCP lease to a host.

  4. Import HP OpenView: QIP can be configured to import IP nodes from an existing HP OpenView management station.

  5. Database Cooperation: The combined QIP and HP OpenView nodes database fields are available from the QIP or Network Node Manager interfaces. Additions to the normal HP OpenView fields would be:

The downside to the QIP approach is that no alerts are sent back to the OpenView console in the event that one of the distributed servers has a problem. QIP should build an SNMP agent that can be situated on each of the servers and report critical operational statistics. A short-term fix to the problem can be achieved by integrating MeasureWare agents (from HP) on the distributed QIP servers and configure an application grouping for all QIP processes.

Juggling assignments
The primary objective of any IP address and directory management system is to manage the assignments of addresses via the DHCP/BootP process and names via the DNS process. The leading IP administrative tools make use of the DHCP, a recent extension to the venerable BootP protocol, to facilitate automated assignment of IP addresses. In all cases these extensions allow client machines, which support the protocol, to obtain its network operating parameters from a DHCP server via the network broadcast mechanism. This process enables the central administration of IP addresses, default gateways, and subnet masks for end user stations and softens the technical demands made on local administrators and their users. Both Isotro's NetID and QIP make use of dynamic domain name service (DDNS) to automatically map the 32-bit IP address, which most people find cumbersome, to a more user-friendly domain name.

Even with the advanced functionality of the Isotro and Quadritek products, additional customization may be necessary to meet large network automation requirements. Key issues like the integration of WINS (Windows Internet naming system) and TFTP (trivial file transfer protocol) are outside the reach of any of the enterprise IP address and name management tools.

General design recommendations
WINS servers are native to NT 3.51/ 4.0 and are used to assign NETBIOS names automatically to end-user stations. WINS names are based on a flat naming structure which makes standalone WINS servers incompatible with the Internet DNS naming scheme. One possible way to overcome this name resolution paradox is to synchronize the IP node names with the NETBIOS names. This will eliminate the confusion of having two names for single end stations and allow both WINS and DNS servers to function correctly.

TFTP servers typically work in conjunction with BootP servers to provide boot images to communications devices, X-terminals, printers, etc. Specifically, TFTP is used to cause a machine requesting its IP address via BootP to also receive information on the location of its operating system image and perform the download automatically. Centralized boot files are especially important in larger organizations where normalization firmware levels and configuration files are essential to the overall support process. Since the NT-based DHCP server does not support BootP clients or the TFTP protocol, and the Isotro and QIP products do not have integrated TFTP servers, additional customization is required to tie the TFTP servers into the IP management solution. The best recommendation is to set up TFTP server(s) on Unix boxes because TFTP is integral to operating systems. A stateless NFS system can be set up to verify image versions if a distributed server configuration is desired.

A real world problem -- and solution
A large manufacturing firm had reached the breaking point with its TCP/IP network infrastructure. Manual paper tracking processors were being stretched to the limit and with a push to integrate new TCP/IP-based distributed applications, the likelihood of a domino-like chain reaction was too great. The company needed a system that could dynamically assign and track IP address, names, and configuration files. Our firm, the Netplex Group, worked with the IS engineers to help solve this TCP/IP dilemma. The design for the new automated TCP/IP administrative architecture factored in the needs identified by each of the site administrators and the evaluation of available product offerings that could fulfill the specified requirements.

Recommended hardware and software platforms were as follows:

The architecture is depicted as follows:

Design summary
The new architecture placed a master QIP/DHCP/BootP server in the headquarters location and QIP remote servers within the same campus to service individual network segments. The master server contained the corporate DHCP/BootP database and distributed the database, as required, to the remote site servers. These servers provided both static and dynamic addresses to the corporate offices and all sites with less than 50 users via the routed BootP relay function. Each remote site with greater than 50 users had a local server to provide DHCP/BootP replies to local clients. This ensures continued local functionality in the event of a WAN failure.

Design decisions regarding DHCP addresses leases were made as follows:

  1. Automatic

  2. Dynamic

  3. Manual

QIP DHCP interacts with the domain name services on a dynamic basis, so that any assignment of an address by DHCP will be entered into the DNS database, and, as such, will be known in the environment. Any changes to the QIP data resulted in an update to the DHCP and DNS data within the time specified by the service level. The QIP DDNS was configured to accept the hostname as the default DNS node name. If no hostname was assigned, QIP was configured to automatically generate a random DNS nodename. Note: WINS servers were left in operation to allow "NT neighborhood browsing." However the NETBIOS and local host names were synchronized at the workstations.

The central server was made available to remote administrators to enable them to administrate their own subnet addresses. The QIP remote client provided this service level to both Windows NT and Windows 95 clients. Each administrator was assigned a user ID and rights to certain subnets and address ranges for which they are responsible. Upon an add, change, or delete request, the administrator could start the remote client and attach to the central server. The administrator could then implement the change on the central server and save the changes. The central server will send updates to all remote servers, reflecting the updated information, on a pre-set, timed basis. Once the central server has updated the remotes, the new information will be in effect. No direct changes are made to remote servers.

TFTP solution
TFTP requires a disk directory large enough to contain the operating systems for all communication equipment that will require downloads. Access to the file system for TFTP is limited to this directory only. Two servers were configured and contained duplicate data in identical directories. A stateless NFS mount process and shell scripts were implemented to ensure automatic version synchronization between the two servers. TFTP administration consists only of copying new boot image files into a specified directory on the primary TFTP server. These servers were centrally located for ease of access and administration and were physically connected to different LAN segments to provide better fault tolerance.

The central TFTP servers were configured to allow bootfile loads from any device (primarily LAN concentrators, routers, and X-terminals) in the network. Since this bootfile load process was not a daily occurrence, it was determined that any network response time issues caused by a remote file load would be minimal.

Additional design points include:

  1. Quantify the impact of variable length subnet masks (VLSM) on the design.

  2. Quantify the impact of route summarization and secondary addressing on the design.

  3. Ensure that BootP relay agents are operational, if required.

  4. Verify the operation of the TCP/IP stack(s) against the servers.

  5. Normalize NETBIOS and DNS node names.

Loosing sleep over an unruly TCP/IP environment is now a choice, rather than a fact of life. Choose the right tools, develop the right processes, and empower your administrators, and your IP nightmare will be a thing of the past.

Click on our Sponsors to help Support SunWorld


About the author
Frank Henderson is chief technology officer at The Netplex Group. His expertise is in designing and installing networks and reengineering help desks, and in ORB, distributed databases, and network management. Dave Koehler is director of network strategies at The Netplex Group. He has 13 years experience in distributed network design. Koehler has written for several journals, and has delivered papers at ComNet, IEEE, and SunWorld Expo. Reach Frank Henderson at and Dave Koehler at

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: