ON THE WIRE

Parking Lot Fiasco Leads To Smart Segmentation

by Bill Alderson and J. Scott Haugdahl

Recently, a client called us in to solve some problems, recommend a segmentation scheme and provide some direction for a network architecture that would work over next several years. After a long, exhausting trip, we finally pulled into our client's parking lot in a suburban area, only to find that no parking was available. In fact, there seemed to be no place to park for miles. We inquired about parking with the guard, only to receive a "You've gotta be kidding" response. When we asked our host about parking, he said, "Hey, there's hardly room for managers in our parking lot, let alone a consultant!" Discerning that the lack of a parking spot was going to delay progress toward the impending birth of a new network architecture, we were given the gift of a parking spot reserved for "Network Services" around back. Once properly parked, we began our mission.

Bill: Hey, Scott, we've got a PPP story for our readers this month.

Scott: You mean the Point-to-Point Protocol for handling multiple protocols over serial links?

Bill: Nope. It's the Proper Parking Protocol.

Scott: Gee, sorry I SLIPed.

Bill: We'll come back to PPP in a bit, but first we need talk about why our client's network was a candidate for segmentation.

Scott: We started by examining the network documentation.

Bill: What documentation? We tried, only to discover that it was woefully out of date and lacked proper internetwork detail.

Scott: It was the same old tune. It's incredible the number of organizations we encounter that upgrade old systems or even install all new systems and end up perpetually fighting fire instead of managing and documenting their networks systematically.

Bill: In this particular instance, we dug in for a day to help better document the network architecture using our layered-by-protocol method.

Scott: This is a method where we document the network from a communications perspective to achieve a visual view of the network for each protocol configured.

Bill: That way, we can visualize packet flow from any client to any server or host and all intervening communications links and components.

Scott: Our client's headquarters network consisted of many hosts and servers using SNA, DECnet, LAT, HP Data Terminal Communications (DTC), TCP/IP Telnet, NetWare IPX, and DEC Local Area VAX Cluster (LAVC) and Pathworks.

Bill: The network was fairly stable until recently. Now it appeared that LAT, SNA and DTC sessions often disconnected, while NetWare and Pathworks users complained that things were slowing dramatically.

Scott: One Ethernet backbone received most of the traffic from WAN circuits that communicated with several mini and mainframe hosts. Recently added PC office automation staff members also used the backbone.

Bill: We placed multiple monitors and analyzers on the Ethernet to quantify traffic volume type and flow characteristics. We noted that several VAXes and HP-3000s were communicating with multiple protocols to many clients.

Scott: Armed with general traffic characteristics, we designed complex filters on multiple analyzers to further characterize traffic several different ways.

Bill: The dilemma seemed to be that the multiple-protocol hosts were central to every i ncoming circuit. How could they be segmented if most traffic was headed for these hosts?

Scott: Since one of the most heavily used VAX hosts had two interfaces, one solution would be to segment the users between the two VAX interfaces.

Bill: It wasn't that simple, since the VAX has the same DECnet-derived data link address on each interface. Having two addresses on two ports would confuse the transparent bridging necessary to connect LAT terminal servers.

Scott: We theorized that viewing the filtered traffic characteristics in real time would lead us to a solution. For instance, we can break the traffic into two categories, "Production" and "Office Automation."

Bill: Production protocols are the more latency-sensitive terminal-oriented protocols, such as LAT and SNA, whereas the Office Automation protocols are the file services-oriented protocols, such as NetWare and Pathworks.

Scott: By setting up one analyzer to monitor utilization of Production protocols and another to monitor Office Automation protocols, we could see what the effect of such a segmentation by protocol would look like before one even touched a hub.

Bill: Very clever. Production traffic on one backbone, Office Automation on the other. The filtered statistics made it all very clear, since we could actually see the way traffic would look on each segment after effecting the change (see figure below).

Scott: We call this "Smart Segmentation," since we didn't decide arbitrarily to break up the network by node counts--an approach we see used far too often.

Bill: Our exercise in segmenting traffic by protocol characteristics proved fruitful. We knew that, in general, Office Automation protocols produce heavy bursts of traffic, often pegging utilization for several seconds. Production protocols on the other hand, are more docile, predictable and very sensitive to being combined with heavy sustaine d traffic bursts from other protocols.

Scott: In the end, the VAXes were happiest when we placed DECnet on the Office Automation interface and LAT and IP on the Production interface. This also got us around the bridge problem mentioned earlier, as bridging will only be turned on the Production segment, allowing the terminal traffic to pass.

Bill: The design became the blueprint on which the future network architecture was subsequently successfully built and...

Scott: documented!

Bill: Upon leaving that evening, we returned to our car to find substantial documentation on the windshield.

Scott: It read: You have parked in an unauthorized parking space. A second violation will result in a letter in your personnel file. A third violation will result in a boot being placed on your tire, requiring your manager's assistance to remove. A fourth violation will result in your car being towed at your expense and likely termination.

Bill: Wow. Here was an organization with leased WAN circuits costing millions of dollars a year. The network empowered (when it's up) thousands of users across the nation, but this company didn't have a network architecture diagram or management directives to manage it proactively.

Scott: Of course, we did have a wad of parking documentation on our windshield.

Bill: It's a pity the Proper Parking Protocol preempted management attention over the mission-critical networks.

Bill and Scott are principals of Pine Mountain Group. They can be reached at otw@pmg.com. Portions of actual trace files from selected columns are available via Pine Mountain Group's Home Page (http://www.pmg.com).

December 15, 1995