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).
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
REPORTS
ANALYTICS
Follow 
