Previous Table of Contents Next


Chapter 68
WAN Network Integration: A Case Study

Charles Breakfield

Merging two wide area networks (WANs) is a process comprising several steps that, when carefully planned, can ensure a successful implementation. In the case of the Resolution Trust Corp.n (RTC) and the Federal Deposit Insurance Corporation (FDIC), considerations included network operating systems compatibility, enhancing E-mail and directory services, applications support, server and workstation memory and processor upgrades, applications support, and routing software upgrades. This case study details the methodologies that brought together two WANs with more than 17,000 end users.

COMPANY BACKGROUND

The original project was created to merge the Banyan WANs at the EDIC and the RTC. The RTC’s corporate charter expired on Dec. 31, 1995, and its assets were integrated into the FDIC’s operations.

The RTC’s origins — and its reason for being — date back almost 10 years. When banks and savings and loans (S&Ls) became insolvent in the late 1980s, they called on the FDIC and the Federal Savings and Loan Insurance Corporation to prop them up. The task was so overwhelming that Congress was petitioned to assist. As a result, the RTC was created, designed to handle the disposition of the assets and liabilities of the failed banks and S&Ls until 1995. When the RTC’s corporate charter expired, all activities and assets rolled over to the FDIC. Its systems were developed independently of the FDIC’s but with this inevitability in mind.

The FDIC had no plans to keep RTC employees after Dec. 31, so FDIC personnel will assume all existing RTC computer network activity. This would be practical only if both organizations were similar in design and layout. Therefore, the project, which began in August 1993 and took 10 months to complete, was implemented to make the RTC’s WAN compatible with the FDIC’s.

THE CHALLENGES AND BENEFITS OF IMPLEMENTATION

The RTC’s Banyan WAN encompassed the 7,000 employees and contractors located in California, Colorado, Texas, Kansas, Georgia, New York, Virginia, and Washington, DC. The WAN needed to be connected to the FDIC’s WAN, which encompassed 10,000 employees who are similarly located. All the RTC Banyan servers targeted for upgrade were production servers being used eight to 12 hours a day, six days a week. Server upgrades had to be coordinated so the end users were not disrupted during the day and so there would be a fallback position if a server upgrade failed.

Several other areas for upgrades were also targeted. An operating system upgrade was required as part of the integration proposal. The FDIC’s 337 Banyan servers, from Banyan Systems Inc., are running on one network operating system, Vines 5.52(5); the 329 RTC Banyan servers were running on Vines 4.11(5), two revisions old. This network operating system upgrade was required to bring the RIC up to the same level the FDIC was running before merging the two organizations. Also, Banyan no longer wanted to provide fixes (i.e., software patches that solved “bugs” or problems) or enhancements for an older version of Vines, so the RTC had to upgrade its network to continue to receive operating system support.

As part of the operating system upgrade, a server hardware upgrade also was necessary, to support the enhanced version of software. Additionally, the Cisco routers in the RTC network needed to be upgraded.

The Business Opportunity

As part of the implementation, new functionality offered by the newest revision of Vines version 5.52 would allow the corporation to use the new features to operate the business better.

The enhanced functionality of the new E-mail under Banyan Vines 5.52(5) was one of the main reasons for the upgrade, because the RTC’s most important application was the E-mail system, and the most heavily used applications were the E-mail and the directory services, Streettalk Directory Assistance (STDA). The full listing of the combined organizations (a total of 17,000 users) under STDA would provide access to all end users by all end users.

Additional network management tools and diagnostic tools were included as part of the new network. Better performance tuning and use of resources would also be easier to accomplish under Vines 5.52(5).

Technical Benefits

The technical benefits of the Vines 5.52(5) operating system were:

  The new file format, S10, under Vines 5.52(5) allowed up to 4G bytes of modes per file system, up from the old file format, SS, under Vines 4.11(5), which allowed 64K bytes of ides. Each file or directory was represented by one mode. More files or directories per volume were required by the RTC.
  The Access Rights List (ARL) functionality was greatly enhanced under 5.52(5). Access control could then be given all the way down to the file level within directories or within subdirectories to a user or a group of users. Security issues could be tailored to the file level, which was not possible before.
  Greater network management was offered through the network management statistics on memory usage, server processes, hard drive activity, and CPU usage. The improved tools promised better server monitoring and network management.
  Valuable to the RTC were the tape backup and restore processes built into the operating system. Under Vines 5.52(5), the operator can back up and restore not just file services, but also specific directories and files with much greater ease.
  New printer functionality was also gained by migrating to Vines 5.52(5). Multiple print queues were serviced by one printer, and print queues were set up to print to other printers if a printer was overloaded. Print jobs were redirected by queue operators or done automatically.
  A less obvious benefit, but still an important feature, was the new routing matrix algorithm that was implemented into Streettalk. The overhaul to the routing matrix in Banyan Streettalk all but eliminated the sporadic occurrence of network “broadcast storms,” which were an inherent problem.
  New functionality was offered under Banyan Vines STDA. User IDs could be defined to include additional attributes on each user put into the system. The security could be set so no one could look at the associated attributes in the Attribute View Definition (AVD) file that holds them. The information contained in the AVD file could be masked and display only the users under STDA that the personnel department and the end user wanted displayed for E- mail purposes.


Previous Table of Contents Next

Copyright © CRC Press LLC