|
|
Support your TCP/IP global enterprise properlyAdministering 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]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
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 |
| Accugraph El Paso, TX 915-581-1171 |
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 Ottawa 613-722-1921 |
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.
Object Existing: QIP can automatically ping and check with HP/OV before assigning an IP address.
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:
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:
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.
|
|
Resources
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
frank.henderson@sunworld.com
and Dave Koehler at
dave.koehler@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright97.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-06-1997/swol-06-realworld.html
Last modified: